So I’m sitting here in my hotel room in Helsinki, after a quick flight from Oslo. In fact, the flight arrived early, and that’s a first time that it has happened for me. I was in the taxi on my way to the hotel 5 minutes before the scheduled time of arrival for the flight.
Anyway, so I got to hotel, had a shower, turned the laptop on, and logged on to the wireless service provided by the hotel along with the phone company. Then I connected to the Nokia VPN and my own VPN to download my emails. After reading said emails, I hopped on to IRC.
As a helpful chap that I am, I saw someone posting a link on the #qt channel to some code of theirs they were having problems with. I clicked the link to see what the problem was. The bizarrely-sized progress window in my KDE 4 popped up, with the progress bar indicating no progress at all.
“Odd,” I thought, then I clicked Cancel and tried again. No such luck… “Maybe that website is just not working from here” I pondered. I decided to try one famous search engine whose reminds us of a very large number. And again it didn’t load.
I was having network trouble.
My first reaction was to test whether the Nokia VPN was still on. It was dead, but vpnc had not disconnected, so the traffic to the Nokia VPN wasn’t going anywhere. I disconnected, but still no Internet.
A couple of minutes of searching, I found out the reason:
cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.0.0.6
search example.com
(This is not edited, the hotel internet really gave me a domain search of “example.com”)
Can you guess what the problem was?
Let me give you a hint: my blog six months ago called “The Great Crash of 2009” addressed this very subject.
The DNS server that the hotel network gave me is on the same network as my home VPN (because my home DHCP server is the ADSL router by my Internet provider). So all my DNS queries were timing out, because they were being transmitted over the VPN to an address that isn’t active. (I think it’s assigned to my N95 when I’m at home, but I’d have to be home to check)
This problem I had is probably quite common, I imagine. I mean, the hotel I’m in isn’t exactly in a touristic spot. It’s probably sought more by business travelers, who, like me, come with a laptop and VPN access to their offices. How many of them reroute 10.0.0.0/24 when the VPN is active? I would bet quite a few.
So we’re 6 months into the year of the Great Crash because IPv4 runs out. And we’re still not using IPv6.
Quick update on how the transition worked
The blog of 6 months ago analysed our own transition into the Nokia network as a case study of where IPv6 would have been helpful. The curious readers of this blog were left imagining “how will they pull off this transition? Will the FTP servers ever be tested again? Can the Trolls print?”
I left you in suspense, so here’s what happened in these 6 months.
Yes, we can print. Otherwise I wouldn’t be here in Helsinki, because I wouldn’t have printed my eTicket.
The network transition isn’t complete yet. I don’t know the exact reasons why our test farm remains in the old Trolltech network, but it does. All I’ve heard are anecdotes and the worst cases. For one thing, we received the level 3 switches that serve the network. But our sysadmins could not install them: we had to wait for a technician to come from the outsourced network provider, unpack the switch, install it in the rack and plug the cables.
Our QA department has been expanding our virtual machines for running tests in parallel. A week or two ago, they reported they couldn’t add more machines. The reason? They had run out of IP addresses in the block allocated by the outsourced network provider. They had to wait for a new allocation — possibly a reallocation!
The network tests in Qt have all been updated to reference the test server by a generic name, “qt-test-server.qt-test-net”. Anyone running the network tests must update their /etc/hosts or Windows equivalent with the IP address of the virtual machine.
(By the way, the network tests of Qt have been made available in the open repository for anyone to see)
We also had to go over all the tests and fix any failures caused by moving to the Nokia network. All of the network tests are now passing (including the one in tst_QHostInfo that assumed that “foo” would never resolve).
Now we have to face other problems. Like today not being able to log in to the Nokia intranet websites… but this one I had been expecting: Nokia IT requires us to change our passwords every 90 days.
The price of security. (Or is it?)
