Created attachment 1 [details]
log of DHCP network traffic during failure

Is this still an issue?

Yes, confirmed it still exists with fw 18 on SB2 also.

Is this still an issue with the latest firmware releases?

Richard checked in some DHCP fixes recently.

Thanks

Can you please test this with the latest firmware to see if this is still an issue. Thanks.

My mac test platform has been borrowed for Transporter FCC testing, but I'll look at it soon.

Bug 15!

Ross, since my test mac is still borrowed, could you give this one a try?  I don't know anything about Mac internet sharing, so there may be some research involved?

I'm going to need a nudge. I've looked through various settings in system preferences, I've searched google and still can't seem to figure out where OS X network sharing is. Is it called something else now? Is this something I need to download? 

Subject: Re:  dhcp fails with Mac OS X network sharing DHCP server

Try the Sharing system preference pane, click on the Internet tab,  
under OSX 10.4...

Verified to still be a bug in 6.5b3 on OS X 10.4. 

Thanks Dean!

Well, Ross, when you get in, come on over and I'll give you a crash course in using this Ethereal machine to make a capture of the DHCP traffic for Richard to look at.

Created attachment 1538 [details]
Sorry, ignore this attachment.

Created attachment 1539 [details]
ethereal capture while trying to connect SB2 via airport on iMac WITH network sharing enabled

Sorry about the confusion. I created the first ethereal capture without enabling Network Sharing :/ Sorry! 

Thank you Chris for the crash course!

Ross thanks for the trace. Can you let me know the WEP key, or if you were using WPA could you capture a trace with no encryption. I can't see the DHCP traffic :)

There is no encryption. 

MAC address of the adapter on the Mac is 00:11:24:a6:b2:b2, MAC address of the SB2 is 00:04:20:05:CA:C7. 

Does this clear up the confusion? Let me know if I did something wrong, I'm very new to the ethereal world. 

alas, not going to make it in the 6.5 release.

Ross thanks - not sure why I thought the attachment was with encryption. It looks fine tonight :). It would be great to have another trace with a pc (or similar) connecting successfully to compare. Thanks.

Ross, could you set up that Dell for dual boot windows/linux so we could use it for both sniffy and wispy?  Neither should be a hard drive hog, so I think the hard drive should be okay.  What do you think?

Ubuntu and XP are now running on sniffy jr. The Atheros minipci adapter is on it's way; I'll update this bug once I have it completely up and running. What do we need for this bug?

Let's get 

1) a capture of a Squeezebox failing to connect and 
2) another PC connecting successfully

and we'll have a look and see if there's anything in there of interest.

Created attachment 2403 [details]
4 sniffy captures

2 captures showing an ibook connecting successfully and 2 captures showing a transporter failing to reach DHCP

added felix so he can see if there's anything in Ross's new captures that can help get this fixed.

I came across this article on Mac OS X hints:
http://www.macosxhints.com/article.php?story=20071223001432304

It mentions using NetInfo Manager to change the reply_threshold_seconds value from the default value of 4 to 0.  I just tried this change and now all our products are now able to get DHCP from my Macintosh!  I have no idea what the ramifications are for changing this value but it works like a charm.

Hopefully this discovery will lead to a solution of our own.

This is great news, well done. I guess, we are just not waiting long enough for an answer from DHCP.

Aha... more details from another post at http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/679001968831:

Looks like we need to tweak the "secs" field in the DHCP request to be >4.

Felix, can you give this a quick shot?

------------------------------------------------------

Essentially, 


Title: Internet Sharing incompatible with e.g. Xbox 360, due to DHCP reply threshold

Summary: 

/usr/libexec/InternetSharing sets bootpd's reply_threshold_seconds to a nonzero value. (Much more detail on this in the Notes section.) This effectively means that some devices, most prominently the Microsoft Xbox 360, will never obtain an IP address from an OS X machine that is acting as a DHCP server using Internet Sharing. Setting reply_threshold_seconds to 0 solves the problem (but is overridden whenever Internet Sharing is on).


Steps to Reproduce:

1) Enable Internet Sharing in System Preferences. For example, share a connection from AirPort to computers using Ethernet.
2) Connect an Xbox 360 using Ethernet and set it to obtain an IP address using DHCP.


Expected Results:

The Mac's DHCP server replies to the Xbox 360's DHCPDISCOVER messages, and the Xbox is able to obtain an IP address and connect to the Internet through the Mac.


Actual Results:

bootpd never replies to the Xbox.


Regression:

The problem is confirmed under 10.4.10 and 10.5.1. I have not had a chance to test under 10.4.11 but I assume it happens there as well.


Notes:

The core problem is that /usr/libexec/InternetSharing, which is the daemon that is launched whenever Internet Sharing is enabled and which then launches bootpd, is apparently hard-coded to set bootpd's reply_threshold_seconds value to 4. Under Leopard, this setting exists in /etc/bootpd.plist, while under Tiger it is found in the local NetInfo domain at /config/dhcp. It seems that /usr/libexec/InternetSharing writes to the plist (Leopard) or NetInfo (Tiger) immediately before launching bootpd, every time it launches bootpd, which makes it impossible for the user to override this behavior (e.g., by changing the value in the plist or NetInfo and then killing bootpd).

Setting reply_threshold_seconds to 4 means that bootpd will ignore DHCPDISCOVER messages whose "secs" field, as described in RFC 2131, Table 1, is less than 4. Unfortunately, some devices, including the Xbox 360 with the current firmware as of 11/18/2007, always set this field to 0 in their DHCPDISCOVER messages. (I have heard that this problem exists with the original Xbox too, as well as some other, less popular devices.) This appears to be allowed by the RFC (see p. 36), but it means that bootpd ignores all such devices and never gives them an IP address.

Since reply_threshold_seconds need not be set for bootpd to run, and it will use 0 if no value is set, I assume that this behavior is deliberate and that it exists to reduce the number of problems caused by users enabling Internet Sharing on LANs where there is already a DHCP server. Note, however, that the DHCP server that Windows XP SP2 runs when its Internet sharing is turned on doesn't exhibit the same behavior (it works with the Xbox 360).

My preference would be that the default setting be changed to 0, but if this is deemed undesirable then I would like there to be some kind of hidden, or not-so-hidden, setting to override it. I've looked everywhere I can think of and have finally been forced to conclude that no such setting currently exists and this value of 4 must be hard-coded. (The source of /usr/libexec/InternetSharing doesn't appear to be available to the public.) If it were instead configurable in /Library/Preferences/SystemConfiguration/com.apple.nat.plist, as some other advanced Internet Sharing settings already are, knowledgeable users like me could at least override it on their machines. Even better would be an "Advanced..." button in the Sharing pane of System Preferences that led to a dialog that allowed the user to, for example, check a box to eliminate the reply threshold (set it to 0).

I copied the bootpd.plist that Internet Sharing creates, disabled Internet Sharing, modified the plist to set the reply threshold to 0 and then ran bootpd manually. The Xbox 360 was then able to obtain an IP address from the Mac as desired. I have attached debugging output from bootpd in the before and after cases.

Holy crap, I just looked in the dhcp_client.c file and found that I put a patch in there that attempted to fix this a while back.

I guess it didn't work.  :(

Fixed in SB fw 88, TR fw 37, SBR fw 23

Verified Fixed with 7.0.1 r2409 / r23

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html