Bugzilla – Bug 2997
DHCP/Auto-IP is very unfriendly
Last modified: 2009-09-08 09:29:30 UTC
I agree - can we please: - Not ask if they want DHCP and just try it anyway - Never assign a link-local address unless we can find a slimserver on it You know I've never liked auto-IP, especially our UI for it... it's doing us a LOT more harm than good, essentially telling the user we've obtained an IP when we haven't. > Incidentally, while we are on the subject, let me log another complaint: > the "Automatically acquire IP from DHCP" mode is UTTERLY useless. If the > DHCP does not respond within - what? - 10 seconds, the wretched SB2 assigns > an IP address outside the WLAN's subnet and you've had it. There is no > recovery from this nonsense other than pulling the plug. Pathetic.
The base problem is in 2730, where we start DHCP too early, before the WLAN is authenticated, so DHCP appears to fail. This will address 90% of the problems. (Per the complaint that you need to pull the plug below, it actually does continue to keep trying and the player gets an updated IP address when it succeeds, but after the user has been presented with the 169 address.) Need to adjust the UI to have the user confirm that they want an auto IP address to catch the other 10%.
I don't think that's a complete fix. The logic I'm suggesting is: 1) Try DHCP without prompting, and if an address is obtained, go to choose server menu 2) If DHCP fails, automatically try auto-IP but ONLY proceed to choose servever **if a slimserver is found.** 3) If Auto-IP ultimately fails, report "can't find an IP address" or something to that effect, and offer the user two choices: "try again" or "use static IP". (Or they can press left to go back to wireless setup).
richard's fixed the most serious problem where many wireless networks were not working. he's also addressed the ui issue and requires a confirmation from the user to self assign. i'm leaving this bug open, though for two reasons: 1. if the user goes left after being presented with the choice of getting an autoip address, plugs in the dhcp server and tries again it immediately fails. the DHCP server should reset and start the countdown again. 2. if the user does choose to get an autoip address, the player doesn't follow the spec and arp for an address for a few seconds to make sure that there isn't a collision. nearly there, richard
I'm not sure I understand the - Not ask if they want DHCP and just try it anyway suggestion. How can you _not_ give someone the choice of assigning a static IP address to the device, regardless of whether or not a DHCP server is operating on the LAN? I can understand the viewpoint that most people will want to use DHCP for the SB, and that this is the most dummy-proof "plug and go" type of setup, but the choice needs to be there regardless.
This is fixed in firmware 50. It is now in test and will be released soon.
This seems largely fixed by Richard's wireless networking revamp culminating in fw48, which absolutely fixed the problem where DHCP was attempted before wireless networking was up and running. Following that, the user is asked if they want to assign an IP or get one via DHCP. If DHCP fails, the user is then asked if they want to auto-assign an IP address (which will be in the 169.254.xxx.xxx range). Note this behavior does not match some of the comments in the early history of this bug. I am happy with the solution as implemented, so I'm willing to mark it verified (and closed, when it's released). If anyone subscribed thinks otherwise, they can re-open the bug.
I forgot to add, the behavior I note above was verified in FW50.
This bug fix is now part of a released version, and so has been marked closed. If you are still experiencing this problem, please reopen the bug.