PoE camera in WSL not found: fix the virtual network

Your PoE camera streams in the vendor's Windows viewer, it answers ping from inside WSL, and the SDK still reports no devices. That combination is not a camera fault, a bad cable or a broken install — it is the WSL 2 network doing what it was designed to do. This guide walks the diagnosis for GigE Vision cameras, Ethernet depth sensors and code readers on a PoE switch: what ping proves, why the discovery broadcast never reaches the camera, and the fixes that work — mirrored networking mode on Windows 11, or opening the device by address on Windows 10. Ten minutes of subnet arithmetic replaces hours of reinstalling.

The symptom: ping answers, the device list stays empty

Three observations define the fault. The camera is healthy: the manufacturer's Windows tool finds it and streams. From the WSL shell, ping to the camera's address replies. And the SDK's enumeration call returns an empty list, so your acquisition code has nothing to open.

This rules out most suspects in one pass. The camera, its power and the cable are cleared by the Windows stream. The Linux userland is cleared by the ping reply. What remains is the path between the two — and the same signature appears whenever a camera sits behind a virtual network, from WSL2 GigE discovery where ping works but the list stays empty to the Docker bridge, where you connect by IP. The mechanism is identical every time, and it applies to any Ethernet area scan camera or 3D sensor attached this way.

Why ping crosses the NAT but discovery does not

WSL 2 runs Linux inside a lightweight virtual machine. In the default NAT architecture — Microsoft's WSL networking documentation describes it and recommends mirrored mode for the cases it breaks — that machine owns a virtual Ethernet adapter on an internal subnet, almost always somewhere in 172.16.0.0/12, while the camera sits on the physical LAN, for example 192.168.1.x. Outbound unicast from Linux is translated through the Windows host onto the LAN, which is why your ping succeeds.

Discovery does not use unicast. GigE Vision discovery is a GVCP packet broadcast on UDP port 3956 to the local subnet's broadcast address; other stacks broadcast or multicast the same way. A broadcast never leaves the virtual switch it was sent on, so the camera never hears the query and the enumeration stays empty. The same rule — why ping is not enough for GenICam discovery — holds on every platform, and multicast adds a membership problem on top, as the WSL2 mDNS discovery failure shows.

Ping travels to address, a routed unicast. Discovery travels to broadcast, which is local by definition.

Worked example: 172.20.32.23/20 against 192.168.1.90/24

Take a typical run; your addresses will differ, the arithmetic does not. Inside WSL, ip addr show eth0 reports inet 172.20.32.23/20. The camera's Windows viewer reports address 192.168.1.90 with netmask 255.255.255.0. Those two lines are all the inputs you need.

The rule in words: the broadcast address is the host address with every host bit forced to 1 — the address OR the inverted netmask.

WSL side. A /20 prefix is netmask 255.255.240.0, so the third octet carries four network bits and four host bits:

• Address octet: 32 = binary 0010 0000
• Mask octet: 240 = binary 1111 0000
• Network octet: 32 AND 240 = 32, so the network is 172.20.32.0
• Host bits: 0000 1111 = 15, so the broadcast octet is 32 OR 15 = 47

The broadcast address is therefore 172.20.47.255, and the discovery packet goes there — on a virtual switch whose only other member is the Windows host. That /20 holds 2^12 − 2 = 4094 host addresses; not one of them is your camera.

Camera side. A /24 is netmask 255.255.255.0: network 192.168.1.0, broadcast 192.168.1.255. The camera answers discovery on that broadcast domain only.

The decision is binary: if the address on eth0 and the camera address share no subnet, discovery cannot work in NAT mode. Commit to mirrored mode below, or to opening the camera by address. Unicast ping to 192.168.1.90 needs no broadcast — WSL hands it to the default route, the host translates it onto the LAN, and the camera replies, which is exactly the pair of observations you started with.

Fix on Windows 11: mirrored networking mode

Mirrored mode makes the WSL side share the host's interfaces and addresses. Linux ends up on 192.168.1.x with broadcast 192.168.1.255, layer-2 adjacent to the camera, and discovery, multicast and inbound UDP streams behave as they do on the Windows host. It needs Windows 11 22H2 or newer.

1. Open %UserProfile%\.wslconfig in a plain-text editor — create the file if it is not there — and set:

[wsl2]
networkingMode=mirrored

2. Run wsl --shutdown, then reopen your WSL terminal; the setting applies to the next start.
3. Confirm with ip addr: the Linux side now carries your LAN address instead of 172.x.x.x.
4. Ping the camera, run the SDK enumeration, and hold a stream for several minutes.

Two follow-ups matter. Keep the camera and the host adapter in one subnet with matched masks — the procedure for setting a GigE camera's remote and local IPs applies unchanged. And if enumeration works but the video freezes, the Hyper-V firewall that guards the WSL virtual machine is filtering the inbound UDP flow; Microsoft's WSL networking documentation covers allowing it.

Fix on Windows 10: open the camera by address

Windows 10 has no mirrored mode, so make discovery unnecessary. Ping already proves the routed path, and most GigE Vision and Ethernet 3D SDKs accept a device address directly: open the camera by IP instead of taking the first entry of a broadcast scan. TCP-based control crosses the NAT reliably; UDP video is the weak point, and if the stream connects then freezes while control still answers, the NAT is dropping the return flow. At that point a TCP port forward on the host covers control-only work, and a native Linux machine — dual boot included — covers the full stack.

A third path exists: switch the distribution to WSL 1, which shares the Windows network stack instead of NAT, so broadcast discovery leaves through the host's adapter. WSL 1 implements less of Linux than WSL 2, so test your SDK there before committing a station to it.

Why usbipd cannot help a PoE camera

The walkthroughs most people find for WSL cameras use usbipd, which attaches a USB device to Linux over USB/IP. That is the right tool for a USB3 camera and the wrong one here: a PoE camera is an Ethernet endpoint behind a switch, and Windows never sees a USB device it could bind and attach. No usbipd command changes which subnet the camera lives on; the fix lives in .wslconfig or in the SDK's open-by-address call. Microsoft's official WSL USB/IP guide covers the USB case only.

Choosing the fix

Checks before you close the ticket

• ip addr inside WSL shows an address in the camera's subnet, or you are opening the camera by address.
• The SDK enumeration returns the camera, and a stream runs for several minutes without freezing.
• The camera holds a static address in the host subnet, recorded in the station documentation.
• .wslconfig is saved in your setup notes so the next machine gets the same mode.
• From the camera's viewer or web page, the client address it logs matches the WSL side.

If you are rebuilding the station, lock the physical layer down at the same time so a nudged connector never imitates a subnet fault: a screw-lock, drag-chain-rated data cable and any GigE camera or Ethernet 3D unit that serves the line, for example the parts below, with spare camera data cables of the same locking type:

When the usual answer is wrong

Reinstalling the SDK, the runtime or WSL itself. The camera was never unreachable — only un-broadcast-to. Topology first, software second.

Moving the camera into 172.20.x.x. That subnet exists only on the virtual switch between Windows and WSL. The camera hangs off a physical switch and can never be layer-2 adjacent to the Linux side, so its broadcast domain never matches, no matter which address you give it.

Waiting for DHCP to sort it out. The WSL virtual switch serves addresses to the VM only; nothing on the physical LAN will offer the camera a lease, so it stays wherever you set it.

If the station grows, plan power before cameras: check the PoE class of each camera you add, then browse the camera finder for the interface you need. More integration notes live on the systems topic page. For a subnet plan specific to your line, contact us with the camera model and your addressing scheme.