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

Feature req: Separate network subsystem per-distribution #10154

Open
the-moog opened this issue May 31, 2023 · 2 comments
Open

Feature req: Separate network subsystem per-distribution #10154

the-moog opened this issue May 31, 2023 · 2 comments
Labels

Comments

@the-moog
Copy link

Lots of mentions of this, and related (i.e. being able to fix the address) but I could not find an actual feature req.

Is your feature request related to a problem? Please describe.
Currently all the WSL distribution images share the same networking subsystem as they share a single VM.
I am guessing with some sort of HyperVisor on the VM as otherwise they'd have to run the same Kernel? (Comment if you know more) but the upshot is that though there is more than one Kernel they share the same network 'hardware' (virtualised).

Example: Issue with port sharing:

  • Network s/w can be unreliable: If you try and run the same service on two running distributions (e.g. for regression testing) with a fixed TCP/UDP then only one will work.

The current implementation means changing the network configuration on one distribution immediately changes the network configuration on all distributions.
That includes

  • Adding interfaces
  • Setting network protocol/address
  • Altering routing table
  • Expect Kernel PF too? (not tested that yet)

Describe the solution you'd like
As a minimum, In the same way that we can --mount when we start WSL, Could there be a --bind where the latter is defined in Hyper-V Manager or in the Network Adapter configuration dialog in Windows.

That way multiple running WSL have the choice of sharing a network configuration, as now, or at least being on a different NAT network even if they have the same address. Port forwarding in Windows would allow indiration.

A more complete solution would be a more conventional virtual ethernet adapter device. So it would just honor the more flexible and traditional /etc/network/interfaces. That woud add the benefit of being able to have more than one interface, e.g. for bonding or briding.

Describe alternatives you've considered
RealVM: VMWare, VirtualBox, Qubes, Xen, QEmu, HyperV?
Buy another PC, use Xen and configure Windows in a VM?

@NotTheDr01ds
Copy link

I meant to comment on this a while back when you posted it, but it got buried under a mountain of other tabs.

It's been a while since I went through the exercise, but I was able to assign different addresses to different WSL2 distributions by creating additional network namespaces as mentioned in this Super User answer.

Caveat: I may not have the bandwidth to replicate this if you need assistance, and I'm not sure if it will work for your use-case.

I am guessing with some sort of HyperVisor on the VM as otherwise they'd have to run the same Kernel? (Comment if you know more)

They actually do share the same kernel. A uname -a on any of your WSL2 distributions will always show the same kernel info.

@the-moog
Copy link
Author

Hi Thanks for the suggestion. I apologise being rather late in replying I rarely get round to catching up on GitHub messages - work/life pressures etc.

Thanks for the link. That suggestion looks very promising. I know of Linux Namespaces but I've never used them.
I understand that often the only reason to mess with that feature is you want superuser like access on a system you are not a superuser. And (for me at least) if that is the situation then I probably don't have the permissions needed to turn it on in the first place (and RHL it's off by default). But in WSL this is a differnt story....

I will not close this issues for the moment. It could be that a couple carefully crafted systemd units could make this a stock feature. The current behaviour can be odd even on the same WSL instance. e.g. Sometimes GUI apps spawned from different tabs in Windows Terminal will work and other times they say they can't connect to the server. This may solve that too.

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

2 participants