(solved) Unstable AP about 88x2bu HOT 18 CLOSED

Here's what I found:

EAPOL-Key Timeout value, the default is 1 second or 1000 milliseconds.

What this means is when it comes time to exchange the EAPOL keys between the AP and client, the AP will send the key and wait up to 1 second by default for the client to respond.

After waiting the defined time value, the AP will re-transmit the key again.

1 - AP sends key attempt to the client
2 - Wait 1 second for a reply
3 - If no reply, then send eapol key retry attempt #1
4 - Wait 1 second for a reply
5 - If no reply, then send eapol key retry attempt #2
6 - If there is still not a response from the client and the retry value is met, then de-authenticate the client.

Again, as with the EAPOL-Key Timeout, extending the EAPOL-Key retry value could in some circumstances be beneficial, however setting it to the max may again be harmful as the de-authenticate message would be prolonged.

However I don't know if it's hostapd problem or something else, I've tried other client, with the same result.

from 88x2bu.

use iperf to test, at about 1.5G data transfer, it stop at 0, and the ap looks like down.

I think it might be heat problem, when under hight load, It can't stand for 1 minute. Maybe the adapter quality is too bad!

from 88x2bu.

@danywheeler

Can you give me a little background? What hardware? What OS? What version of hostapd?

I've been seeing some issues with AP mode and hostapd. All drivers here seem to be affected to one degree or another except the 8812au, which is rock solid. Anything you can add to the search is welcome.

from 88x2bu.

System: Linux rpi4s1 5.4.0-1028-raspi #31-Ubuntu SMP PREEMPT Wed Jan 20 11:30:45 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
Ubuntu server 20.04.2

Hardware: rpi4 8gb, with a powered hub plugged at the bottom usb 3.0 port
hub: https://www.lulian.cn/product/208-cn.html
rtl8812bu: http://www.comfast.cn/index.php?m=content&c=index&a=show&catid=13&id=77

also with driver option rtw_vht_enable=2 rtw_power_mgnt=0 rtw_switch_usb_mode=1 to test.

from 88x2bu.

@morrownr Also could you enlighten me do the raspxx.sh is for Raspberry Pi OS or the hardware? I see that it toggle some make config, however without this the rpi4 seems to working fine on ubuntu server 64 bit. maybe update the doc so people could be better understand it thanks.

from 88x2bu.

The raspiXX.sh scripts simply make some changes in the makefile. The configuration is changed depending on the target hardware and the OS in use. If you use Raspberry Pi HARDWARE, you should run one of these scripts. The one you run depends on whether your OS is 32 bit or 64 bit. The default makefile is set for AMD64/x86 and it works for 32 bit and 64 bit. There are differences in the hardware that the compiler needs to know about. The reason for 2 scripts is that it has been found that the settings for 32 bit OSs on RasPi hardware doesn't work for 64 bit so different settings are required. Is the raspi64.sh script perfect for 64 bit Ubuntu server? I don't know but maybe we can find out. Recommend that you use the removal script and reinstall. You should use raspi64.sh

Please read Step 8 and write it so that you understand it. I will try to make the installation instructions better.

Can you please paste the contents of hostapd.conf here? Once I have that, I think I can make some suggestions. If necessary, I can probably duplicate your setup and see what is going on... I have the hardware

from 88x2bu.

hostapd.conf:

ssid=Test
wpa_passphrase=12345678

interface=wlx200db04cb65d
driver=nl80211
bridge=br-lan
country_code=US
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
macaddr_acl=0
hw_mode=a
wmm_enabled=1
ieee80211d=0
ieee80211h=0

logger_syslog=0
logger_syslog_level=4
logger_stdout=-1
logger_stdout_level=0

# N
ieee80211n=1
ht_capab=[LDPC][HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-7935][DSSS_CCK-40]
# AC
ieee80211ac=1
vht_capab=[MAX-MPDU-11454][RXLDPC][SHORT-GI-80][TX-STBC-2BY1][SU-BEAMFORMEE][HTC-VHT]
vht_oper_chwidth=1
channel=36
vht_oper_centr_freq_seg0_idx=42

from 88x2bu.

Just did a raspi64.sh It's the same as before, the raspi64.sh doesn't seem to make any difference on rpi4. After set rtw_switch_usb_mode=0 to use usb 2.0 the AP is much stable and reliable, doesn't have the problems I had before, but the speed only get around 200Mbps sometimes 0, but is not down, with usb 3.0 its around 300Mbps the max it reaches is 500Mbps but the ap will down and unusable. @morrownr can you do a long time iperf3 test? If I use usb 3.0 it only last about 5 minutes or so, then is unusable and new client can't join.

from 88x2bu.

I have noticed what you are describing and am still trying to figure out what the problem is. If I can get you test with some different settings to see if we can determine the most advanced settings that provide stable operations, I would appreciate it.

