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: Connman to control OpenVPN connection (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Feb 2017 21:00:12 +0100
From: Daniel Wagner <[email protected]>
To: Florent Le Saout <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Connman to control OpenVPN connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi Florent,
On 02/08/2017 07:05 PM, Florent Le Saout wrote:
> On 31/01/2017 12:46, Florent Le Saout wrote:
>> On 01/01/2017 15:39, Daniel Wagner wrote:
>>> On 12/27/2016 06:52 PM, Florent Le Saout wrote:
>> 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.
The VPN Service itself has an AutoConnect property which tells
ConnMan to start it automatically.
>> 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?
No, ConnMan does not have any sort of keep alive test. Though if I
am not mistaken OpenVPN itself has such a bunch option:
--ping-exit n
Causes OpenVPN to exit after n seconds pass without reception
of a ping or other
packet from remote. This option can be combined with
--inactive, --ping, and
--ping-exit to create a two-tiered inactivity disconnect.
For example,
openvpn [options...] --inactive 3600 --ping 10 --ping-exit 60
when used on both peers will cause OpenVPN to exit within 60
seconds if its peer dis?
connects, but will exit after one hour if no actual tunnel data
is exchanged.
Though our plugin doesn't know yet about these option but those
could be easily added.
>>>> * 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
If possible use the 'ip' tool for reporting. The old tools don't show all
details. So for example 'ip route' gives for my current system:
$ ip r
default via 192.168.178.1 dev wlp2s0b1
192.168.178.0/24 dev wlp2s0b1 proto kernel scope link src 192.168.178.20
192.168.178.1 dev wlp2s0b1 scope link
which I started to like. It takes awhile to get accustom to it :)
>> 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)
So this message is suspicious. Not sure why that happens. Need to read
up what is happening.
>> 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 ?
Yes, the ordering of the services defines the default entry. Since there
is only one global default route, the first services sets it.
>>>> * 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 ]
Strange indeed. I haven't tested OpenVPN for a while. I'll setup server
and see if I get the same problems as you.
>> But I have still a question.
>> If Ethernet and Openvpn are providing DNS server, which one is
>> selected first ?
If you use the builtin dnsproxy than ConnMan knows which DNS server it
has to ask for resolving. So if OpenVPN is up than it will use those
entries provided by OpenVPN.
Thanks,
Daniel
ps: please try to avoid HTML emails and top posting.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 14
***************************************
