Re: port-evbppc/60132: same timeouts on 11.0 only with distant AP

["p6ix9%pm.me@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-evbppc/60132; it has been noted by GNATS.

From: p6ix9%pm.me@localhost
To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: port-evbppc/60132: same timeouts on 11.0 only with distant AP
Date: Wed, 04 Nov 2026 18:48:58 +0000

 I see the same authentication timeouts on NetBSD 11.0, but only with
 the more distant of the two access points on my network: node A is in
 the opposite corner of the house, on another floor, while node B is in
 the same room as the Wii. Both attempts on node A timed out, while
 every association to node B in my logs (at least six) succeeded on the
 first try. So in my case the timeouts may simply mean the AP was out
 of the Wii's range.
 
 System:
 
 =C2=A0 NetBSD wii 11.0 NetBSD 11.0 (WII) #0: Thu Jul 30 15:23:12 UTC 2026 e=
 vbppc
 
 =C2=A0 bwi0, from dmesg.boot: BBP 0x4318 rev 2, MAC rev 9, PHY type 2 (11G)
 =C2=A0 rev 7, RF 0x2050 rev 8, firmware rev 0x0127 patch 0x000e.
 
 That is the same firmware as in this PR. Unlike the original report,
 dmesg.boot has no "base tssi measure failed".
 
 Network: one SSID served by two TP-Link Deco BE65 mesh nodes in access
 point mode, WPA2-PSK; node A on 2437 MHz, node B on 2422 MHz. The
 wpa_supplicant.conf network block has:
 
 =C2=A0 key_mgmt=3DWPA-PSK
 =C2=A0 pairwise=3DCCMP TKIP
 =C2=A0 group=3DCCMP TKIP
 =C2=A0 ieee80211w=3D0
 
 wpa_supplicant messages for the first attempt (1 Nov, UTC, syslog
 prefix trimmed, addresses and SSID replaced):
 
 =C2=A0 16:27:55 Trying to associate with <node A> (SSID=3D'<SSID>' freq=3D2=
 437 MHz)
 =C2=A0 16:28:05 Authentication with <node A> timed out.
 =C2=A0 16:28:05 Added BSSID <node A> into ignore list, ignoring for 10 seco=
 nds
 =C2=A0 16:28:05 CTRL-EVENT-DISCONNECTED bssid=3D<node A> reason=3D3 locally=
 _generated=3D1
 =C2=A0 16:28:05 BSSID <node A> ignore list count incremented to 2, ignoring=
  for 10 seconds
 =C2=A0 16:28:05 CTRL-EVENT-DSCP-POLICY clear_all
 =C2=A0 16:28:05 ioctl[SIOCS80211, op=3D23, val=3D0, arg_len=3D0]: Invalid a=
 rgument
 =C2=A0 16:28:05 CTRL-EVENT-SCAN-FAILED ret=3D-1 retry=3D1
 =C2=A0 16:28:06 ioctl[SIOCS80211, op=3D23, val=3D0, arg_len=3D0]: Invalid a=
 rgument
 =C2=A0 16:28:06 CTRL-EVENT-SCAN-FAILED ret=3D-1 retry=3D1
 
 Up to this point it matches the log in your report. The difference is:
 at 16:28:10 wpa_supplicant tried node B and connected on the
 first attempt, instead of retrying the same AP forever. The second
 attempt, at about 18:10, went the same way, connecting to node B at
 18:10:31.
 
 The op=3D23 (IEEE80211_IOC_SCAN_REQ) EINVAL lines also appear every time
 wpa_supplicant starts here, including starts that then connect
 normally. So they look like a side effect rather than the cause. From
 a reading of ieee80211_setupscan(), SCAN_REQ returns EINVAL while the
 interface isn't both IFF_UP and IFF_RUNNING.
 
 Workaround: setting bssid=3D<node B> in the network block keeps
 wpa_supplicant away from node A. That only avoids the timeouts: the
 link to node B still stalls regularly (traffic stops while the
 interface shows DS1), which is a separate problem.