Closed JVIon6oose closed 3 years ago
Your cupsd.conf file is not correct.
Your listen * line above needs to be changed to: "Port 631"
Then you need to restart CUPS which on most Unix boxes is "systemctl restart cups"
On a Mac you can just log out of your account and back in and that will get it.
That should make the printer 'visible' on your local network.
I can reproduce this issue, and I don't think your cupsd.conf is to blame.
I'm not sure that your problem with the ipptool command is the same issue as cupsd. When running ipptool under truss, it's trying to call getpeername
with two null pointers - I haven't investigated further, but I suspect this is just a solaris-related portability bug in there somewhere.
When running snoop
in the global zone to capture packets between the cups server and the printer, it looks as though as soon as you submit a print job, CUPS and the printer just ping-pong SNMP packets back and forth forever. There is no other traffic.
Looks like SNMP is indeed part of the IPP protocol, so I suspect it's just never making it past some kind of handshaking stage?
So, there’s (at least) two problems. Pkgsrc (the source of Joyent’s SmartOS packages) doesn’t build Ghostscript with the CUPS option by default - you can see the problem if you crank the logging up to debug in cupsd.conf. I rebuilt a custom Ghostscript package with cups enabled, and that error was solved at least.
Unfortunately, now cups is failing with “The printer is not responding”, and it appears to be the same “bad address” error you discovered in ipptool above. Sad!
I figured out the issue. The NetBSD pkgsrc (from which Joyent builds their packages) includes this patch file, which introduces a bug (at least on Illumos).
The relevant lines from the diff are the following:
- if (!getpeername(fds[i], (struct sockaddr *)&peer, &len))
+ if (getpeername(fds[i], NULL, 0) == 0) {
Maybe other Unix variants have a hack to to allow NULL
being passed as the third argument (socklen_t *namelen
), but Illumos does not. The kernel rightly assumes this parameter is a pointer to a socklen_t
, and bails out with EFAULT when attempting to copyin
a null pointer from userspace.
I think the cups people have nothing to actually do here, we should file a bug against pkgsrc.
BTW I can confirm that after deleting that patch file and rebuilding print/cups-base
, I can print to my IPP printer from a SmartOS zone.
I have a SmartOS zone with CUPS 2.3.3 installed and I am unable to add an IPP printer (Brother HL-L3230CDW) located in the same network segment. Using
ipptool
:lpadmin
issues the same error:Printer can be reached however:
Same query with
ipptool
from a SmartOS KVM running Debian yields:The cupsd.conf file contents:
I'm guessing IPP is not working correctly in this environment, since the printer is otherwise reachable and IPP is functional from other machines. I am able to print from all other machines I've tried (IPP) using CUPS. Turned off all firewalls to no avail. Thanks in advance.