WiFi connection unstable/lost on three Radios

[P Nelson]

Here is my set-up at home, two Radios and a Touch. Red Radio (LMS reports 100% signal strength as it located on other side of the wall from the router) is connected to my primary Arris NVG468MQ. Black Radio (LMS reports 90-83% signal strength) and the Touch (LMS reports 100% signal strength which is 2 feet away from the router) are connected to a second access point using an older NetGear router. I do not have wifi problems with the Black Radio or the Touch. I have replaced the Arris provided by the internet provider, and the problem still occurs.

The Red Radio will drop the Wifi connection either in standby or while streaming music. Switching Red Radio to the secondary access point results in a LMS reported signal strength of 68-73%, but it drops the Wifi more frequently so the primary access point works better. If I take Red to my office the problem disappears. If I move Black to where Red is located the problem occurs on the Black radio.

I suspect the problem is due to my neighbor installing a wifi extender as the problem appeared about the time he installed the extender. We coordinated on Wifi channels, so we are not using the same or overlapping channels, but the problem still exists. Using a Wifi analyzer I also see a mesh network that is using a wide band (channels 2-10) that overlaps my primary router on channel 1, but the signal strength is less than -85 dBm.

When the red symbol appears, the Repair Network will not fix the connection and trying to select my secondary access point network will not work. I have to reboot to clear the problem.

Thus based upon my experience, even with a very high signal strength the problem will occur at least daily. If I move Red to other locations and the signal strength weakens then the problem occurs more frequently. I moved Red to my bedroom which is close to my neighbor and it would drop within an hour or so.

I hope this helps. If any other information would be helpful, please let me know. If you need logs, then I will need some education on how to do that.

Paul

[POMdev]

...If I take Red to my office the problem disappears. If I move Black to where Red is located the problem occurs on the Black radio....
...If you need logs, then I will need some education on how to do that.

It looks like you are in the same boat as the rest of us. High signal levels don't cure the problem, location is key, this just started happening last year, etc. The apparent cause is transmissions from one or more other wireless devices causing the radio to lose reception over and over again until it just stops. The radio should not have reception problems, nor stop, but it does.

AFAIK, as of this moment, there is no fix for the radio. However, the mitigation script keeps the music playing, and the radios usable. You can download the script (see link in earlier message) and try to install it. There are several steps. If you run into difficulties, post a query and I or someone can help you through this.

[mrw]

When the red symbol appears, the Repair Network will not fix the connection and trying to select my secondary access point network will not work. I have to reboot to clear the problem.

Is this particular element of the problem exclusive to the Radio running the Community firmware ?

I ask, because:

a) I believe that your Red Radio is (or was) running Community firmware, but perhaps your Black Radio is not.
b) I believe that I have located a problem within the Community firmware that could cause it to fail to reconnect in this circumstance. The stock firmware does not have the problem I have identified, so I would not expect it suffer this additional annoying impediment.

[P Nelson]

Is this particular element of the problem exclusive to the Radio running the Community firmware ?

I ask, because:

a) I believe that your Red Radio is (or was) running Community firmware, but perhaps your Black Radio is not.
b) I believe that I have located a problem within the Community firmware that could cause it to fail to reconnect in this circumstance. The stock firmware does not have the problem I have identified, so I would not expect it suffer this additional annoying impediment.

For my home set-up the Radios and Touch are running the Logitech firmware. I am confident the Radios are running the most current Logitech version, but I am at my office at the moment, so I cannot provide the exact version number.

I have a Radio at my office on the Community Firmware (8.0.1 R16835) release. I will bring it home tonight and test it at the same location to see if it behaves any differently when the red Wi-Fi icon appears.

Paul

[mrw]

When the red symbol appears, the Repair Network will not fix the connection and trying to select my secondary access point network will not work. I have to reboot to clear the problem.

Not exactly the order of events that you describe above, but might be contributory:

https://forums.slimdevices.com/showt...=1#post1011202

[frankd]

Is this particular element of the problem exclusive to the Radio running the Community firmware ?

I ask, because:

a) I believe that your Red Radio is (or was) running Community firmware, but perhaps your Black Radio is not.
b) I believe that I have located a problem within the Community firmware that could cause it to fail to reconnect in this circumstance. The stock firmware does not have the problem I have identified, so I would not expect it suffer this additional annoying impediment.

I tried both firmwares - The community firmware and the original firmware using the same radio at the same location and both have exactly the same problem.

[frankd]

Here is my set-up at home, two Radios and a Touch. Red Radio (LMS reports 100% signal strength as it located on other side of the wall from the router) is connected to my primary Arris NVG468MQ. Black Radio (LMS reports 90-83% signal strength) and the Touch (LMS reports 100% signal strength which is 2 feet away from the router) are connected to a second access point using an older NetGear router. I do not have wifi problems with the Black Radio or the Touch. I have replaced the Arris provided by the internet provider, and the problem still occurs.

The Red Radio will drop the Wifi connection either in standby or while streaming music. Switching Red Radio to the secondary access point results in a LMS reported signal strength of 68-73%, but it drops the Wifi more frequently so the primary access point works better. If I take Red to my office the problem disappears. If I move Black to where Red is located the problem occurs on the Black radio.

