GigE Vision port numbers: UDP 3956 and the firewall rule

You can ping the camera, see it in the discovery list, even change its exposure — and the live image never arrives. That split is the signature of GigE Vision's port layout: the control channel sits on one registered UDP port, while the video stream leaves the camera from a dynamically allocated ephemeral port that most deny-by-default firewalls block. This page gives you the complete port map, the reason discovery survives while frames die, the firewall rule that fixes it, and the bandwidth arithmetic to confirm the link can carry the stream once the ports are open.

The port map: one fixed port, everything else dynamic

GigE Vision separates control from streaming, and only the control side claims a fixed port on the device. The control protocol, GVCP, listens on UDP 3956 — the single static port, registered with IANA as GigE Vision Control for both TCP and UDP, though deployments speak UDP. The host software chooses its GVCP source port from the ephemeral range 49152-65535, and the streaming protocol, GVSP, draws both its source and its destination port from that same range. The top of the range is 65535, the last 16-bit port number.

Two consequences follow. A rule for 3956 alone lets you discover, open and configure the camera — and nothing more. And the stream needs 65535 − 49152 + 1 = 16,384 UDP ports to be passable from camera to host.

Why the camera is found while the image is blocked

A stateful firewall tracks the host's outbound GVCP request to camera port 3956 and passes the reply, because the reply matches that flow. The GVSP stream is a different five-tuple: a new source port on the camera, sending to a host port that never carried control traffic, and the host never initiated it. A deny-by-default policy drops every frame. Enumeration, exposure and gain all ride GVCP, which is why they keep answering while the live view stays black.

Discovery has its own precondition: the discovery packet is a UDP subnet broadcast, so camera and host normally share a layer-2 subnet. Why GenICam discovery uses subnet broadcast explains that half of the handshake, and a GigE Vision camera firewall where ping works but discovery fails covers the control-side symptom. When the camera enumerates but delivers nothing, GigE Vision firewall troubleshooting for missing images walks the same fault from the image side.

The rule to write

On the firewall between the vision host and the camera subnet, allow two things:

1. UDP 3956 in both directions between the host and the camera subnet. This carries discovery, control and the replies.
2. UDP 49152-65535 from the camera subnet to the host. That is 16,384 ports, and it is what the stream needs.

Scope rule 2 by source address, the camera VLAN, and by destination, the vision hosts, so nothing else can ride it. If your policy cannot carry a range that wide, pin the stream instead: GigE Vision lets the receiving software tell the camera which destination port to stream to, and the setting sits with the transport-layer or stream-channel options in most GigE software. Fix it at one number — 49500 works — and the host rule collapses to a single inbound UDP port. The camera's source port stays dynamic, so match the rule on destination port, not source.

The same single-port-versus-range decision appears across industrial networking. TCON UDP ephemeral port configuration in PLCs works the identical problem when a PLC reply comes back from an unpredictable port. On the device side, firewall ports and port forwarding on an industrial edge controller shows the rule-writing steps for one class of controller.

Worked example: a 20 MP stream on one GigE link

Take a 20 MP GigE camera in this class, such as the MV-CS200-10GC. An 8-bit mono frame is 20 M pixels × 1 byte = 20 MB. At 5 fps the stream is 20 MB × 5 = 100 MB/s. A 1000BASE-T link moves 1 Gbit/s = 125 MB/s on the wire; after GVSP headers, framing gaps and NIC overhead, plan on 80 percent of it: 125 × 0.8 = 100 MB/s. The link runs at its ceiling with nothing in reserve. At 10 fps you need 200 MB/s, which is a 10GigE camera, not a firewall argument.

A smaller sensor changes the arithmetic, not the rule. At 2.5 M pixels × 1 byte = 2.5 MB per frame, 30 fps gives 2.5 MB × 30 = 75 MB/s — one GigE link with headroom. Ask for RGB8 at 3 bytes per pixel and the same stream becomes 225 MB/s, past what one 1 Gbit/s link carries. Size the camera from the pixel count your inspection actually needs — the camera resolution calculator does that step — then multiply by frame rate as shown.

A 20 MP GigE camera for the single-link limit case:

A 2.5 MP global-shutter GigE camera for the same link with headroom:

What the port rule does not change

Opening the ports fixes delivery, not throughput, and three neighbours of the rule decide whether the stream is healthy once it flows:

• Packet size. The GigE Vision packet size and the NIC jumbo-frame setting set how close you get to wire rate. The same lever is what rescues a 10GigE camera delivering only 1 Gbps.
• Link speed. 5GBASE-T and 10GigE cameras use exactly the same two rules, 3956 plus the ephemeral range. Only the bandwidth changes; cable category and distance for the faster links are covered in 5GBASE-T camera interface bandwidth, cables and distance.
• Multicast. GVSP can address a group instead of one host. The receiver then needs its own configuration, described in GigE Vision multicast receiver control and stream setup.

One thing the rule cannot fix: crossing subnets. Broadcast discovery stops at the router. Accessing GigE cameras from another subnet covers the routed case, and connecting to a GigE camera without broadcast discovery covers networks where broadcast is filtered outright.

Checks before you blame the ports

• Ping proves nothing. ICMP is neither GVCP nor GVSP; a camera that answers ping can still be fully blocked on both channels.
• Bypass test. Stop the host firewall on the camera NIC only, then retest. Frames appear: the rule was the problem. Frames stay absent: look at the link.
• Negotiated speed. A link that settled at 100 Mbit/s carries about 12.5 × 0.8 = 10 MB/s, so a 20 MB frame needs two seconds to arrive. Check that the switch port and the NIC both report 1 Gbit/s.
• MTU end to end. Mismatched jumbo settings drop or truncate frames under load rather than blocking them cleanly. Camera, switch and host NIC must agree.
• Cabling. A locking, flex-rated lead keeps the link from re-negotiating mid-run: the 3 m high-flex GigE camera cable with screw locks pattern, from the GigE camera cables range.

The rule as a checklist

• UDP 3956 open both ways between the vision host and the camera subnet.
• UDP 49152-65535 allowed camera to host, scoped to the camera VLAN as source.
• Otherwise pin the stream destination port and open that single inbound UDP port.
• Camera subnet on its own NIC; jumbo MTU matching from camera to host.
• Link negotiated at full speed: 1 Gbit/s as the floor for a 100 MB/s-class stream.

Choosing the camera and the cable

Pick the sensor first: resolution and frame rate set the bandwidth, and bandwidth decides whether one GigE link is enough or you step up to 10GigE. Browse GigE area scan cameras with the camera finder filtered on interface and resolution, then take the whole station through the system configurator starting at the camera step. If the network policy is the sticking point, send the camera model and the firewall platform through the contact page and we will write the rule with you.