GVSP packets, no receiver: the port unreachable fix

You integrated a GigE Vision camera with a GenTL consumer or your own receiver. The software trigger returns success, the exposure or the projector clearly fires, and the application still receives zero frames. A packet capture settles it in one line: the camera transmits every GVSP data packet, the host answers the first few with ICMP port unreachable, and no process holds a UDP socket on the negotiated stream port. The camera is not the problem; the receiver side is. This guide walks the failure in the order you meet it: what the capture proves, how to read the stream destination back over GVCP, how to bind a test socket and exonerate the host path, and how to make the component that binds the socket also write the destination. It ends with the NIC and cable choices that keep multi-camera machines out of this class of failure.

Why does the camera send every GVSP packet but the application receives nothing?

Because no UDP socket is bound to the stream port the camera was told to use: the kernel answers the first packets with ICMP port unreachable, rate-limits that to about one per second, and silently discards everything after — all 1,340 packets of a 12 MP frame.

GigE Vision splits the work in two. GVCP, the control protocol, configures the device and sets up the stream channels; GVSP carries the image data itself. Before acquisition, the application writes a destination — host address plus UDP port — over GVCP, and from then on the camera sends unicast GVSP datagrams to exactly that pair. The trigger path is separate: when emission is visible on every software trigger, device-side acquisition is confirmed and the fault lies downstream. Confirm emission with a sheet of paper held in the field — never by looking into a laser projector aperture.

The signature is distinctive. A node dump can show NumPacketsReceived = 0 while StreamDestinationIP = 0 and StreamPort = 0: the consumer never wrote a destination at all. Test code that hardcodes the pair makes the camera transmit anyway. One captured integration shows the result: 42,474 GVSP packets sent to UDP port 49152, the first few answered with ICMP port unreachable, the remainder silently discarded by the kernel. Every packet of the frame arrives at a host that has nowhere to put it.

What one frame costs on the wire

Take a 12 MP mono8 frame — 12,000,000 bytes. With 9,000-byte jumbo frames carrying about 8,960 bytes of GVSP payload each, one frame needs 12,000,000 ÷ 8,960 ≈ 1,340 packets. A 1 Gb/s link sustains about 110 MB/s after headers and inter-frame gaps, so the frame occupies the wire for 12,000,000 ÷ 110,000,000 ≈ 0.109 s, about 109 ms, which caps the stream near 9 frames per second. An unbound port discards all 1,340 packets inside that same 109 ms — payload size changes nothing about whether anyone listens.

The LS-CMR-0053 is a 12 MP GigE area scan camera rated at 9 fps:

What does ICMP port unreachable mean in a GigE Vision capture?

It means the datagram reached the host but no socket was listening on that port at that address: the host's ICMP layer reports the fact to the sender, and because GVSP is one-way UDP with no handshake, the camera keeps transmitting the whole frame.

The ICMP replies are addressed to the camera, not to your application, which simply waits out its timeout — the GigE Vision stream timeout checks cover that side of the symptom. Linux also rate-limits destination-unreachable replies to roughly one per second, so a capture showing a few ICMP messages and then silence does not mean the camera stopped: in the captured case, tens of thousands of packets followed the last reply. And if your wait call dies with SIGSEGV or a double free instead of returning a timeout, that is a separate defect in the consumer binary — report it to its vendor — but the network fix below does not change.

Keep the two unreachables apart. Ping tests the host, not the port; if ping itself returns destination host unreachable, the fault sits at the link or routing layer, and destination host unreachable ping diagnostics work through that case. Port unreachable with a successful ping is the receiver-side failure this article fixes.

Torn, horizontally striped frames belong to the last row: a receiver exists but drops packets mid-frame, the failure traced in GigE Vision packet loss horizontal lines. Zero frames from a live transmitter is the first row.

How do you check the stream destination the camera is really using?

Filter the capture for the GVCP writes made before acquisition and read the destination registers back: the camera streams to exactly the address and port last written over GVCP — UDP port 49152 in the captured case — and node values of 0 mean nothing was ever written.

• Isolate the control channel: GVCP runs on UDP port 395, so the display filter udp.port == 395 shows every write. Find the destination write and note which process sent it — the producer, or your own test code.
• Read the nodes back: most stacks expose StreamDestinationIP and StreamPort. Values of 0.0.0.0 and 0 mean the write never landed, and the camera may still stream to whatever a previous session left behind.
• Trust the packets over the node map: the destination column of the GVSP datagrams is the destination actually in force.
• Mind the ordering: the destination must be in place before acquisition starts, the same discipline as setting the GigE camera packet size before acquisition.
• Feeding two receivers from one stream is a destination-mode question instead, covered in GigE Vision multicast receiver setup.

Why is no socket bound to the stream port on the host?

Most often, the consumer opened the device through a different interface instance than the one it streams on; next, the producer never finished its handshake, so it wrote no destination and opened no socket; third, application code overwrote the destination with a value no receiver owns.

On a host with several network interfaces, discovery broadcasts can find the camera on one NIC while the producer binds its receive socket on another; the camera then streams to an address nobody is listening on. Give every camera a home interface and port — the discipline in assigning cameras to ports reliably — and on cross-compiled targets, read GigE Vision RTOS porting and multi-NIC discovery first.

