GigE Vision test packet not received: fix packet size negotiation

The camera is fine; the negotiation is not. Your GigE camera appears in the SDK, attributes read and write normally, and the moment acquisition starts the library reports that the test packet was not received. That single error stops more GigE camera bring-ups than any other network fault, and the cause is almost always one setting: the largest frame the path will carry. This guide takes you from symptom to fix. You will learn what the probe packet does, which cause to check first, how to make the path accept a 9000-byte packet, and what packet size to set when the path must stay at 1500 bytes.

What the test packet actually does

A GigE Vision camera ships its pixels as UDP packets, and the host chooses how large those packets are. Many cameras default to 9000 bytes, because fewer, larger packets cost the host less work per megabyte. A 9000-byte UDP payload does not fit an ordinary Ethernet frame, so before the first image the acquisition library runs a one-packet test: it asks the camera to send a single UDP packet at the full configured size. If that probe arrives, the size is confirmed. If it does not, the library reports that the test packet was not received and that the packet size may be too large for the network configuration.

That is why everything else works while this fails. Discovery, attribute reads and writes all travel in small packets that fit any network. The probe is the first traffic on the link that needs every device between camera and host to accept an oversized frame, which engineers summarise as a path MTU match.

Order matters too: the packet size belongs in the set-up before acquisition starts, not during it. The article on setting the GigE camera packet size before starting acquisition walks that sequence and the settings that ride along with it.

Likely causes, most probable first

Work down the list; the first two causes cover most failed bring-ups.

1. MTU mismatch on the path. The camera is set to 9000 bytes while the host NIC, or one switch port in between, still sits at the 1500-byte default. The probe dies at that hop and the error follows. Test: read the NIC's jumbo-frame property in the adapter's advanced settings, then the MTU of each switch port on the camera's route.
2. Packet size raised above what the path carries. Someone increased the camera's packet size on an office network to chase bandwidth. Test: read the packet-size feature and compare it with the smallest MTU on the path.
3. Security software swallowing the probe. A host firewall can pass small packets and still drop the oversized reply or the stream's UDP port. Test: disable it for one negotiation attempt. The deeper version of this failure — ping works, discovery fails — is its own article.
4. Generic network driver on the NIC. A stock driver loses high-rate UDP traffic, and the probe can be its first casualty. Test: confirm the performance driver is installed and bound to the adapter; what the high-performance NIC driver actually gains gives you the expectation to check against.
5. The library is probing a different adapter. With several NICs installed, discovery can arrive through one port while the probe is expected on another. Test: disable unused adapters or pin the camera to the port's subnet; the scheme in assigning cameras to ports reliably removes the guesswork for good.

Fix the path: raise the MTU, then retry

Prefer this fix, because it keeps the probe as your safety net and keeps the bandwidth you chose the large packet size for.

1. Set the host NIC's jumbo-frame (MTU) property to 9000 bytes.
2. Set every switch port between camera and host to 9000 bytes or more; many switches accept 9216, and any value at or above the packet budget works.
3. Leave the camera's packet size at 9000 for the first attempt.
4. Beat the camera to the test: from the host, send an ICMP echo with the do-not-fragment flag set and a payload of 8972 bytes, first to the nearest switch and then onward toward the camera. The arithmetic is the probe's own: 9000 − 20 (IP header) − 8 (ICMP header) = 8972.
5. Re-run negotiation. A passing probe starts the stream at the full packet size.
6. If the probe still fails, split the path and test hop by hop; the first hop that refuses the 8972-byte echo is the one to reconfigure.

One strictness note. The IP and UDP headers ride outside the packet size, so the strict fit inside a 9000-byte MTU is 8972. Many adapters and cameras budget jumbo frames generously, which is why a packet size of 9000 often passes anyway. Let the probe decide for your hardware; if it will not pass at 9000, set the packet size to 8972 and try once more.

When the path must stay at 1500 bytes

Sometimes the camera crosses an office switch or a network you are not allowed to reconfigure. Then disable the probe and size the packets to the path, in the same change:

