Wandering Ibex

After 6 weeks with Ubuntu 8.10, aka Intrepid Ibex, the change that has most affected the way I use my laptop is the new network manager. Connecting to a wireless network is easy and just works. It is generally fast to connect, definitely faster than with 8.04 aka Hardy Heron. It will immediately recognise networks it knows about and connect automatically. In particular, it is much better than Windows at connecting to a Wi-Fi network that does not advertise its SSID and recognising it later as a known network.

But the biggest benefit is the support for 3G modems out of the box, in particular the Huawei models available in the UK. When I plugged in my 3 USB modem for the first time, it recognised the device, asked me what country and what operator I was on and that was all the configuration I had to go through: no software to install, instantly on. It also integrates seamlessly into the network manager so there's no flaky third party software to use every time I want to connect. I just have to plug the modem in, select it in the network manager drop down and hey presto, in a few seconds I am online, whether in a pub, on the train or anywhere I've got network coverage from 3 (which is sometimes a bit patchy, I have to admit). OK, there's one thing it doesn't do, which the Windows version does: it doesn't tell me how much of my monthly quota I've consumed. However, I very rarely download large files via the modem so I've never reached the limit: large files is what the (fast) home broadband is for. It would be more important for someone who does use a 3G modem more heavily than I do. Maybe that's a feature to ask for in the next version?

Asus Eee PC, Nokia E65 and WPA Wireless Networks

My home wireless network uses WPA for security. When I received my Asus Eee PC, it could not connect to my wireless network complaining about the shared key being too long, which I found odd because all other devices connected fine. Then when I got my Nokia E65, it couldn't connect either but wouldn't tell me why.

Then, over the weekend and prompted by a friend, I decided to fiddle with the Eee PC and get it to connect to the wireless network. So, in an attempt to humour the machine, I changed the pass phrase on my network to something shorter. An lo and behold, the Eee connected! It could then ping all the machines on the network except the router it was actually connected to. As a result, it couldn't route any traffic outside the network so couldn't get on the internet. Checking the routing tables, everything looked fine. It could resolve any name into an IP address so it had nothing to do with the DNS. I thought there could be something dodgy with DHCP so I re-configured the interface manually... and it worked! Going backwards, I set it back to DHCP and... it worked fine, even though I didn't change anything compared to the first attempt. That's IT for you: sometimes, doing the same thing twice fails the first time and works the second, for no apparent reason.

Now all chuffed by my success with the Eee, I decided to try again with the Nokia E65. I first spent a good 20 minutes trying to find how to set up access points and being defeated by the completely non-intuitive menu system of the S60 operating system that runs on those phones. I then turned to the user manual (yes, I know, RTFM) which only marginally helped because said manual is riddled with mistakes and the relevant menu option mentioned did not exist. So I spent another 10 minutes finding out where the manual was wrong. I eventually found what I wanted and set up my access point. Of course, in keeping with the experience with the Eee, it failed to connect first time. The main difference was that the E65 just closed the browser without explanation rather than tell me what went wrong. But trying a second time it worked fine.

So there you go: shortening the WPA secret key means that all my wireless enabled devices can now connect to my home network (apart from the Nintendo DS but that's because it doesn't support WPA at all). Some might say that a shorter key means my network is less secure. Yes and no: considering the network doesn't advertise its SSID in the first place, that's two pieces of information you need to guess. And then, because I knew I was shortening the pass phrase, I took more time to think of something that would be more difficult to guess.

PS: Nokia, could you please ditch the poor excuse for an operating system called S60 and give use something intuitive and user friendly instead? Now that you've acquired Trolltech, could we have nice Qtopia based phones please?

The Weakest Link

I asked my ISP what BT had done to rectify the problem on my broadband and got the following answer:

BT had changed the SNR margin and applied interleaving to your line to try and reduce errors in transmission. This did not seem to fix the issue though. The way your service is now delivered has changed from BT exchange equipment to our own LLU equipment.

So, in other words, BT is now completely out of the loop (literally) and it works great!

Broadband purgatory

Any experienced network administrator will tell you: the worse problems are not when nothing works but when it sort of works but not quite. So when I started having performance problems with my broadband connection 6 weeks ago, I knew I was in trouble. How to explain the problem to my ISP's helpdesk? I could download pages, even though they sometimes timed out but I couldn't upload any file. So my flickr photo stream started to dry out.

Of course, the first reaction of my ISP was to blame my equipment. As I had the same problem on a Power Mac G5 running OS-X and an IBM laptop running Windows XP, with Firefox as well as Internet Explorer, whether I was connected with to the network wirelesly or with a cable, it quickly came apparent that the only potential culprit on my side was the broadband router. As I was due for an upgrade anyway, I bought a new one and proved that I still had the problem with two different routers.

Then followed the various requests for test outputs to see what could go wrong. All this was a very slow process as I could not test during the day while my ISP's helpdesk was only able to review the tests during working hours. So a routine set in: I do a test during the evening, they look at it the following day, they suggest something else, I do a new test, etc. I quickly became frustrated and ended up writing a shell script to automate calls to traceroute followed by ping in order to get any decent statistics. And, lo and behold! It then became obvious that, anywhere on my network I had no packet loss whatsoever, whereas as soon as I reached my ISP's first router, I had between 5% and 50% packet loss depending on packet size. Now, 5% loss is huge and definitely way too high for TCP/IP to function properly. 50% loss doesn't even bear thinking about. The most likely culprit was now my broadband line. So my ISP passed the call to BT and, miracle, my connection now works like a charm! It only took 6 weeks to get there.

It's scary how we get used to facilities such as broadband though. Those 6 weeks really felt more like 6 months of frustration. Every time I clicked a link or a button on a page, I had no guarantee that it would load properly. Interestingly enough, the pages that were most affected by the problem were pages that depended on AJAX, GMail in particular. I suspect that this is because, when a normal page fails to load completely, the only downside is missing images and suchlike. The page is still usable. But an AJAX page can be completely crippled when it can't load everything: some essential functionality is missing. In fact, I saw exactly the same problem at work recently on my current project: a web application that depends heavily on Javascript and is completely broken if some of the Javascript source files fail to load properly. So, there's a moral for all AJAX developers out there: one of the rules to follow to build bulletproof AJAX is to ensure that your application still works, even if some of the code fails to load.

Following this, I just created a project on SourceForge, where I will maintain the script I developed during this incident. Obviously, this assumes the project gets approved by SourceForge. Assuming it does, I hope this tool proves useful to others and if anybody can contribute by testing it on other operating systems such as Linux or Solaris and helping me make it generic enough to run on those, it'd be much appreciated.