This happens both on OpenWrt (hostapd) and Ubiquity networks.
I own the OpenWrt router.
This is the output with FT-PSK as a key_mgmt option (broken config):
STA 30:52:cb:81:c0:29 IEEE 802.11: authentication OK (open system)
STA 30:52:cb:81:c0:29 MLME: MLME-AUTHENTICATE.indicatiroot@LEDESu:~#
logread -f -e hostapd
STA 30:52:cb:81:c0:29 IEEE 802.11: authentication OK (open system)
STA 30:52:cb:81:c0:29 MLME:
MLME-AUTHENTICATE.indication(30:52:cb:81:c0:29, OPEN_SYSTEM)
STA 30:52:cb:81:c0:29 MLME: MLME-DELETEKEYS.request(30:52:cb:81:c0:29)
STA 30:52:cb:81:c0:29 IEEE 802.11: authenticated
STA 30:52:cb:81:c0:29 IEEE 802.11: authentication OK (open system)
STA 30:52:cb:81:c0:29 WPA: event 0 notification
STA 30:52:cb:81:c0:29 MLME:
MLME-AUTHENTICATE.indication(30:52:cb:81:c0:29, OPEN_SYSTEM)
STA 30:52:cb:81:c0:29 MLME: MLME-DELETEKEYS.request(30:52:cb:81:c0:29)
STA 30:52:cb:81:c0:29 IEEE 802.11: authenticated
STA 30:52:cb:81:c0:29 IEEE 802.11: authentication OK (open system)
STA 30:52:cb:81:c0:29 WPA: event 0 notification
STA 30:52:cb:81:c0:29 MLME:
MLME-AUTHENTICATE.indication(30:52:cb:81:c0:29, OPEN_SYSTEM)
STA 30:52:cb:81:c0:29 MLME: MLME-DELETEKEYS.request(30:52:cb:81:c0:29)
STA 30:52:cb:81:c0:29 IEEE 802.11: authenticated
STA 30:52:cb:81:c0:29 IEEE 802.11: authentication OK (open system)
STA 30:52:cb:81:c0:29 WPA: event 0 notification
STA 30:52:cb:81:c0:29 MLME:
MLME-AUTHENTICATE.indication(30:52:cb:81:c0:29, OPEN_SYSTEM)
STA 30:52:cb:81:c0:29 MLME: MLME-DELETEKEYS.request(30:52:cb:81:c0:29)
STA 30:52:cb:81:c0:29 IEEE 802.11: authenticated
This is a working config:
STA 30:52:cb:81:c0:29 IEEE 802.11: authentication OK (open system)
STA 30:52:cb:81:c0:29 MLME:
MLME-AUTHENTICATE.indication(30:52:cb:81:c0:29, OPEN_SYSTEM)
STA 30:52:cb:81:c0:29 MLME: MLME-DELETEKEYS.request(30:52:cb:81:c0:29)
STA 30:52:cb:81:c0:29 IEEE 802.11: authenticated
STA 30:52:cb:81:c0:29 IEEE 802.11: association OK (aid 3)
STA 30:52:cb:81:c0:29 IEEE 802.11: associated (aid 3)
STA 30:52:cb:81:c0:29 MLME: MLME-ASSOCIATE.indication(30:52:cb:81:c0:29)
STA 30:52:cb:81:c0:29 MLME: MLME-DELETEKEYS.request(30:52:cb:81:c0:29)
STA 30:52:cb:81:c0:29 IEEE 802.11: binding station to interface 'wlan0-1'
STA 30:52:cb:81:c0:29 WPA: event 1 notification
STA 30:52:cb:81:c0:29 WPA: start authentication
STA 30:52:cb:81:c0:29 IEEE 802.1X: unauthorizing port
STA 30:52:cb:81:c0:29 WPA: sending 1/4 msg of 4-Way Handshake
STA 30:52:cb:81:c0:29 WPA: received EAPOL-Key frame (2/4 Pairwise)
STA 30:52:cb:81:c0:29 WPA: sending 3/4 msg of 4-Way Handshake
STA 30:52:cb:81:c0:29 WPA: received EAPOL-Key frame (4/4 Pairwise)
AP-STA-CONNECTED 30:52:cb:81:c0:29
STA 30:52:cb:81:c0:29 IEEE 802.1X: authorizing port
STA 30:52:cb:81:c0:29 RADIUS: starting accounting session FE1A7096D90FD955
STA 30:52:cb:81:c0:29 WPA: pairwise key handshake completed (RSN)
Il 14/10/19 21:52, michael-dev ha scritto:
Hi,
it basically reads:
nl80211: Connect request send successfully
...
wlan0: Event ASSOC_REJECT (12) received
wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
so your AP advertises FT/1X support, but then does not accept the
(should be FT-filled) Association Request.
How much control do you have over the AP? Is it hostapd running there?
Can you produce an AP debug log?
Regards,
M. Braun
Am 14.10.2019 14:00, schrieb Matteo Fortini:
Hi,
I reran the debug test with FT-EAP. I attach the corresponding log.
Thank you,
Matteo
Il 13/10/19 11:59, michael-dev@xxxxxxxxxxxxx ha scritto:
Hi,
having key mgmt restricted to wpa-eap basically disables FT at runtime.
Though the debug log is about PSK not EAP so it does not help
explain why FT-EAP fails for you.
Could you please attach an FT-EAP enabled debug log?
Thanks,
M. Braun
Am 11. Oktober 2019 17:11:49 MESZ schrieb Matteo Fortini
<matteo.fortini@xxxxxxxxx>:
I'm using wpa_supplicant 2.9.3
I cannot connect to any fast transition (FT) networks. I attach
a debug log.
This includes for instance all the Ubiquity networks, but I
tested it also on OpenWrt+Roaming (802.11r)
It seems that the FT-XXX key_mgmt configuration which is set by
NM triggers some bug.
Configuration which doesn't work:
network={
ssid="myNetwork"
scan_ssid=1
proto=RSN
key_mgmt=WPA-EAP WPA-EAP-SHA256 FT-EAP FT-EAP-SHA384
pairwise=CCMP
auth_alg=OPEN
bgscan="simple:30:-65:300"
eap=PEAP
identity="myuser"
password="*******"
fragment_size=1266
proactive_key_caching=1
}
Configuration which works:
network={
ssid="myNetwork"
scan_ssid=1
proto=RSN
key_mgmt=WPA-EAP
pairwise=CCMP
auth_alg=OPEN
bgscan="simple:30:-65:300"
eap=PEAP
identity="myuser"
password="*******"
fragment_size=1266
proactive_key_caching=1
}
My network card is a BCM4350 802.11ac Wireless Network Adapter
running on Linux 5.3
* wpasupplicant=2:2.4-1+deb9u4 (oldstable) *works*, but because
NetworkManager uses "Config: added 'key_mgmt' value 'WPA-EAP'"
* wpasupplicant=2:2.7+git20190128+0c1e29f-6 (stable) *doesn't
work*, but because NetworkManager uses "Config: added 'key_mgmt'
value 'WPA-EAP
WPA-EAP-SHA256 FT-EAP FT-EAP-SHA384'"
Now I'm on wpasupplicant=2:2.9.3 and it doesn't work, either,
for the same config reason
Apparently nm uses the capabilities and triggers the bug.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
