The Substantially Similar Weblog

I recently upgraded my home router box to Debian Lenny. Everything went fairly smoothly, with a few exceptions. My NFS mounts no longer worked because apparently wildcards are no longer allowed in IP addresses in /etc/exports; the export addresses needed to be translated to subnet format (e.g., 192.168.98.* becomes 192.168.98.0/824).

But after a power failure last night, the router box rebooted and I was no longer able to access the Internet from any clients on my LAN. Strangely, I could ping or traceroute external hosts and perform DNS lookups, but web surfing and ssh timed out after an initial handshake. I noticed by telnetting to port 80 of an external host, I got an error back from an invalid HTTP request (e.g. “oeunthioues”), but if I sent a standard valid request (GET /index.html HTTP/1.0), the connection just hung with no response.

I won’t recount all the false leads I had in diagnosing this problem. It turned out that the Internet-facing NIC on my router box had been reset to a low MTU. By setting the MTU on the LAN clients to that low number, or raising the MTU on the Internet-facing NIC back to 1500, the problem was solved:

# ifconfig eth2 mtu 1500

After restarting networking on the router box, the MTU was again set back down to 576, which is apparently the default MTU for an X.25 network. I have no idea why the interface is getting that value by default (where it wasn’t before), so I just added a hack to /etc/network/interfaces to fix it:

iface eth2 inet dhcp
  post-up /sbin/ifconfig eth2 mtu 1500

Interestingly, pre-up didn’t work.

Hopefully I’ve included enough relevant terms in this entry that others with this problem will find it. It was hard to diagnose because no errors appeared in any log file, and I had partial but not complete connectivity from internal clients to the Internet. My first guess was that it was due to the iptables upgrade, but in fact it was entirely unrelated.

[tags]Debian, Lenny, iptables, firewall, router, MTU[/tags]

There is a widespread problem with the Linux driver for the Realtek 8168/8169 cards where the modules load properly and the card is visible but no link is detected. E.g.:

Jun 21 18:28:41 localhost kernel: r8169: eth0: link down
Jun 21 18:28:41 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready

There are lots of details and suggested solutions from the Ubuntu people. None of the suggestions worked for me, however. Several of them suggest configuring the card under Windows, but the box containing this device is a single-boot linux fileserver. The “wake-on-LAN” functionality seems to be implicated, but not in a way I can see how to fix.

After much head-banging (in the bad sense), I found a simple solution:

(1) Install ethtool
(2) Modify /etc/network/interfaces as follows (substitute your r8169 interface for ‘eth1’ and other settings accordingly):

iface eth1 inet static
pre-up /usr/sbin/ethtool -s eth1 autoneg off
address 192.168.98.1
netmask 255.255.255.0

This did the trick for me where no other solution would work. Of course, link autodetection no longer occurs, but that’s a small price to pay for connectivity.

This is a Debian etch installation using a slightly more recent kernel (2.6.25-2-686).

As an interesting side note, on this new box, the interface appears as eth0 in the kernel logs, but is actually mapped as eth1. Similarly, a second Ethernet interface appears in the log as a different device number than that by which it is referenced. Any ideas why?

Update 6/22/08: Still not getting 1000BaseT (Gigabit), however. If I force 1000BaseT with ethtool -s eth1 speed 1000, the link goes down again (even with autoneg off). The same card in another box, however, detects the link and goes to 1000BaseT automatically. So I’m stuck at 100BaseT.

Update 6/24/08: Linux 2.6.26-rc5 fixes the problem 100% for me.

[Tags]realtek, r8169, linux, drivers, hacking[/Tags]

Inexplicable oddity of the day: X was hanging after log in. It looked like it got stuck on xrdb.

Inexplicable solution: /dev/null was not readable. (Not only do I not know why /dev/null being unreadable caused the problem, I also don’t know why /dev/null lost its world-readable bit).

There’s a first time for everything, I guess, and this is the first time /dev/null has been the crucial point in fixing my system.

I’m not sure I’d ever be able to explain how to diagnose and fix problems like this to newbies.

Apologies to any Planet Debian readers for having just monopolized the front page with several stories; I moved a bunch of old stories to a new blog topic, and apparently Planet Debian thinks they are all now new stories, even though they have their old timestamp. If anyone knows a remedy for this, please let me know. (I guess this entry is further compounding my overpresence!)

At long last, my bug #184361 is fixed and my one line patch has been accepted! This is a happy day for me. I receive dozens of hits per day related to this bug, which prevents users from cancelling their own print jobs without authentication. I’ve also had to respond to a lot of email over the last couple of years helping people rebuild cups with this patch.

My only regret is that my useful linux page is slightly less useful now that my patch has been accepted.

Spam gets more clever all the time. Yesterday, this· appeared on the debian-mentors list·:

 Date: Wed, 7 Apr 2004 22:36:41 -0700 (PDT) From: rasheed badmus  Subject: free game boy To: debian-mentors@lists.debian.org Hello: I'd like to request for someone to sponsor the following unofficial packages I have: snes9express (1.39-beta) - a GUI frontend for SNES9x (as far as I know this is still an orphaned package); and visualboy advance (a gameboy/gameboy color/gameboy advance emulator for Linux). The said packages can be obtained in this apt source location: anything that u want to send,send it by this below. P.O box 1103 agodi Ibadan, Oyo state, Nigeria. 

Although list members quickly figured out that this was actually spam·, someone made a good point: if spammers start using text from a typical posting to a list in the body of their message, it’s going to be very hard to use content-based filters reliably. I can’t see how, for example, a Bayesian filter would be able to drop the above message in the right bin.

Also, see this fairly technical but fascinating description of how an Internet cafe technician in Dublin caught a spammer red-handed·. The best part is where the spammer tries to eat his USB memory stick so the police won’t get it. (Sorry, this is one instance where my civil liberties instincts are overcome by my harsh justice instincts).

(this is another case where this post would ideally be filed under two categories—”Debian” and perhaps “spam”—which is not yet a category.)

I just discovered that spoon, aka Ian Truskett, has passed away.

I never met spoon, and had only exchanged a handful of emails with him. I maintain the Debian package of a perl module he wrote, libwww-shorten-perl (or WWW::Shorten). It’s an odd connection to have with someone, and now to realize that they died. I don’t know quite what to do about it.

It also reminds me that there are many small free software projects out there maintained by lone developers (I have several myself), and as the movement ages we need to figure out how to pass on the torch without too much disruption. Maybe we should all have something like a living will, expressing some sense of who should take up our projects when we’re gone.

I’m uploading spoon’s last release of WWW::Shorten into sid now, released just a few weeks before he died. It’s not much of a tribute, I know, but it’s the only thing I can think to do.

After eight months, I finally completed the Debian New Maintainer process a few minutes ago. I am now ajkessel@debian.org, at least for Debian purposes. I once asked an employer who took 6 months to hire me whether they did hiring by attrition. I think Debian might have a similar process, but it’s probably the only way to weed out people who won’t be sufficiently committed to the project.