WiFi connection unstable/lost on three Radios

[reinholdk]

Also, I'm wondering if this an Asus issue that got introduce during a recent firmware upgrade.

I don't have Wifi issues with two radios connected to an Asus RT-N66U (in AP mode), currently with firmware 3.0.0.4.382_50702.

[BertdeJong]

I don't have Wifi issues with two radios connected to an Asus RT-N66U (in AP mode), currently with firmware 3.0.0.4.382_50702.

I am using the same router, but not in AP mode, it is my DHCP server. I connect using a TP-Link UAP330. I have a SSID assigned to the radio's and only they can connect to this AP (MAC filtering). btw I am on firmware 380.70 (Asuswrt-Merlin), I am in Europe. And I am having problems, see my post. I connot get two radio's to stay connected at the same time. The Annoying fact is that it hat worked for years on the same hardware.

Has it always worked for you or did you have to change anything?

[reinholdk]

Has it always worked for you or did you have to change anything?

Always worked. Had to change channels two or three times throughout the years due to neighbour's Wifi.
Actually I have two RT-N66U routers in AP mode to have a better coverage in the house. They have the same SSID. And there are 3 Radios connected wireless, two of them to the same (nearer) router.

[BertdeJong]

Always worked. Had to change channels two or three times throughout the years due to neighbour's Wifi.
Actually I have two RT-N66U routers in AP mode to have a better coverage in the house. They have the same SSID. And there are 3 Radios connected wireless, two of them to the same (nearer) router.

Well, this setup hasn't worked for me, I use the ASUS as a router, maybe that is part of the problem. Only a hardware solution seems to work

[BertdeJong]

I have three Squeezebox Radios (HW version 5), all on WiFi. Since a few weeks ago, they all have the same problem: After some time (minutes-hours) they lose connection with my WiFi access point(s). The WiFi symbol is red. "Repair Network" usually resolves the problem temporarily, but sometimes a reboot is required. But no permanent cure.

I did a major update of my entire home network infrastructure (combined Ethernet and WiFi) and software/firmware before this problem started, so many things could potentially have caused this. My LMS runs on a QNAP TS-569 Pro NAS. My (new) ordinary WiFi consists of three TP-Link Deco M9 Plus configured as Access Points (mesh network) with Ethernet backhaul to an Asus RT-N66U router. It makes no difference whether I'm using DHCP or static IP on my Radios. After spending two days investigating, I believe I have narrowed it down to the WiFi link between the Radios and my access point(s). I have replaced the TP-Link mesh network with my old Asus RT-AC66U router (configured as AP). The AP's "Wireless log" shows that the radios drop out, one after the other. This is the wireless log when all three radios are playing:

Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PSM Tx rate Rx rate Connect Time
00:04:20:26:C0:0D Yes Yes -47dBm No 18M 54M 00:39:58
00:04:20:2A:2E:B7 Yes Yes -45dBm No 36M 54M 00:39:58
00:04:20:28:44:5E Yes Yes -63dBm No 2M 54M 00:39:58

5 GHz radio is disabled.

The Radios report a signal strength of 75-100%.

Since this is my old and trusty AP, which has been working flawlessly for years, AND that the problem also exists when using my mesh network, I have only one "suspect" left: The Radio firmware was recently updated to v7.7.3 r16676, as part of an upgrade to QLogitechMediaServer v2.03.01. Unfortunately, LMS is no longer supported "out of the box" from QNAP, but I have been using their official LMS until recently. I don't known with version of the Radio firmware that was bundled with the QNAP LMS that I used until recently, but I noticed that the LMS update triggered a firmware update to 7.7.3 r16676 (dated February 14. 2014).

To cut a long story short:
1. Has anyone experienced and fixed a similar WiFi connection issue? I saw that another user changed his WiFi channel to 1 to try and fix this. I have just tried to set a fixed channel on my AP, so fingers crossed...
2. If I were to revert to an older version of the Radio firmware (v7.7.2?), would it be compatible with the current community LMS? On the other hand, I would seem very strange if this is a firmware problem, given the fact that the firmware is almost five years old and used by thousands.

Thank you very much!

--

Stein Erik

I have the exact same problem, also with an ASUS N66U as a router. I have used both the Merlin and Asus firmware, both don't work. The only solution that works is to add a wifi dongle that transfers to ethernet. I saw you came tot the same conclusion.

[BertdeJong]

Same problem here! For a couple of days, Wifi stops working after some hours. Reproducible.
Where can I edit the wifi file, mentioned by Ralphy?

ok found it. you habe to enable remote login on the radio.

Did it solve your problem? I can Putty in the radio, but how do I enter the script?

[BertdeJong]

how to edit WiFi file Radio

I had a similiar issue with my radio after installing a new wifi AP. If I unplugged the new AP and rebooted the radio it worked as before.

I came across this bug report describing how or why this could happen.

I modifed the wlan file as discussed in the bug report and my radio on wifi has been solid for 5 month now with the new AP point online.

--- /etc/init.d/wlan.orig
+++ /etc/init.d/wlan
@@ -16,7 +16,7 @@
 	    SETMAC="--setmac $macaddr"
 	fi
 
-	/lib/atheros/loadAR6000l.sh $SETMAC
+	/lib/atheros/loadAR6000l.sh $SETMAC --setRD 96
 	if [ $? -ne 0 ]; then
 	    /usr/bin/logger -s "wlan: failed"
 	    exit -1

Hoe do I edit this file? I can get in to the Radio using Putty .

kind regards,
Bert de Jong

[mrw]

Hoe do I edit this file? I can get in to the Radio using Putty .

kind regards,
Bert de Jong

You could edit the file using the 'vi' editor, which is present on the Radio. Easy if you know 'vi', but a bit of a challenge if you don't. Google may help.

Or you could copy the file onto your main computer, using scp, or winscp, or whatever. Edit it there and then put it back.

I am assuming that you have some familiarity with using basic unix/linux commands in the shell.

[RobTheGob]

I'm a little late to the party - but have been having similar issues recently (also with ASUS WAP's!) and thought I'd share my fix...

In my case - the issue appears to be related to the ASUS "Roaming Assistant" (located at: "Advance Settings:Wireless:Professional" on the stock ASUS firmware). I've now disabled it on my routers on 2.4GHz, it had previously been set to -55 dBm or -57 dBm. I can't recall if that is "on" by default - I may have turned it on myself when experimenting with the various modes (like AiMesh, which I stopped using).

When I looked at the Wireless logs - the SB Radio I was testing with would occasionally be in the -60 dBm range (and not have a closer WAP to connect to).

Hopefully it helps somebody else!

[[email protected]]

All 3 Squeezebox Radios loses wlan every 5-30mi

Hi everybody,

i'm seeking already since few weeks for a solution. it drives me crazy but i wont give up..i dont want an other system ;-)
i have all 3 squeezebox radios for over 10 years and now suddenly the wlan icon gets red and the music stops playing.

-LAN works fine but i need WLAN cause of my house
-downgrad fritzbox doesnt helped
-autochannel fritzbox disabled, fix channel 11, doesnt worked
-WLAN strengh is by over 80%
-LMS 7.9.2 SYNOLOGY (but issue comes as well when connected to mysqueezebox)
-Update to UESMART doesnt helped
-separat wlan doesnt helped
-i have 1 SSID for all (made already a split 2,4 and 5ghz) doesnt helped
-ASUS AP (roaming is disabled)
-Other LMS on windows 10 doesnt worked

Thats the last entry from the log before 1 radio gets cut, perhaps i oversee something:

