In the forums bpa suggests not giving the choice of self-assigned IP address during setup.  I agree, as the first thing that will happen is that the firmware update will fail unless the unlikely network configuration exists where the user's router NATs 169.254 IP addresses to the outside world.

Second, it appears selecting self-assigned IP address becomes a permanent network setting.  On rebooting the Fab4 it won't try to get a DHCP address.  This is much different than previous Squeezebox behavior of automatically self-assigning an address on DHCP failure, but still attempting DHCP on subsequent startups.

*** Bug 11770 has been marked as a duplicate of this bug. ***

AutoIP is a failure mode for DHCP timeouts that lets the device stay on the network even though DHCP failed.  If DHCP succeeds later, then the AutoIP address goes away.  So, there's no specific AutoIP setting, it should just be DHCP or static.

Finally, for the first setup experience that requires an internet connection to download firmware, then AutoIP is useless, since it's is by definition, not routable to the internet.  

If there is a way to get a firmware update from a local SC, then there's a case where it would work, but it's very unlikely.

I just ran a test for bug 11668 (DHCP failure menu, fails to appear in setup) and found that the "Try again" ("Detect DHCP automatically") menu selection _does_ work when the connection is wireless.  So this bug only appears when the connection type is ethernet.

(In reply to comment #3)
> AutoIP is a failure mode for DHCP timeouts that lets the device stay on the
> network even though DHCP failed.  If DHCP succeeds later, then the AutoIP
> address goes away.  So, there's no specific AutoIP setting, it should just be
> DHCP or static.

I think my earlier report was wrong.  The DHCP server must not have been running when I rebooted after selecting self-assigned address.  Another test:

- disable DHCP server
- factory reset SBT
- select self-assigned address (AutoIP) when DHCP fails
- there's no way to get past the firmware update
- enable DHCP server
- reboot SBT

On rebooting, the SBT did get an IP address, so it was using DHCP again.

> - disable DHCP server
> - factory reset SBT
> - select self-assigned address (AutoIP) when DHCP fails
> - there's no way to get past the firmware update
> - enable DHCP server
> - reboot SBT
> 
> On rebooting, the SBT did get an IP address, so it was using DHCP again.

FOr me rebooting was not necessary, worked directly  after reenabling DHCP.
And the problem happens in wireless as well.

  Rudolf

Adding QA to the cc list.

I'm able to confirm the Detect DHCP automatically selection does nothing. This prompt only shows up on a network with DHCP server disabled. I selected self assigned and it cannot reach mysqueezebox.com. Enabled DHCP, rebooted fab4, ifconfig shows self assigned IP address still. WRT310N by Linksys.

Created attachment 5113 [details]
Proposed patch for SetupNetworking.lua

Confirmed on r5265 / wired that 'Detect DHCP automatically' does nothing due to a call from SetupNetworking.lua to t_wpaStatus() in Networking.lua which should be in a task.

I agree that the first option probably should be named differently as the system already tried (and failed) to detect the dhcp server automatically.

I suggest the whatever we chose it should at least contain the word 'again', either 'Try again' or 'Detect DHCP server again'.

"Try again" sounds great.

I am not sure about the patch, as it will display the popup even when the ethernet error is displayed. From looking at the coded, it would appear that _connect() is usually not called in a Task(), so should this not normally always fail?

I think you are correct, '_connect()' only sometimes is called in a Task() and as long as it is for the wireless interface the offending part of the code is not used and doesn't cause an error.

However of the three occasions _connect() is called for the wired interface two calls use a Task() ('networkScan' and 'ethernetConnect') only the one the bug is about doesn't.

I don't understand your remark: "it will display the popup even when the
ethernet error is displayed" - when would that happen?

The Task() is executed later, asynchronously. The code as written is designed to exit early in the return if there is not status link:

	local status = iface:t_wpaStatus()
	if not status.link then
		return _attachEthernet(self, iface, ssid, createNetwork)
	end
        -- more stuff

As this code now gets executed in a task, the "more stuff" is always run, even when the attachEthernet screen is shown. Either the whole function should be moved into the task, of the task calls _connect1() to do "more stuff" after the link status is checked.

What I don't understand is why this does not fail if you do:
1. factory reset
2. choose ethernet

Should the error not happen then too? It does not, as I see the attach ethernet screen.

Created attachment 5125 [details]
Another patch

If you do a factory reset and choose ethernet (w/o cable attached) _connect() is called in a task "networkScan". That is at least what I can see when I debug.

That looks better. Thanks.

Fixed in r5308.

I'm ready to verify this, when can I expect to see r5308 available on eng?

This looks solid. Without reboot Fab4 gets an IP from DHCP after it has been enabled. WRT310N, r5312.