(solved) AP Mode working!

[morrownr]

A pull request was submitted and merged today by @MatteoPaier in the 8814au repo. It appears that the same problem is applicable to this repo so I have merged the fix here as well. Early results look promising.

I am requesting everyone that has an interest in AP Mode to test and report here in this issue.

Regards,

Nick

[henkv1]

Hi Nick, Thanks for your hard work. The issue I have with AP mode is that a few meters away from the AP, the signal strength is pretty good. But the connection speed on my Android phone and tablet drops to zero. At least in 2.4G mode. This patch does not change this behavior.

[morrownr]

Hi henkv1,

Thanks for the report. What you are describing is the primary problem we have seen with this driver in AP mode. The AP mode simply crashes dropping throughput to zero effectively making AP mode worthless. I'd like to test a setup as close to what you have as possible later today if I can get you to share some details.

What OS and version? Hardware? Software? hostapd? Configuration?

I see you are running 2.4G.

Any info helps.

[henkv1]

My system runs Arch Linux ARM on a Raspberry Pi 3 (but I have the same issue on a Pi 4) 32 bit. I also have a second AP in the same network, also running Arch Linux ARM on a Pi but with a ath9k wifi adapter. Roaming works pretty well when I come from the ath9k AP, but not the other way around, because of the network throughput dropping to zero while the signal strength is still fine.

I do not experience this issue when I use 5G, but the wireless range is very limited then.

Software versions: Linux 5.10.36, Hostapd 2.9, WPA-EAP authentication with FreeRadius 3.0.21.

Hostapd.conf:

interface=wlan0
bridge=br0
hw_mode=g
channel=7
# hw_mode=a
# channel=157
# ieee80211ac=1

require_ht=1
require_vht=1

ignore_broadcast_ssid=0
macaddr_acl=0
wpa=2
ieee80211n=1

bss_load_update_period=50
country_code=nl
ieee80211d=1
ieee80211h=1

rrm_neighbor_report=1
rrm_beacon_report=1

beacon_int=20
dtim_period=2
max_num_sta=32
rts_threshold=-1
fragm_threshold=-1
send_probe_response=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wmm_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0

auth_server_addr=192.168.1.110
auth_server_port=1812
auth_server_shared_secret=secret

wpa_key_mgmt=WPA-EAP

ieee8021x=1
wpa_group_rekey=86400
eap_reauth_period=0
wpa_disable_eapol_key_retries=0

group_cipher=CCMP
rsn_pairwise=CCMP
wpa_pairwise=CCMP
ssid=wifi
rsn_preauth=1
rsn_preauth_interfaces=br0

ft_over_ds=1
ft_psk_generate_local=0

iapp_interface=br0

nas_identifier=ap1
mobility_domain=a1a1
r0_key_lifetime=10000
reassociation_deadline=1000
pmk_r1_push=1

[morrownr]

henkv1,

Thanks for the info. I have been able to reproduce your result on 2.4 GHz. After about 20 seconds of iperf3 pushing the AP, AP mode crashes and drops offline. So, it appears the patch is working for 5 GHz but not for 2.4 GHz on this driver. Now to do additional testing to see if I can determine why.

Separate subject: I use RasPis also. My RasPi4b serves as an AP. Something I stumbled across is the ALFA AWUS036ACM adapter and it works wonderfully with the RasPi. I primarily use it with 5 GHz but would not mind at all testing on 2.4 GHz if you are interested in a report. My RasPiAP with the ALFA is so stable that it is truly a 24/7/365 device.

[henkv1]

Hi Nick, I think your issue is different from mine. I don't see an AP mode crash, only a drop in network traffic on the client (the client stays connected and the signal strength is fine) when I am a few meters away from the AP (or behind a concrete wall) . When I approach the AP again, the network traffic comes back.

I am also unable to reproduce the crash with iperf3. What options do you use?

[morrownr]

I am probably using the wrong words to describe what I am seeing. What you are describing is what I am seeing as well. The wifi signal remains available but the ability to push data crashes and burns.

iperf3 -c 192.168.1.41 -t 120

Note that I am forcing iperf3 to work 120 seconds because the "crash" usually doesn't happen until 20 to 30 seconds into an iperf3 session.

Edit: FYI: 2.4 Ghz is working on the 8814au driver.

[henkv1]

