I’ve got a gl-ar300md which I use almost exclusively as a wireless repeater while travelling. Sometimes, after connecting it to any given source wireless where it shows something like 20-35% signal, the gl-ar300md’s broadcasted SSID/wireless drops repeatedly.
I first thought it was because I was using a 1A power adapter and it wanted more than that, but after plugging it into a 2.1A power source, I got the same result.
It wasn’t until after I read someone’s offhand comment on this forum (a random reply about 4-5 messages deep in an unrelated thread) that I discovered that LAN WiFi will drop when the signal on the WAN connection isn’t strong enough.
Sure enough, I placed it closer to the source and no longer did the LAN connection between my devices and the GL router drop repeatedly.
Some notes about this:
While I understand that the WAN and LAN connections use the same radio, if there were any way to separate the two so that the LAN connection does not drop when the WAN connection drops, that would be super helpful to making troubleshooting this easier.
Expected behaviour is that when the WAN signal drops, my devices would remain connected to the LAN wifi, but I simply wouldn’t have Internet until the WAN reconnects. After all, this is the behaviour we all experience when a wired WAN connection drops.
It would be really helpful if there were some kind of indicator in the firmware, whether in the GL GUI or in the LEDE advanced GUI, that the signal between the GL router and the Internet/WAN source is weak enough to cause problems with the Internet dropping out.
When in WISP config, it might also indicate somewhere that because they share the same radio, when the WAN connection drops, so too will the LAN.
Understood. Any chance of some kind of signal strength warning in the firmware? Any kind of indicator of what to expect from the device when the signal is weak would surely help!
In Luci (advanced) , I think if you set the lan wifi to AP-WDS mode this will keep the AP on if the wan drops.
You do not have to set up WDS, just enable this mode.
@alzhao yes you are correct it is not related to wds or wisp, at least not directly.
It is the intended defaults of the open source MAC80211 drivers.
To be more precise, in MAC80211 the Client radio (on a device with just one physical radio) takes priority, logically if there is nothing to repeat then shut down the access point.
This priority can be changed by setting BOTH Client (WDS) and Access Point (WDS) on the respective radio interfaces. It does work
To double check my sanity, I just downloaded the latest release openwrt-ar300m-2.264.bin
I set up in wisp mode and made sure it was working.
Looking in Advanced (Luci):
I find that Access Point (WDS) is already set
But the linking wireless is set to just Client mode.
On turning off the wifi that the AR300M is connected to, as expected the AR300M’s radio also went off, as everyone finds.
I then used Luci to change the radio mode from Client, to Client (WDS) and repeated the test.
YES!
The AR300M’s radio now stays on.
This is the intended functionality of OpenWrt WDS, a part of the MAC80211 specification.
This does not work on the MT300N-V2 as it does not use the full MAC80211, only a shim and is handled directly by the proprietary drivers.
As an aside, if this was not the default MAC80211 behaviour in wisp/repeater mode then in a scenario where a repeater has the SAME ssid as other repeaters or the base radio, if one repeater looses its connection upstream, then it will become a rogue access point and poison any roaming on the site. Having the rogue turn off its radio prevents this poisoning.
Running your own travel router with a unique ssid is a different matter of course.
Whoah. Not only does using AP-WDS mode on the LAN wifi help with these disconnects, it also seems to stabilize the connection when using the 5G radio. I don’t completely understand why though.
Once I got the 5G driver installed and the radio up with stock connectivity, here’s the weird behaviour I would get from my AR300MD (I also got this when using the old 3.03 firmware and it frustrated me to no end):
Upon client mode connection to the WAN 2.4Ghz WiFi, luci would either randomly add two wireless connections (both seemingly with the same settings), OR it would add one new connection, but change the display of the SSID and Mode of my LAN connection to match that of the new WAN connection, thus killing my LAN WiFi. In the case of the duplicate, if I deleted the second one, the first one would remain, but then fail to connect to the WAN WiFi altogether.
For whatever reason this never happened prior to installing the 5G driver even though what I’m describing here technically has nothing to do with the 5G radio yet.
After reconfiguring both the 5Ghz LAN connection and the 2.4Ghz LAN connection to AP-WDS mode (rather than just AP mode), I have yet to see either of these problems and I’m able to successfully connect and maintain connectivity with the 5Ghz and 2.4Ghz LAN all while the WAN remains operational.
While the above deals with both WAN and LAN WiFi dropping due to WAN signal problems (and how to rectify the LAN WiFi dropping when the issue should be isolated to the WAN WiFi connection), I have since discovered an issue with LAN WiFi dropping out while using Wired WAN with no Wireless WAN connection.
This issue was occurring because of a repeating script triggered on boot and running every 15 seconds that appears to re-scan for wireless connections. I can’t recall if this was added by stock firmware or something that I added from a forum recommendation because of my unit being one with a 5Ghz radio. To resolve the problem I did the following:
Log in to Advanced / LuCI Interface.
Go to System > Startup and scroll to bottom where the “Local Startup” section is.
Comment out this line which is near the bottom of the Local Startup textarea (add a # to the start of the line): (sleep 15;/usr/bin/gl_health) &
After commenting it out, the issue went away and I’m able to keep my wired WAN connection and WiFi LAN going continuously. I haven’t tested using a WiFi WAN connection in client mode since making this change, so I suppose it’s possible that turning off the gl_health script could break WiFi WAN connections. We shall find out.
Note that when I was previously using WiFi WAN in client mode, the gl_health script seemingly created no issues. There were occasional disconnects, but not nearly as frequent as when using wired WAN.
Is there, perhaps, a need to have the gl_health script updated to detect if actually using wireless WAN before doing its usual scan?
