Matt-J.co.uk : Ramblings

Here’s something that seems a little interesting, O2 appear to be sending a header of the end users mobile number, to any website visited over their mobile data network.

Header is ‘x-up-calling-line-id’
Other networks don’t feel the need, I wonder what their reasoning is, either way, questionable privacy fail here!

More info here;
http://lew.io/headers.php

So, it turns out i’m one of the lucky 46,524 ElReg (The Register) readers who has had their e-mail address spammed to a few thousand people… who have in turn, kindly placed it on PasteBin, random torrent sites, many forums, the side of the moon with a laser and other such annoying places!

And yet, i’m not that annoyed!

Here’s why… and I think in this day and age of everyone worrying about every bit of data, it’s important;

1. I’m called Matt and my blog is at www.matt-j.co.uk. Is it really that hard for a targeted phishing attack to work out an e-mail address in the first place?

2. It’s the register, a website that takes pride in highlighting technical cockups, basterdisations, IT Fo Pah’s and Comical! Yahoo! Related! Exclamation! Mark! Frenzy! Issues! before they’ve even sat down for the morning caffeine…. So no matter how annoyed we are all individually feeling, I’m pretty sure as an organization they’ll be feeling ten times worse for being beaten at their own game.

3. Did I mention it’s the register? I’m finding it quite hard (Maybe a psychologist wants to tell me why) to get annoyed with such an instutution within the industry, somewhere that generally gives you a good morning roundup of crap you need to concern your little head with.

But mainly because (and this is the important bit I was talking about at the beginning, the rest was just to test your stamina and determination!)…
They owned up, instantly, in an e-mail to everyone affected, disclosing figures that are far too un-rounded to be made up!

Yes, I think that’s it… Look at the recent Blackberry incident, it wasn’t that the service was down, it was that no-one from blackberry would give any of the circling vultures a single word for hours, even as speculation grew, nothing, twitter messages a-plenty… nothing! THAT’S the problem.

So ElReg, as much as you’ve amassed a million cocks to put yourself (and my e-mail address) in such a bastardy situation, it’s not going to stop me reading your news in a morning, fair play for making a hard decision.

And everyone else, I don’t claim to know much about business, but if you’re sucking at an all time low when competitors around you selling exactly the same service/product/moon etching laser are doing well, you may want to look at becoming more open and transparent with your customers.

Just my 10p, keep the change!

Matt

Hi all,

Came accross this issue the other day and since i’m currently stuck on a train between London Euston and Manchester, with what could be called a passable excuse of an internet connection, I’ll take a moment to document it, hope it saves someone else some head-scratching.

Issue: If using a Policy-Map based service policy within IOS to filter traffic on an interface and the undelying class-map is edited with any ‘match protocol http <more>‘ statements, the policy-map stops processing traffic, effectivley turning itself off for that interface.

Consider the following, two interfaces;

Vlan 1: 192.168.0.1/24

Loopback 99: 192.168.100.1/24

We the create a simple class-map to match ICMP traffic and use this in a policy-map with a match action of ‘drop’.

We now assign this to the output of the loopback99 interface, with the following command;

conf t
interface loopback 99
service-policy output TEST_POLICY_1
exit
exit

This should now block ICMP traffic (such as an echo/ping) to the interface IP;

We can also see the policy-map status for the interface, showing packets flowing through the assigned service policy and that drops are occuring;

Here is the issue, when we add/change any match criteria in the class-map (TEST_CLASS_1) relating to HTTP, the policy map stops working.

I also I added a ‘match protocol smtp’  before this, but you’ll just have to trust me that the policy-map continued working after that, only the addition of HTTP inspection caused a failure.

And now our traffic fails to pass through the policy-map, allowing ICMP which should be dropped;

The only workaround I have found is to remove the service policy from the interface and then re-add it after a class-map change, this restores correct functionality;

The following further output (too large for a screenshot) shows that while ‘broken’, the traffic was not even hitting the policy-map (as can be seen through traffic counters);

APCI877#sh policy-map interface loopback99
Loopback99

