View Full Version : How my Squeezeboxen nuked wireless relaying of DHCP

2009-11-06, 22:28
My remote office's network is laid out like so (read top to bottom):
[microwave link to outside world]
[D-Link DI-604: wired router hosting DHCP server]
[Engenius ECB-3220: wireless AP relaying DHCP requests] [other wired devices...]
[SB3] [Boom] [Laptop 1] [Laptop 2] [...] <-- all wireless DHCP clients

Both of the Squeezeboxen (the Boom and the SB3) are tuned to SqueezeNetwork in perpetuity. (Someday I'll dup our home music collection and host a 'Server here.)

PROBLEM: I came into the office one day, fired up [Laptop x], and found that I couldn't acquire a DHCP lease through the wireless link. Wired clients still worked. Curiously, the wireless SB3 continued to stream music from SqueezeNetwork, even though it had a 169.xxx address. This behavior persisted through a firmware reset of the AP. I was blaming the a hardware failure in the AP, but didn't understand how the SB3 could continue to stream.

DIAGNOSIS: In my absence, the office had enjoyed a power outage. The S'boxen rebooted more quickly than the AP, which in turn had rebooted more quickly than the router. So the Sboxen adopted 169.xxx addresses, which was enough for them to keep streaming from their last known source. However, as long as the Sboxen kept those initially-forged links to the AP, the AP would not relay DHCP replies from the server to any workstation arriving late to the party.

SOLUTION: I had to disconnect power to the Sboxen, then reboot the AP, then repower the Sboxen, before the AP would relay DHCP.

Here's hoping that sharing this story saves somebody else a few hours of debugging their network

2009-11-07, 06:14
the only way it gets fixed is if you file a bug at bugzilla.

on my slim stuff, i either reserve a dhcp addy in the router, or set a static ip, so i don't think i ever see the issue.

2009-11-07, 10:25
I'm more inclined to blame the Senao ("Engenius") AP firmware. Perhaps the problem is more general... I'll take a look at bugzilla.

2009-11-07, 10:41
This is a classic race condition. There's really nothing to be done about it other than always power up router, AP, and devices needing DHCP IPs in that order.

In addition, many routers honor a lease if it is the same as a previous one - and most devices (including PCs) that use DHCP addressing will try and get the last address they had.

I reboot my router a lot while testing security tweaks and my devices NEVER need to acquire a new IP lease.

I'm thinking your router and/or AP may be unusual in this, OR you just hit a particular combo of timing that jammed up the works that you'll never see again.

2009-11-07, 11:49
This doesn't sound like a squeezebox bug at all. 169.254.x.x is a non-routable subnet that should never have a gateway. What device is acting as the gateway for 169.254.x.x?

This seems like really bad behavior on the part of the AP. It's changing the internal NAT subnet based on IP traffic it sees from clients? That seems very very broken.