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] openvpn: Ensure complete VPN provider state transition when
disconnecting
(Jussi Laakkonen)
2. Re: Next release (Jussi Laakkonen)
3. Re: Connman 1.35 authentication timeout and alternate configuration for
wired interface
(chaitanya cherukuri)
4. Re: Connman 1.35 authentication timeout and alternate configuration for
wired interface
(Daniel Wagner)
5. Re: [PATCH] openvpn: Ensure complete VPN provider state transition when
disconnecting
(Daniel Wagner)
6. Re: Connman 1.35 authentication timeout and alternate configuration for
wired interface
(chaitanya cherukuri)
7. Re: Connman 1.35 authentication timeout and alternate configuration for
wired interface
(Daniel Wagner)
----------------------------------------------------------------------
Date: Thu, 23 Jan 2020 16:29:58 +0200
From: Jussi Laakkonen <[email protected]>
Subject: [PATCH] openvpn: Ensure complete VPN provider state
transition when disconnecting
To: [email protected]
Message-ID: <[email protected]>
Explicitly set VPN provider disconnect state to ensure full state
transition from ready -> disconnect -> idle. The OpenVPN process may
refuse to shut down completely because of VPN interface being busy
(openvpn request >FATAL:ERROR: Cannot ioctl TUNSETIFF vpn0: Device or
resource busy (errno=16)) and a process is left behind. The cause for
such behavior is from OpenVPN TCP "Connection reset" leading to "Restart
pause" of increasing amount of seconds. This happens when the server has
some limits for re-connections, or the server is simply slow in
accepting TCP clients, or the transport abruptly goes away. As a result
the state transition to ready -> disconnect -> idle is not complete.
By updating the state in ov_disconnect()
vpn_provider.c:__vpn_provider_connect() is prevented from connecting
until the state transition is complete. Commit
be1b90c6db3d0c71a25369ac1fb8c5628ea28acc introduced this problem by
implementing the ov_disconnect() so vpn.c:vpn_disconnect() did not do
the state transition for OpenVPN.
---
vpn/plugins/openvpn.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/vpn/plugins/openvpn.c b/vpn/plugins/openvpn.c
index e5d9d943..75f5cb86 100644
--- a/vpn/plugins/openvpn.c
+++ b/vpn/plugins/openvpn.c
@@ -1114,6 +1114,8 @@ static void ov_disconnect(struct vpn_provider *provider)
return;
connman_agent_cancel(provider);
+
+ vpn_provider_set_state(provider, VPN_PROVIDER_STATE_DISCONNECT);
}
static int ov_device_flags(struct vpn_provider *provider)
--
2.20.1
------------------------------
Date: Thu, 23 Jan 2020 16:38:11 +0200
From: Jussi Laakkonen <[email protected]>
Subject: Re: Next release
To: Richard Röjfors <[email protected]>
Cc: Daniel Wagner <[email protected]>, connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Richard,
On 1/22/20 1:50 PM, Richard Röjfors wrote:
>
> Yes we are using TCP.
>
I assumed so, I think I faced a similar problem with our setup testing
free VPNBook OpenVPN using TCP. But yours may still be a different one.
>
> Sounds great! I will try to verify it. Its not super easy to reproduce,
> but over time and a few
> devices it always happens. I'm thinking I could hack ofono a little to
> simulate
> the situation....
>
I submitted a patch for OpenVPN plugin just moments ago to connman list.
Please check if that improves your situation. After all, it is fixing a
regression introduced by the changes I sent for OpenVPN.
I still have a hunch there could be an improvement in place for the
vpn-provider.c to track the connman state, and to delay the connection
if connman is not reporting to be online. This would prevent connections
to VPNs when, in case just like yours, the default service (mobile data,
wifi) goes down only momentarily.
In our fork we have this functionality already implemented. Now I just
need to find time to create a patch/patches against connman upstream for
Daniel and others reading the list to review.
Sincerely,
Jussi
------------------------------
Date: Thu, 23 Jan 2020 10:15:52 -0500
From: chaitanya cherukuri <[email protected]>
Subject: Re: Connman 1.35 authentication timeout and alternate
configuration for wired interface
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<calvd-wpqv8wzqxmjsg+iutnp0fvpjbspelopyfudcb0vphy...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
On Mon, Jan 20, 2020 at 2:28 PM Daniel Wagner <[email protected]> wrote:
>
> Hi,
>
> Please only text mails.
>
> On Mon, Jan 20, 2020 at 01:12:01PM -0500, chaitanya cherukuri wrote:
> > I'm using connman version 1.35 with Yocto( sumo). I have a couple of
> > questions.
>
> Consider to update ConnMan. 1.35 is over 2 years old.
>
I'm planning to update it to 1.37 with the same Yocto version(sumo).
Hopefully, that shouldn't be any problem.
> > 1) I have this annoying issue where the WiFi on my imx6 is not
> > authenticating. Is there any e any configuration that I need to set to
> > increase the timeout for authentication? I see this in dmesg:
> >
> > wlan0: authenticate with c8:d3:a3:59:68:ca
> > wlan0: send auth to c8:d3:a3:59:68:ca (try 1/3)
> > wlan0: send auth to c8:d3:a3:59:68:ca (try 2/3)
> > wlan0: send auth to c8:d3:a3:59:68:ca (try 3/3)
> > wlan0: authentication with c8:d3:a3:59:68:ca timed out
>
> This looks like a problem in the driver or firmware layer. Enable
> wpa_supplicant logging.
>
I will enable the logging and look into this.
> > 2) If both Wired and Wireless are connected, I cannot ping the device with
> > the wired IP address. Again, Is there any configuration that I missed?
>
> Check the rp_filter settings.
>
> > 3) If the DHCP server fails to automatically assign the IP address, I would
> > like to assign an Alternative configuration to my wired interface. for this
> > do I need to manage this with the script or is there any configuration that
> > I can set?
>
> ConnMan will automatically assign a IPv4LL address if DHCP fails.
>
As a simple test, I unplugged the ethernet cable going to the server
assuming that ConnMan doesn't get a DHCP lease
so that the IPv4LL state machine is triggered and assigns an address
automatically but this didn't happen. Do I need to install zeroconf
recipe?
> Thanks,
> Daniel
--
--
Chaitanya
------------------------------
Date: Thu, 23 Jan 2020 16:44:22 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Connman 1.35 authentication timeout and alternate
configuration for wired interface
To: chaitanya cherukuri <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Thu, Jan 23, 2020 at 10:15:52AM -0500, chaitanya cherukuri wrote:
> > ConnMan will automatically assign a IPv4LL address if DHCP fails.
> >
> As a simple test, I unplugged the ethernet cable going to the server
> assuming that ConnMan doesn't get a DHCP lease
> so that the IPv4LL state machine is triggered and assigns an address
> automatically but this didn't happen.
No that wont work. If you unplug the ethernet cable the interface will
be shutdown. If you want to test this, just attach your device to a
switch which has no uplink and no DHCP server connected to it.
> Do I need to install zeroconf recipe?
I don't think so. This is not a config option. It's always builtin and
activated.
Thanks,
Daniel
------------------------------
Date: Thu, 23 Jan 2020 18:08:45 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] openvpn: Ensure complete VPN provider state
transition when disconnecting
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Thu, Jan 23, 2020 at 04:29:58PM +0200, Jussi Laakkonen wrote:
> Explicitly set VPN provider disconnect state to ensure full state
> transition from ready -> disconnect -> idle. The OpenVPN process may
> refuse to shut down completely because of VPN interface being busy
> (openvpn request >FATAL:ERROR: Cannot ioctl TUNSETIFF vpn0: Device or
> resource busy (errno=16)) and a process is left behind. The cause for
> such behavior is from OpenVPN TCP "Connection reset" leading to "Restart
> pause" of increasing amount of seconds. This happens when the server has
> some limits for re-connections, or the server is simply slow in
> accepting TCP clients, or the transport abruptly goes away. As a result
> the state transition to ready -> disconnect -> idle is not complete.
>
> By updating the state in ov_disconnect()
> vpn_provider.c:__vpn_provider_connect() is prevented from connecting
> until the state transition is complete. Commit
> be1b90c6db3d0c71a25369ac1fb8c5628ea28acc introduced this problem by
> implementing the ov_disconnect() so vpn.c:vpn_disconnect() did not do
> the state transition for OpenVPN.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Thu, 23 Jan 2020 12:57:56 -0500
From: chaitanya cherukuri <[email protected]>
Subject: Re: Connman 1.35 authentication timeout and alternate
configuration for wired interface
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<calvd-wpvcj4a_bzjsgbubp3gwfks0ify2-wiuvsjekeyj7m...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
On Thu, Jan 23, 2020 at 10:44 AM Daniel Wagner <[email protected]> wrote:
>
> Hi,
>
> On Thu, Jan 23, 2020 at 10:15:52AM -0500, chaitanya cherukuri wrote:
> > > ConnMan will automatically assign a IPv4LL address if DHCP fails.
> > >
> > As a simple test, I unplugged the ethernet cable going to the server
> > assuming that ConnMan doesn't get a DHCP lease
> > so that the IPv4LL state machine is triggered and assigns an address
> > automatically but this didn't happen.
>
> No that wont work. If you unplug the ethernet cable the interface will
> be shutdown. If you want to test this, just attach your device to a
> switch which has no uplink and no DHCP server connected to it.
>
Thank you this is working. When the unit detects there is no uplink an
IPv4LL address is assigned.
Upon every reboot, a new IPv4LL address is assigned. Is there any way
to have the same IPv4LL address?
> > Do I need to install zeroconf recipe?
>
> I don't think so. This is not a config option. It's always builtin and
> activated.
>
> Thanks,
> Daniel
Thanks,
Chaitanya
------------------------------
Date: Fri, 24 Jan 2020 08:48:01 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Connman 1.35 authentication timeout and alternate
configuration for wired interface
To: chaitanya cherukuri <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Chaitanya,
On Thu, Jan 23, 2020 at 12:57:56PM -0500, chaitanya cherukuri wrote:
> Thank you this is working. When the unit detects there is no uplink an
> IPv4LL address is assigned.
> Upon every reboot, a new IPv4LL address is assigned. Is there any way
> to have the same IPv4LL address?
No, IPv4LL is an autoconfig protocol, see
https://en.wikipedia.org/wiki/Link-local_address
Device discovering is done via the host name not the IP address
(mDNS). If you want to connect to a headless device with our Laptop, just type
in the
device name as URL to access it via port 80.
mDNS (aka zeroconf, bonjour) is supported by all modern operating
system.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 51, Issue 30
***************************************
