<div dir="ltr"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi Beniamino,<br><br></div>Thank you very much for your response <span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">and comprehensive explanation.<br></span></span></span></div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">Exactly this is what I did yesterday and finally managed to make it work.<br></span></span></span></div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">First sniffed the configuration that is injected by NetworkManager on the AP side,<br>---<br>Dec 21 18:36:35 NetworkManager[1475]: <info>  [1671647795.2306] Config: added 'ssid' value 'CLMAP'<br>Dec 21 18:36:35 NetworkManager[1475]: <info>  [1671647795.2309] Config: added 'mode' value '2'<br>Dec 21 18:36:35 NetworkManager[1475]: <info>  [1671647795.2311] Config: added 'frequency' value '2472'<br>Dec 21 18:36:35 NetworkManager[1475]: <info>  [1671647795.2313] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256'<br>Dec 21 18:36:35 NetworkManager[1475]: <info>  [1671647795.2315] Config: added 'psk' value '<hidden>'<br>---<br></span></span></span></div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">then added the key protocols on the client side, which runs the wpa supplicant only<br>---<br>network={        <br>        ssid="CLMAP"<br>+      key_mgmt=WPA-PSK WPA-PSK-SHA256<br>---<br><br></span></span></span></div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">For some reason, the RPi4 (Raspberry Pi 4 Model B Rev 1.5; Debian GNU/Linux 11 (bullseye)),<br>failed to select the correct key protocol, but the hint in the wpa configuration solve the problem.<br></span></span></span></div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">Thanks for your help!<br><br></span></span></span></div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">Best regards,<br></span></span></span></div><span class="gmail-HwtZe" lang="en"><span class="gmail-jCAhz gmail-ChMk0b"><span class="gmail-ryNqvb">Krystian Heberlein<br></span></span></span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 22 gru 2022 o 09:47 Beniamino Galvani <<a href="mailto:bgalvani@redhat.com">bgalvani@redhat.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 21, 2022 at 07:02:57PM +0100, Krystian Heberlein wrote:<br>
> Hi,<br>
> <br>
> Recently I was struggling to establish a connection with a WiFi Access<br>
> Point managed by NetworkManager with WPA supplicant plugin.<br>
> Although most available devices are able to connect with the AP, my<br>
> RasberryPi 4B won't cooperate.<br>
> On the RPi4 I'm trying to connect as a client with WPA supplicant, but<br>
> constantly the association gets rejected:<br>
<br>
Hi,<br>
<br>
the message about an invalid MIC can be caused either by a wrong<br>
password (but I suppose you checked that) or by a different<br>
key-management protocols selected on AP and STA. This last problem was<br>
supposedly fixed by commits [1][2], which are already included in NM<br>
1.38.0.<br>
<br>
[1] <a href="https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/a66e054bd67432673b8cc022c862937b95dae348" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/a66e054bd67432673b8cc022c862937b95dae348</a><br>
[2] <a href="https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/1a7db1d7f712d7696f64b089011bc45fc86e7924" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/1a7db1d7f712d7696f64b089011bc45fc86e7924</a><br>
<br>
Since you said that the same client is able to connect when using NM<br>
but not with wpa_supplicant alone, I would compare wpa_supplicant<br>
configuration with the the one sent by NM to the supplicant. After<br>
connecting with NM, do:<br>
<br>
  # journalctl -u NetworkManager -e | grep "Config: added "<br>
  <info>  [1671697112.3658] Config: added 'ssid' value 'Hotspot'<br>
  <info>  [1671697112.3658] Config: added 'mode' value '2'<br>
  <info>  [1671697112.3658] Config: added 'frequency' value '2462'<br>
  <info>  [1671697112.3658] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 SAE'<br>
  <info>  [1671697112.3658] Config: added 'psk' value '<hidden>'<br>
  <info>  [1671697112.3658] Config: added 'proto' value 'RSN'<br>
  <info>  [1671697112.3658] Config: added 'pairwise' value 'CCMP'<br>
  <info>  [1671697112.3659] Config: added 'group' value 'CCMP'<br>
<br>
and compare the values with wpa_supplicant configuration.<br>
<br>
If you have SAE in "key_mgmt", that could be the cause of the issue.<br>
NM adds SAE automatically when it detects it is supported by the<br>
supplicant; however if you disable PMF that would also disable SAE:<br>
<br>
  nmcli connection modify Hotspot wifi-sec.pmf disable<br>
  nmcli connection up Hotspot<br>
<br>
If none of the suggestions above work, increase the logging level of<br>
wpa_supplicant on both AP and client with:<br>
<br>
  # busctl set-property fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 fi.w1.wpa_supplicant1 DebugLevel s excessive<br>
<br>
then try to connect and analyze logs.<br>
<br>
Beniamino<br>
</blockquote></div><br></div>