Galaxy A51 phone keeps dropping WiFi

[sfx2000]

I always disable non-standard options.

This one you can't disable from WebUI - you have to configure the driver on initialization...

I'm not going to go into debug here - let's just say, from what I've found, this might fix quite a few issues with 2.4 including IOT devices.

As a side note - found another issue with Avahi, but that's another discussion... that one might help out Linux/Mac/Windows as well for device discovery

 

[drinkingbird]

This one you can't disable from WebUI - you have to configure the driver on initialization...

I'm not going to go into debug here - let's just say, from what I've found, this might fix quite a few issues with 2.4 including IOT devices.

As a side note - found another issue with Avahi, but that's another discussion... that one might help out Linux/Mac/Windows as well for device discovery

Professional screen does let you choose between MCS7/N and MCS9/256QAM/TurboQAM. With Turbo enabled it advertises VHT capable and without it advertises HT capable. My draft-N device still can't connect with it disabled and not advertising 5.5 and 11 rates though, not really surprising, if it doesn't support Turbo or VHT it won't attempt to connect to it.

N only - disable b unchecked - Turbo
Mode: Managed RSSI: 0 dBm SNR: 0 dB noise: -87 dBm Channel: 10
BSSID: D0:17:C2:E2:7B:00 Capability: ESS ShortSlot RRM
Supported Rates: [ 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
VHT Capable:
Chanspec: 2.4GHz channel 10 20MHz (0x100a)
Primary channel: 10
HT Capabilities:
Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ]
VHT Capabilities:
Supported VHT (tx) Rates:
NSS: 1 MCS: 0-9
NSS: 2 MCS: 0-9
NSS: 3 MCS: 0-9
Supported VHT (rx) Rates:
NSS: 1 MCS: 0-9
NSS: 2 MCS: 0-9
NSS: 3 MCS: 0-9


Same without Turbo
Mode: Managed RSSI: 0 dBm SNR: 0 dB noise: -88 dBm Channel: 10
BSSID: D0:17:C2:E2:7B:00 Capability: ESS ShortSlot RRM
Supported Rates: [ 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
HT Capable:
Chanspec: 2.4GHz channel 10 20MHz (0x100a)
Primary channel: 10
HT Capabilities:
Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ]

 

[sfx2000]

Professional screen does let you choose between MCS7/N and MCS9/256QAM/TurboQAM

That does not fix the issue at hand.

WL commands do at init...

 

[drinkingbird]

That does not fix the issue at hand.

WL commands do at init...

Not suggesting it as a fix for anything, just observation. I've yet to have any device have any issue connecting with TurboQAM enabled, however I have seen various issues over the years when you mess with basic rates.

But turning off this option does get rid of the VHT stuff from the beacons at least, when you apply the setting it bounces the wireless.

 

[sfx2000]

Not suggesting it as a fix for anything, just observation. I've yet to have any device have any issue connecting with TurboQAM enabled, however I have seen various issues over the years when you mess with basic rates.

What broadocm is doing isn't legit with 802.11n as a default for devices period - it's not an Asus issue

It's down to the MAC framing and there, it doesn't directly show up in Wireshark - I had to turn up debug on my ath9k and intel wifi drivers and caught it.

I initially thought it was an auth issues, but the handshake actually completes - and if we go open, without WPA getting in the way, the issue becomes clear after the attach request/response...

The client stops responding from an AP perspective, so hostapd declares a detach - there's a bit of a race condition, as you also get info from wpa_supplicant. Reason there is because the attach is already lost...

 

[drinkingbird]

What broadocm is doing isn't legit with 802.11n as a default for devices period - it's not an Asus issue

It's down to the MAC framing and there, it doesn't directly show up in Wireshark - I had to turn up debug on my ath9k and intel wifi drivers and caught it.

I initially thought it was an auth issues, but the handshake actually completes - and if we go open, without WPA getting in the way, the issue becomes clear after the attach request/response...

The client stops responding from an AP perspective, so hostapd declares a detach - there's a bit of a race condition, as you also get info from wpa_supplicant. Reason there is because the attach is already lost...

That's their way of punishing anyone who doesn't use broadcom wifi chips in their devices also.

You'd think disabling VHT support and bouncing the driver would eliminate that "hack" but can't say I'm surprised it doesn't.