Squeezebox Touch in Endless "Verify Ethernet Connection" Loop After Factory Reset

[SqueezedUser]

Hello Michael

I have enclosed 2 versions of the /var/log/messages with the SD-Card removed,

• the first: after power on and before choosing the language
• the second: after having chosen the language and after some time it remains endlessly saying "Verify Ethernet Connection"

You will also find the dmesg-output in the 3rd attachment.

Regarding the Wlan-connection, the only way to try it out is via command-line (it is the only communication I have to this device; no Home-Screen just the ever-running hourglass...) but I didn't find any wlanX-device to "ifconfig up" and to "iwlist" and configure it thereafter... Surprisingly, I haven't seen anything except the ieee802.11 stack in the dmesg-output. Did I miss something? So for the moment, I'm stuck to the wire.

P.S. I never used the Wlan with this SBT.


Kind regards
Pierre

> Many thanks for your instructions. Formerly, I just transferred the
> messages logfile with the SD-card (did a clean shutdown before removal).
> Now I could set up the SSH connection with your instructions below (BTW.
> you have to add the parameters "-o
> KexAlgorithms=+diffie-hellman-group1-sha1 -c aes256-cbc" in either the
> ssh- or scp- command lines on Linux) and it gets more comfortable...

Ah, right. I've got that in my ~/.ssh/config file... always forget about it.

> |Filename: messages-20200526-1910.txt

I compared this to a fresh file from one of my own Touchs. The biggest
difference indeed is what you posted before, some failure around
"halfDuplexBugVerification" - whatever that is...

But as this is related to Ethernet, could you please try to use wlan
instead? And I'd recomment you remove the SD card and only insert it
when you want to transfer something. It's firing up slimserver, which
slows down things a lot, and introduces more noise to the log file.

--

Michael

[Paul Webster]

Some bits from the files

dmesg (looks OK to me - but would need comparison with another ethernet connected Touch to see if more usually comes out)

eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
eth0: status: link down.
eth0: status: link up, 100MBit Full Duplex, auto-negotiation complete.

From pre-lang

Jan  1 01:01:27 kernel: eth0: status: link up, 100MBit Full Duplex, auto-negotiation complete.

Link comes up - time not yet set from internet.

8 seconds later - IP address assigned

Jan  1 01:01:35 udhcpc[723]: Lease of 192.168.1.112 obtained, lease time 86400
Jan  1 01:01:35 root: udhcpc_action eth0 bound ip=192.168.1.112

About 1 minute later ... very fast retries ... perhaps implying networking hard error (not a timeout) and still no time

Jan  1 01:02:39 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {mysqueezebox.com_Request}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))
Jan  1 01:02:40 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {fab4.squeezenetwork.com}(R))

and then the HalfDuplex check ...

Jan  1 01:07:17 squeezeplay: ERROR  squeezeplay.task - Task.lua:75 task error halfDuplexBugVerification: ...ve/applets/SetupNetworking/SetupNetworkingApplet.lua:378: attempt to index local 'iface' (a nil value)
Jan  1 01:07:17 squeezeplay: stack traceback:
Jan  1 01:07:17 squeezeplay: 	/usr/share/jive/jive/ui/Task.lua:75: in function 'resume'
Jan  1 01:07:17 squeezeplay: 	/usr/share/jive/jive/ui/Framework.lua:317: in function 'eventLoop'
Jan  1 01:07:17 squeezeplay: 	/usr/share/jive/jive/JiveMain.lua:422: in function </usr/share/jive/jive/JiveMain.lua:264>
Jan  1 01:07:17 squeezeplay: 	(tail call): ?
Jan  1 01:07:17 squeezeplay: 	/usr/share/jive/jive/JiveMain.lua:638: in main chunk
Jan  1 01:07:17 squeezeplay: 	[C 0x615b9]: ?
Jan  1 01:07:17 squeezeplay: 	[C 0x29fec]: ?

Suggestion - Perhaps there is a low level ethernetworking interoperability problem that you can avoid by plugging in somewhere else.
if you have another networked ethernet hub/switch then try plugging it into that one instead ... e.g. a spare port on your ISP router.

Once you get past the language selection part then ... maybe things will start working when you replug it back in the place where you want it (or you can enable wifi).
Other thing to work out is what it does once the language is set ... and do that by hand. Presumably it is writing to a config file to say which language has been chosen.

[mherger]

