Bug 9490 - Recently updated Windows 7 clients fail to print
Summary: Recently updated Windows 7 clients fail to print
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Printing (show other bugs)
Version: 3.6.10
Hardware: All Linux
: P5 normal
Target Milestone: ---
Assignee: printing-maintainers
QA Contact: Samba QA Contact
Depends on:
Reported: 2012-12-10 16:23 UTC by Neil Hoggarth
Modified: 2021-01-08 00:25 UTC (History)
0 users

See Also:

packet capture of printing attempt (252.24 KB, application/vnd.tcpdump.pcap)
2012-12-10 16:23 UTC, Neil Hoggarth
no flags Details
level 10 debug log (1.99 MB, application/octet-stream)
2012-12-10 16:24 UTC, Neil Hoggarth
no flags Details
smb.conf file from the test server (244 bytes, application/octet-stream)
2012-12-10 16:31 UTC, Neil Hoggarth
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neil Hoggarth 2012-12-10 16:23:25 UTC
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.
Comment 1 Neil Hoggarth 2012-12-10 16:24:22 UTC
Created attachment 8331 [details]
level 10 debug log
Comment 2 Neil Hoggarth 2012-12-10 16:31:37 UTC
Created attachment 8332 [details]
smb.conf file from the test server
Comment 3 Björn Jacke 2021-01-08 00:25:08 UTC
this is working with more recent samba versions