I suspect the problem is due to my neighbor installing a wifi extender as the problem appeared about the time he installed the extender. We coordinated on Wifi channels, so we are not using the same or overlapping channels, but the problem still exists. Using a Wifi analyzer I also see a mesh network that is using a wide band (channels 2-10) that overlaps my primary router on channel 1, but the signal strength is less than -85 dBm.

When the red symbol appears, the Repair Network will not fix the connection and trying to select my secondary access point network will not work. I have to reboot to clear the problem.

Thus based upon my experience, even with a very high signal strength the problem will occur at least daily. If I move Red to other locations and the signal strength weakens then the problem occurs more frequently. I moved Red to my bedroom which is close to my neighbor and it would drop within an hour or so.

I hope this helps. If any other information would be helpful, please let me know. If you need logs, then I will need some education on how to do that.

Paul

This is exactly my situation (also concerning the switching of radio locations...), thus probably exactly the same issue...

[frankd]

I'm not an SB developer, just a user albeit with instrumentation. I don't dare to intrude on the development forum. I am unfamiliar with and therefore cannot write an automated install and configuration patch, or plugin, app, or whatnot. I was hoping one of the senior members on the Community-Build-Radio-Firmware/ would volunteer to do so, but these participants are experienced people who just install and configure the script, and that's it. (One fellow did, however, develop a clever analysis and display package to graph connection failures, but that has been it so far.) They also seemed busy with new firmware releases, and my latest requests got lost in the subsequent excitement.

Regarding needing a patch to the firmware, this might work, but what about the configuration, and who could or would do it? The script was designed for troubleshooting the wireless connectivity issue. I suppose an automated install appropriate for many users would by default disable remote logging. SSH access would be needed to configure remote logging for troubleshooting, or to modify the script. Could be OK.

In any event, I am happy to provide support in this forum in this, the Community Build, or other topics. For example, I can try to help you install the package as it is now.

First of all thanks for developing this script.
I am currently trying out the script with the most affected radio (in parallel to testing 2 Vonets with two other Radios).
So far my experience:
The original version of the script restarted the network multiple times, but failed one time in 24h. However when the radio was synchronized, the music was interrupted two times (disconnect from network and reconnect to the network) each time when the wifi was restarted.
I am currently experimenting with several parameters (only 3 failed pings with 1 second time gap instead of 6 pings with 2 seconds time gap to trigger the restart, but allowing 8 seconds instead of 5 seconds for the restart.
So far the adapted parameter seem to help, but if somebody develops a plugin, these parameters need to be adjustable in the plugin (as well as hardcoding a gateway like I did).
I am monitoring the situation and keep you updated.

P.S.: The Vonets for the other radios work well, still survived several days despite of the higher voltage. However the LEDs are very annoying...

[staresy]

Interesting thread, as mentioned earlier, same problems as many of you. I have 2 locations each with LMS and multiple devices. One site is fairly isolated and has minimal neighbouring WIFI - I've never had any issues here with Radios or Receivers here. The other site is in an apartment in a city centre - over the last year or so radios and receiver regularly drop of the NW. So I assume it's my neighbour's WIFI to blame.

Anyway, as I see it there are two issues here, one is why does it happen in the first place, this is no doubt going to be tricky to pin-point and even trickier to resolve given that the WIFI hardware is pretty old (and unsupported now?).

The other issue is how the radio's and receivers behave in the event of an error. The recovery process seems very hit and miss and I suspect there are a number of bugs and blind alleys in the code here. Understandable because, in the past, the WIFI was pretty rock solid and never need revisiting once set. So I think the "RF" issue is highlighting some weaknesses in the recovery/reconnect code. The good news (I hope), is that surely that can be improved by the people who know about this stuff?

Sometimes, my system gets so confused (lost NW, can't reconnect, spinning blue circle, can't find NW, reboot device, reboot router, factory reset device is the only cure). This is very annoying when you get home and all you want to do is play some music, and you are forced down a reboot/factory reset cycle.

A more robust recovery/repair procedure would be a great step forward, at least then a easy re-connection would be an option.

Anyway, I'm pleased to see that this is getting some attention here, keep up the good work, much appreciated.

[POMdev]

...The original version of the script restarted the network multiple times, but failed one time in 24h. However when the radio was synchronized, the music was interrupted two times (disconnect from network and reconnect to the network) each time when the wifi was restarted.
I am currently experimenting with several parameters (only 3 failed pings with 1 second time gap instead of 6 pings with 2 seconds time gap to trigger the restart, but allowing 8 seconds instead of 5 seconds for the restart.
So far the adapted parameter seem to help, but if somebody develops a plugin, these parameters need to be adjustable in the plugin (as well as hardcoding a gateway like I did).

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:

Oh, dear. That -x is supposed to clear the TCPLOG variable, but the conditionals on line 515 and 584 don't work:
if [[ -n TCPLOG ]] ; then
should be
if [[ -n "$TCPLOG" ]] ; then
like on line 252. Sorry for the bug and thanks for the bug report.

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.