Mediatek MT7925 WiFi7 NIC - MR56 sends "Status code: Association denied due to requesting STA......"

[thomasthomsen]

Im currently troubleshooting a new laptop that cannot connect to MR56 AP.

Its clear that it fails association from packet captures, the AP responds with:

"Status code […]: Association denied due to requesting STA not supporting all of the data rates in the BSSBasicRateSet parameter, the Basic HT-MCS Set field of the HT Operation parameter, or the Basic VHT-MCS and NSS Set field in the VHT"

The fun thing is that if we set the driver to run 802.11n only, it can actually associate and get on the network just fine.

Have anyone else seen this problem ?

(And of course, since its Mediatek (or Qualcomm or Realtek, im also looking at you) you cannot go look for a newer driver on their website).

Thanks

Thomas

[alemabrahao]

What is the minimum bitrate setting?
Try disabling VHT/HE mode.

[thomasthomsen]

Min. bitrate is 12Mbit on all SSIDs.
But it does not seems to be the basic datarates thats the problem, since it can connect if we force it down to 802.11n.

Its very strange.

[alemabrahao]

What about disabling VHT/HE mode?

[thomasthomsen]

There is no option, like in your example picture, on this NIC.

But Im guessing setting it to 802.11n disables VHT and HE modulation schemes. (802.11ac and 802.11ax)

And if we do this the client will connect, of course only with HT (802.11n) schemes.

All other clients works perfectly, just not the MT7925 NIC.

I have packetcaptures of the client trying to connect, but I cant quite figure out the difference between that and one that works perfectly, there are differences but no "smoking gun", except the AP sending the above Association denied.

[cmr]

I'm guessing that the NIC is trying to use an MCS table entry that is beyond the MR56, do you have an MR57 or CW916/7x AP that you could try and see what bitrate it connects at?

[thomasthomsen]

I have done packet captures, but I cannot find that it tries anything that is beyond the APs capabilities.
When we force it in the drivers to 802.11n it can connect, using anything above.
802.1ac , or ax or even with everything on including .be, it just does not connect.
I mean, if it was a .be issue it should still be able to connect with ac or ax on.
Perhaps I should post some of those packetcaptures.

[thomasthomsen]

I dont look at wireless captures that often, it bascially only happens every 2 to 3 years that there is a client (or AP) that behaves so strangely that we need captures.

[GIdenJoe]

Aaah good old Mediatek and their drivers..... 😜

It might be a good idea to try to capture the beacon, probe req/response and assoc frames to see what the laptop is sending in it's MCS rates.

I believe there will be some necessary MCS'es missing in one of the protocol versions.  Also check if it has the 6,9,12,24,36,48,54 datarates supported.

[thomasthomsen]

Yep. I hate all those makers of wireless NICs where you cant go directly to their website to get the latest drivers to try out ... I think it is basically only Intel where you can do that these days.
Realtek, Qualcomm, and ... sigh , Mediatech , not so much. - Try to find a laptop or motherboard with that NIC and hope that vendor A has a newer driver then vendor B on their website.
Yes there are "sites" out there offering drivers, but I quite certain that this is how you get ants ... I mean malware 🙂

I have packet captures of a client trying to associate, and that is where I got the above "deny" from.
But I just cant see any MCS information inside those frames being different then from a client that connects just fine.
The annoying thing is that the MT7925 is the only Wi-Fi7 NIC Im currently myself missing in my lab.
I have Intel, Realtek, Qualcomm, but not the MT7925, and of course this is the one one of my customers have, and where there is ... trouble.
Its so strange.

[GIdenJoe]

Let me tell you an anekdote from a few years back.

About 3 to 4 years ago I bought an Acer laptop for my wife which apparently had a Mediatek wireless adapter.

The issue I had was actual packetloss (ping loss) when moving the lid of the laptop or the laptop itself.  The move could be 10 cm or a few mm.  At the moment of moving the pings just got lost.  My work laptop next to it having an AX chipset didn't show any hint of loss.  Also the AP was 4 meters away and in direct line of sight.

Since it was based on movement I first suspected a hardware issue but wanted to test first.

I first tried the newest driver that was available on the Acer support side.  Did not help.
I then tried the newest driver I could find from the vendor site itself.  Did not help.

Finally on some eastern european site by using the device ID I could find an even newer driver and that fixed the issue.

[thomasthomsen]

I know ... I have similar experiences with the mentioned vendor(s) 🙂