Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Unable to print to network printer [solved]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
alienjon
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1533

PostPosted: Mon Mar 10, 2014 1:23 am    Post subject: Unable to print to network printer [solved] Reply with quote

I've been fighting with this all day, but here's the gist of it all:

I have an xPrintServer - Home Edition connected to an HP 1200 Laserjet printer. For anyone who isn't familiar with this device, xPrintServer is basically a cell-phone sized print server that runs CUPS. The setup runs fine with everything else in the house (including my dual booted Windows 7 and my laptop that runs Kubuntu). Actually, in checking Kubuntu, the setup is identical to that of my Gentoo box (making me think that it's something not installed correctly in Gentoo as opposed to the printer's literal configuration in CUPS).

These are the details for the printer's setup:
Name: HP_LaserJet_1200_3
Description: HP LaserJet 1200 - xPrintServer
Location: xPrintServer-0080A398AA9F
Connection: ipp://xPrintServer-0080A398AA9F.local:631/printers/HP_LaserJet_1200_3
Driver: Current - Remote Printer

Basically, when CUPS is started (at boot time or if I /etc/init.d/cupsd restart) it is automatically detected (automatically generating the above information). If I try to print a test page, though, I get the following status error message:

Code:
Processing - "Unable to locate printer "xPrintServer-0080A398AA9F.local"."


Here's some system info:

emerge cups hplip gutenprint:

[ebuild   R    ] net-print/cups-1.7.1  USE="X acl dbus gnutls pam ssl threads usb zeroconf -debug -java -kerberos -lprng-compat -python (-selinux) -static-libs -xinetd" LINGUAS="-ca -es -fr -it -ja -ru" PYTHON_SINGLE_TARGET="python2_7 -python2_6" PYTHON_TARGETS="python2_7 -python2_6" 0 kB
[ebuild   R    ] net-print/hplip-3.14.1  USE="X hpcups kde libnotify (policykit) qt4 snmp -doc -fax -hpijs -libusb0 -minimal -parport -scanner -static-ppds" PYTHON_SINGLE_TARGET="python2_7 -python2_6" PYTHON_TARGETS="python2_7 -python2_6" 0 kB
[ebuild   R    ] net-print/gutenprint-5.2.9  USE="cups foomaticdb gimp gtk nls ppds readline -static-libs" 0 kB



/var/log/cups/error_log (note, all this info is there before I try to print and nothing is added after):

W [09/Mar/2014:20:55:56 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [09/Mar/2014:20:55:56 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [09/Mar/2014:20:55:56 -0400] CreateDevice failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [09/Mar/2014:20:56:23 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [09/Mar/2014:20:56:23 -0400] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
W [09/Mar/2014:20:56:23 -0400] CreateDevice failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files


A few things I've tried thus far:
1) I made minor changes to cupsd.conf (per a suggestion I'd seen in a thread elsewhere). This may have helped with the autodetection process (which wasn't working before, but it is now).
/etc/cups/cupsd.conf:

Browsing On
BrowseLocalProtocols dnssd

2) Deleting the printer and manually entering the information that I believe to be correct (ie: http://192.168.1.145/printers/HP_LaserJet_1200_3, which is the recommended URL to use from the web-interface for the xPrintServer).
3) Installing gutenprint (in case it was a driver issue).

I also want to note that in the CUPS web interface, the automatically detected printer cannot be opened (ie: if I click any of the links to open the printer, I get a 'page not found' error).

These posts were helpful (and seem close to the mark) but the problem has persisted.

I know that the printer and xPrintServer are working fine and can interact with linux with no problem (as Kubuntu can connect and print). Additionally, the printer WILL print if I plug it into the Gentoo computer directly. It's only the network aspect that seems to glitch on me.
_________________
He who laughs last, laughs hardest
He who laughs hardest has milk come out of his nose
He who has milk come out of his nose gets laughed at
Can you see the catch 22 here?


Last edited by alienjon on Thu Mar 20, 2014 1:33 am; edited 1 time in total
Back to top
View user's profile Send private message
cboldt
n00b
n00b


Joined: 24 Aug 2005
Posts: 53

PostPosted: Mon Mar 10, 2014 11:37 am    Post subject: Reply with quote

I take from your description that the printer is connected to a network machine other than your Gentoo box.

Do you have a /etc/cups/client.conf file?

Code:
ServerName xPrintServer's Network device name
Back to top
View user's profile Send private message
alienjon
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1533

PostPosted: Mon Mar 10, 2014 11:17 pm    Post subject: Reply with quote

cboldt wrote:
I take from your description that the printer is connected to a network machine other than your Gentoo box.

Yes, the printer is connected to an xPrintServer that runs serves CUPS.

cboldt wrote:
Do you have a /etc/cups/client.conf file?

I do, and had actually messed around with it before, but with no luck. I decided to try again and attempted several iterations, though I've found no changes. I've tried both the IP address for the server (192.168.1.145) and the device name (xPrintServer-0080A398AA9F). Both respond to pings, though I noticed that the default address (when I pinged) xPrintServer-0080A398AA9F was an external address, for some reason. I tried updating /etc/hosts such that:

Code:
192.168.1.145   xPrintServer-0080A398AA9F


but that also didn't effect anything. My current /etc/cups/client.oconf file is the default (it only contains the ServerName /run/cups/cups.sock entry) but below are the iterations I tried (With and without the change to /etc/hosts):

Code:

192.168.1.1
192.168.1.145
192.168.1.145/printers
192.168.1.145/printers/HP_LaserJet_1200_3
http://192.168.1.145/printers/HP_LaserJet_1200_3
xPrintServer-0080A398AA9F
xPrintServer-0080A398AA9F/printers
xPrintServer-0080A398AA9F/printers/HP_LaserJet_1200_3
http://xPrintServer-0080A398AA9F/printers/HP_LaserJet_1200_3


For the hell of it, I included *:631* in there a few times for good measure, though little good it did me.

How does CUPS check for the network location of a printer? I wonder if I couldn't replicate the issue or find out exactly what CUPS is looking at when it tries to connect?

One last thing. I tried a combination of removing the 'automatically detected printer' and adding it manually, using ipp://192.168.1.145/printers/HP_LaserJet_1200_3, and a gutenprint PPD and got a 'processing %' leading to a notice that the document was able to render, but now I'm getting a "The configuration is incorrect or the printer no longer exists." for a status message. This feels both like the same error worded differently and progress at the same time.

I wonder if CUPS is having a hard time with the dnss protocol that is automatically detected (I'd seen that noted elsewhere, though from a few year ago, I believe). I'll play with this.
_________________
He who laughs last, laughs hardest
He who laughs hardest has milk come out of his nose
He who has milk come out of his nose gets laughed at
Can you see the catch 22 here?
Back to top
View user's profile Send private message
cboldt
n00b
n00b


Joined: 24 Aug 2005
Posts: 53

PostPosted: Tue Mar 11, 2014 12:29 am    Post subject: Reply with quote

My network printer is hardcoded, in the client machines not connected to the printer, in /etc/cups/printers.conf. This avoids the need for "browsing."

There are lots of lines in there, many added by cups. The hardcoding of the printer is done by one line:

Code:
DeviceURI ipp://hypoid/printers/HP2100-at-hypoid


The machine that has the printer connected to it is known as "hypoid." The cups installation on that machine names the default printer, also in /etc/cups/printers.conf, but the DeviceURI is the parallel port.

Code:
<DefaultPrinter HP2100-at-hypoid>
...
DeviceURI parallel:/dev/lp0
...
</Printer>


IIRC, hard-coding the IP addy works fine, but from your description, there is no issue with resolving the machine name.

Printer names have to match, too. In my case, "HP2100-at-hypoid."

I'm no "network printing guru," but recently fixed a network won't print issue by adding one-liner client.conf files (which I'd had, then commented out, system kept working, new version of CUPS, followed by no joy printing over the network. Weird error messages, fiddling with printer scripts to track events, and found out both sides of the printer system - client and server - were attempting to prepare printer-ready code).

Can you view log files at the print server?
Back to top
View user's profile Send private message
cboldt
n00b
n00b


Joined: 24 Aug 2005
Posts: 53

PostPosted: Tue Mar 11, 2014 12:53 am    Post subject: Reply with quote

The way I understand the way CUPS works, client.conf is optional. The client.conf file in the client machine is a one liner, and I think all it does is shift preparing the page for printing, to the machine named in client.conf. ServerName does not so much tell CUPS where to send the file, as tell it WHAT to send. Took me a while to scope that out.

The DeviceURI line is in printers.conf. Even if you don't have a client.conf, , you can get action on the server machine if the DeviceURI named in the client machine's printers.conf points to an address that the network can resolve and transmit to. You should see action in the server's logs, if DeviceURI points to the correct machine, regardless of having or not having a client.conf file.

DeviceURI (always in printers.conf) is one way for CUPS to "detect" a remote printer.

On the client machine, the DeviceURI (in printers.conf) will point to ipp://MACHINE(or IP)/printers/PRINTERNAME

I noted in your first message, a reference in the logs to "xPrintServer-0080A398AA9F.local" I'd wonder where that "local" appendage came from, and if you were able to get rid of it.
Back to top
View user's profile Send private message
Mistwolf
Tux's lil' helper
Tux's lil' helper


Joined: 07 Mar 2007
Posts: 107
Location: Edmonton, AB

PostPosted: Tue Mar 11, 2014 1:51 am    Post subject: Reply with quote

Are you running the cups-browsed daemon?

From the cups ebuild:

Quote:
CUPS-1.6 no longer supports automatic remote printers or implicit classes via the CUPS, LDAP, or SLP protocols, i.e. \"network browsing\". You will have to find printers using zeroconf/avahi instead, enter the location manually, or run cups-browsed from net-print/cups-filters which re-adds that functionality as a separate daemon.


Hope this helps.
Back to top
View user's profile Send private message
alienjon
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1533

PostPosted: Tue Mar 11, 2014 2:00 am    Post subject: Reply with quote

cboldt wrote:
The way I understand the way CUPS works, client.conf is optional. The client.conf file in the client machine is a one liner, and I think all it does is shift preparing the page for printing, to the machine named in client.conf. ServerName does not so much tell CUPS where to send the file, as tell it WHAT to send. Took me a while to scope that out.

Interesting, I hadn't seen that only the one (first?) line of client.conf is read. I did try changing the one line (that before now was pointing to the cups socket) but to no avail. I tried both the URL and xPrintServer-0080A398AA9F (though not the several iterations noted previously - I could if you think this could still be the culprit, but I suspect it may lie elsewhere).

cboldt wrote:
The DeviceURI line is in printers.conf. Even if you don't have a client.conf, , you can get action on the server machine if the DeviceURI named in the client machine's printers.conf points to an address that the network can resolve and transmit to. You should see action in the server's logs, if DeviceURI points to the correct machine, regardless of having or not having a client.conf file.

I'm going to post the contents of printers.conf below, in case it is helpful. At first glance it appears to be the same info I've seen elsewhere (in the CUPS web interface and the KDE printers configuration in systemsettings.

/etc/cups/printers.conf:
# Printer configuration file for CUPS v1.7.1
# Written by cupsd on 2014-03-10 21:50
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
<Printer CUPS-PDF>
UUID urn:uuid:47660ad4-eefe-34e1-4bf7-4c70d54a6856
Info Virtual PDF Printer
Location Local Printer
MakeModel Generic CUPS-PDF Printer
DeviceURI cups-pdf:/
State Idle
StateTime 1394397809
Type 8450124
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>
<Printer HP_LaserJet_1200_3>
UUID urn:uuid:eba4b951-3667-3bd8-465e-9ff170acdb04
Info HP LaserJet 1200 - xPrintServer
Location xPrintServer-0080A398AA9F
DeviceURI ipp://xPrintServer-0080A398AA9F:631/printers/HP_LaserJet_1200_3
State Idle
StateTime 1394502611
Type 6
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
Option cups-browsed true
</Printer>


cboldt wrote:
I noted in your first message, a reference in the logs to "xPrintServer-0080A398AA9F.local" I'd wonder where that "local" appendage came from, and if you were able to get rid of it.

I noticed this previously, and wondered how it was added/who added it. I'd guess that this may be related to the xPrintServer piece, as I haven't seen it mentioned anywhere in regards to cups, but I also haven't seen it in any of the configurations for xPrintServer either. For the hell of it I tried removing it from printers.conf (despite the warning) but the result is still the same. Also, in my last post I mentioned pinging both the server's IP and URL and both get a response (though the URL by default returns an external one, interestingly). When I add *.local, however, I get an unknown host.
_________________
He who laughs last, laughs hardest
He who laughs hardest has milk come out of his nose
He who has milk come out of his nose gets laughed at
Can you see the catch 22 here?
Back to top
View user's profile Send private message
alienjon
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1533

PostPosted: Tue Mar 11, 2014 2:05 am    Post subject: Reply with quote

Mistwolf wrote:
Are you running the cups-browsed daemon?

I am:

/etc/init.d/cups-browsed status:
* status: started

emerge avahi cups-filters:
[ebuild   R    ] net-dns/avahi-0.6.31-r2  USE="autoipd dbus gdbm gtk gtk3 howl-compat introspection ipv6 mdnsresponder-compat mono python qt4 utils -bookmarks -doc {-test}" PYTHON_TARGETS="python2_7 -python2_6" 0 kB
[ebuild   R    ] net-print/cups-filters-1.0.43-r1  USE="dbus foomatic jpeg png tiff zeroconf -perl -static-libs" 0 kB

_________________
He who laughs last, laughs hardest
He who laughs hardest has milk come out of his nose
He who has milk come out of his nose gets laughed at
Can you see the catch 22 here?
Back to top
View user's profile Send private message
cboldt
n00b
n00b


Joined: 24 Aug 2005
Posts: 53

PostPosted: Tue Mar 11, 2014 1:30 pm    Post subject: Reply with quote

Code:
man client.conf


You'll see that multiple lines are allowed, but there is only one instance of ServerName. The presence of the other configuration switches is used to negotiate connection and communication.

IMO, you need a client.conf file on the client machine (but not on the print server), and the ServerName line should point to the hostname-or-ip-address of the print server.

If you hard code the print destination, you don't need the browse-daemon, and any printing issues will be resolved outside of the browse-daemon setup. Browsing is great when the network is big, printers change, etc. You can get network printing to work without browsing, by hard-coding the DeviceURI for the destination printer (in printers.conf).

I've never dug into the details of the browse daemon, so I don't know if it is supposed to run on the server, the client, or has to be running on both. From your post, I infer (maybe incorrectly) you are running the browse-daemon on only the client.

Back to the behavior of CUPS across the network, my recent experience was failure to print from the client, but could print from the print server. By reading logs at the server, I could see that the client was passing SOMETHING to the server, but the server was throwing a print/filter error. That told me that the DeviceURI in printers.conf on the client machine was correct. I had to tinker with the filter scripts to figure out what the difference was between passing a print job from the client, vs. passing exactly the same job from the server. The key to making both jobs appear the same to the server, was to have a client.conf file on the client machine, pointing to the server machine. Now the print job looks the same to the server, no matter if it came from the client, or came from the server.

What does printers.conf on the server machine contain?

What happens when you issue the command `telnet xPrintServer-0080A398AA9F 631`? That is different from a "ping" in that it attempts to connect to port 631 at the hostname.

I don't understand exactly what you did when you "pinged" a URL, nor do I understand what you mean by the URL "returns an external one." You should get the same response when you `telnet hostname 631` as when you `telnet IP-address 631`. If you don't, then your hostname-to-IP-address resolver has an issue - and that is separate from CUPS.
Back to top
View user's profile Send private message
alienjon
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1533

PostPosted: Thu Mar 13, 2014 3:01 am    Post subject: Reply with quote

I feel guilty that I haven't responded sooner and wanted to apologize. I'm doing some renovations in my house right now and the printer and network are somewhat in flux. I'll probably post in a few days when I am able to test out some of your suggestions. Thanks for all the feedback!
_________________
He who laughs last, laughs hardest
He who laughs hardest has milk come out of his nose
He who has milk come out of his nose gets laughed at
Can you see the catch 22 here?
Back to top
View user's profile Send private message
alienjon
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1533

PostPosted: Thu Mar 20, 2014 1:33 am    Post subject: Reply with quote

Sorry about the delay. It seems that there is good news all around. Firstly: my wife and I have nice new tile in the kitchen and carpet in the living room. Second: in plugging things back in and - in the process - getting a new router the problem seems to have resolved. Though a new router is in the picture, the only difference is that the print server now has a dynamically assigned address, whereas previously it was statically assigned by the router. I'm not sure why or how this would have caused Gentoo to have a problem with printer assignment, especially when my Kubuntu laptop didn't have the same issue, but it's working well now. Thanks for all the help!
_________________
He who laughs last, laughs hardest
He who laughs hardest has milk come out of his nose
He who has milk come out of his nose gets laughed at
Can you see the catch 22 here?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum