Closed ghost closed 2 years ago
True, OpenVPN's built-in message when all the --remote
endpoints from .ovpn were refused is a bit over generic. It would not suggest user that the "Force TCP" setting is probably the reason.
When parsing the .ovpn, the OpenVPN internals raise REMOTE
notification for each --remote
in .ovpn. Our notification handler gets called and responds to accept/refuse individual --remote
line. Unfortunately, it doesn't know the total number of --remotes
. So, eduVPN client doesn't know it actually refused all the --remotes
and handle this situation gracefully with a more meaningful message.
As the "No usable connection profiles are present" string is hard-coded into OpenVPN, the simplest way would be to strcmp() the error returned from OpenVPN and convert it into a friendlier message.
This is no longer an issue with APIv3 I guess?
Ahh. :) Cool. I guess I should have gone straight into APIv3 implementation, rather than addressing issues on the tracker first.
But maybe this makes sense when considering OpenVPN internals... not sure.