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 = [156]! [2003/06/16 14:03:48, 0, pid=6843] rpc_parse/parse_spoolss.c:spoolss_io_devmode(806) spoolss_io_devmode: please report to samba-technical@samba.org! [2003/06/16 14:03:48, 0, pid=6843] rpc_server/srv_spoolss.c:api_spoolss_open_printer_ex(76) 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 sharing, though.
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 structure.
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 adequate.
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.
database cleanup