As you can see, legacy rates are not enabled in 19.07 on my router, and my vacuum cleaner is connected to my 2.4 GHz WLAN without any problems. So I think there is another problem in 21.02.
I miss the option legacy_rates '1' option in your 2.4GHz radio settings.
Correct. I had tried it, but when it didn't make a difference, I turned it back off.
BUT ... I just tried it again, and now the tablet can connect! This may have been an error on my part, before I may have neglected to do "Save & Apply" in LuCI.
I do see it now in /etc/config/wireless as well.
Thanks!
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'soc/soc:pcie@82000000/pci0000:00/0000:00:02.0/0000:02:00.0'
option htmode 'HT20'
option country 'US'
option channel 'auto'
option cell_density '0'
option legacy_rates '1'
1 Like
Sometimes that happens to me too.
Please, you're welcome. Glad that it now works for you.
Regards,
Ronny
I can officially say adding the following code to the local startup does decrease the latency on 5GHz:
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
However, my Motorola Moto G30 really is struggling to get past 150Mbps on the 5GHz channel despite the link speed being 433Mbps. On the other hand, the Moto G30 will complete an Ookla Speedtest at a lot higher speeds of 220~Mbps on my BT Smarthub 2.
I sometimes think it could be my phone because my older Uelefone Armor 8 phone has a fairly close benchmark score to the Moto G30 and yet that will complete Ookla Speedtests at 250Mbps on OpenWrt.
Thank you so much for your question and investigation! Your workaround just helped me a lot.
It's very confusing that the seemingly legacy option must be enabled to maintain the 2.4G wifi (authentication?). I have no idea but turn to the forum, and luckily find your thread.
Sorry for bumping this, but I was having this issue after upgrading to 22.03.0 and just upgraded to 22.03.2 to see if it fixed it but it did not. As others mentioned, enabling the legacy rates has resolved it so thanks for that. In my case the device that is failing to connect to 2.4GHz is a Sony Xperia XZ1 compact. It can connect to 5GHz ok as well as to several other OpenWRT APs.
I grabbed a packet trace with my sniffer and noticed that when legacy rates are disabled, the probe response packet from the AP contains the Extended Supported Rates Tag with a length of zero which Wireshark reports as malformed. When legacy rates are enabled, the Extended Supported Rates Tag has a valid length and valid data. I think my phone is rejecting the malformed Probe Response packet during the connection attempt since it never tries to associate.
Here's the bad Tag which is 2 bytes: 0x32 0x00
Tag: Extended Supported Rates: Undecoded
Tag Number: Extended Supported Rates (50)
[Expert Info (Note/Undecoded): Dissector for 802.11 IE Tag (Extended Supported Rates) code not implemented, Contact Wireshark developers if you want this supported]
[Dissector for 802.11 IE Tag (Extended Supported Rates) code not implemented, Contact Wireshark developers if you want this supported]
[Severity level: Note]
[Group: Undecoded]
Tag length: 0
[Expert Info (Error/Malformed): Tag length 0 too short, must be greater than 0]
[Tag length 0 too short, must be greater than 0]
[Severity level: Error]
[Group: Malformed]
Tag Data: <MISSING>
And here it is after enabling the legacy rates option: 0x32 0x05 0x24 0x30 0x48 0x60 0x6c
Tag: Extended Supported Rates 18, 24, 36, 48, 54, [Mbit/sec]
Tag Number: Extended Supported Rates (50)
Tag length: 5
Extended Supported Rates: 18 (0x24)
Extended Supported Rates: 24 (0x30)
Extended Supported Rates: 36 (0x48)
Extended Supported Rates: 48 (0x60)
Extended Supported Rates: 54 (0x6c)
I don't know what could cause this, but maybe this information is useful to someone.
I'm facing the same problem with a roborock vacuum cleaner. It doesn't connect to either 22.03.5 nor 23.05.0 even with legacy_rates enabled. I tried to sniff the packets with tcpdump filtered by the mac address of the vacuum cleaner, but no packets are being exchanged, so I feel like the problem is at the wireless link negotiation before the tcp/ip traffic. @mudlark how did you capture the packets?
This sort of study is best done with a third wifi device such as a Linux laptop which can monitor the packets on the air.
thanks for the hint. the problem was actually that it needed encrypted network, and I was trying with open one.
I currently use a Kali linux virtualbox VM with a simple atheros USB wifi dongle that supports monitor mode. I've also had success with ubuntu on laptops that have intel wifi chipsets as well as a variety of other random wifi devices/distros. Generally you just need to run something like
rfkill unblock all
ifconfig wlan0 down
iwconfig wlan0 mode monitor
ifconfig wlan0 up
iwconfig wlan0 channel 10
rfkill pulls control of the device away from the networkmanager. Sometimes you have to ifconfig up before changing modes and sometimes it has be down, depends on the device/driver. Once its in the right mode run wireshark. You should see all the low level wifi packets on the selected channel.
Kali linux comes with some aircrack tools that can also do the above automatically.
1 Like
The problem is (most likely) about the specific hardware, which has always been troubled with interoperability issues from the start - and has been abandoned by the company over half a decade ago. In case of problems, try some different wireless hardware, these mvebu routers are still very capable in a wired-only fashion, but their wireless side is a dead end. Some cheap 802.11ax capable mt7621a+mt7915DBDC running OpenWrt will offer a world of a difference here, starting for ~15 bucks new (dap-x1860, covr-x1860, wsm20, …) or (much-) better.
2 Likes
