On Mon, Jun 22, 2020 at 8:17 AM KeithG <ys3al35l@gmail.com> wrote:

Good call. I just built this for my architecture (aarch64) and installed it. Will see if there is any improvement.



On Mon, Jun 22, 2020 at 4:01 AM Ryll, Jan (GED-SDD2) <Jan.Ryll@bshg.com> wrote:

Hi Keith,


its only a assumption, but it could be a firmware problem.

We had also issues with connman and wifi but not on raspi. In our case it was a cypress chipset.






From: KeithG <ys3al35l@gmail.com>
Sent: Sunday, June 21, 2020 5:19 PM
To: connman@lists.01.org
Subject: connman wifi disconnect problem


I have been trying to diagnose a problem I am having with my RPis. I am using iwd and connman to manage my ethernet connectivity. What I have noticed is that after a while, sometimes, connectivity stops and I cannot reconnect except after a reboot. I have seen this on RPi3's more so than with RPi1/2. I have only noticed it with wlan0 and not with ethernet.


From the journal, it looks like the network goes down (wlan0), connman quickly notes it is down and pulls the ip address and sets the interface down and then avahi identifies that it is down. It is interesting that sometime before this, the ipv4 address was withdrawn. I am running an openWRT router (other side of the DHCP equation) and this RPI MAC has a reserved ipv4 address on the router.


If I restart connman on the RPi, it will not regain connectivity on ipv4 or ipv6 on wlan0. If I reboot the router and then restart connman on the RPi, it will not regain connectivity. I have to power cycle the RPI to get it to connect again. If I plug in the ethernet cable, it grabs an address immediately and everything is back, but it will still not reconnect over wifi. I must reboot the RPi to get it to reconnect. I will see if I can figure out how to have journal log more info on connman...


Any idea what this could be? I will flash the router with ddwrt and see if it is the router.


In my /etc/connman/main.conf, I have this:

FallbackNameservers =,
DefaultAutoConnectTechnologies = ethernet,wifi
PreferredTechnologies = ethernet,wifi
AllowHostnameUpdates = false
SingleConnectedTechnology = true
AlwaysConnectedTechnologies = ethernet,wifi
AutoConnectRoamingServices = true


The journal shows this:

Jun 20 18:02:19 rune64 kernel: nfs: server not responding, timed out
Jun 20 18:02:20 rune64 systemd[1]: dbus-org.freedesktop.timedate1.service: Succeeded.
Jun 20 18:02:35 rune64 kernel: nfs: server not responding, timed out
Jun 20 18:02:39 rune64 kernel: nfs: server not responding, timed out

... lots of these 'not responding'...

Jun 20 18:07:54 rune64 kernel: nfs: server not responding, timed out
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Withdrawing address record for 2601:241:4200:255:ba27:ebff:fe52:ccd0 on wlan0.
Jun 20 18:07:55 rune64 connmand[259]: wlan0 {del} address 2601:241:4200:255:ba27:ebff:fe52:ccd0/64 label (null)
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leaving mDNS multicast group on interface wlan0.IPv6 with address 2601:241:4200:255:ba27:ebff:fe52:ccd0.
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Joining mDNS multicast group on interface wlan0.IPv6 with address fdcb:9d61:70f3:0:ba27:ebff:fe52:ccd0.
Jun 20 18:07:57 rune64 kernel: nfs: server not responding, timed out
Jun 20 18:08:10 rune64 kernel: nfs: server not responding, timed out
Jun 20 18:08:13 rune64 kernel: nfs: server not responding, timed out
Jun 20 18:08:14 rune64 connmand[259]: wlan0 {del} route 2601:241:4200:255:: gw :: scope 0 <UNIVERSE>

I'm still struggling with this and have done a lot of poking at it and posting Denis off list as well. This is what I 'think' I have learned.

1) iwd as standalone or with systemd-networkd/dhcpch or with NetworkManager on x64 or on RPIs, all running arch linux, works great at version 1.9. If the SSID 'goes away' and 'comes back' the computer will reconnect. every time.
2) NetworkManager works well with iwd and as best I can tell, it will reconnect via its interaction with iwd.
3) When I run systemd-networkd/dhcpcd with iwd, it is more like it iwd running standalone as I can edit the /var/lib/iwd/ssid.psk either manually or through iwctl so that:
In this setup, the computer reconnects at boot *and* when the SSID goes away and comes back.

4) When connman manages iwd, though, I cannot edit the ssid.psk file and have it stick. Though it connects every time at boot, it will not reconnect if the ssid goes away and returns. This is with the headless rpis with their broadcom cards and with a laptop runnning a full Arch Linux desktop with an intel wifi card. One other thing I notice is that when it has disconnected (SSID off then on), the 'connmanctl services' list is incomplete. It definitely does not show all the currently available ssids broadcasting. If I type 'connmanctl scan wifi' it will complete a scan *and* reconnect. It is like connman gets stuck. and stops managing the wifi.

I also note that if the ethernet cable is plugged in on the RPIs then the device is connected to the wifi ap then the ethernet cable is removed that all internet connectivity ceases. Both interfaces go down and will not reconnect requiring a reboot. It is tough for me to really query this as I see it on my headless rpis and when the connectivity goes away, I have to reboot to get it back. It did not behave like this with netctl nor does it behave like this with systemd-networkd.

Also, on the rpis, I have noticed that connman can get into a state where plugging in the ethernet cable results in nothing. connman will not bring up the ethernet interface.

We have reworked a php interface from netctl tp work with connman for these little rpi audio devices and I would love for it to work, but if a headless device cannot reconnect when the ssid returns, it is a bit useless. Isn't connman supposed to do this? There are many things I like about connman but this seems like a basic function that seems to be broken and I am surprised that I find very little info on it on the internet. The attached log is on my laptop. I restarted the SSID radio at 10:06 and at 10:20, I did a 'connmanctl scan wifi' when it reconnected. I find this strange as connman1.38 does not return with a 'scan completed' message but it does reconnect. I see this behavior on the RPis as well.

I am running connman 1.38 and iwd 1.9 and have tried current gits of both and also get the same result.

Any help?