This is a bug (discussed on this list a while ago) in Win2K. Per the RFC you
must either put a zero (0) in the byte count field, or the total amount of data
to be printed. Thus you have the choice in Win2k to count bytes or not. The bug
is that if you choose not to count bytes Win2k fails zero the counter and puts
some random (usually very large - on the order of terabytes) value on the byte
count field instead of zero. If you count bytes then the correct value is placed
in the byte count field. Per the RFC the LPR server should refuse connections if
it does not have enough space to hold the file. Most of us do not have terabytes
of free space on our spool file systems so LPRng properly refuses the print
request.
What amazes me is that M$ has not put out a patch for this. It's got to be a one
line fix, simply zero the counter. But as of SR1 there is no patch available
that I am aware of to fix this. The work-around is to always count bytes.
- Justus Addiss
Joshua Penix <[EMAIL PROTECTED]> on 02/02/2001 21:08:51
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc: (bcc: Justus J. Addiss/HI-Healthinfo/3M/US)
Subject: LPRng: LPR Byte Counting
I just spent a disgusting amount of time attempting to get Windows NT and
2000 clients talking to my Linux-based LPRng print server. Here's what I've
found, and am curious about any insight list members might have.
My objective is to move printing from our Novell server to the Linux print
server. 95% of client stations who use the printers are running NT4.0. All
printers are attached via JetDirect.
We've set printing up successfully with Samba doing the work of accepting
jobs and feeding them to the local LPRng daemon. But just for grins, we
thought we'd try leaving Samba out of the equation, and have NT4 use its
TCP/IP printing functionality to talk directly to the LPRng box via standard
LPR protocol. I assumed this would work because NT4 can talk directly to
our JetDirects via LPR... but when pointing it to our LPRng box, it
absolutely refused to submit the job, chalking it up to "unknown network
errors."
My laptop happens to run Win2k, so I figured I'd try it as well... created a
new "Standard TCP/IP Port" and gave it the IP of the LPRng server and a
queue name. It also refused to print, simply saying "There was an error
found when printing the document" (whoever wrote these useless Windows error
messages should be shot). But it also happily printed to a JetDirect's LPR
interface.
The failure of both NT4 and Win2k to talk to LPRng was followed by about 3
hours of my tailing LPRng logs, messing with printcap, messing with
lpd.perms, messing with lpd.conf, all to no avail.
Then, in a final frustrated attempt before going home I re-created the
"Standard TCP/IP Port" on my Win2k box and this time checked the "LPD Byte
Counting Enabled" box. Microsoft's Win2k help describes this option as
follows:
"Click if you encounter problems such as missing or incomplete documents
when printing. When LPR byte counting is enabled, the computer counts the
number of bytes in a document before sending it to the printer. Byte
counting, which can be very time consuming, is not required by most
printers. This option is available only when the LPR protocol is selected."
Well shazam! As soon as I checked that box, the damn thing printed without
complaint. I then went over to a NT4 box to try checking the same option,
only to find that it doesn't have one. So, having a lead on "LPR Byte
Counting" I went and dug around Deja. Very few references to it, but the
ones that did exist were people saying "LPR Byte Counting is required per
the RFC standard, so why on earth is there a box in Win2k to make it
optional?"
Of course, far be it from Microsoft to actually follow an RFC standard
properly... thus my *assumption* is that NT4's TCP/IP printing functionality
is "broken" in regard to byte counting, and LPRng is enforcing the standard
and denying NT4 when it wants to print. Does this sound right? Anyone else
tried such a thing?
So it looks like I'll be going back to Samba unless anyone knows a
workaround... what a pain!!!
--Josh
-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
