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

Simpler and more reliable implementation for Windows 10+? #7

Open
dlenski opened this issue Dec 30, 2021 · 1 comment
Open

Simpler and more reliable implementation for Windows 10+? #7

dlenski opened this issue Dec 30, 2021 · 1 comment

Comments

@dlenski
Copy link

dlenski commented Dec 30, 2021

There are some cases where it's apparently possible to delete the loopback route (127.0.0.0/8) on Windows. This prevents the IPv4-based dumb_socketpair from working, and it appears to be very difficult to recreate the required loopback route. Yay, Windows 🤷‍♂️.

This breaks OpenConnect for users who run route /f to nuke their routing table (presumably out of sheer desperation… yay, Windows again) and then reconnect to a network.

It seems that there is a way to make dumb_socketpair sidestep IPv4 brokenness altogether, since AF_UNIX+SOCK_STREAM are available on Windows 10+.

Implementing dumb_socketpair with AF_UNIX sockets would be simpler and more reliable. The function could try using AF_UNIX sockets first, and only fallback to the IPv4-based approach if that fails.

@DimitriPapadopoulos
Copy link

@dlenski I suggest you push a merge request into selectable-socketpair/selectable-socketpair in the short term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants