WSL2 camera discovery fails: mDNS multicast needs mirrored networking

A camera SDK that lists devices on Windows returns an empty list inside WSL2, yet ping by IP still works. The pattern has one dominant cause: unicast traffic crosses the WSL2 NAT boundary, link-local multicast does not. Your discovery command sends an mDNS query to 224.0.0.251 on UDP port 5353, the packet dies on the virtual switch, and the camera never hears it. Run the four-step capture test below to confirm your case. Then pick a fix that works on Windows 10 — connect by IP, discover on the Windows side, or pin the camera's address — or move to mirrored networking once the host runs Windows 11 22H2 or newer.

The symptom and the five-minute capture test

Three observations together identify the NAT multicast limitation. The device-list command returns nothing inside WSL2. The same command run on Windows finds the camera immediately. And a plain ping to the camera's IP from WSL2 gets replies. Add a packet capture and the picture completes itself: traffic from the WSL address never reaches the physical adapter.

Run the test in this order:

1. Run discovery on Windows with a capture on the physical Ethernet adapter. You should see UDP packets to 224.0.0.251 on port 5353, asking for service types of the form name._tcp.local.
2. Run the same discovery inside WSL2 with the capture still running. In this failure mode, no packet from the WSL address appears: the query never leaves the virtual switch.
3. Ping the camera by IP from WSL2. Replies prove the unicast path through the NAT is healthy, so routing and the camera itself are fine.
4. Trace the discovery process inside WSL2 with strace, or capture on eth0 with tcpdump. You will see it send to 224.0.0.251 on port 5353 — the tool is doing its job; the network is not carrying the packet.

If all four hold, stop editing firewalls. The packets are not blocked anywhere — they are never sent. Go straight to the fixes.

Why NAT mode swallows link-local multicast

Ethernet cameras announce themselves in two ways, and both are link-local traffic. mDNS discovery sends UDP queries to 224.0.0.251 on port 5353 — the address and port that RFC 6762 reserves for multicast DNS — and builds its list from the devices that answer with a service record. GigE Vision cameras instead answer a discovery broadcast on UDP port 3956; the subnet broadcast walkthrough shows what those packets look like on the wire. One is multicast, the other broadcast, and neither is meant to leave its local link.

WSL2 NAT mode puts the distribution on an internal virtual switch with an address in the 172.16.0.0/12 range — 172.21.x.x in the case this page works from. The Windows host translates unicast flows and forwards them through the physical NIC, which is why ping, SSH and streaming by IP all behave. Multicast and broadcast are not translated flows; NAT mode does not replicate them onto the adapter. Microsoft documents multicast support as a mirrored-mode feature, and mirrored mode exists from Windows 11 22H2 onward — Windows 10, build 19045 included, has no mirrored mode to switch on. Discovery of this kind is what Bonjour and Avahi implement on ordinary hosts; this mDNS and Bonjour discovery walkthrough follows the same query-and-answer flow your SDK uses.

Every camera that announces over the network inherits the limitation — GigE area scan cameras and the network-attached 3D sensors alike. USB cameras are the exception: they enumerate on the bus, so none of this applies until you bridge one into the VM.

Likely causes in order of probability

Start at rank 1; it explains nearly every case where ping works and Windows discovery works. The lower ranks cover the residue.

Worked example: Windows 10 22H2, build 19045, WSL 2.7.3.0, camera at 192.168.137.15

The inputs, with where each comes from: a bench PC fixed on Windows 10 22H2, build 19045; WSL 2.7.3.0 running Ubuntu 22.04 in default NAT mode; a wired camera link where the host holds static 192.168.137.50 on a /24 and the camera answers at 192.168.137.15 (address example — any camera the Windows tool finds shares that subnet); a WSL eth0 address of 172.21.46.200 (read yours with ip addr show eth0; the reported range is 172.21.x.x); and a strace of the discovery run showing queries to 224.0.0.251 on UDP 5353.

The rule: NAT translates unicast flows only. Addresses in 224.0.0.0/24 form the link-local control block, which is defined not to leave the local link, and NAT mode replicates nothing onto the physical adapter on its own. Mirrored networking, the mode that carries multicast, needs Windows 11 22H2 — build 22621 or newer.

