Skip to content
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

Merged
merged 5 commits into from Jan 20, 2023

Conversation

LaakkonenJussi
Copy link
Contributor

@LaakkonenJussi LaakkonenJussi commented Dec 19, 2022

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.

@LaakkonenJussi LaakkonenJussi changed the title Log unhandled VPNC errors as warnings Log unhandled VPNC errors Dec 19, 2022
Copy link
Contributor

@pvuorela pvuorela left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems simple.

@LaakkonenJussi LaakkonenJussi changed the title Log unhandled VPNC errors Improve VPNC logging and fix connect replying, use EALREADY as provider result Jan 4, 2023
[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.
[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.
@pvuorela
Copy link
Contributor

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.

Copy link
Member

@llewelld llewelld left a 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.

connman/src/service.c Show resolved Hide resolved
Copy link
Member

@llewelld llewelld left a 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).

@LaakkonenJussi LaakkonenJussi changed the title Improve VPNC logging and fix connect replying, use EALREADY as provider result [connman] VPN connecting fixes, fix VPNC connect reply and logging. Fixes JB#55105 Jan 19, 2023
@LaakkonenJussi LaakkonenJussi changed the title [connman] VPN connecting fixes, fix VPNC connect reply and logging. Fixes JB#55105 [vpn] Connecting fixes, fix VPNC connect reply and improve logging. Fixes JB#55105 Jan 19, 2023
@LaakkonenJussi LaakkonenJussi merged commit f96c490 into sailfishos:master Jan 20, 2023
@LaakkonenJussi LaakkonenJussi deleted the jb55105 branch January 20, 2023 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants