Hostapd : did not acknowledge authentication response

I have a lot of message like that on the ZBT - WG3526 - 16Mo

daemon.notice hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not acknowledge authentication response

i have to clic on the ssid 3 / 4 times with my iphone

i flashed it with OpenWrt SNAPSHOT r6755-d089a5d773 and i've just updated to OpenWrt 18.06-SNAPSHOT, r7015-c0763f08a5 and the problem seems to be still here

well, i have tested with the stable 17.01.4 version same problem.

in fact, it's only with 2.4 Ghz. i can connect over 5Ghz without troubles, but i can't on 2.4Ghz. when i said i need to clic 3 / 4 times it was because my phone switched to 5ghz automatically.

EDIT : The first connection is always good. after the first connection, i have to restart wifi or network to be able to connect to the 2.4Ghz.

more infos :slight_smile:

got this errors in kernel.

[  104.296771] ------------[ cut here ]------------
[  104.301479] WARNING: CPU: 0 PID: 6 at /home/keulu/Work/beonwifi/hardware/zbt_wg3526_16mo_17.01.4/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7621/mt76-2017-10-12-1be430fc/mt7603_mac.c:1279 mt7603_mac_work+0xe8/0x284 [mt7603e]()
[  104.322637] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CLASSIFY slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt act_connmark nf_conntrack act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress mt76x2e mt7603e ledtrig_usbport mt76 mac80211 cfg80211 compat ledtrig_heartbeat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables ifb tun leds_gpio xhci_mtk xhci_plat_hcd xhci_pci xhci_hcd ahci libahci libata sd_mod scsi_mod gpio_button_hotplug usbcore nls_base usb_common
[  104.416086] CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.92 #0
[  104.422257] Workqueue: phy0 mt7603_mac_work [mt7603e]
[  104.427284] Stack : 8fc32000 80470000 803e92a0 000004ff 8f0b55c4 00000002 8fc04614 8fc32018
[  104.427284] 	  00000088 800651c8 803e92a0 00000000 00000006 804c367c 80404d24 8fc69d54
[  104.427284] 	  80470000 80062f14 80470000 804e0000 80472318 8047231c 803edbdc 8fc69d54
[  104.427284] 	  80470000 80042674 8fc04614 8fc69d8c 000003bf 00000000 00000000 00c69d74
[  104.427284] 	  8f0b54dc 8ff87900 8ff87800 30796870 00000000 00000000 00000000 00000000
[  104.427284] 	  ...
[  104.462739] Call Trace:
[  104.465179] [<80016a00>] show_stack+0x54/0x88
[  104.469542] [<801b7648>] dump_stack+0x84/0xbc
[  104.473894] [<8002cfb8>] warn_slowpath_common+0xa0/0xd0
[  104.479096] [<8002d070>] warn_slowpath_null+0x18/0x24
[  104.484136] [<8f0b55c4>] mt7603_mac_work+0xe8/0x284 [mt7603e]
[  104.489863] [<80040298>] process_one_work+0x214/0x358
[  104.494892] [<80041198>] worker_thread+0x2d8/0x440
[  104.499673] [<80045970>] kthread+0xd8/0xec
[  104.503750] [<80005478>] ret_from_kernel_thread+0x14/0x1c
[  104.509118] 
[  104.510993] ---[ end trace 9dc91337adf7e7ec ]---
[  215.603693] ------------[ cut here ]------------
[  215.608378] WARNING: CPU: 1 PID: 6 at /home/keulu/Work/beonwifi/hardware/zbt_wg3526_16mo_17.01.4/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7621/mt76-2017-10-12-1be430fc/mt7603_mac.c:1288 mt7603_mac_work+0x1bc/0x284 [mt7603e]()
[  215.629623] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CLASSIFY slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt act_connmark nf_conntrack act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress mt76x2e mt7603e ledtrig_usbport mt76 mac80211 cfg80211 compat ledtrig_heartbeat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables ifb tun leds_gpio xhci_mtk xhci_plat_hcd xhci_pci xhci_hcd ahci libahci libata sd_mod scsi_mod gpio_button_hotplug usbcore nls_base usb_common
[  215.722886] CPU: 1 PID: 6 Comm: kworker/u8:0 Tainted: G        W       4.4.92 #0
[  215.730281] Workqueue: phy0 mt7603_mac_work [mt7603e]
[  215.735310] Stack : 8fc32000 80470000 803e92a0 00000508 8f0b5698 00000002 8fc04614 8fc32018
[  215.735310] 	  00000088 800651c8 803e92a0 00000001 00000006 804c367c 80404d24 8fc69d54
[  215.735310] 	  80470000 80062f14 80470000 804e0000 80472318 8047231c 803edbdc 8fc69d54
[  215.735310] 	  80470000 80042674 8fc04614 8fc69d8c 00000507 00000000 00000000 00c69d74
[  215.735310] 	  8f0b54dc 8ff87900 8ff87800 30796870 00000000 00000000 00000000 00000000
[  215.735310] 	  ...
[  215.770800] Call Trace:
[  215.773251] [<80016a00>] show_stack+0x54/0x88
[  215.777611] [<801b7648>] dump_stack+0x84/0xbc
[  215.781960] [<8002cfb8>] warn_slowpath_common+0xa0/0xd0
[  215.787170] [<8002d070>] warn_slowpath_null+0x18/0x24
[  215.792239] [<8f0b5698>] mt7603_mac_work+0x1bc/0x284 [mt7603e]
[  215.798061] [<80040298>] process_one_work+0x214/0x358
[  215.803093] [<80041198>] worker_thread+0x2d8/0x440
[  215.807879] [<80045970>] kthread+0xd8/0xec
[  215.811959] [<80005478>] ret_from_kernel_thread+0x14/0x1c
[  215.817328] 
[  215.818939] ---[ end trace 9dc91337adf7e7ed ]---

just after i put log_level '1' on wlan0 (2.4Ghz) and wifi restart

ok i found a solution.

i didn't plug antennas. and i think that the transmit power of 5Ghz mips override the 2.4.

with antennas, more gain, so 0 authent failed.

If your problem is solved, please consider marking this topic as [Solved]. (Click the pencil behind the topic...)

Actually it's not solved. The same issue exists in devices with non detachable antennas, i.e. mi router 3g

got one mi R3G, didn't see this issue on it.

  • Have you changed the channel?
  • Have you increased Tx power?
  • Have you disabled Krack and Spectre protection?

in order, Yep, Yep, Nope.

no care witch channel or Power. restart WiFi work sometimes.

Maybe it's a problem only with ramips_mt7621 mips ? R3G has this mips ?

Then try to disable it, this is not on by default.

Hi, have the same problem with mi3g. Krack is disabled. Do you mean to disable Spectre on router or PC?
Most interesting thing is that I can't connect to 2.4 GHz from my laptop, but MI gateway connects without issues.

To mitigate the OP's specific issue, I suggested disabling this on the router. I was not aware until your post that any PC permits disabling of this fix, because, in fact, when the fix is implemented on all clients in a WLAN, the risk would be completely mitigated. The OpenWrt fix only does various things to stop retransmission at those crucial times when the rekeys can occur (in the case of unpatched Linux and Androids, to an all-zero key). The risk is defined in the GUI as:

This workaround might cause interoperability issues and reduced robustness of key negotiation especially in environments with heavy traffic load.

This is the exact issue in the OPs title...the rekey may have not been received, in: heavy traffic, high noise, long distance, etc.

But how can it happen that embedded devices like IP camera or Xiaomi Gateway can connect, but Linux and Android can't?

I never stated this. The issue is not regarding connectivity or the OS. It's regarding:

If the android is with the user is 80 meters in the backyard, and the camera is 1 meter from the router, which one will likely authenticate without issue?

Are you aware of the Whitepaper outlining the specific vulnerabilities if carried out on a Linux or Android device?

If someone is having an issue like you describe, someone local to them may be maliciously attempting to compromise those [unpatched] devices. The risk for those devices - is that the key can be set to 00:00:00:00...

The router is 0.5 m from the laptop and the phone, and camera with gateway are 10 meters. So it's more likely that phone and camera should connect. And yes, I'm aware of vulnerabilities and have patched kernel installed. But it doesn't explain why some devices can connect, while others can't.

Not necessarily. One phrase: multi-path propagation. Also your issue is not similar, you describe as if your laptop never connects initially, these issues are with re-authentication.

Well OK post your /etc/config/network. Also, your issue is with a laptop (not OpenWrt it seems), need OS, wifi make and model, etc. This information is not provided.

You may also want to make a new thread.

Also, I explained the only technical reason, not sure what you mean:

You only seem to be concerned about this part:

So, if your mitigation is disabled on the router...simply put, it didn't solve your problem. I usually suggest congested networks, bad keys, non-default settings on the client wifi card, etc.

Also include the log messages you're receiving.

  • Are you using 40 MHz or higher bandwidth on the router?
  • are you running reg or 256-QAM hack on your router?
  • Do you have your router set to N or AC only?

I have the same issue and I want to try to "disable Krack and Spectre protection", but I've searched a bit on google and can't find out how to do such thing :-/
I'm running a fresh build of OpenWrt on the 18.06 branch with the cherry picked commit related to my router: TP-Link WA801ND-v5
I've tried all the channels from 1 to 13, tx power from blank, then 0 to 20, if the client is within the 5m, it connects and stay connected even if we go farer. But if we try to connect from 10+ meters away, it fails with this IEEE 802.11: did not acknowledge authentication response. I have the v2 of this same model and it does work perfectly and from farer.

UPDATE: Oh, and I even tried different beacon_int (within 100 to 300), widths 20 and 40 MHz, N or legacy, activating WMM or not, same....

Hello,
I could solve the same issue (iPad iOS 11.4.1 on 17.01.4 and 18.06.1, on a router with Atheros 2.4 GHz only) by disabling "Allow legacy 802.11b rates" in wireless network settings->Avanced Settings.