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

keep TCP connections alive on vEthernet when resuming from sleep #6271

Closed
esumii opened this issue Nov 23, 2020 · 2 comments
Closed

keep TCP connections alive on vEthernet when resuming from sleep #6271

esumii opened this issue Nov 23, 2020 · 2 comments
Labels

Comments

@esumii
Copy link

esumii commented Nov 23, 2020

Is your feature request related to a problem? Please describe.
I have to restart all my X clients on WSL2 (while the X server is still running on Windows) when resuming my laptop from sleep.

Describe the solution you'd like
Keep TCP connections over vEthernet alive when sleeping/resuming

Describe alternatives you've considered
Connections on 127.0.0.1 from WSL1 are kept alive after sleeping/resuming (but I prefer WSL2 for its much faster file system); WSL2 can also make connections over 127.0.0.1 using socat but it's too slow for X clients.

Additional context
This issue seems different from #4992 since I do not have to restart the server (let alone rebooting WSL2 or Windows itself).

My current environments are:

  • Windows 10 version 20H2 (OS build 19042.630)
  • Debian version 10.5
  • "uname -a" gives: Linux LAPTOP-xxxxxxxx 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 GNU/Linux
  • My X server is ASTEC-X but I don't think the problem is specific to this product or even an X server.
@SamB
Copy link

SamB commented Mar 16, 2021

I think it's fairly clear that the commenters on #4992 who talk about having to reboot aren't experiencing the same problem as the OP, who only had connections originating from the WSL2 side drop: they didn't say anything about the server losing it's listening socket or anything, so presumably they, too, merely had to restart/reconnect any X clients.

(That's certainly been my experience.)

@esumii
Copy link
Author

esumii commented Mar 24, 2021

Thanks, the workaround using wsld worked for me too, so I'm closing this issue.

Duplicate of #4992

@esumii esumii closed this as completed Mar 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants