Printing from Linux host fails LPDSVC: Event ID 4007. SimulatePassThrough ineffective

Well, this is really not a server, but this set of groups are
collectively perhaps the best place to ask this question.

I have a windows only printer that is attached to a windows machine
(Windows XP Professional SP 3).

I have followed this guide to redirect the port and set up a dummy
postscript printer to allow unix hosts to print:

http://iharder.sourceforge.net/curre...winmacprinter/

The two hosts are properly networked on the same subnet.

LPD service is running, and I have changed its scope to accept
connections only from the linux host.

Yes, port 515 is open and I can telnet to it.

In the Event Viewer, I have this persistent failure to accept print
jobs from the linux host:

Source: LPDSVC
Event ID: 4007
Type: Warning
Illegal format used for commands received from 192.168.0.1 : service refused

(192.168.0.1 is the linux host)

Correspondingly, the error on the linux host is
/usr/lib/cups/backend/lpd failed.

I have tried to add (a) SimulatePassThrough (1) and (b)
LpdPrinterPassThrough (1) keys to the registry using regedit:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servi ces\LPDSVC\Parameters
for the first one (a).
and the printer under \Control\ for the second one (b).

No use.

Retstarted spooler and lpdsvc. Rebooted. Restarted cups on the linux host.

No use.

Suggestions ? (No, buying a decent cross platform printer is out of the
question for the office, so I am stuck with this one.)

Geico Caveman wrote:
> Well, this is really not a server, but this set of groups are
> collectively perhaps the best place to ask this question.
>
> I have a windows only printer that is attached to a windows machine
> (Windows XP Professional SP 3).
>
> I have followed this guide to redirect the port and set up a dummy
> postscript printer to allow unix hosts to print:
>
> http://iharder.sourceforge.net/curre...winmacprinter/
>
> The two hosts are properly networked on the same subnet.
>
> LPD service is running, and I have changed its scope to accept
> connections only from the linux host.
>
> Yes, port 515 is open and I can telnet to it.
>
> In the Event Viewer, I have this persistent failure to accept print jobs
> from the linux host:
>
> Source: LPDSVC
> Event ID: 4007
> Type: Warning
> Illegal format used for commands received from 192.168.0.1 : service
> refused
>
> (192.168.0.1 is the linux host)
>
> Correspondingly, the error on the linux host is
> /usr/lib/cups/backend/lpd failed.
>
> I have tried to add (a) SimulatePassThrough (1) and (b)
> LpdPrinterPassThrough (1) keys to the registry using regedit:
>
> \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servi ces\LPDSVC\Parameters
> for the first one (a).
> and the printer under \Control\ for the second one (b).
>
> No use.
>
> Retstarted spooler and lpdsvc. Rebooted. Restarted cups on the linux host.
>
> No use.
>
> Suggestions ? (No, buying a decent cross platform printer is out of the
> question for the office, so I am stuck with this one.)
>

you may have better luck sharing the printer as a windows share and
setting up an smb client.

Hre is a guide as to how to do that shamelesslessly cribbed

Setting up a Linux client printing to a Linux Samba print server

All you need to do is activate the Cups admin GUI and install a printer
(not a physical printer), bearing in mind that you're printing to IP
address 192.168.2.2 where the queuename there is laserjet1020 (It's a HP
Laserjet 1020). The steps are, screen by screen, as follows:

* Open http://localhost:631 --> Administration --> Add Printer:
enter a printer name, say hpviasamba, no spaces, and optionally a
location and description.
* In Device for hpviasamba, select from the drop-down list Windows
printer via Samba.
* In Device URI, enter smb://workgroup/192.168.2.2/laserjet1020.
If you have restricted access to the server, you must add the
username and password in the URI; e.g.
smb://workgroup/usernameassword@192.168.2.2/laserjet1020.
You can use the NetBIOS name instead of the IP address in the
device URI but you need to have passed the browsing test that I gave
above for good Name Resolution.
* Select the printer manufacturer from list in cups database
* Select the printer model from list in cups database
* Click printers, click Configure Printer to set formatting settings
* On the Printers page, click Print Test Page to check connectivity



Or are you SURE the printer is 'windows only' I tend to attach printers
either direct to the network, or to the linux machines on it..and then
tal to them via either direct print or SMB if you want to set up samba
and make them look like 'windows printers'


Experience suggests the less you try and make windows smart, the better
luck you have.

On 2010-10-13 17:17:57 -0500, The Natural Philosopher
<> said:

>
> you may have better luck sharing the printer as a windows share and
> setting up an smb client.
>
> Hre is a guide as to how to do that shamelesslessly cribbed
>
> Setting up a Linux client printing to a Linux Samba print server
>
> All you need to do is activate the Cups admin GUI and install a printer
> (not a physical printer), bearing in mind that you're printing to IP
> address 192.168.2.2 where the queuename there is laserjet1020 (It's a
> HP Laserjet 1020). The steps are, screen by screen, as follows:
>
> * Open http://localhost:631 --> Administration --> Add Printer:
> enter a printer name, say hpviasamba, no spaces, and optionally a
> location and description.
> * In Device for hpviasamba, select from the drop-down list Windows
> printer via Samba.
> * In Device URI, enter smb://workgroup/192.168.2.2/laserjet1020.
> If you have restricted access to the server, you must add the
> username and password in the URI; e.g.
> smb://workgroup/usernameassword@192.168.2.2/laserjet1020.
> You can use the NetBIOS name instead of the IP address in the
> device URI but you need to have passed the browsing test that I gave
> above for good Name Resolution.
> * Select the printer manufacturer from list in cups database
> * Select the printer model from list in cups database
> * Click printers, click Configure Printer to set formatting settings
> * On the Printers page, click Print Test Page to check connectivity

For peculiar reasons, which are solid and will require a lot of
irrelevant explanations, I cannot use this as a Samba printer
(technically I can, but I do not want to, for very sound reasons).


>
>
>
> Or are you SURE the printer is 'windows only' I tend to attach printers
> either direct to the network, or

Oh please. Do you think I would inflict all this on myself if I was 1
million percent certain that this was not a pure windows printer ? Its
a Dell MFP 1125.

> to the linux machines on it..and then tal to them via either direct
> print or SMB if you want to set up samba and make them look like
> 'windows printers'
>
>
> Experience suggests the less you try and make windows smart, the better
> luck you have.


True, but lpd is the only option in this case.

Geico Caveman wrote:
> On 2010-10-13 17:17:57 -0500, The Natural Philosopher

>>
>> Or are you SURE the printer is 'windows only' I tend to attach
>> printers either direct to the network, or
>
> Oh please. Do you think I would inflict all this on myself if I was 1
> million percent certain that this was not a pure windows printer ? Its a
> Dell MFP 1125.

Ok, so connect it as a raw queue on Lunx, assuming it has parallel or
USB, and then export the raw queue as a direct socket: The windows
machines will use the correct drivers for the printer anyway.

It wont be useable from Linux, unless your write a printer definition,
but who cares? It never will be anyway.

Fundamentally, you have to appreciate that printer DRIVERS are in the
client machines. The print SERVER only pushes data to it.

If the client machine hasn't got a driver, the printer will never be
properly usable from that machine anyway, no matter which one its
plugged into.


Unless you fake up e,g. postscript to native emulation on the server.

Robert Heller wrote:
> At Thu, 14 Oct 2010 13:50:36 +0100 The Natural Philosopher <> wrote:
>
>> Geico Caveman wrote:
>>> On 2010-10-13 17:17:57 -0500, The Natural Philosopher
>>>> Or are you SURE the printer is 'windows only' I tend to attach
>>>> printers either direct to the network, or
>>> Oh please. Do you think I would inflict all this on myself if I was 1
>>> million percent certain that this was not a pure windows printer ? Its a
>>> Dell MFP 1125.
>> Ok, so connect it as a raw queue on Lunx, assuming it has parallel or
>> USB, and then export the raw queue as a direct socket: The windows
>> machines will use the correct drivers for the printer anyway.
>>
>> It wont be useable from Linux, unless your write a printer definition,
>> but who cares? It never will be anyway.
>>
>> Fundamentally, you have to appreciate that printer DRIVERS are in the
>> client machines. The print SERVER only pushes data to it.
>
> Except, that under Linux, a with a CUPS (or LPD in the old days) server,
> Linux *clients* just queue postscript and the server runs GhostScript
> to perform PS=>Printer Raster translation / filtering. I *think* the OP
> wants to implement this 'trick', but it is uncertain that MS-Windows
> will cooperate, since the 'native' printer language of MS-Windows is GDI
> and not PostScript. The OP will probably have to set up a psuedo queue
> on the MS-Windows box using a PostScript to GDI filter (can the
> MS-Windows port of GhostScript do this?) and then 'share' this psuedo
> queue with his Linux machine.
>
>> If the client machine hasn't got a driver, the printer will never be
>> properly usable from that machine anyway, no matter which one its
>> plugged into.
>>
>>
>> Unless you fake up e,g. postscript to native emulation on the server.
>
> Note that generally MS-Windows based printers don't export a postscript
> view of the printer and when they do, the usually 'driver' is going to
> be GhostScript which is also available under Linux.
>

Good clarification. It raises the question of whether this is ever going
to work: at some stage you need a converter from postcript to this printer.

If that's not available, its useless as a printer FROM linux.


>>
>

On 2010-10-14 07:50:36 -0500, The Natural Philosopher
<> said:

> Geico Caveman wrote:
>> On 2010-10-13 17:17:57 -0500, The Natural Philosopher
>
>>>
>>> Or are you SURE the printer is 'windows only' I tend to attach printers
>>> either direct to the network, or
>>
>> Oh please. Do you think I would inflict all this on myself if I was 1
>> million percent certain that this was not a pure windows printer ? Its
>> a Dell MFP 1125.
>
> Ok, so connect it as a raw queue on Lunx, assuming it has parallel or
> USB, and then export the raw queue as a direct socket: The windows
> machines will use the correct drivers for the printer anyway.
>
> It wont be useable from Linux, unless your write a printer definition,
> but who cares? It never will be anyway.
>
> Fundamentally, you have to appreciate that printer DRIVERS are in the
> client machines. The print SERVER only pushes data to it.
>
> If the client machine hasn't got a driver, the printer will never be
> properly usable from that machine anyway, no matter which one its
> plugged into.
>
>
> Unless you fake up e,g. postscript to native emulation on the server.

