On Sun, Sep 20, 2020 at 10:44:37AM -0500, KeithG wrote:
I'm still struggling with this and have done a lot of poking at
posting Denis off list as well. This is what I 'think' I have learned.
BTW, you should refrain from posting off list questions if it doesn't
contain any secret information (or you were asked to send it privately).
I don't know what you figured out with Denis' help. Open source includes
1) iwd as standalone or with systemd-networkd/dhcpch or with
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
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.
That means if iwd manages the reconnects all works well.
4) When connman manages iwd, though, I cannot edit the ssid.psk file
have it stick. Though it connects every time at boot, it will not reconnect
if the ssid goes away and returns.
This is because ConnMan is taking over the job of managing the
connections and actively disables the AutoConnect in iwd.
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
Check what the monitor-iwd scripts shows and compare it with the output
from 'connmand -n -d plugins/iwd.c'
If I type 'connmanctl scan wifi' it will complete a scan
Likely the SSID was not seen by ConnMan and that's why it doesn't do a
reconnect. The scan will retrigger the machinery. The output from
monitor-iwd is again a good starting point to see what is missing
between the communication between ConnMan and iwd.
It is like connman gets stuck. and stops managing the wifi.
ConnMan is only reacting to events. If there is no event from iwd to
ConnMan nothing will happen. From your description I think there is
either a missing event or ConnMan ignores an event (would be a bit
surprising but well).
I also note that if the ethernet cable is plugged in on the RPIs then
device is connected to the wifi ap then the ethernet cable is removed that
all internet connectivity ceases.
Again ConnMan reacts to events. If the kernel doesn't send a netlink
message, nothing will happen. I would be surprised if ConnMan and the
the generic kernel code have a bug there. So I would look more closely
at what the driver is doing here first.
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.
As far as I know, systemd-networkd uses also udev as input. Maybe this
makes the difference.
Also, on the rpis, I have noticed that connman can get into a state
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?
ConnMan should be able to this modulo bugs.
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.
I've tried your scenarios on my hardware and it works. Obviously,
different hardware/driver behave slightly differently and ConnMan might
choke on it.
So the question is why it works with systemd-networkd and not with