I have seen 1/2 hour ago. I have did recompile and now i have a different problem
Wed Aug 2 17:24:13 2023 daemon.err hostapd: nl80211: disabling multicast to unicast failed with -19 (No such device) on interface phy0-ap0
Wed Aug 2 17:24:13 2023 daemon.warn hostapd: phy0-ap0: Could not connect to kernel driver
Wed Aug 2 17:24:13 2023 daemon.err hostapd: Interface initialization failed
At developers, I've just tried the official regular OpenWrt master build (Non NSS) with latest Ath11k firmware WLAN.HK.2.9.0.1-01862 and the issue is absolutely reproducible every time for my setup described in the first post.
I've even tried with reset to default but no success either.
I've tried the official regular OpenWrt master build (Non NSS) with Ath11k firmware WLAN.HK.2.9.0.1-01385 too. There is no issue with it keeping the same settings and packages installed.
I can confirm this issue on wrt36 with snapshot build both with firmware WLAN.HK.2.9.0.1-01862-QCAHKSWPL_SILICONZ-1 and WLAN.HK.2.9.0.1-01837-QCAHKSWPL_SILICONZ-1.
I'm definitely seeing this same issue also with WLAN.HK.2.9.0.1-01385-QCAHKSWPL_SILICONZ-1.
I'm only changing firmware files, my system image is the same - snapshot r23636-ba7d6dddc7. @sppmaster If you are not seeing this with 01385, could it be that there are other variables in your setup, like you used different build with 01385 where you did not see issue?
No, there are no other variables. I use the same NSS image but just changed the firmware files in /lib/firmware/IPQ8074 then rebooted.
I've tried with regular OpenWrt (Non-NSS) build too. The same issue is present with it too.
The issue has been present for quite long time. The line number in assertion varies according to the firmware versions, but the remaining part is roughly the same (and naturally the underlying reason is similar, a device leaving AP).
Examples of the same:
I see that @Ansuel reported bugs for Ath11k.
Unfortunately I have one Xiaomi Smart Phone that frequently disconnects itself from the 5G network and its 2.4 WLAN is just awful and I cannot use it. Disconnecting frequently from the 5G WLAN it hits all other devices connected to it.
At least in my case the firmware doesn't crash.
Can you tell us what is your test setup. I've tested one more time extensively for more than 10 minutes sequentially running iperf3 tests on a Laptop and a Smart Phone and disconnecting two other devices from WLAN. I couldn't reproduce the issue with WLAN.HK.2.9.0.1-01385-QCAHKSWPL_SILICONZ-1.
Or at least it doesn't happen every time as with both later versions of the firmware.
There are other users that reported they don't see similar behaviour with the latest firmware version.
Probably there are some other factors that are not so obvious and may cause an adverse effect too.
Default radio settings, channel 149 (HE80), psk2. Nothing fancy.
I have around 10 clients connected, mostly Apple devices (Macs and iPhones).
The test is running ping to router from connected mac client and toggling WiFi off on iPhone.
Yes, it does not happen every time, but toggle WiFi enough and it will happen.
I have checked logs, nothing interesting. Ran hostapd with debug logging - also nothing of interest.
Also, just to be clear, I don't see such extreme interruptions as you reported. Interruption is usually around 1 second long or less. I would see pings going normal (under 10ms), then on client disconnect one ping taking anywhere from 300ms to timeout.
I am now using 1835 and it has run fine for a week without crashes or apparent interruptions.
((DL-WRX36, 23.05) but I only have 2 modern Samsung phones a Samsung tablet and an LG TV using the wireless (5GHz) so my network is lightly taxed.
I downgraded firmware on my wrx36 to WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1. It is very very hard to repro the issue with this older firmware.
From practical perspective this is definitely better than 2.9.0.1 firmware. Reproducing the issue on 2.9.0.1 is very easy just by togglig WiFi on/off on iPhone a couple of times.
As a reference to the issues in this thread and a workaround from this post I've tried the following.
I've just returned to the latest (at the moment) Ath11k firmware WLAN.HK.2.9.0.1-01862.
Rebooted the router and tested once again without multi to unicast option. Confirmed the loss of both Ping and Iperf3 traffic.
I've turned on multi to unicast option only for the 5G radio.
In wireless config it is option multicast_to_unicast_all '1'
I've tested once again with multi to unicast option turned on.
There is no more loss of both Ping and Iperf3 traffic if a client disconnects from the 5G WLAN.
There is a long discussion commenting this issue.
So I suggested in my earlier post these issues were connected. That is now confirmed, I think.
@egc, @asvio, @Catfriend1@Pow maybe you can try to use the workaround enabling multi to unicast option in wireless settings.
Hey @sppmaster
Since commit 549e710fc I've not had any more disconnection problems or network errors.
I think it's essentially due to the new implementation of the hostapd package but I'm not 100% sure.
I have done some tests enabling and disabling multi_to_unicast and in my case (nbg7815) I have not found any difference in performance and/or ping errors.
Since commit 549e710fc I've not had any more disconnection problems or network errors.
This.
I don't know what fixed this - hostapd upgrade, kernel upgrade or kernel patches but with latest snapshot (r23763-46ed38adeb) I'm not seeing this issue anymore. At least it is not easily reproducible as before.
I am also not seeing IPv6 connectivity issue that previously required multicast_to_unicast_all workaround or downgrading firmware to 2.7.0.1. It is too early to call this yet on the multicast bug as the group rekey interval for CCMP is day, so I want to keep running this for extended time to be certain.
One thing I noticed with latest snapshot is no ath11k errors in dmesg. Previously running wifi would always have these errors, something about flushing the ring or something, can't recall exact message.
I've flashed freshly compiled build with latest commits (kernel 6.1.46).
For me the issue is still there absolutely repeatable when multi to unicast is not checked.
The "workaround" option multicast_to_unicast_all '1' only masks the issue temporary but at one point it doesn't matter at all.
I'll continue to monitor how it goes/changes as time goes by.
Just an update. I have been running OpenWrt SNAPSHOT, r23763-46ed38adeb on wrx36 with ath11k firmware downgraded to WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 for two months (uptime 56 days) without problems.
Dual radio - channel 149 HE80 with sae-mixed encryption, channel 6 HE20 with psk2+ccmp encryption.