The Samba-Bugzilla – Bug 178
Failure parsing devmode causes all RPC printing to fail
Last modified: 2005-11-14 09:24:27 UTC
I've an installation here with a Windows 2000 client printing to a Samba queue
that is then serviced by CUPS. The client is using the CUPS Windows print
driver, although that does not seem to make a difference.
Most applications we can print from just fine, but if we try to print a complex
document from Microsoft Publisher 2000, Publisher reports an error and the
following errors appear in the Samba log.
[2003/06/16 14:03:48, 0, pid=6843] rpc_parse/parse_spoolss.c:spoolss_io_devmode(803)
spoolss_io_devmode: I've parsed all I know and there is still stuff left|
[2003/06/16 14:03:48, 0, pid=6843] rpc_parse/parse_spoolss.c:spoolss_io_devmode(805)
spoolss_io_devmode: available_space = [-64], devmode_size = !
[2003/06/16 14:03:48, 0, pid=6843] rpc_parse/parse_spoolss.c:spoolss_io_devmode(806)
spoolss_io_devmode: please report to firstname.lastname@example.org!
[2003/06/16 14:03:48, 0, pid=6843]
spoolss_io_q_open_printer_ex: unable to unmarshall SPOOL_Q_OPEN_PRINTER_EX.
[2003/06/16 14:03:48, 0, pid=6843] rpc_server/srv_pipe.c:api_rpcTNP(1486)
api_rpcTNP: spoolss: SPOOLSS_OPENPRINTEREX failed.
Once this has occurred, that particular smbd process can no longer hande
printing requests at all; we can't even view the status of any printers or print
to other Samba queues. Logging out of the Windows machine (thus closing the
session and killing the smbd process) and the logging back in cures the problem,
until we try to print that document again.
The document can be printed successfully to the same printer (using the same
driver) if we go directly to CUPS, however. We'd prefer to use Samba printer
Hi Kevin. Can you post a level 10 debug (just add 'debug level = 10' to your
smb.conf file) of the devicemode in question? The parsing of the device mode
should start with the string "spoolss_io_devmode".
There's probably some flag that we aren't parsing correctly in the device mode
Created attachment 31 [details]
Level 10 debug log of problem occurring
The log was much longer than this, of course, but I included only from the PIPE
spoolss being requested to the error being returned... hopefully that will be
Created attachment 34 [details]
fix devmode parsing on bad sizes
Just attached a patch that should atleast cause us not to
bail out. The devmode size looks wrong though. Maybe a bug
in the application.
Created attachment 35 [details]
Updated log after applying posted patch
Sorry to say, the patch supplied does not allow samba to get past the problem.
Here is a new level 10 log created with the patch in place.
marking bug reopened since proposed patch did not solve the problem (updated log
previously attached to bug)
Just an update, problem still appears in 3.0.0beta2
After studying the updated log I have to agree with Jerry that the devmode size
looks wrong. A size of 0x9c puts the size of the devicemode somewhere in the
middle of the form name which is not right.
You could try commenting out the "if (available_space)" block in
rpc_parse/parse_spoolss.c and see if that fixes things. You might run in to
trouble with the extra printer data (the 0x37c bytes in the driverextra field)
but if it is just the size field that is wrong it could work.
I have to concur with the cop out answer "application bug" though - sorry.
This might be too much effort to test out, but does it work if you print with
the printer connected to a Windows print server?
I believe we have already tested it with the printer on a Windows print server,
but the server was Windows 98 so didn't use RPC printing. I can test with the
printer attached to a Windows 2000 server in the next day or two.
I will also try commenting out the offending line in the code.
The user has been printing to this printer on the same Linux server through CUPS
without problems, but then that's an entirely different protocol (IPP). We want
to switch over to using Samba printing so we can have automatic driver download
and easier queue management... too bad this application is buggy.
don't believe this is our fault.
originally reported against 3.0.0beta2. CLeaning out
non-production release versions.