Galaxy A51 phone keeps dropping WiFi

[drinkingbird]

"N-Only" doesn't disable legacy basic rates, so the beacon is still transmitted in DSSS, not OFDM... this is so that legacy BSS's can see the beacon and management frames (including CTS/RTS) so that they don't get stepped on.

Due to a "quirk" in 802.11n - N-only mode may go into protection if there is even a sniff of legacy B/G anywhere near by - an old HP wireless printer over at the neighbors house for example - and you'll see this as non-HT stations present with the field set to true (1).

G/N mixed operations - what this does is set the wireless radio to OFDM only mode, and the basic rate starts at 6, and follows the OFDM rates up - remember in Wireshark and other parsers, when you see 6(B),12(B), etc, this does not mean it's in 11b mode, that just says it's the basic rates...

Anyways...

Going back to Asus and the WL closed source driver - not sure how the Asus WebUI scripts initialize the driver, so I can't comment on that too terribly much, other than report what I observed - over in the basic settings, there is the switch to disable 11b mode, and that was causing issues with clients not being able to properly attach. Toggling that switch back to enabled, then things were fine - note that the router was set for WPA2, not mixed WPA/WPA2...

For devices that use hostapd - things there are a bit more straight forward, as long as both hostapd and the drivers are fairly recent - OpenWRT for example, changed the default settings for legacy a couple of years back now - I'd have to look for the commit over in Master, but it's there...

At some point some of the options disappeared in the basic screen. On my AC1900 it now offers "auto/N Only/Legacy" as really the only settings. b/g protection is automatically enabled and greyed out if you change it to N only. So I guess they leave 5.5 and 11 enabled for compatibility but attempt to protect from/reject B and G devices using protection. "N Only" does disable several of the legacy basic rates, the ones below 5.5 obviously, so that is definitely helpful.

I have noticed very old draft-N devices like my blu-ray player won't connect if 5.5/11 are disabled, so I'm guessing that is probably one reason they don't remove it. I can remove them via WL and everything connects except that device (and I suspect my old HP N printer which was also probably draft-N, but that is hardwired so I haven't ever tried). So essentially you can force G/N Mixed still but it has to be done using WL command and script and may prevent older/draft N from connecting.

Yes I realize the B there is for basic rate not 802.11 b

I do find having my outdoor AP with minimum rate of 12 works well, my phone does not attempt to hang onto it as I drive down the road or go back into the house. It actually probably works better than the minimum RSSI feature which I also have enabled and pretty aggressive.

 

[sfx2000]

At some point some of the options disappeared in the basic screen. On my AC1900 it now offers "auto/N Only/Legacy" as really the only settings. b/g protection is automatically enabled and greyed out if you change it to N only. So I guess they leave 5.5 and 11 enabled for compatibility but attempt to protect from/reject B and G devices using protection. "N Only" does disable several of the legacy basic rates, the ones below 5.5 obviously, so that is definitely helpful.

See this... seems to be working these days...

old-school 68U-B1

 

[sfx2000]

See this... seems to be working these days...

old-school 68U-B1

View attachment 50449

Over the air...

 

[sfx2000]

Over the air...View attachment 50450

More...

 

[drinkingbird]

See this... seems to be working these days...

old-school 68U-B1

View attachment 50449

Ah, that box pops up if I change it from N only to Auto. So in reality Auto with "disable 11b" actually accomplishes what you would think "N only" does. Except if it senses a G device it will potentially re-enable the legacy rates (or not, who knows). Probably only if one is present during start up or a scan.

Going forward, you shall be referred to as Thumper.

 

[sfx2000]

At some point some of the options disappeared in the basic screen. On my AC1900 it now offers "auto/N Only/Legacy" as really the only settings. b/g protection is automatically enabled and greyed out if you change it to N only. So I guess they leave 5.5 and 11 enabled for compatibility but attempt to protect from/reject B and G devices using protection. "N Only" does disable several of the legacy basic rates, the ones below 5.5 obviously, so that is definitely helpful.

I fail to understand - see above - it's all clear there - device settings, over the air values...

there is no secret sauce - perhaps this is outside of your range, and that's ok...

 

[drinkingbird]

I fail to understand - see above - it's all clear there - device settings, over the air values...

there is no secret sauce - perhaps this is outside of your range, and that's ok...

And you always have to take it there, not capable of just having a discussion without trying to assert your superiority?

Apparently you think "N only" advertising B DSSS/CCK rates while "Auto" with "disable b" does not makes sense, but I don't.

 

[sfx2000]

