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] inet: Prevent glib source from being removed
twice (Daniel Wagner)
2. Re: [PATCH] service: Add EnableOnlineCheck config option
(Daniel Wagner)
3. Re: [RFC] wifi: make max connection retries configurable
(Daniel Wagner)
4. Re: Auto-connect from wpa_supplicant and ConnMan does not
become aware (Daniel Wagner)
5. Re: [RFC] Proposal for ConnMan session API extensions
(Daniel Wagner)
6. Re: [PATCH] inet: Prevent glib source from being removed
twice (Slava Monich)
7. Re: [RFC] wifi: make max connection retries configurable
(M?ns Rullg?rd)
8. Re: Connman to control OpenVPN connection (Florent Le Saout)
----------------------------------------------------------------------
Message: 1
Date: Tue, 31 Jan 2017 08:29:35 +0100
From: Daniel Wagner <[email protected]>
To: Slava Monich <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] inet: Prevent glib source from being removed
twice
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
> @@ -2262,7 +2265,7 @@ static int inet_rtnl_recv(GIOChannel *chan, gpointer
> user_data)
>
> rtnl_data->callback(h, rtnl_data->user_data);
>
> - inet_rtnl_cleanup(rtnl_data);
> + return 1;
> }
So we do not cleanup it here, instead we give back 1. Does this stand
for error or success? If it should be an error I would suggest to go
with -1 as with the rest in that function. On success just fall
through, but I guess you added return 1 on purpose, no?
The rest looks good to me.
Thanks,
Daniel
------------------------------
Message: 2
Date: Tue, 31 Jan 2017 08:48:04 +0100
From: Daniel Wagner <[email protected]>
To: Lukasz Nowak <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] service: Add EnableOnlineCheck config option
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Lukasz,
On Mon, Jan 30, 2017 at 02:55:53PM +0000, Lukasz Nowak wrote:
> The --disable-wispr switch does not disable the online http check.
> The src/wispr.c is executed unconditionally from service.c right now.
I see. I think we should fix then the --disable-wispr instead adding
an configuration option. Since we have already a wispr.c file I
suggest to move the wispr code from service.c to wispr.c. So that we
have something like:
int __connman_service_ipconfig_indicate_state(...)
{
[...]
case CONNMAN_SERVICE_STATE_READE:
__connman_wispr_check_portal(service, type); /* a better name
needed */
[...]
}
and we either add wispr.c an version for --disable-wispr in a #ifdef
block or maybe even better have a wispr-disabled.c (better name) which
contains just the READY to ONLINE transistion. And the configure
script just adds one or the other to the build.
BTW, there are also couple more of the __connman_wispr_start() calls
in the service.c file. That needs also to be addressed.
Thanks,
Daniel
------------------------------
Message: 3
Date: Tue, 31 Jan 2017 08:51:52 +0100
From: Daniel Wagner <[email protected]>
To: M?ns Rullg?rd <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 01/29/2017 08:42 PM, M?ns Rullg?rd wrote:
> What about making it a per-connection setting stored along with ssid and
> psk?
Sorry for the delay. Okay that avoid the global setting. If you don't
insist having a D-Bus option for this then I am fine with it. I say that
because Marcel wont be too happy if we add something like this to the
D-Bus API. But having it in the config file sounds like a good
compromise to me.
Thanks a lot for your patience.
Daniel
------------------------------
Message: 4
Date: Tue, 31 Jan 2017 08:52:48 +0100
From: Daniel Wagner <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: [email protected]
Subject: Re: Auto-connect from wpa_supplicant and ConnMan does not
become aware
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jose,
On 01/27/2017 10:30 AM, Jose Blanquicet wrote:
> We found a way to simulate AP which generates multiple WPS credentials
> on a single WPS provisioning step. It can be done by using hostapd,
> one will need to enable CONFIG_TESTING_OPTION into the config file and
> run ?set wps_testing_dummy_cred 1? from hostap_cli before doing
> "wpa_pbc / wps_pin".
>
> We worked on a patch and we will put it together with the series we
> have been working for RFC of WPS connections.
Excellent. Thanks for casing those bugs!
Thanks,
Daniel
------------------------------
Message: 5
Date: Tue, 31 Jan 2017 09:09:40 +0100
From: Daniel Wagner <[email protected]>
To: "Achtzehn Andreas (CM/ENA4)" <[email protected]>,
Lukasz Nowak <[email protected]>, "Nakamura, Yusuke (ADITJ/SWG)"
<[email protected]>
Cc: "[email protected]" <[email protected]>, "Hoyer Marko
(ADITG/SWG)" <[email protected]>, "EXTERNAL Thorwirth Bjoern
(Brunel, CM-CI1/ERN5-E)" <[email protected]>,
"Ishikawa, Tetsuri (ADITJ/SWG)" <[email protected]>
Subject: Re: [RFC] Proposal for ConnMan session API extensions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Andreas,
>> One more subtle difference is that our source IP extension would act
>> on the forwarding behavior of the host running ConnMan. In Lukasz patch
>> the rule is applied to a netfilter chain that is acting on local
>> processes instead. Our proposal may therefore be used for implementing,
>> e.g., a webservice on a router running ConnMan which would enable
>> forwarding after authentication (just one example). This also changes
>> the meaning of "source IP" in our case. For Lukasz patch the source IP
>> apparently matches a local interface on the host running ConnMan, while
>> for us it's (as Lukasz I think pointed out already) an arbitrary
>> source IP.
>
> Thanks for the detailed explanation. This really helps understanding
> what you are trying to solve. ConnMan so far ignored all non local use
> cases. The Session API was also designed in this way. I haven't really
> thought it through it yet so I can't really say something useful at this
> point. Let me think a bit on this.
After a good night of sleep (okay 2) I have something for you. It is
possible to write your own policy plugin (see include/session.h). That
allows you to integrate ConnMan in your environment. I had a lot of
discussion with the ConnMan community on how the GENIVI use cases could
be implemented. And we didn't really find a generic solution which
worked for everyone. That's why we settled on a compromise and have
introduced the plugin infrastructure for the sessions.
I even did a small prototype (which doesn't compile anymore) for it [1].
So adding a new plugin which integrates into such environment works for
me. I just don't think it is a good idea to add such feature to the core
of ConnMan directly, because as I said previously, ConnMan was designed
to run on the edges of the network not in the middle of it.
Thanks,
Daniel
[1]
https://github.com/igaw/pold/blob/master/connman/0001-session_policy_pold-Add-session-plugin-for-remote-co.patch
------------------------------
Message: 6
Date: Tue, 31 Jan 2017 11:21:13 +0200
From: Slava Monich <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] inet: Prevent glib source from being removed
twice
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 31/01/17 09:29, Daniel Wagner wrote:
>
>> @@ -2262,7 +2265,7 @@ static int inet_rtnl_recv(GIOChannel *chan, gpointer
>> user_data)
>>
>> rtnl_data->callback(h, rtnl_data->user_data);
>>
>> - inet_rtnl_cleanup(rtnl_data);
>> + return 1;
>> }
> So we do not cleanup it here, instead we give back 1. Does this stand
> for error or success? If it should be an error I would suggest to go
> with -1 as with the rest in that function. On success just fall
> through, but I guess you added return 1 on purpose, no?
You may argue that this is unnecessary.
1. If we call inet_rtnl_cleanup here and return zero, the caller
(inet_rtnl_event) would return TRUE telling glib to not remove the
source, which is fine. Everything is cool.
2. With this change, inet_rtnl_recv returns non-zero, the caller
(inet_rtnl_event) zeros watch_id, calls inet_rtnl_cleanup and returns
FALSE telling glib to remove the source. The result is the same.
You can think of it as an attempt to simplify the interface between
inet_rtnl_event and inet_rtnl_recv - clean things up if the latter
returns non-zero, do nothing if it returns zero.
Good catch. Do you want to remove this change? Strictly speaking it
doesn't fix anything.
> The rest looks good to me.
>
> Thanks,
> Daniel
>
Regards,
-Slava
------------------------------
Message: 7
Date: Tue, 31 Jan 2017 10:00:08 +0000
From: M?ns Rullg?rd <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [RFC] wifi: make max connection retries configurable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Daniel Wagner <[email protected]> writes:
> On 01/29/2017 08:42 PM, M?ns Rullg?rd wrote:
>> What about making it a per-connection setting stored along with ssid and
>> psk?
>
> Sorry for the delay. Okay that avoid the global setting. If you don't
> insist having a D-Bus option for this then I am fine with it. I say
> that because Marcel wont be too happy if we add something like this to
> the D-Bus API. But having it in the config file sounds like a good
> compromise to me.
Well, in our system a per-connection setting would need to be accessible
over d-bus.
--
M?ns Rullg?rd
------------------------------
Message: 8
Date: Tue, 31 Jan 2017 12:46:25 +0100
From: Florent Le Saout <[email protected]>
To: Daniel Wagner <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: Connman to control OpenVPN connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Daniel,
Thanks for your feedback.
Sorry for the delay but I was fully focused on something else recently.
See my comments inline.
Thanks,
Florent.
On 01/01/2017 15:39, Daniel Wagner wrote:
> Hi Florent,
>
> On 12/27/2016 06:52 PM, Florent Le Saout wrote:
>> Hello,
>>
>> I'm trying to get vpn connection managed by connman.
>>
>> I've been looking in the documentation in the sources or website, but
>> didn't find my answer yet.
>>
>> So far, I can connect to my OpenVPN server manually via connmanctl, so I
>> guess my vpn config file is quite ok.
>>
>> But the remaining question is about the autoconnection and link
>> verification.
>>
>> From my understanding autoconnect, reconnect etc, that we can configure
>> in main config file only applies to technologies, but VPNs are not
>> technologies from connman perspectives, so they are listed as service
>> (maybe my statement here is not correct ?).
>
> If you set your Ethernet Service and VPN Service to autoconnect, the
> VPN tunnel will be openened after the Ethernet Service got connected.
Regarding Ethernet, i see clearly that I can set it here
"DefaultAutoConnectTechnologies = " in the main.conf, which is properly
set as default.
But this is only valid regarding technologies, and VPN is not a
technology but a service, so it's not possible to set it here.
So could you tell me if my assumptions are correct and how to set
AutoConnect and autoreconnect for VPN ?
>
>
>> My goal is to be able, as soon as I get proper network connection,
>> either by ethernet, cellular or wifi technologies to get connected to my
>> vpn server and in case of disconnection (so implicitly a connection
>> check is done in background) to get reconnected.
>
> That should work in theory :)
It seems it's properly managed but I have to test a bit more.
>
>> * How to setup autoconnect and reconnect with OpenVPN (also in case we
>> change technology from ethernet to cellular for instance) ?
>
> ConnMan will reconnect the tunnel when the underlying connection dies
> and there is a new connection established.
Let say for a weird reason that my tunnel is not working anymore but the
underling connection is still ok, then nothing will do a check inside
excepted OpenVPN client itself ? There is nothing inside connman which
will detect loss of connection of the tunnel itself even if the
underlying connection is still valid?
>
>> * Regarding routes, I would like to know how to apply the routes
>> pushed by the OpenVPN server as the default route?
>
> ConnMan will add the routes automatically to your routing table. You
> just need to push them from the server, e.g. do something like
>
> push "redirect-gateway def1"
I have that in my server config (I was about to add it to my original
question) :
* push "redirect-gateway def1 bypass-dhcp"
When I do run OpenVPN manually, I get the route properly setup with my
tunnel as default route, but with connman it's not the case anymore.
Destination Gateway Genmask Flags Metric Ref
Use Iface
default 10.8.0.1 128.0.0.0 UG 0
0 0 tun0
I get those debug messages :
connman-vpnd[1099]: vpn0 {update} flags 102609 <UP,RUNNING,LOWER_UP>
connmand[1095]: vpn0 {update} flags 102609 <UP,RUNNING,LOWER_UP>
connmand[1095]: vpn0 {newlink} index 12 address 00:00:00:00:00:00
mtu 1500
connmand[1095]: vpn0 {newlink} index 12 operstate 6 <UP>
connman-vpnd[1099]: vpn0 {newlink} index 12 operstate 6 <UP>
connmand[1095]: vpn0 {add} address 10.8.0.18/32 label vpn0 family 2
connmand[1095]: Adding host route failed (Network is unreachable)
connmand[1095]: rp_filter set to 2 (loose mode routing), old value was 0
Connected vpn_Test_com
connmanctl> connmand[1095]: ipconfig state 4 ipconfig method 1
connmand[1095]: vpn0 {add} route 10.8.0.1 gw 0.0.0.0 scope 253 <LINK>
connmand[1095]: eth0 {add} route 149.202.178.61 gw 192.168.4.4 scope
0 <UNIVERSE>
connmand[1095]: eth0 {del} route 0.0.0.0 gw 192.168.4.4 scope 0
<UNIVERSE>
connmand[1095]: eth0 {add} route 0.0.0.0 gw 192.168.4.4 scope 0
<UNIVERSE>
And for some reason, since I've added this line
"Networks=192.168.1.0/255.255.255.0/10.8.0.1" in my openvpn config file
for connman, it works almost all the time.
It seems that when connman services are listed this way :
# connmanctl services
* R Test VPN vpn_Test_com
*AO Wired ethernet_7076ff01000c_cable
My routing table is as expected :
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric
Ref Use Iface
default * 0.0.0.0 U
0 0 0 vpn0
10.8.0.1 * 255.255.255.255 UH
0 0 0 vpn0
192.168.4.0 * 255.255.254.0 U
0 0 0 eth0
192.168.4.4 * 255.255.255.255 UH
0 0 0 eth0
192.168.4.201 192.168.4.4 255.255.255.255 UGH 0
0 0 eth0
But when connman services are listed this way :
# connmanctl services
*AO Wired ethernet_7076ff01000c_cable
* R Test VPN vpn_Test_com
My routing table is not as expected :
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
default 192.168.4.4 0.0.0.0 UG 0
0 0 eth0
10.8.0.1 * 255.255.255.255 UH 0
0 0 vpn0
192.168.4.0 * 255.255.254.0 U 0
0 0 eth0
192.168.4.4 * 255.255.255.255 UH 0
0 0 eth0
192.168.4.201 192.168.4.4 255.255.255.255 UGH 0
0 0 eth0
Do you think that the order of the services has any impact on the
default routing interface ?
>> * Regarding DNS server, I also would like to know how to get the DNS
>> pushed by the OpenVPN applied in resolv.conf ?
>
> Same here ConnMan will take of the DNS resolving, you might need to push
> the right DNS entries from the OpenVPN server:
>
> push "dhcp-option DNS 85.25.128.10"
> push "dhcp-option DNS 85.25.255.10"
This part is working properly, when I do a connmanctl services vpn_....
I get :
Nameservers = [ 10.8.0.1 ]
But I have still a question.
If Ethernet and Openvpn are providing DNS server, which one is selected
first ?
>
> HTH,
>
> Thanks,
> Daniel
--
*Florent LE SAOUT*
R&D department
Embedded Software Developer
AUSY contractor for KERLINK
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170131/5ab6b3be/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 40
***************************************
