Created attachment 8330 [details]
packet capture of printing attempt

We have an Ubuntu 8.04 server running Samba 3.6.4, acting as a print server for Windows clients. Recently several Windows 7 systems (which used to work) have become unable to print via the print server.

I have also reproduced the problem using a test setup consisting of an Ubuntu 12.04 workstation running Samba 3.6.10.

We're using local printer drivers on the clients, and they are are set up to print to a "local port" of the form \\servername\printsharename. The SMB connection between the clients and servers is working normally, and they are able to browse file shares successfully. When the clients print to the network print queues the job is transferred to the Samba server successfully, and the client behaves as though everything has worked, but no printout appears from the printer. An orphaned "smbprn.XXXXXX" file is left behind in the Samba spool directory. If this file is manually submitted to CUPS using the "lp" command then it prints as expected.

I attach a tcpdump packet trace of an unsuccessful attempt to send a Windows printer test page to the test server running Samba 3.6.10, and a level 10 log.smbd file corresponding to this.

It appears to me that the client opens the printer, sends the data, then just before it closes the connection does a "spurious" second open and close of the same printer (request/responses in packets 226-231), and only then closes the FID associated with the initial open (request in packet 232). And Samba fails to find the printer handle associated with the main print transaction at this point (log.smbd messages around timestamp 15:37:52.109) - I'm guessing that some internal state on the Samba side has been "stepped on" by the clients second nested open/close of the same printer?

I have a tentative hypothesis (which I haven't been able to prove yet) that a recent Windows update has changed the client side behaviour. The clients which are exhibiting the problem are laptops which get updates on the fly from the Windows update servers. Other Windows 7 clients that get updates via our local managed update server haven't started exhibiting the problem yet.