Created attachment 10111 [details] tcp dump from windows 7 selftest print My Company migrated from Windows XP to Windows 7. All Laserprinters are configured to printout in duplex mode. Every thing was working fine with Windows XP. after the switch to Windows 7 the accounting of printed pages are wrong (this took a lot of money). After analyzing the problem, I saw the Windows 7 is creating the additioal blanks page. So I opened a call at MS. The supporter from Microsoft showed, that the problem is not on Microsoftside and it has something todo with "advanced-print-features". I asume there is something wrong on samba side, with the "advanced-print-features". So I created a set of logs and pcap with windows xp - working And one windows 7 - notworking In both scenarios I only open the printerproperties from a windows client and clicked the testpage-button. on window xp - one page is created on windows 7 - 2 pages are created this behaviour is on all samba 3.6/4.0 and 4.1 but 3.6 is my production version in cause of a enterprise distro
Created attachment 10112 [details] log.smb from windows 7 selftest print
Created attachment 10113 [details] tcp dump from windows xp selftest print
Created attachment 10114 [details] log.smb from windows xp selftest print
I forgot to mention, the printerdriver is created via cupsaddsmb! No special vendor drivers! only the well known dll's.
The first network trace doesn't have any spoolss commands. However I found the following in the log file. [2014/07/16 15:08:45.266114, 10, pid=519] printing/printing.c:446(print_job_find) print_job_find: looking up job 13 for share cobp0708 [2014/07/16 15:08:45.266163, 10, pid=519] printing/printing.c:474(print_job_find) print_job_find: returning system job -1 for jobid 13. Maybe we need to handle -1 here in a different way.
I looked in both log-files for "job -1" and found it in both. ( -> grep -P2 -A2 "job -1" printselftest_windowsxp_working.log >printselftest_windowsxp_working2.log grep -P2 -A2 "job -1" printselftest_windows7_notworking.log >printselftest_windows7_notworking2.log) this could not be the problem ... there was only a little difference, but I am not a expert :-( sdiff printselftest_windowsxp_working2.log printselftest_windows7_notworking2.log with a private section of 2020 bytes | print_job_find: looking up job 13 for share cobp0708 [2014/07/16 15:09:52.261612, 10, pid=18668] printing/printing | [2014/07/16 15:08:43.835793, 10, pid=519] printing/printing.c print_job_find: returning system job -1 for jobid 14. | print_job_find: returning system job -1 for jobid 13. [2014/07/16 15:09:52.261805, 8, pid=18668] printing/printing | [2014/07/16 15:08:43.835827, 5, pid=519] printing/printing.c Packed devicemode [Letter] < -- < with a private section of 2020 bytes < [2014/07/16 15:09:52.660177, 10, pid=18668] printing/printing < print_job_find: returning system job -1 for jobid 14. < [2014/07/16 15:09:52.660210, 5, pid=18668] printing/printing < get_stored_queue_info: total_count = 1 get_stored_queue_info: total_count = 1 -- -- with a private section of 2020 bytes | print_job_find: looking up job 13 for share cobp0708 [2014/07/16 15:09:52.813397, 10, pid=18668] printing/printing | [2014/07/16 15:08:43.937942, 10, pid=519] printing/printing.c print_job_find: returning system job -1 for jobid 14. | print_job_find: returning system job -1 for jobid 13. [2014/07/16 15:09:52.813429, 5, pid=18668] printing/printing | [2014/07/16 15:08:43.937979, 5, pid=519] printing/printing.c get_stored_queue_info: total_count = 1 get_stored_queue_info: total_count = 1
Created attachment 10125 [details] Additional trace from windows 7 I made a additional trace. Maybe there is something helpfull inside.
Created attachment 10126 [details] Additional trace from windows 7 log.smb
(In reply to comment #5) > The first network trace doesn't have any spoolss commands. > > However I found the following in the log file. > > [2014/07/16 15:08:45.266114, 10, pid=519] > printing/printing.c:446(print_job_find) > print_job_find: looking up job 13 for share cobp0708 > [2014/07/16 15:08:45.266163, 10, pid=519] > printing/printing.c:474(print_job_find) > print_job_find: returning system job -1 for jobid 13. > > Maybe we need to handle -1 here in a different way. Hmm, old style (non-spoolss) print job via file IO? We had a bug in the non-spoolss jobid tracking code-path in the past that was fixed. I'll take a closer look when get through my post-vacation backlog.
Created attachment 10134 [details] 3rd tcp dump from windows 7 selftest print Here the third try with windows 7. 1) I rebooted the client. 2) connected the server 3) navigated to the \\<hostname>\printer 4) opened properties of the printer 5) clicked on selftest 6) closed the properties Is it possible, that the client caches all driversettings on the client?
Created attachment 10135 [details] 3d log.smb from windows 7 selftest print
Created attachment 10138 [details] 4th tcp dump from windows 7 selftest print You was completely right! :-( my tcpdump was wrong! Now, I have done: tcpdump -p -s 0 -w printselftest_windows7_notworking4.pcap host 10.128.58.43
Created attachment 10139 [details] eth log.smb from windows 7 selftest print
Created attachment 10140 [details] 2nd tcp dump from windows xp selftest print I also created new captures from WinXP
Created attachment 10141 [details] 2nd log.smb from windows xp selftest print
This issue appears to be the result of client-driver behaviour, rather than a bug in the Samba spoolss server. On Windows XP the client dispatches the document as a single page job: - Attachment#10140 [details], frame 1738 shows a single StartPagePrinter spoolss request - Attachment#10140 [details], frame 1938, offset 0x0380 shows a "%%Pages: 1" token in the raw CUPS print job data. On Windows 7 the client dispatches the document as a two page job: - Attachment#10138 [details], frame 938 shows the first StartPagePrinter request - Attachment#10138 [details], frame 1220, offset 0x0980 shows a "%%Pages: 2" token in the raw CUPS print job data. - Attachment#10138 [details], frame 1225 shows the second StartPagePrinter request
You are may be right! I had the same opinion for month so I opend a call at MS. I know the empty page is created on the windows client. I tried to reproduce the problem with a local printer on a Windows 2008 R2 server. I created a Printer called PostScriptTest with a Xerox Phaser 6180DN PS. This driver uses the same dll's as the cupsaddsmb driver. The port was configured as "FILE:". So all printout are redirected to file. With this setup I could reproduce the problem, odd printjobs created a additional page. the MS-Hotline detected my missconfiguraiton. I have to disable the "advanced printer features". here the original text: Ich konnte den Code Pfad identifizieren der das Problem verursacht. Im winprint Print Prozessor wird bei einer ungeraden Seitenanzahl und aktiviertem Duplex eine Blank Page gedruckt. Dieser Code Pfad wird nur durchlaufen wenn der Druckjob zuerst als EMF gespeichert und dann in RAW umgewandelt wird. Deshalb tritt das Problem nicht auf wenn die Advanced Printing Features nicht selektiert sind. In diesem Szenario wird der Druckjob sofort als RAW gerendered ohne den Druckprozessor anzusprechen. Eine Änderung des betroffenen Codepfads ist nach Rücksprache mit unserem Development nicht möglich. Wir haben deshalb die beiden Lösungsmöglichkeiten gesprochen: 1. Verwenden aktueller Hersteller Treiber. Sie werden prüfen ob von Canon aktuelle Druckertreiber angeboten werden die auf die Microsoft pscript5.dll aufsetzen. 2. Abschalten der Advanced Printing Features Beachten sie hierzu folgende Hintergrundinformationen: http://blogs.technet.com/b/askperf/archive/2007/10/23/disabling- advanced-print-features.aspx Sie werden prüfen ob diese Möglichkeit umgesetzt werden kann. I know this has something to do with: printprocessor:winprint-standardtyp:RAW-Advanced Printing Features. could there be something wrong?
(In reply to comment #17) > You are may be right! > > I had the same opinion for month so I opend a call at MS. I know the empty page > is created on the windows client. > > I tried to reproduce the problem with a local printer on a Windows 2008 > R2 server. > > I created a Printer called PostScriptTest with a Xerox Phaser 6180DN > PS. This driver uses the same dll's as the cupsaddsmb driver. > The port was configured as "FILE:". So all printout are redirected to > file. With this setup I could reproduce the problem, odd printjobs > created a additional page. > > the MS-Hotline detected my missconfiguraiton. I have to disable the > "advanced printer features". > > here the original text: > > Ich konnte den Code Pfad identifizieren der das Problem verursacht. Im > winprint Print Prozessor wird bei einer ungeraden Seitenanzahl und > aktiviertem Duplex eine Blank Page gedruckt. > Dieser Code Pfad wird nur durchlaufen wenn der Druckjob zuerst als EMF > gespeichert und dann in RAW umgewandelt wird. > Deshalb tritt das Problem nicht auf wenn die Advanced Printing Features > nicht selektiert sind. In diesem Szenario wird der Druckjob sofort als > RAW gerendered ohne den Druckprozessor anzusprechen. > Eine Änderung des betroffenen Codepfads ist nach Rücksprache mit > unserem Development nicht möglich. > > Wir haben deshalb die beiden Lösungsmöglichkeiten gesprochen: > 1. Verwenden aktueller Hersteller Treiber. Sie werden prüfen ob > von Canon aktuelle Druckertreiber angeboten werden die auf die > Microsoft pscript5.dll aufsetzen. > 2. Abschalten der Advanced Printing Features > Beachten sie hierzu folgende Hintergrundinformationen: > http://blogs.technet.com/b/askperf/archive/2007/10/23/disabling- > advanced-print-features.aspx > Sie werden prüfen ob diese Möglichkeit umgesetzt werden kann. > > I know this has something to do with: > > printprocessor:winprint-standardtyp:RAW-Advanced Printing Features. > > could there be something wrong? If I understand this correctly, MS are aware of the EMF->RAW job conversion Windows client bug, but don't intend to fix it. I don't think there's anything that can be done on our side. Samba doesn't offer support for EMF print jobs.
When I start to analyze the problem I had the same opinion as you. But after the discussion with the the Supporttechnician from MS, I think there is also something strange with the printing part of Samba. Samba should work as a "drop-in replacement" for a Windows File/Printserver. This mean, when the "advanced-print-features" are disable, Samba should work like a Windowsprintserver. Maybe there is something wrong with the negotiation of the printing behaviour ("advanced-print-features"). The Client should never create anything with EMF when everything works normal. Is there a way to connect the MS-Engineers with the Samba-Engineers? regards Franz
(In reply to comment #19) > When I start to analyze the problem I had the same opinion as you. > > But after the discussion with the the Supporttechnician from MS, I think there > is also something strange with the printing part of Samba. > > Samba should work as a "drop-in replacement" for a Windows File/Printserver. > > This mean, when the "advanced-print-features" are disable, Samba should work > like a Windowsprintserver. > > Maybe there is something wrong with the negotiation of the printing behaviour > ("advanced-print-features"). > The Client should never create anything with EMF when everything works normal. The getprinter requests in your traces are returning both RAW as the datastream type, and the "raw only" attribute, which is usually how a print server is indicating that advanced printing is not supported. Can you verify on windows7 what state the printer says about advanced printing?
Hello Jim, Thanks for your reply! How should I check it? Like this: See attachment. Regards Franz -----Ursprüngliche Nachricht----- Von: samba-bugs@samba.org [mailto:samba-bugs@samba.org] Gesendet: Donnerstag, 31. Juli 2014 13:27 An: Pförtsch, Franz Betreff: [Bug 10721] Printing single pages on a duplex printer creates additional blank pages https://bugzilla.samba.org/show_bug.cgi?id=10721 Jim McDonough <jmcd@samba.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO --- Comment #20 from Jim McDonough <jmcd@samba.org> 2014-07-31 11:27:16 UTC --- (In reply to comment #19) > When I start to analyze the problem I had the same opinion as you. > > But after the discussion with the the Supporttechnician from MS, I > think there is also something strange with the printing part of Samba. > > Samba should work as a "drop-in replacement" for a Windows File/Printserver. > > This mean, when the "advanced-print-features" are disable, Samba > should work like a Windowsprintserver. > > Maybe there is something wrong with the negotiation of the printing > behaviour ("advanced-print-features"). > The Client should never create anything with EMF when everything works normal. The getprinter requests in your traces are returning both RAW as the datastream type, and the "raw only" attribute, which is usually how a print server is indicating that advanced printing is not supported. Can you verify on windows7 what state the printer says about advanced printing? -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Created attachment 10166 [details] cups_printer_properties_advanced.png
Created attachment 10167 [details] Printerproperties Advanced Tab german
Comment on attachment 10166 [details] cups_printer_properties_advanced.png Printer properties advanced tab (german)
I got it! since Windows 7 the printerdialog has changed. one additional entry is in the printers properties dialog available. here is the path: * printer driver properties -> advanced tab ("Enable advanced printing features" disabled) * Printing Defaults ... -> Advanced ... ** as default there are now three additional parameters: Advanced Printing Features: Enabled Pages per Sheet Layout: Right then Down Booklet Binding Edge: On Lefte Edge ** when "Advanced Printing Features:" is set to disable, the other two parameters are greyed out and the additional blank page is not printed. Maybe this parameter should be hidden, when the "advanced printing features" are disabled or the checkbox "Advanced Printing Features" should be disabled. could someone check this analysis? Is there anything helpful possible? Very strange is, the user standardsettings are changed to "Advanced Printing Features" enable. It is a hardwork to force the user to disable this setting.
Created attachment 10192 [details] Printer Propeties Advanced Printing Defaults
Created attachment 10193 [details] Printer Propeties Advanced
Created attachment 10194 [details] Printer Propeties Advanced Printing Defaults Advanced Options Enabled
Created attachment 10195 [details] Printer Propeties Advanced Printing Defaults Advanced Options Disabled
It seems there are two bugs here on the windows side: first, the EMF->RAW conversion, which they admit is causing the extra page, that they will not fix. The workaround they are posting is displaying another bug, which is that they are not properly detecting that the network printer queue (in this case, samba) is not even offering EMF, and therefore cannot be counted on for Advanced Printing Features. I fail to see what Samba can do if Microsoft is simply refusing to change the client behavior. We would welcome them to work with us, and it's quite easy for them to contact us as an open source project. Unfortunately, we don't have the same access to their developers. I'm unfortunately only left with closing the bug as invalid, because the bugs are on the windows 7 client.