LPR Printing

G

Guest

I have a bit of problem with LPR printing on one of my machines that is
puzzling me. I can print without a problem using LPR from this box as long as
I use the command line to spool the job. The following command works just
fine:

lpr -S10.10.10.10 -PHPOJ file.txt

However when I create a new LPR port specifying the same values and try to
print the same text file from Notepad the job just sits in the local queue
and never seem to get spooled to the server (verified with lpq -S10.10.10.10
-PHPOJ) and eventually the queue goes into an error state.

What am I missing?
 
A

Alan Morris

When using LPR Ports the port name format will appear as 10.10.10.10:HPOJ
and you get a "there is nothing to configure" if you attempt to configure
port.

Is the target a print server device or another machine running the LPD
service?

This works fine just need to get some more information.
 
G

Guest

You are exactly right. The target is another WinXP box running print service
for unix (i.e. lpd).

Alan Morris said:
When using LPR Ports the port name format will appear as 10.10.10.10:HPOJ
and you get a "there is nothing to configure" if you attempt to configure
port.

Is the target a print server device or another machine running the LPD
service?

This works fine just need to get some more information.
--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

Siggi Bjarnason said:
I have a bit of problem with LPR printing on one of my machines that is
puzzling me. I can print without a problem using LPR from this box as long as
I use the command line to spool the job. The following command works just
fine:

lpr -S10.10.10.10 -PHPOJ file.txt

However when I create a new LPR port specifying the same values and try to
print the same text file from Notepad the job just sits in the local queue
and never seem to get spooled to the server (verified with lpq -S10.10.10.10
-PHPOJ) and eventually the queue goes into an error state.

What am I missing?
 
A

Alan Morris

Does this work if you print using the Standard TCP/IP Port? You have to
manually configure the port to LPR mode and Byte Count enabled. The queue
name is the share name on the machine suppling LPD.

I'll assume you have disabled the firewall on the XP LPD target. XP sets
the service to manual start. You will need to change this to automatic if
you need this on all the time. After, of course, we get this working for
you.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

Siggi Bjarnason said:
You are exactly right. The target is another WinXP box running print service
for unix (i.e. lpd).

Alan Morris said:
When using LPR Ports the port name format will appear as 10.10.10.10:HPOJ
and you get a "there is nothing to configure" if you attempt to configure
port.

Is the target a print server device or another machine running the LPD
service?

This works fine just need to get some more information.
--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

Siggi Bjarnason said:
I have a bit of problem with LPR printing on one of my machines that is
puzzling me. I can print without a problem using LPR from this box as
long
as
I use the command line to spool the job. The following command works just
fine:

lpr -S10.10.10.10 -PHPOJ file.txt

However when I create a new LPR port specifying the same values and try to
print the same text file from Notepad the job just sits in the local queue
and never seem to get spooled to the server (verified with lpq -S10.10.10.10
-PHPOJ) and eventually the queue goes into an error state.

What am I missing?
 
G

Guest

I had tried using Standard TCP/IP port but I didn't enable ByteCount. However
I tried that again and now it works from parts of my network, which is
obviously a network problem. What is so weird is that it always works
reliable if I print to file and then queue the resulting file using the LPR
command line. Does the command line LPR work differently (use different
ports, etc) than Standard TCP/IP printing over LPR?

Alan Morris said:
Does this work if you print using the Standard TCP/IP Port? You have to
manually configure the port to LPR mode and Byte Count enabled. The queue
name is the share name on the machine suppling LPD.

I'll assume you have disabled the firewall on the XP LPD target. XP sets
the service to manual start. You will need to change this to automatic if
you need this on all the time. After, of course, we get this working for
you.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

Siggi Bjarnason said:
You are exactly right. The target is another WinXP box running print service
for unix (i.e. lpd).

Alan Morris said:
When using LPR Ports the port name format will appear as 10.10.10.10:HPOJ
and you get a "there is nothing to configure" if you attempt to configure
port.

Is the target a print server device or another machine running the LPD
service?

This works fine just need to get some more information.
--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

message I have a bit of problem with LPR printing on one of my machines that is
puzzling me. I can print without a problem using LPR from this box as long
as
I use the command line to spool the job. The following command works just
fine:

lpr -S10.10.10.10 -PHPOJ file.txt

However when I create a new LPR port specifying the same values and try to
print the same text file from Notepad the job just sits in the local queue
and never seem to get spooled to the server (verified with
lpq -S10.10.10.10
-PHPOJ) and eventually the queue goes into an error state.

What am I missing?
 
A

Alan Morris

I agree that is strange. There might be some DNS hostname resolution issue
involved. Lpr.exe uses lprhelp.dll for most of the functions. Lprmon.dll
loaded in spooler uses the same lprhelp.dll for most of the same functions.

Lpr.exe in default configuration will send the data out using ports
721 -731. Standard TCP/IP Port will send data out port 1025 and above.
Some LPD service implementations will only accept data if the source ports
are 721 -731. I have only seen this with UNIX and Linux. Windows and all
the printer NICs I have ever tested accept data from any source port.

Lpr.exe and LPR Port will send a data file informing the LPD service what
the incoming file size is. LPR Port calls the spooler and GDI to completely
render the job and creates a lprxxxx.tmp file in the spool directory to
determine how much data it will send to the LPD service. Lpr.exe just uses
the existing file size since the print job was already rendered.

When using LPR Port is the tmp file created? Standard TCP/IP port uses a
canned data file and tells the LPD service the incoming job is 4gig. This
works for most printers. Windows LPD does require an exact file size. When
enabling Byte Count on Standard Port, a Tcpxxxx.tmp file is created.


--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

Siggi Bjarnason said:
I had tried using Standard TCP/IP port but I didn't enable ByteCount. However
I tried that again and now it works from parts of my network, which is
obviously a network problem. What is so weird is that it always works
reliable if I print to file and then queue the resulting file using the LPR
command line. Does the command line LPR work differently (use different
ports, etc) than Standard TCP/IP printing over LPR?

Alan Morris said:
Does this work if you print using the Standard TCP/IP Port? You have to
manually configure the port to LPR mode and Byte Count enabled. The queue
name is the share name on the machine suppling LPD.

I'll assume you have disabled the firewall on the XP LPD target. XP sets
the service to manual start. You will need to change this to automatic if
you need this on all the time. After, of course, we get this working for
you.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

Siggi Bjarnason said:
You are exactly right. The target is another WinXP box running print service
for unix (i.e. lpd).

:

When using LPR Ports the port name format will appear as 10.10.10.10:HPOJ
and you get a "there is nothing to configure" if you attempt to configure
port.

Is the target a print server device or another machine running the LPD
service?

This works fine just need to get some more information.
--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

message I have a bit of problem with LPR printing on one of my machines
that
is
puzzling me. I can print without a problem using LPR from this box
as
long
as
I use the command line to spool the job. The following command
works
just
fine:

lpr -S10.10.10.10 -PHPOJ file.txt

However when I create a new LPR port specifying the same values
and
try to
print the same text file from Notepad the job just sits in the
local
queue
and never seem to get spooled to the server (verified with
lpq -S10.10.10.10
-PHPOJ) and eventually the queue goes into an error state.

What am I missing?
 
G

Guest

While on a network where I can reproduce this issue I printed a test page
(using the test page feature in the property dialog) and I also printed a
text file from notepad. The the job eventually error out so I cancelled both
jobs. Here is the spool directory after submitting both jobs and after
cancelling both jobs:
C:\WINDOWS>dir C:\WINDOWS\system32\spool\PRINTERS
Volume in drive C has no label.
Volume Serial Number is 04C8-2E56

Directory of C:\WINDOWS\system32\spool\PRINTERS

