I only have problems with my smartphones and with the vacuum cleaner robot wifi.
On the network side (Ethernet), everything runs well and smoothly.
@Cookie, glad the settings helped.
I just rechecked my WRT1900AC setup notes, and I forgot to add the setting for the 2.4GHz radio:
- Select "Allow legacy 802.11b rates" for 2.4GHz devices such as some Android phones to be able to authenticate to network.
I was also having issues with my 2.4GHz Android devices not connecting, and found this tip on the forum here:
where the user claimed,
"They don't use 802.11b rates but without it no connection, with it they connect straight away, just no idea why this is needed..."
Cheers,
2Torr
1 Like
That reminds me that I'll have to test for that issue, too, when I get the chance to upgrade. The default for that setting is "unchecked" in relatively recent OpenWRT builds. Annoyingly, in the past, if it was checked, it broke Roku connectivity! Corroborating instances of this can be found in the Roku forums. I don't know if this still holds true in 21.02.
The default value changed between 19.07 and 21.02. Earlier it was on by default, now the default is off.
The legacy rate support option's default was intentionally toggled in late 2020, as enabling legacy rates (for ancient 802.11b connecting devices) hurts also other WiFi devices' speeds.
2 Likes
Thanks for the info. about possible Roku connectivity issues as well. I hope this issue is resolved in 21.02.1, but if not, perhaps this issue could be fixed with a mwlwifi driver update which would allow us to be able to use all our modern devices without compromising the transfer speeds?
2 Likes
A driver update is very unlikely to happen, which is discussed in the following, but, just to be sure, have you been following the WRT3200ACM & WRT32X thread where they've fixed a major issue on it in the 21.02 daily snapshots and the master for this family of devices? That was what I was talking about me needing to test. You should definitely test a 21.02 daily snapshot and/or the master to see if it solves your problems. The 21.02 daily snapshots are in a hidden directory, but someone can probably send you a link to it.
Thanks for the link! I misspoke earlier. I'm currently running v21.02.0, and I haven't kept up with the thread since 10/17/2021. I'll look into the latest snapshots over the holidays. 
Checking the "Allow legacy 802.11b rates" option made no difference for me. The one device that could not connect still cannot.
I'hava already compiled 21.02.1 complete with oopen
Please post your /etc/config/network and /etc/config/wireless
as well the output from ubus call system board
Which wifi are you using? 2.4GHz or 5GHz?
Ronny
Hi Ronny,
The issue is with 2.4GHz. I have one device that will not connect at 2.4GHz but it will connect at 5GHz, and it will also connect at 2.4GHz to a TP-Link Archer C7 running 21.02.1.
Requested file contents below.
Thanks and best regards ... Jack
# ---- ubus call system board ---
{
"kernel": "5.4.154",
"hostname": "wrt1900ac",
"system": "ARMv7 Processor rev 2 (v7l)",
"model": "Linksys WRT1900AC v1",
"board_name": "linksys,wrt1900ac-v1",
"release": {
"distribution": "OpenWrt",
"version": "21.02.1",
"revision": "r16325-88151b8303",
"target": "mvebu/cortexa9",
"description": "OpenWrt 21.02.1 r16325-88151b8303"
}
}
# ---- /etc/config/network ----
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'xxxx:xxxx:xxxx::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config device
option name 'lan1'
option macaddr 'xx:xx:xx:xx:xx:xx'
config device
option name 'lan2'
option macaddr 'xx:xx:xx:xx:xx:xx'
config device
option name 'lan3'
option macaddr 'xx:xx:xx:xx:xx:xx'
config device
option name 'lan4'
option macaddr 'xx:xx:xx:xx:xx:xx'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6hint '0'
list dns '208.67.222.222'
list dns '208.67.220.220'
option ipaddr '192.168.1.1'
config device
option name 'wan'
option macaddr 'xx:xx:xx:xx:xx:xx'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
option peerdns '0'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
option reqaddress 'try'
option peerdns '0'
option reqprefix '60'
config interface 'guestnet'
option proto 'static'
option netmask '255.255.255.0'
list dns '208.67.222.222'
list dns '208.67.220.220'
option ip6assign '64'
option ip6hint 'f'
option device 'wlan0-1'
option ipaddr '192.168.2.1'
config device
option name 'wlan0-1'
config device
option name 'eth0'
config device
option name 'eth1'
config device
option name 'wlan0'
config device
option name 'wlan1'
# ---- /etc/config/wireless ----
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'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option macaddr 'xx:xx:xx:xx:xx:xx'
option ssid 'xxx'
option encryption 'psk2+ccmp'
option key 'xxx'
config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path 'soc/soc:pcie@82000000/pci0000:00/0000:00:03.0/0000:03:00.0'
option htmode 'VHT80'
option country 'US'
option channel 'auto'
option cell_density '0'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option macaddr 'xx:xx:xx:xx:xx:xx'
option ssid 'xxx'
option encryption 'psk2+ccmp'
option key 'xxx'
config wifi-iface 'wifinet2'
option device 'radio0'
option mode 'ap'
option ssid 'xxx'
option network 'guestnet'
option encryption 'psk2+ccmp'
option key 'xxx'
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.