… or the tail of how I spent the better part of a day scratching my head.
Don’t assign static IP addresses via
ifconfig on the machines in your LAN. Let them use DHCP and then assign static IP addresses to the machines (via their MAC addresses) on the router interface.
When it rains
On Monday this week, our home DSL behaved very flaky. Really slow with a lot of packet loss. Since I’m usually very patient, I didn’t immediately call the provider to open a ticket, instead I waited to see if the problem would go away. It didn’t. On Tuesday I opened a ticket with the Telco, and at the same time tried to figure out what was going on. Reset all devices (splitter, modem, router), tried various settings to make the connection more stable, all to no avail.
Now, after the provider assured to me that the line was ok, I was a bit desperate and figured I’d replace the good old Linksys WRT54GL (running DD-WRT) with the new ASUS RT-N66U which I had bought a while ago and never gotten around to install.
Shortly after buying the new router I had already replaced the stock firmware with TomatoUSB, specifically the Shibby mod (As an aside, the TomatoUSB firmware is really well done and offers a lot of features that the stock firmware doesn’t offer). This gave me a head start for setting things up on the new router. I configured PPPoE, DHCP, WLAN in that order. Connected with the laptop via wireless and was able to use the internet (At this point, I think the old Linksys router just crapped out and reached end of life. I certainly won’t debug what the actual problem was but give it its well earned rest in the electronics graveyard.).
After that I began to reconnect all other devices, most notably the FreeBSD fileserver. Once connected, I couldn’t reach the WAN (internet) from any other machine. 80% packet loss on the line, whereas the internal LAN worked fine. Strange. Disconnect fileserver, WAN accessible again. After a morning of fruitless debugging, connecting and disconnecting devices and playing around with settings I decided to let it rest and go for a run, as one does.
After a day in the office with enough distraction (and some googling) I went back to the problem at hand in the evening and tried to see the difference between those devices that could be connected to the LAN ports and worked (like the printer, or the Windows netbook), and those that screwed the network when connected to the LAN port (like the fileserver). After a while it dawned to me that DHCP might be the culprit.
Traditionally the FreeBSD server had its own, static IP assigned via
/etc/rc.conf. Apparently, if you do this and at the same time assign (the same) static IP to the server’s MAC via the TomatoUSB UI, it doesn’t work.
The solution for me was to switch the server to use DHCP as well by specifying
/etc/rc.conf and then assign the static IP on the router’s interface.
I still don’t know what caused my connection to be bad at the beginning of the week, but here I am reconnected to the world and at the same time having been forced to finally set up the new ASUS router. I like it a lot and I’m looking forward to setting up more features like a guest WLAN, QoS and OpenVPN. But first I need a break from IT (net-)work.