TCP client or listener: match your network barcode reader to your host

A networked barcode reader that answers a ping but never delivers a scan is almost always a role problem, not a wiring problem. One end is trying to open the TCP connection while the other end is trying to do exactly the same. This guide gives you the client and listener model in one page, the six settings that make a push work, the socket states that prove the link came up, and the bridge that rescues the case where both ends insist on dialing out. It is written for controls and software engineers connecting fixed code readers or Wi-Fi handhelds to a host application, SCADA, MES or a PLC.

Why does a networked barcode reader that answers a ping still send no scans?

Because the two ends disagree about who dials. A TCP connection forms only when one side actively connects to the other's listening port; if both ends try to connect out, or both sit waiting, the handshake never completes and no scan data moves.

TCP carries data only after a connection exists. A connection exists only after one side sends SYN, the listener answers with SYN-ACK, and the dialing side completes the handshake with ACK. A ping proves none of that: it shows the network path and the reader's stack are alive and says nothing about port state. The mismatch has two shapes. If both ends are clients, each sends SYN to a port where nothing listens, and each gets a refusal or a timeout. If both ends are listeners, both wait forever and the wire stays silent.

One wording trap catches teams here. Some host drivers describe themselves as passive listeners because they wait for data after connecting, yet they still dial out first. The word describes the receive behavior, not who opens the socket. Read the reader the same way — push, stream and auto-connect all mean client.

What is the difference between a TCP client and a TCP listener on a barcode reader?

A client opens the connection: it stores the far end's IP and port and sends the first SYN packet. A listener binds its own port number, waits for that SYN, accepts the session, and reads whatever arrives — once established, either side may send.

Which side dials has no effect on who talks afterwards: once the session is up, both ends can send and receive over it. The two port numbers behave differently, and that is where most confusion starts. The listener's port is fixed by configuration — 5000 in the examples below. The dialing side picks a fresh ephemeral source port for every session: 49152–65535 by default on Windows hosts, 32768–60999 on Linux. Your firewall rule opens the listener port only; the source port needs nothing.

Which side should open the connection in a barcode reader set-up?

Let the reader dial and the host listen for the usual line-side set-up. A reader configured as a TCP client with a fixed host IP and port pushes each decode within milliseconds of the scan, and the host application simply binds that port and reads what arrives.

Reader-as-client wins on the line for three practical reasons. The reader knows the instant it has a decode, so latency is LAN speed — a few milliseconds on a switched network, next to the tens of milliseconds the decode itself takes. Host software restarts far more often than readers redeploy, and a listener comes back in seconds while the reader reconnects on its retry timer. One listening port then serves every reader on the line, because each opens its own session from its own source port.

Choose host-as-client when the exchange is command-driven: the host decides when a read happens, sends the trigger, and gets one answer per command — the right shape when a read must wait for a clamp, a gate or an operator confirmation.

The same split applies to handheld code readers. A Wi-Fi handheld joins your WLAN, takes the host's IP and listening port in its network settings, and pushes each scan as a client; a wired Fast Ethernet handheld behaves identically on the plant network, minus roaming. The two models below cover both cases:

How do you set up the reader as the client and the host as the listener?

Configure five settings on the pair and one firewall rule, and the push works: 192.168.10.10 as the host, TCP 5000 as the listener port, a few seconds of reconnect, a CR LF record boundary, and an inbound rule scoped to the reader's subnet.

1. Host address. Give the listening host a stable IP — static, or a DHCP reservation — because the reader holds that address in its own configuration and dials it on every push.
2. Listener port. Pick a free registered port, 1024–49151; 5000 is the common bench choice. Ports below 1024 need elevated privileges on Linux and buy nothing.
3. Reader side. Set the reader's protocol to its client, push or auto-connect mode, enter the host IP and port from steps 1 and 2, and set the reconnect interval to a few seconds so a host restart costs one retry cycle.
4. Bind address. Bind the listener on 0.0.0.0 or on the plant NIC's IP. A listener bound on 127.0.0.1 accepts connections from the same machine only — the classic reason a remote reader never arrives.
5. Framing. TCP is a byte stream, not a message queue: terminate each record with a suffix such as CR LF so the host can split records — the record-boundary patterns are in the prefix and suffix framing for barcode scanner input guide.
6. Firewall. Add one inbound rule: TCP 5000 to the host, restricted to the reader's subnet. Host firewalls block inbound by default, so a push that works with the firewall off and dies with it on is a missing rule, not a role problem.

Worked example. Plant LAN 192.168.10.0/24, host listener at 192.168.10.10 on TCP 5000, reader at 192.168.10.51. With the host application running and the reader still powered down, the host shows the listener bound:

TCP    0.0.0.0:5000          0.0.0.0:0            LISTENING

One retry interval after the reader boots, the session appears:

TCP    192.168.10.10:5000    192.168.10.51:53312  ESTABLISHED

Port 53312 is the reader's ephemeral source port for this session, inside the dynamic range desktop Windows uses by default (49152–65535; Linux defaults to 32768–60999). If the state sticks at SYN_RECEIVED, a firewall is swallowing the handshake. If no line ever appears, the reader's target IP or port does not match the listener.

