It's strange - I had those "0 bytes received" appearance on multiple notebooks with an AX210NGW adapter the last days. When it occurs, it doesn't go away by itself.
I've now rebooted my two AX3600 units and it started working after setting mode=AX in Windows device manager for the wifi card.
I'll be on the lookout what my be the root cause here... currently I suspect the mesh SSID running in parallel to the SSID where the AX210 clients connect to. This is my config:
It's not about ignoring DFS. This thread is about wifi clients not able to connect via AX but only AC. This occured again some minutes ago and I don't understand why. It happens with HE80 or HE160 mode.
I have 5 SSIDs + 1 802.11s network all on one radio on my 301w with no issues connecting any clients, so I don't think your mesh net is an issue.
IIRC, 160MHz will always need a DFS channel to work (not sure about 80+80) as there is not anywhere on the spectrum 8 contiguous 20MHz channels outside DFS.
Thanks for sharing your experience :). So it's wrong to suspect the mesh. Came to this as a radio restart with unconnected mesh partner allowed to connect via AX. I'm currently totally compliant with dfs rules and using the correct country code so it's also not the client with a mismatched country.
Good point. in regards to the short preamble, this should really only be used if you have a perfectly clear enviornment, otherwise clients may have a hard time syncing. Otherwise, short preamble can slightly reduce sync times and therefore latency.
The ieee80211w option set to 1 means Protected Management frames are optional, so shouldn't be an issue.
Thank you two for the feedback... I'll try your suggested config improvements and then report back . Indeed, I'm living far outside town so there are no other wifi access points competing in range.
What about the short preamble 0 and turning off PMF? Do I need to also test this because in (client) AC mode devices connect fine and stay reliably connected. It's just the problem in AX mode (for the wifi 6 capable devices).
I can reproduce even with my latest not-yet-merged patch. But not on the two ipq radios, just the mt76 one.
But I can also reproduce with iwinfo 00aab871, so none of our patches.
So I guess your reporter tested also with the mt76 radio? Can he/she/them report with recent mt76 bump reverted?
The weird thing is that iw scans just fine. And sometimes iwinfo does too, but on the next run it doesn't. And iw always does. With iwinfo it also always works on the ipq radios.
I can poke it some more tomorrow, but this may be a mt76 regression and iwinfo doing something stupid >(but we didn't touch the stupid part with our patches).
I personally upgraded to the mastersnapshot from yesterday with my mt7621 + mt7915 + mt7975 device, which uses the mt76 driver (D-Link DAP x1860) and connect to it with my Intel AX200 Windows 10 client and it works fine so far (I wonder for how long :D). I do not experience the issues you describe with the Xiaomi AX3600.
When you are about to download a master-snapshot, have a look at the buildbots and check if your target has already been built with latest commit(s): https://buildbot.openwrt.org/master/images/#/grid