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. [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 <[email protected]>
Subject: [PATCH] test: Replace static glib with gi.repository module
To: [email protected]
Cc: KeithG <[email protected]>, Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
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 <[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 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 <[email protected]>
Subject: Re: wpa3 support
To: "Dembianny, Sven (GED-SDD1)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: wpa3 support
To: "Dembianny, Sven (GED-SDD1)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: [PATCH] vpn: Move vpn_provider_get_ident() declaration to
vpn-provider.h
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: [PATCH] test: Replace static glib with gi.repository
module
To: [email protected]
Cc: KeithG <[email protected]>
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: [PATCH 0/6] Support SplitRouting variable on vpnd
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 59, Issue 24
***************************************
