NetBSD Problem Report #28593

From kilbi@rad.rwth-aachen.de  Thu Dec  9 14:24:56 2004
Return-Path: <kilbi@rad.rwth-aachen.de>
Received: from linus.rad.rwth-aachen.de (linus.rad.RWTH-Aachen.DE [134.130.11.100])
	by narn.netbsd.org (Postfix) with ESMTP id D447B251EB0
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  9 Dec 2004 14:24:54 +0000 (UTC)
Message-Id: <200412091424.iB9EOoUe024090@basis.lke.rad.klinikum.rwth-aachen.de>
Date: Thu, 9 Dec 2004 15:24:50 +0100 (MET)
From: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
Reply-To: kilbi@rad.rwth-aachen.de
To: gnats-bugs@netbsd.org
Subject: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
X-Send-Pr-Version: 3.95

>Number:         28593
>Category:       bin
>Synopsis:       lpd is handling jetdirect/direct tcp printers not properly
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 09 14:27:00 +0000 2004
>Last-Modified:  Thu Dec 09 21:45:00 +0000 2004
>Originator:     kilbi@rad.rwth-aachen.de
>Release:        NetBSD 2.0 and -current
>Organization:
>Environment:


System: NetBSD basis 2.0 NetBSD 2.0 (BASIS) #6: Mon Nov 29 10:14:17 MET 2004 root@basis:/usr/src/sys/arch/i386/compile/BASIS i386
Architecture: i386
Machine: i386
All machines/platforms
>Description:
	For several months I was investigating the reason, why several
	printjobs for jetdirect or other direct tcp (normally port
	9100) printers (as kyocera's) failed (with '40 eio error's on
	jetdirect, mostly showing some postscript errors on the
	'final' paper sheet).

	After looking at cups sources of their socket backend the
	reason seems to be that these jetdirect printers require the
	sending host to read back some message over the network
	connection (where lpd at the moment simply ends with an
	exit(0)).
>How-To-Repeat:
	E. g. take a postscript print job which produces a stderr
	meassage like '%%[ ProductName: HP LaserJet 4050 Series ]%%'
	(Adobe's Postscript driver does this), send it via direct tcp
	(lpd and port@host) to a jetdirect (postscript capable! :-))
	printer and see how it fails.
>Fix:
	The appended patch solves the problem completely for me (and
	about 40 tcp capable print spoolers of our dept.). The
	important part is the 'select' call itself (waiting for a sent
	back message and timeout), which does not end with the
	'timeout' normally. The (optional) read back of the sent back
	message yields the above mentioned postscript stderr message.

	This patch is only worth for template purposes... ;-)

	I've chosen 'sw-bug' as category because so many jetdirect
	devices are involved.

Index: lpd/printjob.c
===================================================================
RCS file: /cvsroot/src/usr.sbin/lpr/lpd/printjob.c,v
retrieving revision 1.39
diff -u -b -r1.39 printjob.c
--- lpd/printjob.c	7 Aug 2003 11:25:28 -0000	1.39
+++ lpd/printjob.c	9 Dec 2004 13:02:45 -0000
@@ -59,6 +59,8 @@
 #include <sys/types.h>
 #include <sys/file.h>

+#include<sys/socket.h>
+
 #include <pwd.h>
 #include <unistd.h>
 #include <signal.h>
@@ -299,8 +301,37 @@
 			if (TR != NULL)		/* output trailer */
 				(void)write(ofd, TR, strlen(TR));
 		}
+
+		/* That's what {Free,Open}BSD does */
+		/* , but it's not enough (still 40 eio errors) */
+		/* (void)close(ofd);
+		   (void)wait(NULL); */
+
 		(void)unlink(tempfile);
 		(void)unlink(tempremote);
+
+		/* Stuff that is done in cups socket backend */
+		shutdown(pfd, SHUT_WR);
+
+		fd_set input;
+		struct timeval timeout;
+
+		timeout.tv_sec  = 90;
+		timeout.tv_usec = 0;
+		FD_ZERO(&input);
+		FD_SET(pfd, &input);
+		if (select(pfd + 1, &input, NULL, NULL, &timeout) > 0) {
+		  char buf[BUFSIZ];
+		  int rlen;
+
+		  if ((rlen = recv(pfd, buf, sizeof(buf), 0)) > 0) {
+		    if (rlen >= sizeof(buf)) rlen = sizeof(buf) - 1;
+		    buf[rlen] = '\0';
+		    syslog(LOG_ERR, "Printer reply: >%s<\n", buf);
+		  }
+		}
+		(void)close(pfd);
+
 		exit(0);
 	}
 	goto again;

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
Date: Thu, 9 Dec 2004 16:45:37 +0100

 LOG_ERR for the return message sounds a bit drastic...

 Martin

From: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and
 jetdirect/direct tcp printers
Date: Thu, 9 Dec 2004 17:32:40 +0100

 >>>>> "Martin" == Martin Husemann <martin@duskware.de> writes:

     Martin> LOG_ERR for the return message sounds a bit drastic...

 Sure! ;-)

 My patch should only outline the problem / a solution. Also using
 'recv' seems not appropriate for all kind of 'pfd', maybe even using
 'ofd' would be the correct fd in this condition...

 I hope bin-bug people will correct all my mistakes (and I will learn
 from that) ... :-)

 Markus.

From: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
To: David Brownlee <abs@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and
 jetdirect/direct tcp printers
Date: Thu, 9 Dec 2004 19:54:05 +0100

 Some additional notes on this topic:

 My proposed patch just handles outstanding message data from the
 pronter at the end of a print job what might be not sufficient!
 Depending on the (postscript) print job much more message data can
 accumulate (I can remember some page numbering messages for each page)
 and fail the print job at an earlier stage. Maybe that's the reason
 why cups socket backend checks for (and cond. reads) incoming message
 data after each sent data block (8k in size), too.

 - Is there an easy way to handle these incoming message data
   independently from the output stream? Output data is sent quite
   wildly spread in our source...

 - Can input and output of a socket be handled by 2 different
   processes?

 - Can a socket's input independently/directly drained into /dev/null,
   so the printer is satisfied that way?

 Markus.

From: "Greg A. Woods" <woods@weird.com>
To: kilbi@rad.rwth-aachen.de
Cc: David Brownlee <abs@NetBSD.org>,
	NetBSD GNATS submissions and followups <gnats-bugs@netbsd.org>,
	NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
Date: Thu, 9 Dec 2004 16:44:20 -0500 (EST)

 [ On Thursday, December 9, 2004 at 19:54:05 (+0100), Markus W Kilbinger wrote: ]
 > Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
 >
 > My proposed patch just handles outstanding message data from the
 > pronter at the end of a print job what might be not sufficient!
 > Depending on the (postscript) print job much more message data can
 > accumulate (I can remember some page numbering messages for each page)
 > and fail the print job at an earlier stage. Maybe that's the reason
 > why cups socket backend checks for (and cond. reads) incoming message
 > data after each sent data block (8k in size), too.

 Indeed it is quite possible for a print job on a true PostScript printer
 to produce output at any time, and for it to produce pretty much any
 amount of output too.  E.g. fonts can be sent back, etc.

 This is also why I use netatalk's printer interface with my Apple
 LaserWriter instead of trying to use its builtin TCP/IP interface.

 I've also tried to get afpd or papd or whichever it is to e-mail the job
 output back to the user, but haven't had as much luck with that part
 yet.  Ideally though lpd would always do that....

 However I would suggest that if lpd is going to read back any messages
 from the printer that they should be logged in the error log file (LF)
 and that they should also be mailed back to the user if possible.

 (BTW, I've got a whole raft of other patches to usr.sbin/lpr that help
 me avoid CUPS -- let me know if you want them!  :-)

 If I could avoid netatalk just for one printer I'd like to do that too!

 -- 
 						Greg A. Woods

 +1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.