WRT1900AC - TIMEOUTS/POOR LATENCY WHEN GUEST DEVICES CONNECT #350
Comments
|
On Wed, Feb 20, 2019 at 9:42 AM SuoaJ ***@***.***> wrote:
I have tried OpenWrt v18.06.1, v18.06.2 and the latest version on @davidc502 website on the WRT1900AC. Same behaviour on all of them - the wireless network, 2.4GHz, performance begins to degrade(poor latency, timeouts) when about 3 or more devices are connected on the guest network. The degraded connection is between devices on the LAN and the router. No other packages were installed when tested. The guest network was configured using this guide. There are no obvious messages in system/kernel log when the problem(large fluctuations in LAN ping times) pops up but I know for sure it only happens when devices begin to get on to the guest network) .
A few observations:
The wireless performance improves when legacy mode is disabled on the 2.4Ghz network. Nonetheless, ping times can fluctuate quite high sometimes and the occasional timeout occurs.
All the devices on the guest network(3 to 6 most times) are Android devices. I don't know if this matters.
The wireless guess devices are my neighbours and are a little distance from me, hence they usually connect at 80(+)db.
Could this be a Wifi driver issue?
Not necessarily either a driver or a firmware issue.
At -80dBm (I'm assuming you're in dBm) the connection will be right on
the edge of most consumer devices being able to even keep a connection
going. I wouldn't consider anything below -70dBm as routinely
functional. Since we're talking about 2.4GHz, it could simply be
because the devices are communicating at b/g rates instead of n,
especially considering the low RSSI. Also the fact that they're
connecting at such low RSSI could mean they're connecting and
disconnecting a lot. If you want to have good performance, I wonder
why you're allowing devices that aren't yours in the first place.
Rhetorical question. In any case, I suggest doing a wireless sniff and
looking at the results. Likely the answers are in there. Anything else
would just be speculation.
- Steve
|
|
Thanks for the reply. Let me address your second point first. I live in a third world country where all of us are not fortunate to have a broadband Internet connection at home. I happen to be able to afford it, so I share what I can with my neighbors. On your first point; yes, the devices are connecting at b/g rates. However, should this affect latency on the main WiFi, to the point of even "timeouts" between a device on the main wireless LAN(not the guest LAN) and the router itself, especially on a router with solid hardware as the WRT1900AC? What should I look for on the wireless sniff? You |
|
On Wed, Feb 20, 2019 at 10:22 AM SuoaJ ***@***.***> wrote:
Thanks for the reply. Let me address your second point first. I live in a third world country where all of us are not fortunate to have a broadband Internet connection at home. I happen to be able to afford it, so I share what I can with my neighbors.
Sorry, it wasn't meant to be judgmental. Fair enough. And that's very
nice of you to do, kudos. And, you have to accept the consequences of
doing so. A hit to performance is going to be one of those
consequences.
Likely the biggest issue is the signal strength for those clients. You
need to improve that to a decent amount (50-65dBm). Like it or not,
you're now a "service provider." Move your AP, invest in another AP
linked to yours and build up the relevant infrastructure. Repeaters,
higher-gain antennas, etc. All I can give is general thoughts.
On your first point; yes, the devices are connecting at b/g rates. However, should this affect latency on the main WiFi, to the point of even "timeouts" between a device on the main wireless LAN(not the guest LAN) and the router itself, especially on a router with solid hardware as the WRT1900AC?
In a word, yes. For many varied reasons, all combining to give you the
effect you're seeing. It's not a function of "solid hardware".
What should I look for on the wireless sniff?
Well, you answered one of the first things to look at - checking that
they're at b/g rates. Looking at the pattern of assoc and disassoc
and similar management packets, the signal strengths, repeats, and
overall what these clients are doing to your environment would all be
interesting/useful in diagnosing the specific issue. But I suspect the
root cause is what is already pointed out and there's really only one
solution - improving signal strength for your clients.
Good luck.
- Steve
|
|
Hi Steve, if signal strength is the culprit, then how much signal strength is good enough? No matter the signal strength, there will always be clients on the edge of the WiFi, possibly connecting at b/g rates. Yet still we have open public access points which do deteriorate like this when many clients are connected. Prior to this router, I ran a Xiaomi R3G router at the same location which did not behave this way. Neither did my GL-MT300N-V2 or a Linksys EA3500. |
|
On Wed, Feb 20, 2019 at 11:35 AM SuoaJ ***@***.***> wrote:
Hi Steve, if signal strength is the culprit, then how much signal strength is good enough? No matter the signal strength, there will always be clients on the edge of the WiFi, possibly connecting at b/g rates. Yet still we have open public access points which do deteriorate like this when many clients are connected. Prior to this router, I ran a Xiaomi R3G router at the same location which did not behave this way. Neither did my GL-MT300N-V2 or a Linksys EA3500.
OK.
You're comparing apples and oranges. "open public access points"
likely are full enterprise AP network systems, with expensive
equipment and properly engineered and managed deployments. A single
consumer-based AP isn't going to do the same job.
As for the other routers. Also OK. Different tolerances. Different
chips, different limits. Maybe they just cut off other devices at a
particular RSSI limit. Maybe they do better with legacy clients. Who
knows. If another AP works better for what you're doing, you might
want to use that.
Your original question: is it a firmware or driver issue? It's
possible, but not likely your problem; there's plenty of other more
obvious explanations to look at first. Do I know for 100% fact that
signal strength is your issue? No. But it's a big red flag. And is it
your only problem? Probably not.
You're trying to run an enterprise level service on a single home
router. Wrong hardware and network configurations for the use-case
you're trying to do. Can it be done? Maybe, if you know what you're
doing and live with the trade-offs. When working at the edge of a
device's use-case, some things will work and some won't work well.
Trial and error.
- Steve
|
|
I'm sure you will agree that having 3 to 6 'guest' devices within a 100-150 meter range connected to a router isn't exactly enterprise stuff. Is it? Obviously, the cause of the problem is unclear but I'm willing to try out different suggestions. Thanks for the input. |
|
If you still have any of those other devices, setting one up as a dumb AP for the guest network, with a UTP backhaul may offer a way around the apparent mwlwifi difficulties. |
|
I have given some thought to this but I wouldn't benefit from the good range of the WRT1900AC. So I'm gonna keep on trying to figure this out and if nothing else works, then I may have no choice but to settle for this option. |
|
just some cents from me. since all about talking about android and mobile devices. mobile devices have one annoying features which will fuck up every network and increase latencies. "power save". power save often means, a mobile radio goes to sleep but the connection is still established and the ap gets no signal that the device is gone in reality. now we have different clients wich are showing as connectable but in fact they wont receive anymore any data. this will cause a lot of troubles with hanging packets within a transmission queue. of course we cannot fix it since marvell still refuse to maintain the driver in any way and to fix bugs at all. but as a work around you may simply disable the power save function in your wifi settings (on your mobile device). i know that this option is available on several phones. |
|
Thanks for the option, @BrainSlayer. I can certainly try it out on my own phone but I wouldn't want to touch others phones. Some people are very sensitivity when it comes to a cellphone and their privacy. Hopefully, a solution can be found which does not involved the end-user. |
|
@BrainSlayer Don't the packets and zombie clients time out eventually?
Isn't this github repository the device driver in question? If so, what prevents us from implementing this fix ourselves? The code is hard to understand? Or is it something else? |
|
they should. the problem is that the chipset firmware is handling this and we can't change it. on ath9k and other drivers der is a cyclic null frame ping link packet to detect such zombies to kick them out or at least ignore them and clean the queue. the marvell driver has 2 parts. the opensource part here which is a interface between the linux wireless stack and the chipset. but the chipset has a own closed source firmware which we cannot control. thats the main issue here |
|
a common solution is also to announce that the ap isnt powersave capable. but i need to research if this works where and how we can handle this. my request on your is first to find out if its a solution at all. and it only works if all devices have powersave disabled |
|
can we not implement a cyclic null frame ping link packet that is handled in the "software side" of the driver, and keep the devices in the active list forcibly and kick out the ones that we don't get a response ? |
|
Hi same problem for my on my router |
|
Seem to be experiencing this problem on my WRT32X too running the latest driver version. Looks like there is isn't much support here anymore. |
|
@dmascord . no we can't. its fullmac chipset .all relevant functions are handled within the chipset firmware binary blob. |
I have tried OpenWrt v18.06.1, v18.06.2 and the latest version on @davidc502 website on the WRT1900AC. Same behaviour on all of them - the wireless network, 2.4GHz, performance begins to degrade(poor latency, timeouts) when about 3 or more devices are connected on the guest network. The degraded connection is between devices on the LAN and the router. No other packages were installed when tested. The guest network was configured using this guide. There are no obvious messages in system/kernel log when the problem(large fluctuations in LAN ping times) pops up but I know for sure it only happens when devices begin to get on to the guest network) .
A few observations:
The wireless performance improves when legacy mode is disabled on the 2.4Ghz network. Nonetheless, ping times can fluctuate quite high sometimes and the occasional timeout occurs.
All the devices on the guest network(3 to 6 most times) are Android devices. I don't know if this matters.
The wireless guess devices are my neighbours and are a little distance from me, hence they usually connect at 80(+)db.
Could this be a Wifi driver issue?
The text was updated successfully, but these errors were encountered: