LPR / LPD

• Protokoll definiert in RFC1179 (TCP Port 515)

Probleme mit LPR in Windows XP

• Langsamer Druck (lange Übertragung) mit LPR-Port-Monitor-Software, oder mit eingeschalteter Byte-Zählung und deaktivierten erweiterten TCP/IP-Funktionen des Druckers
  • lt. KB970048 Ursache ist "Delayed ACK" des Druckers, was von Windows nicht richtig gehandhabt wird
  • behoben mit Hotfix Fix249891, der die tcpmon.dll Version 5.1.2600.5795 (15-Apr-2009, Größe 45,568 Bytes) enthält
• ist die Bytezählung abgeschaltet, wird als Datenstromlänge die Zahl 125899906843000 übermittelt - entgegen der RFC1179, die für diesen Fall eine 0 vorsieht. Die Suche nach dieser magischen Zahl erzielt viele Treffer ratloser Finder. Microsoft empfiehlt, falls es ohne Bytezählung nicht funktioniert kann diese eingeschaltet werden...

LPR oder RAW?

Ein guter Vergleich ist hier zu finden: Difference Between LPR and RAW

Bei RAW werden die Druckdaten ohne weitere Prozessierung über Port 9100 übertragen, wie früher über die LPT oder COM-Schnittstelle (nur dass diese auch einen Rückkanal hatten wie "Papier fehlt" usw.). D.h. auf dem Client muss der Druckauftrag mittels Druckertreiber druckerspezifisch aufbereitet werden, also z.B. als PCL-Druckjob. Die Übertragung läuft dann ohne großen Overhead ab.

LPR enthält ein Job-Management-System (den LPDaemon), das mehrere Drucker-Warteschlangen und Clients pro Server über einen einzigen Port unterstützt. Über LPR sind neben druckerspezifischen Binärdaten auch Formate wie CIF, DVI, troff, ditroff, Postscript und Sun-Raster definiert, die auf dem LPR-Server verarbeitet werden. Die Unterstützung dafür muss aber im Drucker vorhanden sein. In Windows wird jedoch nur das Binärformat verwendet. Außerdem gibt es bei LPR nur die Server-Antwort "ok" und "Fehler", was keinen Aufschluss über das Problem zulässt.

Beide Übertragungsarten nutzen TCP womit eine vollständige Übertragung gesichert ist. Damit bevorzuge ich unter Windows RAW und sehe ich keinen Grund LPR einzusetzen.

In Windows existiert der Befehl lpr, mit dem direkt Daten zu einem LPR-fähigen Netzwerkdrucker geschickt werden können. Ein paar Beispiele für meinen HP LaserJet 2300 mir PostScript, der den Netzwerknamen HPLJ2300 hat und die LPR-Warteschlange "lpr" bedient. Das Datenformat wird über die Option "-o" bestimmt, deren Parameter in das LPR-Control-File übertragen wird. Ist "-o" nicht angegeben, wird "-o f" verwendet, also formatiertes ASCII:

• ASCII-Textdatei: lpr -S HPLJ2300 -P lpr ASCII-Datei.txt
• PostScript-Datei: lpr -S HPLJ2300 -P lpr -o o Postscript-Datei.ps
• binäre PCL-Daten: lpr -S HPLJ2300 -P lpr -o l PCL-Datei.prn

Leider meldet der HPLJ2300 keinen Fehler zurück wenn ein nicht unterstütztes Format wie Sun-Raster oder DVI übertragen wird. Die Daten werden als ASCII interpretiert wodurch wirre Zeichen ausgedruckt werden.

Weitere Kommandos für LPR:

• Status der Remote-Warteschlange anzeigen: lpq -S HPLJ2300 -P lpr -l

SNMP-Statusabfrage

Mit "SNMP-Status aktiviert" wird der Druckerstatus zyklisch nach RFC1759 abgefragt. Damit können Gerätemeldungen wie "Kein Papier", "Gerät offen", "Offline" (heißt "nicht bereit", z.B. bei fehlendem Toner oder wenn eine Meldung am Display bestätigt werden muss) usw. übermittelt werden. Ist die Option deaktiviert, wird der Drucker immer als "Bereit" angezeigt:

• Nachdem ein Druckauftrag übertragen wurde, wird nach ca. 25 Sekunden der Status abgefragt.
• Liegt keine Meldung vor, wird alle 10,5 Minuten abgefragt.
• Liegt eine Meldung vor, z.B. Kein Papier, wird alle 55 Sekunden erneut abgefragt.

Es empfiehlt sich also diese Funktion einzuschalten wenn der Druckserver dies unterstützt.

Alternativ kann statt RAW oder LPR mit SNMP auch IPP verwendet werden. Bei Windows XP sollte die URL mit Portangabe 631 erfolgen, also z.B. "http://HPLJ2300:631". Bei IPP werden Druckaufträge und Statusinformation über das gleiche Protokoll übertragen.

AirPrint basiert auf Bonjour/mDNS und IPP. Beides kann JetDirect - aber AirPrint geht nicht...