Consumer Routers
Home / Musings Home

On the one hand, the "consumer router" (NAT routers made by companies such as D-Link, Netgear, Linksys, etc...) is a pretty nice idea. They're easy enough for most non-technical "consumers" to install as a quick solution for hooking up a couple of computers in their house to a single Internet connection. And, since most consumers only use the Internet for looking at web pages and maybe checking their POP3 e-mail accounts, I suppose that the consumer routers they buy work fine for them.

Unfortunately, the routing capabilities of most of the consumer routers I have used are not quite up to snuff. Since the routers are using NAT, they have to keep a table of open connections, so that they know where to send incoming packets on various ports. Unfortunately, most of the consumer routers I've had the displeasure of using seem to have a rather short timeout on inactive connections in their connection tables. So if I've SSH'd into a remote host, leave for 20 minutes (during which no traffic is generated on the SSH connection), then come back and want to use the SSH connection, the router will have forgotten all about the connection, and won't be able to route the returning packets from the server back to my PC. So the connection will just drop. Just lovely. Some consumer routers I've used have a short enough timeout that they even drop IRC connections now and then! I mean, gee whiz guys, the IRC protocol sends pretty regular 'pings' back and forth between the server and the client, you'd think that would be enough to keep the router happy. But no. And of course, being a "consumer router," I've never seen an option to change the timeout, or to set a longer timeout on certain ports/protocols than others (which would come in handy if the maximum table size was very small), or anything ilke that.

Because of these and other issues, I typically use a PC with two ethernet cards running Linux as my router. I don't know what the default idle timeout for NAT table entries is in Linux 2.4, but I've left connections idle for days and never had a problem with them. All in all, Linux 2.4's routing features suit me very well. However, an incident that occurred as I was moving into my dorm this year is a perfect example of the kind of problems that I typically have with PC hardware:

I was using my Linux router at home on my cable modem all summer, and it was working just fine. I have two identical 100mbit PCI ethernet cards in the machine, which are run by the natsemi.o (National Semiconductor chipset, I guess) driver. A DHCP server binds to one ethernet card and gives out IP addresses on my LAN, and a DHCP client sends queries on the other ethernet card to get an IP address from whatever WAN the machine is connected to, be it a cable modem, or a dorm network. After that, things just fall into place with some routing/NAT rules I've set up, and everything goes from there. So in theory, there should be no reconfiguration and no messing around required to change the router from one Internet connection to another.

Immediately prior to my move, I issued the 'shutdown -hn now' command to the router, powered it off, unplugged it, and put it in my car. After getting here and unpacking, I decided to hook the router back up so I could get on the Internet. However, my PC could not get an IP address from it, nor could I ping the router even after manually configuring my PC with what should have been a suitable IP address. I thought that this was pretty strange, since the activity light on the router's LAN ethernet card was flashing and the link light was on, but nevertheless, the two machines would not communicate.

In order to solve this problem I disconnect my monitor from my PC and hook it up to the router. I then reboot the router, and notice that only the WAN ethernet card (eth0) was being detected by the natsemi.o driver, and that the LAN ethernet card (eth1) was not being detected or activated by the driver at all. This seemed pretty strange to me, since BOTH ethernet cards showed up just fine in the PCI device list in the computer's BIOS, and both ethernet cards also showed up in the Linux kernel's copy of the PCI device list (in /proc/pci). But no matter what I did, natsemi.o would only see one ethernet card.

Now, this situation seemed pretty strange to me, since I had made absolutely no software or hardware configuration changes to the machine to bring this malfunction about. Both ethernet cards were fully seated in their PCI slots, the link and activity lights on the cards were working, and the computer had not been excessively shaken up during the move or damaged in any way.

At this point, the obvious solution to try is to move the ethernet cards into different PCI slots. Logically speaking, this shouldn't make any difference at all, since the ethernet cards were not moved to create the problem, so why would moving them solve it? But realistically, from having spent so much time screwing around with computers having this kind of problem before, I knew that this had a pretty good chance of solving the problem. And solve it it did. I slid the bottom ethernet card down one PCI slot, and moved the top PCI card into the slot previously occupied by the bottom card. When I booted the machine back up, both ethernet cards were detected and activated by the driver just fine. Now, how much sense does this make??

Well, this article is getting long and going nowhere. But if consumer routers worked a little bit better, I wouldn't have these kinds of problems because I wouldn't have to use a PC to do a job that should be able to easily be done by an appliance. But I think it's also something of a sad state of affairs when PC hardware (or, maybe it's just the PC hardware that I happen to own, but that seems like a pretty big coincidence) is so shady that I have come to not really be surprised at getting this kind of behavior out of it.

Note: Any routers or other products appearing in the following advertisement are NOT, and I repeat NOT necessarily endorsed by me. I am NOT in direct control of the selection of the advertised products.