The Thin Beer

Faster than ADSL

Some researchers in Israel have recently been investigating high bit rate communication technologies, with surprising results (PDF)---achieving 37,000 Kbps (compared to 128 Kbps for ISDN and 1500 Kbps for ADSL).  Hat tip to Mitch Wand.

I broke the power law

Debian Linux and resolv.conf

I posted earlier about how I was having some bizarre problems with DNS server entries in /etc/resolv.conf on Debian Linux.  I see from the Typepad referrer logs that a lot of people are finding The Thin Beer by searching online for Debian+resolv.conf (but not as many as search for beer+pictures).

One of my pet peeves about the Internet is that it is often very easy to find others who have had the same technical problems, but very difficult to find anybody with any answers.  Judging from what can be found online, most people never find online answers to their technical questions.  Even more frustrating is when the original poster will respond with nothing more than "Never mind, I solved the problem".

So, I have been remiss by not describing the resolution to my DNS problems.  If you don't care about such things, you can skip the rest of this post.

The symptom of the problem was that /etc/resolv.conf would unpredictably show up with new nameserver addresses, which were unreachable.  I am using Cisco's VPN client software for Linux.  It turns out that the VPN client software wants to change the DNS server addresses on the client machine (I think I know why, but it's not important).  It does this when the client connects to the VPN.

/etc/resolv.conf is restored to its original status when one of three things happens: when the VPN client disconnects from the VPN, when the kernel module is shut down, or when the kernel module is first started.

The problem would occur when none of these things would happen.  Then, on the next boot, the DNS entries would be messed up.  The solution is to make sure that at least one of these three things happens.

I do not always remember to disconnect from the VPN when I shut down the computer.  That leaves starting the kernel module or stopping the kernel module.

The VPN client installation reported that the kernel module would be started automatically when the machine was booted, but this fails to happen on Debian.  Apparently, Debian uses runlevel 2 for what other Linux distributions use runlevel 3.  The Cisco VPN client installation places a startup script in /etc/rc3.d (as well as /etc/rc4.d and /etc/rc5.d), but not in /etc/rc2.d.  Solution: place a symlink to /etc/init.d/vpnclient_init in /etc/rc2.d that looks exactly like the one in /etc/rc3.d.

This solved the problem, but raised another problem on this machine.  When the machine is restarted and enters runlevel 2, the VPN kernel module is started, and the DNS server addresses are restored if they need to be.  However, this occurs only after the machine tries to start its mail transfer agent (MTA), exim4.  Exim4 hangs (for five minutes or so) if it can't reach a DNS server when it starts.  Five minutes is an eternity as part of a boot sequence.

One solution to the latter problem is to change the priority of the VPN startup script in /etc/rc2.d, so that it runs before exim4 (or else change the priority of the exim4 startup to achieve the same effect).  I don't know if this solution has any unintended consequences.

The solution that I adopted was to put shutdown links to the vpn client script in runlevels 0 and 6, so that the VPN kernel module will be stopped when the machine is shut down or rebooted.  Now, everything works fine.

Debian kicks my butt again

I posted earlier about how I was having some struggles with Linux at home.  I thought that I had Debian reeling with my agressive punching, but it turns out it was just employing "rope-a-dope" tactics against me.

A couple of days ago, I used the nifty Debian package manager to automagically upgrade hundreds of pieces of software.  The next time I rebooted (you guessed it), the wireless network had stopped working again.

This time, I knew right away what I had done.  There are no Linux drivers for my wireless card, so I am using ndiswrapper and the Windows drivers.  ndiswrapper has some user-level utilities, and a kernel module that must be compiled for your kernel.  When Debian upgraded the ndiswrapper utilities, it did not upgrade the source package for the kernel module.  Since the driver and the utilities were different versions, the kernel refused to load the driver.

It's really frustrating to fix Linux problems without Internet access.  First, you can't search online for others with the same problem (and hopefully, solutions).  Second, you can't download software.  It took me a day and a half until I could get to my office and download a later version of the driver sources.

Debian Linux and I do not get along

Update: I've solved the problem I was having with DNS.

You may have noticed that we didn't post much last week (OK, maybe you didn't notice that).  We were having network problems at home, and our Danish class kept me too busy to spend much time at my office.

Before we came to Denmark, I bought this fabulous(ly cheap) 12" laptop to take with us.  I wiped Windows off it and installed Debian Linux.  Getting everything (touchpad, sound, wireless network, USB ports, DVD, etc.) to work was an adventure---mostly because nobody really knows (except Averatec, and they're not saying) what crazy, cheap, little-used, proprietary chips are inside the thing.  It was definitely not like installing on a Dell or IBM laptop.

Anyway, wireless in the apartment worked using DHCP until last Tuesday, when it inexplicably died.  Tech support at the ISP were little help (I didn't even say Linux, either).  So I just switched from DHCP to statically configuring everything.  Everything worked then except DNS.  Debian puts DNS nameserver IP addresses in /etc/resolv.conf.  I could bring up the wireless interface, edit this file, and everything would be cool.

The problem was that bringing up the interface overwrote /etc/resolv.conf with bogus IP addresses.  They weren't the same every time, and I still have no idea where they were coming from.  One of my former coworkers (I use them as tech support, it helps to have friends at a networking software company) suggested that DHCP had made resolv.conf be a symlink to some other file, and was still trying to write to that file.

Well, I checked, and /etc/resolv.conf is not a symlink.  However, the problem mysteriously healed itself, through no action of mine.  Nothing's changed /etc/resolv.conf for a few days.  Maybe it can tell I'm watching it.