Question on UDP multicast in mirrored mode and Wireshark

[kistlin]

When trying the new mirrored mode, I tried to receive UDP multicast.
This all works, except when I open Wireshark.
Wireshark on Windows is showing all the UDP packets that should come in every second.
Wireshark in WSL doesn't show any packets.
Only when I run for example a Python script to receive multicast, the packages also show up in Wireshark.
Is that expected behavior?

WSL version: 2.0.7.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
Windows version: 10.0.22631.2506

[realumhelp]

I have been playing around with multicast in WSL for the last few hours and its not really convincing me that IGMP is working properly from inside of WSL at least in mirrored mode (i'll try NAT mode sometime soon). Using a similar config with networkingMode = mirrored and I do a multicast join to group 239.0.0.1 inside of WSL I do not see an IGMP join packet leave the actual machine even with a passive Ethernet tap on the physical NIC /w Wireshark and I also do not see any igmp joins in Cisco for that interface either (sho ip igmp groups).

If everything is in the same subnet multicast behavior will depend on how your switch handles multicast traffic. Basically, does it support IGMP Snooping and/or does it treat multicast like broadcast. In a L2 environment multicast might work or it might not. So lets get funky and move to an L3 routed multicast environment with PIM.

With two VLANs 10 and 11 for instance also assume that PIM is correctly setup. If you start a multicast sender in VLAN 10 (/w ttl > 1 and verify there is now a Cisco mroute show ip mroute) and then do a multicast join from inside of a WSL instance in VLAN 11. I do not see the traffic flow and no IGMP Groups/no mroutes on the switch but I do see that the WSL instance "thinks" that it is joined (Linux ip maddr shows the group as joined). If you look at the host Windows system it is also not joined to the group (netsh interface ip show joins). Obviously, the switch in my case Cisco does not see the join either (sho ip igmp groups or sho ip mroute). This kind of implies that IGMP traffic from inside of WSL is not being forwarded.

If I do a join from the host Windows system an IGMP join is sent and the Cisco will do its PIM/mroute magic, the data will start routing and Windows will see the traffic inside of Wireshark. If I look at Wireshark inside of WSL at this point I still do not see the traffic, it could be the Linux network stack is filtering the multicast traffic because it is not joined to the group (a guess). If I now do a join inside of WSL the data will being to show. Linux is getting the data because of the host Windows IGMP join because the Linux join doesn't really go anywhere. If the host Windows machine leaves the group while the WSL Linux machine is still joined WSL will stop receiving the traffic.

So all of this kind of leads me to believe that the IGMP joins inside of WSL are getting eaten and not really being transmitted anywhere.

Hope this helps!

[shixudong2020]

1 for userspace udp bind(include multicast),u need first bind udp socket,then tcpdump,is's expected behavior
2 wsl's Official kernel CONFIG_IP_MULTICAST is not set,so not see any multicast join to group
3 because 2, and most switch enable IGMP snooping, so WSL can not receive multicast udp

[masonlilly-ms]

I've encountered something similar with ROS 2. Whenever ROS 2 nodes on a remote machine send multicast traffic (which is the default when there are multiple subscribers), subscribers running in WSL simply never receive the data.

I wrote a barebones script to send and receive multicast packets (works on either Windows or Linux) (remove the .txt from the extension, for some reason Github won't accept a .py file) and tested it as both sender and receiver in all combinations of WSL, the host Windows OS, and a remote machine on the network. I watched the resulting network traffic using tshark (terminal Wireshark).

The specific commands I ran with the script are:
Sender:

python3 multicast.py --interface_ip <your IP address> send

Receiveer:

python3 multicast.py --interface_ip <your IP address> receive

To capture only the relevant packets in tshark, I invoked it with the following command, with a filter applied:

tshark -i <name of your network interface, e.g. eth0> -f "igmp or dst port 7400"

Note: 7400 is the default port used in the script, and in ROS 2.

Here are the scenarios I found that do and don't work:

From \ To	Windows	Remote	WSL
Windows	Yes	Yes	Rarely
Remote	Yes	Yes	Rarely
WSL	No?	Yes	Yes

Usually*, WSL processes won't receive packets send from the surrounding Windows OS or from a remote machine, but it always receives packets send from within WSL. I don't recall ever getting a listener in Windows to receive a packet sent from within WSL.

I believe there are at least two things going on here. First, I agree with @realumhelp that IGMP packets are not sent when processes try to join a multicast group in WSL. I confirmed this using tshark within WSL and on Windows, with both ROS 2 nodes and my test script. I also confirmed that these packets (and the symmetrical "leave" packets when the process shuts down) are sent when the same processes run directly on Windows and on a native Linux machine. In the ROS case, when testing behind an IGMP-snooping router, multicast packets were never delivered at all to the Windows device when the listener was in WSL, but they began to flow immediately when I contrived to have the computer join the multicast group by other means, by running another process to listen on the port directly on Windows. So that's definitely part of the issue, and explains at least the Remote-to-WSL square in the table.

For some reason, when both the sender and receiver are in WSL, the packets are delivered successfully, even though tshark within WSL never sees IGMP packets. I suspect WSL is doing some magic internally that causes this to work.

I also find that when I test behind a non-IGMP-snooping router (where therefore packets are delivered to all hosts unconditionally), the multicast packets sent from Windows or a remote host are visible to tshark running in Windows but not WSL. This is consistent with the typical* behavior where listeners in WSL never receive those packets. *I say "typically" because I've seen some scenarios where these directions do work, through no clear intervention on my part, including at least one case where ROS began working spontaneously after being left to run a long time. So I think there's something happening here I'm still missing.

One final thing is the WSL-to-Windows case. Here, the Windows listener does send IGMP packets to the router, but it doesn't seem like it should matter because the sender is transmitting on the same NIC. In this case, tshark both on Windows and in WSL sees the outgoing packet, but the listening process never acknowledges it. Because transmitting outbound from WSL to a remote listener works perfectly well, I suspect this may be some separate third issue.

[borjamunozf]

Paying 1 bitcoin to anyone that gives us an example where Multicast is actually working under mirrored Mode.
(No, but I would appreciate if any WSL or Microsoft dev could at least say something regarding this)

The documentation says that Multicast works with mirrored mode, but I have not found any example and bunch of issues reported with multicast Windows <> WSL, examples that work for NAT and Bridged mode.

This has huge impact in the company I'm working on:

• NAT mode has a huge performance issue (Topic packets from Windows to WSL interface dissappearing (ROS2 app) #11966 )
• Bridged mode fixes the strange performace problem but it triggers issues when working in the office that makes it not valid, so not a consistent solution.
• Mirrored was our hope, but after a lot of time invested we have not been able to made any simple case work at all.

[doug-melville-scg]

This issue is pushing us to move to Linux workstations to enable our R&D with NVIDIA's Omniverse IsaacSim. We have ROS2 on WSL2 and Omniverse on the Windows 11 host and although communication is possible both latency and packet loss are unacceptable for our application.

[kistlin]

And you better figure this out as https://github.com/microsoft/WSL/releases/tag/2.4.5 mentions.

Add user warning letting users know bridged networking will be deprecated

Bridged mode is the only network mode that let's me work without a problem.

[shixudong2020]

1.Windows host-> WSL distro
Run a multicast receiver simultaneously on the Windows host. Then, when the Windows host sends a multicast packet, it also sends a copy to the loopback device, and mirrors the multicast packet to the receiving direction of the WSL2's mirrored NIC. In this way, WSL2 can receive the multicast packet from the Windows host smoothly.
2.WSL distro->Windows host
hostAddressLoopback=true,and WSL executes "sudo ip route add 224.1.1.1 via 169.254.73.152 dev eth0 onlink", Here eth0 denotes the NIC on which the default route is located.Then Windows host can successfully receive multicast packets from WSL2 (mirrored)
for detail,please see WSL2 and multicast(https://blog.csdn.net/sxd2001/article/details/144649381)

[kistlin]

@shixudong2020
1.Windows host-> WSL distro Run a multicast receiver simultaneously on the Windows host.
This is exactly what I don't want and is not expected, when using WSL/Linux with an application wanting to receive multicast.
There should be no need to maintain another application on Windows just to receive multicast.
Or it might be an application of which internals are not even known and then one has to reverse engineer to figure out all multicast addresses?
Not really user friendly.
At least for my daily workflow, bridged mode is still the least painful. If it just would handle multiple interfaces smoother.

[kistlin]

For me this works now without running anything on Windows. I also changed the VM firewall according to https://learn.microsoft.com/en-us/windows/wsl/networking#mirrored-mode-networking. I'm not sure though if absolutely necessary.