Connection to a WPA2 Wi-Fi router fails

Connection to a WPA2 Wi-Fi router fails

[François Galea]

Hello,

This was tested on a Zynq (Cortex-A9) and a RPi4, on a 32-bit Arm 
Buildroot Linux system.

The Wi-Fi router uses WPA2 Personnal authentication.

Problem starts from buildroot releases including connman 1.45. Previous 
releases using connman 1.44 and prior are working fine. Also switching 
from 1.45 to 1.44 in a buildroot version that includes connman 1.45 works.


If a connection was previously successfully set up, for instance from 
connman 1.44 or older, `/var/log/messages` contains:

Jan  1 00:00:11 zest daemon.info connmand[141]: Adding interface wlan0 [ 
wifi ]
Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {update} flags 
36867 <UP>
Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {newlink} index 2 
address 9A:8F:85:81:67:B4 mtu 1500
Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {newlink} index 2 
operstate 2 <DOWN>
Jan  1 00:00:11 zest daemon.info dbus-daemon[120]: [system] Successfully 
activated service 'fi.w1.wpa_supplicant1'
Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags 
36931 <UP,RUNNING>
Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4 
address 8C:3D:16:20:0E:4A mtu 1500
Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4 
operstate 0 <UNKNOWN>
Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags 
36867 <UP>
Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4 
address 8C:3D:16:20:0E:4A mtu 1500
Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4 
operstate 2 <DOWN>
Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4 
address 8C:3D:16:20:0E:4A mtu 1500
Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4 
operstate 2 <DOWN>
Jan  1 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi ] 
state is association
Jan  1 00:00:11 zest daemon.warn connmand[141]: Interface wlan0 [ wifi ] 
error "invalid-key"
Jan  1 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi ] 
state is failure


Otherwise, when creating a new connection:

# connmanctl
Error getting VPN connections: The name net.connman.vpn was not provided 
by any .service files
connmanctl> services

connmanctl> enable wifi
Enabled wifi
connmanctl> scan wifi
Scan completed for wifi
connmanctl> services
     Kamoulox             wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
     Livebox-D050 
wifi_8c3d16200e4a_4c697665626f782d44303530_managed_psk
     Freebox-3B4B3C 
wifi_8c3d16200e4a_46726565626f782d334234423343_managed_psk
     patetalex            wifi_8c3d16200e4a_7061746574616c6578_managed_psk
     DRAME                wifi_8c3d16200e4a_4452414d45_managed_psk
connmanctl> agent on
Agent registered
connmanctl> connect wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
Agent RequestInput wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
   Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
   WPS = [ Type=wpspin, Requirement=alternate ]
Passphrase? my_wifi_passphrase
Agent ReportError wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
   invalid-key
connmanctl> Retry (yes/no)? no
Error 
/net/connman/service/wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk: 
Input/output error
connmanctl>


 From both situations it appears the wifi passphrase is not accepted.

wbx (as CC of this email) noticed that reverting commit 
5e73b55e00b97e1867397258b72f0d6e5ad7d31d allows connections to work again.

Is it a known situation? Is there a patch available?

Best,

François

Re: Connection to a WPA2 Wi-Fi router fails

[Michael Nazzareno Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 4333 bytes --]

Hi

On Tue, May 12, 2026 at 11:14 AM François Galea <fgalea@free.fr> wrote:
>
> Hello,
>
> This was tested on a Zynq (Cortex-A9) and a RPi4, on a 32-bit Arm
> Buildroot Linux system.
>
> The Wi-Fi router uses WPA2 Personnal authentication.
>
> Problem starts from buildroot releases including connman 1.45. Previous
> releases using connman 1.44 and prior are working fine. Also switching
> from 1.45 to 1.44 in a buildroot version that includes connman 1.45 works.
>
>
> If a connection was previously successfully set up, for instance from
> connman 1.44 or older, `/var/log/messages` contains:
>
> Jan  1 00:00:11 zest daemon.info connmand[141]: Adding interface wlan0 [
> wifi ]
> Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {update} flags
> 36867 <UP>
> Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {newlink} index 2
> address 9A:8F:85:81:67:B4 mtu 1500
> Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {newlink} index 2
> operstate 2 <DOWN>
> Jan  1 00:00:11 zest daemon.info dbus-daemon[120]: [system] Successfully
> activated service 'fi.w1.wpa_supplicant1'
> Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> 36931 <UP,RUNNING>
> Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> address 8C:3D:16:20:0E:4A mtu 1500
> Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> operstate 0 <UNKNOWN>
> Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> 36867 <UP>
> Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> address 8C:3D:16:20:0E:4A mtu 1500
> Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> operstate 2 <DOWN>
> Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> address 8C:3D:16:20:0E:4A mtu 1500
> Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> operstate 2 <DOWN>
> Jan  1 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi ]
> state is association
> Jan  1 00:00:11 zest daemon.warn connmand[141]: Interface wlan0 [ wifi ]
> error "invalid-key"
> Jan  1 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi ]
> state is failure
>
>
> Otherwise, when creating a new connection:
>
> # connmanctl
> Error getting VPN connections: The name net.connman.vpn was not provided
> by any .service files
> connmanctl> services
>
> connmanctl> enable wifi
> Enabled wifi
> connmanctl> scan wifi
> Scan completed for wifi
> connmanctl> services
>      Kamoulox             wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
>      Livebox-D050
> wifi_8c3d16200e4a_4c697665626f782d44303530_managed_psk
>      Freebox-3B4B3C
> wifi_8c3d16200e4a_46726565626f782d334234423343_managed_psk
>      patetalex            wifi_8c3d16200e4a_7061746574616c6578_managed_psk
>      DRAME                wifi_8c3d16200e4a_4452414d45_managed_psk
> connmanctl> agent on
> Agent registered
> connmanctl> connect wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> Agent RequestInput wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
>    Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
>    WPS = [ Type=wpspin, Requirement=alternate ]
> Passphrase? my_wifi_passphrase
> Agent ReportError wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
>    invalid-key
> connmanctl> Retry (yes/no)? no
> Error
> /net/connman/service/wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk:
> Input/output error
> connmanctl>


I think that change only asks the agent who established the connection
to try the various method. Is the patch in attach work?
* sven *: Does it cover your use case too?

Michael


>
>
>
>  From both situations it appears the wifi passphrase is not accepted.
>
> wbx (as CC of this email) noticed that reverting commit
> 5e73b55e00b97e1867397258b72f0d6e5ad7d31d allows connections to work again.
>
> Is it a known situation? Is there a patch available?
>
> Best,
>
> François
>
>


-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

[-- Attachment #2: auth.patch --]
[-- Type: text/x-patch, Size: 939 bytes --]

diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 5e289953..b1880574 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -4955,8 +4955,15 @@ static void add_network_security(DBusMessageIter *dict, GSupplicantSSID *ssid)
 		add_network_security_ciphers(dict, ssid);
 		break;
 	case G_SUPPLICANT_SECURITY_PSK:
-		key_mgmt = "SAE WPA-PSK WPA-PSK-SHA256";
-		ieee80211w = G_SUPPLICANT_MFP_OPTIONAL;
+		if (ssid->keymgmt & G_SUPPLICANT_KEYMGMT_SAE) {
+			// AP supports SAE, so we provide the full suite for roaming/transition
+			key_mgmt = "SAE WPA-PSK WPA-PSK-SHA256";
+			ieee80211w = G_SUPPLICANT_MFP_OPTIONAL;
+		} else {
+			// AP is legacy; don't confuse it with SAE/SHA256 strings
+			key_mgmt = "WPA-PSK";
+			ieee80211w = G_SUPPLICANT_MFP_OPTIONAL;
+		}
 		add_network_ieee80211w(dict, ssid, ieee80211w);
 		add_network_security_psk(dict, ssid);
 		add_network_security_ciphers(dict, ssid);

Re: Connection to a WPA2 Wi-Fi router fails

[François Galea]

Le 12/05/2026 à 11:32, Michael Nazzareno Trimarchi a écrit :
> 
> I think that change only asks the agent who established the connection
> to try the various method. Is the patch in attach work?
> * sven *: Does it cover your use case too?
> 
> Michael
> 

Thank you for your quick reply.

I applied the patch to the connman git master branch and I can confirm 
it works. Thanks!

François

RE: Connection to a WPA2 Wi-Fi router fails

[Dembianny Sven (BSH GDE-EDSD7)]

Hi Michael,

I don't think so, e.g., if AP does not support SAE but repeater does, roaming will fail.
This will also break certification tests.

@ François do you have more info about your setup, e.g. MFP setting on AP/wpa_supplicant config/WPA-PSK-SHA256 instead of WPA-PSK?

Best regards, Sven

> -----Original Message-----
> From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> Sent: Dienstag, 12. Mai 2026 11:33
> To: François Galea <fgalea@free.fr>; Dembianny Sven (BSH GDE-EDSD7) <sven.dembianny@bshg.com>
> Cc: connman@lists.linux.dev; wbx@openadk.org
> Subject: Re: Connection to a WPA2 Wi-Fi router fails
>
> Hi
>
> On Tue, May 12, 2026 at 11:14 AM François Galea <fgalea@free.fr> wrote:
> >
> > Hello,
> >
> > This was tested on a Zynq (Cortex-A9) and a RPi4, on a 32-bit Arm
> > Buildroot Linux system.
> >
> > The Wi-Fi router uses WPA2 Personnal authentication.
> >
> > Problem starts from buildroot releases including connman 1.45.
> > Previous releases using connman 1.44 and prior are working fine. Also
> > switching from 1.45 to 1.44 in a buildroot version that includes connman 1.45 works.
> >
> >
> > If a connection was previously successfully set up, for instance from
> > connman 1.44 or older, `/var/log/messages` contains:
> >
> > Jan  1 00:00:11 zest daemon.info connmand[141]: Adding interface wlan0
> > [ wifi ] Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {update}
> > flags
> > 36867 <UP>
> > Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {newlink} index 2
> > address 9A:8F:85:81:67:B4 mtu 1500 Jan  1 00:00:11 zest daemon.info
> > connmand[141]: eth0 {newlink} index 2 operstate 2 <DOWN> Jan  1
> > 00:00:11 zest daemon.info dbus-daemon[120]: [system] Successfully
> > activated service 'fi.w1.wpa_supplicant1'
> > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> > 36931 <UP,RUNNING>
> > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index
> > 4 address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > connmand[141]: wlan0 {newlink} index 4 operstate 0 <UNKNOWN> Jan  1
> > 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> > 36867 <UP>
> > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index
> > 4 address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > connmand[141]: wlan0 {newlink} index 4 operstate 2 <DOWN> Jan  1
> > 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> > address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > connmand[141]: wlan0 {newlink} index 4 operstate 2 <DOWN> Jan  1
> > 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi ]
> > state is association Jan  1 00:00:11 zest daemon.warn connmand[141]:
> > Interface wlan0 [ wifi ] error "invalid-key"
> > Jan  1 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi
> > ] state is failure
> >
> >
> > Otherwise, when creating a new connection:
> >
> > # connmanctl
> > Error getting VPN connections: The name net.connman.vpn was not
> > provided by any .service files
> > connmanctl> services
> >
> > connmanctl> enable wifi
> > Enabled wifi
> > connmanctl> scan wifi
> > Scan completed for wifi
> > connmanctl> services
> >      Kamoulox             wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> >      Livebox-D050
> > wifi_8c3d16200e4a_4c697665626f782d44303530_managed_psk
> >      Freebox-3B4B3C
> > wifi_8c3d16200e4a_46726565626f782d334234423343_managed_psk
> >      patetalex            wifi_8c3d16200e4a_7061746574616c6578_managed_psk
> >      DRAME                wifi_8c3d16200e4a_4452414d45_managed_psk
> > connmanctl> agent on
> > Agent registered
> > connmanctl> connect wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > Agent RequestInput wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> >    Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
> >    WPS = [ Type=wpspin, Requirement=alternate ] Passphrase?
> > my_wifi_passphrase Agent ReportError
> > wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> >    invalid-key
> > connmanctl> Retry (yes/no)? no
> > Error
> > /net/connman/service/wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk:
> > Input/output error
> > connmanctl>
>
>
> I think that change only asks the agent who established the connection to try the various method. Is
> the patch in attach work?
> * sven *: Does it cover your use case too?
>
> Michael
>
>
> >
> >
> >
> >  From both situations it appears the wifi passphrase is not accepted.
> >
> > wbx (as CC of this email) noticed that reverting commit
> > 5e73b55e00b97e1867397258b72f0d6e5ad7d31d allows connections to work again.
> >
> > Is it a known situation? Is there a patch available?
> >
> > Best,
> >
> > François
> >
> >
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> michael@amarulasolutions.com
> __________________________________
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com
> http://www.amarulasolutions.com/
> &data=05%7C02%7Csven.dembianny%40bshg.com%7Cf4aa618e280e45c3d76e08deb0096f57%7C0ae5
> 1e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C639141751758647935%7CUnknown%7CTWFpbGZsb3
> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> %3D%3D%7C0%7C%7C%7C&sdata=8tD7KmAQSPxg%2BRZ0yB7MYBeWVudCjvw4T4MJhOHy3%2Fk%3D
> &reserved=0

Re: Connection to a WPA2 Wi-Fi router fails

[Michael Nazzareno Trimarchi]

Hi Sven

On Tue, May 19, 2026 at 4:16 PM Dembianny Sven (BSH GDE-EDSD7)
<sven.dembianny@bshg.com> wrote:
>
> Hi Michael,
>
> I don't think so, e.g., if AP does not support SAE but repeater does, roaming will fail.
> This will also break certification tests.
>

Ok I was thinking about it but at the same time we should have access
point / wifi driver that fails in this connection case.  This patch
was only ment to understand where the problem sit

> @ François do you have more info about your setup, e.g. MFP setting on AP/wpa_supplicant config/WPA-PSK-SHA256 instead of WPA-PSK?
>

Michael

> Best regards, Sven
>
> > -----Original Message-----
> > From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> > Sent: Dienstag, 12. Mai 2026 11:33
> > To: François Galea <fgalea@free.fr>; Dembianny Sven (BSH GDE-EDSD7) <sven.dembianny@bshg.com>
> > Cc: connman@lists.linux.dev; wbx@openadk.org
> > Subject: Re: Connection to a WPA2 Wi-Fi router fails
> >
> > Hi
> >
> > On Tue, May 12, 2026 at 11:14 AM François Galea <fgalea@free.fr> wrote:
> > >
> > > Hello,
> > >
> > > This was tested on a Zynq (Cortex-A9) and a RPi4, on a 32-bit Arm
> > > Buildroot Linux system.
> > >
> > > The Wi-Fi router uses WPA2 Personnal authentication.
> > >
> > > Problem starts from buildroot releases including connman 1.45.
> > > Previous releases using connman 1.44 and prior are working fine. Also
> > > switching from 1.45 to 1.44 in a buildroot version that includes connman 1.45 works.
> > >
> > >
> > > If a connection was previously successfully set up, for instance from
> > > connman 1.44 or older, `/var/log/messages` contains:
> > >
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: Adding interface wlan0
> > > [ wifi ] Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {update}
> > > flags
> > > 36867 <UP>
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {newlink} index 2
> > > address 9A:8F:85:81:67:B4 mtu 1500 Jan  1 00:00:11 zest daemon.info
> > > connmand[141]: eth0 {newlink} index 2 operstate 2 <DOWN> Jan  1
> > > 00:00:11 zest daemon.info dbus-daemon[120]: [system] Successfully
> > > activated service 'fi.w1.wpa_supplicant1'
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> > > 36931 <UP,RUNNING>
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index
> > > 4 address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > > connmand[141]: wlan0 {newlink} index 4 operstate 0 <UNKNOWN> Jan  1
> > > 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> > > 36867 <UP>
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index
> > > 4 address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > > connmand[141]: wlan0 {newlink} index 4 operstate 2 <DOWN> Jan  1
> > > 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> > > address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > > connmand[141]: wlan0 {newlink} index 4 operstate 2 <DOWN> Jan  1
> > > 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi ]
> > > state is association Jan  1 00:00:11 zest daemon.warn connmand[141]:
> > > Interface wlan0 [ wifi ] error "invalid-key"
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi
> > > ] state is failure
> > >
> > >
> > > Otherwise, when creating a new connection:
> > >
> > > # connmanctl
> > > Error getting VPN connections: The name net.connman.vpn was not
> > > provided by any .service files
> > > connmanctl> services
> > >
> > > connmanctl> enable wifi
> > > Enabled wifi
> > > connmanctl> scan wifi
> > > Scan completed for wifi
> > > connmanctl> services
> > >      Kamoulox             wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > >      Livebox-D050
> > > wifi_8c3d16200e4a_4c697665626f782d44303530_managed_psk
> > >      Freebox-3B4B3C
> > > wifi_8c3d16200e4a_46726565626f782d334234423343_managed_psk
> > >      patetalex            wifi_8c3d16200e4a_7061746574616c6578_managed_psk
> > >      DRAME                wifi_8c3d16200e4a_4452414d45_managed_psk
> > > connmanctl> agent on
> > > Agent registered
> > > connmanctl> connect wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > > Agent RequestInput wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > >    Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
> > >    WPS = [ Type=wpspin, Requirement=alternate ] Passphrase?
> > > my_wifi_passphrase Agent ReportError
> > > wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > >    invalid-key
> > > connmanctl> Retry (yes/no)? no
> > > Error
> > > /net/connman/service/wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk:
> > > Input/output error
> > > connmanctl>
> >
> >
> > I think that change only asks the agent who established the connection to try the various method. Is
> > the patch in attach work?
> > * sven *: Does it cover your use case too?
> >
> > Michael
> >
> >
> > >
> > >
> > >
> > >  From both situations it appears the wifi passphrase is not accepted.
> > >
> > > wbx (as CC of this email) noticed that reverting commit
> > > 5e73b55e00b97e1867397258b72f0d6e5ad7d31d allows connections to work again.
> > >
> > > Is it a known situation? Is there a patch available?
> > >
> > > Best,
> > >
> > > François
> > >
> > >
> >
> >
> > --
> > Michael Nazzareno Trimarchi
> > Co-Founder & Chief Executive Officer
> > M. +39 347 913 2170
> > michael@amarulasolutions.com
> > __________________________________
> >
> > Amarula Solutions BV
> > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com
> > http://www.amarulasolutions.com/
> > &data=05%7C02%7Csven.dembianny%40bshg.com%7Cf4aa618e280e45c3d76e08deb0096f57%7C0ae5
> > 1e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C639141751758647935%7CUnknown%7CTWFpbGZsb3
> > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> > %3D%3D%7C0%7C%7C%7C&sdata=8tD7KmAQSPxg%2BRZ0yB7MYBeWVudCjvw4T4MJhOHy3%2Fk%3D
> > &reserved=0



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

Re: Connection to a WPA2 Wi-Fi router fails

[Waldemar Brodkorb]

Hi Sven,
Dembianny Sven (BSH GDE-EDSD7) wrote,

> Hi Michael,
> 
> I don't think so, e.g., if AP does not support SAE but repeater does, roaming will fail.
> This will also break certification tests.
> 
> @ François do you have more info about your setup, e.g. MFP setting on AP/wpa_supplicant config/WPA-PSK-SHA256 instead of WPA-PSK?

Sorry for the late reply. Francois seems not to answered your
question and I see no fixes for this problem in GIT master either.

My AP is a standard Vodafone AP with WPA2.
How can I give you better information about the details of this AP?

best regards
 Waldemar
 
> Best regards, Sven
> 
> > -----Original Message-----
> > From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> > Sent: Dienstag, 12. Mai 2026 11:33
> > To: François Galea <fgalea@free.fr>; Dembianny Sven (BSH GDE-EDSD7) <sven.dembianny@bshg.com>
> > Cc: connman@lists.linux.dev; wbx@openadk.org
> > Subject: Re: Connection to a WPA2 Wi-Fi router fails
> >
> > Hi
> >
> > On Tue, May 12, 2026 at 11:14 AM François Galea <fgalea@free.fr> wrote:
> > >
> > > Hello,
> > >
> > > This was tested on a Zynq (Cortex-A9) and a RPi4, on a 32-bit Arm
> > > Buildroot Linux system.
> > >
> > > The Wi-Fi router uses WPA2 Personnal authentication.
> > >
> > > Problem starts from buildroot releases including connman 1.45.
> > > Previous releases using connman 1.44 and prior are working fine. Also
> > > switching from 1.45 to 1.44 in a buildroot version that includes connman 1.45 works.
> > >
> > >
> > > If a connection was previously successfully set up, for instance from
> > > connman 1.44 or older, `/var/log/messages` contains:
> > >
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: Adding interface wlan0
> > > [ wifi ] Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {update}
> > > flags
> > > 36867 <UP>
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {newlink} index 2
> > > address 9A:8F:85:81:67:B4 mtu 1500 Jan  1 00:00:11 zest daemon.info
> > > connmand[141]: eth0 {newlink} index 2 operstate 2 <DOWN> Jan  1
> > > 00:00:11 zest daemon.info dbus-daemon[120]: [system] Successfully
> > > activated service 'fi.w1.wpa_supplicant1'
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> > > 36931 <UP,RUNNING>
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index
> > > 4 address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > > connmand[141]: wlan0 {newlink} index 4 operstate 0 <UNKNOWN> Jan  1
> > > 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> > > 36867 <UP>
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index
> > > 4 address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > > connmand[141]: wlan0 {newlink} index 4 operstate 2 <DOWN> Jan  1
> > > 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> > > address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest daemon.info
> > > connmand[141]: wlan0 {newlink} index 4 operstate 2 <DOWN> Jan  1
> > > 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi ]
> > > state is association Jan  1 00:00:11 zest daemon.warn connmand[141]:
> > > Interface wlan0 [ wifi ] error "invalid-key"
> > > Jan  1 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi
> > > ] state is failure
> > >
> > >
> > > Otherwise, when creating a new connection:
> > >
> > > # connmanctl
> > > Error getting VPN connections: The name net.connman.vpn was not
> > > provided by any .service files
> > > connmanctl> services
> > >
> > > connmanctl> enable wifi
> > > Enabled wifi
> > > connmanctl> scan wifi
> > > Scan completed for wifi
> > > connmanctl> services
> > >      Kamoulox             wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > >      Livebox-D050
> > > wifi_8c3d16200e4a_4c697665626f782d44303530_managed_psk
> > >      Freebox-3B4B3C
> > > wifi_8c3d16200e4a_46726565626f782d334234423343_managed_psk
> > >      patetalex            wifi_8c3d16200e4a_7061746574616c6578_managed_psk
> > >      DRAME                wifi_8c3d16200e4a_4452414d45_managed_psk
> > > connmanctl> agent on
> > > Agent registered
> > > connmanctl> connect wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > > Agent RequestInput wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > >    Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
> > >    WPS = [ Type=wpspin, Requirement=alternate ] Passphrase?
> > > my_wifi_passphrase Agent ReportError
> > > wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > >    invalid-key
> > > connmanctl> Retry (yes/no)? no
> > > Error
> > > /net/connman/service/wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk:
> > > Input/output error
> > > connmanctl>
> >
> >
> > I think that change only asks the agent who established the connection to try the various method. Is
> > the patch in attach work?
> > * sven *: Does it cover your use case too?
> >
> > Michael
> >
> >
> > >
> > >
> > >
> > >  From both situations it appears the wifi passphrase is not accepted.
> > >
> > > wbx (as CC of this email) noticed that reverting commit
> > > 5e73b55e00b97e1867397258b72f0d6e5ad7d31d allows connections to work again.
> > >
> > > Is it a known situation? Is there a patch available?
> > >
> > > Best,
> > >
> > > François
> > >
> > >
> >
> >
> > --
> > Michael Nazzareno Trimarchi
> > Co-Founder & Chief Executive Officer
> > M. +39 347 913 2170
> > michael@amarulasolutions.com
> > __________________________________
> >
> > Amarula Solutions BV
> > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com
> > http://www.amarulasolutions.com/
> > &data=05%7C02%7Csven.dembianny%40bshg.com%7Cf4aa618e280e45c3d76e08deb0096f57%7C0ae5
> > 1e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C639141751758647935%7CUnknown%7CTWFpbGZsb3
> > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> > %3D%3D%7C0%7C%7C%7C&sdata=8tD7KmAQSPxg%2BRZ0yB7MYBeWVudCjvw4T4MJhOHy3%2Fk%3D
> > &reserved=0

