Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1003907: fails to successfully associate
124 views
Skip to first unread message
Andrej Shadura
Jan 18, 2022, 10:00:04 AM1/18/22
to
I tried forwarding the logs to the hostapd list, but apparently the file is too large to be allowed by default.
The original message with the attachments can be found here: https://bugs.debian.org/1003907#20
On Tue, 18 Jan 2022, at 11:50, Michael Biebl wrote:
> I only saw this reply by accident, as I wasn't CCed.
> But I assume this was directed at me.
>
> CCing the upstream mailing list will probably not work, since I'm not
> subscribed.
>
> Anyway, here is the requested output.
> I hope the results are properly anonymized as I didn't check the logs
> and I don't want to change my WiFi password :-)
>
> The package upgrade starts at 11:35
>
> I let wpasupplicant/NM try for another 3 mins before I stopped them.
>
> Regards,
> Michael
>
> On Tue, 18 Jan 2022 09:09:14 +0100 "Andrej Shadura" <and...@shadura.me>
> wrote:
>> Adding the Debian bug to the loop.
>>
>> On Tue, 18 Jan 2022, at 03:59, Masashi Honma wrote:
>> > To investigate more, could you enable wpa_supplicant debug option and
>> > provide the log ?
>> >
>> > Procedure is like this.
>> >
>> > 1) Edit /etc/systemd/system/multi-user.target.wants/wpa_supplicant.service to
>> > add -dddddddddd option like this.
>> >
>> > ExecStart=/sbin/wpa_supplicant -u -s -dddddddddd -O /run/wpa_supplicant
>> >
>> > 2) Reboot wpa_supplicant.
>> > $ sudo systemctl daemon-reload
>> >
>> > 3) Enable NetworkManager logging
>> > $ sudo nmcli general logging level DEBUG domains ALL
>> >
>> > 4) Get logs
>> > $ journalctl -u NetworkManager -b
>> >
>> > If possible, could you provide Wi-Fi capture ?
>> >
>> > Regards,
>> > Masashi Honma.
>>
>> --
>> Cheers,
>> Andrej
>>
>>
>
> Attachments:
> * wpasupplicant.txt
> * NetworkManager.txt
> * OpenPGP_signature
--
Cheers,
Andrej
The original message with the attachments can be found here: https://bugs.debian.org/1003907#20
On Tue, 18 Jan 2022, at 11:50, Michael Biebl wrote:
> I only saw this reply by accident, as I wasn't CCed.
> But I assume this was directed at me.
>
> CCing the upstream mailing list will probably not work, since I'm not
> subscribed.
>
> Anyway, here is the requested output.
> I hope the results are properly anonymized as I didn't check the logs
> and I don't want to change my WiFi password :-)
>
> The package upgrade starts at 11:35
>
> I let wpasupplicant/NM try for another 3 mins before I stopped them.
>
> Regards,
> Michael
>
> On Tue, 18 Jan 2022 09:09:14 +0100 "Andrej Shadura" <and...@shadura.me>
> wrote:
>> Adding the Debian bug to the loop.
>>
>> On Tue, 18 Jan 2022, at 03:59, Masashi Honma wrote:
>> > To investigate more, could you enable wpa_supplicant debug option and
>> > provide the log ?
>> >
>> > Procedure is like this.
>> >
>> > 1) Edit /etc/systemd/system/multi-user.target.wants/wpa_supplicant.service to
>> > add -dddddddddd option like this.
>> >
>> > ExecStart=/sbin/wpa_supplicant -u -s -dddddddddd -O /run/wpa_supplicant
>> >
>> > 2) Reboot wpa_supplicant.
>> > $ sudo systemctl daemon-reload
>> >
>> > 3) Enable NetworkManager logging
>> > $ sudo nmcli general logging level DEBUG domains ALL
>> >
>> > 4) Get logs
>> > $ journalctl -u NetworkManager -b
>> >
>> > If possible, could you provide Wi-Fi capture ?
>> >
>> > Regards,
>> > Masashi Honma.
>>
>> --
>> Cheers,
>> Andrej
>>
>>
>
> Attachments:
> * wpasupplicant.txt
> * NetworkManager.txt
> * OpenPGP_signature
--
Cheers,
Andrej
Michael Biebl
Jan 18, 2022, 4:00:04 PM1/18/22
to
Am 18.01.22 um 21:47 schrieb Masashi Honma:
> The log indicates that the Wi-Fi access point rejected the association
> request from the Wi-Fi station with status
> code=WLAN_STATUS_INVALID_IE.
>
> We can't read from this log why the Wi-Fi access point rejected the
> assocication request.
> If I have that Wi-Fi access point on hand, I can bisect this issue.
> What is the Wi-Fi access point you are using?
>
It's a FRITZ!Box 7490 (a very common Wi-Fi Router in Germany) running
Firmware version 07.39.
WPA-Mode is set to WPA2+WPA3
Michael Biebl
Jan 19, 2022, 5:20:03 AM1/19/22
to
Am 18.01.22 um 21:56 schrieb Andrej Shadura:
> Hi Michael,
> Just a random thought: could you please try those two versions formerly from experimental:
> * 2:2.9.0+git20200517+dd2daf0-1
> * 2:2.9.0+git20210909+a75fdcd-1
>
> I have re-enabled some options (WNM, MBO, FILS and mesh networking) in the latter, I wonder if that could have some effect.
>
I tried the various versions from snapshots.d.o
2:2.9.0-23 - works
2:2.9.0+git20200221+f65da0c-1 - works
2:2.9.0+git20200517+dd2daf0-1 - doesn't work
2:2.9.0+git20210909+a75fdcd-1 - doesn't work
2:2.9.0+git20211018+2e122945fa53-1 - doesn't work
2:2.9.0+git20211116+0b853303ae31-1 - doesn't work
2:2.10-1 - doesn't work
I then went on and disabled WPA2+WPA3 mode on the Wi-Fi router and set
it to WPA2 (CCMP).
After that, the connection was established successfully with 2.10.
If I remember correctly, my hardware doesn't support WPA3, but since I
enabled support for both WPA2+WPA3, it should fall back to WPA2.
Obviously I'd like to keep WPA3 enabled for newer clients.
Regards,
Michael
> Hi Michael,
> * 2:2.9.0+git20200517+dd2daf0-1
> * 2:2.9.0+git20210909+a75fdcd-1
>
> I have re-enabled some options (WNM, MBO, FILS and mesh networking) in the latter, I wonder if that could have some effect.
>
I tried the various versions from snapshots.d.o
2:2.9.0-23 - works
2:2.9.0+git20200221+f65da0c-1 - works
2:2.9.0+git20200517+dd2daf0-1 - doesn't work
2:2.9.0+git20210909+a75fdcd-1 - doesn't work
2:2.9.0+git20211018+2e122945fa53-1 - doesn't work
2:2.9.0+git20211116+0b853303ae31-1 - doesn't work
2:2.10-1 - doesn't work
I then went on and disabled WPA2+WPA3 mode on the Wi-Fi router and set
it to WPA2 (CCMP).
After that, the connection was established successfully with 2.10.
If I remember correctly, my hardware doesn't support WPA3, but since I
enabled support for both WPA2+WPA3, it should fall back to WPA2.
Obviously I'd like to keep WPA3 enabled for newer clients.
Regards,
Michael
Masashi Honma
Jan 30, 2022, 7:10:04 PM1/30/22
to
> Is it possible that wpasupplicant reports that the driver (iwlwifi)
> supports SAE but my hardware does not actually support SAE?
It looks like your device supports SAE.
Because SAE authentication is completed in your log.
----
Jan 18 11:36:02 pluto wpa_supplicant[86593]: SME: SAE completed -
setting PMK for 4-way handshake
----
By your log, wpa_supplicant already recognize that your device does
not support 802.11w (00-0f-ac:6 is missing).
Therefore if wpa_supplicant can recognize your AP requires 802.11w,
wpa_supplicant avoid to connect the AP.
----
Jan 18 11:35:58 pluto wpa_supplicant[86593]: Initializing interface
'wlp3s0' conf 'N/A' driver 'nl80211,wext' ctrl_interface
'/run/wpa_supplicant' bridge 'N/A'
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:1
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:5
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:2
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:4
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:10
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:8
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:9
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Using
driver-based off-channel TX
----
But your AP indicates that the AP is not capable and not required 802.11w.
30 18
01 00
00 0f ac 04
01 00
00 0f ac 04
02 00
00 0f ac 02
00 0f ac 08
80 00 <----- here
----
Jan 18 11:36:01 pluto wpa_supplicant[86593]: 38:10:d5:8f:38:e2
freq=5620 qual=0 noise=-92~ level=-61 snr=31* flags=0xb age=1048
est=135000
Jan 18 11:36:01 pluto wpa_supplicant[86593]: IEs - hexdump(len=439):
00 08 77 67 72 6f 75 74 65 72 01 08 8c 12 98 24 b0 48 60 6c 03 01 7c
07 3c 44 45 20 24 01 17 28 01 17 2c 01 17 30 01 17 34 01 17 38 01 17
3c 01 17 40 01 17 64 01 1e 68 01 1e 6c 01 1e 70 01 1e 74 01 1e 78 01
1e 7c 01 1e 80 01 1e 84 01 1e 88 01 1e 8c 01 1e 20 01 03 0b 05 02 00
01 00 00 46 05 73 d0 00 00 0c 2d 1a ef 09 1b ff ff ff 00 00 00 00 00
00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 3d 16 7c 05 04 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4a 0e 14 00 0a 00 2c
01 c8 00 14 00 05 00 19 00 7f 08 05 00 0f 00 00 00 00 40 bf 0c b2 01
80 33 ea ff 00 00 ea ff 00 00 c0 05 01 7a 00 fc ff c1 06 00 00 00 64
00 00 c3 04 02 3c 3c 3c dd 18 00 50 f2 02 01 01 00 00 03 a4 00 00 27
a4 00 00 42 43 5e 00 62 32 2f 00 dd 09 00 03 7f 01 01 00 00 ff 7f dd
0c 00 04 0e 01 01 02 01 00 00 00 00 00 dd 16 8c fd f0 04 00 00 49 4c
51 03 02 09 72 01 8c 16 00 00 3c 00 00 00 dd 6f 00 50 f2 04 10 4a 00
01 10 10 44 00 01 02 10 3b 00 01 03 10 47 00 10 c9 59 b5 c3 8d d0 39
ac a9 80 38 10 d5 65 71 88 10 21 00 03 41 56 4d 10 23 00 04 46 42 6f
78 10 24 00 04 30 30 30 30 10 42 00 04 30 30 30 30 10 54 00 08 00 06
00 50 f2 04 00 01 10 11 00 04 46 42 6f 78 10 08 00 02 02 80 10 3c 00
01 03 10 49 00 06 00 37 2a 00 01 20 30 18 01 00 00 0f ac 04 01 00 00
0f ac 04 02 00 00 0f ac 02 00 0f ac 08 80 00 dd 08 8c fd f0 01 01 02
01 00
Jan 18 11:36:01 pluto wpa_supplicant[86593]: Beacon IEs -
hexdump(len=363): 00 08 77 67 72 6f 75 74 65 72 01 08 8c 12 98 24 b0
48 60 6c 03 01 7c 05 04 00 01 00 00 07 3c 44 45 20 24 01 17 28 01 17
2c 01 17 30 01 17 34 01 17 38 01 17 3c 01 17 40 01 17 64 01 1e 68 01
1e 6c 01 1e 70 01 1e 74 01 1e 78 01 1e 7c 01 1e 80 01 1e 84 01 1e 88
01 1e 8c 01 1e 20 01 03 0b 05 02 00 01 00 00 46 05 73 d0 00 00 0c 2d
1a ef 09 1b ff ff ff 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00
00 00 00 00 3d 16 7c 05 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 4a 0e 14 00 0a 00 2c 01 c8 00 14 00 05 00 19 00 7f 08
05 00 0f 00 00 00 00 40 bf 0c b2 01 80 33 ea ff 00 00 ea ff 00 00 c0
05 01 7a 00 fc ff c1 06 00 00 00 64 00 00 c3 04 02 3c 3c 3c dd 18 00
50 f2 02 01 01 00 00 03 a4 00 00 27 a4 00 00 42 43 5e 00 62 32 2f 00
dd 09 00 03 7f 01 01 00 00 ff 7f dd 08 8c fd f0 01 01 02 01 00 dd 16
8c fd f0 04 00 00 49 4c 51 03 02 09 72 01 8c 16 00 00 3c 00 00 00 dd
0c 00 04 0e 01 01 02 01 00 00 00 00 00 dd 1d 00 50 f2 04 10 4a 00 01
10 10 44 00 01 02 10 3c 00 01 03 10 49 00 06 00 37 2a 00 01 20 30 18
01 00 00 0f ac 04 01 00 00 0f ac 04 02 00 00 0f ac 02 00 0f ac 08 80
00
----
So wpa_supplicant try to connect the AP and send association request.
Of course the association request does not include group management
cipher suite for 802.11w.
30 14
01 00
00 0f ac 04
01 00
00 0f ac 04
01 00
00 0f ac 08
00 00
----
Jan 18 11:36:02 pluto wpa_supplicant[86593]: nl80211: Associate (ifindex=9)
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * bssid=38:10:d5:8f:38:e2
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * freq=5620
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * SSID=wgrouter
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * IEs -
hexdump(len=61): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f
ac 08 00 00 7f 0b 00 00 0a 02 01 40 40 40 00 01 20 46 05 70 00 00 00
00 3b 11 80 51 53 54 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * WPA Versions 0x2
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * pairwise=0xfac04
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * group=0xfac04
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * akm=0xfac08
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * htcaps -
hexdump(len=26): 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * htcaps_mask -
hexdump(len=26): 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * vhtcaps -
hexdump(len=12): 00 00 00 00 00 00 00 00 00 00 00 00
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * vhtcaps_mask -
hexdump(len=12): 00 00 00 00 00 00 00 00 00 00 00 00
----
The AP reject with WLAN_STATUS_INVALID_IE.
I guess this is because lack of group management cipher suite for 802.11w.
----
Jan 18 11:36:02 pluto wpa_supplicant[86593]: wlp3s0:
CTRL-EVENT-ASSOC-REJECT bssid=38:10:d5:8f:38:e2 status_code=40
----
I'm still having problems buying that access point from Japan.
But this comment would be helpful.
> To connect the wireless device anyway, you must adjust the security settings in the FRITZ!Box:
> Disabling WPA3 transition mode (WPA2 + WPA3)
Almost APs allows no 802.11w STAs when "WPA3 transition mode (WPA2 +
WPA3)" is enabled.
But unfortunately the AP does not allow it.
> Still curious, why this worked flawlessly with this device with 2.9.0-23
Before the commit 7a9c36722511ce4df88b76cceceb241d6c6a151e "DBus: Add "sae" to
interface key_mgmt capabilities", there is no way to enable WPA3 via DBus.
So your station just using WPA2. Your access point does not appear to require
802.11w for WPA2.
To summarize, the AP indicates that it does not require 802.11w for WPA3,
when in fact it does. So it could not be solved by wpa_supplicant.
Regards,
Masashi Honma.
2022年1月31日(月) 1:01 Michael Biebl <bi...@debian.org>:
>
>
> Since I could easily reproduce it, I ran git bisect.
>
> 7a9c36722511ce4df88b76cceceb241d6c6a151e is the first bad commit
> commit 7a9c36722511ce4df88b76cceceb241d6c6a151e
> Author: Brian Norris <brian...@chromium.org>
> Date: Fri Feb 28 15:50:47 2020 -0800
>
> DBus: Add "sae" to interface key_mgmt capabilities
>
> This will be present when the driver supports SAE and it's included in
> the wpa_supplicant build.
>
> Signed-off-by: Brian Norris <brian...@chromium.org>
>
>
> Reverting that commit on top of 2.10 I was again able to successfully
> establish a connection.
>
> The debian build uses CONFIG_SAE=y.
> Is it possible that wpasupplicant reports that the driver (iwlwifi)
> supports SAE but my hardware does not actually support SAE?
>
> https://www.intel.com/content/www/us/en/support/articles/000054783/wireless.html
>
> My network controller is an "Intel Corporation Centrino Advanced-N 6205"
> supports SAE but my hardware does not actually support SAE?
It looks like your device supports SAE.
Because SAE authentication is completed in your log.
----
Jan 18 11:36:02 pluto wpa_supplicant[86593]: SME: SAE completed -
setting PMK for 4-way handshake
----
By your log, wpa_supplicant already recognize that your device does
not support 802.11w (00-0f-ac:6 is missing).
Therefore if wpa_supplicant can recognize your AP requires 802.11w,
wpa_supplicant avoid to connect the AP.
----
Jan 18 11:35:58 pluto wpa_supplicant[86593]: Initializing interface
'wlp3s0' conf 'N/A' driver 'nl80211,wext' ctrl_interface
'/run/wpa_supplicant' bridge 'N/A'
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:1
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:5
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:2
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:4
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:10
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:8
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Supported cipher
00-0f-ac:9
Jan 18 11:35:58 pluto wpa_supplicant[86593]: nl80211: Using
driver-based off-channel TX
----
But your AP indicates that the AP is not capable and not required 802.11w.
30 18
01 00
00 0f ac 04
01 00
00 0f ac 04
02 00
00 0f ac 02
00 0f ac 08
80 00 <----- here
----
Jan 18 11:36:01 pluto wpa_supplicant[86593]: 38:10:d5:8f:38:e2
freq=5620 qual=0 noise=-92~ level=-61 snr=31* flags=0xb age=1048
est=135000
Jan 18 11:36:01 pluto wpa_supplicant[86593]: IEs - hexdump(len=439):
00 08 77 67 72 6f 75 74 65 72 01 08 8c 12 98 24 b0 48 60 6c 03 01 7c
07 3c 44 45 20 24 01 17 28 01 17 2c 01 17 30 01 17 34 01 17 38 01 17
3c 01 17 40 01 17 64 01 1e 68 01 1e 6c 01 1e 70 01 1e 74 01 1e 78 01
1e 7c 01 1e 80 01 1e 84 01 1e 88 01 1e 8c 01 1e 20 01 03 0b 05 02 00
01 00 00 46 05 73 d0 00 00 0c 2d 1a ef 09 1b ff ff ff 00 00 00 00 00
00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 3d 16 7c 05 04 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4a 0e 14 00 0a 00 2c
01 c8 00 14 00 05 00 19 00 7f 08 05 00 0f 00 00 00 00 40 bf 0c b2 01
80 33 ea ff 00 00 ea ff 00 00 c0 05 01 7a 00 fc ff c1 06 00 00 00 64
00 00 c3 04 02 3c 3c 3c dd 18 00 50 f2 02 01 01 00 00 03 a4 00 00 27
a4 00 00 42 43 5e 00 62 32 2f 00 dd 09 00 03 7f 01 01 00 00 ff 7f dd
0c 00 04 0e 01 01 02 01 00 00 00 00 00 dd 16 8c fd f0 04 00 00 49 4c
51 03 02 09 72 01 8c 16 00 00 3c 00 00 00 dd 6f 00 50 f2 04 10 4a 00
01 10 10 44 00 01 02 10 3b 00 01 03 10 47 00 10 c9 59 b5 c3 8d d0 39
ac a9 80 38 10 d5 65 71 88 10 21 00 03 41 56 4d 10 23 00 04 46 42 6f
78 10 24 00 04 30 30 30 30 10 42 00 04 30 30 30 30 10 54 00 08 00 06
00 50 f2 04 00 01 10 11 00 04 46 42 6f 78 10 08 00 02 02 80 10 3c 00
01 03 10 49 00 06 00 37 2a 00 01 20 30 18 01 00 00 0f ac 04 01 00 00
0f ac 04 02 00 00 0f ac 02 00 0f ac 08 80 00 dd 08 8c fd f0 01 01 02
01 00
Jan 18 11:36:01 pluto wpa_supplicant[86593]: Beacon IEs -
hexdump(len=363): 00 08 77 67 72 6f 75 74 65 72 01 08 8c 12 98 24 b0
48 60 6c 03 01 7c 05 04 00 01 00 00 07 3c 44 45 20 24 01 17 28 01 17
2c 01 17 30 01 17 34 01 17 38 01 17 3c 01 17 40 01 17 64 01 1e 68 01
1e 6c 01 1e 70 01 1e 74 01 1e 78 01 1e 7c 01 1e 80 01 1e 84 01 1e 88
01 1e 8c 01 1e 20 01 03 0b 05 02 00 01 00 00 46 05 73 d0 00 00 0c 2d
1a ef 09 1b ff ff ff 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00
00 00 00 00 3d 16 7c 05 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 4a 0e 14 00 0a 00 2c 01 c8 00 14 00 05 00 19 00 7f 08
05 00 0f 00 00 00 00 40 bf 0c b2 01 80 33 ea ff 00 00 ea ff 00 00 c0
05 01 7a 00 fc ff c1 06 00 00 00 64 00 00 c3 04 02 3c 3c 3c dd 18 00
50 f2 02 01 01 00 00 03 a4 00 00 27 a4 00 00 42 43 5e 00 62 32 2f 00
dd 09 00 03 7f 01 01 00 00 ff 7f dd 08 8c fd f0 01 01 02 01 00 dd 16
8c fd f0 04 00 00 49 4c 51 03 02 09 72 01 8c 16 00 00 3c 00 00 00 dd
0c 00 04 0e 01 01 02 01 00 00 00 00 00 dd 1d 00 50 f2 04 10 4a 00 01
10 10 44 00 01 02 10 3c 00 01 03 10 49 00 06 00 37 2a 00 01 20 30 18
01 00 00 0f ac 04 01 00 00 0f ac 04 02 00 00 0f ac 02 00 0f ac 08 80
00
----
So wpa_supplicant try to connect the AP and send association request.
Of course the association request does not include group management
cipher suite for 802.11w.
30 14
01 00
00 0f ac 04
01 00
00 0f ac 04
01 00
00 0f ac 08
00 00
----
Jan 18 11:36:02 pluto wpa_supplicant[86593]: nl80211: Associate (ifindex=9)
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * bssid=38:10:d5:8f:38:e2
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * freq=5620
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * SSID=wgrouter
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * IEs -
hexdump(len=61): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f
ac 08 00 00 7f 0b 00 00 0a 02 01 40 40 40 00 01 20 46 05 70 00 00 00
00 3b 11 80 51 53 54 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * WPA Versions 0x2
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * pairwise=0xfac04
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * group=0xfac04
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * akm=0xfac08
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * htcaps -
hexdump(len=26): 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * htcaps_mask -
hexdump(len=26): 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * vhtcaps -
hexdump(len=12): 00 00 00 00 00 00 00 00 00 00 00 00
Jan 18 11:36:02 pluto wpa_supplicant[86593]: * vhtcaps_mask -
hexdump(len=12): 00 00 00 00 00 00 00 00 00 00 00 00
----
The AP reject with WLAN_STATUS_INVALID_IE.
I guess this is because lack of group management cipher suite for 802.11w.
----
Jan 18 11:36:02 pluto wpa_supplicant[86593]: wlp3s0:
CTRL-EVENT-ASSOC-REJECT bssid=38:10:d5:8f:38:e2 status_code=40
----
I'm still having problems buying that access point from Japan.
But this comment would be helpful.
> To connect the wireless device anyway, you must adjust the security settings in the FRITZ!Box:
> Disabling WPA3 transition mode (WPA2 + WPA3)
Almost APs allows no 802.11w STAs when "WPA3 transition mode (WPA2 +
WPA3)" is enabled.
But unfortunately the AP does not allow it.
> Still curious, why this worked flawlessly with this device with 2.9.0-23
Before the commit 7a9c36722511ce4df88b76cceceb241d6c6a151e "DBus: Add "sae" to
interface key_mgmt capabilities", there is no way to enable WPA3 via DBus.
So your station just using WPA2. Your access point does not appear to require
802.11w for WPA2.
To summarize, the AP indicates that it does not require 802.11w for WPA3,
when in fact it does. So it could not be solved by wpa_supplicant.
Regards,
Masashi Honma.
2022年1月31日(月) 1:01 Michael Biebl <bi...@debian.org>:
>
>
> Since I could easily reproduce it, I ran git bisect.
>
> 7a9c36722511ce4df88b76cceceb241d6c6a151e is the first bad commit
> commit 7a9c36722511ce4df88b76cceceb241d6c6a151e
> Author: Brian Norris <brian...@chromium.org>
> Date: Fri Feb 28 15:50:47 2020 -0800
>
> DBus: Add "sae" to interface key_mgmt capabilities
>
> This will be present when the driver supports SAE and it's included in
> the wpa_supplicant build.
>
> Signed-off-by: Brian Norris <brian...@chromium.org>
>
>
> Reverting that commit on top of 2.10 I was again able to successfully
> establish a connection.
>
> The debian build uses CONFIG_SAE=y.
> Is it possible that wpasupplicant reports that the driver (iwlwifi)
> supports SAE but my hardware does not actually support SAE?
>
> https://www.intel.com/content/www/us/en/support/articles/000054783/wireless.html
>
> My network controller is an "Intel Corporation Centrino Advanced-N 6205"
Michael Biebl
Mar 19, 2022, 6:30:03 PM3/19/22
to
Am 19.03.22 um 22:30 schrieb Andrej Shadura:
> Hi,
>
> Michael, Masashi, what’s your opinion, what should I do as the maintainer of wpa in Debian?
I can still reproduce the problem.
If more debugging is needed, please let me know. I'll try to help as
much as I can.
Michael
> Hi,
>
> Michael, Masashi, what’s your opinion, what should I do as the maintainer of wpa in Debian?
I can still reproduce the problem.
If more debugging is needed, please let me know. I'll try to help as
much as I can.
Michael
Masashi Honma
Mar 24, 2022, 6:10:04 PM3/24/22
to
> Masashi, if I understand you correctly, you argue that this is an issue
> with the AP (or its firmware).
> If so, should the company AVM be contacted about this?
> I'm afraid I'm not too knowledgeable in that regard.
Michael, Hans-Peter Jansen already reported to AVM at 2022-02-06
(https://bugzilla.opensuse.org/show_bug.cgi?id=1195395).
According to his latest comment,
"Just a heads up: AVM is still investigating on this. Some tests with
newer hardware confirmed, that WPA3 is working well there."
2022年3月25日(金) 2:48 Michael Biebl <bi...@debian.org>:
>
> Some more data points:
>
> Disabling NetworkManager completely and using wpasupplicant alone with
> the following config:
>
> network={
> ssid="wgrouter"
> psk="<hidden>"
> key_mgmt=WPA-PSK
> id_str="wgrouter"
> }
>
> does indeed work.
>
> As soon as I enable NetworkManager though, my connection fails, even
> though /etc/NetworkManager/system-connections/wgrouter.nmconnection
> contains
>
> [wifi-security]
> key-mgmt=wpa-psk
> psk=<hidden>
>
> In journalctl -u NetworkManager I see
>
> Mär 21 11:15:07 pluto NetworkManager[2450]: <info> [1647857707.7752]
> Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE'
>
>
> Ľubomír, is there a way how I can tell NetworkManager to *not* use SAE?
>
>
>
> Am 21.03.22 um 09:38 schrieb Andrej Shadura:
> > Hi,
> >
> > On Sun, 20 Mar 2022, at 00:23, Masashi Honma wrote:
> >> In my opinion, this issue could be closed.
> >>
> >> These are reasons.
> >> 1) It is not wpa_supplicant issue but AP issue.
> >> 2) Users affected by this issue have some workarounds.
> >
> > It’s true, but I’m not quite happy about not being able to fix this.
> >
> > Ľubomír (cc'ed), how did you deal with this issue in Fedora? I assume you must also have received reports from Fritzbox users.
> >
> >> Details of the 1)
> >> The investigation has revealed that the AP is in violation of "2.3
> >> WPA3-Personal transition mode" of the "WPA3 Specification v3.0", which
> >> is causing the issue. Specifically, the target AP is setting MFPR to 1
> >> even though it implicitly requires IEEE 802.11w. By "implicitly" we
> >> mean that the Assocation Request fails with WLAN_STATUS_INVALID_IE
> >> when using a Wi-Fi NIC with IEEE 802.11w disabled.
> >>
> >>
> >> Details of the 2)
> >> We know that users who meet the following conditions are affected by this issue.
> >> - Using FRITZ!Box 7580/7590 with WPA2+WPA3 mode
>
> I've tested it with both 7490 and 7530 AX, fwiw.
>
> >> - Using wpa_supplicant with wpa_key_mgmt=SAE WPA-PSK
> >> - Local Wi-Fi NIC does not support IEEE802.11w
> >>
> >> Users affected by this issue can work around the issue in one of the
> >> following ways.
> >> - Use wpa_supplicant with WPA2 only mode (specify wpa_key_mgmt=WPA-PSK)
> >> - Use FRITZ!Box 7580/7590 with WPA2 only mode
> >> - Use IEEE 802.11w supporting Wi-Fi NIC
> >
>
> Masashi, if I understand you correctly, you argue that this is an issue
> with the AP (or its firmware).
>
> If so, should the company AVM be contacted about this?
> I'm afraid I'm not too knowledgeable in that regard.
> _______________________________________________
> Hostap mailing list
> Hos...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap
> with the AP (or its firmware).
> If so, should the company AVM be contacted about this?
> I'm afraid I'm not too knowledgeable in that regard.
Michael, Hans-Peter Jansen already reported to AVM at 2022-02-06
(https://bugzilla.opensuse.org/show_bug.cgi?id=1195395).
According to his latest comment,
"Just a heads up: AVM is still investigating on this. Some tests with
newer hardware confirmed, that WPA3 is working well there."
2022年3月25日(金) 2:48 Michael Biebl <bi...@debian.org>:
>
> Some more data points:
>
> Disabling NetworkManager completely and using wpasupplicant alone with
> the following config:
>
> network={
> ssid="wgrouter"
> psk="<hidden>"
> key_mgmt=WPA-PSK
> id_str="wgrouter"
> }
>
> does indeed work.
>
> As soon as I enable NetworkManager though, my connection fails, even
> though /etc/NetworkManager/system-connections/wgrouter.nmconnection
> contains
>
> [wifi-security]
> key-mgmt=wpa-psk
> psk=<hidden>
>
> In journalctl -u NetworkManager I see
>
> Mär 21 11:15:07 pluto NetworkManager[2450]: <info> [1647857707.7752]
> Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE'
>
>
> Ľubomír, is there a way how I can tell NetworkManager to *not* use SAE?
>
>
>
> Am 21.03.22 um 09:38 schrieb Andrej Shadura:
> > Hi,
> >
> > On Sun, 20 Mar 2022, at 00:23, Masashi Honma wrote:
> >> In my opinion, this issue could be closed.
> >>
> >> These are reasons.
> >> 1) It is not wpa_supplicant issue but AP issue.
> >> 2) Users affected by this issue have some workarounds.
> >
> > It’s true, but I’m not quite happy about not being able to fix this.
> >
> > Ľubomír (cc'ed), how did you deal with this issue in Fedora? I assume you must also have received reports from Fritzbox users.
> >
> >> Details of the 1)
> >> The investigation has revealed that the AP is in violation of "2.3
> >> WPA3-Personal transition mode" of the "WPA3 Specification v3.0", which
> >> is causing the issue. Specifically, the target AP is setting MFPR to 1
> >> even though it implicitly requires IEEE 802.11w. By "implicitly" we
> >> mean that the Assocation Request fails with WLAN_STATUS_INVALID_IE
> >> when using a Wi-Fi NIC with IEEE 802.11w disabled.
> >>
> >>
> >> Details of the 2)
> >> We know that users who meet the following conditions are affected by this issue.
> >> - Using FRITZ!Box 7580/7590 with WPA2+WPA3 mode
>
> I've tested it with both 7490 and 7530 AX, fwiw.
>
> >> - Using wpa_supplicant with wpa_key_mgmt=SAE WPA-PSK
> >> - Local Wi-Fi NIC does not support IEEE802.11w
> >>
> >> Users affected by this issue can work around the issue in one of the
> >> following ways.
> >> - Use wpa_supplicant with WPA2 only mode (specify wpa_key_mgmt=WPA-PSK)
> >> - Use FRITZ!Box 7580/7590 with WPA2 only mode
> >> - Use IEEE 802.11w supporting Wi-Fi NIC
> >
>
> Masashi, if I understand you correctly, you argue that this is an issue
> with the AP (or its firmware).
>
> If so, should the company AVM be contacted about this?
> I'm afraid I'm not too knowledgeable in that regard.
> _______________________________________________
> Hostap mailing list
> Hos...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap
Michael Biebl
Apr 4, 2022, 5:00:03 AM4/4/22
to
On Fri, 25 Mar 2022 07:07:03 +0900 Masashi Honma
<masash...@gmail.com> wrote:
> > Masashi, if I understand you correctly, you argue that this is an issue
> > with the AP (or its firmware).
>
> > If so, should the company AVM be contacted about this?
> > I'm afraid I'm not too knowledgeable in that regard.
>
> Michael, Hans-Peter Jansen already reported to AVM at 2022-02-06
> (https://bugzilla.opensuse.org/show_bug.cgi?id=1195395).
>
> According to his latest comment,
> "Just a heads up: AVM is still investigating on this. Some tests with
> newer hardware confirmed, that WPA3 is working well there."
>
were quite dismissive and didn't really acknowledge the problem. The
support ticked was closed subsequently. I didn't further pursue this route.
That said, there might be a workaround available in NetworkManager
I filed
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/964
and a potential fix is now available in
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1175
Thanks Beniamino and Thomas!
Andrew, could we keep this bug report at RC until we have a fix?
Even if the fix means a workaround in NM.
Regards,
Michael
Michael Biebl
Apr 8, 2022, 4:20:04 AM4/8/22
to
Am 08.04.22 um 09:56 schrieb Andrej Shadura:
> Hi,
Once NM is in testing for a couple of days, feel free to close the bug
report.
Regards,
Michael
> Hi,
>
> On Mon, 4 Apr 2022, at 10:47, Michael Biebl wrote:
>> That said, there might be a workaround available in NetworkManager
>> I filed
>> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/964
>> and a potential fix is now available in
>>
>> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1175
>>
>> Thanks Beniamino and Thomas!
>>
>>
>> Andrew, could we keep this bug report at RC until we have a fix?
>> Even if the fix means a workaround in NM.
>
> I noticed you uploaded the workaround to Debian, and it’s about to migrate to testing — how about downgrading the bug from release-critical? Assuming that it actually helps.
> On Mon, 4 Apr 2022, at 10:47, Michael Biebl wrote:
>> That said, there might be a workaround available in NetworkManager
>> I filed
>> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/964
>> and a potential fix is now available in
>>
>> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1175
>>
>> Thanks Beniamino and Thomas!
>>
>>
>> Andrew, could we keep this bug report at RC until we have a fix?
>> Even if the fix means a workaround in NM.
>
Once NM is in testing for a couple of days, feel free to close the bug
report.
Regards,
Michael
Michael Biebl
Apr 8, 2022, 5:50:04 PM4/8/22
to
Hi
Am 08.04.22 um 10:11 schrieb Michael Biebl:
> Am 08.04.22 um 09:56 schrieb Andrej Shadura:
>> I noticed you uploaded the workaround to Debian, and it’s about to
>> migrate to testing — how about downgrading the bug from
>> release-critical? Assuming that it actually helps.
>
> Once NM is in testing for a couple of days, feel free to close the bug
> report.
Hm, you could add a versioned Breaks against network-manager to ensure
>> migrate to testing — how about downgrading the bug from
>> release-critical? Assuming that it actually helps.
>
> Once NM is in testing for a couple of days, feel free to close the bug
> report.
you have at least NM 1.36.4-2 together with wpasupplicant 2.10. I'll
leave that up to you.
Regards,
Michael
0 new messages