Ah, that box pops up if I change it from N only to Auto. So in reality Auto with "disable 11b" actually accomplishes what you would think "N only" does. Except if it senses a G device it will potentially re-enable the legacy rates (or not, who knows). Probably only if one is present during start up or a scan.

You have it all wrong - the driver is running as 11g/n - there is no 11b

Study up padawan - get past your attitude and you might learn a thing or two...

 

[drinkingbird]

Well - you know what you know...

I know what you don't...

I've done my time in IEEE 802 and IETF...

So you should see why the way asus presents it makes no sense. If anything they should have a greenfield and mixed mode. It appears "auto" with "b disabled" behaves like greenfield with failback possible to mixed, while "N only" is behaving as mixed. Does not make sense. Any enterprise/professional device certainly wouldn't present it that way.

 

[drinkingbird]

Study up padawan - get past your attitude and you might learn a thing or two...

Yeah, you telling me to get past my attitude is really not carrying any weight.

You know what you think you know, have fun with that.

 

[sfx2000]

Yeah, you telling me to get past my attitude is really not carrying any weight.

You know what you think you know, have fun with that.

Well... that's your view...

 

[sfx2000]

Well... that's your view...

When you start writing code - let me know...

I'll be happy to review and share knowledge - I mostly work on ath9k stuff at a wireless level, but primitives are what they are, and most of this dives back into the kernel.

WL is a bit weird, as they're wireless, but also ethernet... broadcom does what it does, but it doesn't make it easy for others outside of their closed source...

 

[drinkingbird]

Ah, that box pops up if I change it from N only to Auto. So in reality Auto with "disable 11b" actually accomplishes what you would think "N only" does. Except if it senses a G device it will potentially re-enable the legacy rates (or not, who knows). Probably only if one is present during start up or a scan.

Going forward, you shall be referred to as Thumper.

For others following this or finding it in the future.

If you want to disable CCK/DSSS (legacy) rates, there seem to be two options, at least on the non-HND routers like RT-AC68U

1. Set to auto, check off "disable b", hit apply. That will disable those legacy rates however my guess is that if it does sense a device requiring a legacy rate, it may re-enable them.
2. Do the same as above, but after hitting apply, change it to "N Only" and hit apply again. The "disable b" checkbox disappears, but it is still in effect, so this results in the legacy rates being permanently disabled. If you change it back to auto you'll see the "disable b" checkbox comes back and is still checked off. So it hides the box, but does not unset it. I checked and confirmed 5.5 and 11 are no longer advertised or supported (both in the CLI and via InSSIDer), even after a reboot after doing this.

Note that some draft-N devices don't seem to like having those legacy rates disabled so you may not be able to run in this mode if you have fairly old N devices.

 

[Rob Q]

Interesting. I'm a bit confused though, should I change anything on my AC1900P to improve the range of the 2.4 GHz network?

 

[Tech9]

There is nothing you can do to improve the range.

 

[drinkingbird]

Interesting. I'm a bit confused though, should I change anything on my AC1900P to improve the range of the 2.4 GHz network?

The settings being discussed would technically decrease your range. They prevent low quality client signals from connecting, and prevent legacy devices (which can severely degrade throughput, latency, etc) from connecting.

Increasing range should be done with additional APs. Trying to squeeze more out of one that isn't reaching where you need it to is just going to cause more issues than it solves.

 

[sfx2000]

See this... seems to be working these days...

old-school 68U-B1

Ok - it's not actually working for some instances - been spending better part of the day debugging this, and while Windows seems to be ok with this, Linux is not...

I'll start another thread - but it does look like there is an issue with Broadcom's WL driver in how it handles TurboQAM - which if folks recall, is non-standard for 802.11n... Broadcom does some tricky things to get VHT type performance in 2.4 with TurboQAM, and it's not in the beacon itself (other chipset vendors take a different approach here compared to Broadcom)

Disabling legacy support in 2.4GHz is what started me down this path, but it does raise issues that Asus can't fix...

 

[Tech9]

but it does look like there is an issue with Broadcom's WL driver

Isn't this driver for BCM4360 something years old already? The hardware was made like 2012.

 

[sfx2000]

Linux is not...

And linux includes ChromeOS and Android - I'm sure that Broadcom has "tweaks" in place for their client chipsets for mobile phones and others...

Isn't this driver for BCM4360 something years old already? The hardware was made like 2012.

Yes, but this driver is still current for the non-HND platforms... the same issue might be in HND, but I don't have a Router/AP to test

And yes, it's how the driver is configured via WL by WebUI for 2.4GHz

Anyways - like I mentioned, it's a Broadcom issue by going outside of the 802.11 specs to support Turbo/NitroQAM

 

[Tech9]

I always disable non-standard options.