Workaroud for #290: delay the client-connect after concurrend disconnects

[bernhardkaindl]

Change-type: patch
Connects-to: #290

Due to e.g. network interruptions or a hardware/power-on reset of a BalenaOS device, the openvpn server can end up receiving a new connection from a openvpn client from which it believes that it still or already has an existing connection.

That existing connection could be from a no longer used, previous network connection or from the old boot of the BalenaOS device for example.

The OpenVPN server then replaces the old connection with the new connection, issues a client-disconnect event for the old connection and a client-connect event for the new connection, and both events happen at the same time.

If the device is unlucky, the client-connect event could get sent thru curl -X POST to the API before the client-disconnect event thru curl -X DELETE.

Of course, the precondition for this is that the server still believes that it has an old connection which it has to disconnect, when the reconnect happens.

This minimal workaround adds a sleep 1 before curl -s -X POST in the script to delay to POST to occur about one second after the DELETE and not concurrent.

An alternative, less simple solution would be to make the curl -X POST calls increment a connection counter and the curl -X DELETE calls decrement a counter of connections. The device would only be marked offline when this counter returns to 0.