10/14/2005 02:37 AM <DIR> .
10/14/2005 02:37 AM <DIR> ..
10/14/2005 02:35 AM 2,700 FP00000.SHD
10/14/2005 02:35 AM 76,804 FP00000.SPL
10/14/2005 02:37 AM 2,744 FP00001.SHD
10/14/2005 02:37 AM 6,179,676 FP00001.SPL
10/14/2005 02:35 AM 204,107 Tcp89.tmp
5 File(s) 6,466,031 bytes
2 Dir(s) 26,948,591,616 bytes free

C:\WINDOWS>dir C:\WINDOWS\system32\spool\PRINTERS
Volume in drive C has no label.
Volume Serial Number is 04C8-2E56

Directory of C:\WINDOWS\system32\spool\PRINTERS

10/14/2005 02:37 AM <DIR> .
10/14/2005 02:37 AM <DIR> ..
10/14/2005 02:37 AM 0 FP00000.SHD
10/14/2005 02:37 AM 0 FP00000.SPL
10/14/2005 02:37 AM 0 FP00001.SHD
10/14/2005 02:37 AM 0 FP00001.SPL
4 File(s) 0 bytes
2 Dir(s) 26,955,087,872 bytes free


Alan Morris said:
I agree that is strange. There might be some DNS hostname resolution issue
involved. Lpr.exe uses lprhelp.dll for most of the functions. Lprmon.dll
loaded in spooler uses the same lprhelp.dll for most of the same functions.

Lpr.exe in default configuration will send the data out using ports
721 -731. Standard TCP/IP Port will send data out port 1025 and above.
Some LPD service implementations will only accept data if the source ports
are 721 -731. I have only seen this with UNIX and Linux. Windows and all
the printer NICs I have ever tested accept data from any source port.

Lpr.exe and LPR Port will send a data file informing the LPD service what
the incoming file size is. LPR Port calls the spooler and GDI to completely
render the job and creates a lprxxxx.tmp file in the spool directory to
determine how much data it will send to the LPD service. Lpr.exe just uses
the existing file size since the print job was already rendered.

When using LPR Port is the tmp file created? Standard TCP/IP port uses a
canned data file and tells the LPD service the incoming job is 4gig. This
works for most printers. Windows LPD does require an exact file size. When
enabling Byte Count on Standard Port, a Tcpxxxx.tmp file is created.


--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

Siggi Bjarnason said:
I had tried using Standard TCP/IP port but I didn't enable ByteCount. However
I tried that again and now it works from parts of my network, which is
obviously a network problem. What is so weird is that it always works
reliable if I print to file and then queue the resulting file using the LPR
command line. Does the command line LPR work differently (use different
ports, etc) than Standard TCP/IP printing over LPR?

Alan Morris said:
Does this work if you print using the Standard TCP/IP Port? You have to
manually configure the port to LPR mode and Byte Count enabled. The queue
name is the share name on the machine suppling LPD.

I'll assume you have disabled the firewall on the XP LPD target. XP sets
the service to manual start. You will need to change this to automatic if
you need this on all the time. After, of course, we get this working for
you.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

message You are exactly right. The target is another WinXP box running print
service
for unix (i.e. lpd).

:

When using LPR Ports the port name format will appear as
10.10.10.10:HPOJ
and you get a "there is nothing to configure" if you attempt to
configure
port.

Is the target a print server device or another machine running the LPD
service?

This works fine just need to get some more information.
--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

message I have a bit of problem with LPR printing on one of my machines that
is
puzzling me. I can print without a problem using LPR from this box as
long
as
I use the command line to spool the job. The following command works
just
fine:

lpr -S10.10.10.10 -PHPOJ file.txt

However when I create a new LPR port specifying the same values and
try to
print the same text file from Notepad the job just sits in the local
queue
and never seem to get spooled to the server (verified with
lpq -S10.10.10.10
-PHPOJ) and eventually the queue goes into an error state.

What am I missing?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top