RE: Connection to a WPA2 Wi-Fi router fails

[Dembianny Sven (BSH GDE-EDSD7)]

Hi Waldemar,
> 
> Hi Sven,
> Dembianny Sven (BSH GDE-EDSD7) wrote,
> 
> > Hi Michael,
> >
> > I don't think so, e.g., if AP does not support SAE but repeater does, roaming will fail.
> > This will also break certification tests.
> >
> > @ François do you have more info about your setup, e.g. MFP setting on AP/wpa_supplicant
> config/WPA-PSK-SHA256 instead of WPA-PSK?
> 
> Sorry for the late reply. Francois seems not to answered your question and I see no fixes for this
> problem in GIT master either.
> 
> My AP is a standard Vodafone AP with WPA2.
> How can I give you better information about the details of this AP?
What model is being used?
It is possible that MFP is additionally configured as optional. Could you please check the AP settings or the beacon frames?

Also, what firmware version is running on the Raspberry Pi 4? The firmware files should be located under:
/lib/firmware/

Best regards,  Sven
> best regards
>  Waldemar
> 
> > Best regards, Sven
> >
> > > -----Original Message-----
> > > From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> > > Sent: Dienstag, 12. Mai 2026 11:33
> > > To: François Galea <fgalea@free.fr>; Dembianny Sven (BSH GDE-EDSD7)
> > > <sven.dembianny@bshg.com>
> > > Cc: connman@lists.linux.dev; wbx@openadk.org
> > > Subject: Re: Connection to a WPA2 Wi-Fi router fails
> > >
> > > Hi
> > >
> > > On Tue, May 12, 2026 at 11:14 AM François Galea <fgalea@free.fr> wrote:
> > > >
> > > > Hello,
> > > >
> > > > This was tested on a Zynq (Cortex-A9) and a RPi4, on a 32-bit Arm
> > > > Buildroot Linux system.
> > > >
> > > > The Wi-Fi router uses WPA2 Personnal authentication.
> > > >
> > > > Problem starts from buildroot releases including connman 1.45.
> > > > Previous releases using connman 1.44 and prior are working fine.
> > > > Also switching from 1.45 to 1.44 in a buildroot version that includes connman 1.45 works.
> > > >
> > > >
> > > > If a connection was previously successfully set up, for instance
> > > > from connman 1.44 or older, `/var/log/messages` contains:
> > > >
> > > > Jan  1 00:00:11 zest daemon.info connmand[141]: Adding interface
> > > > wlan0 [ wifi ] Jan  1 00:00:11 zest daemon.info connmand[141]:
> > > > eth0 {update} flags
> > > > 36867 <UP>
> > > > Jan  1 00:00:11 zest daemon.info connmand[141]: eth0 {newlink}
> > > > index 2 address 9A:8F:85:81:67:B4 mtu 1500 Jan  1 00:00:11 zest
> > > > daemon.info
> > > > connmand[141]: eth0 {newlink} index 2 operstate 2 <DOWN> Jan  1
> > > > 00:00:11 zest daemon.info dbus-daemon[120]: [system] Successfully
> > > > activated service 'fi.w1.wpa_supplicant1'
> > > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {update}
> > > > flags
> > > > 36931 <UP,RUNNING>
> > > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink}
> > > > index
> > > > 4 address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest
> > > > daemon.info
> > > > connmand[141]: wlan0 {newlink} index 4 operstate 0 <UNKNOWN> Jan
> > > > 1
> > > > 00:00:11 zest daemon.info connmand[141]: wlan0 {update} flags
> > > > 36867 <UP>
> > > > Jan  1 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink}
> > > > index
> > > > 4 address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest
> > > > daemon.info
> > > > connmand[141]: wlan0 {newlink} index 4 operstate 2 <DOWN> Jan  1
> > > > 00:00:11 zest daemon.info connmand[141]: wlan0 {newlink} index 4
> > > > address 8C:3D:16:20:0E:4A mtu 1500 Jan  1 00:00:11 zest
> > > > daemon.info
> > > > connmand[141]: wlan0 {newlink} index 4 operstate 2 <DOWN> Jan  1
> > > > 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [ wifi ]
> > > > state is association Jan  1 00:00:11 zest daemon.warn connmand[141]:
> > > > Interface wlan0 [ wifi ] error "invalid-key"
> > > > Jan  1 00:00:11 zest daemon.info connmand[141]: Interface wlan0 [
> > > > wifi ] state is failure
> > > >
> > > >
> > > > Otherwise, when creating a new connection:
> > > >
> > > > # connmanctl
> > > > Error getting VPN connections: The name net.connman.vpn was not
> > > > provided by any .service files
> > > > connmanctl> services
> > > >
> > > > connmanctl> enable wifi
> > > > Enabled wifi
> > > > connmanctl> scan wifi
> > > > Scan completed for wifi
> > > > connmanctl> services
> > > >      Kamoulox             wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > > >      Livebox-D050
> > > > wifi_8c3d16200e4a_4c697665626f782d44303530_managed_psk
> > > >      Freebox-3B4B3C
> > > > wifi_8c3d16200e4a_46726565626f782d334234423343_managed_psk
> > > >      patetalex            wifi_8c3d16200e4a_7061746574616c6578_managed_psk
> > > >      DRAME                wifi_8c3d16200e4a_4452414d45_managed_psk
> > > > connmanctl> agent on
> > > > Agent registered
> > > > connmanctl> connect wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > > > Agent RequestInput wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > > >    Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
> > > >    WPS = [ Type=wpspin, Requirement=alternate ] Passphrase?
> > > > my_wifi_passphrase Agent ReportError
> > > > wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk
> > > >    invalid-key
> > > > connmanctl> Retry (yes/no)? no
> > > > Error
> > > > /net/connman/service/wifi_8c3d16200e4a_4b616d6f756c6f78_managed_psk:
> > > > Input/output error
> > > > connmanctl>
> > >
> > >
> > > I think that change only asks the agent who established the
> > > connection to try the various method. Is the patch in attach work?
> > > * sven *: Does it cover your use case too?
> > >
> > > Michael
> > >
> > >
> > > >
> > > >
> > > >
> > > >  From both situations it appears the wifi passphrase is not accepted.
> > > >
> > > > wbx (as CC of this email) noticed that reverting commit
> > > > 5e73b55e00b97e1867397258b72f0d6e5ad7d31d allows connections to work again.
> > > >
> > > > Is it a known situation? Is there a patch available?
> > > >
> > > > Best,
> > > >
> > > > François
> > > >
> > > >
> > >
> > >
> > > --
> > > Michael Nazzareno Trimarchi
> > > Co-Founder & Chief Executive Officer M. +39 347 913 2170
> > > michael@amarulasolutions.com __________________________________
> > >
> > > Amarula Solutions BV
> > > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172
> > > info@amarulasolutions.com
> > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> > > .amarulasolutions.com%2F&data=05%7C02%7Csven.dembianny%40bshg.com%7C
> > > 00a2bd14c2d74f32f2c208def5e13e36%7C0ae51e1907c84e4bbb6d648ee58410f4%
> > > 7C0%7C0%7C639218544918069416%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> > > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
> > > yfQ%3D%3D%7C0%7C%7C%7C&sdata=kxL6P7SRricrBgLeS4U18xAwP250HMfWS3uDowQ
> > > ZDaA%3D&reserved=0
> > > &data=05%7C02%7Csven.dembianny%40bshg.com%7Cf4aa618e280e45c3d76e08de
> > > b0096f57%7C0ae5
> > > 1e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C639141751758647935%7CUnknown%
> > > 7CTWFpbGZsb3
> > > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
> > > oiTWFpbCIsIldUIjoyfQ
> > > %3D%3D%7C0%7C%7C%7C&sdata=8tD7KmAQSPxg%2BRZ0yB7MYBeWVudCjvw4T4MJhOHy
> > > 3%2Fk%3D
> > > &reserved=0