1. In the camera attributes, find the test-packet switch among the transport-layer or Ethernet features and turn it off.
2. Set the packet size to 1440 bytes.
3. Start acquisition and confirm the stream.

The bandwidth you lose is small; the receive work you add is not. At 1440 bytes the same data rate needs about six times as many packets as at 9000, and each packet costs the NIC and host the same handling. On a host that also runs a second camera, that overhead is what hurts, and congested links lose stream packets more often. The budget for that case is in two GigE cameras on one host: ports and bandwidth, and the symptom of the loss is in diagnosing blank frames from stream packet loss.

Worked example: packet size on a standard 1500-byte port

The inputs, and where each comes from. The path is a standard office port at a 1500-byte MTU: that is the Ethernet default, and a failing probe at 9000 bytes with a fully reachable camera is the evidence for it. The IPv4 header is 20 bytes and the UDP header is 8 bytes; both are fixed by the protocol. The camera's packet size is the UDP payload. The remaining 32 bytes are headroom kept as the long-standing safe margin.

The rule, in words: the largest UDP payload a path can carry equals the smallest MTU on it minus the IP and UDP headers, and the camera's packet size must not exceed that budget.

The result: on this port the strict ceiling for the packet size is 1472 bytes, and 1440 is the value to set.

The decision, with the threshold: any packet size above 1472 bytes cannot survive this port — the probe fails, and with the probe disabled the frames tear. At 1440 bytes the stream passes with margin. When the camera later moves to a machine-vision VLAN with a 9000-byte MTU, re-enable the probe and raise the packet size toward 8972; each packet then carries roughly six times more image data, and the host's receive load drops with it.

Choose a host interface that behaves

Onboard Ethernet ports at factory defaults cause a good share of these failures. A network card dedicated to the cameras turns MTU, driver and bandwidth into three settings you own: set the jumbo property once, install the performance driver, and negotiation becomes a formality. If you are specifying the interface from scratch, the knowledgebase article on selecting hardware for GigE Vision acquisition compares what to weigh in a capture NIC. The shop's host cards sit with the cameras in the accessories finder, and the range itself is under GigE frame grabbers.

A dual-port PoE NIC keeps each camera on its own port, with power over the same cable:

For a bench with more cameras, a PoE Gigabit card on a PCIe x4 slot does the same job in one card:

And where you want the receive work off the host chipset, a GigE frame grabber is the machine-vision version of the same card:

Prevent it on the next station

• Put the camera VLAN and its switch ports at a 9000-byte MTU in the build sheet, before the first power-up.
• Give each camera its own NIC or frame-grabber port and record the mapping, so discovery and probing stay deterministic.
• After any switch swap or network firmware update, re-run negotiation before production.
• Treat a probe failure as a network alarm, not a camera fault, and you will never spend a day on the wrong device.

When this is not your problem

The probe points at the path, but a few neighbouring faults wear the same mask.

• Discovery fails as well. Then the control channel is the patient, not the MTU: start with the GigE Vision firewall checks for missing images.
• The stream starts, then drops blank frames. The probe passed, so size is fine; the packet-loss article above covers diagnosis, and the stream timeout checks for packets, buffers and MTU add the buffer side.
• The link falls below gigabit and a packet-size error appears. A cable or switch negotiation dropped the speed; the packet-size error that follows a dropped link walks that fault.
• Software triggers arrive seconds late. The same setting is usually the cause; the delayed-software-trigger fix ends at the packet size too.

The decision, and what to order

Three cases, three answers.

• Path you control: raise NIC and switch MTU to 9000, keep the probe enabled, packet size near 9000. Negotiation becomes a start-up check that protects the station for its whole life.
• Path fixed at 1500 bytes: probe off, packet size 1440. Accept the higher packet count, and plan a dedicated VLAN when the cell gains a camera.
• New station: fix the MTU in the design, before the camera is ever powered, and give the cameras their own ports.

Everything on the camera side of this fix is an area scan camera speaking GigE Vision, and the host side is the cards above. To have the chain chosen as a set, start at the camera step of the configurator; if the probe still fails after the MTU sweep, send the hop list through the contact page and we will point at the offending hop.