WiFi connection unstable/lost on three Radios

[Tony T]

...the LEDs are very annoying...

Yes. Can’t tape over the case as it’s the vent...
....but, the case is press fit. Easy to pop open and place a small piece of electrical tape directly over the LED.

[frankd]

Thank's for digging into this. What happened after the failure, did you have to reboot? How long was the music interruption? On what service? We sometimes notice a couple of second interruptions here, but have experienced that for many years.

Edit: Why hard-code the gateway? The idea was to test the wifi by pinging the nearest device (i.e., the gateway) (e.g., in case the LMS server is down), and netstat is supposed to return that IP address correctly.

A user PMd me (last month) and noted that there were two (v 0.6.3) bugs on lines 515 & 584 when using -x (no TCPLOG). I replied:

A new version 0.6.4 (not finished) has these fixed in two places. You should fix yours (to 0.6.3.1), it might improve your results significantly if using -x. Actually, everyone should do this.

Before uploading a new version, I am wondering if I should add new command line switches to assign values to variables which would replace the three constants you mentioned: 'Seconds between Tests', 'Failure Limit', and 'Restart Wait Seconds', or something else. I would like your and others opinions before continuing. Keep in mind any change might add yet new bugs.

I am using the script with the two bug-fixes now. I hard-coded the gateway just to be sure to reduce the number of potential sources of failure, non-hardcoded is of course ways more elegant in future.
The good news: In most cases the two affected radios did restart the wifi without me requiring a reboot. Within one week I had to reboot one radio once - it was without network and rebooting was the only way to get it back again... Thus overall I have to intervene a lot less.

Since the radios are located furthest away from my office at home, the only way to monitor failures for me means synchronizing the entire apartment. My observations:
if the WIFI of one of the affected radios fails, the synchronization group is interrupted (maybe 5 second interruption , plays for 5 seconds, then is interrupted for another second). My interpretation: First interruption after a certain time of wifi failure, the group continues without the affected radio and gets interrupted again when the affected radio joins the affected group again (using Philippe's Sync-Group Plugin).

For me it seems as if the time from detecting the problem first to restarting the network takes a long time, causing these interruptions. One example with time stamps below. That was the reason why I wanted to use only 3 loops with 1 second delay each...

2021-02-26T16:48:36+0100 Schlafzimmer.65_063 192.168.192.1 ping failed eth1 AR6000 802.11g ESSID:"Franky2" Mode:Managed Frequency:2.472 GHz Access Point: 00:18:E74:214 Bit Rate=6 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retryn Encryption keyff Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:34 Invalid misc:0 Missed beacon:1
2021-02-26T16:48:37+0100 Schlafzimmer.65_063 Link Statistics
2021-02-26T16:48:21+0100: Bit Rate=36 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:29 Invalid misc:0 Missed beacon:1 time=5.444 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
2021-02-26T16:48:23+0100: Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=13.399 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
2021-02-26T16:48:25+0100: Bit Rate=48 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=29.844 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
2021-02-26T16:48:26+0100: Bit Rate=36 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:27/94 Signal level:-68 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=3.126 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
2021-02-26T16:48:28+0100: Bit Rate=48 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=13.090 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
2021-02-26T16:48:31+0100: Bit Rate=36 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:27/94 Signal level:-68 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=13.340 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
2021-02-26T16:48:33+0100: Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:27/94 Signal level:-68 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=15.156 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
2021-02-26T16:48:36+0100: Bit Rate=6 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:34 Invalid misc:0 Missed beacon:1 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
2021-02-26T16:49:13+0100 Schlafzimmer.65_063 failed 2021-02-26T16:48:36+0100 reset 2021-02-26T16:48:43+0100 up 2021-02-26T16:49:11+0100 eth1 AR6000 802.11g ESSID:"Franky2" Mode:Managed Frequency:2.472 GHz Access Point: 00:18:E74:214 Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retryn Encryption keyff Link Quality:28/94 Signal level:-67 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 PING 192.168.192.1 (192.168.192.1): 56 data bytes 64 bytes from 192.168.192.1: seq=0 ttl=64 time=45.989 ms --- 192.168.192.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 45.989/45.989/45.989 ms

[POMdev]

I am using the script with the two bug-fixes now. I hard-coded the gateway just to be sure to reduce the number of potential sources of failure, non-hardcoded is of course ways more elegant in future.
The good news: In most cases the two affected radios did restart the wifi without me requiring a reboot. Within one week I had to reboot one radio once - it was without network and rebooting was the only way to get it back again... Thus overall I have to intervene a lot less.

Since the radios are located furthest away from my office at home, the only way to monitor failures for me means synchronizing the entire apartment. My observations:
if the WIFI of one of the affected radios fails, the synchronization group is interrupted (maybe 5 second interruption , plays for 5 seconds, then is interrupted for another second). My interpretation: First interruption after a certain time of wifi failure, the group continues without the affected radio and gets interrupted again when the affected radio joins the affected group again (using Philippe's Sync-Group Plugin).

For me it seems as if the time from detecting the problem first to restarting the network takes a long time, causing these interruptions. One example with time stamps below. That was the reason why I wanted to use only 3 loops with 1 second delay each...

It looks like the automatic gateway detection does not have to be overridden, as it seems reliable.

Looking at your logs, what stands out to me is, first of all, the very low signal level ...Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:34.... I might have this backwards, but it might be that "Franky24" has a higher signal level than "Franky2". That said, I mistakenly ran a radio with similar levels and it continued to work, albeit with more frequent resets. Also, your "failed" to "reset" time is only 7 seconds vs 19 seconds here, but your "reset" to "up" time is 28 seconds vs 19 seconds here. Perhaps the long up time delay has something to do with low signal strength.

Since the music generally kept playing here, it seemed OK with the hard coded test frequency and failure delay values. Synchronization adds another level of complexity, and these values may not be optimum for that use case. I think your changes are entirely appropriate, others might consider doing the same.

The script was giving the radio network stack software, and any other possible future lower level mitigating solutions, every opportunity to do recover before "pulling the rug out" from the radio and restarting everything. Regrettably, the script does not track how many times the radio recovers from a few missed pings. We could add a statistic for number of failed pings and longest ping failure for later transmission to evaluate the time out constants. Modifying these values could lead to an improvement.

BTW, there are other ways to monitor failures than synchronization. The TCP logger ncat described in manual.txt seems the easiest, yielding a real time display and saved log of failures. I also use the excellent Nirsoft Wireless Network Watcher and NetworkConnectLog apps for an on-screen real time update (although brief interruptions may not be captured by the latter two).

Thanks for the report.

[vcrpro3]

Per the title bar, this problem always happens whenever I don't use my Squeezebox Radio or Boom. It even happens randomly even if I had used my Squeezebox devices in the past previous days. I have to try all sorts of computer 'acrobatics' to get connectivity with my wi-fi router. I'm at my wits end on this.

[vcrpro3]

Per the title bar, this problem always happens whenever I don't use my Squeezebox Radio or Boom. It even happens randomly even if I had used my Squeezebox devices in the past previous days. I have to try all sorts of computer 'acrobatics' to get connectivity with my wi-fi router. I'm at my wits end on this.

...and now I am getting the 'scanner.exe error. the only way i been able to fix this is by completely removing LMS and it registry entries and then re-installing it....a major pita...

[toby10]

Per the title bar, this problem always happens whenever I don't use my Squeezebox Radio or Boom. It even happens randomly even if I had used my Squeezebox devices in the past previous days. I have to try all sorts of computer 'acrobatics' to get connectivity with my wi-fi router. I'm at my wits end on this.

SB players or LMS host computer not connecting to WiFi?
Sure it is not connecting to WiFi or just not connecting to server (LMS or MySB.com)?

[toby10]

...and now I am getting the 'scanner.exe error. the only way i been able to fix this is by completely removing LMS and it registry entries and then re-installing it....a major pita...

What is listed in log immediately following scanner.exe error?

[frankd]

Yes. Can’t tape over the case as it’s the vent...
....but, the case is press fit. Easy to pop open and place a small piece of electrical tape directly over the LED.

I tried it with the Vonets VAP11G-300 and the VAP11N-300. For the G version it worked well, however you have to use multiple layers of tape. for the N version it was less successful as there is little space to cover with the tape and there is a lot of indirect scattering of light.
Amazing how much light these micro LEDs can emit...
For all who are interested, the instructions I noted for myself:

VAP11G-300 / VAP11G-500:
- Open the two parts using a scissor or screwdriver from the front-end (away from the cables)
- Put 4 Layers of Tape (Panzerband) onto the two diodes.
- Put the board into the half with the reset button, ensure that the cables fit
- press the board with a screw-driver versus the back (cables / reset button) while closing the case starting at the back

VAP11N-300
- not as effective as VAP11G-300
- Open the two parts using a scissor or screwdriver from the front-end (away from the cables)
- Put 4 Layers of Tape (Panzerband) onto the two diodes.
- Close the case starting from the back (cables)

[Tony T]

Worked from me on the “G” with only one small cut square of Scotch 3M Super 33+ Black Electric tape.