hostapd.conf
#vht_oper_chwidth=1
#vht_oper_centr_freq_seg0_idx=42

88x2bu.conf
options 88x2bu rtw_drv_log_level=4 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=1

Those settings leave USB3 active take down 80 MHz channel width. The log level cranked up and the power management is back to default. Try those settings and tell me what you see.

from 88x2bu.

Here's driver WARN message:

 RTW: module init start
 RTW: rtl88x2bu v5.8.7.4_37264.20200922_COEX20191120-7777
 RTW: rtl88x2bu BT-Coex version = COEX20191120-7777
 RTW: [HALMAC]11692M
 RTW: ERROR [HALMAC][ERR]Dump efuse in suspend
 RTW: HW EFUSE
 RTW: hal_com_config_channel_plan chplan:0x7F
 RTW: ERROR [HALMAC][ERR]Dump efuse in suspend
 RTW: [HALMAC][ALWAYS]shall R reg twice!!
 RTW: ERROR [HALMAC][ERR]Dump efuse in suspend
 RTW: ERROR [HALMAC][ERR]Dump efuse in suspend
 RTW: ERROR [HALMAC][ERR]Dump efuse in suspend
 RTW: [RF_PATH] ver_id.RF_TYPE:RF_2T2R, rf_reg_path_num:2, max_tx_cnt:2
 RTW: [RF_PATH] PG's trx_path_bmp:0x00, max_tx_cnt:0
 RTW: [RF_PATH] Registry's RF PATH:UNKNOWN
 RTW: [RF_PATH] HALDATA's trx_path_bmp:0x33, max_tx_cnt:2
 RTW: [RF_PATH] HALDATA's rf_type:RF_2T2R
 RTW: [RF_PATH] NumTotalRFPath:2
 RTW: [TRX_Nss] HALSPEC - tx_nss :2, rx_nss:2
 RTW: [TRX_Nss] Registry - tx_nss :0, rx_nss:0
 RTW: [TRX_Nss] HALDATA - tx_nss :2, rx_nss:2
 RTW: rtw_regsty_chk_target_tx_power_valid return _FALSE for band:0, path:0, rs:0, t:-1
 RTW: ERROR _halmac_reg_write_32: I/O FAIL!
 RTW: WARN free_recv_skb_queue not empty, 8
 RTW: module init ret=0
 RTW: [HALMAC]11692M
 RTW: ERROR [HALMAC][ERR]Dump efuse in suspend
 RTW: HW EFUSE

Looks like hardware problem, I don't know, hope some one know and can give me an explanation.

from 88x2bu.

I can investigate as I have time. Have you made the changes to the 2 .conf files I recommended in my previous message? I'd like to see if you achieve stability with those settings.

from 88x2bu.

I think as I change rtw_drv_log_level=3 it's working with out break out, just like usb2.0 but speed is a bit faster. however I discovered the error and warn message above. other settings are unchanged.

from 88x2bu.

See how the stability is over time. My testing seems to indicate 80 MHz channel width is the cause of the problem so setting the following shuts it down:

hostapd.conf (comment the following 2 lines out)
#vht_oper_chwidth=1
#vht_oper_centr_freq_seg0_idx=42

88x2bu.conf (return the following to a setting of 1)
rtw_vht_enable=1

It is not clear to me what the problem is. This driver and the 8821cu driver have this problem while the 8812au and 8821au drivers do not have this problem.

from 88x2bu.

Seems toggle driver log on to ERROR or WARN makes it better, it recovers from 0 Mbps to functional speed, wouldn't be down.

from 88x2bu.

In theory, that should not make a difference but who knows.

Have you taken it out of 80 MHz channel width mode?

hostapd.conf (deactivate the 2 lines below)
#vht_oper_chwidth=1
#vht_oper_centr_freq_seg0_idx=42

88x2bu.conf (return setting to default)
options 88x2bu rtw_vht_enable=1

Nick

from 88x2bu.

nope, it's the same setting with problems but with driver log turned on, it seems the problem goes away.

from 88x2bu.

You may be on to something. I'm going to test this. Keep in mind that USB 3, especially when pushed at higher speeds, can show issues. This is a USB device so only plug it into a USB 3 port or USB 3.1 gen 1 port. Stay away from USB 3.1 gen 2 ports because, as best I can tell, the usb code has not been updated or tested with 3.1 gen 2.

Keep me posted if you figure anything else out.

from 88x2bu.

Hi I was having the same problem but with 8812au - periodic failed handshake loop and being unable to connect. It was happening on two devices, an old android smartphone and esp8266.

It went away after I changed wpa_pairwise from CCMP to TKIP.

.... Never mind this fixed nothing. I switched back to another adapter, I don't have much time to debug this at the moment sorry.

from 88x2bu.