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. [PATCH] test: Replace static glib with gi.repository module (Daniel Wagner) 2. Re: connman wifi disconnect problem (Daniel Wagner) 3. Re: wpa3 support (Daniel Wagner) 4. Re: wpa3 support (Daniel Wagner) 5. Re: [PATCH] vpn: Move vpn_provider_get_ident() declaration to vpn-provider.h (Daniel Wagner) 6. Re: [PATCH] test: Replace static glib with gi.repository module (Daniel Wagner) 7. Re: [PATCH 0/6] Support SplitRouting variable on vpnd (Jussi Laakkonen) ---------------------------------------------------------------------- Date: Wed, 23 Sep 2020 09:15:26 +0200 From: Daniel Wagner <w...@monom.org> Subject: [PATCH] test: Replace static glib with gi.repository module To: connman@lists.01.org Cc: KeithG <ys3al...@gmail.com>, Daniel Wagner <w...@monom.org> Message-ID: <20200923071526.21845-1-w...@monom.org> By using the dynamic gi.repository modules the scripts run also with Python3. --- test/monitor-connman | 4 ++-- test/monitor-services | 4 ++-- test/p2p-on-supplicant | 13 ++++--------- test/simple-agent | 4 ++-- test/test-counter | 5 +++-- test/test-session | 10 ++++------ 6 files changed, 17 insertions(+), 23 deletions(-) diff --git a/test/monitor-connman b/test/monitor-connman index 8403f913051b..c6edd76075ee 100755 --- a/test/monitor-connman +++ b/test/monitor-connman @@ -1,6 +1,6 @@ #!/usr/bin/python -import gobject +from gi.repository import GLib import dbus import dbus.mainloop.glib @@ -82,6 +82,6 @@ from dbus.lowlevel import MethodCallMessage, HANDLER_RESULT_NOT_YET_HANDLED bus.add_match_string("member=Update,interface=net.connman.Notification") bus.add_message_filter(message_filter) - mainloop = gobject.MainLoop() + mainloop = GLib.MainLoop() mainloop.run() diff --git a/test/monitor-services b/test/monitor-services index d570e5f57d9c..c520a8cda6c1 100755 --- a/test/monitor-services +++ b/test/monitor-services @@ -1,6 +1,6 @@ #!/usr/bin/python -import gobject +from gi.repository import GLib import dbus import dbus.mainloop.glib @@ -102,5 +102,5 @@ import dbus.mainloop.glib signal_name="PropertyChanged", path_keyword="path") - mainloop = gobject.MainLoop() + mainloop = GLib.MainLoop() mainloop.run() diff --git a/test/p2p-on-supplicant b/test/p2p-on-supplicant index 339d5eba726e..22501fc39d99 100755 --- a/test/p2p-on-supplicant +++ b/test/p2p-on-supplicant @@ -3,10 +3,9 @@ from os import O_NONBLOCK from sys import stdin, stdout, exit, version_info, argv from fcntl import fcntl, F_GETFL, F_SETFL -import glib +from gi.repository import GLib import dbus import dbus.mainloop.glib -import gobject import argparse WPA_NAME='fi.w1.wpa_supplicant1' @@ -32,7 +31,7 @@ P2P_GROUP_CAPAB_GROUP_OWNER = 1 << 0 flags = fcntl(stdin.fileno(), F_GETFL) flags |= O_NONBLOCK fcntl(stdin.fileno(), F_SETFL, flags) - glib.io_add_watch(stdin, glib.IO_IN, self.input_cb) + GLib.io_add_watch(stdin, GLib.IO_IN, self.input_cb) self.prompt() @@ -42,7 +41,7 @@ P2P_GROUP_CAPAB_GROUP_OWNER = 1 << 0 stdout.flush() def input_cb(self, fd, event): - if event != glib.IO_IN: + if event != GLib.IO_IN: return self.line += fd.read(); @@ -610,10 +609,6 @@ P2P_GROUP_CAPAB_GROUP_OWNER = 1 << 0 return command def main(): - if version_info.major != 2: - print('You need to run this under Python 2.x') - exit(1) - parser = argparse.ArgumentParser(description='Connman P2P Test') command_list = build_args(parser) @@ -634,7 +629,7 @@ P2P_GROUP_CAPAB_GROUP_OWNER = 1 << 0 bus = dbus.SystemBus() - mainloop = gobject.MainLoop() + mainloop = GLib.MainLoop() wpa_s = Wpa_s(bus, args.ifname, args.command + params) diff --git a/test/simple-agent b/test/simple-agent index 282785e23d34..04de3f604858 100755 --- a/test/simple-agent +++ b/test/simple-agent @@ -1,6 +1,6 @@ #!/usr/bin/python -import gobject +from gi.repository import GLib import dbus import dbus.service @@ -351,7 +351,7 @@ import sys except: "Cannot register vpn agent" - mainloop = gobject.MainLoop() + mainloop = GLib.MainLoop() mainloop.run() #manager.UnregisterAgent(path) diff --git a/test/test-counter b/test/test-counter index c09aabc12b4b..4c55162045c9 100755 --- a/test/test-counter +++ b/test/test-counter @@ -1,7 +1,8 @@ #!/usr/bin/python +from gi.repository import GLib + import sys -import gobject import dbus import dbus.service @@ -73,7 +74,7 @@ import dbus.mainloop.glib manager.RegisterCounter(path, dbus.UInt32(10), dbus.UInt32(period)) - mainloop = gobject.MainLoop() + mainloop = GLib.MainLoop() mainloop.run() #manager.UnregisterCounter(path) diff --git a/test/test-session b/test/test-session index e45d22b8e724..112074f16b75 100755 --- a/test/test-session +++ b/test/test-session @@ -1,15 +1,13 @@ #!/usr/bin/python +from gi.repository import GLib + import sys -import gobject -import string import dbus import dbus.service import dbus.mainloop.glib -import glib - import traceback def extract_list(list): @@ -293,11 +291,11 @@ import traceback app_path = sys.argv[2] bus = dbus.SessionBus() - app_name = "com.example.SessionApplication.%s" % (string.strip(app_path, "/")) + app_name = "com.example.SessionApplication.%s" % (str.strip(app_path, "/")) if sys.argv[1] == "run": name = dbus.service.BusName(app_name, bus) - mainloop = gobject.MainLoop() + mainloop = GLib.MainLoop() app = SessionApplication(bus, app_path, mainloop) -- 2.28.0 ------------------------------ Date: Wed, 23 Sep 2020 09:17:58 +0200 From: Daniel Wagner <w...@monom.org> Subject: Re: connman wifi disconnect problem To: KeithG <ys3al...@gmail.com> Cc: "Ryll, Jan (GED-SDD2)" <jan.r...@bshg.com>, "connman@lists.01.org" <connman@lists.01.org> Message-ID: <20200923071758.amhcwufh2km6c...@beryllium.lan> Content-Type: text/plain; charset=us-ascii On Tue, Sep 22, 2020 at 08:59:57AM -0500, KeithG wrote: > I cannot find the monitor-iwd script. This script is part of the iwd sources. > 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' The Python support for GLib gobject was always a bit troublesome and it seems it aged really badly. > 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 have the same problem with Python 3 on my distro. It still works with Python 2. The test script need to use the dynamic version of the GLib binding. See the other patch. > 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. I'll try to reproduce it later. Thanks, Daniel ------------------------------ Date: Wed, 23 Sep 2020 09:21:12 +0200 From: Daniel Wagner <w...@monom.org> Subject: Re: wpa3 support To: "Dembianny, Sven (GED-SDD1)" <sven.dembia...@bshg.com> Cc: "connman@lists.01.org" <connman@lists.01.org> Message-ID: <20200923072112.bhwcbaojqr5sw...@beryllium.lan> Content-Type: text/plain; charset=us-ascii Hi, On Wed, Sep 23, 2020 at 06:44:38AM +0000, Dembianny, Sven (GED-SDD1) wrote: > is it planned to implement WPA3 support? WPA3 needs to be supported by wpa_supplicant or iwd. This is not something ConnMan needs to implement (wrong layer). Thanks, Daniel ------------------------------ Date: Wed, 23 Sep 2020 09:25:49 +0200 From: Daniel Wagner <w...@monom.org> Subject: Re: wpa3 support To: "Dembianny, Sven (GED-SDD1)" <sven.dembia...@bshg.com> Cc: "connman@lists.01.org" <connman@lists.01.org> Message-ID: <20200923072549.ghnpnz7xt7dof...@beryllium.lan> Content-Type: text/plain; charset=us-ascii On Wed, Sep 23, 2020 at 09:21:13AM +0200, Daniel Wagner wrote: > WPA3 needs to be supported by wpa_supplicant or iwd. This is not > something ConnMan needs to implement (wrong layer). Well not completely true. In case of wpa_supplicant I am sure we need to update the plugins/wifi.c plugin. Just to make it clear, I wont do it due to lack of time. For iwd, I expect only small or even none needed modification on ConnMan side. Maybe ask on the iwd mailing list or on the #iwd IRC channel about the feature. ------------------------------ Date: Wed, 23 Sep 2020 09:28:09 +0200 From: Daniel Wagner <w...@monom.org> Subject: Re: [PATCH] vpn: Move vpn_provider_get_ident() declaration to vpn-provider.h To: Jussi Laakkonen <jussi.laakko...@jolla.com> Cc: connman@lists.01.org Message-ID: <20200923072809.6olczz46kbsyi...@beryllium.lan> Content-Type: text/plain; charset=us-ascii Hi Jussi, On Tue, Sep 22, 2020 at 12:02:18PM +0300, Jussi Laakkonen wrote: > All the functions the VPN plugins would need should be declared in the > relevant headers. VPNs do not need to include vpn/vpn.h as the functions > declared there are not for plugins to use. > > Drop also the "../vpn.h" include from OpenVPN plugin, which was the only > plugin using vpn_provider_get_ident(). Patch applied. Thanks, Daniel ------------------------------ Date: Wed, 23 Sep 2020 09:28:29 +0200 From: Daniel Wagner <w...@monom.org> Subject: Re: [PATCH] test: Replace static glib with gi.repository module To: connman@lists.01.org Cc: KeithG <ys3al...@gmail.com> Message-ID: <20200923072829.7umnct2wzhyxd...@beryllium.lan> Content-Type: text/plain; charset=us-ascii On Wed, Sep 23, 2020 at 09:15:26AM +0200, Daniel Wagner wrote: > By using the dynamic gi.repository modules the scripts run also with > Python3. Patch applied. ------------------------------ Date: Wed, 23 Sep 2020 17:45:44 +0300 From: Jussi Laakkonen <jussi.laakko...@jolla.com> Subject: Re: [PATCH 0/6] Support SplitRouting variable on vpnd To: Daniel Wagner <w...@monom.org> Cc: connman@lists.01.org Message-ID: <555f5b8f-edac-8774-545f-95607dc7f...@jolla.com> Content-Type: text/plain; charset=utf-8; format=flowed Good Evening Daniel, On 9/23/20 9:44 AM, Daniel Wagner wrote: > 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. > Right, then that "handle_routes" did confuse me in understanding this whole part. >> 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. Would it be reasonable to add checks to e.g., plugins/vpn.c when routes are being handled to test whether a non-split routed VPN has the default route assigned? And when it is missing add it since otherwise the routing fails to work. > >> 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 > It does make the vpnd side code quite difficult to understand. I think that lead me to wrong tracks originally (we had a separate option for default route but I thought split routing would do the same). We are not using that '-r'. But for me that was an issue to account for with the changes. If someone then uses that '-r' with vpnd it might be a bit annoying to notice it being removed. Not that functionality would change then anyways. It is quite old, so people might expect it to be present. But having it as only partially working is not good either. Would there be any real use cases for this? If not, I'm also rooting for ripping it out. >>> 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. Hm, I may have been misreading that part. Maybe because our fork has a quite different approach to that...Damn. I assumed that by controlling split routing a VPN can be set to be as the main route or to have it act like enterprise VPN, to have only the certain set of networks being routed over VPN. This is interesting and I didn't notice the service ordering to be in control. Saving and reading the value from the config makes that part quite odd for me or is it just for restoring the previous state of service order after restart or something else? This I think gave me the idea of exposing the SplitRouting value. I had some faint memory that it was acceptable to move VPN controls more to vpnd, and this SplitRouting just seemed to be like that. I have another related issue on my hands that should be done at some point. From what I've understood there can be only one VPN per transport medium active at a time (src/connection.c) as it relies on the phy index. We have a dependency system specially for the service ordering, that is currently using struct reference but would be better to use indexes (a TODO for me). So with a connection between the VPN and the transport medium service the ordering seemed to work better in rapidly changing networking environments. Cannot anymore recall all the details, but it may have also something to do with the difference there is in service.c for historical reasons. > >> 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. > I'm glad to hear. I need to check on that service ordering difference a bit more. And to see what and why we have there. I'll return to these issues later on. I guess most of our changes we've been planning to upstream need first a RFC round or two. Hopefully we get to them in the near future, maybe even this year. Cheers, Jussi ------------------------------ 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 24 ***************************************