Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: connman wifi disconnect problem (KeithG)
2. Re: [PATCH 0/6] Support SplitRouting variable on vpnd
(Daniel Wagner)
3. wpa3 support (Dembianny, Sven (GED-SDD1))
----------------------------------------------------------------------
Date: Tue, 22 Sep 2020 19:08:55 -0500
From: KeithG <ys3al...@gmail.com>
Subject: Re: connman wifi disconnect problem
To: Daniel Wagner <w...@monom.org>
Cc: "Ryll, Jan (GED-SDD2)" <jan.r...@bshg.com>, "connman@lists.01.org"
<connman@lists.01.org>
Message-ID:
<CAG17S_MD6Z2N7EmsNfP4askO8=df5qzmcju5tdakltfkf0v...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="00000000000057224405afefe44c"
--00000000000057224405afefe44c
Content-Type: text/plain; charset="UTF-8"
DAniel,
I am still trying to run the python scripts. I am on arch and finally
figured out I needed to do it this way:
"sudo pip install gobject pygobject" in additon to the pacman -Sy gobject
so Now I get a bit farther:
# ./monitor-connman
Traceback (most recent call last):
File "./monitor-connman", line 85, in <module>
mainloop = gobject.MainLoop()
AttributeError: module 'gobject' has no attribute 'MainLoop'
I am still at a loss as to how to get this running.
On Tue, Sep 22, 2020 at 8:59 AM KeithG <ys3al...@gmail.com> wrote:
>
>
> On Mon, Sep 21, 2020 at 3:15 AM Daniel Wagner <w...@monom.org> wrote:
>
>> 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.
>>
>
> I cannot find the monitor-iwd script. I found the monitor-connman script,
> but when I try to run the monitor-connman script, I get a gobject error:
>
> $ ./monitor-connman
> Traceback (most recent call last):
> File "./monitor-connman", line 3, in <module>
> import gobject
> ModuleNotFoundError: No module named 'gobject'
>
> This is even though I believe that python-gobject is installed and I can
> run the hello.py script on this page:
> https://pygobject.readthedocs.io/en/latest/getting_started.html
> python 3.8.5 and
> $ pacman -Q | grep gobject
> gobject-introspection 1.66.0-1
> gobject-introspection-runtime 1.66.0-1
> pygobject-devel 3.36.1-1
> python-gobject 3.36.1-1
>
> I am now running on a pretty common dell laptop with an intel wifi card
> and get the same behavior. iwd 1.9 connman 1.38. I connected via connman
> then powered down the radio on the router then back on then had to
> reconnect by typing in teh password. The journal of this event is
> attached.
>
> I did notice that in order to reconnect on this laptop (Arch Linux x86_64)
> that I had to type in the password again though I was just connected before
> I turned off the SSID. The journal running /usr/bin/connmand -n -d
> plugins/iwd.c:src/service.c though this event is attached.
>
--00000000000057224405afefe44c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>DAniel,</div><div><br></div><div>I am still trying to=
run the python scripts. I am on arch=C2=A0 and finally figured out I neede=
d to do it this way:</div><div>"sudo pip install gobject pygobject&quo=
t; in additon to the pacman -Sy gobject so Now I get a bit farther:</div><d=
iv># ./monitor-connman<br>Traceback (most recent call last):<br>=C2=A0 File=
"./monitor-connman", line 85, in <module><br>=C2=A0 =C2=A0=
mainloop =3D gobject.MainLoop()<br>AttributeError: module 'gobject'=
; has no attribute 'MainLoop'</div><div><br></div><div>I am still a=
t a loss as to how to get this running. <br></div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Sep 22, 2020 at 8=
:59 AM KeithG <<a href=3D"mailto:ys3al...@gmail.com";>ys3al...@gmail.com<=
/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 21, 2020 at 3:15 AM Daniel=
Wagner <<a href=3D"mailto:w...@monom.org"; target=3D"_blank">wagi@monom.=
org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">On Sun, Sep 20, 2020 at 10:44:37AM -0500, KeithG wrote:<br>
> I'm still struggling with this and have done a lot of poking at it=
and<br>
> posting Denis off list as well. This is what I 'think' I have =
learned.<br>
<br>
BTW, you should refrain from posting off list questions if it doesn't<b=
r>
contain any secret information (or you were asked to send it privately).<br=
>
I don't know what you figured out with Denis' help. Open source inc=
ludes<br>
open discussion.<br>
<br>
> 1) iwd as standalone or with systemd-networkd/dhcpch or with NetworkMa=
nager<br>
> on x64 or on RPIs, all running arch linux, works great at version 1.9.=
If<br>
> the SSID 'goes away' and 'comes back' the computer wil=
l reconnect. every<br>
> time.<br>
> 2) NetworkManager works well with iwd and as best I can tell, it will<=
br>
> reconnect via its interaction with iwd.<br>
> 3) When I run systemd-networkd/dhcpcd with iwd, it is more like it iwd=
<br>
> running standalone as I can edit the /var/lib/iwd/ssid.psk either manu=
ally<br>
> or through iwctl so that:<br>
> [Settings]<br>
> AutoConnect=3Dtrue<br>
> In this setup, the computer reconnects at boot *and* when the SSID goe=
s<br>
> away and comes back.<br>
<br>
That means if iwd manages the reconnects all works well.<br>
<br>
> 4) When connman manages iwd, though, I cannot edit the ssid.psk file a=
nd<br>
> have it stick. Though it connects every time at boot, it will not reco=
nnect<br>
> if the ssid goes away and returns.<br>
<br>
This is because ConnMan is taking over the job of managing the<br>
connections and actively disables the AutoConnect in iwd.<br>
<br>
> This is with the headless rpis with<br>
> their broadcom cards and with a laptop runnning a full Arch Linux desk=
top<br>
> with an intel wifi card. One other thing I notice is that when it has<=
br>
> disconnected (SSID off then on), the 'connmanctl services' lis=
t is<br>
> incomplete. It definitely does not show all the currently available ss=
ids<br>
> broadcasting.<br>
<br>
Check what the monitor-iwd scripts shows and compare it with the output<br>
from 'connmand -n -d plugins/iwd.c'<br>
<br>
> If I type 'connmanctl scan wifi' it will complete a scan<br>
> *and* reconnect.<br>
<br>
Likely the SSID was not seen by ConnMan and that's why it doesn't d=
o a<br>
reconnect. The scan will retrigger the machinery. The output from<br>
monitor-iwd is again a good starting point to see what is missing<br>
between the communication between ConnMan and iwd.<br>
<br>
> It is like connman gets stuck. and stops managing the wifi.<br>
<br>
ConnMan is only reacting to events. If there is no event from iwd to<br>
ConnMan nothing will happen. From your description I think there is<br>
either a missing event or ConnMan ignores an event (would be a bit<br>
surprising but well).<br>
<br>
> I also note that if the ethernet cable is plugged in on the RPIs then =
the<br>
> device is connected to the wifi ap then the ethernet cable is removed =
that<br>
> all internet connectivity ceases.<br>
<br>
Again ConnMan reacts to events. If the kernel doesn't send a netlink<br=
>
message, nothing will happen. I would be surprised if ConnMan and the<br>
the generic kernel code have a bug there. So I would look more closely<br>
at what the driver is doing here first.<br>
<br>
> Both interfaces go down and will not<br>
> reconnect requiring a reboot. It is tough for me to really query this =
as I<br>
> see it on my headless rpis and when the connectivity goes away, I have=
to<br>
> reboot to get it back. It did not behave like this with netctl nor doe=
s it<br>
> behave like this with systemd-networkd.<br>
<br>
As far as I know, systemd-networkd uses also udev as input. Maybe this<br>
makes the difference.<br>
<br>
> Also, on the rpis, I have noticed that connman can get into a state wh=
ere<br>
> plugging in the ethernet cable results in nothing. connman will not br=
ing<br>
> up the ethernet interface.<br>
> <br>
> We have reworked a php interface from netctl tp work with connman for =
these<br>
> little rpi audio devices and I would love for it to work, but if a hea=
dless<br>
> device cannot reconnect when the ssid returns, it is a bit useless. Is=
n't<br>
> connman supposed to do this?<br>
<br>
ConnMan should be able to this modulo bugs.<br>
<br>
> There are many things I like about connman but<br>
> this seems like a basic function that seems to be broken and I am surp=
rised<br>
> that I find very little info on it on the internet.<br>
<br>
I've tried your scenarios on my hardware and it works. Obviously,<br>
different hardware/driver behave slightly differently and ConnMan might<br>
choke on it.<br>
<br>
So the question is why it works with systemd-networkd and not with<br>
ConnMan.<br></blockquote><div><br></div><div>I cannot find the monitor-iwd =
script. I found the monitor-connman script, but when I try to run the monit=
or-connman script, I get a gobject error:</div><div><br></div><div>$ ./moni=
tor-connman <br>Traceback (most recent call last):<br>=C2=A0 File "./m=
onitor-connman", line 3, in <module><br>=C2=A0 =C2=A0 import gob=
ject<br>ModuleNotFoundError: No module named 'gobject'</div><div><b=
r></div><div>This is even though I believe that python-gobject is installed=
and I can run the hello.py script on this page:</div><div><a href=3D"https=
://pygobject.readthedocs.io/en/latest/getting_started.html" target=3D"_blan=
k">https://pygobject.readthedocs.io/en/latest/getting_started.html</a></div=
><div>python 3.8.5 and <br></div><div>$ pacman -Q | grep gobject<br>gobject=
-introspection 1.66.0-1<br>gobject-introspection-runtime 1.66.0-1<br>pygobj=
ect-devel 3.36.1-1<br>python-gobject 3.36.1-1<br></div><div><br></div><div>=
I am now running on a pretty common dell laptop with an intel wifi card and=
get the same behavior. iwd 1.9 connman 1.38. I connected via connman then =
powered down the radio on the router then back on then had to reconnect by =
typing in teh password.=C2=A0 The journal of this event is attached. <br></=
div><div><br></div><div>I did notice that in order to reconnect on this lap=
top (Arch Linux x86_64) that I had to type in the password again though I w=
as just connected before I turned off the SSID. The journal running /usr/bi=
n/connmand -n -d plugins/iwd.c:src/service.c though this event is attached.=
<br> </div></div></div>
</blockquote></div>
--00000000000057224405afefe44c--
------------------------------
Date: Wed, 23 Sep 2020 08:44:28 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH 0/6] Support SplitRouting variable on vpnd
To: Jussi Laakkonen <jussi.laakko...@jolla.com>
Cc: connman@lists.01.org
Message-ID: <20200923064428.medsq4yvhnim5...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Good Morning Jussi,
On Tue, Sep 22, 2020 at 04:09:57PM +0300, Jussi Laakkonen wrote:
> Thanks for the comments, the change here is a bit old so bear with me. I
> needed to check this more closely after vacations and whatnot, to re-gain
> understanding of what this actually does.
No worries. I know this problem.
> > I am bit confused. Why does the vpnd need to know about the split
> > routing at all? The vpnd should always push all the routes to ConnMan
> > and there should be the logic if the routes are used or not. What do I
> > miss?
> >
>
> I think this is a good question and now I understand that I've overlooked
> some things. We're both half right. vpnd has the option "handle_routes"
> passed as startup parameter. When set with "routes/r" vpnd does manage
> routes. But by default connmand does handle them. And I guess my changes
> need improving.
Yes, the original idea is that connamn-vpnd doesn't do anything on IP or
routing configuration at all. Instead it just passes the information to
connmand.
> I've seen issues where the default route is not in the VPN routes list and
> thus, the networking may be inoperable until VPN is disconnected as there is
> no default route for routing traffic. I guess this happened after a lot of
> disconnect/reconnect and changing of transport services rapidly. It started
> to occur at some point and this kind of approach helped us with the case.
> But now I see that it was originally in the wrong place, and only
> half-correct. Need to continue with this.
Okay, if there are wrong/stale routes, it's connmand fault.
> Isn't that SplitRouting a VPN only option that should be controlled via the
> VPN connection D-Bus API like the other options? We'd see this more as a
> user controllable option. It may be that I'm also missing something but it
> seemed reasonable to expose this via VPN API rather than via service API.
> Especially since vpnd does also add the routes in
> vpn-provider.c:set_connected() (and provider_append_route()) when
> handle_routes is set.
> So, wouldn't this suggest that both need to know the value for split
> routing?
Oh, I didn't realize this commit exists: a7851eb04e67 ("vpnd: Add -r
option which enables route handling in vpnd") which came with the large
VPN re-design/factoring back in 2012. This makes things unnecessarily
complex. Do you use the '-r' option in your setup?
I see following options ordered according my preferences:
- rip it out
- leave it as it is and document, not working for split routing
- add support for split routing
> > BTW, I think this is also a bit fragile because the user might decide to
> > reorder the services ('enable split routing') while vpn up happens. I
> > really would like to keep logic code in one daemon as much as possible.
> >
>
> That fragile issue is a valid point. I guess changes to the SplitRouting
> value via D-Bus should trigger a reconnect if the VPN is already connected,
> as the value change is propagated forwards to connmand. Dropping/adding
> default route on the fly might not be good or required anyways (?).
The split routing is enabled/disabled by the ordering of the
services. If the first services is a VPN services ->
SplitRouting=false. if the first services is a non VPN services followed
by a VPN service (or more than one!) all VPN services have
SplitRouting=true. This is controlled only by the ordering of the
services. This is why I don't like the idea to forward this information
to connmand-vpnd.
> But if this is something that is completely different from upstream point of
> view, we keep it to ourselves :). Anyways, we do manage services over D-Bus
> a lot.
As I said in the past, I am very interested to get most of your
downstream changes upstreamed eventually. So we should at least try to
figure out how things could work for upstream and downstream.
Thanks,
Daniel
------------------------------
Date: Wed, 23 Sep 2020 06:44:38 +0000
From: "Dembianny, Sven (GED-SDD1)" <sven.dembia...@bshg.com>
Subject: wpa3 support
To: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <5e742ec838164feca0f028192983c...@bshg.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
is it planned to implement WPA3 support?
Thanks, Sven
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- connman@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org
------------------------------
End of connman Digest, Vol 59, Issue 23
***************************************
