WSL2 GigE camera discovery: why ping works and the list is empty

You ping the camera from WSL2 and the reply comes back instantly. Open the vendor's device-list tool or start the ROS node, and the camera list is empty. That exact combination — ping passes, enumeration finds nothing — is the signature of WSL2's default networking, not of a broken camera or cable. Here are the two checks that confirm it in five minutes, the numbers that explain why it happens, the documented setting that fixes it, and where to move the acquisition when that setting is not available. It applies to any GigE Vision camera and any GenTL-based tool, because the blocker sits below all of them: the discovery broadcast never crosses the Windows-to-WSL2 virtual switch.

Why ping works and discovery fails

Every GigE Vision camera is found the same way, and ping has nothing to do with it. The transport layer — the GenTL producer your SDK or ROS driver loads — sends a discovery command as a UDP broadcast on port 3956, to the subnet broadcast address or to 255.255.255.255. Every camera that hears it answers with a unicast reply carrying its IP, MAC address and model. Ping is unicast: WSL2's NAT forwards any flow your side starts, the camera answers, the reply returns. Discovery is broadcast, and the NAT'd virtual switch forwards broadcasts in neither direction. Your request dies inside Windows; the camera never sees it; nothing comes back.

That puts WSL2 in a different failure family from its nearest neighbours. GenICam discovery uses subnet broadcast explains why a camera addressed outside your subnet also stays invisible, and a Windows firewall can drop the incoming broadcast while ping passes. WSL2 is harder than both: no firewall rule can fix it, because the packet is dropped at the virtual switch, not filtered by a rule. A missing transport layer fails the same symptom from the other end — broadcasts leave fine, but no code listens for the replies. The fixes differ, so confirm which one you have.

Any GigE camera behaves identically here; the failure is in the network path, not the sensor. Two current models from the area scan cameras range fail exactly the same way: the MV-CS200-10GC (20 MP, 1" sensor, C-mount) and the LS-CMR-0053 (12 MP, 1/1.7" sensor, 9 fps), both GigE:

Different sensors, different resolutions, one identical failure mode in WSL2.

Two checks that confirm the NAT is the blocker

Both take a minute and settle the question.

Read the WSL2 address. Run ip addr in the WSL2 terminal and look at eth0. In the default NAT mode the address comes from the private 172.16.0.0/12 block — 172.20.32.138/20 is a typical shape — which is not your plant LAN. In mirrored mode, eth0 carries the same address the Windows host holds on the LAN. A 172.x address plus a camera that pings is the NAT signature.

Capture on both sides. Run sudo tcpdump -i eth0 udp port 3956 inside WSL2 while your tool scans: you will see discovery packets leaving. Run a capture on the Windows physical adapter (Wireshark works) at the same time: nothing arrives there. A packet that leaves WSL2 but never appears on the physical NIC is dropped at the virtual switch — confirmed. If instead the replies arrive in WSL2 and the tools still show nothing, work through the Linux discovery checks, because the network is fine and the problem sits in the software stack.

NAT mode versus mirrored mode at a glance

The whole article is the difference between those two columns.

Worked example: camera at 192.168.1.50, WSL2 adapter at 172.20.32.138/20

Inputs. The camera holds a static address of 192.168.1.50 with a 255.255.255.0 mask — the plant-subnet address you assigned (illustrative values in the common set-up; substitute your own). The WSL2 adapter shows 172.20.32.138/20, read from ip addr in default NAT mode. Discovery targets UDP port 3956, broadcast.

Rule. An IP broadcast packet is delivered only to addresses inside the sender's own subnet, and a NAT forwards only unicast flows that the WSL2 side initiated.

Arithmetic.

The two ranges do not overlap. The discovery broadcast to 172.20.47.255 — and the one to 255.255.255.255 — has no path to 192.168.1.50, and the virtual switch does not relay broadcasts to the LAN side either.

