(solved) Unstable AP

[dc-me]

Sometimes I can't connect to AP with following message:

wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 IEEE 802.11: associated wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: event 1 notification wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: start authentication wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 IEEE 802.1X: unauthorizing port wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: sending 1/4 msg of 4-Way Handshake wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: EAPOL-Key timeout wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: sending 1/4 msg of 4-Way Handshake wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: EAPOL-Key timeout wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: sending 1/4 msg of 4-Way Handshake wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: EAPOL-Key timeout wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: sending 1/4 msg of 4-Way Handshake wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: EAPOL-Key timeout wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: PTKSTART: Retry limit 4 reached wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 WPA: event 3 notification wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 IEEE 802.1X: unauthorizing port wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 MLME: MLME-DEAUTHENTICATE.indication(22:2d:a8:d8:e3:69, 2) wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 MLME: MLME-DELETEKEYS.request(22:2d:a8:d8:e3:69) wlx200db04cb65d: STA 22:2d:a8:d8:e3:69 IEEE 802.11: disassociated

This happens when the signal is weak, when this happens if I move the client to a better signal location it wouldn't recover, However With a system reboot the problem goes away, and I can connect it again.

[dc-me]

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.

[dc-me]

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!

[morrownr]

@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.

[dc-me]

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.

[dc-me]

@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.

[morrownr]

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

[dc-me]

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

[dc-me]

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.

[morrownr]

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.

[dc-me]

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.

[morrownr]

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.

[dc-me]

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.

[morrownr]

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.

[dc-me]

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

[morrownr]

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

[dc-me]

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

[morrownr]

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.

[scraprats]

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.