Service-policy output: TEST_POLICY_1
Class-map: TEST_CLASS_1 (match-any)
20 packets, 2000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol icmp
20 packets, 2000 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol http host "bob.com"
0 packets, 0 bytes
5 minute rate 0 bps
drop


Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
APCI877#ping 192.168.100.1 source vlan 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
APCI877#ping 192.168.100.1 source vlan 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
APCI877#sh policy-map interface loopback99
Loopback99
Service-policy output: TEST_POLICY_1
Class-map: TEST_CLASS_1 (match-any)
20 packets, 2000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol icmp
20 packets, 2000 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol http host "bob.com"
0 packets, 0 bytes
5 minute rate 0 bps
drop

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any


I have has a search via google and looked around the cisco bug toolkit, but couldnt see anything exactly matching this behaviour. I will be testing on the latest IOS 15.1 at some point (when i’m infront of a router that has a little more flash/ram).

Any suggestions, comments or blaringly obvious known cisco bugs i’ve missed are welcome on this one!

Matt

Last week I had the missfortune of needing to get some low bandwidth endpoints online for a client, these unmanned locations would have a few peices of technology sat behind an ADSL router with an IPSEC VPN back to a central location,bog standard stuff!

Naturally, I’d specified Cisco 877 ISR routers (as anything newer was overkill) allowing a good level of remote management, monitoring and control.

Base configuration was written offline, router is then connected to a BT ADSL2+ socket and an issue I immediatley recognised reared it’s ugly head;

PPPATM: ATM0 0/38 [0], Event = Vaccess Down
%LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
%DIALER-6-UNBIND: Interface Vi2 unbound from profile Di1
%LINK-3-UPDOWN: Interface ATM0, changed state to down

Errors would repeat every 30 seconds to 5 minutes, nearly two years on, 877′s still don’t support BT’s ADSL2+ connections it seemed!

Expecting a new, working ADSL firmware update in that timeframe, I headed to the cisco.com website and was bitterly dissapointed, even the firmware release ‘patch’ of yesteryear had been removed (which we didn’t have much luck with anyway when it first came out).

I knew we were looking for at least 4.0.0.18 (or 4.0.18 depending on where you see it written), backed up by many sources (just search for ADSL2+ BT Cisco 877).

