Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH] ntp: Do not depend on the existence of a nameserver entry
(Daniel Wagner)
2. Re: connman wifi disconnect problem (Daniel Wagner)
----------------------------------------------------------------------
Date: Mon, 21 Sep 2020 09:51:33 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] ntp: Do not depend on the existence of a
nameserver entry
To: Markus Held <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Markus,
On Mon, Sep 21, 2020 at 08:32:45AM +0200, Markus Held wrote:
> __connman_timeserver_sync() does not need to return -EINVAL if
> there is no nameserver specified. This allows NTP to synchronise
> with a timeserver configured as IP address and not require a
> nameserver.
Patch applied.
Thanks a lot!
Daniel
------------------------------
Date: Mon, 21 Sep 2020 10:15:51 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: connman wifi disconnect problem
To: KeithG <[email protected]>
Cc: "Ryll, Jan (GED-SDD2)" <[email protected]>, "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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 it and
> 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
open discussion.
> 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:
> [Settings]
> AutoConnect=true
> 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 and
> 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
> broadcasting.
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
> *and* reconnect.
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 the
> 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 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?
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
ConnMan.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 59, Issue 21
***************************************