Reading the arithmetic: the camera address ANDed with its mask lands on the host's own subnet, which is why the Windows tool lists the camera. The WSL address lands on 172.21.32.0 under its /20 NAT prefix — a different network, and with any prefix from /12 to /24 the camera's /24 stays outside, so the verdict does not hinge on the exact mask. Unicast to 192.168.137.15 crosses the NAT as one translated flow, which is why ping answers. The discovery query targets 224.0.0.251, scoped to the link, so it stops at the virtual switch.

Result: the physical-adapter capture shows the Windows-originated mDNS packets but nothing from 172.21.46.200, and the device list inside WSL2 stays empty.

Decision: connect by IP, because the unicast path is already proven, and leave firewall rules alone while the capture shows no query leaving the VM. Revisit mirrored mode only when the host itself reaches build 22621 or newer.

The fixes that work on Windows 10

None of these restores live discovery inside WSL2 — all three get the camera session running, which is the actual goal.

1. Connect by IP from WSL2. Ping proved the path, so the SDK's open-by-address call reaches the camera through the NAT. Expect the discovery list to stay empty: that is the NAT behaving as designed, not a new fault. Read the address from a per-station config file and pass it to the open call, so a swapped camera is a one-line change.
2. Run discovery on Windows, connect from WSL2. Keep the vendor's device-list tool on the Windows side and let it print addresses; hand each address to the WSL2 pipeline through a file, an environment variable or a command-line argument. In CI this split is clean — Windows owns enumeration, Linux owns processing.
3. Pin the camera's address. Make the address stationary so the connect-by-IP call keeps working across power cycles: a persistent IP written with the vendor's configuration tool, or a DHCP reservation tied to the camera's MAC address. Record the result per station. The camera IP assignment guide explains both mechanisms in detail.

Skip these so you do not burn an afternoon on them: port exceptions for the SDK inside WSL2 or on Windows; repeated WSL restarts and network resets; moving the camera to Wi-Fi, where multicast meets rate limits and client isolation of its own.

If the host can move to Windows 11 22H2 or newer

Mirrored networking closes the gap. Put [wsl2] with networkingMode=mirrored into .wslconfig, restart WSL, and the distribution shares the host's interfaces: multicast reaches the LAN, mDNS queries appear on the physical adapter, and the device list populates as it does on Windows. GigE Vision broadcast discovery works through mirrored mode the same way.

Budget one test pass before you standardize on it. Mirrored mode changes localhost binding and interacts with VPN clients differently from NAT, and setups that publish container ports are the ones reporting startup delays until they are reworked.

When this diagnosis is wrong

The capture test separates this limitation from its look-alikes. Watch for four.

• The query reaches the adapter but the list stays empty. Multicast is flowing, so WSL is innocent: the camera firmware does not register the service name the SDK asks for, or it answers on one interface only. Repeat the capture on Windows with the same SDK build; if Windows sees the same silence, update firmware or SDK. Devices publish their service records in a structured form — mDNS and schema discovery for embedded devices explains what a client expects to receive.
• Ping fails too. Routing, not multicast: the camera sits on a different subnet, hangs off an adapter the VM does not see, or its address moved. Fix the route first and discovery follows.
• You are on Wi-Fi. Access points with client isolation block multicast between wireless clients even with no WSL in the path. Run the same discovery from Windows on the same Wi-Fi before blaming the VM.
• The SDK runs in Docker inside WSL2. You now have two NAT boundaries, and multicast dies at the first. The Ethernet 3D camera in Docker guide walks discovery and streaming checks for exactly that nesting.

Set-up choices that prevent the empty list

Five habits keep this off the problem queue:

• Decide the discovery policy once: Windows enumerates, WSL2 processes. Future stations never ask the multicast question.
• Pin addresses with a persistent IP or a DHCP reservation, and record them per station, so connect-by-IP survives reboots and re-cabling.
• Keep the capture in the runbook: a saved Wireshark view filtered to UDP 5353 and UDP 3956 confirms the forwarding gap in one run.
• Version-match the SDK in WSL2 and on Windows, camera firmware included, because mismatched service names imitate this exact symptom.
• Re-test mirrored mode at every host OS refresh; the moment a bench reaches Windows 11 22H2, native discovery returns.

Where to go next

If you are specifying cameras for a Windows-plus-WSL2 bench, decide the interface before the software: GigE for 2D pipelines, network-connected 3D for depth and profiling. The camera finder filters by interface, resolution and sensor format. The 3D sensor range follows. More host-side fixes sit on the systems topic page; for a configured station or a second opinion on your network layout, contact the team and we will check the discovery plan with you.