[WSL 2] NIC Bridge mode SOCK_DGRAM

[graziamk]

Description:
I need to run an Open Sound Control (OSC) application in WSL2 and have it communicate with other computers/servers on my network. It seems impossible to do this currently.

• Windows build number: Microsoft Windows [Version 10.0.19041.21]

• What you're doing and what's happening: Cant send/receive UDP packet between Windows and WSL2 (Ubuntu) Instance.

Using:

• Ubuntu for WSL2: https://www.microsoft.com/store/productId/9NBLGGH4MSV6
• Wireshark: https://1.na.dl.wireshark.org/win64/Wireshark-win64-3.2.1.exe

Steps required to reproduce:
(0) Configured Firewall rule to allow inbound/outbound UDP packets on port 19540 (not sure if necessary; I did this via GUI, should I include print-screen?)
(1) Started the WSL2/Ubuntu by Clicking on the Ubuntu icon in Start Menu. This opens the Ubuntu Console.
(2) In [Windows Console]: Got the adapters and IP addresses (see attached file)
ipconfig_output.txt

(3) [In Ubuntu Console]: Started a UDP listener on port 19540 with this command:
$ nc -lu -p 19540
(4) Started Wireshark capturing on “Ethernet adapter vEthernet (WSL)” with filter “udp port 19540”
(5) Started my Application and sent the string “/menu/node” via OSC (i.e. a UDP packet to port 19540 containing the string “/menu/node”).
(6) [nc] in WSL2 console shows string “/menu/node”
(7) No response in [WireShark]: nothing captured.

• What's wrong / what should be happening instead:
  I believe that it is currently impossible to detect the UDP message generated in WSL2 from the Windows host. If so, that needs to be changed so that there is a way for WireShark (or some other application/utility/functionality within Windows 10) to detect and receive, or capture, a UDP message generated in WSL2.

One possibility for Wireshark to capture the UDP message on one of the interfaces listed in IPCONFIG (maybe show the exact IP of the WSL2 machine?). It should, at least, be possible to write a C program in windows that captures this UDP packet and forwards it to the ‘main’ NIC.
 
There is a related issue reported here (#4150), with a need that is similar to mine, except that it uses TCP communication. This issue has a workaround via adding port-forwarding rules "netsh interface portproxy add ...". However, if I am not mistaken, it is not possible to port-forward UDP packets using native windows features/functionality.

[WPMGPRoSToTeMa]

As a workaround I'm using a tool suggested in the answer on serverfault. The direct link to the tool: http://aluigi.altervista.org/mytoolz/sudppipe.zip.

It can be used as follows:
sudppipe -b <source_ip> <destination_ip> <destination_port> <source_port>
You can find the destination_ip using the ifconfig command in your WSL, see eth0 interface.

Usage example:
sudppipe -x -b 0.0.0.0 172.22.149.212 27015 27016

The only problem is that your UDP packets will have source address and source port different from the original ones.

[adrusi]

Can we get a clarification as to what the root cause is? As it stands it is hard for me, and I imagine others, to understand how to apply the recommended workaround to my usecase.

At which point are packets being dropped? Are they dropped by the linux -> windows network bridge before they can be sent to the network? Or do they get sent to the network but responses reaching windows fail to be routed to linux (based on graziamk's description of their issue, I think this at least can't be the only issue)?

Based on the issues referencing this one, it looks like the issue only affects UDP networking. Is UDP networking not supported on WSL2?

[peigongdsd]

Hey here.
Have you captured on other interfaces?
Have a view on my issue, and you can try to capture on your default route (route for internet).
Maybe you'll see that packets are also wrongly routed to the wrong adapter, like me.

[stampycode]

Any updates? It's been a while.

[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!