Result. Zero replies on UDP port 3956 and an empty camera list, while the unicast ping from 172.20.32.138 to 192.168.1.50 passes, because NAT forwards exactly that kind of flow.

Decision. While WSL2 holds an address outside the camera's subnet in NAT mode, no camera setting can help: re-address the camera, and the broadcast still cannot reach it. Change the networking mode or move the stack — nothing else touches this failure.

The fix: mirrored networking mode

Mirrored mode removes the NAT. WSL2 stops building its own private network and shares the Windows host's interfaces and address, so broadcasts behave as they do on any machine plugged into the same switch — discovery and the image stream both work.

It needs Windows 11 22H2 or later and WSL 2.0 or newer. Add the mode to .wslconfig in your Windows user profile:

[wsl2]
networkingMode=mirrored

Then restart WSL so the file takes effect:

wsl --shutdown

Reopen WSL2 and run ip addr again: eth0 should now carry the host's LAN address. Run your tool's scan and the camera appears; the ROS node finds it on the next start without any configuration change.

Two follow-ups worth knowing. In mirrored mode the Windows firewall stands in front of WSL traffic as well, so with a correct address and an empty list, work through the firewall checks linked in the first section. And with several NICs installed, make sure the tool scans the adapter the camera is physically connected to; the switch-port and bandwidth planning numbers apply to a mirrored host unchanged.

If mirrored mode is not available: move the stack

On Windows 10, or where policy forbids changing the WSL network, run the acquisition where the NIC lives.

On the Windows host. GigE cameras ship a Windows SDK and GenTL producer, so acquisition moves over with no new hardware. If you keep image processing in WSL2, you end up shuttling frames across the same boundary you are trying to avoid — most teams move the whole pipeline to Windows instead. Give the stream a NIC of its own: the MV-GE2002P is a dual-port PoE GigE card with two ports, full height, so the camera draws power over the data cable:

The rest of the range sits in the frame grabbers category, and the accessories finder filters it by interface and port count.

On a native Linux machine. A small Ubuntu box next to the camera runs the same ROS1 node code with no virtual network in the path. This is the zero-surprise option and the right one for anything that must run unattended around the clock. Dual-booting the same workstation works too, as long as the camera talks to whichever system owns the NIC at that moment.

What will not work even though ping does

Forcing the camera's IP. A unicast control packet from WSL2 does traverse the NAT, so a forced-IP command can be accepted once. The stream is different: the camera starts sending UDP packets to your address without an open flow, and NAT drops unsolicited inbound traffic. There is no port forward that rescues it — the built-in Windows port-proxy tool forwards TCP only, and the stream runs over UDP. Half-working setups like this produce symptoms close to the stream timeout and packet loss guide, but there the transport is fixable and here it is not.

Bridge and relay scripts. Community scripts that relay UDP or bridge the WSL switch to the LAN break with Windows updates and are unsupported by anyone. Mirrored mode is the documented equivalent; use it instead of a script.

WSL1. The details sit in the FAQ above: the broadcast reaches the LAN because there is no virtual NAT, but there are no raw sockets, tcpdump does not run, and some SDK features misbehave without a real Linux kernel. Use it to prove a diagnosis, not as an acquisition platform.

Keep it working

• Re-run the two checks after WSL updates. WSL releases have changed networking behaviour before; ip addr plus a UDP 3956 capture re-verifies the mode in two minutes.
• Keep the camera address inside the LAN subnet, as a reserved DHCP lease or a recorded static address. A camera outside the subnet fails discovery on every host, WSL2 or not.
• Keep the .wslconfig change in workstation setup notes, so a rebuilt machine does not silently fall back to NAT mode.
• Test with the SDK's list command before the ROS node. It separates the transport layer from your node's configuration in one step.

For a GigE setup meant to run on Windows or native Linux, start in the camera finder or build a system and we will check the networking plan with you. If you would rather talk it through first, the contact page reaches the applications team, and the systems topic page collects the rest of the transport-layer troubleshooting.