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: Service remains on service list even if it is not longer
available (Jose Blanquicet)
2. Re: iptables - ignoring the entries from other processes
(Puustinen, Ismo)
3. Re: [PATCH v1 0/3] Use /dev/random instead of /dev/urandom
(Andr? Draszik)
4. Re: Connman to control OpenVPN connection (Florent Le Saout)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Feb 2017 08:55:59 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected], "MANIEZZO Marco (MM)"
<[email protected]>, [email protected]
Subject: Re: Service remains on service list even if it is not longer
available
Message-ID:
<cafc8ijltu8c+ozz6c8oqzwicqsmypq392krfeb6csorshnm...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Daniel,
On Sat, Feb 4, 2017 at 6:08 PM, Daniel Wagner wrote:
>>> When we get disconnected because of AP we are connected to goes out of
>>> range. ConnMan keeps showing such AP in the services list even though
>>> it is not longer available (We cannot connect to it). In addition,
>>> such AP will continue in our service list even if we connect to a new
>>> one. What is the propose of keeping that AP in the services list? From
>>> our point of view it creates confusion to the user. We would prefer to
>>> not do that, what do people think?
>>
>>
>> Ping? Is it how it supposed to be?
>
>
> Sorry, somehow your question fall through the cracks.
Don't worry.
> If I am not complete
> mistaken, ConnMan will show all AP which wpa_s lists. So if wpa_s is not
> removing the AP than you still will see it listed. Obviously, that is not
> what should happen. I suggest to check what wpa_s is doing by monitoring it.
Following you suggestion I monitored wpa_s while doing the same tests:
AP goes out of range or AP deauthenticate STA. Now, the wpa_s side is
correct; when AP is not longer in range then wpa_s removes it from the
scan results list and notifies it by sending a "BSSRemoved" D-Bus
signal. When ConnMan receives such signal in WiFi plugin,
network_removed(), ConnMan removes the network and thus the service
unless it is the network ConnMan was connected to, it is due to the
"Fast Reconnection" feature implemented by Naveen in a series of
patches starting from 6245582d0dc9a3f47a6880dabf437ee7c351caef. Such
feature is described as:
"The idea here is that we do not disable network on disconnect and let
wpa_s keep trying to find out that network. Only when ConnMan has
another network this network would be removed and new network would be
added."
Such feature works correctly and do what it is supposed to do but by
avoiding to disable the network in WiFi plugin then the service is not
removed from the services list. Now, assume such AP never comes back
into the range then user will continue seeing a service which is not
actually available because the corresponding AP is not longer in
range. It will be removed only in case of a new connection (I was
wrong in the initial description I wrote when I said it wasn't).
Now, as I said, we would prefer to avoid showing such ?unavailable?
service in the services list. We thought two possible solutions:
- Keep all the structures (service and network) allocated but make
such service unavailable via D-Bus, it means to not send it into the
list of Manager.GetServices() and unregister its patch from D-Bus.
Only when wpa_s notifies AP is back then we make it available again.
- Free all structures and recreate them only when wpa_s notifies the
AP is again in range but then we should ensure the service and plugin
state machines get updated correctly.
In both solutions we will be prepared for a possible reconnection from
wpa_s, following what Naveen implemented but avoiding to show the
service as part of the available services when it actually isn?t. What
do you think?
Regards,
Jose Blanquicet
------------------------------
Message: 2
Date: Wed, 8 Feb 2017 10:39:55 +0000
From: "Puustinen, Ismo" <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: iptables - ignoring the entries from other processes
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Mon, 2017-02-06 at 22:57 +0100, Usman S wrote:
> not be disturbed. Also I think we should also include the important
> xtables_lock before read and release after committing so that it is
> clean like iptables does. Yeah, the drawback could that if someone
> else is holding and has not released, Connman would be blocked as
> well
> but this seems to me a generic problem. Please let me know your
> comments.
I did a rough patch for the xtables lock some time ago:
https://github.com/ostroproject/ostro-os/pull/204/commits/4024bbe7ca708
e92e986f3e3622a9fc25dc26b34
------------------------------
Message: 3
Date: Wed, 08 Feb 2017 13:46:37 +0000
From: Andr? Draszik <[email protected]>
To: [email protected]
Subject: Re: [PATCH v1 0/3] Use /dev/random instead of /dev/urandom
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2017-02-07 at 12:16 +0300, Slava Monich wrote:
> Hi Daniel,
>
> > Hi,
> >
> > Is short don't block on /dev/urandom, use /dev/random.
> >
> > See http://www.2uo.de/myths-about-urandom/ for more details.
> >
> > Thanks,
> > Daniel
> >
>
> I'm a bit confused. I read that web page again and again - it claims?
> that it's /dev/urandom which should be used because it never blocks and?
> it's /dev/random which DOES block. But your comments imply the opposite?
> - that /dev/urandom blocks and /dev/random doesn't.
Doesn't /dev/urandom block if the entropy pool hasn't been initialised yet
(just after boot)? But that's probably not what was meant, and /dev/random
also blocks in that case.
Cheers,
Andre'
------------------------------
Message: 4
Date: Wed, 8 Feb 2017 19:05:10 +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,
Sorry to ask again for help, but I'm falling in the routing issue
described below almost all the time now (the default route is still
Ethernet and not vpn).
I can provide more information, like config files in use, to help to
figure out what's going on if needed.
Thanks,
Florent.
On 31/01/2017 12:46, Florent Le Saout wrote:
>
> 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
--
*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/20170208/31fdbf56/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 13
***************************************
