Hi Jussi,

Den ons 22 jan. 2020 kl 11:34 skrev Jussi Laakkonen <jussi.laakkonen@jolla.com>:
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?

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....