[WSL 2] NIC Bridge mode SOCK_RAW

[mario19911]

Hello everybody,

we just started working with the new WSL2 feature and figured out that the network interfaces are not mapped into WSL as it was the case in WSL1.

I know that this would work with "netsh interface portproxy add..." in some cases which is the workaround for this case and it also works pretty fine.

But what happens with RAW sockets? Normally I would do a bind to the physical interface I want to listen on, but I don't think this is possible any more in WSL2 since I don't have access to the physical interfaces, right?

Will there be a feature to access the interfaces from windows directly? Not for settings IP-Addresses and so on (which might be agains the architecture of WSL2) - but for binding without workaround, RAW sockets and so on...

[therealkenc]

Most unfortunately #4150 was annotated with a workaround available banner, which only applies to ipv4/ipv6. UDP #4825 is spiritually similar. Ditto ICMP, ARP.

Normally I would do a bind to the physical interface I want to listen on

You can bind virtual eth0, same as you would in (say) a Linux guest in QEMU or Hyper-V.

Will there be a feature to access the [Windows] interfaces from windows directly?

At the Data Link Layer, let's call it... probably not. The ask is qualitatively different than #4825, and roughly equivalent to: "Can I bind the Linux host's MAC in a Linux QEMU guest"? Answer, no. [With caveat it's technically possible to do a lot of things in extremis.]

Once #4619 ships someone is going to open an issue observing that nmap on localhost doesn't work as expected (for some definition of expected), conflating localhost with lo, but I digress.

[mario19911]

Sure, binding to the virtual eth0 will work, but will I be able to receive e.g. multicasts that are sent in a LAN?
If this works, I still have the problem that I will receive it from ALL physical interfaces, not just the one I want to listen on...so there is no such workaround with a "proxy" at this layer?

I think it would be a very nice feature to have the possibility of RAW sockets to support more applications (e.g. the GOOSE protocol of IEC61850) :)

[therealkenc]

Sure, binding to the virtual eth0 will work, but will I be able to receive e.g. multicasts that are sent in a LAN?

Ethernet broadcast on MAC ff:ff:ff:ff:ff:ff could be feasible under umbrella #4150 assuming the WSL vEthernet MAC lived on the same VLAN. Which is different question (quoth) "Will there be a feature to access the interfaces [on] windows directly?" (with still short answer "no"). Your vEthernet interface on the VM side is not "on windows". That interface on the Linux side has a different MAC. That MAC could be on the same VLAN though. [Hypothetically. Making a lot of generous assumptions about how #4150 plays out (if at all).]

If this works, I still have the problem that I will receive it from ALL physical interfaces

Lost me at "it" and "ALL" on that one. The VM side could (in the hypothetical) have one or more bridged interfaces. What link layer frames are received on the VM side would depend on which Windows interfaces are bridged. You are still binding to eth0 (eth1, eth2). Short answer "the problem" is "depends on your network topology".

I think it would be a very nice feature to have the possibility of RAW sockets to support more applications (e.g. the GOOSE protocol of IEC61850) :)

I don't have a substation handy at the moment to test that. DHCP maybe.

Constructive suggestion would be to try your use case with Hyper-V and a virtual switch. If your scenario works in Hyper-V, then the scenario is at least in principle possible to provide in WSL. [Being careful not to conflate the possible with the probable.] Bonne chance.

[mario19911]

Ok so the direct access is not possible, but as you mentioned it could be possible with a network bridge mentioned in #4150 .

Will there be a feature with network bridges in the public release? :)

[lapo-luchini]

I managed to have both IPv4 (static address) and IPv6 working in WSL2, like this:

1. open a WSL2 shell, and immediately close it (this creates the "WSL" virtual switch in Hyper-V)
2. selected "Connection type: external network" (bridging) in Hyper-V Virtual Switch Manager in the virtual switch called "WSL"
3. wsl --shutdown in order to have it re-load on next shell
4. add static IP address inside WSL2:
   sudo ip addr add 192.168.1.8/24 dev eth0
5. define static route inside WSL2:
   sudo route add default gw 192.168.1.1
sudo route del default gw 172.23.160.1

PS: 192.168.1.8/24 is relative to my own network, so will vary depending on yours.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!