-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AP mode fails with 'timed out to flush queue 3' #151
Comments
I have an 8811cu and an 8812bu that should be arriving tomorrow evening and I can try to reproduce after they arrive. I will speak to @lwfinger later today and mull over this with him unless he starts working the issue before then and responds here. I will update you as soon as I can. @henkv1 Thank you for letting us know. |
First of all, I would like to introduce @brianwitte to this list. I recently placed a request on the Linux wireless mailing list for someone to co-administer the GitHub repos and to be trained when I am no longer able to do it. Brian stepped up, and I am pleased that he did. @henkv1 - How are you setting up the AP? I would like to repeat what you are doing using an 8821ce to see if the problem is with the 8821c chip, or just with the USB driver. |
@lwfinger, @brianwitte I use this guide as a base for my setup. It works fine with the Realtek drivers in that repository (but those drivers are out-of-kernel and not fully compliant). So I tried to use the rtw88 driver instead, but without luck, so far. |
Note that 8812bu is Wifi 4 (802.11n) hardware, and 8822bu is Wifi 5 (802.11ac). They are quite different. |
8812bu is capable of 802.11ac. When I use channel 36, the AP is visible, but I observe a lot of reconnects and the following error message in the kernel log of the AP: [27801.522737] rtw_8822bu 1-1.5:1.0: timed out to flush queue 3 The AP is not visible when I use channel 40. |
Hi, [ 324.869779] rtw_8822bu 1-1.4:1.0: timed out to flush queue 3 |
I have two different rtl8822bu USB dongles. Here I get the same error ("timed out to flush queue 3") as soon as I shut down hostapd, and I have similar symptoms (client connects, but connection drops). After some investigations, it seems that this is due to the rtl8822bu not sending beacons at all (I guess that the network can still be discovered due to probe responses). In my understanding the driver uploads a beacon template to the dongle in the so-called "reserved pages", ad its firmware is in charge to periodically sending it over the air, but it seems this mechanism isn't working here. In my case the reserved pages are apparently uploaded fine (i.e. no complaints - no "failed to download drv rsvd page" / "error beacon valid" messages). The rest of traffic seems to flow normally. I'm looking in this issue more in deep, but so far I have had no luck (I may also post on the kernel ML, but I need to collect and reorder some information first). |
Do not post to the kernel ML, but rather to the wireless ML as described in README.md. You are giving too much credit to the firmware. The beacons are generally triggered by hostapd. Only the contents of the beacon frame are stored. I suspect the fault lies with hostapd. Have you tried making an AP with NetworkManager? A quick fix would be to kill hostapd in a script that immediately unloads and reloads rtw88_8822bu. |
@andreamerello : Is 2.4Ghz working for you ? On my side, i only had the issue on 5ghz #112 |
I just found out that increasing the beacon interval in hostapd fixes the connection issues for me. Both 2.4 and 5 GHz are working with my rt8812bu adapter.
And this one:
|
On my side, neither 2.4GHz / 5GHz work. And configuring the network from network manager rather than hostapd didn't make any difference. So far, what I've understood is that from the driver side, the AP mode is enabled and the beacon is downloaded to the firmware. I've also tried to hack with some registers that are involved in beaconing process, but no luck. Finally I've noticed that the beacon TX descriptor seems incomplete to me i.e. the PCI driver does fill up a lot of extra stuff wrt the USB driver (e.g. rate, hw sequence number, broadcast flag, etc). I've tried to do the same in the USB code, but nothing changed. I will get back to do experimenting on this soon, and I will also try setting modify beacon interval. |
Tweaking beacon interval, as well as other hostapd parameters which I thought could affect beacon itself (e.g. IEs) didn't make any difference here. I see some commits that let me speculate me that AP mode worked correctly in some scenarios. I suspect that it is OK for PCIe cards, while I wonder whether is there any USB dongle that has no problem with it. If I could have more information on this, I could try to narrow down my experiments considering what's different in the code that supports working vs not-working cards. |
When I create the AP, 5GHz, channel 36. The AP is visible and I am able to connect. But when I generate some traffic, the connection drops and I see the following errors in the kernel log:
|
When I put my 8811cu and/or my 8812bu adapter in AP mode, the client is able to connect. But when it generates any traffic the connection drops.
On the AP I see the following message in the kernel log:
[ 1858.393929] rtw_8821cu 1-1.4:1.0: timed out to flush queue 3
This is my setup:
Raspberry Pi 3 with Arch Linux Arm 6.1.34-1-rpi-ARCH, aarch64. Latest rtw88 driver from this repository. Bridged ethernet. hostapd v2.10 and WPA2 authentication.
The text was updated successfully, but these errors were encountered: