Bugzilla – Bug 2221
MAC address bug w/DHCP when bridging enabled
Last modified: 2008-12-18 11:38:39 UTC
Despite having the latest firmware (v22), I've noticed my SB2 is was not receiving its statically assigned IP address that I have my firewall configured to assign. I've tracked this down to the MAC address being reported/used. It is incorrect (at least from my firewall's point of view). Here are the DHCP leases given out over time to the SB2, with the corresponding MAC addresses as the first field. 20:05:78:00:00:0C 192.168.2.144 2005/09/28 20:34:13 20:05:78:00:00:0C 192.168.2.144 2005/09/28 20:28:00 20:05:78:00:00:0C 192.168.2.144 2005/09/28 20:30:01 20:05:72:00:00:0C 192.168.2.145 2005/09/10 17:19:48 20:05:70:00:00:0C 192.168.2.147 2005/09/02 16:49:27 Besides being incorrect, notice the change in the 3rd octet (70 -> 72 -> 78). My ARP table and firewall logs showed the bogus MAC address(es). Also, the the incorrect MAC address showed in the slimserver system 's ARP table. The assigned MAC address is 00:04:20:05:b8:2b, and this shows in the player's settings under Information. (Perhaps its just a coincidence that the 20:05 portion is in both the actual and bogus MAC addresses.) After unplugging the SB2, and assigning a static IP address, I find that the correct MAC address is being used again. Going back to DHCP yields the incorrect MAC address again. I then reset to factory defaults, and reconfigured everything in the SB2. Now I'm seeing the correct MAC address again (it matches the tag on the bottom of SB2). dhcpd: DHCPDISCOVER from 00:04:20:05:b8:2b via eth0 dhcpd: DHCPOFFER on 192.168.2.3 to 00:04:20:05:b8:2b via eth0 dhcpd: DHCPREQUEST for 192.168.2.3 (192.168.2.1) from 00:04:20:05:b8:2b via eth0 dhcpd: DHCPACK on 192.168.2.3 to 00:04:20:05:b8:2b via eth0 I've reviewed my firewall logs going back a couple of months. The bogus MAC address appeared exactly when I had enabled bridging (to help out another slim user, back on Sept. 2). I can now see that when I disabled DHCP, the correct MAC address was used, and when DHCP was re-enabled that day, and since, the incorrect one was used. So, one could guess that the bridging code is generating its own clone MAC address? And it seems that what is displayed via web or SB2's display is either the correct NVRAM value or an in-core MAC value for the hardware vs. any cloned or proxied MAC address. I'm guessing that you don't have cloned MAC addresses for an interface. Resetting the device disabled bridging, and once again, the correct MAC address (as printed on the bottom of the SB2) is being used. I'm almost postitive there's a bug still somewhere in the firmware that's causing the MAC address to be incorrect sometimes under these circumstances.
Don't know about the bridging, but here is a similiar scenario that happened yesterday (10-17).. I have a SqueezeBox2 wireless connected via wire to netgear switch. Using the 10-15 nightie. Was playing fine on the 16th and 17th using both slimserver playlists, and squeezenetwork with no slimserver running. My switch is a Netgear Ds106, and DHCP is supplied by a Speedtouch 530 ADSL Modem. I was Listening to a playlist when SB abruptly stopped playing. Slimserver web interface said squeezbox was playing, but SB display was blank. Pressed power button, and SB said could not connect. Went through setup, and it got a DHCP assigned IP. Still could not find the slimserver. Tried to ping the IP address from the slimserver machine, and the ping failed. Tried to use the SB to connect to squeezenetwork, and that failed. Unplugged the power cable of the SB and replugged. Went through setup, and still could not connect to slimserver or squeezenetwork, and all pings to the SB failed. I unplugged the NIC cable and replugged the NIC cable, and the SB immediately connected to the slimserver and started playing from where it had left off. I have seen this behavior in VIA motherboards with too little power to the board. The NIC part just locks up, but I have a voltage regulating UPS, and after reading this bug (2221), it sounds like the switch had an arp entry for a certain MAC address assigned to the port in the switch, that the MAC address of the SB changed, and the switch simply dropped all packets to and from the port. Then, perhaps the unplug of the NIC cable forced a new arp entry.
Mike: can you please update to the latest 6.2b2 with its new firmware (v25) and let me know if this bug is still happening? Thanks, dean
I don't see the fix working. I still see the bogus MAC address: 17:23:50 dhcpd: DHCPREQUEST for ... 20:05:73:00:00:0c via eth0 I'm using svn4705 and firmware 25.
I've encountered the same problem with a brand new Squeezebox 3, with firmware version 28. If Ethernet/WiFi bridging is disabled, the unit works normally. With bridging turned on, the unit places an incorrect MAC address into its DHCP request packets; the incorrect addresses are similar to the ones you report. Although the correct MAC address is in the Ethernet link-level source field, the DHCP server addresses its response at link level to the incorrect MAC address in the request, so the Squeezebox never sees the response. The Squeezebox blindly retransmits the request, with the server answering each one, until it times out and defaults to a self-assigned address in the 169.254/16 range. Also, if bridging is enabled and the host connected to the Ethernet port attempts to send a DHCP request, the Squeezebox overwrites the Ethernet source address field with its own address, and the Ethernet host is unable to get a response. This is incorrect behavior for a bridge; bridged frames should be repeated without modification.
I also still see the symptoms using v28 on a Squeezebox2. There also seems to way to disable bridging without setting factory defaults if there's nothing connected to the Ethernet interface. The MAC address of anything connected to the Ethernet interface seems to be modified in transit by the Squeezebox. Again, always 20:05:... MAC addresses.
Can you describe your network setups in more detail? Is the DHCP server on the wireless or wired side of the bridge? Also, Phil, note that 802.11 wireless bridging operates under the limitation that wireless clients can only appear with a single MAC address on the wireless network, requiring the bridge to rewrite the MAC address to its own and perform a kind of NAT.
Dean, who were are you asking to describe network setups in more detail? All posters of this bug? In that case, my DHCP server is on the wireless side of the SB3, at my FireWall (a SmoothWall system by the way): +DMZ---PublicServers / WAN----FireWall +wireless---SB3---wired \ / +LAN---AP \ +wired---VariousSystems
Sorry, mostly from Mike and Phil. Also, confirm that the DHCP requests are broken for both the squeezebox and any devices it's bridging on the far, wired, side. Finally, what DHCP server are you using and where is it on your diagram? I'm having trouble reproducing this issue here.
I'll look in detail at what's happening at the packet level with firmware 29 today sometime and report back. I can confirm that in firmware <= v28 it was the SB that was sending out DHCP packets with the 20:x MAC addr. I'll check the bridged side today as well. As for the DHCP server, it runs on my SmoothWall firewall (FireWall in my diagram). Its ISC's DHCP server, v3.02.
Aha, don't bother. I was able to reproduce and fix. Look for it in firmware 30. (If you'd like a patched copy of 29 to test against, send me email directly: dean@slimdevices.com)
You can either email me a patch 29, or i'll wait for 30 - your call.
Your patched copied resolved the issue. See the email I sent you offline.
Subject: Re: MAC address bug w/DHCP when bridging enabled Slim Devices Bugzilla wrote: > Can you describe your network setups in more detail? I see you already put out a patch, but for completeness I'll describe my setup. The DHCP server, Slimserver and just about everything else are on the far side of the wireless link as seen from the Squeezebox. I had only plugged a laptop into the Squeezebox's Ethernet port to test the bridge function when I encountered the problem. > Also, Phil, note that 802.11 wireless bridging operates under the limitation > that wireless clients can only appear with a single MAC address on the wireless > network, requiring the bridge to rewrite the MAC address to its own and perform > a kind of NAT. I don't think that's right. 802.11 frames can carry up to four MAC addresses precisely to support wireless Ethernet bridging. You have the MAC addresses of the ultimate source and destination plus the MAC addresses of the two wireless transceivers bridging the frame. When the bridged frame is relayed back onto a wired Ethernet segment, the two transceiver MAC addresses are removed leaving an "ordinary" Ethernet frame with the addresses of the ultimate source and destination nodes. --Phil
This should be addressed in Firmware 33 in the latest nightly releases. Please give it a shot and reopen the bug if it's still an issue.