There is a race condition at boot, when both vpnclient and hotspot services are starting:
The hotspot check what's the gateway interface and detects that it is eth0. It configures the NAT rule according on this interface.
The VPN client starts, and thus the gateway interface changes to tun0
The VPN attempts to changes the NAT rules with the correct gateway interface, but detects that the hotspot isn't active (it's activating).
When both services are done, there is no access to internet when connected to the hotspot, because the NAT rule is incorrect.
Solution
There is probably a better solution than this, but here I just patch it by checking in the OpenVPN hook if the hotspot is active or activating.
PR Status
[x] Code finished and ready to be reviewed/tested
[x] The fix/enhancement were manually tested (if applicable)
Automatic tests
Automatic tests can be triggered on https://ci-apps-dev.yunohost.org/after creating the PR, by commenting "!testme", "!gogogadgetoci" or "By the power of systemd, I invoke The Great App CI to test this Pull Request!". (N.B. : for this to work you need to be a member of the Yunohost-Apps organization)
Problem
There is a race condition at boot, when both vpnclient and hotspot services are starting:
eth0
. It configures the NAT rule according on this interface.tun0
When both services are done, there is no access to internet when connected to the hotspot, because the NAT rule is incorrect.
Solution
There is probably a better solution than this, but here I just patch it by checking in the OpenVPN hook if the hotspot is active or activating.
PR Status
Automatic tests
Automatic tests can be triggered on https://ci-apps-dev.yunohost.org/ after creating the PR, by commenting "!testme", "!gogogadgetoci" or "By the power of systemd, I invoke The Great App CI to test this Pull Request!". (N.B. : for this to work you need to be a member of the Yunohost-Apps organization)