Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

CUPS as printserver for Windows clients doesn't print

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
kmeriksen
Posts: 9
Joined: 2014-03-17 12:57

CUPS as printserver for Windows clients doesn't print

#1 Post by kmeriksen »

This problem has driven me mas for weeks now. I want to use a Debian 9.3 64 bit as printserver (among other things) for a number of windows 10 clients (64 bit). All systems are fully updated as of today.

CUPS is running well om the Debian machine and I can print without problems. The printer is shared. On Windows 10 I install the printer using http://10.0.0.100:631/printers/HP-3020-Servus as port and it is easily found. Fresh 64 bit driver from HP installed on Windows. All is fine until I ask Windows to print a test page - it goes direct into Error status. However in the CUPS access_log things looks nice:

Code: Select all

10.0.0.35 - - [11/Jan/2018:15:39:37 +0100] "POST /printers/HP-3020-Servus HTTP/1.1" 426 148342 Print-Job successful-ok
Windows claims the test page is 144 kB so that looks about right. Error_log has nothing at all.

Everything is fine - except the printer doesn't print anything. It's really driving me crazy!

shep
Posts: 423
Joined: 2011-03-15 15:22

Re: CUPS as printserver for Windows clients doesn't print

#2 Post by shep »

There can be an issue where your print job is filter'd twice. See https://forums.freebsd.org/threads/53725/#post-302146 and the referenced Fedora bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1010580.

From the Fedora bug report:

Code: Select all

 Tim Waugh 2013-09-24 07:44:21 EDT

192.168.160.9 is sending invalid application/vnd.cups-raster data.

How is that client configured? It seems to be running filters locally before sending the job to the CUPS server, but that's not the best way to do things and seems to be causing a problem here.

Rather than setting a driver for the remote printer, it should just send the data it gets from the application... in other words, it should be a 'raw' queue.
Is it possible to send the Windows print job as "raw"?

Edit: Add IPP/Samba options below:

Other work arounds are set up a dummy IPP printer or to set up Samba printing. See this Arch Linux wiki
https://wiki.archlinux.org/index.php/CU ... er_sharing

kmeriksen
Posts: 9
Joined: 2014-03-17 12:57

Re: CUPS as printserver for Windows clients doesn't print

#3 Post by kmeriksen »

Is it possible to send the Windows print job as "raw"?
Yes. In the Advanced tab you can select Print Processor, which is set as RAW by default.

I have tried to make my setup at an other site with different hardware but the same software and got the same result (everything looks OK, but no print).

However now I've had a bit of luck and got my initial setup to work as expected. I'm unsure why. I only thing I can think of, is that I switched to the HP Universal PS Print Driver for Windows 10 and switched to PS in CUPS too. BTW, it's a bit hard to find the HP Universal PS driver. HP wants to push the Universal PCL driver.

The whole thing seems a bit shaky. I'm looking into compiling CUPS 2.2.6 to replace 2.2.1. It looks doable.

shep
Posts: 423
Joined: 2011-03-15 15:22

Re: CUPS as printserver for Windows clients doesn't print

#4 Post by shep »

Most applications generate print command outputs as postscript and, according to OpenPrinting, the HP 3020 is postscript capable:
http://www.openprinting.org/printer/HP/HP-LaserJet_3020

With a postscript capable printer, your print job can be sent directly to the printer.
postscript ----debian cups spooler ---> postscript capable printer
HP was able to produce cheaper printers using PCL (Printer Command Language) and in order for those printers to work, the postscript job has to be "filter'd":
postscript ---debian cups filter ----> pcl ---debian cups spooler---> pcl capable printer
The spooler part queues the print job and sends to the printer when the printer is ready.

There are other filters and according to the OpenPrinting page I linked, the hplip driver, for your printer, uses a "raster converter" filter.
These are set by the ppd, usually by a code line in the ppd that talks about a raster converter:
https://www.cups.org/doc/raster-driver.html
Where you can get in trouble is if your Windows machine "filters" the print job, sends it over the network, to your linux cups printer which is expecting postscript.

Windows postscript ---windows filter---> pcl ------> network ----//--> debian cups expecting postscript but gets pcl.

If you have raw output from Windows:
Windows postscript ---no filter (aka "raw") ---> postscript ------> network ------> debian cups gets postscript and should print.

kmeriksen
Posts: 9
Joined: 2014-03-17 12:57

Re: CUPS as printserver for Windows clients doesn't print

#5 Post by kmeriksen »

Shep, thanks for the clear summary. As said my home setup is now working. However my real problem is at work (I made the home setup not to annoy 60+ users). Software is the same. Printers are HP Office Pro flow M880 and OfficeJet X576dw. Both Postscript capable. Everything look nice - I can even pull valid options (extra trays etc).

From http://localhost:631
***
HP_X576dw_2B (Idle, Accepting Jobs, Shared)
Description: HP X576dw 2.sal baghus
Location: 2. sal baghus
Driver: HP Officejet Pro X476-X576 MFP Postscript (recommended) (color, 2-sided printing)
Connection: socket://192.168.1.240:9100
Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided
***
Test page from the CUPS interface prints nicely.

A screen dump from the Windows 10 setup (in Danish, sorry) can be seen here http://www.mikesbits.eu/img/win-printer.png. A bit hard to read but it says HP Universal PS driver ver. 6.5.0 and print processor is RAW.

A test print from Windows 10 results in nothing, but /var/log/cups/access_log says:
192.168.1.45 - - [17/Jan/2018:08:58:00 +0100] "POST /printers/HP_X576dw_2B HTTP/1.1" 426 4613454 Print-Job successful-ok. Error_log is empty.

I'm stuck...

shep
Posts: 423
Joined: 2011-03-15 15:22

Re: CUPS as printserver for Windows clients doesn't print

#6 Post by shep »

socket://192.168.1.240:9100
Is the JetDirect print port (:9100) and it is where your Linux system sends the print job.

You can specify the JetDirect printer address in Windows. I'm not real fluent in windows but it looks like your screenshot has the printer at http://192.168.1.2:631 which Iikely is the IP of your Debian system. Port 631 is the the cups server.

You should be able to simplify things by telling Windows to send the print job directly to the Network Printer at 192.168.1.240:9100

https://technet.microsoft.com/en-us/lib ... 76760.aspx

kmeriksen
Posts: 9
Joined: 2014-03-17 12:57

Re: CUPS as printserver for Windows clients doesn't print

#7 Post by kmeriksen »

You can specify the JetDirect printer address in Windows
Sure, but then I can't control printer access and I can't log usage for billing. I need both. Currently we use a very shaky Windows 10 Pro as printer server (using smb/netbios) but as people bring their own devices I have a *** fight to keep in control of the smb ("samba") master browser. I've tried to install a Linux Samba server and bump up "OS Level" to 128, but still lose the master browser competition to rouge hardware on a regular basis. So I want to skip smb all together and stick to plain TCP/IP - alas IPP which means CUPS.

I know I'm gradually complicating the story, but I tried to keep my story as generic as possible.

shep
Posts: 423
Joined: 2011-03-15 15:22

Re: CUPS as printserver for Windows clients doesn't print

#8 Post by shep »

My suspicion is that this is on the Windows side. I did a quick search and found the following.

In the thread, the problem was solved by using the windows web browser to get the correct IP:PORT.

https://community.spiceworks.com/topic/ ... windows-10.

Hope this works.

Post Reply