#503 closed Bug / Defect (notabug)
iOS app sending OCC_EXIT, server process terminated
Reported by: | ratiox | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN git master branch (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | iOS App OCC_EXIT SIGTERM |
Cc: |
Description
Hi,
not sure, if this is the right place for this bug report, since it is related to both iOS App and the "regular" openvpn software.
Problem:
iOS App sends OCC_EXIT message when disconneting from server. Server proccess is terminating. iOS client cannot reconnect.
Software Version:
iOS App: 1.0.5 build 177 on iOS 64-bit
OpenVPN server: 2.1.x, 2.2.x, 2.3.x
Solution:
iOS App should not send OCC_EXIT message on disconnects. OpenVPN software should have an option to ignore OCC_EXIT message or to reinterpret it as something, that results in SIGUSR1 instead of SIGTERM.
Problem and workaround are documented here:
https://forums.openvpn.net/topic17423.html
Thank you!
Martin
Change History (3)
comment:1 Changed 9 years ago by
Resolution: | → notabug |
---|---|
Status: | new → closed |
comment:2 Changed 8 months ago by
I would like to add that the suggested workaround (adding "mode server") conflicts with the usage of "secret /path/to/static.key".
I now have a workaround with systemd restarting the service unit. I added Restart=on-success in an override.conf.
comment:3 Changed 7 months ago by
--secret
is something which is heavily discouraged, as it's not secure enough for today's standards, and it will no longer be supported in 2.7.x
This said, this ticket was originally about the iOS client, which does not support --secret
at all (and never will).
As you found out in the forum thread, having the server actually run as server by specifying
"mode server"
in the server config will avoid it ending when the client disconnects (=sending an OCC_EXIT in UDP mode if "explicit-exit-notify" is active).
So while one could add extra options, I think the workaround is good enough given the already-overwhelming number of special-case options we have to maintain.