RTL8814AU AP mode error #271
Comments
|
I have tested the new driver against Arch Linux which is using the latest kernel 6.12.6 and tried building the package from https://aur.archlinux.org/packages/rtw88-dkms-git which will always use the latest commit from this github repo. And I was able to connect to the Wi-Fi and use it. I didn't tried any form of pentesting yet with this new driver. But I think I will report very quickly when I get free time. |
@chaoyanggo Are you trying to use it in AP mode and station mode at the same time? |
|
@dubhater Station mode can, AP mode cannot connect. |
|
[ 436.943268] rtw_8812au 2-1.4:1.0: error beacon valid @dubhater Is it possible to block this error message? |
|
No, we need to fix the problem. |
|
I am setup here to test AP mode. I can switch over to testing AP mode with this new driver in a few hours but I will wait for you to tell me how you set up AP mode so that I can look at duplicating it getting close. If using hostapd, please post your hostapd.conf. |
|
In @chaoyanggo 's last message, his post indicates rtw_8812au, not rtw_8814au. Just pointing this out. |
|
I have been testing AP mode for 2 days now... or rather trying to test it. The problem that I am seeing is that client systems will not connect. It shows a good interface: The problem is showing like an authentication failure. I am going to work with the hostapd.log to see if I can get more information. |
|
Those "Modules linked in" messages are probably part of some warnings. Are they from rtw88? |
No. My bad... drivers/gpu/drm/drm_gem.c I don't know why RasPi continues to source from Broadcom, a company well known for its poor Linux support. FYI: I have been looking in the hostapd.log file and it is still not obvious to me why this is not working. The hostapd setup is a known good setup. AP mode comes right up. I can see the ssid. The problem happens when when negotiation fails or so it would seem. Could this be a problem on my end? Yes. I will keep working it until I have a good idea what the problem is. |
|
@dubhater Sorry, I haven't had time to test the network card recently. My problem is the same as his |
|
I have tried everything I know to make AP mode work with rtw_8814au. None of the logs are help. It won't even connect if I turn security totally off. What I finally did that may be of some help is I changed out the rtw_8814au adapter for a rtw_8822bu adapter. The rtw_8822bu adapter allowed connections immediately. WPA3, WPA2 and Open. The reason that I picked this adapter is that I guessed that the code might be closer to the rtw_8814au than any of the others. |
|
Maybe it works now. |
Thank you for your efforts |
|
Now AP mode works. Thanks. I tested with WPA3: |
|
I am running into some issues with AP mode. Here is the short version: I bring up the rtw_8814au based adapter. It works fine for various periods of time from maybe 10 minutes to over an hour. Then no more packets and a log that looks like the following: I tested multiple times to today with setups from 5 GHz, WPA3 and 80 MHz channel width to 2.4 GHz, WPA2 and 20 MHz channel width. This problem has happen every time but the time from bringing the AP to dead in the water varies. I have rechecked hostapd.conf settings and even changed settings. I can't recall ever seeing a problem in the log that looks like this. When you can, test for long periods and see if you are seeing the same thing. |
This problem has been a long time, not only this network card has this error, but also the entire rtw 88 network card has this problem. But I observed for a long time this error does not affect the normal operation of the network card |
Are you saying that you see the same lines in the log yet the AP continues to operate? There is no continue to operate here. When I see those lines in the log, down goes the AP and there is no recovery.
You have seen this problem with other drivers in this rtw88 repo? If so, which chipsets? I think I am going to test AP most with a rtl8812au based adapter to what I can see. |
|
@morrownr |
|
That makes it look like this problem is not specific to a particular chip/driver. I do not remember this when testing the rtl8812au and rtl8821/11au drivers. |
|
Although he had this error, it worked well except for 88xxbu |
|
I just tested rtw_8812au. Same thing. When those lines start happening here, it is over. The only way to get AP mode working again is a reboot. |
|
23044.188799] rtw_8822bu 5-1:1.0 wlan7: left allmulticast mode 8822bu 8812bu AP mode works, but there are some packet dropouts |
|
I have been testing rtw_8822bu this morning. Here is what I saw: AP mode went down faster with the rtw_8822bu driver than any of the others. |
|
@morrownr You are using the Raspberry Pi as a host, right? Can you try some x86 computer instead? |
That is correct. It is a RasPi4B and is setup to be a dedicated AP testing system.
I can. It may take a few days as I need to figure out which system to use and set it up. Any thoughts on what distro to use? Debian 12 is okay? |
|
The same one you use on the Raspberry Pi. |
|
This is a ARM64 A53 Ubuntu LTS system 64bit system I made a short test on RTL8723DU RTW88 module-based driver. I can connect to the AP via my PC and my board directly. The AP config iscat /etc/hostapd/hostapd.conf Here is the ping:Pinging 192.168.175.1 with 32 bytes of data: Ping statistics for 192.168.175.1: And I also see the message.But only ONE time at the very beginning of the server create. [ 618.964688] rtw_8723du 1-1:1.2: error beacon valid Here is the short iperfs -s and linked with my PC[ 5] local 192.168.175.1 port 5201 connected to 192.168.175.86 port 52122 |
|
I also tested the RTL8821CU USB dongle on A53 ARM64 board. DriverSetup[ 155.394898] rtw_core: loading out-of-tree module taints kernel. The AP Setup
Using interface wlan0 with hwaddr 48:8f:4c:90:16:0a and ssid "AP-NAME" Observed IssueAt the middle of iperfs the connection suddenly drop and keep running. Pinging 192.168.175.1 with 32 bytes of data: Ping statistics for 192.168.175.1: So I tried to disconnect the AP and reconnect to the AP via PC. [ 261.926720] efuse thermal meter is 0xff And there is still some random loss in the link as this proposed [ 5] 143.00-144.00 sec 0.00 Bytes 0.00 bits/sec 1 141 KBytes iperf3 Before reconnect and stuckiperfsAccepted connection from 192.168.175.86, port 64302 iperfs after reconnectiperfs[ 5] local 192.168.175.1 port 5201 connected to 192.168.175.86 port 49629 |
That needs to be wpa=2 . See the hostapd docs. |
|
What happen will it do when wpa=3? Just wondering. |
|
I followed @morrownr suggestion and replaced the wpa=3 to wpa=2 and the result for: A35 ARM64 AP <-> PC directly and iperf3 test No more the message like these, so maybe it is caused by wrong wpa setting.[ 618.964688] rtw_8723du 1-1:1.2: error beacon valid But there are still unconditional drop like theseiperf3 RTL8821CUServer listening on 5201Accepted connection from 192.168.175.86, port 56460 [ ID] Interval Transfer Bitrate Retr iperf3 RTL8723DUServer listening on 5201Accepted connection from 192.168.175.86, port 57752 [ ID] Interval Transfer Bitrate Retr iperf3 RTL8822BUServer listening on 5201Accepted connection from 192.168.175.86, port 64544 [ ID] Interval Transfer Bitrate Retr iperf3 RTL8812AUServer listening on 5201Accepted connection from 192.168.175.86, port 52877 [ ID] Interval Transfer Bitrate Retr |
|
I had test the RTL8822BU USB dongle with 3.0 on the ARM64 A53 board. Sure it is USB 3.0 both HW and usb tree message. I do see a better link result on STA finally got a good >190Mbps speed. Now I do see a lot of these messages during testing iperf3 DUT to PC. The full report can be found here. https://github.com/briansune/rtw88-hw/tree/main/rtl8822bu_arm_a53 dmesg<\details> |
This has been a problem for a long time |
|
I am just start using start turning back to use RTW88 driver on most devices. BTW I had tried on A35 64bit ARM and issue found again and case is even worst that the connection is dead. As for STA all A9, A35, A53 have similar speed ~20-30Mbps. See report: It sound like this issue is introduced by kernel version? |
|
I had also follow your guidances on RTL8811AU using driver 88xxa, 8811a, 8821au driver. Just tested on A9 32bit. The report is here: https://github.com/briansune/rtw88-hw/tree/main/rtl8811au_arm_a9 The speed test is bad via Ookla only < avg(25Mbps) As for the AP completely dead and cannot work properly. |
|
@dubhater @morrownr @chaoyanggo I had tested the rtl8814au pcba and i cannot see issue on ap and sta. Ookla speed can go upto 233.50Mbps. Here is the report: |
|
Interesting that AP mode works with this one but not the others. |
|
I am not sure why (know very less on software) Here are the reports for rtl8811au on A9 and A35. AP not working Here is the report for rtl8811cu on A9 AP working properly w/o those trouble message but interestingly the STA cannot work =/ |
|
I finally discover a repeatable method to degrade and trigger those trouble message. If my PC is turned on bluetooth and listen to music during the AP test. DUT <-> PC (no router). So do there are any thing causing BT coex fighting with the WIFI? |
|
Ah, yes, the RTL8814AU, RTL8821AU and RTL8811AU have trouble receiving anything in the 2.4 GHz band, even beacons, when Bluetooth devices are streaming music nearby. I don't know if anything can be done to fix it. |
I agree with this. There actually messages all over the internet about this problem. This is not the only kind of interference that can affect bluetooth and WiFi 2.4. USB3 cables and connections can interfere as well... especially if you have an external ssd on a USB3 cable. Whew. The best solution is probably to look at how you have things setup. At the location you are using BT to stream music, don't have an 2.4 WiFi. Use 5 GHz at that location and 2.4 in other locations that are far away from the BT device. Separation is the best way to mediate this problem. |
|
How could this even allow when there is only 2.4G Channels to use? What a sad thing to know =[ |
Actually, the more you know, the better you can handle it. One of the basic filters that I use over at my site to help select adapters for the Plug and Play List is In my house, at the workplace where I listen to BT music, I only use 5 GHz WiFi. Several other locations in the home make heavy use of 2.4 Ghz but they are all away from the BT. Here is some lite reading: |
|
First thank you for the enclosed document from Intel. So I deeply get your point on interference. However what I am pointing out are: The RTL8814AU only have USB 2.0 and 2.4G channels to use, how can you even work with such physically filtering? And also with RTL8812AU dongle and RTL8811AU as well. They all uses USB 2.0 unless hardware modification see my reports images on the dongle hardware (PCB components). Meanwhile, most stamp-based PCBA are USB 2.0 so you are just telling us that the option on all w/o 5G embedded devices are no hope on using RTW88. |
That is somewhat different than my knowledge of the rtl8814au chip. The adapter that I have that uses the rtl8814au chip definitively has 5 GHZ WiFi and USB3. In fact, it can do 3 streams if your AP or router supports it. |
|
See report image and the PCBA to understand more. For all RTL88 [2|1] 1 [A|B|C] U aka USB-based chips if first is 1 then no BT and all of them can design to work with 5G as well. If you had more understanding on USB 3,0 port A then you are sure that behind the 4 pins there are additional pins, So it is not a general idea on RTW88 to only resolve such issue via 5G from the beginning. Same as the RTL88 [2|1] 1 [A|B|C] S aka SDIO-based chips which only the different is the physical interface. The point here is showing that if USB2 is the only speed that is using then using 5G is not worth as the 5G speed is complete bottle-necked by the interface itself and the only usage as you also proposed is to sperate things and to reduce interference. |
|
I made reply on the previous a lot so I split it into two sections. As you had more experience on room and spaces. Then you are also very sure that the inherent design on RF is to reduce range vs increase bandwidth. If you do a simple google on 5G vs 2.4G what is the basic different is that https://kb.netgear.com/29396/What-is-the-difference-between-2-4-GHz-5-GHz-and-6-GHz-wireless-frequencies So I don't think when designing products will remove 2.4G from the first equation as 2.4G is the final straw to maintain connection with all housing, antenna, transmission path loss etc. |
I had done a quick test on the frequency band. What If RTW88 reduce most priority on collision band between BT and WIFI 2,4G. During I tested on RTL8812BU on STA. As we all agree that 2.4G will affected by BT devices. Then what if AP&STA only uses those BANDs that have zero chance to collide aka odd # channel 2.4xxxG+1,3,7,9 etc. I do a quick test on 2.4G band on channel no. 8, the speed is completely almost same no BT device cases. I cannot see any affection on BT devices. |
[ 469.416829] device wlan2 left promiscuous mode
[ 469.417273] br-lan: port 3(wlan2) entered disabled state
[ 475.069246] usb 8-1: USB disconnect, device number 2
[ 479.077313] usb 2-1.4: new high-speed USB device number 4 using xhci-hcd
[ 479.253939] rtw_8814au 2-1.4:1.0: Firmware version 33.6.0, H2C version 6
[ 479.541897] usb 2-1.4: USB disconnect, device number 4
[ 479.825187] usb 2-1.4: new high-speed USB device number 5 using xhci-hcd
[ 479.989986] rtw_8814au 2-1.4:1.0: Firmware version 33.6.0, H2C version 6
[ 537.957925] device wlan0 left promiscuous mode
[ 537.958544] br-lan: port 4(wlan0) entered disabled state
[ 540.035678] br-lan: port 3(wlan0) entered blocking state
[ 540.036182] br-lan: port 3(wlan0) entered disabled state
[ 540.037769] device wlan0 entered promiscuous mode
[ 540.038680] br-lan: port 3(wlan0) entered blocking state
[ 540.039178] br-lan: port 3(wlan0) entered forwarding state
[ 540.812057] br-lan: port 3(wlan0) entered disabled state
[ 540.813272] br-lan: port 4(wlan4) entered blocking state
[ 540.813748] br-lan: port 4(wlan4) entered disabled state
[ 540.814522] device wlan4 entered promiscuous mode
[ 542.171917] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 542.172907] br-lan: port 3(wlan0) entered blocking state
[ 542.173392] br-lan: port 3(wlan0) entered forwarding state
[ 543.246540] IPv6: ADDRCONF(NETDEV_CHANGE): wlan4: link becomes ready
[ 543.247432] br-lan: port 4(wlan4) entered blocking state
[ 543.247922] br-lan: port 4(wlan4) entered forwarding state
[ 543.780563] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 567.316346] device wlan0 left promiscuous mode
[ 567.317575] br-lan: port 3(wlan0) entered disabled state
[ 570.096217] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 570.141142] br-lan: port 3(wlan0) entered blocking state
[ 570.141627] br-lan: port 3(wlan0) entered disabled state
[ 570.142382] device wlan0 entered promiscuous mode
[ 570.142906] br-lan: port 3(wlan0) entered blocking state
[ 570.143375] br-lan: port 3(wlan0) entered forwarding state
[ 578.381821] rtw_8814au 2-1.4:1.0: error beacon valid
[ 578.382558] rtw_8814au 2-1.4:1.0: failed to download drv rsvd page
[ 578.383117] rtw_8814au 2-1.4:1.0: failed to download beacon
[ 590.165371] device wlan4 left promiscuous mode
[ 590.165983] br-lan: port 4(wlan4) entered disabled state
[ 590.724246] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 591.447360] br-lan: port 4(wlan4) entered blocking state
[ 591.447863] br-lan: port 4(wlan4) entered disabled state
[ 591.448743] device wlan4 entered promiscuous mode
[ 593.509199] IPv6: ADDRCONF(NETDEV_CHANGE): wlan4: link becomes ready
[ 593.510106] br-lan: port 4(wlan4) entered blocking state
[ 593.510593] br-lan: port 4(wlan4) entered forwarding state
[ 594.020382] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 595.204219] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 597.476245] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 599.620276] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 601.512189] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 617.572165] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 637.060145] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 658.659913] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 678.179951] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 690.947836] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 698.499769] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
[ 708.643824] rtw_8814au 2-1.4:1.0: failed to get tx report from firmware
6.1.120 kernel build
I can search for wireless signals, but I can't connect to them.
The text was updated successfully, but these errors were encountered: