Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USB printer not working on Linux with current SVN #1661

Closed
michaelrsweet opened this issue May 6, 2006 · 10 comments
Closed

USB printer not working on Linux with current SVN #1661

michaelrsweet opened this issue May 6, 2006 · 10 comments
Labels
priority-low question General usage question
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

michaelrsweet commented May 6, 2006

Version: 1.2-current
CUPS.org User: flameeyes

After upgrade to CUPS 1.2svn, I've been unable to print on my USB printer (Kyocera-Mita FS-1020D).

CUPS shows the error message: "Printer not connected; will retry in 30 seconds...", while the usb backend "DEBUG: LPGETSTATUS returned a port status of 18".

The printer works perfectly on the same identical setup if I downgrade to 1.1, either with the original 1.1 printers.conf or by re-adding the printer (yes I readded the printer on CUPS 1.2, too).

I'm not sure if this is related, but it sounds like so: on CUPS 1.1 the printer has the uri usb://Kyocera/Mita%20FS-1020D , while if I add it again in CUPS 1.2 I get usb://Kyocera/FS-1020D , discarding entirely the Mita part.

I'm afraid both cups doesn't handle correctly brand names that have spaces in them, but I'm not sure how to make sure of that.

uname: Linux enterprise 2.6.16-gentoo-r6 #1 PREEMPT Wed May 3 03:09:20 CEST 2006 x86_64 AMD Athlon(tm) 64 Processor 3500+ GNU/Linux

AMD64 architecture, Gentoo Linux.

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 6, 2006

CUPS.org User: mike

Please run the USB backend (/usr/lib/cups/backend/usb) and report the exact data that is returned.

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 6, 2006

CUPS.org User: flameeyes

Here it is the output:

enterprise ~ # DEVICE_URI="usb://Kyocera/FS-1020D" /usr/lib64/cups/backend/usb 1281 root "Test Page" 1 job-uuid=urn:uuid:7519ea8b-456e-35d0-638d-7b9d70845a3b
STATE: +connecting-to-device
DEBUG: Printer using device file "/dev/usb/lp0"...
STATE: -connecting-to-device
DEBUG: LPGETSTATUS returned a port status of 18...

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 6, 2006

CUPS.org User: mike

No, just run the backend with no arguments - I want to see the device ID string.

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 6, 2006

CUPS.org User: flameeyes

nterprise ~ # /usr/lib64/cups/backend/usb
direct usb://Kyocera/FS-1020D "Kyocera FS-1020D" "Kyocera FS-1020D USB #1" "ID:FS-1020D;MFG:Kyocera;CMD:PCLXL,PostScript Emulation,PCL5E,PJL;MDL:FS-1020D;CLS:PRINTER;DES:Kyocera Mita FS-1020D;CID:HP Laserjet 1300 Series;"

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 7, 2006

CUPS.org User: mike

OK, nothing so far indicates a failure. The first run was able to connect to the device and start printing.

WRT the new device URI, this is because we not use the manufacturer (MFG) and model (MDL) strings in preference to the description (DES) string. Kyocera apparently is not using the same string for both...

Another issue could be the permissions on /dev/usb/lp*. In CUPS 1.2, the backends run as "lp" by default...

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 8, 2006

CUPS.org User: flameeyes

The printer doesn't start printing at all, as I said, it get stucks with "Printer not connected; will retry in 30 seconds...". The permissions on the device are root:lp 0664, so shouldn't be a problem.

I'm not sure if the MGT is correct at this point, although that's fetched by the kernel, as lsusb -v shows always "Kyocera Mita", and also FreeBSD recognise it only as "Kyocera Mita FS-1020D".
Also, this way when adding the printer from the quick add in Administration section it jumps to the wrong drivers' page, but another story.

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 8, 2006

CUPS.org User: mike

Given the output from your first run of the command, the backend is able to open the port when you run it, but not able to open the port when cupsd runs it.

Just for fun, try using "chmod 666 /dev/usb/lp0" to see if that clears up the problem.

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 8, 2006

CUPS.org User: flameeyes

Before change (just plugged the printer in):

flame@enterprise ~ $ ls -l /dev/usb/lp*
crw-rw---- 1 root lp 180, 0 2006-05-08 17:55 /dev/usb/lp0

Just to make sure it's root:lp 0660..

chmodded 666... it prints.

Okay so what's wrong?

BTW, I've seen almost the same behaviour on FreeBSD, but there I supposed it was my fault.

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 8, 2006

CUPS.org User: flameeyes

Okay so the problem seems to be that even if I tell it to run with "lp" group, it only runs as "lp" user, and does not respect the groups set for that user.

flame@enterprise ~ $ grep lp /etc/passwd
lp4:7:lp:/var/spool/lpd:/bin/false

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 8, 2006

CUPS.org User: mike

CUPS will only use the "lp" group if it does not have the same GID as one of the system groups. Otherwise, it sets the group to "nobody" and logs the error in the error_log file.

@michaelrsweet michaelrsweet added priority-low question General usage question labels Mar 17, 2016
@michaelrsweet michaelrsweet added this to the Stable milestone Mar 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-low question General usage question
Projects
None yet
Development

No branches or pull requests

1 participant