Archer C7 v4 client compatbility in 19.07.8 vs 21.02.1

Installing and Using OpenWrt
1

TLDR: Are there controls in 21.02.1, perhaps not visible in Luci, that would affect Archer C7 v4 driver compatibility with low-end IoT WiFi devices?

I have a pair of Archer C7 (v4) used as access points for a number lots of SSIDs mapped to different VLANs. One of those SSID/VLAN pairs is a 2.4Ghz network for IoT devices from a variety of manufacturers. I use LibreNMS to ping the IoT devices regularly so I have a sense of how often they drop off the network.

Sometime shortly after its release I updated both APs to 21.02.1. Over time it I have had a general sense that some of the IoT devices are having more trouble since that upgrade. An OpenGarage device drops off the network several times a day. An Enel X Juicebox and Harmony Hub had more drops as well. These devices had been stable in the past.

Today the issue was made more immediate when I tried to add a new Chargriller grill controller to the IoT network. The grill's app connects over Bluetooth to present a list of 2.4Ghz SSIDs the controller can see. That presented list didn't include any of the SSID's from my APs. Attempts to tweak the AP settings had no effect. In particular it does not appear the channel width, encryption type, or legacy device options had any effect.

To try to isolate the issue I pulled out a third backup Archer C7 v5 and configured it as a simple AP with a testing SSID and no other networks. What I found was that the test SSID was visible to the grill if the Archer was running 19.07.8. Using that firmware I can configure the SSID otherwise identically to my main APs (40Mhz, WPA-PSK2, etc.) and have the grill work. However if I take that working device and configuration and upgrade to 21.02.1 it immediately stops working. Flashing back to 19.07.8 and restoring a backup restores functionality.

This leads be to believe that somehow 21.02.1 is somehow less compatible than 19.07.8 with low end WiFi devices. However, nothing stands out to me in Luci.

Are there some set of settings (perhaps outside Luci) I should be looking at here? Rolling back all APs to 19.07.8 doesn't seem like a long-term solution, but I suspect it will be a more stable IoT network, and I'd like the grill to work.

Thanks for any insights....

2

There is a setting in the 2.4 Ghz wireless config called Allow legacy 802.11b rates

The description states -

Legacy or badly behaving devices may require legacy 802.11b rates to interoperate. Airtime efficiency may be significantly reduced where these are used. It is recommended to not allow 802.11b rates where possible.

If the devices are being dropped due to inactivity, uncheck "Disable Inactivity Polling", and increase the value in "Station inactivity limit".

I have a couple of static devices that were getting kicked when I didn't want them kicked, so that solved it.

3

There is a setting in the 2.4 Ghz wireless config called Allow legacy 802.11b rates

Thanks for the suggestion, but that is not checked in the working 19.07.8 config, and adding it to the 21.02.1 config doesn't make a difference. I should note that the devices are all modern enough that they support 802.11g at minimum, so I don't expect them to need 802.11b.

If the devices are being dropped due to inactivity, uncheck "Disable Inactivity Polling", and increase the value in "Station inactivity limit".

I've used these options to reduce (but not eliminate) the flakiness for some existing devices (like the OpenGarage), but these shouldn't affect the grill controller. Its failing to even scan the SSIDs from 21.02.1, it hasn't associated yet, so its not eligbile to be dropped.

4

SSH into the router and run cat /etc/config/wireless.

Redact the passwords in the "option key" sections and post the results.

Then, run cat /etc/config/firewall.

5

/etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '36'
	option hwmode '11a'
	option path 'pci0000:00/0000:00:00.0'
	option htmode 'VHT80'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ahb/18100000.wmac'
	option txpower '20'
	option channel '6'
	option htmode 'HT40'
	option cell_density '0'
	option legacy_rates '1'

config wifi-iface 'wifinet0'
	option network 'lan'
	option skip_inactivity_poll '1'
	option ssid 'CharTest'
	option encryption 'psk2'
	option device 'radio1'
	option mode 'ap'
	option key 'testtest'
	option disassoc_low_ack '0'
	option wds '1'

/etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config include
	option path '/etc/firewall.user'
6

Doesn't look like you have the firewall fully configured, and minimal wifi.

Are you planning on using VLANs, or guest networks for the IoT devices?

Did you keep your config settings when you upgraded from 19.07.08 to 21.02.1?

The guidance is to re-configure from scratch, due to the change from swconfig to DSA.

7

Does disabling WDS have any effect on your IoT device visibility? If that helps, maybe configure two SSIDs. One for IoT and one for WDS link between APs.

8

The config posted above was minimal config built on a test device (I have a spare Archer C7) just to see if the grill would connect. It was created from a 19.0.8 config that worked for the grill upgraded to 21.02.1. I was trying to get down to a minimal test case.

That said, I did get it working, and it appears to be related to "Allow legacy 802.11b rates* as you suggested. What seems to work:

  • "Allow legacy 802.11b rates* must be enabled on 21.02.1. It was not necessary on 19.0.8.

  • The AP must be rebooted after Allow legacy 802.11b rates is enabled on on 21.02.1. Changing and saving the config live did not work (this was done several times, and is why I thought it unrelated).

It may also have been necessary to change the country to "US" (again not necessary on 19.0.8), but I cannot be sure as I made that change in parallel with the reboot.

Hopefully this will help someone else, my general impression is that 21.02.1's drivers are a lot less forgiving than 19.0.8. I'm not completely sure what "Allow legacy 802.11b rates* means in the context of the different drivers, but happy to have it working.

Thanks for the help!