Squeezebox Touch in Endless "VerifyEthernet Connection" Loop After Factory Reset

> Jan 1 01:07:17 squeezeplay: ERROR squeezeplay.task - Task.lua:75 task error halfDuplexBugVerification: ...ve/applets/SetupNetworking/SetupNetworkingApplet.lua:378: attempt to index local 'iface' (a nil value)

This part sounds like a bug in Squeezeplay. Or at least unwanted
behaviour due to some unexpteced data.

> Suggestion - Perhaps there is a low level ethernetworking
> interoperability problem that you can avoid by plugging in somewhere
> else.
> if you have another networked ethernet hub/switch then try plugging it
> into that one instead ... e.g. a spare port on your ISP router.

Good idea!

> Once you get past the language selection part then ... maybe things will

I think the device hanging is not due to the language selection, but
above failure. I tried to figure out what triggers the setup route,
rather than just going to the main menu. Haven't found it yet. But I'm
pretty sure it should be feasible to set some flag in some config file
to get there.

> start working when you replug it back in the place where you want it (or
> you can enable wifi).

Wouldn't you be able to use Wifi if you did another factory reset?


--

Michael

[SqueezedUser]

On this SBT, trying to start the connection on the command line (no home screen!) just gives:

# ifconfig wlan0 up
ifconfig: SIOCGIFFLAGS: No such device

On my other SBT, this command works perfectly well however...

=> Is there really no way to restore an older firmware via the ssh-connection? The problem appeared after a simple factory reset.


Kind regards
Pierre

> Jan 1 01:07:17 squeezeplay: ERROR squeezeplay.task - Task.lua:75 task error halfDuplexBugVerification: ...ve/applets/SetupNetworking/SetupNetworkingApplet.lua:378: attempt to index local 'iface' (a nil value)

This part sounds like a bug in Squeezeplay. Or at least unwanted
behaviour due to some unexpteced data.

> Suggestion - Perhaps there is a low level ethernetworking
> interoperability problem that you can avoid by plugging in somewhere
> else.
> if you have another networked ethernet hub/switch then try plugging it
> into that one instead ... e.g. a spare port on your ISP router.

Good idea!

Sorry, but I tried this also several times... Maybe take it to someone else's ISP?

> Once you get past the language selection part then ... maybe things will

I think the device hanging is not due to the language selection, but
above failure. I tried to figure out what triggers the setup route,
rather than just going to the main menu. Haven't found it yet. But I'm
pretty sure it should be feasible to set some flag in some config file
to get there.

> start working when you replug it back in the place where you want it (or
> you can enable wifi).

Wouldn't you be able to use Wifi if you did another factory reset?

This does not work unfortunately:
# ifconfig wlan0 up
ifconfig: SIOCGIFFLAGS: No such device
On my other SBT, this command works perfectly well however...




--

Michael

[mherger]

Squeezebox Touch in Endless "VerifyEthernet Connection" Loop After Factory Reset

> On this SBT, trying to start the connection on the command line (no home
> screen!) just gives:

Can't you do another factory reset with the ethernet cable unplugged,
then try to configure it as WLAN?

> => Is there really no way to restore an older firmware via the
> ssh-connection? The problem appeared after a simple factory reset.

The firmware you're using is what probably 90% of all Touch units out
there use. I doubt downgrading will help. And no, I still don't know how
to do it manually. Did you check wiki.slimdevices.com?

--

Michael

[SqueezedUser]

Hello Michael,

Following http://wiki.slimdevices.com/index.ph...zeOSNetworking, I tried the following:

1. Remove Ethernet cable
2. Perform Factory Reset (via fab4 button)
3. Upon Language Screen appearing, choose English => beep => nothing else happens (Language Screen remains)
4. Connect USB-Keyboard; type CTL-ALT-F3
5. Login as root, pwd 1234

Then, typing command: "ifconfig wlan0 up" (which works fine on my other SBT) and which just gives:
# ifconfig wlan0 up
ifconfig: SIOCGIFFLAGS: No such device

OK, trying to set it in the Autostart script according to the wiki chapter " Autostart wireless"

Autostart wireless

1. Remove auto eth0 in /etc/network/interfaces : Done
2. Add auto wlan0=<SSID> in /etc/network/interfaces ('ifup -a' in '/etc/init.d/rcS' will start it): Done
3. Only remove disabled=1 from the one wireless setting to start in /etc/wpa_supplicant.conf: No wireless setting yet in that file

