iwd not connecting on Raspberry Pi with Raspbian

iwd not connecting on Raspberry Pi with Raspbian

[Patrick =?unknown-8bit?q?H=C3=A4cker?=]

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

Hello,

I try to get iwd running on a Raspberry Pi using a Raspbian kernel (5.4.59). 
The needed kernel options should be added (https://github.com/raspberrypi/
linux/issues/3547), wpa_supplicant works, I compiled a kernel adding 
CONFIG_KEY_DH_OPERATIONS (which was the only remaining complaint by iwd), 
upgraded to iwd 1.8 but had no success.

Now I am running out of ideas what else to try. The (hopefully) relevant part 
of iwd running in debug mode for 2.4 GHz:
> src/station.c:station_autoconnect_next() Considering autoconnecting to BSS
>     '98:9b:cb:4b:b1:cc' with SSID: auenstein, freq: 2472, rank: 7090,
>     strength:\0 -5600
> src/station.c:station_enter_state() Old State: autoconnect_quick, new
>     state: connecting
> src/station.c:station_netdev_event() Associating
> src/netdev.c:netdev_unicast_notify() Unicast notification 59
> src/netdev.c:netdev_mlme_notify() MLME notification Connect(46)
> src/netdev.c:netdev_connect_event()
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/wiphy.c:wiphy_reg_notify() Notification of command Reg Change(36)
> src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for
>     (global) is DE
> 4-Way handshake failed for ifindex: 3, reason: 15
> src/station.c:station_connect_cb() 3, result: 3
> src/station.c:station_disassociated() 3
> src/station.c:station_enter_state() Old State: connecting, new state:
>     disconnected\0

And the same for 5.6 GHz with a different error:
> src/station.c:station_autoconnect_next() Considering autoconnecting to BSS
>     '98:9b:cb:4b:b1:cd' with SSID: auenstein5G, freq: 5600, rank: 4592,
>     strength: -6500
> src/station.c:station_enter_state() Old State:
>     autoconnect_quick, new state: connecting
> src/station.c:station_netdev_event() Associating
> src/netdev.c:netdev_unicast_notify() Unicast notification 59
> src/netdev.c:netdev_mlme_notify() MLME notification Connect(46)
> src/netdev.c:netdev_connect_event()
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/wiphy.c:wiphy_reg_notify() Notification of command Reg Change(36)
> src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for
>     (global) is DE
> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
> src/netdev.c:netdev_disconnect_event()
> Received Deauthentication event, reason: 2, from_ap: false
> src/station.c:station_disconnect_event() 3
> src/station.c:station_disassociated() 3
> src/station.c:station_enter_state() Old State: connecting, new state:
> disconnected\0

I could imagine, that there is still a kernel module missing, but this is just 
guessing. Any hints how to continue debugging?

I still think that iwd would be a good match for the Raspberry Pi and ideally 
after this issue is fixed most Raspberry Pi user can switch to iwd if they 
like.

Kind regards
Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: iwd not connecting on Raspberry Pi with Raspbian

[KeithG]

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

Patrick,

I run iwd on RPi, but I am using Arch Linux. I've never tried it with
RaspiOS. Works pretty well, though I am having a re-connect issue that we
are trying to debug.

My guess is that you compiled the kernel to remove this message in the log:

Aug 23 22:52:24 rune64 iwd[235]: No Diffie-Hellman support found, WPS will
not be available
Aug 23 22:52:24 rune64 iwd[235]: The following options are missing in the
kernel:
Aug 23 22:52:24 rune64 iwd[235]:         CONFIG_KEY_DH_OPERATIONS

This is harmless and I have no problems connecting with this notification.
I think it means I cannot use WPS which I do not.

Are you trying to connect using the iwctl commands?

iwctl station wlan0 scan
iwctl station wlan0 get-networks
iwctl station wlan0 connect 'Network_Name"

It should return with

Type the network passphrase for "Network_Name" psk.
Passphrase: ********

