Archer C7 V2 and packet loss on 5Ghz

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello,

I tried a lot of thing I have found on this forum about this.

I use few Archer C7 and Archer C5 and R6100 in AP mode only, and on one Archer C7 I have so many crash with ath10k-ct so I migrated to ath10k but I have another issue with this module,

I don't have any crash but some clients have packet loss on 5 Ghz, restart WLAN on client solve issue.
I can't ping client, and client cannot ping the gateway when happen

Maybe a tweak ?

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

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'SSID'
	option encryption 'psk2'
	option key 'xxxx'
	option nasid 'C46E1F4FD519'
	list r1kh 'C4:6E:1F:4F:D5:1A,C4:6E:1F:4F:D5:1A,5468576D5A7134743777217A25432A46'
	list r1kh 'C4:6E:1F:4F:D5:19,C4:6E:1F:4F:D5:19,5468576D5A7134743777217A25432A46'
	option ieee80211r '1'
	option ft_over_ds '0'
	list r0kh 'C4:6E:1F:4F:D5:1A,C46E1F4FD51A,5468576D5A7134743777217A25432A46'
	list r0kh 'C4:6E:1F:4F:D5:19,C46E1F4FD519,5468576D5A7134743777217A25432A46'
	option mobility_domain '4f57'
	option r1_key_holder 'C46E1F4FD519'
	option ft_psk_generate_local '0'
	option ieee80211k '1'
	option ieee80211v '1'
	option wnm_sleep_mode '1'
	option bss_transition '1'
	option time_advertisement '2'
	option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
	option rrm_neighbor_report '1'
	option rrm_beacon_report '1'
	option pmk_r1_push '1'
	option disassoc_low_ack '0'
	option reassociation_deadline '20000'

There are around 8 clients on this AP

2

"don't have any crash but some clients have packet loss on 5 Ghz, restart WLAN on client solve issue."

Maybe it's just the 1 or 2 client devices that aren't roaming correctly? Many people never reboot or update their client devices maybe try that also? Try googling the client devices to see if they support 802.11kvr?

"Going A->B works perfectly, but since the client is never deauth/disassociated from A after the transition, going back to A before max_inactivity kicks in on AP A means the client will not reassociate to A, because A expects the old key and Client uses a new one I suppose (and it's still registered in the kernel, you can observe the infamous "Could not set STA to kernel driver" error until the client decides to re-do the entire handshake properly).
Lowering max_inactivity to 15 seconds allowed me to mostly work around this issue.
My guess it that this case is better-handled in WPA-EAP deployments, where one controller is in charge of the keys and does push/pull to the APs."

3

I don't see roam trace in logs for this client
Just lot of beacon request

il i filter them : I see only initial association en wifi 5 at 10:48

16-hostapd.log:2023-05-16T10:48:09+00:00 AP68-1 hostapd: wlan0: AP-STA-CONNECTED 00:6d:52:eb:99:e6
16-hostapd.log:2023-05-16T10:48:09+00:00 AP68-1 hostapd: wlan0: STA 00:6d:52:eb:99:e6 IEEE 802.1X: authorizing port
16-hostapd.log:2023-05-16T10:48:09+00:00 AP68-1 hostapd: wlan0: STA 00:6d:52:eb:99:e6 RADIUS: starting accounting session 83A6A2A73D7ADD96
16-hostapd.log:2023-05-16T10:48:09+00:00 AP68-1 hostapd: wlan0: STA 00:6d:52:eb:99:e6 WPA: pairwise key handshake completed (RSN)
16-hostapd.log:2023-05-16T10:48:09+00:00 AP68-1 hostapd: wlan0: EAPOL-4WAY-HS-COMPLETED 00:6d:52:eb:99:e6

And packet has dropped for 10 seconds at 12:53 UTC, no trace in logs.

I have second SSID without roam on Wifi 5Ghz too, and I have same issue, packets loss

config wifi-iface 'wifinet4'
	option device 'radio0'
	option mode 'ap'
	option ssid 'SSID_TEST'
	option encryption 'sae-mixed'
	option key 'xxx'
	option ieee80211w '1'
	option network 'WORK'
	option disassoc_low_ack '0'
4

I have another drop at 12:59

I see it on Grafana

image
image1509×694 94.5 KB

Seem to be global wlan0 interface without any throughput

wlan1 (2.4 Ghz) seems to be ok

5

You could try ct driver with the normal firmware.
I’ve more or less problems (almost stable-ish until it’s suddenly not, to downright unstable depending on context) with the ct firmware, but normal firmware with ct driver works great.

6

so
From fresh install
opkg remove ath10k-firmware-qca988x-ct
opkg install ath10k-firmware-qca988x kmod-ath10k-ct
?

7

Yeah, but you dont need the last part since the ct driver is already default.

(Or just use the online imagebuilder)

8

I have some error on boot

[   54.036013] ath10k_pci 0000:00:00.0: wmi print 'P 135 V 16 T 433'
[   54.049240] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
[   54.072764] ath10k_pci 0000:00:00.0: rts threshold -1
[   54.078921] ath10k_pci 0000:00:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4

But wifi is up, I will test this

`

9

Maybe all your USB 3.0 DJ stuff is interfering with the wifi. What about all the DMX512 noisy DC switch mode power supplies? What frequency are all your class D amplifiers running on? Try to provide at least 3-6 feet space between all devices if possible.

10

AP are isolated on wall.

I use dmx devices outside, not at home :slight_smile:

I tried the suggestion of non Ct firmware with Ct kernel module and no packet drop on 5ghz since this combinaison

1 Like
11

DTIM interval 3 important with IOS, I don't know why? Since I put this setting, no IOS disconnection on our large network

12

apparently because of Apple's power management:

Note that the article is quite old and might not be up to date. I myself have never hady any problems with the default setting of 2 (probably sometimes the default might have been 3 with other firmware though + the real value will also depend on beacon interval), and I've been through a lot of routers and i-devices through the years.

Here's another article that explains it as well
https://routerguide.net/dtim-interval-period-best-setting/

13

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.