Then, typing ifconfig => only interface lo is up...
manually firing up ifconfig wlan0 up => error message above
manually firing up eth0 => no error; etho appears after typing ifconfig

Should I try to startup the wlan0 interface with "ifup" instead of "ifconfig ... up"? What is the full command-line syntax in this case?


If I only could get the SBT home-screen back...

Many thanks for your support

Kind regards
Pierre

> On this SBT, trying to start the connection on the command line (no home
> screen!) just gives:

Can't you do another factory reset with the ethernet cable unplugged,
then try to configure it as WLAN?

> => Is there really no way to restore an older firmware via the
> ssh-connection? The problem appeared after a simple factory reset.

The firmware you're using is what probably 90% of all Touch units out
there use. I doubt downgrading will help. And no, I still don't know how
to do it manually. Did you check wiki.slimdevices.com?

--

Michael

[Paul Webster]

Sounds like a broken or unseated WiFi card ... I did not spot anything in your earlier dmesg dump referring to it - although it would be good to see a dmesg log from a Touch that has one working.

[SqueezedUser]

Hello Paul

Perhaps. Please find both dmesg files in attachment. Is there any other means of getting further HW-status information - there is only one and the same module loaded in both SBTs: "sd8686", nothing about wlan-specific HW?

Kind regards
Pierre

Sounds like a broken or unseated WiFi card ... I did not spot anything in your earlier dmesg dump referring to it - although it would be good to see a dmesg log from a Touch that has one working.

[SqueezedUser]

*** solved ***

Hello,

Just SOLVED the SBT endless "Verify Ethernet connection" looping screen appearing after having reset a wired SBT (FW 7.8.0 r16754) the following way:

• copy the file http://update.slimdevices.com/update...7.3_r16676.bin to a FAT-formatted (old) SD-Card
• rename that file to fab4.bin
• insert the SD card in the "looping" SBT, which reacts with a menu (with FW-Upgrade among other items !)
• select firmware upgrade to FW 7.7.3 r16676 OK

Thereafter it reloads the old firmware, then the SBT reboots normally, asking for the mysqueezebox account parameters...

Meaning that the SBT is back, running (although with a quite older release).

Hoping this workaround may help.


Kind regards
Pierre

Hello Paul

Perhaps. Please find both dmesg files in attachment. Is there any other means of getting further HW-status information - there is only one and the same module loaded in both SBTs: "sd8686", nothing about wlan-specific HW?

Kind regards
Pierre

[mherger]

Squeezebox Touch in Endless &quot;VerifyEthernet Connection&quot; Loop After Factory Reset

> Meaning that the SBT is back, running (although with an quite older
> release).

Wow... that's quite a finding. Which means that the latest firmware
would not be able to set up a device from scratch?

What would be interesting now is what happens if you update to the
latest firmware. Would it continue to work?...

--

Michael

[SqueezedUser]

Follow-Up / Conclusions

Hello Michael

Great, isn't it. I finally had to upgrade to FW version 7.8.0 r16754 after connecting it to my LMS-Server (the latter left no choice). So now, it is running again and both SBTs have the very same release.

Furthermore, I did some comparative tests between the 2 SBTs in the meantime and can now be a lot more precise now on

• the "where" and
• the "why"

the endless loop may happen. Here are the bare facts:

On the problematic SBT we have:

1. all Wlan signal information fields are blank in the menu "Settings/Advanced/Diagnostic/Wireless"
2. trying to manually firing up Wlan on the terminal gives an error (i.e., # ifconfig wlan0 up => ifconfig: SIOCGIFFLAGS: No such device)
3. selecting the menu "Settings/Advanced/Networking/Choose Network" RESTARTS the endless loop "Verify Ethernet Connection"

This last fact comes precisely to the point.

On the "untouched" SBT we have:

1. all Wlan signal information fields do have a value in the menu "Settings/Advanced/Diagnostic/Wireless"
2. manually firing up Wlan on the terminal just works fine
3. selecting the menu "Settings/Advanced/Networking/Choose Network" gives FIRST "Verify Ethernet Connection", AND THEN "Searching Networks" which then lists plenty of neighbor Wlan SSIDs to choose from...

Conclusions:

• Where in the code? The last observation shows the problem appearing after the Ethernet checking (which is fine but this is not advertised as such and not exited on) immediately followed by a Wlan check (which seems to be defective here and this hangs that SBT).
• Why may it happen? Most probably the initial setup after a factory reset directly jumps to that code section (very same Message and sequence?), hanging my SBT.

Hope this could help for a code modification where some exit feature to the home screen, either immediately after the first running network interface is found or just on some manual event would be implemented.

Many thanks for your support

P.S. Any hint to check the Wlan circuitry? There seems to be no add-on module in the SBT (IC/antenna directly soldered to the main board?)

Kind regards
Pierre

> Meaning that the SBT is back, running (although with an quite older
> release).

Wow... that's quite a finding. Which means that the latest firmware
would not be able to set up a device from scratch?

What would be interesting now is what happens if you update to the
latest firmware. Would it continue to work?...

--

Michael

[mrw]

https://github.com/Logitech/squeezep...public/7.8/src

^ that's where you'd find the code. But... where in there?

There were seven changes that impacted networking set up. I have not been following the thread, so I don't know which might be a likely candidate. Here's a list of the changes, should someone wish to review. The last one looks intriguing, it seems that it might disable ethernet unless connectivity to mySB.com can also be established.


Description: Network setup changes - Wait at least 2 seconds while scanning the network to allow the user to read the screen

https://github.com/Logitech/squeezeplay/commit/438fde489a0627e4ecd329b8293c11ac158777c0

Description: Setup changes - Remove welcome screen - This also removes the hidden demo start which is now in the language selection step

https://github.com/Logitech/squeezeplay/commit/9d773b4b3593a473f93d9e0ccdeb76bd6084bc7d

Description: Setup changes - Remove welcome screen - This also removes the hidden demo start which is now in the language selection step

https://github.com/Logitech/squeezeplay/commit/30c3c8479b42b07248a05a012153020427a7c044

Description: Setup changes - Add hidden demo start to language selection step

https://github.com/Logitech/squeezeplay/commit/4da56ffe9c687b5eba6f0c15b73c8f001af5db38

Sort SSIDs by signal strength Sort the SSID list by signal strength

https://github.com/Logitech/squeezeplay/commit/00de3e1e09e17734344f6b4b7009aa7db4d031b5

Test connectivity to mySB.com upon detection of Ethernet - In addtion to check for an Ethernet link also ping mySB.com and only if mySB.com is available use Ethernet.

https://github.com/Logitech/squeezeplay/commit/7dc2ba0c2989869dcf58c2b15a22f9d5f0649559

[ralphy]

There were seven changes that impacted networking set up. I have not been following the thread, so I don't know which might be a likely candidate. Here's a list of the changes, should someone wish to review. The last one looks intriguing, it seems that it might disable ethernet unless connectivity to mySB.com can also be established.

Test connectivity to mySB.com upon detection of Ethernet - In addtion to check for an Ethernet link also ping mySB.com and only if mySB.com is available use Ethernet.
https://github.com/Logitech/squeezep...22f9d5f0649559

Running the community radio firmware with qemu yields the same endless loop verifying the ethernet connection issue.

Reverting commit 7dc2ba0c2989869dcf58c2b15a22f9d5f0649559 allows you to complete the setup and access the menus, settings, etc.

Granted it's not comparing the issue on the same hardware but does seem to indicate that the above change has the potential to cause issues should mysb.com eventually be retired.

[GB_Joe]

On the problematic SBT we have:

1. all Wlan signal information fields are blank in the menu "Settings/Advanced/Diagnostic/Wireless"
2. trying to manually firing up Wlan on the terminal gives an error (i.e., # ifconfig wlan0 up => ifconfig: SIOCGIFFLAGS: No such device)
3. selecting the menu "Settings/Advanced/Networking/Choose Network" RESTARTS the endless loop "Verify Ethernet Connection"

Firstly, thanks to all who've contributed to this thread, because I've had exactly the same issues and would not have had the patience to do all this stuff!

Unfortunately my SBT does not really have the option of plugging in to my network with a wire for anything other than diagnostics. I'm thinking from what I've read here that if I have these symptoms then the wifi really is dead? Are there any simple ethernet-to-wifi gizmos which might give it a new lease of life, or should I pass it on to someone who's able to plug it in? I don't want to waste time and money on something that's unlikely to work, so any advice would be really appreciated.

[mrw]

Are there any simple ethernet-to-wifi gizmos which might give it a new lease of life

Search the forum for "Vonets". There have been a number of posts describing one or more such gizmos under this brand that have apparently been successfully used.