WiFi device only responds randomly

Installing and Using OpenWrt
1

I'm using a Xiaomi AX3600 that has 3 built-in radios (1x ath10k 2G, 1x ath11k 2G, 1x ath11k 5G).

On 2G my main SSID and an additional IoT SSID is being broadcast. To the IoT SSID a Yeelight Ceiling Light is connected that unfortunately only responds randomly.

64 bytes from 192.168.40.228: seq=0 ttl=255 time=6393.335 ms
64 bytes from 192.168.40.228: seq=1 ttl=255 time=5393.964 ms
64 bytes from 192.168.40.228: seq=2 ttl=255 time=4394.515 ms
64 bytes from 192.168.40.228: seq=3 ttl=255 time=3395.155 ms
64 bytes from 192.168.40.228: seq=4 ttl=255 time=2396.094 ms
64 bytes from 192.168.40.228: seq=5 ttl=255 time=1397.195 ms
64 bytes from 192.168.40.228: seq=6 ttl=255 time=397.929 ms
64 bytes from 192.168.40.228: seq=7 ttl=255 time=1331.469 ms
64 bytes from 192.168.40.228: seq=8 ttl=255 time=331.399 ms
64 bytes from 192.168.40.228: seq=9 ttl=255 time=2092.262 ms
64 bytes from 192.168.40.228: seq=10 ttl=255 time=1095.553 ms
64 bytes from 192.168.40.228: seq=11 ttl=255 time=96.005 ms
64 bytes from 192.168.40.228: seq=12 ttl=255 time=421.591 ms

It makes no difference if

  • both SSIDs are moved between the two 2G radios
  • no client is connected to the main SSID
  • the 5G radio is disabled

It works if

  • the same setup is run on an ancient WR841ND using OpenWrt 19.07 or the AX3600 stock firmware
  • the two SSIDs are split between the two 2G radios (no solution because ath10k will crap out after some time)
  • the main SSID on 2G is disabled

I first thought it was an issue with the ath11k driver but since moving both SSIDs to the ath10k radio yields the same result, that is ruled out. Also only the Yeelight is showing this issue. If I connect a phone or computer to the IoT SSID, it works just fine.


config wifi-device 'radio0'
	option type 'mac80211'
	option path 'soc/20000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
	option htmode 'HT20'
	option band '2g'
	option channel '1'
	option cell_density '0'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/c000000.wifi'
	option band '5g'
	option htmode 'HE80'
	option cell_density '0'
	option channel 'auto'
	option country 'DE'
	option ieee80211k '1'
	option bss_transition '1'
	option he_su_beamformer '1'
	option he_su_beamformee '1'
	option he_mu_beamformer '1'
	option disabled '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2'
	option key ''
	option ssid 'xx_5G'

config wifi-device 'radio2'
	option type 'mac80211'
	option path 'platform/soc/c000000.wifi+1'
	option band '2g'
	option cell_density '0'
	option channel '1'
	option htmode 'HE40'
	option country 'DE'
	option ieee80211k '1'
	option bss_transition '1'
	option he_su_beamformer '1'
	option he_su_beamformee '1'
	option he_mu_beamformer '1'

config wifi-iface 'default_radio2'
	option device 'radio2'
	option network 'lan'
	option mode 'ap'
	option ssid 'xx'
	option encryption 'psk2'
	option key ''
	option disabled '0'

config wifi-iface 'wifinet3'
	option device 'radio2'
	option network 'iot'
	option mode 'ap'
	option ssid 'xx iot'
	option encryption 'psk2'
	option key ''
	option disabled '0'

I tried various options but nothing helped and I'm at a loss here.

2

Do other devices on that network respond as expected?

This may be normal behavior for that light... typically, many IoT devices of this nature don't run their network adapter 100% of the time. Instead, they will sleep the radio for a while, wake up and listen for incoming connections/commands, then sleep again. This is an energy saving feature (even though it seems insignificant, it does add up, and also may be the default operating mode of the wifi module they have built into their light).

You can often see similar behavior when you ping a mobile phone, for example. When it is sleeping, it may have slow response tmes to pings (or even timeout for some), but will clearly respond at least to some pings. However, if you use the phone to ping something like a desktop computer or the router, the resposes will be normal - fast and consistent.

3

Every other devices works fine and also the Yeelight works fine if the main SSID is disabled or moved to the other 2G radio or on stock firmware or on an ancient WR841ND on OpenWrt 19.07.

It just does not work properly when both SSIDs are broadcast from the same radio, no matter if it's the ath10k radio or the ath11k one but at the same time broadcasting both SSID from the only WR841ND built-in radio is also working.

4

Maybe taking a step back... does the Yeelight respond to the commands (on/off, whatever other color/brightness controls that it has, etc.)? If so, the issue may be purely academic and not of practical importance. If it is not responding properly, obviously it is worth digging into.

5

And that is the issue. I started investigating when I found that the Yeelight responded to commands with a hefty delay that I'd never seen before. So it's not just the ping but any communication with the device that is affected.

I suspect it could be hostapd or some issue with the kernel or it is a bug in both ath10k and ath11k but I just don't know what else to try.