New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[vpn] Connecting fixes, fix VPNC connect reply and improve logging. Fixes JB#55105 #36
Conversation
5b6dded
to
b2402f4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems simple.
2b9ed38
to
f271df9
Compare
d076c06
to
9d2ae82
Compare
[vpnc] Log unhandled errors. JB#55105 Add logging of unhandled errors to help in error resolving.
[vpnc] Ensure that vpnc_connect_done() is called at shutdown. JB#55105 The vpnc_connect_done() is called only once, at success or at failure. Adding this call makes sure that it will be called when the server returns invalid response, configuration is incompatible with the server or vpnc cannot be run on the system (e.g., vpnc is ran as regular user that has no permission to create raw sockets). By doing so the D-Bus LimitsExceeded can be avoided as every pending request, even in case of failures, will get a response.
[provider] Reply with EALREADY if connecting a VPN in progress. JB#55105 It is clearer to report back to the caller that the VPN is being already set to connect to indicate the clear difference between "connection set to in progress" vs. "we are already connecting this".
[service] Handle provider EALREADY replies if connecting a VPN. JB#55105 The provider.c now returns EALREADY when trying to connect a VPN that is already being set to connect. In case of VPN autoconnection this should be dealt similarly to EINPROGRESS as it indicates we could have a VPN left to connect as the result of connection is not yet known. Also cleanup the service/provider connect reply code handling. By reacting to EALREADY the connect_timeout() is being set only once for a connection attempt.
9d2ae82
to
1c37ff5
Compare
[vpnc] Use natt as the default NAT Traversal Mode. JB#55105
For example, on the man-pages of Debian the following is stated on
--natt-mode option:
--natt-mode <natt/none/force-natt/cisco-udp>
Which NAT-Traversal Method to use:
• natt -- NAT-T as defined in RFC3947
• none -- disable use of any NAT-T method
• force-natt -- always use NAT-T encapsulation even without presence of a NAT device (useful if the OS captures all ESP traffic)
• cisco-udp -- Cisco proprietary UDP encapsulation, commonly over Port 10000
Note: cisco-tcp encapsulation is not yet supported
Default: natt
conf-variable: NAT Traversal Mode <natt/none/force-natt/cisco-udp>
Thus, the default here should be also "natt". This avoids creating
IPPROTO_ESP socket that is a raw socket and cannot be used as a regular
user.
89df2af
to
d27c8f9
Compare
|
Got quite a bit more stuff since my earlier approve. Not that familiar with the details and don't have vpnc to test with, but can't say there's anything wrong either so guess this is still approved from my side. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look sensible, just one point that I wasn't sure about.
I'm also not able to test this unfortunately. Are there any publicly accessible VPNC servers I could try with? Otherwise, it looks sensible enough, I would be comfortable to approve it anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't able to test the changes I'm afraid, but the code looks good to me (and builds fine, apart from the unrelated failing unit test raised elsewhere).
Add logging of unhandled errors with VPNC to help in error resolving.
Fix the replying to the connect request when VPNC connection abruptly fails
because of server/client misconfiguration. This avoids the D-Bus LimitsExceeded
error when VPNC keeps trying and failing by always replying to the connection
request.
Use natt as default NAT Traversal mode. This is the default according to man
pages.
Use EALREADY in provider.c connect reply for VPNs that were already connecting.
This helps in differentiate between the two cases: VPN was just connected or
has been trying to connect and waiting for vpnd reply. Also connect_timeout()
is set only once per connection attempt.