Re: Connection to a WPA2 Wi-Fi router fails

[Waldemar Brodkorb]

Hi Sven,
Dembianny Sven (BSH GDE-EDSD7) wrote,

> Hi Waldemar,
> > 
> > Hi Sven,
> > Dembianny Sven (BSH GDE-EDSD7) wrote,
> > 
> > > Hi Michael,
> > >
> > > I don't think so, e.g., if AP does not support SAE but repeater does, roaming will fail.
> > > This will also break certification tests.
> > >
> > > @ François do you have more info about your setup, e.g. MFP setting on AP/wpa_supplicant
> > config/WPA-PSK-SHA256 instead of WPA-PSK?
> > 
> > Sorry for the late reply. Francois seems not to answered your question and I see no fixes for this
> > problem in GIT master either.
> > 
> > My AP is a standard Vodafone AP with WPA2.
> > How can I give you better information about the details of this AP?
> What model is being used?

Vodafone Wifi 6.
It is this one:
https://www.vodafone.de/downloadarea/CGA6444VF-DMS3-CTC-25-593_v2.0_German_public_20210511.pdf

> It is possible that MFP is additionally configured as optional. Could you please check the AP settings or the beacon frames?

It seems not.
See:
sudo iw dev wlan0 scan | grep -A20 -B2 'Vodafone-C30C'
	last seen: 84 ms ago
	Information elements from Probe Response frame:
	SSID: Vodafone-C30C
	Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0
	DS Parameter set: channel 11
	Country: DE	Environment: Indoor/Outdoor
		Channels [1 - 13] @ 20 dBm
	TPC report: TX power: 18 dBm
	ERP: Barker_Preamble_Mode
	Extended supported rates: 6.0 9.0 12.0 48.0
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: PSK
		 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
	BSS Load:
		 * station count: 2
		 * channel utilisation: 31/255
		 * available admission capacity: 0 [*32us]
	RM enabled capabilities:
		Capabilities: 0x72 0x00 0x00 0x00 0x00
			Neighbor Report
			Beacon Passive Measurement
