Home›Guides›Printer identity: why queue names and IPs betray you
Printer identity: why queue names and IPs betray you
Published:
Its companion guide diagnosed the symptom:
a label printed on the wrong
printer. This one explains why the stack makes that failure
easy — layer by layer, from your application down to the socket. None
of these layers is broken. Each simply trusts an identity that is allowed to
change underneath it.
Layer 1: the application knows a name
Your ERP, WMS or script says "print to PRINTER_A". That string is
the only thing the application knows. It has no idea what device the name
resolves to today — it delegates that entirely to the layer below. If the
mapping below changes, the application keeps doing exactly what it was told,
and keeps being wrong.
Layer 2: the queue is a hand-maintained mapping
Windows and CUPS queues are name-to-port tables edited by humans:
installers, backup restores, cloned workstation images, driver reinstalls.
Nothing reconciles this table against physical reality. Two queues can point
at one port; one queue can silently move to another port; a restored image can
bring last year's mapping into this year's network. The queue layer
answers "where does this name go?" — it never answers "is that
still the right place?"
Layer 3: the address is a lease
An IP address feels permanent because it rarely changes — but on a DHCP
network it is a lease, and the lease table is the only place
the binding exists. A power cut, a long weekend past the lease time, or a
router replacement reshuffles it. The printer that was .50 comes back as .73,
and whatever now owns .50 — another printer, a scanner, a thermostat —
receives the jobs. Printers make this worse than laptops do: they are
installed once, by their address, and nobody looks again for years.
Layer 4: port 9100 has no handshake
Raw printing (JetDirect, port 9100) is a design from a friendlier era: open
a TCP socket, write bytes, close. There is no step where the device
says who it is and no step where the sender checks. Any listener on
that port — including the wrong printer — accepts the bytes without complaint.
The one protocol interaction that could catch the drift simply does not
exist.
Layer 5: the language carries no identity either
ZPL itself has no "print only if you are printer X" field.
^XA … ^XZ describes the label, never the intended device. EPL,
TSPL and CPCL are the same. So the last line of defence — the job content — is
also blind. By the time bytes reach the wrong printer, nothing in them can
reveal the mistake; you find out when a human finds the labels in the wrong
tray.
Why "it never happened to us" is survivorship
Every mechanism above fails silently and intermittently: the failure needs
a lease to expire and another device to claim the address, or a clone
and a name collision. Sites go years without it, then lose an
afternoon of shipping labels at the returns desk. The absence of the failure
is luck compounding, not evidence of a safe design.
What a real fix looks like
The stable identity of a printer is the device itself —
its serial number and configuration — not any name or address pointing at it.
A design that closes this class of failure has to:
bind jobs to a device identity, not to an address;
verify that identity on every connection, before sending
the job — not once at install time;
refuse to print when the device that answers is not the device the job was
bound to.
You can approximate step 2 today by hand: print the printer's own
configuration label from each queue after every network change and compare.
That is the manual version of a handshake the protocol never gave you — and
doing it by hand is exactly why it gets skipped on the busy day when it would
have mattered.
Frequently asked questions
Why is an IP address a bad printer identity?
On a DHCP network an address is a lease, not a property of the device. A power cut or an expired lease can hand .50 to another device, and every job addressed there follows it. Printers make this worse: they are installed once by address and nobody looks again for years.
Does port 9100 verify which printer answered?
No. Raw printing opens a TCP socket, writes bytes and closes. There is no step where the device states its identity and no step where the sender checks it, so any listener on that port accepts the job silently.
Can ZPL restrict a job to one specific printer?
No. ZPL has no field that names an intended device; ^XA … ^XZ describes the label only, and EPL, TSPL and CPCL are the same. The job content cannot detect that it reached the wrong machine.
