Galaxy A51 phone keeps dropping WiFi

[drinkingbird]

Okay, I made a few changes.
2.4 GHz
Control Channel: Auto (It's hopping channels. After a reboot it was on Ch. 8, now Ch. 11)
Explicit beamforming: Enable
Bluetooth Coexistence: Pre-emptive

System:
USB Mode: USB 2.0

I found these....

The infamous USB 3.0 issue - OK on stock vs. NOT ok on Merlin

EDIT 11th Dec: However, today I tried flashing older stock and Merlin firmwares, 3 versions of each type, all are 384 codebase. And I can now confirm that the issue is only on Merlin firmwares. There's this infamous issue of USB sticks plugged in USB 3.0 port that has been mentioned here many...

www.snbforums.com

DSL-AC68U - Wifi 2.4GHz band interference issues with USB 3.0 drive

TLDR; Skip to the bottom to read the solution. I typed up about the problem of 2.4GHz wifi constantly dropping / disconnecting that I had been experiencing with my DSL-AC68U, until I found the solution so thought I'd post it anyway as this may help someone with the same issue. (1) Bought the...

www.snbforums.com

You can try bluetooth coexistence disabled too, supposedly pre-emptive helps (with BT devices that support it - the plain "enabled" is more of a crude version that doesn't negotiate with devices), but you can try without and see if your wifi improves and/or bluetooth suffers.

I had an old BT headset (BT 3.0) for work and if I was in the same room as my router, nobody could hear me, even trying both coexistence settings. I don't think 3.0 supported pre-emptive. But new one is 5.0 with BLE and other features and it works great. Part of it is that BLE takes a lot less bandwidth for HD audio, whereas 3.0 sucked up a lot.

 

[Rob Q]

Well, whatever I did works. I can still stay connected to my 2.4 network on the driveway and up to the road. Sometimes it does drop due to the "quality" but that could just be the network across the street being at the same strength is my signal and on the same channel.
I think it was the USB 3.0 mode bug.
Is there a way to "fine tune" it so it doesn't disconnect at-72dBm? Maybe have it set to -75?

 

[drinkingbird]

Well, whatever I did works. I can still stay connected to my 2.4 network on the driveway and up to the road. Sometimes it does drop due to the "quality" but that could just be the network across the street being at the same strength is my signal and on the same channel.
I think it was the USB 3.0 mode bug.
Is there a way to "fine tune" it so it doesn't disconnect at-72dBm? Maybe have it set to -75?

If you are using roaming assistant or aimesh yes you can tweak that value. If not, then it is your phone and probably not, I haven't seen any setting even in developer options to change anything to do with RSSI. In fact many complain that their phone is not sensitive enough and end up disabling wifi scan throttling (which makes it less more aggressive with roaming) in developer options.

But if your neighbor is using the same channel, you can try a different one, most devices won't disconnect until the mid 80s or so, but every OS and implementation (samsung may have their own settings that override google) are different. In reality, it is the SSID that typically makes the determination, just because they're on the same channel doesn't have a huge amount to do with it these days.

 

[sfx2000]

So, the idea is that I use my 5 GHz network for indoors and the 2.4 GHz for out of the house and around the property. The signal is so strong that it even my neighbors can see my 2.4 GHz network at a strong signal.
The problem is that when I exit the house and go on the drive way, my phone switches to LTE instead of 2.4 GHz and it says "Ready to connect when network quality improves". This is a real pain.

The phone is going to do what it's going to do - if LTE is a better signal, it'll use it... it wants to use the best possible signal in it's view/rulesets about what network it will favor when given a choice...

If you have WiFi calling enabled, this drives decisions that the device has to make to ensure that not only making calls works, but also receiving calls, which can happen at any time...

If your phone is working fine - then don't worry to much about it - there's little you can do on the router side - e.g. the client is in charge, and there's little options on how to "force" it to bend to your wishes/wants/desires...

 

[sfx2000]

Is there a way to "fine tune" it so it doesn't disconnect at-72dBm? Maybe have it set to -75?

In my experience, the trigger for mobiles is around -70, and that's with the timed average to keep the device from ping-ponging from one AP to another and also from WiFi to LTE...

Know that Google (Android) and iOS (Apple) have billions of sets of data across wifi and lte, and they work with the chipset vendors, handset OEM's, and the carriers to make settings that ensure that the devices have the best possible connectivity.

 

[Magister]

I thought you should only use channel 1, 6 and 11 when using 20MHz wide channel. Imagine a 3 lanes highway. Of course you can drive between 2 lanes, but you f*ck up everything.

If you use an in-between channel, like 8, your AP sees other RFs as noise, as well as APs on 6 and 11 will see your RF as noise, like if it was a microwave oven. But if everyone is using the same channel, the modem sees others SSID and all and they all can mitigate, I guess... I hope that WiFi is not using a primitive random ALOHA protocol but some kind of carrier sense?

For instance a local hospital is using 130 APs, all on 1, 6 and 11

 

[sfx2000]

I thought you should only use channel 1, 6 and 11 when using 20MHz wide channel. Imagine a 3 lanes highway. Of course you can drive between 2 lanes, but you f*ck up everything.

If you use an in-between channel, like 8, your AP sees other RFs as noise, as well as APs on 6 and 11 will see your RF as noise, like if it was a microwave oven. But if everyone is using the same channel, the modem sees others SSID and all and they all can mitigate, I guess... I hope that WiFi is not using a primitive random ALOHA protocol but some kind of carrier sense?

I fail to see how this is related to OP's problem...

Just saying...

 

[Tech9]

but you f*ck up everything

No, you don't. Modern Wi-Fi can drive in between the lanes very well. Many routers on Auto select channels different than 1-6-11, filter the noise and push more data on channels with more available bandwidth. If someone around still uses 801.11g router and has a problem - time to upgrade.

 

[drinkingbird]

I thought you should only use channel 1, 6 and 11 when using 20MHz wide channel. Imagine a 3 lanes highway. Of course you can drive between 2 lanes, but you f*ck up everything.

If you use an in-between channel, like 8, your AP sees other RFs as noise, as well as APs on 6 and 11 will see your RF as noise, like if it was a microwave oven. But if everyone is using the same channel, the modem sees others SSID and all and they all can mitigate, I guess... I hope that WiFi is not using a primitive random ALOHA protocol but some kind of carrier sense?

For instance a local hospital is using 130 APs, all on 1, 6 and 11

This was true for A/B/G. Much less so with N and pretty much not at all for AC and AX. The 1/6/11 rule no longer applies to residential areas, you have to take what you can get which is often going to be an overlapping channel. All of the sending stations will see each other and coexist and share as much as possible. In your picture above, you will get much better performance on channel 3 or 8 than on 1/6/11 and it will actually hurt the neighboring networks less than if you had picked one of those 3 channels. In most cases there will be more usable bandwidth on an overlapping channel with no or few networks than a non overlapping with lots of them.

1/6/11 is only practical now when you have control of the entire environment, so corporate or you live in the boonies etc.

 

[sfx2000]

1/6/11 is only practical now when you have control of the entire environment, so corporate or you live in the boonies etc.

1/4/8/11 works well with 11g/n/ax as they have 20MHz channels, unlike 802.11b where channels are 25 MHz wide.

Also - disabling legacy mode (802.11b) has significant benefit airtime wise, as both beacon rates and multicast rates increase from 1 Mbps (in DSSS mode) to 6 Mbps in OFDM mode.

One last note - one of the key things in 11n over 11g - 11n mandates cochannel rejection of -20 dB - which means that overlapping BSS's can have the same RSSI at the client station, and the client must reject the interfering BSS (SSID).

11ax improves this even more due to color coding in 11ax mode (client and AP must support 11ax, otherwise you fallback to earlier spec revs)

 

[Magister]

Interesting, thanks! Anyway on 2.4 I only have smart plugs, so I don't really care... I'll double check my 2.4 "professional settings". Everything else is wired or on 5GHz.

 

[sfx2000]

For instance a local hospital is using 130 APs, all on 1, 6 and 11

This is somewhat of an unrealistic scenario - the screen cap is obviously inside the extended network - get a 100 meters away, and all those AP's are in the noise floor...

 

[drinkingbird]

1/4/8/11 works well with 11g/n/ax as they have 20MHz channels, unlike 802.11b where channels are 25 MHz wide.

Also - disabling legacy mode (802.11b) has significant benefit airtime wise, as both beacon rates and multicast rates increase from 1 Mbps (in DSSS mode) to 6 Mbps in OFDM mode.

One last note - one of the key things in 11n over 11g - 11n mandates cochannel rejection of -20 dB - which means that overlapping BSS's can have the same RSSI at the client station, and the client must reject the interfering BSS (SSID).

11ax improves this even more due to color coding in 11ax mode (client and AP must support 11ax, otherwise you fallback to earlier spec revs)

Yeah that's why I never understand some here telling people to set it to "auto" for mode. N/AC/AX (depending on the router) with legacy rates disabled is absolutely the way to go. That's the only way I can see to get the Asus to disable the legacy beacon rates and set it to 6M, other than running SSH commands which may or may not work, haven't tried. Pro grade stuff lets you specify the specific beacon rate as well as the MCS rates supported. Nothing should be running the pre OFDM rates these days, even 5.5 and 11. 6/12/24 is all that should be used (probably mostly 6, 12 in some cases, 24 is sort of aggressive).

At this point in my area I just leave it at auto and have it rescan daily and they all play musical chairs. Gave up on attempting to hardcode.

At some point maybe 2.4N will finally go away and 2.4AX will take over but I think that's a long ways away.

 

[sfx2000]

At some point maybe 2.4N will finally go away and 2.4AX will take over but I think that's a long ways away.

2.4 G/N is fine - it's DSSS mode (legacy) that is the problem...

OpenWRT deprecated it some time back as a default - and many cable operators on their gateways disable 11b mode as well...

Stepping away from 11b is much like getting away from WEP/WPA (1) - mixed mode has a lot of impact.

11g/wap2 is the minimum these days - 11g for OFDM, WPA2 for packet aggregation which is supported by 11g/11n

I've got a hobby OpenWRT build that might surprise you with it's performance on N300 2.4GHz - ath9k drivers are still in active development, and have SQM at that level via the cerowrt team and changes merged back into both mainline linux as well as OpenWRT...

 

[sfx2000]

That's the only way I can see to get the Asus to disable the legacy beacon rates and set it to 6M, other than running SSH commands which may or may not work, haven't tried.

Older Legacy Platforms on Asus (e.g. non-HND) have a bug in the WL driver where disabling 11b support in the WebUI breaks WPA/WPA2 auth... so while that checkbox is there in 386, might step carefully if one has an AC68U...

Not sure if this bug is also in HND - brought it up with @RMerlin and he said take it up with Asus directly - but since I don't have an HND based device, I can't confirm if that WL bug is there or not...

 

[drinkingbird]

2.4 G/N is fine - it's DSSS mode (legacy) that is the problem...

OpenWRT deprecated it some time back as a default - and many cable operators on their gateways disable 11b mode as well...

Stepping away from 11b is much like getting away from WEP/WPA (1) - mixed mode has a lot of impact.

11g/wap2 is the minimum these days - 11g for OFDM, WPA2 for packet aggregation which is supported by 11g/11n

I've got a hobby OpenWRT build that might surprise you with it's performance on N300 2.4GHz - ath9k drivers are still in active development, and have SQM at that level via the cerowrt team and changes merged back into both mainline linux as well as OpenWRT...

B is disabled by default in a lot of stuff I see, I believe even Asus. Just referring to getting rid of a lot of the remaining legacy and compatibility stuff associated with G and N to hopefully continue improving performance and reliability of 2.4ghz. But so much stuff is using N 2.4ghz still I don't think that will happen for a long time. I guess as more and more moves to 5ghz and 6ghz those IOT and other devices using 2.4 will start to get more breathing room.

 

[drinkingbird]

Older Legacy Platforms on Asus (e.g. non-HND) have a bug in the WL driver where disabling 11b support in the WebUI breaks WPA/WPA2 auth... so while that checkbox is there in 386, might step carefully if one has an AC68U...

Not sure if this bug is also in HND - brought it up with @RMerlin and he said take it up with Asus directly - but since I don't have an HND based device, I can't confirm if that WL bug is there or not...

My RT-AC1900 (68U) has 2.4 set to "N Only" for years now and no issues with WPA2, however I just checked and it is advertising basic rates of 5.5 and 11 on 2.4ghz (6/12/24 on 5ghz as expected). So I guess it is somewhat misleading. Maybe that was modified for the reasons you mention.
With GUI set to "N Only" it is showing Supported Rates: [ 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ] and I can see it advertising 5.5 and 11 as basic rates.
For the heck of it, I used WL rateset to change it to 6b 9 12b 18 24b 36 48 54 and it works as expected, I can connect to 2.4 with WPA2 from laptop and phones. So I guess the bug you mention may be related to the GUI and what it changes. Not that big of a deal, my Asus only services one 2.4ghz device, an old N150 blu-ray player.

Even my Ubiquiti is weird about it. The options in my old N150 AP are minimum rate/beacon 1/1, 2/2, 5.5/5.5, 6/11, 9/11, 11/11, 12/12, and 24/24. 6/6 is missing so in reality to totally disable CCK/DSSS I have to set my beacons to 12 which is fine, I don't want my phone holding on that long as I drive away anyway. So even they can't quite get it quite right.

This is the challenge of working with pro grade stuff and having had it in my house before, then going to consumer and semi-pro, I don't like these GUIs that try to dumb it down or do what they think you want them to do. I want it to give specific settings that I can put how I want them.

 

[Rob Q]

My neighbors 2.4 GHz network is on channel 5 and 8 at 20 MHz wide. I have mine set to channel 1 at 20 MHz. Everyone here seems to be using AC.
I can stay connected now to the end of my driveway and it becomes a bit spotty. It'll either drop or stay connected and reach as far as two houses down from me. Channel 1 does have some strong signals but they're 2 and 3 houses up from me. When I walk down the road, my signal drops at -80dB, then it switches over to LTE.

 

[drinkingbird]

My neighbors 2.4 GHz network is on channel 5 and 8 at 20 MHz wide. I have mine set to channel 1 at 20 MHz. Everyone here seems to be using AC.
I can stay connected now to the end of my driveway and it becomes a bit spotty. It'll either drop or stay connected and reach as far as two houses down from me. Channel 1 does have some strong signals but they're 2 and 3 houses up from me. When I walk down the road, my signal drops at -80dB, then it switches over to LTE.

That's to be expected. When your AP is indoors you can't expect to get very far away from your house and have a usable signal. Remember your phone has to get its signal back to the AP also and it has much smaller antennas and less power. In reality if you find that your phone shows wifi signal but has unusable internet, you probably actually want to decrease the power on your router so the phone will disconnect sooner.

AC routers still support 2.4Ghz (technically it is just N on 2.4) so even if your neighbors are using AC they'll usually also have a 2.4Ghz signal.

 

[sfx2000]

My RT-AC1900 (68U) has 2.4 set to "N Only" for years now and no issues with WPA2, however I just checked and it is advertising basic rates of 5.5 and 11 on 2.4ghz (6/12/24 on 5ghz as expected). So I guess it is somewhat misleading. Maybe that was modified for the reasons you mention.
With GUI set to "N Only" it is showing Supported Rates: [ 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ] and I can see it advertising 5.5 and 11 as basic rates.

"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...