Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, 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 0/6] VPN provider fixes and VPNC VPN agent support
(Daniel Wagner)
2. RE: connman installs duplicate routes? (David Weidenkopf)
----------------------------------------------------------------------
Message: 1
Date: Wed, 5 Jun 2019 14:33:08 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/6] VPN provider fixes and VPNC VPN agent support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Tue, May 28, 2019 at 03:47:28PM +0300, Jussi Laakkonen wrote:
> This set of patches improves and fixes some issues with vpn-provider.c
> and implements VPN agent support for VPNC.
>
> vpn-provider.c changes:
> * Support plugin specific data in provider. Plugins may set pointer to
> data for latter use, e.g., in case notify needs additional data.
> * Support retrieval of setting string immutable status. The main
> values within provider have the same status as the provider as other
> strings have individual statuses. Some VPN plugins need to
> temporarily cache credentials, but immutable ones should not be
> cleared.
> * Allow only DBUS_TYPE_STRING values in set_property()
>
> VPNC changes:
> * Support VPN agent for setting authentication credentials. VPNC now
> is able to retrieve credentials using agent, if any, and clears them
> after writing the credentials to VPNC process, so VPN agent is used
> also with next connect attempt and credentials are not stored in
> provider.
> * Detect authentication and connection errors which VPNC outputs to
> stderr. If these are detected provider is notified with appropriate
> error code.
> * Check the D-Bus message arg types in notify. With invalid types
> crash would be expected.
Many thanks for your excellent work. The commit message are really
helping understanding what's going on :)
All patches applied. Hopefully I got it right. Scream if I screwed it up!
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 5 Jun 2019 14:54:21 +0000
From: David Weidenkopf <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: connman installs duplicate routes?
Message-ID:
<06C3949C7271B8419F288F951ED39EC2076B41@AME-MBX-PRD02.arthrex.local>
Content-Type: text/plain; charset="us-ascii"
Hi Daniel,
Thanks for our reply. You have confirmed what I learned since reading the code.
I have not done any testing yet, but my concern is how fast connections
failover to WiFi when ethernet is disconnected. My assumption was that having a
route present would improve the user experience.
What is the preferred configuration when a user has configured WiFi and then
connects ethernet? Is there a better way than using
SingleConnectedTechnology=true?
Regards,
David
________________________________________
From: Daniel Wagner [[email protected]]
Sent: Wednesday, June 05, 2019 2:20 AM
To: David Weidenkopf
Cc: [email protected]
Subject: Re: connman installs duplicate routes?
Hi David,
On Thu, May 23, 2019 at 11:23:19PM +0000, David Weidenkopf wrote:
> Hi, I am using connman 1.35. If I enable both a ethernet and wifi
> service, the default route is selected as you would expect. However,
> multiple routes will be created for the LAN.
For every Service which is in either in online or ready state ConnMan
will add a route to the routing table.
> ~# ip route show
> default via 192.168.16.1 dev eth0
> 1.0.0.1 via 192.168.16.1 dev eth0
> 1.0.0.1 via 192.168.16.1 dev wifi0
> 1.1.1.1 via 192.168.16.1 dev eth0
> 1.1.1.1 via 192.168.16.1 dev wifi0
> 192.168.16.0/24 dev wifi0 proto kernel scope link src 192.168.16.40
> 192.168.16.0/24 dev eth0 proto kernel scope link src 192.168.16.29
> 192.168.16.1 dev eth0 scope link
> 192.168.16.1 dev wifi0 scope link
>
> This output is after ethernet has been disconnected and been
> reconnected. The default route is eth0 as expected. However, there
> are two LAN routes with the wifi0 route being first and being
> selected. It seems that connman should either remove the wifi0 route
> or set a metric on it.
The routes are added by the kernel and not by ConnMan. It seems it is
not possible to change the metric of an existing route [1], instead
ConnMan would need to delete the route set by the kernel and set a new
one with a metric.
> The impact is that LAN traffic is sent over wifi0 instead of eth0. Using
>
> SingleConnectedTechnology=true
>
> in the configuration works around this but seems to be a discouraged
> setting. Also, it means that wifi is not connected when ethernet is.
Yes, that's correct. Though I haven't really understood why
you want to have the Ethernet and WiFi link into the same network up
and running.
> What is the best way to configure/use connman when ethernet and wifi
> are present?
As usual this depends on what you want to achieve.
> Is this a defect?
Yes and no. I agree it would be good to add the metric to the
links. But then it is only important if you have two links to the same
network, IIUC.
Thanks,
Daniel
[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.iu.edu_hypermail_linux_net_0504.3_0017.html&d=DwIBAg&c=DerLBi25kwTldccx5BE8Yg&r=2EEPhN2n4EOk5Bc2u6g97c4a9NaIyf_MMwxLgRis7kg&m=pV4xXIzrsgQUMPfo6lW4ipkeLomvDZ1ZxDkxAq75cEw&s=QsFExu90AOISKUtWdayA9f0Q9IxQoU6X2mrQz6MSOm8&e=
This e-mail and any files transmitted with it are the property of Arthrex, Inc.
and/or its affiliates, are confidential, and are intended solely for the use of
the individual or entity to whom this e-mail is addressed. If you are not one
of the named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender at 239-643-5553 and
delete this message immediately from your computer. Any other use, retention,
dissemination forwarding, printing or copying of this e-mail is strictly
prohibited. Please note that any views or opinions presented in this email are
solely those of the author and do not necessarily represent those of the
company. Finally, while Arthrex uses virus protection, the recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 44, Issue 2
**************************************
