Bugzilla – Bug 5212
DHCP setup fails
Last modified: 2011-11-06 23:25:09 UTC
My new Squeezebox 3 (firmware 81) fails to get a DHCP address, although my DHCP server sends a response. Using a static IP works. The SB3 is connected over WLAN (11g, no encryption) to a Netgear WGR614v2, the DHCP server is the ISC 3.0.5 server running on Fedora Core 6, connected by cable to the Netgear box. The DHCP server works fine for e.g. the Wii console which sits next to it and also connects by wireless. The SB3 sends a DHCP Discover, gets back a DHCP Offer, but ignores it and sends another Discover message, etc. After five such exchanges the SB3 picks a 169 address and continues to send Discover messages, which get Offers back (which are still ignored). A typical exchange between the SB3 and the DHCP server: 15:18:00.297643 IP (tos 0x0, ttl 32, id 28, offset 0, flags [none], proto: UDP (17), length: 328) 0.0.0.0.68 > 255.255.2 55.255.67: BOOTP/DHCP, Request from 00:04:20:07:d9:a9, length: 300, xid:0xf9b6122f, flags: [Broadcast] (0x8000) Client Ethernet Address: 00:04:20:07:d9:a9 Vendor-rfc1048: DHCP:DISCOVER HN:"Vardagsrum" CID:[ether]00:04:20:07:d9:a9 VC:"Logitech" PR:SM+DG+NS 15:18:00.298355 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 10.0.1.17.67 > 255.255 .255.255.68: BOOTP/DHCP, Reply, length: 300, xid:0xf9b6122f, flags: [Broadcast] (0x8000) Your IP: 10.0.1.54 Client Ethernet Address: 00:04:20:07:d9:a9 sname "Zurg" Vendor-rfc1048: DHCP:OFFER SID:10.0.1.17 LT:43200 SM:255.255.255.0 DG:10.0.1.1 NS:10.0.1.17
Is this related to bug 3660?
It looks related, but a little different: I have not enabled bridging in the SB3, and I'm not using WEP/WPA. Some extra info for clarification, based on the discussion in bug 3660: The DHCP exchange was captured on the wired side of the Netgear box; my network setup is approximately Slimserver/DHCP --- Laptop (traffic capture) | | Netgear === SB3 where "-" are cables, "=" is wireless.
Felix would you be interested in looking at this bug? Is there something about this DHCP offer packet that Squeezebox considers ill-formed?
This sounds suspiciously like the problem Vista has with its DHCP requests, in that it sets the BROADCAST flag. A lot of DHCP server setups won't work with this, because they won't broadcast to 255.255.255.255. If possible, the solution is to not set the broadcast flag in dhcp requests, as it's not needed (unless the squeezebox's tcp/ip stack does require it). Some info about the vista problem is at: http://slashdot.org/article.pl?sid=07/09/02/1223209 I've had the same problem. It's tricky to debug, because it works the first time for a lease, so it appears to be an intermittent problem. I think there are some other bugs floating around in bugzilla which could be duplicates of this.
SB's tcp/ip stack unfortunately requires DHCPOFFER, DHCPACK and DHCPNAK messages to be received as broadcast messages as long as it has no IP address assigned. I've tried to change the code to request offers etc. as unicast, but that won't get routed correctly into DHCP code, because unicast offers get discarded. I found the following statements here: http://www.faqs.org/rfcs/rfc2131.html Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address). A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit [21]. So, it looks like if a client (like SB) cannot receive unicast offers it is ok to ask for broadcast offers by setting the broadcast flag, _but_ I guess there are DHCP servers out there that do not support sending broadcast offers, hence the incompatibility. :(
Unassigned bugs cannot have a priority.