From the failing trace, MP2 is never sending an Authentication commit frame. It is sending the first authentication commit frame in the MP2 → MG capture.
This tells me it is capable of initiating, but maybe not responding? We’re still digging through the traces, in the meantime I’d be interested to know what wpa_supplicant is reporting in the debuglogs. Looks like you’re running supplicant manually so just add -dd to your supplicant invocation.
I have captured the logs as mentioned. One in the failing state, exactly the same state as before. And one where it is directly connected to the MG.
Thanks for your continued support and I hope this helps!
Debug logs.zip (19.3 KB)
Hey @SanderV
Thanks for both logs. Comparing the two we see the successful logs getting:
nl80211: Event message available
nl80211: Drv Event 72 (NL80211_CMD_NEW_PEER_CANDIDATE) received for wlan0
nl80211: New peer candidate 00:c0:ca:b6:5c:be
wlan0: Event NEW_PEER_CANDIDATE (49) received
wlan0: new peer notification for 00:c0:ca:b6:5c:be
where the failing logs see
nl80211: Event message available
nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlan0
nl80211: MLME event 59 (NL80211_CMD_FRAME) on wlan0(00:0a:52:09:18:ad) A1=00:0a:52:09:18:ad A2=be:d6:26:d0:92:21 on link_id=-1
nl80211: MLME event frame - hexdump(len=128): b0 00 ...
nl80211: Frame event
nl80211: RX frame da=00:0a:52:09:18:ad sa=be:d6:26:d0:92:21 bssid=be:d6:26:d0:92:21 freq=5180 ssi_signal=-100 fc=0xb0 seq_ctrl=0x120 stype=11 (WLAN_FC_STYPE_AUTH) len=128
wlan0: Event RX_MGMT (18) received
mgmt::auth
authentication: STA=be:d6:26:d0:92:21 auth_alg=3 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x120
SAE: Queue Authentication message from be:d6:26:d0:92:21 for processing (queue_len 0)
SAE: Process next available message from queue
authentication: STA=be:d6:26:d0:92:21 auth_alg=3 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x120 (from queue)
Mesh peer be:d6:26:d0:92:21 not yet known - drop Authentication frame
Now I believe the sequence of these two logs are a little different because in the successful case, MP2 is initiating the auth, whereas in the failing case MP1 is initiating the auth. However, the hint as to why MP1 is failing comes from the commit which added drop Authentication frame.
It came from upstream 09d96de - mesh: Drop Authentication frames from BLOCKED STA · MorseMicro/hostap@09d96de · GitHub. Indicating that MP1 is considered by MP2 to be BLOCKED.
The only reason I can think MP2 would block MP1 this early in the init sequence is the RSSI. Indicated in the log as ssi_signal=-100. This seems… wrong, especially as you have other logs showing the RSSI as a more sensible value.
As an experiment, can you set mesh_rssi_threshold=-110. Additionally, can you swap MP1 and MG. Does the failure follow MP1?