I was unable to reproduce the iperf3 'crash', but the connection speed drops really fast when I am moving away from the AP.

[morrownr]

Is that with 2.4 GHz or 5 GHz?

[henkv1]

2.4 GHz

[morrownr]

Okay, Let me come up with a plan to do some good testing on 2.4.

[henkv1]

Maybe it's just an hardware issue. The device was cheap after all.

[morrownr]

You could be right. I have more than one 8812bu based adapter so I will see what happens with another adapter. 5 GHz is rock solid now. I am only seeing a problem with 2.4.

[morrownr]

Update: The problem with the 2.4 GHz band in AP mode is evidently not hardware related. I went to defaults on all of the module parameters and 2.4 is working fine. Now I need to figure out which parameter is the problem so I can document it.

This is cool. AP mode working well.

[henkv1]

This is great news. Please let me know when I can test it.

[morrownr]

I narrowed the issue down to this module parameter: rtw_switch_usb_mode=

The default was 0 which meant no switch would take place. I had changed the setting to 1 so as to activate USB3 mode. That is what I do if the adapter is a USB3 capable adapter and the port is USB3 capable. That works with the 8812au and 8814au drivers in both bands. Evidently we need to use 1 for USB3 with 5 GHz and 2 for USB2 for 2,4 GHz with this driver. I can't see why in the code but I tested and tested and that is what seems to work consistently.

Please do test to see if you can verify or disprove my results. Also, I merged a change to the default rtw_switch_usb_mode= setting in 88x2bu,conf. I changed the default from rtw_switch_usb_mode=0 to rtw_switch_usb_mode=2. Think about that and tell me what you think.

Thanks,

Nick

[henkv1]

Hi Nick, Thank you. It looks like this fixed the issue! One question: do I need rtw_switch_usb_mode=2 for 2.4 GHz even if I put the device in a USB3 port?

[morrownr]

Quote: "do I need rtw_switch_usb_mode=2 for 2.4 GHz even if I put the device in a USB3 port?"

Reply: Yes.

If you are going to be running an AP with the 2.4 GHZ band and you have time to experiment with different ports and different settings, please do.

I'm not seeing this issue with 2.4 GHz on the 8814au driver that had the same problem and the same patch applied. The 8812au driver never had the problem so the patch was never applied there. I've used meld to compare the code in the 3 drivers we are talking about and it isn't clear to me why the difference.

In my testing yesterday, I came away with the option that this driver has very good support for 5GHz AP mode now. It seems to work really well. It still needs to be tested long term because AP mode needs to be stable 24/7/365.

[morrownr]

After considerable testing, I am going to declare AP mode fixed. I am working on a document that will be made available here in the repo that provides the steps to setup a wireless access point. In it will be the following:

Note: For USB3 adapters based on the Realtek rtl8812au, rtl8814au, and rtl8812bu chipsets, the following module parameters may be needed for best performance when the adapter is set to support 5 GHz band:

rtw_vht_enable=2 rtw_switch_usb_mode=1

Note: For USB3 adapters based on the Realtek rtl8812au, rtl8814au, and rtl8812bu chipsets, the following module parameters may be needed for best performance when the adapter is set to support 2.4 GHz band:

rtw_vht_enable=1 rtw_switch_usb_mode=2

[YudinIgor]

Good day. How to set up two WiFi cards rtl8812bu (usb 3) ?

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub Bus 002 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet

Bus 001 Device 004: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey] Bus 001 Device 006: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M | Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M | Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M

/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M | Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M | Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=rtl88x2bu, 480M |__ Port 4: Dev 6, If 0, Class=Vendor Specific Class, Driver=rtl88x2bu, 480M

Need point 5Ghz (rtw_vht_enable = 2 rtw_switch_usb_mode = 1) + 2.4Ghz (rtw_vht_enable = 1 rtw_switch_usb_mode = 1). hostapd -B /etc/hostapd/wifi24.conf /etc/hostapd/wifi58.conf

/etc/hostapd/wifi24.conf interface=wifi1 driver=nl80211 ssid=WiFi24 hw_mode=g channel=11 ieee80211n=1 ...

/etc/hostapd/wifi58.conf interface=wifi2 driver=nl80211 ssid=WiFi58 hw_mode=a channel=36 ieee80211n=1 ieee80211ac=1 ...