What's new

Galaxy A51 phone keeps dropping WiFi

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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
 
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 ]
 
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.
 
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...
 
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.
 
Similar threads

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top