Yes. I have done that. Consult the URL I included.

On 2010-10-14 09:12:44 -0500, Robert Heller <> said:

> At Thu, 14 Oct 2010 13:50:36 +0100 The Natural Philosopher
> <> wrote:
>
>>
>> Geico Caveman wrote:
>>> On 2010-10-13 17:17:57 -0500, The Natural Philosopher
>>
>>>>
>>>> Or are you SURE the printer is 'windows only' I tend to attach
>>>> printers either direct to the network, or
>>>
>>> Oh please. Do you think I would inflict all this on myself if I was 1
>>> million percent certain that this was not a pure windows printer ? Its a
>>> Dell MFP 1125.
>>
>> Ok, so connect it as a raw queue on Lunx, assuming it has parallel or
>> USB, and then export the raw queue as a direct socket: The windows
>> machines will use the correct drivers for the printer anyway.
>>
>> It wont be useable from Linux, unless your write a printer definition,
>> but who cares? It never will be anyway.
>>
>> Fundamentally, you have to appreciate that printer DRIVERS are in the
>> client machines. The print SERVER only pushes data to it.
>
> Except, that under Linux, a with a CUPS (or LPD in the old days) server,
> Linux *clients* just queue postscript and the server runs GhostScript
> to perform PS=>Printer Raster translation / filtering. I *think* the OP
> wants to implement this 'trick', but it is uncertain that MS-Windows
> will cooperate, since the 'native' printer language of MS-Windows is GDI
> and not PostScript. The OP will probably have to set up a psuedo queue
> on the MS-Windows box using a PostScript to GDI filter (can the
> MS-Windows port of GhostScript do this?) and then 'share' this psuedo
> queue with his Linux machine.

Thanks for the response, but if you had followed the URL in the
original post, you would have seen that I have taken care of the
postscript at windows end by setting up a dummy printer and redirecting
ports. Please read the URL. The dummy printer prints postscript test
pages fine from within windows.

The issue is that windows LPDSVC, which expects certain characters in
postscript input is not seeing them (there are reports of this all over
the Internet). So, I need the windows LPD service to stop inserting
itself in the process and just pass the incoming file to the printer
itself. I have followed the commonly suggested registry hack, and it
does not work.

Why don't people read the *actual* question you pose, instead of diving
into the deep end of a pool of assumptions ?

Sigh.

On 2010-10-14 09:36:48 -0500, The Natural Philosopher
<> said:

>
> Good clarification. It raises the question of whether this is ever
> going to work: at some stage you need a converter from postcript to
> this printer.
>
> If that's not available, its useless as a printer FROM linux.

I have a humble request to make of you.

Please go back to the original question and *actually* read what I
wrote. Not skim, but *read*.

Geico Caveman wrote:
> On 2010-10-14 07:50:36 -0500, The Natural Philosopher
> <> said:
>
>> Geico Caveman wrote:
>>> On 2010-10-13 17:17:57 -0500, The Natural Philosopher
>>
>>>>
>>>> Or are you SURE the printer is 'windows only' I tend to attach
>>>> printers either direct to the network, or
>>>
>>> Oh please. Do you think I would inflict all this on myself if I was 1
>>> million percent certain that this was not a pure windows printer ?
>>> Its a Dell MFP 1125.
>>
>> Ok, so connect it as a raw queue on Lunx, assuming it has parallel or
>> USB, and then export the raw queue as a direct socket: The windows
>> machines will use the correct drivers for the printer anyway.
>>
>> It wont be useable from Linux, unless your write a printer definition,
>> but who cares? It never will be anyway.
>>
>> Fundamentally, you have to appreciate that printer DRIVERS are in the
>> client machines. The print SERVER only pushes data to it.
>>
>> If the client machine hasn't got a driver, the printer will never be
>> properly usable from that machine anyway, no matter which one its
>> plugged into.
>>
>>
>> Unless you fake up e,g. postscript to native emulation on the server.
>
> Yes. I have done that. Consult the URL I included.
>
Except it doesn't actually work, does it?

On 2010-10-14 12:08:26 -0500, The Natural Philosopher
<> said:

>>>
>>>
>>> Unless you fake up e,g. postscript to native emulation on the server.
>>
>> Yes. I have done that. Consult the URL I included.
>>
> Except it doesn't actually work, does it?

I do not know if you are being facetious here, but I would think that
anyone with basic comprehension skills would have gathered by now that
the problem lies with the LPD server on the windows XP machine, and not
with the postscript printer (which has been tested on windows XP).

If you have nothing to add, and only wish to troll on the basis of a
barely read post, feel free to do so, but I am currently more
interested in solving a problem, than in listening to you pontificate
about stuff that you clearly do not care to understand (I did not say
you can't understand, just not care to understand).

No offense is meant, but I would not care if any was taken. All I see
you doing is taking this thread astray with your preconceptions.