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. Re: Next release (Richard Röjfors)
2. Re: Next release (Daniel Wagner)
3. Re: Next release (Jussi Laakkonen)
4. Re: Next release (Richard Röjfors)
5. Re: Next release (Richard Röjfors)
----------------------------------------------------------------------
Date: Wed, 22 Jan 2020 10:35:37 +0100
From: Richard Röjfors <[email protected]>
Subject: Re: Next release
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>
Message-ID:
<cahb-pjkmd5wxgckzjqnmxsfwkamvgo3sgfsulx3rsreg70y...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000e87045059cb73f00"
--000000000000e87045059cb73f00
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Daniel,
Den l=C3=B6r 18 jan. 2020 kl 18:07 skrev Daniel Wagner <[email protected]>:
> Hi,
>
> I think the current version is in good shape. We have a few 'new'
> features, such as VPN revamp, WireGuard support and iwd 1.0
> support. Also the usual bug fixes.
> Is there anything properly annoying with the current HEAD?
>
>
I have experienced a new issue after the openvpn rework.
Now if running over a cellular connection and if that connection goes up
and down "rapidly", (fast enough for openvpn still being connection when it
goes down).
We can end up in a state where the VPN is not brought up when
the connection goes up again.
This did not happen on 038eb34a9e56e54f710c8a4fb2d407cfed62fdac,
but happens on 2b5f5024728c2911dfd8cda71fece603cab81d05
--Richard
--000000000000e87045059cb73f00
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Daniel,</div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Den l=C3=B6r 18 jan. 2020 kl 18:07 skrev Da=
niel Wagner <<a href=3D"mailto:[email protected]";>[email protected]</a>>:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I think the current version is in good shape. We have a few 'new'<b=
r>
features, such as VPN revamp, WireGuard support and iwd 1.0<br>
support. Also the usual bug fixes.=C2=A0</blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<br>
Is there anything properly annoying with the current HEAD?<br>
<br></blockquote><div><br></div><div><div>I have experienced a new issue af=
ter the openvpn rework.<br>Now if running over a cellular connection and if=
that connection=C2=A0 goes up</div><div>and down "rapidly", (fas=
t enough for openvpn still being connection when it goes down).</div><div>W=
e can end up in a state where the VPN is not brought up when</div><div>the =
connection goes up again.</div><div><br></div><div>This did not happen on=
=C2=A0038eb34a9e56e54f710c8a4fb2d407cfed62fdac,</div><div>but happens on=C2=
=A02b5f5024728c2911dfd8cda71fece603cab81d05</div><div></div></div><div>=C2=
=A0</div><div>--Richard</div></div></div>
--000000000000e87045059cb73f00--
------------------------------
Date: Wed, 22 Jan 2020 11:27:01 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Next release
To: Richard Röjfors <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Hi Richard,
On Wed, Jan 22, 2020 at 10:35:37AM +0100, Richard Röjfors wrote:
> I have experienced a new issue after the openvpn rework.
> Now if running over a cellular connection and if that connection goes up
> and down "rapidly", (fast enough for openvpn still being connection when it
> goes down).
> We can end up in a state where the VPN is not brought up when
> the connection goes up again.
>
> This did not happen on 038eb34a9e56e54f710c8a4fb2d407cfed62fdac,
> but happens on 2b5f5024728c2911dfd8cda71fece603cab81d05
For the OpenVPN plugin these are the commits
2b5f5024728c ("openvpn: Use correct error value in VPN agent credential reply")
be1b90c6db3d ("openvpn: Rewrite plugin to support VPN agent and encrypted
private keys")
3c58f7325a5b ("vpn: Remove Host check in plugins")
Could you try to revert the first two and see if you still have the
problem. There are plenty of changes in the vpn core code between the
two version you tested. So first I'd like to rule out that the
rewrite of the plugin is the problem.
Please also provide logs.
Thanks,
Daniel
------------------------------
Date: Wed, 22 Jan 2020 12:34:49 +0200
From: Jussi Laakkonen <[email protected]>
Subject: Re: Next release
To: Daniel Wagner <[email protected]>, Richard Röjfors
<[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Richard and Daniel,
On 1/22/20 12:27 PM, Daniel Wagner wrote:
> Hi Richard,
>
> On Wed, Jan 22, 2020 at 10:35:37AM +0100, Richard Röjfors wrote:
>> I have experienced a new issue after the openvpn rework.
>> Now if running over a cellular connection and if that connection goes up
>> and down "rapidly", (fast enough for openvpn still being connection when it
>> goes down).
>> We can end up in a state where the VPN is not brought up when
>> the connection goes up again.
>>
>> This did not happen on 038eb34a9e56e54f710c8a4fb2d407cfed62fdac,
>> but happens on 2b5f5024728c2911dfd8cda71fece603cab81d05
>
> For the OpenVPN plugin these are the commits
>
> 2b5f5024728c ("openvpn: Use correct error value in VPN agent credential
> reply")
> be1b90c6db3d ("openvpn: Rewrite plugin to support VPN agent and encrypted
> private keys")
> 3c58f7325a5b ("vpn: Remove Host check in plugins")
>
> Could you try to revert the first two and see if you still have the
> problem. There are plenty of changes in the vpn core code between the
> two version you tested. So first I'd like to rule out that the
> rewrite of the plugin is the problem.
>
> Please also provide logs.
>
Do you Richard use OpenVPN with TCP? I have a hunch that long TCP
timeouts would cause trouble in that scenario. If there are openvpn
processes left running, I'm fairly certain that telling provider to go
to disconnect state in openvpn.c:oc_disconnect() would solve the issue.
I need to check other plugins as well, since the
vpn/plugins/vpn.c:vpn_disconnect() check for vpn_driver->disconnect()
might be required for all VPNs. But apparently, for OpenVPN when using
TCP it might solve the issue. I'll send a patch later this week when I
have time.
Cheers,
Jussi
------------------------------
Date: Wed, 22 Jan 2020 12:50:54 +0100
From: Richard Röjfors <[email protected]>
Subject: Re: Next release
To: Jussi Laakkonen <[email protected]>
Cc: Daniel Wagner <[email protected]>, connman <[email protected]>
Message-ID:
<CAHB-PjkednR+D-X60B3vopESu49Njx375pzm=e=mptqyk0v...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000c154d5059cb92363"
--000000000000c154d5059cb92363
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Jussi,
Den ons 22 jan. 2020 kl 11:34 skrev Jussi Laakkonen <
[email protected]>:
> Hi Richard and Daniel,
>
> On 1/22/20 12:27 PM, Daniel Wagner wrote:
> > Hi Richard,
> >
> > On Wed, Jan 22, 2020 at 10:35:37AM +0100, Richard R=C3=B6jfors wrote:
> >> I have experienced a new issue after the openvpn rework.
> >> Now if running over a cellular connection and if that connection goes
> up
> >> and down "rapidly", (fast enough for openvpn still being connection
> when it
> >> goes down).
> >> We can end up in a state where the VPN is not brought up when
> >> the connection goes up again.
> >>
> >> This did not happen on 038eb34a9e56e54f710c8a4fb2d407cfed62fdac,
> >> but happens on 2b5f5024728c2911dfd8cda71fece603cab81d05
> >
> > For the OpenVPN plugin these are the commits
> >
> > 2b5f5024728c ("openvpn: Use correct error value in VPN agent credential
> reply")
> > be1b90c6db3d ("openvpn: Rewrite plugin to support VPN agent and
> encrypted private keys")
> > 3c58f7325a5b ("vpn: Remove Host check in plugins")
> >
> > Could you try to revert the first two and see if you still have the
> > problem. There are plenty of changes in the vpn core code between the
> > two version you tested. So first I'd like to rule out that the
> > rewrite of the plugin is the problem.
> >
> > Please also provide logs.
> >
>
> Do you Richard use OpenVPN with TCP?
Yes we are using TCP.
I have a hunch that long TCP
> timeouts would cause trouble in that scenario. If there are openvpn
> processes left running, I'm fairly certain that telling provider to go
> to disconnect state in openvpn.c:oc_disconnect() would solve the issue.
>
> I need to check other plugins as well, since the
> vpn/plugins/vpn.c:vpn_disconnect() check for vpn_driver->disconnect()
> might be required for all VPNs. But apparently, for OpenVPN when using
> TCP it might solve the issue. I'll send a patch later this week when I
> have time.
>
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....
--Richard
--000000000000c154d5059cb92363
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Jussi,</div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">Den ons 22 jan. 2020 kl 11:34 skrev Jussi La=
akkonen <<a href=3D"mailto:[email protected]";>jussi.laakkonen@jo=
lla.com</a>>:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Hi Richard and Daniel,<br>
<br>
On 1/22/20 12:27 PM, Daniel Wagner wrote:<br>
> Hi Richard,<br>
> <br>
> On Wed, Jan 22, 2020 at 10:35:37AM +0100, Richard R=C3=B6jfors wrote:<=
br>
>> I have experienced a new issue after the openvpn rework.<br>
>> Now if running over a cellular connection and if that connection=
=C2=A0 goes up<br>
>> and down "rapidly", (fast enough for openvpn still being=
connection when it<br>
>> goes down).<br>
>> We can end up in a state where the VPN is not brought up when<br>
>> the connection goes up again.<br>
>><br>
>> This did not happen on 038eb34a9e56e54f710c8a4fb2d407cfed62fdac,<b=
r>
>> but happens on 2b5f5024728c2911dfd8cda71fece603cab81d05<br>
> <br>
> For the OpenVPN plugin these are the commits<br>
> <br>
> 2b5f5024728c ("openvpn: Use correct error value in VPN agent cred=
ential reply")<br>
> be1b90c6db3d ("openvpn: Rewrite plugin to support VPN agent and e=
ncrypted private keys")<br>
> 3c58f7325a5b ("vpn: Remove Host check in plugins")<br>
> <br>
> Could you try to revert the first two and see if you still have the<br=
>
> problem. There are plenty of changes in the vpn core code between the<=
br>
> two version you tested. So first I'd like to rule out that the<br>
> rewrite of the plugin is the problem.<br>
> <br>
> Please also provide logs.<br>
> <br>
<br>
Do you Richard use OpenVPN with TCP?</blockquote><div><br></div><div>Yes we=
are using TCP.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"> I have a hunch that long TCP <br>
timeouts would cause trouble in that scenario. If there are openvpn <br>
processes left running, I'm fairly certain that telling provider to go =
<br>
to disconnect state in openvpn.c:oc_disconnect() would solve the issue.<br>
<br>
I need to check other plugins as well, since the <br>
vpn/plugins/vpn.c:vpn_disconnect() check for vpn_driver->disconnect() <b=
r>
might be required for all VPNs. But apparently, for OpenVPN when using <br>
TCP it might solve the issue. I'll send a patch later this week when I =
<br>
have time.<br></blockquote><div><br></div><div>Sounds great! I will try to =
verify it. Its not super easy to reproduce, but over time and a few</div><d=
iv>devices it always happens. I'm thinking I could hack ofono a little =
to simulate</div><div>the situation....</div><div><br></div><div>--Richard<=
/div></div></div>
--000000000000c154d5059cb92363--
------------------------------
Date: Wed, 22 Jan 2020 13:00:30 +0100
From: Richard Röjfors <[email protected]>
Subject: Re: Next release
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>
Message-ID:
<cahb-pjnzlvzh0y0cr8ko8kyn_3wmucs4vwucpte_de2wye-...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="00000000000014766c059cb94694"
--00000000000014766c059cb94694
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Daniel,
Den ons 22 jan. 2020 kl 11:27 skrev Daniel Wagner <[email protected]>:
> Hi Richard,
>
> On Wed, Jan 22, 2020 at 10:35:37AM +0100, Richard R=C3=B6jfors wrote:
> > I have experienced a new issue after the openvpn rework.
> > Now if running over a cellular connection and if that connection goes =
up
> > and down "rapidly", (fast enough for openvpn still being connection whe=
n
> it
> > goes down).
> > We can end up in a state where the VPN is not brought up when
> > the connection goes up again.
> >
> > This did not happen on 038eb34a9e56e54f710c8a4fb2d407cfed62fdac,
> > but happens on 2b5f5024728c2911dfd8cda71fece603cab81d05
>
> For the OpenVPN plugin these are the commits
>
> 2b5f5024728c ("openvpn: Use correct error value in VPN agent credential
> reply")
>
I hardly see that this could be the root cause, we don't use any agent.
> be1b90c6db3d ("openvpn: Rewrite plugin to support VPN agent and encrypted
> private keys")
>
This one is of course suspicious ;)
> 3c58f7325a5b ("vpn: Remove Host check in plugins")
>
I don't think this can cause it...
>
> Could you try to revert the first two and see if you still have the
> problem. There are plenty of changes in the vpn core code between the
> two version you tested. So first I'd like to rule out that the
> rewrite of the plugin is the problem.
>
> Please also provide logs.
>
I need to do some filtering before I could provide logs.
What I have seen is that openvpn was never finished connecting and it
always says "init_instance" when getting the SIGTERM:
Jan 10 18:59:31 info connman-vpnd[502]: pid 21413 was not killed, retrying
after 2 sec
Jan 10 18:59:31 notice openvpn[21413]: SIGTERM[hard,init_instance]
received, process exiting
While the log from a previous stop (after which the VPN was brought up
again) looks like:
Jan 10 18:59:22 notice openvpn[820]: SIGTERM[hard,] received, process
exiting
--Richard
--00000000000014766c059cb94694
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Daniel,</div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Den ons 22 jan. 2020 kl 11:27 skrev Daniel =
Wagner <<a href=3D"mailto:[email protected]";>[email protected]</a>>:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Richard,<br>
<br>
On Wed, Jan 22, 2020 at 10:35:37AM +0100, Richard R=C3=B6jfors wrote:<br>
> I have experienced a new issue after the openvpn rework.<br>
> Now if running over a cellular connection and if that connection=C2=A0=
goes up<br>
> and down "rapidly", (fast enough for openvpn still being con=
nection when it<br>
> goes down).<br>
> We can end up in a state where the VPN is not brought up when<br>
> the connection goes up again.<br>
> <br>
> This did not happen on 038eb34a9e56e54f710c8a4fb2d407cfed62fdac,<br>
> but happens on 2b5f5024728c2911dfd8cda71fece603cab81d05<br>
<br>
For the OpenVPN plugin these are the commits<br>
<br>
2b5f5024728c ("openvpn: Use correct error value in VPN agent credentia=
l reply")<br></blockquote><div><br></div><div>I hardly see that this c=
ould be the root cause, we don't use any agent.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
be1b90c6db3d ("openvpn: Rewrite plugin to support VPN agent and encryp=
ted private keys")<br></blockquote><div><br></div><div>This one is of =
course suspicious ;)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
3c58f7325a5b ("vpn: Remove Host check in plugins")<br></blockquot=
e><div><br></div><div>I don't think this can cause it...</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Could you try to revert the first two and see if you still have the<br>
problem. There are plenty of changes in the vpn core code between the<br>
two version you tested. So first I'd like to rule out that the<br>
rewrite of the plugin is the problem.<br>
<br>
Please also provide logs.<br></blockquote><div><br></div><div>I need to do =
some filtering before I could provide logs.</div><div>What I have seen is t=
hat openvpn was never finished connecting and it always says "init_ins=
tance" when getting the SIGTERM:</div><div><br></div><div>Jan 10 18:59=
:31 info connman-vpnd[502]: pid 21413 was not killed, retrying after 2 sec<=
br>Jan 10 18:59:31 notice openvpn[21413]: SIGTERM[hard,init_instance] recei=
ved, process exiting<br></div><div>=C2=A0</div><div>While the log from a pr=
evious stop (after which the VPN was brought up again) looks like:<br>Jan 1=
0 18:59:22 notice openvpn[820]: SIGTERM[hard,] received, process exiting<br=
><br></div><div>--Richard</div></div></div>
--00000000000014766c059cb94694--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 51, Issue 27
***************************************
