Client host sending wrong input to LPD port

We are starting to see more and more support incidents about the message “client host x.x.x.x sending wrong input to LPD port”.  This message should require little interpretation since network administrators are the target audience for RPM.  It gives the IP address of a host communicating improperly with RPM.  In other words, this host is not using proper LPR/LPD protocol.

You should check the IP address of the client host here.  If it is outside your network and is not a trusted host, you should take steps to harden RPM against further unwanted intrusion.  This starts by identifying the hosts you actually want sending you print jobs and then blocking all other hosts.

If the IP address is inside your network, it is likely caused by a network vulnerability scanner.  In some cases, RPM handles these scans without issue but reports a critical event which cannot be suppressed.  Some vulnerability scanners are more intrusive than others and can cause issues which prevent RPM from receiving further print requests.  This was fixed in RPM 6.2.0.594 (2026-02-26). Scanners that opened and closed connections faster than RPM could process them could exhaust its connection pool, after which RPM stopped accepting connections until the service was restarted. The root cause is resolved, so if you are seeing this symptom, check your RPM version first. On earlier versions, restarting the RPM service — or in extreme cases the computer — is the only way to restore printing.

RPM is a print server which primarily works with print data from legacy systems.  The LPR/LPD protocol is not a perfectly defined protocol like HTTP or SSH in that it does not see regular updates for emerging security threats.  LPR/LPD is described in rfc1179.  In there, it specifically says that the document is not defining an official Internet standard, but is attempting only to document standard practices between vendors of the era.

The solution, whether the traffic originates from inside your network or outside, is to block the offending host(s).  The best scenario is to block all hosts except only those from which you wish to receive print jobs.  The safest place to block outside hosts is on a company firewall preventing the traffic from even reaching the RPM host.  For inside hosts, it could be done using the Windows firewall or one included with your antivirus program on the host where RPM is installed.

RPM also has its own Host Access settings, which control who may submit print jobs to RPM regardless of what the network in front of it allows. As of 6.2.0.600 (2026-04-05) these offer three modes — allow all hosts, allow all except those listed, and deny all except those listed — and hosts can be given as individual addresses, hostnames, wildcards such as *.example.com, or CIDR ranges such as 192.168.1.0/24.  Use both. A network firewall stops unwanted traffic before it reaches the RPM host, which is the better place to stop it. Host Access is the boundary that belongs to RPM itself, so it still applies if the host moves, if someone else changes the firewall rule, or if the traffic originates inside the perimeter — which, as noted above, is where a vulnerability scanner usually lives. Earlier versions offered only a single on/off toggle, which is why we once described this as a temporary measure; a default-deny list with CIDR support is a real access control and worth configuring on its own merits.