[19-04-05 13:24:07.7289] Slim::Networking::Slimproto::_stat_handler (785) 00:04:20:26:24:40: STAT-STMt: fullness=7141, output_fullness=3511312, elapsed=1008.194
[19-04-05 13:24:08.2411] Slim::Web::JSONRPC::handleURI (141) POST data: [{"id":1,"method":"slim.request","params":["00:04:20:26:24:40",["status","-",1,"tags:uB"]]}]
[19-04-05 13:24:08.2417] Slim::Web::JSONRPC::requestMethod (403) Parsing command: Found client [00:04:20:26:24:40]
[19-04-05 13:24:08.2421] Slim::Web::JSONRPC::requestMethod (449) Dispatching...
[19-04-05 13:24:14.2933] Slim::Web::HTTP:rocessURL (764) processURL Clients: 192.168.0.200:34484
[19-04-05 13:24:24.0005] Slim::Networking::Slimproto::check_all_clients (223) Haven't heard from 00:04:20:26:24:40 in 15 seconds, closing connection
[19-04-05 13:24:24.0008] Slim::Networking::Slimproto::slimproto_close (247) connection closed
[19-04-05 13:24:24.0016] Slim::Networking::Slimproto::slimproto_close (284) setting timer to forget client in 300 secs
[19-04-05 13:24:24.1379] Slim::Web::HTTP::sendResponse (2018) Sent 719 to 192.168.0.200:35286
[19-04-05 13:24:24.1379] Slim::Web::HTTP::sendResponse (2018) Sent 719 to 192.168.0.200:35286
[19-04-05 13:24:24.1382] Slim::Web::HTTP::sendResponse (2024) No more segments to send to 192.168.0.200:35286
[19-04-05 13:24:24.1386] Slim::Web::HTTP::sendResponse (1980) No segment to send to 192.168.0.200:35286, waiting for next request...
[19-04-05 13:24:24.5112] Slim::Web::HTTP::sendResponse (2018) Sent 3527 to 192.168.0.200:35286
[19-04-05 13:24:24.5115] Slim::Web::HTTP::sendResponse (2052) More segments to send to 192.168.0.200:35286
[19-04-05 13:24:24.5121] Slim::Web::HTTP::sendResponse (2018) Sent 7 to 192.168.0.200:35286
[19-04-05 13:24:24.5124] Slim::Web::HTTP::sendResponse (2024) No more segments to send to 192.168.0.200:35286
[19-04-05 13:24:24.5130] Slim::Web::HTTP::sendResponse (1980) No segment to send to 192.168.0.200:35286, waiting for next request...
[19-04-05 13:24:24.7811] Slim::Networking:iscovery::__ANON__ (119) Jive: 12:34:56:78:12:34
[19-04-05 13:24:24.7815] Slim::Networking:iscovery::gotTLVRequest (194) sending response
[19-04-05 13:24:34.1971] Slim::Web::HTTP:rocessHTTP (340) Client at 192.168.0.200:35286 disconnected. (Client closed)
[19-04-05 13:24:34.1974] Slim::Web::HTTP::closeHTTPSocket (2435) Closing HTTP socket Slim::Web::HTTP::ClientConn=GLOB(0x5d96778) with 192.168.0.200:35286 (Client closed)
[19-04-05 13:24:34.2601] Slim::Web::JSONRPC::requestMethod (403) Parsing command: Found client [00:04:20:26:24:40]
[19-04-05 13:24:34.2606] Slim::Web::JSONRPC::requestMethod (449) Dispatching...

i would really appreached for a positiv input /support :-)

I saw the other postes but cant see a solution for me or i'm wrong

thx a lot and let me know.

regards
Fabian

[Arcuza]

suddenly the wlan icon gets red and the music stops playing

Are you able to get a log from the DHCP server?

Do you experience the same problem when setting a static IP on the device and reserving that static IP in your DHCP server?

[drmatt]

I wonder if your AP bounced them? I've had similar since I configured wireless ap assisted device roaming. (I.e. the ap determines that a device has a stronger signal on another ap so it cuts its connection to push it over).
I've had a lot of devices that don't necessarily reliably reconnect.


Transcoded from Matt's brain by Tapatalk

[Nojelc]

I have this problem now.

I recently returned to my holiday house. Everything was working when I left last year. On my return I updated the firmware on my Asus RT-AC68U router (mistake) and shortly afterwards my 2 SB Radios started disconnecting, in exactly the same way as described by others in this thread. I tried various things to get them working properly, all to no avail. Luckily I had anothert brand of router (Telenor) that I purchased last year to test out 4G internet access in this area. After plugging that in everything worked fine again.

Asus routers seem to be the common factor in people reporting this problem, and as everything has been working fine with my Asus router for a number of years, the problem seems to have been introduced with the latest firmware update.

As I am not technically competant to edit the file on my radios I guess I will just have to use with my non Asus router, which is a shame as in all other respects I prefer it.

[drmatt]

Well, my problems have nothing to do with Asus routers, cos I haven't got one.. but my problems may be something else I just spotted..


Transcoded from Matt's brain by Tapatalk

[rpress]

I had Wifi drops on a few of my Radios, especially one of them for some reason. They all showed good signal strength.

After tweaking many settings in my Mikrotik router I've solved the problem. I think the two most impactful settings were setting to g/n only (not b/g/n) and disabling one antenna (out of 3) in the AP which had a worse signal.