dumb_socketpair(): fallback from AF_UNIX to AF_INET if AF_UNIX fails
1) If bind() fails with an AF_UNIX socket, we should retry with
AF_INET socket
Because we have to used named paths for AF_UNIX sockets on Windows, a
likely point of failure is that the temporary directory in
nonexistent/non-writable, or even that we somehow have a collision in the
filename.
2) If any of the other AF_UNIX operations (listen, socket, connect, accept)
fail, we might as well also retry with AF_INET.
We don't know of any expected points-of-failure, but all indications are
that AF_UNIX support in Windows is incomplete, undocumented, and
potentially buggy.
Signed-off-by: Daniel Lenski <email address hidden>
dumb_socketpair(): generate named socket path more carefully
Windows forces us to use named-path Unix sockets. Generating a path in the
temporary directory, combining current high-res time and PID, seems like a
less-bad option.
- Only adds 16 bits of time-based random bits,
- Will currently fail if there aren't 14 characters available for the filename,
- Might conceivably generate paths longer than UNIX_PATH_MAX, and
- Offers no other apparent offsetting advantages
Signed-off-by: Daniel Lenski <email address hidden>
Unfortunately, and maddeningly, it's possible for the local IPv4 routes
(127.0.0.0/8) to be deleted on Windows; this will prevent dumb_socketpair()
from working in its current form.
Nevertheless, it works well enough that we can use it in OpenConnect. The
modified version of dumb_socketpair() in this patch tries to create an AF_UNIX
socketpair, and only uses IPv4 local sockets as a fallback. With this modified
version, I confirm that I can do the following on Windows 10:
1) Nuke routes with `route /f`.
2) Reconnect network adapter via GUI.
3) Confirm that IPv4 local route (127.0.0.0/8) still hasn't been recreated.
4) Run OpenConnect and successfully create the cmd pipe.
Update usage of Wintun, avoid disconnections on Windows
Closes #338
See merge request openconnect/openconnect!306
9033a84...
by
Dimitri Papadopoulos <email address hidden>
Windows: fix instability with Wintun as tunnel device driver
In https://gitlab.com/openconnect/openconnect/-/issues/338, multiple users
reported that connections using Wintun as the tunnel device driver become
non-functional after 20-30 minutes of operation, without
any message from OpenConnect at all.
We analyzed this issue as follows:
1. There was an off-by-one error in the check of outgoing packet size
against the tunnel device's MTU (`tun_len < pkt->len`). Outgoing packets
of exactly the MTU size would be considered errors and silently discarded
by OpenConnect.
2. However, OpenConnect failed to instruct the driver to release these
discarded packets. They would accumulate in the Wintun driver buffer and
probably cause an out-of-memory condition, eventually freezing the
driver.
We fixed the issued as follows:
1. Fix the off-by-one error, changing to `tun_len <= pkt->len`.
2. Always release outgoing packets, even if discarded.
3. Print extended debugging messages when receiving/sending packets. Such
messages would have helped us diagnose the error much sooner.
