Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[connman-vpn] Increasing delay in VPN autoconnect. Contributes to JB#…
…42337 This commit changes the vpn autoconnection to operate as follows: - Try to connect a VPN if the default transport service is connected - Stop autoconnecting if there is no transport service - Stop autoconnecting if default transport service is not connected - Stop autoconnecting if default transport service is connected VPN - Keep loop running when a VPN is in connecting state - When kept in loop increase the delay periodically In order to show indication to the user it is important to let autoconnect try to connect a VPN. Otherwise in case of network going down to ready from online, or connecting a network which has no access to Internet there is no indication that VPN is being connected. The autoconnect function will be kept in main loop if there are VPNs to automatically connect and the delay will increase based on the attempt count. Every VPN_AUTOCONNECT_TIMEOUT_STEP (30) increases the delay with 1s up to 10s. The amount of attempts after which the delay no longer increases is VPN_AUTOCONNECT_TIMEOUT_ATTEMPTS_TRESHOLD (270). After initial call the delay is 1s, increasing up to 10s. Each call to vpn_auto_connect() is changed to remove the timeout function from main loop in order to reset the attempt counter and the delay. This way each change happening in networking conditions that triggers call to do_auto_connect() will also reset these and gets the autoconnect running with no delay, otherwise there may be a max. 10s delay before VPN is even attempted to connect. Each connman service change now triggers vpn_auto_connect() (ecf3ce0) so it is safe to drop out from main loop after no connected is found. Except ready -> online state change does not trigger anything. This reduces battery usage on situation, where VPN is to be connected automatically but the network goes offline (e.g., during night) so the VPN autoconnect would not be continuously running in the background with 1s intervals. Also, in case a VPN server goes unavailable for a short or longer period this will first try to connect more rapidly in the first 30 tries and increase the delay periodically.
- Loading branch information