--
	signal: -72.00 dBm
	last seen: 3208 ms ago
	SSID: Vodafone-C30C
	Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
	TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
	Country: DE	Environment: Indoor/Outdoor
		Channels [36 - 64] @ 23 dBm
		Channels [100 - 140] @ 30 dBm
	Power constraint: 0 dB
	TPC report: TX power: 23 dBm
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: PSK
		 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
	BSS Load:
		 * station count: 6
		 * channel utilisation: 6/255
		 * available admission capacity: 0 [*32us]
	RM enabled capabilities:
		Capabilities: 0x72 0x00 0x00 0x00 0x00
			Neighbor Report
			Beacon Passive Measurement

 
> Also, what firmware version is running on the Raspberry Pi 4? The firmware files should be located under:
> /lib/firmware/

That is the dmesg output after loading the Wifi driver in Buildroot:
[  249.369934] brcmfmac: F1 signature read @0x18000000=0x15264345
[  249.373427] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[  249.382449] usbcore: registered new interface driver brcmfmac
[  249.618723] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[  249.626771] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b

But at the moment I am fighting with connmanctl, it seems I cannot
scan wifi anymore:
# connmanctl scan wifi
Error /net/connman/technology/wifi: Not supported
# connmanctl enable wifi
wifi is already enabled
# connmanctl scan wifi
Error /net/connman/technology/wifi: Not supported
# connmanctl technologies
/net/connman/technology/ethernet
  Name = Wired
  Type = ethernet
  Powered = True
  Connected = False
  Tethering = False
  TetheringFreq = 2412
/net/connman/technology/wifi
  Name = WiFi
  Type = wifi
  Powered = True
  Connected = False
  Tethering = False
  TetheringFreq = 2412

I can scan wifi with iw on the RPI4.

best regards
 Waldemar