Windows Network Printing Connection Timeouts - Lion Specific

This hit the nail right on the head for me. Changing the samba password on the samba server in question to an alphanumeric one (how's that for Windows security) cleared the problem right up. Glad I don't share files on that server :-P

This solved our issue - many thanks for it 🙂

I am on a windows / exchange 2007 network, with Lion (up to 10.7.3), username and password login and a proxy server. We use HP printers (perfect) as well as Canon printers (image running advance 5051, 8085, 3080).

Canon printers are connecter through LPD protocol (IP address, as well as HP printers), and work with UFR2 drivers (printers are not set up to be compatible with Postscript). I can print but... it takes at least 10 seconds of rainbow wheel until the job is sent to the printer. It is also the same when printing to PDF, when a Canon printer is set as default printer. Little snitch shows that mcc.app (located in UFR driver folder in Library/Printers) is active and connects to the printer.

With 2.25 UFR2 drivers, preview and textedit would freeze (and crash) when printing. Canon issued 2.30 drivers that solved this problem and now, preview and textedit print fast (the job is sent immediately to the printer, 1 sec. but still not as fast as with 10.6.8). With all other apps (outlook, safari, firefox, word, excel, etc.) I get the rainbow wheel for 10-15 seconds. It looks like it depends on how many documents I print the one after the others.

Finally, I noticed while using goggle chrome that printing is fast and immediate when printing through chrome interface, but still slow with canon driver interface.

Thus, I think (at my level, I am just a user) that Apple replaced Samba with something else which works in a different way, supposed to be compatible but in fact and that does not work well (with canon drivers?) (I did not try with the generic driver but if I use such driver I would loose all printing options). It is really annoying...

Alexis

alexis117 wrote:

Thus, I think (at my level, I am just a user) that Apple replaced Samba with something else which works in a different way, supposed to be compatible but in fact and that does not work well (with canon drivers?) (I did not try with the generic driver but if I use such driver I would loose all printing options). It is really annoying...

The Canon drivers do not support SMB (Samba) connections. As you have stated, you created the print queues using LPD, not SMB.

And you would only be able to use the Generic PS driver if the Canon's had the Postscript kit installed. For the ADVANCE models you have, this is an option. For some regions, the 3080 has Postscript as a standard inclusion. If all the Canon's do support Postscript, then I suggest you use the Canon PS v3.20 driver rather than the UFR2 driver. Or even the Canon PPDs, which do give you most of the full driver features. One benefit of using the PPD is that there is no additional Canon filters or resources used to create and submit the spool file. So if the Mac still delays for 10+ seconds when using the PPD then this would indicate that it is system related rather than a driver issue.

Thank you

understood (about SMB / LPD).

I have installed the PS PPD 3.15 driver this morning and yes, it works quite well with Canon iR-ADV C5051 printer, despite the configuration screen is quite different and offers less options. However, all Canon printers we have here are not compatible with PS. We tested the PS PPD Driver with Canon iR-ADV C8085 or ex. and it does not work at all.

What's the matter with UFR2 driver (apart from the fact that it is a Canon standard)?

alexis117 wrote:

I have installed the PS PPD 3.15 driver this morning and yes, it works quite well with Canon iR-ADV C5051 printer, despite the configuration screen is quite different and offers less options.

The PPD does lack features like Job Accounting, Booklet, Secure Print and Mailbox compared to the PS driver, and yes the printer panes are text based rather than pretty Windows-like graphics, but the PPD requires no additional plugins or resources that can add load to a Mac.

However, all Canon printers we have here are not compatible with PS. We tested the PS PPD Driver with Canon iR-ADV C8085 or ex. and it does not work at all.

So this would indicate that the PS kit (license) was not ordered which is crazy. The company spends a stack of money on a high-end 80+ ppm copier and does not spend just a bit more to get the PS option, which would guarantee better performance. Still it is even crazier that PS is an option on such an expensive machine.

Not that long ago it was imperative that a printer for a Mac had Postscript. This was a perfect match for desktop publishing and production print runs.

Now with proprietary printer languages like UFR2, these high-end machines often perform no better than personal laser printer or inkjet. This is due to the UFR2 driver requiring additional plugins, like the mcc.app you mention previously and its supporting Backgrounder service, which can cripple a Mac - especially one that is already on the edge of having insufficient to run OS X.

Another con is that it's impossible to get the UFR2 driver installed and shared from OS X server, or even a Windows server to Mac client. The UFR2 services require a direct connection from the Mac to the printer which is not a great way to control or monitor network printing.

And the biggest problem with the UFR2 driver is forward compatibility. For the last three OS X releases, the then current UFR2 driver did not function at all or operated with limitations on the new OS. So in a couple of years time when you upgrade the Mac's to 10.8 the day that it is released there is about a 90% chance that the current UFR2 driver won't work on the new OS. And if history repeats, Canon will take about 3 to 4 months to get a new version of the driver out to the public. But if you had the Postscript kit in the printer, then even if the then current Canon Postscript driver had a problem with the new feline, you could use the Canon PPD or even the Generic PS included with the OS to continue printing, while others with a UFR2-only device jumped on the forums and shared their woes about upgrading without checking that their peripherals still functioned.

So that's just a small summary of the issues I have with the UFR2 driver.

I've analyzed the problem scenarios I've encountered at my institution, and can report the following findings:

A conspicuous symptom is going to print a web page, click the Print button - and nothing happens: the print dialog just sits there. (This, in feeding a Windows 2008 print server, requiring authentication.) A look at the CUPS error_log shows a backend 256 error. This is a CUPS environment issue, rather than OS X itself.

In OS 10.6, when a printer is defined via the usual OS X System Preferences GUI (Advanced tab, "Windows"), it ends up with a CUPS option of "auth-info-required=none" (seen via command 'lpoptions -p <PrinterName>'). Going to print in 10.6 in the same Windows authentication environment, one clicks the Print button and the interaction then proceeds, the job going into the print queue; thereafter one has to Resume the job in that queue to get a pop-up authentication dialog, where one would enter "Domain/Username" and Password (and save in Keychain). CUPS then dynamically changes the printer option to be "auth-info-required=username,password" upon realizing that reality.

In OS 10.7, when a printer is defined the same way, it ends up with the option "auth-info-required=negotiate", which is for Kerberos - which does not play a part in this Mac environment. Depending upon the phase of the moon, CUPS may eventually get by this and finally put the job into the print queue and allow authentication to proceed (CUPS then sets the printer option to "auth-info-required=username,password"). Sometimes it remains stuck. I've found that when the stuck situation persists, I can do 'lpadmin -p <PrinterName> -o auth-info-required=username,password' to set what CUPS should ultimately set into /etc/cups/printers.conf, and then the printing works.

The other nuisance in printing through a Windows server is jobnames being "Remote Downlevel Document". I crafted a correction via software which inspects the PostScript job prolog to get the original name from the %%Title line, and substitute that as the correct job name, which has solved that issue for us.

Thank you Alan. I should have realized this myself after dealing with something like this on my NAS.

Glad it worked for you. Thanks for letting me know.

Hey this solution was awesome... 4 years I've been unable to print from mac across windows. Admittedly a little lazy but even so, thanks =]

Good to hear!