or are you using connman to manage iwd?
Do you have an /etc/iwd/main.conf? If so, what is in it?

I assume you have enabled and started iwd.

Keith


On Sat, Aug 29, 2020 at 7:59 AM Patrick Häcker <pat_h@web.de> wrote:

> Hello,
>
> I try to get iwd running on a Raspberry Pi using a Raspbian kernel
> (5.4.59).
> The needed kernel options should be added (https://github.com/raspberrypi/
> linux/issues/3547 <https://github.com/raspberrypi/linux/issues/3547>),
> wpa_supplicant works, I compiled a kernel adding
> CONFIG_KEY_DH_OPERATIONS (which was the only remaining complaint by iwd),
> upgraded to iwd 1.8 but had no success.
>
> Now I am running out of ideas what else to try. The (hopefully) relevant
> part
> of iwd running in debug mode for 2.4 GHz:
> > src/station.c:station_autoconnect_next() Considering autoconnecting to
> BSS
> >     '98:9b:cb:4b:b1:cc' with SSID: auenstein, freq: 2472, rank: 7090,
> >     strength:  -5600
> > src/station.c:station_enter_state() Old State: autoconnect_quick, new
> >     state: connecting
> > src/station.c:station_netdev_event() Associating
> > src/netdev.c:netdev_unicast_notify() Unicast notification 59
> > src/netdev.c:netdev_mlme_notify() MLME notification Connect(46)
> > src/netdev.c:netdev_connect_event()
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/wiphy.c:wiphy_reg_notify() Notification of command Reg Change(36)
> > src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for
> >     (global) is DE
> > 4-Way handshake failed for ifindex: 3, reason: 15
> > src/station.c:station_connect_cb() 3, result: 3
> > src/station.c:station_disassociated() 3
> > src/station.c:station_enter_state() Old State: connecting, new state:
> >     disconnected
>
> And the same for 5.6 GHz with a different error:
> > src/station.c:station_autoconnect_next() Considering autoconnecting to
> BSS
> >     '98:9b:cb:4b:b1:cd' with SSID: auenstein5G, freq: 5600, rank: 4592,
> >     strength: -6500
> > src/station.c:station_enter_state() Old State:
> >     autoconnect_quick, new state: connecting
> > src/station.c:station_netdev_event() Associating
> > src/netdev.c:netdev_unicast_notify() Unicast notification 59
> > src/netdev.c:netdev_mlme_notify() MLME notification Connect(46)
> > src/netdev.c:netdev_connect_event()
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/wiphy.c:wiphy_reg_notify() Notification of command Reg Change(36)
> > src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for
> >     (global) is DE
> > src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> > src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
> > src/netdev.c:netdev_disconnect_event()
> > Received Deauthentication event, reason: 2, from_ap: false
> > src/station.c:station_disconnect_event() 3
> > src/station.c:station_disassociated() 3
> > src/station.c:station_enter_state() Old State: connecting, new state:
> > disconnected
>
> I could imagine, that there is still a kernel module missing, but this is
> just
> guessing. Any hints how to continue debugging?
>
> I still think that iwd would be a good match for the Raspberry Pi and
> ideally
> after this issue is fixed most Raspberry Pi user can switch to iwd if they
> like.
>
> Kind regards
> Patrick_______________________________________________
> iwd mailing list -- iwd(a)lists.01.org
> To unsubscribe send an email to iwd-leave(a)lists.01.org
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 5775 bytes --]

Re: iwd not connecting on Raspberry Pi with Raspbian

[Patrick =?unknown-8bit?q?H=C3=A4cker?=]

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

Hi Keith,

thanks for answering, I really appreciate it.

> I run iwd on RPi, but I am using Arch Linux. I've never tried it with
> RaspiOS. Works pretty well, though I am having a re-connect issue that we
> are trying to debug.
Knowing that, it's likely, that it's a problem due to the Raspbian 
configuration or the specific iwd / network environment combination.

> My guess is that you compiled the kernel to remove this message in the log:
> 
> Aug 23 22:52:24 rune64 iwd[235]: No Diffie-Hellman support found, WPS will
> not be available
> Aug 23 22:52:24 rune64 iwd[235]: The following options are missing in the
> kernel:
> Aug 23 22:52:24 rune64 iwd[235]:         CONFIG_KEY_DH_OPERATIONS
> 
> This is harmless and I have no problems connecting with this notification.
> I think it means I cannot use WPS which I do not.
Yes exactly, I had this message, and although I do not use WPS I thought it 
would be worth a try. But whether that option is included in the kernel or not 
does not make a difference.

> Are you trying to connect using the iwctl commands?
> 
> iwctl station wlan0 scan
> iwctl station wlan0 get-networks
> iwctl station wlan0 connect 'Network_Name"
> 
> It should return with
> 
> Type the network passphrase for "Network_Name" psk.
> Passphrase: ********
Yes, these were my first tests. However, few seconds after entering the 
Passphrase I always get a red "Operation failed".
Therefore, I manually created correct psk files in /var/lib/iwd (I know they 
are correct, as they work on another computer in the same network). However 
that was not successful (but I used this configuration for creating the debug 
output, as it's simpler not having to type the password).

> or are you using connman to manage iwd?
No I am testing iwd directly. Currently I let systemd-networkd manage the 
network interface. But without being connected with iwd this obviously fails 
(however it works when using wpa_supplicant).

> Do you have an /etc/iwd/main.conf? If so, what is in it?
No, I am not using a config file.

> I assume you have enabled and started iwd.
In general yes, but for testing I sometimes disable it in systemd and start it 
manually. But neither mode works.

I created an strace, but it didn't enlighten me. The bad file descriptor does 
not look good, but is probably due to the deauthentication event and not the 
other way round.
> recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=
>     "D\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\3\0\0\0\3\20\0\0\0\0\0\0"...,
>     iov_len=4096}], msg_iovlen=1, msg_control=[{cmsg_len=16,\0
>     cmsg_level=SOL_NETLINK, cmsg_type=0x3}], msg_controllen=16, msg_flags=0},
>     0) = 68
> recvmsg(4, {msg_name=NULL, msg_namelen=0,\0 msg_iov=[{iov_base=
>    "0\0\0\0\27\0\0\0\0\0\0\0\0\0\0\0000\1\0\0\10\0\1\0\0\0\0\0\10\0\3\0"...,
>     iov_len=8192}], msg_iovlen=1, msg_control=[{cmsg_len=16,
>     cmsg_level=SOL_NETLINK, cmsg_type=0x3}], msg_controllen=16, msg_flags=0},
> 0) = 48\0
> write(2, "Received Deauthentication event,"..., 59) = 59
> close(12)                               = 0
> epoll_ctl(3, EPOLL_CTL_DEL, 12, NULL)   = -1 EBADF (Bad file descriptor)\0

Any more ideas how to debug this, anyone?  Is it possible to run an Arch 
kernel on a Raspbian?

Kind regards
Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: iwd not connecting on Raspberry Pi with Raspbian

[KeithG]

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

You may need to remove wpa_supplicant. I have it removed from my images.

On Sat, Aug 29, 2020, 12:20 Patrick Häcker <pat_h@web.de> wrote:

> Hi Keith,
>
> thanks for answering, I really appreciate it.
>
> > I run iwd on RPi, but I am using Arch Linux. I've never tried it with
> > RaspiOS. Works pretty well, though I am having a re-connect issue that we
> > are trying to debug.
> Knowing that, it's likely, that it's a problem due to the Raspbian
> configuration or the specific iwd / network environment combination.
>
> > My guess is that you compiled the kernel to remove this message in the
> log:
> >
> > Aug 23 22:52:24 rune64 iwd[235]: No Diffie-Hellman support found, WPS
> will
> > not be available
> > Aug 23 22:52:24 rune64 iwd[235]: The following options are missing in the
> > kernel:
> > Aug 23 22:52:24 rune64 iwd[235]:         CONFIG_KEY_DH_OPERATIONS
> >
> > This is harmless and I have no problems connecting with this
> notification.
> > I think it means I cannot use WPS which I do not.
> Yes exactly, I had this message, and although I do not use WPS I thought
> it
> would be worth a try. But whether that option is included in the kernel or
> not
> does not make a difference.
>
> > Are you trying to connect using the iwctl commands?
> >
> > iwctl station wlan0 scan
> > iwctl station wlan0 get-networks
> > iwctl station wlan0 connect 'Network_Name"
> >
> > It should return with
> >
> > Type the network passphrase for "Network_Name" psk.
> > Passphrase: ********
> Yes, these were my first tests. However, few seconds after entering the
> Passphrase I always get a red "Operation failed".
> Therefore, I manually created correct psk files in /var/lib/iwd (I know
> they
> are correct, as they work on another computer in the same network).
> However
> that was not successful (but I used this configuration for creating the
> debug
> output, as it's simpler not having to type the password).
>
> > or are you using connman to manage iwd?
> No I am testing iwd directly. Currently I let systemd-networkd manage the
> network interface. But without being connected with iwd this obviously
> fails
> (however it works when using wpa_supplicant).
>
> > Do you have an /etc/iwd/main.conf? If so, what is in it?
> No, I am not using a config file.
>
> > I assume you have enabled and started iwd.
> In general yes, but for testing I sometimes disable it in systemd and
> start it
> manually. But neither mode works.
>
> I created an strace, but it didn't enlighten me. The bad file descriptor
> does
> not look good, but is probably due to the deauthentication event and not
> the
> other way round.
> > recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=
> >
>  "D\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\3\0\0\0\3\20\0\0\0\0\0\0"...,
> >     iov_len=4096}], msg_iovlen=1, msg_control=[{cmsg_len=16,
> >     cmsg_level=SOL_NETLINK, cmsg_type=0x3}], msg_controllen=16,
> msg_flags=0},
> >     0) = 68
> > recvmsg(4, {msg_name=NULL, msg_namelen=0,  msg_iov=[{iov_base=
> >
> "0\0\0\0\27\0\0\0\0\0\0\0\0\0\0\0000\1\0\0\10\0\1\0\0\0\0\0\10\0\3\0"...,
> >     iov_len=8192}], msg_iovlen=1, msg_control=[{cmsg_len=16,
> >     cmsg_level=SOL_NETLINK, cmsg_type=0x3}], msg_controllen=16,
> msg_flags=0},
> > 0) = 48
> > write(2, "Received Deauthentication event,"..., 59) = 59
> > close(12)                               = 0
> > epoll_ctl(3, EPOLL_CTL_DEL, 12, NULL)   = -1 EBADF (Bad file descriptor)
>
> Any more ideas how to debug this, anyone?  Is it possible to run an Arch
> kernel on a Raspbian?
>
> Kind regards
> Patrick

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 4201 bytes --]

Re: iwd not connecting on Raspberry Pi with Raspbian

[Denis Kenzior]

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

Hi Patrick,

On 8/29/20 7:59 AM, Patrick Häcker wrote:
> Hello,
> 
> I try to get iwd running on a Raspberry Pi using a Raspbian kernel (5.4.59).
> The needed kernel options should be added (https://github.com/raspberrypi/
> linux/issues/3547), wpa_supplicant works, I compiled a kernel adding
> CONFIG_KEY_DH_OPERATIONS (which was the only remaining complaint by iwd),
> upgraded to iwd 1.8 but had no success.

CONFIG_KEY_DH_OPERATIONS is needed for WPS.  If you're not using that, then this 
can be dropped, but probably a good idea to keep it.

> 
> Now I am running out of ideas what else to try. The (hopefully) relevant part
> of iwd running in debug mode for 2.4 GHz:
>> src/station.c:station_autoconnect_next() Considering autoconnecting to BSS
>>      '98:9b:cb:4b:b1:cc' with SSID: auenstein, freq: 2472, rank: 7090,
>>      strength: -5600
>> src/station.c:station_enter_state() Old State: autoconnect_quick, new
>>      state: connecting
>> src/station.c:station_netdev_event() Associating
>> src/netdev.c:netdev_unicast_notify() Unicast notification 59
>> src/netdev.c:netdev_mlme_notify() MLME notification Connect(46)
>> src/netdev.c:netdev_connect_event()
>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/wiphy.c:wiphy_reg_notify() Notification of command Reg Change(36)
>> src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for
>>      (global) is DE
>> 4-Way handshake failed for ifindex: 3, reason: 15
>> src/station.c:station_connect_cb() 3, result: 3
>> src/station.c:station_disassociated() 3
>> src/station.c:station_enter_state() Old State: connecting, new state:
>>      disconnected

This is a brcmfmac card right?  We have seen some weirdness with brcmfmac where 
it simply refuses to perform the handshake (which is what is happening in your 
case).  The handshake times out (reason: 15 = 
MMPDU_REASON_CODE_4WAY_HANDSHAKE_TIMEOUT).

The strange part is that it does work in other setups and it seems to be a 
combination of AP or some other weird factor that screws this up.  Have you 
tried different brcmfmac firmware versions?

> 
> And the same for 5.6 GHz with a different error:
>> src/station.c:station_autoconnect_next() Considering autoconnecting to BSS
>>      '98:9b:cb:4b:b1:cd' with SSID: auenstein5G, freq: 5600, rank: 4592,
>>      strength: -6500
>> src/station.c:station_enter_state() Old State:
>>      autoconnect_quick, new state: connecting
>> src/station.c:station_netdev_event() Associating
>> src/netdev.c:netdev_unicast_notify() Unicast notification 59
>> src/netdev.c:netdev_mlme_notify() MLME notification Connect(46)
>> src/netdev.c:netdev_connect_event()
>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/wiphy.c:wiphy_reg_notify() Notification of command Reg Change(36)
>> src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for
>>      (global) is DE

Seems like the kernel is switching the regulatory domain here, right after we 
try to connect.  I wonder if you can use iw to set this prior to triggering the 
connection with iwd.  Does anything change?

>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>> src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
>> src/netdev.c:netdev_disconnect_event()
>> Received Deauthentication event, reason: 2, from_ap: false

And here we see the firmware using an incorrect password somehow and triggering 
a disconnect by itself, without iwd's input.  I think James had the exact same 
issue on RPI4, and we determined that the firmware/driver was just borked...

>> src/station.c:station_disconnect_event() 3
>> src/station.c:station_disassociated() 3
>> src/station.c:station_enter_state() Old State: connecting, new state:
>> disconnected >
> I could imagine, that there is still a kernel module missing, but this is just
> guessing. Any hints how to continue debugging?

This is a driver / firmware problem.  You say that wpa_s works correctly.  Can 
you capture iwmon traces of both wpa_s and iwd trying to connect to the same AP 
and share that with us?

Refer to: https://iwd.wiki.kernel.org/debugging for details.  You can also hop 
onto #iwd on freenode.  Usually we're around during US working hours.

> 
> I still think that iwd would be a good match for the Raspberry Pi and ideally
> after this issue is fixed most Raspberry Pi user can switch to iwd if they
> like.
> 

Yes, definitely.

Regards,
-Denis

Re: iwd not connecting on Raspberry Pi with Raspbian

[Patrick =?unknown-8bit?q?H=C3=A4cker?=]

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

Hi Denis,

thanks for the answer!

> This is a brcmfmac card right?  We have seen some weirdness with brcmfmac
> where it simply refuses to perform the handshake (which is what is
> happening in your case).  The handshake times out (reason: 15 =
> MMPDU_REASON_CODE_4WAY_HANDSHAKE_TIMEOUT).
> 
> The strange part is that it does work in other setups and it seems to be a
> combination of AP or some other weird factor that screws this up.  Have you
> tried different brcmfmac firmware versions?
Yes, it's a brcmfmac card. I speculate, that it had some state, which iwd did 
not expect due to booting up with wpa_supplicant and only switching to iwd 
afterwards (it worked after I removed wpa_supplicant and rebooted).

Therefore I did not try different brcmfmac firmware versions. I am probably 
using this firmware:
> brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip
>     BCM4345/6\0
> brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 23 2020
>     02:19:54 version 7.45.206 (r725000 CY) FWID 01-88ee44ea\0

> >> src/wiphy.c:wiphy_reg_notify() Notification of command Reg Change(36)
> >> src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for
> >> 
> >>      (global) is DE
> 
> Seems like the kernel is switching the regulatory domain here, right after
> we try to connect.  I wonder if you can use iw to set this prior to
> triggering the connection with iwd.  Does anything change?
Actually, the reg domain is set before to the correct value (DE in my case, I 
have double-checked that, when I saw the message in the logs). I am not sure 
why it's switching.  I am on channel 13, so with an US/default reg domain I 
couldn't access the 2-GHz-Wi-Fi.

> >> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
> >> src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
> >> src/netdev.c:netdev_disconnect_event()
> >> Received Deauthentication event, reason: 2, from_ap: false
> 
> And here we see the firmware using an incorrect password somehow and
> triggering a disconnect by itself, without iwd's input.  I think James had
> the exact same issue on RPI4, and we determined that the firmware/driver
> was just borked...
The provided password was definitely correct, as it's provided by a file and 
working now without being changed in between. But it might be, that the 
firmware/driver ended up with a wrong authentication somehow, although the 
correct password was provided.

> >> src/station.c:station_disconnect_event() 3
> >> src/station.c:station_disassociated() 3
> >> src/station.c:station_enter_state() Old State: connecting, new state:
> >> disconnected >
> > 
> > I could imagine, that there is still a kernel module missing, but this is
> > just guessing. Any hints how to continue debugging?
> 
> This is a driver / firmware problem.  You say that wpa_s works correctly. 
> Can you capture iwmon traces of both wpa_s and iwd trying to connect to the
> same AP and share that with us?
I wanted to use iwmon already before. Unfortunately, it does not work on this 
system:
> Wireless monitor ver 1.8
> Failed to create monitor interface nlmon: Unknown error -95\0
There is (to me) no obvious error in its strace, but I am omitting it here, as 
it is probably a separate issue and I am not sure if anyone is interested in 
solving that problem.

So where to go from here on? The principle issue (iwd in Raspbian) is solved. 
But if someone is interested to find and fix the root cause to avoid the 
removing/rebooting procedure on the Raspberry Pi in the future, I can assist 
with this (although my time is limited mostly to weekends).
My gut feeling is, that we need to fix that issue before suggesting to have iwd 
as default on a Raspberry.

Kind regards
Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: iwd not connecting on Raspberry Pi with Raspbian

[Denis Kenzior]

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

Hi Patrick,

On 8/30/20 8:38 AM, Patrick Häcker wrote:
> Hi Denis,
> 
> thanks for the answer!
> 
>> This is a brcmfmac card right?  We have seen some weirdness with brcmfmac
>> where it simply refuses to perform the handshake (which is what is
>> happening in your case).  The handshake times out (reason: 15 =
>> MMPDU_REASON_CODE_4WAY_HANDSHAKE_TIMEOUT).
>>
>> The strange part is that it does work in other setups and it seems to be a
>> combination of AP or some other weird factor that screws this up.  Have you
>> tried different brcmfmac firmware versions?
> Yes, it's a brcmfmac card. I speculate, that it had some state, which iwd did
> not expect due to booting up with wpa_supplicant and only switching to iwd
> afterwards (it worked after I removed wpa_supplicant and rebooted).

There isn't really any state for iwd to be confused by.   Once a CMD_DISCONNECT 
is issued, or the device brought into IF_OPER_DOWN state, the kernel / driver 
should clean up any state associated with the previous connection.

iwd tries to reset as much of the driver as possible at startup, by 
deleting/re-creating the default interface and power-cycling the card. 
Unfortunately brcmfmac doesn't support the first part either.

The issue is likely that wpa_s uses handshake offload (with handshake handled by 
the firmware) and iwd does not.  This maybe leads to the firmware or driver 
being confused possibly due to some missing cleanups.  But that's a kernel 
driver / firmware issue, not a problem in iwd.

> 
> Therefore I did not try different brcmfmac firmware versions. I am probably
> using this firmware:
>> brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip
>>      BCM4345/6
>> brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 23 2020
>>      02:19:54 version 7.45.206 (r725000 CY) FWID 01-88ee44ea
> 
>>>> src/wiphy.c:wiphy_reg_notify() Notification of command Reg Change(36)
>>>> src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for
>>>>
>>>>       (global) is DE
>>
>> Seems like the kernel is switching the regulatory domain here, right after
>> we try to connect.  I wonder if you can use iw to set this prior to
>> triggering the connection with iwd.  Does anything change?
> Actually, the reg domain is set before to the correct value (DE in my case, I
> have double-checked that, when I saw the message in the logs). I am not sure
> why it's switching.  I am on channel 13, so with an US/default reg domain I
> couldn't access the 2-GHz-Wi-Fi.

Okay, we can seemingly rule that out then...

> 
>>>> src/netdev.c:netdev_link_notify() event 16 on ifindex 3
>>>> src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
>>>> src/netdev.c:netdev_disconnect_event()
>>>> Received Deauthentication event, reason: 2, from_ap: false
>>
>> And here we see the firmware using an incorrect password somehow and
>> triggering a disconnect by itself, without iwd's input.  I think James had
>> the exact same issue on RPI4, and we determined that the firmware/driver
>> was just borked...
> The provided password was definitely correct, as it's provided by a file and
> working now without being changed in between. But it might be, that the
> firmware/driver ended up with a wrong authentication somehow, although the
> correct password was provided.
> 
>>>> src/station.c:station_disconnect_event() 3
>>>> src/station.c:station_disassociated() 3
>>>> src/station.c:station_enter_state() Old State: connecting, new state:
>>>> disconnected >
>>>
>>> I could imagine, that there is still a kernel module missing, but this is
>>> just guessing. Any hints how to continue debugging?
>>
>> This is a driver / firmware problem.  You say that wpa_s works correctly.
>> Can you capture iwmon traces of both wpa_s and iwd trying to connect to the
>> same AP and share that with us?
> I wanted to use iwmon already before. Unfortunately, it does not work on this
> system:
>> Wireless monitor ver 1.8
>> Failed to create monitor interface nlmon: Unknown error -95
> There is (to me) no obvious error in its strace, but I am omitting it here, as
> it is probably a separate issue and I am not sure if anyone is interested in
> solving that problem.

You do not have nlmon (CONFIG_NLMON) compiled into the kernel or perhaps the 
nlmon module is not loaded.

> 
> So where to go from here on? The principle issue (iwd in Raspbian) is solved.
> But if someone is interested to find and fix the root cause to avoid the
> removing/rebooting procedure on the Raspberry Pi in the future, I can assist
> with this (although my time is limited mostly to weekends).
> My gut feeling is, that we need to fix that issue before suggesting to have iwd
> as default on a Raspberry.
> 

Not sure, but so far it really sounds like you need to start a thread on 
linux-wireless and get brcmfmac maintainer's attention.

Regards,
-Denis