A consumer that reports DeviceRegistersValid = false could not validate the device registers through its producer. It never reached the stage of writing a stream destination or opening a socket, so no binding appears no matter how the camera is triggered. Fix the producer's device access before anything else: the compatibility path is the GenTL producer GigE Vision support check.

The third cause is self-inflicted. Test harnesses that hardcode StreamDestinationIP and StreamPort make the camera transmit faithfully while the consumer's real socket sits on a different port — the exact capture from the first section.

How do you prove the host can receive on that port?

Bind a plain UDP socket to the negotiated port on the host and trigger one frame: if a test receiver counts datagrams, the camera, cable and link are exonerated and the defect sits in the consumer; if it counts none, the loss is on the path.

1. List the listeners. On Linux, ss -lun prints every bound UDP socket; on Windows, netstat -an does the same. The negotiated port should be absent before your application runs.
2. Start a minimal receiver on that port. socket, AF_INET, SOCK_DGRAM and settimeout are the Python standard library's names; count and first are example variables:

import socket

count = 0      # int, datagrams received
first = None   # (address, port) of the first sender

receiver = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
receiver.bind(("0.0.0.0", 49152))   # example: use the port from your capture
receiver.settimeout(5.0)
while True:
    try:
        data, sender = receiver.recvfrom(9216)   # 9216 B covers a jumbo packet
    except socket.timeout:
        break
    count += 1
    if first is None:
        first = sender
print("datagrams:", count, "first sender:", first)

3. Trigger exactly one frame with the camera destination still pointing at that port.
4. Read the result. Roughly 1,340 datagrams for the 12 MP example means the whole path works, and the printed first sender should be the camera's address.
5. Restart your GenTL consumer and rerun ss -lun during acquisition: the producer's own port must appear, bound, before the first trigger.

Datagrams counted, application empty — the consumer is the defect; take the next section. Datagrams zero — the path is the defect: check the negotiated link speed (GigE packet size error when the link drops below gigabit) and the packet size against the end-to-end MTU (capping the packet size when it exceeds the MTU). Once frames arrive partially, receive buffers are the next lever in socket buffer tuning on embedded Linux.

How do you fix stream destination binding for good?

Make one component own both halves: the process that binds the UDP receive socket must also be the one that writes the stream destination over GVCP, immediately before starting acquisition — and nothing else in the system writes transport addresses.

In a GenTL stack that owner is the producer. The application configures exposure and triggering through the node map and never touches addresses or ports; the producer discovers the device, binds its socket, writes the matching destination, then arms acquisition. If a producer build reports DeviceRegistersValid = false, or its port never shows in the socket list during acquisition, update it or switch to one whose GigE Vision support is proven — the compatibility check linked above is exactly that path.

Host hygiene is short: allow inbound UDP from the camera address on the chosen port range, keep camera traffic on its own segment when frames are large, and give the receiving process a static address so the destination you write stays valid.

Hardware closes the remaining gaps. The MV-GE2002P is a dual-port PoE GigE NIC in a full-height bracket:

Two ports let one camera own a full gigabit segment while the second port serves another camera or the plant network, and PoE removes separate power wiring.

The MV-GE1104 is a 4-port GigE frame grabber, and the LS-CBL-0199 is a 3 m high-flex drag-chain GigE camera cable with screw locks:

More GigE frame grabbers and camera cables follow the same port-count logic: size the card to one large-frame camera per port.

When is the port unreachable actually the camera's fault?

Rarely: when the camera keeps streaming to a stale destination after the receiver moved — the register still holds an address from a previous session — or when it ignores a fresh destination write and sends to an address of its own choosing.

Stale destinations happen when the host address changes between sessions — a DHCP renewal, a replaced PC. The fix is procedural: rewrite the destination at every device open, and put the receiving host on a static address on the camera segment. Device registers are volatile, so a power cycle clears them to defaults; use that as a commissioning workaround, never as a design. If a capture shows a correct GVCP destination write followed by GVSP to a different address, hand both traces to the device vendor: that pairing is a device defect.

What checks stop this before deployment?

A one-minute commissioning sequence: destination written and read back before acquisition, the listener visible in the socket list, packet size inside the end-to-end MTU, and one camera per gigabit port while frames are large.

• Read StreamDestinationIP and StreamPort back after configuration: both nonzero, and equal to the receiving address and the bound port.
• The consumer's socket appears in ss -lun (or netstat -an) before the first trigger fires.
• The GVSP packet size fits the smallest MTU on the path, with 9,000-byte jumbo frames enabled end to end.
• Firewall rules admit inbound UDP from the camera address on the stream port range.
• Receive buffers are sized for a full-frame burst, not a trickle.
• One large-frame camera per gigabit port; share a port only for small frames or low duty cycles.
• Capture one frame at handover: every GVSP packet lands on a bound port, and the trace contains no ICMP.

When you add the next camera, run the vision system configurator to pair it with a matching NIC and cable, browse the area scan camera finder, or write to the applications team with your capture attached.