Fixed readers run the same pattern all shift. The fixed code readers below are Ethernet and GigE models shortlisted for exactly this duty — reader as client, pushing each decode to your listener:

How do you set up the host as the client with the reader as the listener?

Reverse every value. The host driver dials the reader's IP and service port, the reader goes into server or accept mode on that port, and the inbound firewall rule moves to the reader's side, permitting TCP to its service port from the host's address.

The reader's service port is part of its command protocol, so you set exactly the number that protocol defines — it is not a free choice like a push target. After the session comes up, the host sends a trigger and reads one decode per command, which suits stations where the read must wait for a fixture. Reconnect duty flips too: when the reader reboots, the host's session dies, so set the host driver's reconnect timeout to a few seconds as well. Expect one connection per reader in this pattern; a fleet of readers means a fleet of sessions, which is the load the reader-as-client pattern handles better.

What do you do when both the reader and the host insist on being the client?

Bridge the gap with a serial-to-Ethernet converter: connect an RS-232 barcode reader to the converter, set the converter to server mode listening on a raw TCP port, and point your client-only host driver at the converter's IP and port — the host now dials something that actually answers.

Three ways out, in the order most plants pick them.

Converter bridge. The converter binds a raw TCP port — 4001 and 10001 are the defaults you will meet most often — and forwards every serial byte over the established session, so the client-only host finally has a listener to dial. Power-over-Ethernet models feed the reader over the same drop. The serial side is covered in the RS232 barcode scanner connection to an embedded host guide, and the reader without Ethernet in handheld barcode scanner to a PLC without Ethernet.

UDP, if both ends offer it. A UDP push needs no handshake, so the roles stop mattering: the reader sends datagrams to the host's IP and port, and a UDP listener simply receives them. Size each datagram to stay unfragmented on Ethernet:

UDP does not retransmit, so treat it as informational; a scan that gates stock movements belongs on TCP with framing.

Move the link behind a PLC. Let the controller own the reader and let the host read from it: the Ethernet/IP implicit I/O assembly and Modbus RTU guides map those links, and this PLC-side PROFINET and TCP reader integration page applies the same role thinking on the controller. When the host is a robot controller, nothing changes — its socket instructions are the client and dial the reader's listener or the converter, as the TCP client configuration for a robot controller shows end to end.

How do you test which role each side is playing before touching production?

Separate reachability from role: ping proves the cabling and the reader's stack, a port test proves a listener exists, and the socket states prove who dialed whom — three bench checks that take less than five minutes.

Run the checks in order. On the host, netstat -an | findstr 5000 on Windows, or ss -tlnp | grep 5000 on Linux, shows whether your side is LISTENING; if the line is missing, the listener never bound, usually because another process owns the port. Second, test a connection toward the far end: Test-NetConnection 192.168.10.51 -Port 5000 on Windows or nc -zv 192.168.10.51 5000 on Linux. Success proves a listener exists there, refusal means the device is reachable but nothing listens on that port, and a timeout points at routing or a firewall. Third, power-cycle the reader and watch the states walk LISTENING → SYN_RECEIVED → ESTABLISHED within one retry interval.

When should a network barcode reader not use raw TCP push at all?

Change transport when data must not be lost or when the host speaks fieldbus. A scan that gates a physical action deserves an acknowledged path — PLC I/O over Ethernet/IP or Modbus, or an application-level ACK — because raw TCP push confirms delivery to the socket, not consumption by the application.

If the host crashes between receiving a record and writing it, the reader believes the scan was handled and nothing retries. For reject kicks, pick confirmations and batch records, add an acknowledgement: an application-level ACK over the same socket, or a PLC-owned link whose I/O image updates only after a completed exchange — the barcode reader PLC communication planning guide walks that reliability decision. Add a sequence number alongside the CR LF suffix so the host notices a gap and can demand a re-send, and judge the decode itself before trusting it, as the barcode read confidence guide sets out. Where the record must survive with its image for audit, the barcode inspection image archiving guide keeps decode and picture together.

What should you check before ordering an Ethernet barcode reader?

Shortlist by protocol before pixels: the reader must offer a TCP client push mode with a configurable host IP and port, a reconnect interval settable in seconds, and — if your host driver only dials out — a server or accept mode or an RS-232 port you can bridge.

• Interface first: Fast Ethernet or GigE for fixed stations, WLAN for handhelds that move with operators, PoE where a second cable would be costly.
• Client push mode with a configurable target IP and port, plus a reconnect interval measured in seconds, not minutes.
• Server or accept mode — or an RS-232 fallback — for the client-only-host case.
• Framing control: configurable prefix and suffix, with CR LF as the minimum.
• The parts around the reader: light boards, lens covers and I/O boxes from the code reader accessories range.

Decision, restated per case: the reader dials and the host listens on push lines; the host dials and the reader listens on command-driven stations; when both ends insist on dialing, bridge through a converter, switch to UDP, or move the link behind a PLC. Filter models by interface and resolution in the code reader finder, then tell us which side dials in your architecture and we will check the protocol fit with you — start at the contact page. More integration patterns sit in the code-reading guides.