What’s clear however, is that 4.0.0.18 as talked about all over the place doesn’t seem to be solving anyones problems and after getting hold of a copy by searching google for the what the filename would be based on the 4.0.0.17 download ( http://www.alcatron.net/cisco877/firmware/adsl_alc_20190_4.0.018.bin ) I once again confirmed this, even setting the line type to only ADSL2+ to rule out any negotiation issues still saw consistent drops every minute or so;

conf t
int atm0
dsl operating-mode adsl2+


(At this point it is probably worth mentioning that the 877 will use new firmware as long as it is called ‘adsl_alc_20190.bin’ and is found in the routers flash on startup (if not, the default firmware in the IOS will be used), further details and screensots courtesy of alcatron.net here!)

Eventually, after a lot of firmware testing, I found that cisco have some ‘by request’ only firmware versions which not many people seem to know about.
After testing internal version 4.0.223, I can confirm that my ADSL2+ link suddenly became stable and has continued this way ever since (Now over one week).

I think it’s a little strange that Cisco has kept this one so tightly under wraps.
Anyway, I am not suggesting that this firmware is fit, safe or even sensible to use, but it has resolved my issues here and if you’re reading this and at the very end of your patience with an 877/ADSL2+ combination, you can find the firmware at the link below;

http://downloads.netmetix.net/Cisco/Firmware/adsl_alc_20190_4.0.223.bin

I hope this helps! Let me know if you have sucess with this, would be interested to see how many people are still affected.

Hot off the press from Jamesbotham.wordpress.com, who kindly found the time to write up our Lync Integration efforts, this article will shows how to integrate Lync 2010 and the Cisco Call Manager Express to offer Enterprise Voice capabilities to your Lync installation.

Lab Configuration
The installation has a 4 digit dial plan, all of our Cisco phones are in the 3… range and our Lync users are in the 5… range.

We currently run a UC560 running CME 8.1 so have no access to E.164 support although 8.5 will have support and is coming to the UC500 soon. This document will allow the configuration without using this support so will probably be updated once I can play with 8.5’s E.164 support.

Lync Configuration

Topology Updates
From topology builder we are going to create a new PSTN gateway, to do this expand your site Media Servers and then select your mediation server and select properties to open the following window.

Select the option “New” to create a PSTN gateway, type in the FQDN if you have an A record setup for your phone system OR type the IP address in. Override the port from the default port to 5060 which is the standard port for SIP and CME’s default configuration, finally ensure TCP is set (TLS is out of scope of this document).

Click OK and ensure you publish your topology to your environment.

Trunk Configuration

Now its time to create your PSTN routing

Create the first of our 2 rules, this rule will remove the +44 (UK dialling prefix, replace with your own if outside of the UK) from the beginning of the number dialled from Lync and replace it with a 0 so that the CME can understand the number we are trying to dial.

Our final translation rules is designed to remove the + sign from the from our extensions as they are being dialled, again this is so that the CME can understand what we are sending it.

Normalisation Rules

Normalisation rules are used to try and form an E.164 number from the digits dialled by an end user, for example if you were to dial 01234 567890 from your Lync client the normalisation rule will turn this in to an E.164 of +441234567890 .

Again we are going to create 2 normalisation rules, to create the first select “New” under the “Associated Normalization Rules”.

This rule is going to allow us to dial a PSTN call through the CME device, we are looking for any number that starts with a 0 and is at least 2 characters long, once we have this we are going to remove the 0 and add +44 to form a valid E.164 number.

Rule number 2 allows us to dial an extension on the CME, this rule finds and number beginning with 3 and is 4 digits long and appends + to it.

Now that your configuration is complete ensure that you select Commit All to upload your dial plans back in to Lync.

Route Configuration

The final piece of configuration on Lync is to create a route from Lync to the CME, below is a working configuration that allows all numbers starting +44 and +3 to be sent to the CME. Ensure that you select the previously configured PSTN gateway as well as a PSTN policy.

Now that the Lync configuration is completed, ensure you go to each section and ensure everything is committed. Once you have committed all of the changes leave your Lync installation, get a cup of coffee and let Lync simmer for around 10 minutes to ensure that everything has replicated around.

In Part 2 we will configure Cisco Call Manager Express to work with the above configuration. Part 2 either HERE or HERE.

I think it’s time for a change, but some life changes take time, planning, certainty (and a shiny new LinkedIn Profile!)

… Changing a wordpress theme however, doesn’t take much effort at all! I’ve gone for something a little easier on the eyes (and a little more professional).

Thoughts?

More soon,

Matt

Holy crap!

http://www.hpl.hp.com/personal/Vinay_Deolalikar/Papers/pnp_8_11.pdf

“Scott Aaronson, associate professor of computer science at the Massachusetts Institute of Technology, is so sceptical that he pledged in his blog to pay Mr Deolalikar an additional $200,000 (£125,000) if the solution is accepted by Clay.”

http://scottaaronson.com/blog/?p=456

Crazy if this turns out to be true!

Mumblings: http://rjlipton.wordpress.com/2010/08/09/issues-in-the-proof-that-p%E2%89%A0np/

For the uninitiated: http://en.wikipedia.org/wiki/P_versus_NP_problem

So today I stumbled accross this: IBM’s new eX5 architechture/server range.

The main advantage is they seem to have decoupled memory from the Xeon X86 processors, allowing for extra rackmount modules of RAM without needing extra processors or more servers.

It’s all well and good and i’d like to be able to say, this this the birth of MAN’s (Memory Area Networks) to accompany existing SAN and LAN technology, however; I can’t answer that, as there does not seem to be much technical information available!

For example, is the architechture addressable? can a memory module be connected to multiple server nodes and memory used as needed (like a Dynamic SAN environment can for secondary storage). This would allow the system ideally to scale to a full MAN type scenario, with virtualisation provisioning technologies reserving X amount of memory for new VM’s, could even allow memory sharing between server nodes at memory speeds for clustered applications and failover scenario’s.

-or-

is it, as I expect, some silicon that extends QPI onto some custom IBM external interface, allowing point to point or limited point to multipoint connection to another tray of ram. I get the feeling this is probably more the case.

I cannot confirm from what I have read so far that it’s either of these, but if it was the former I should imagine there would be more of a fuss…

I guess i’ll have to wait a while for a distributed network technology that is still DDR3-Quick even after additional network addressing overheads.

Still, good to see movement from the norm, if for no other reason than to spark technical discussion.

Matt

Further Reading:

http://www-03.ibm.com/press/us/en/pressrelease/29570.wss

http://www.redbooks.ibm.com/abstracts/redp4650.html

ftp://public.dhe.ibm.com/common/ssi/pm/br/n/xsb03013usen/XSB03013USEN.PDF
ftp://public.dhe.ibm.com/common/ssi/pm/rg/n/xso03099usen/XSO03099USEN.PDF

Recently had to try and explain why a FTPS configuration was not working over an otherwise open private WAN. Issue was the two stateful firewalls at each end. Since writing this post I have shown it / e-mailed it to three other people to try and help them understand their own encrypted FTP issues.

So because it seems helpful I’ll add it here (IP Guru’s will get annoyed by the very simplistic language used, but it could save you time if you get asked in future!)

FTP connections require more than one channel of information, there is the control channel, TCP Port 21 and then single / multiple data transfer channels for PUT/GET/DIR commands for sending/receiving/listing data etc. The TCP or UDP ports that the data transfer channels use are negotiated between the server and client via the control channel once the user has logged in successfully.

A modern firewall works by looking at outbound connections from an internal network and ‘tracking’ them, that is, it keeps a record of internal host A trying to contact internet webserver W1 on port 21, then only allows traffic from the internet if it is from Webserver W1 on port 21 sending data to internal host A. In this way, any communication channel that has not originated inside the customers network will not be allowed into the network from the internet (or <NETWORK NAME REMOVED> in this case). Clearly this posed a problem for the FTP protocol, as the original FTP specification mandated that the FTP SERVER would decide on the data transfer channel ports and try connecting BACK to the client on these new ports, of course that did not work, as the firewall at the client end has no record of the client connecting outbound on these data transfer channel ports and so drops the connection.

To get around this issue (when security became important on the internet and people started deploying firewalls) the FTP standards created a new ‘PASSIVE’ mode, this mode just allows the data transfer channels to be created FROM the client to the server, allowing the firewall to see the outbound connection and therefore allow return data traffic from the server. This works fine, unless BOTH server AND client are behind firewalls, at this point, neither ACTIVE or PASSIVE mode solves the problem, there will always be one firewall that drops the connection because it hasn’t seen the computer behind it initiate the connection first.

To solve this, most firewalls (including ours here and the one at <SITE NAME REMOVED>) have ‘FTP Helpers’ built in, these pieces of code inspect the data passed between server and client in the FTP control channel (Port 21) and therefore see the negotiation between the systems over what data channels to use, because they see which ports the systems are getting ready to use for FTP data channels, the firewalls can dynamically open the needed ports, expectantly waiting for the connection and then close the ports again when the control channel disconnects (because if there is no control channel there is no user).

This works perfectly, however if you need ENCRYPTION on your FTP transfer, due to the nature of the data you are transferring, then, both control and data channels are encrypted from client to server and back again with TLS or SSL encryption.The firewall becomes blind to the data it needs to ‘help’ the FTP connection, as the control channel appears to the firewall as nothing but encrypted jibberish, therefore the FTP helper in the firewalls cannot work out what ports are being negotiated.

This is why you can log in successfully, but anything that requires listing, sending or retrieving data fails, as the data channel cannot be set up because the firewalls are not expecting the connections. The only resolution to this is FTP Clear Control Channel mode, this (as the name suggests) only uses encryption for the transfer channels and leaves the control channel in plain text so that firewalls along the path can deal with the connection correctly.

It is support for FTP Clear Control Channel mode that I wanted to log onto the server and check for, but after some reading into FileZilla server, it appears this is not supported.

It is for this reason that both our site AND <SITE NAME REMOVED> are to blame, purely because they both operate firewalls.

This is not an issue that can be resolved without doing one of the following:

- Running a FTP server that supports CCC

- Removing one of the Firewalls

- Removing encryption

- Permanently opening up a range of ports from/to both machines and then configuring both server and client to always use these ports for data channels. This would also mean only that pair of systems specifically configured for this server could successfully use FTP in this manner.