Home›Guides›The printer answers ping, but port 9100 does not
The printer answers ping, but port 9100 does not
Published:
The printer has an address, ping gets replies,
the settings page says the raw port is 9100 — and still nothing sent to
9100 arrives. The two facts do not contradict each other: ping proves the
address, not the service.
Ping proves the address, not the service
Ping is ICMP, handled by the network stack. Port 9100 is a TCP service
the printer runs on top of it. A firewall or VLAN rule can pass ICMP and
drop TCP; the raw service can be disabled, bound to another port, or busy
with a connection somebody else is holding. Each of those leaves ping green
and 9100 dead, and each needs a different fix — so the checks below are
ordered to tell them apart.
Check 1: read the configuration label
Send ^XA^WC^XZ from anything that still reaches the printer
(USB, the web page, a driver), or use the front-panel print-config option.
The label states the IP address the printer actually has, the raw
port number and whether the service is on. This is the printer's own
statement; settings pages and driver dialogs describe what somebody
configured, not what is running.
Check 2: open the port with a raw client
From the sending machine: nc -vz <ip> 9100 on Linux
and macOS, Test-NetConnection <ip> -Port 9100 in
PowerShell. The failure mode is the diagnosis: connection
refused means the address is right and no service listens there —
the raw port is off or on another number; timeout means
something between you and the printer drops TCP while letting ICMP through —
a firewall, an ACL, a VLAN boundary; connected means the
service is fine and the problem is in what you send.
Check 3: one connection at a time
A raw port that connects for one client and hangs for the next often has
a connection already open on it — a driver, a print server, a monitoring
tool that polls status and never disconnects. Close the other clients, or
unplug the printer's network for ten seconds, and try the raw client again.
If it now connects, the fix is on the host that kept the socket open, not on
the printer.
Check 4: it connects, but nothing prints
Then the transport is not the problem. Send the smallest possible label
by hand as the network
printing guide shows. If that prints, the application is sending to a
different name or queue — the
printer identity
guide walks the layers. If even the hand-sent label does nothing, check
that the file is in the language the printer speaks with the
printer language detector:
an EPL printer given ZPL, or the reverse, silently ignores the job.
