Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
On Mon 15 Feb 2021 at 14:27:59 +0100, mh wrote:
> Am Mon, 15 Feb 2021 10:26:52 +0000
> schrieb Brian Potkin <firstname.lastname@example.org>:
> > On Sun 14 Feb 2021 at 20:31:28 +0100, mh wrote:
> > [...]
> > > # ippfind -T 5
> > > ~#
> > An IPP printer is not found. This would fit the observation that
> > cups-browsed has not set up a print queue. I have come to the
> > conclusion that the B432 does not implement IPP-over-USB correctly.
> First: Thanks for your help and for all your efforts. But further
> investigation and tests based on the new knowledge provided by you lets
> me come to a different conclusion (see below). I didn't know about
> ipp-usb, how it works and what it does and it automagically being
I've tried to help with understanding by quoting a wiki link.
> > A queue set up with a vendor PPD will not function while ipp-usb is
> > active, so purge it and proceed as you did with the Live ISO. Also
> > see #982190:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982190
> > Cheers,
> > Brian.
> Purging ipp-usb instantly made the cups webinterface showing my
> printer. So I could configure it using the vendor PPD file. Printing
> menue (Libreoffice) shows one OKI printer. Print succeeded.
The printer would have shown under Local Printers. With ipp-usb
active it shows under Discovered Network Printers. This is because
IPP-over-USB effectively treats the printer as a network connected
device, not a USB connected device.
> So the main issue is solved as I can print from within my
> default system. From what I've seen during configuration and printing,
> the printer setup seems stabel, the printer showed up immediately, the
> print job is carried out without much delay.
> I then reinstalled ipp-usb which again prevented the cups webinterface
> from seeing the printer. So clearly something around ipp-usb is broken.
> I purged ipp-usb again and all is well.
This is important: ipp-usb is not broken in this regard. Earlier we
bInterfaceClass 7 Printer
bInterfaceSubClass 1 Printer
iInterface 6 OKI B432 IPP0
bInterfaceClass 7 Printer
bInterfaceSubClass 1 Printer
iInterface 9 OKI B432 IPP1
I believe these are know as endpoints and that one is used to send
data to the printer and the other to receive data from the printer.
Both endpoints are commandeered by IPP-over-USB. This means that a
queue can be set up with a vendor PPD but there aren't any endpoints
for it use. The queue will not work. It is a consequence of the USB
standard and not of the design of ipp-usb.
> I then investigated the LIVE-ISO. To my surprise ipp-usb is installed
> within the LIVE-ISO. All the commands which failed/did have an empty
> output on my default system work here with the expected output (I
> guess), except for # avahi-browse -rt _ipp._tcp due to avahi-browse not
> being installed:
This is the concerning part. Why do some commands like ippfind,
lpstat -e and avahi-browse give empty outputs on Debian unstable? Are
the Debian and Live ISO versions of ipp-usb the same?
> # /usr/lib/cups/backend/usb
> DEBUG: Loading USB quirks from "/usr/share/cups/usb".
> DEBUG: Loaded 98 quirks.
> DEBUG: list_devices
> DEBUG: libusb_get_device_list=9
> DEBUG: Failed to detach "usblp" module from 06bc:0357
> # systemctl list-units "ipp-usb*" | grep service
> ipp-usb.service loaded active running Daemon for IPP over USB printer
> # lpstat -t
> Zeitplandienst läuft
> Keine systemvoreingestellten Ziele
> Gerät für OKI_DATA_CORP_B432:
> OKI_DATA_CORP_B432 akzeptiert Anfragen seit Mo 15 Feb 2021 12:45:49 CET
> Drucker OKI_DATA_CORP_B432 ist im Leerlauf. Aktiviert seit Mo 15 Feb
> 2021 12:45:49 CET
> # lpstat -l -e
> OKI_B432_010E46_USB_ network none
> OKI_DATA_CORP_B432 permanent
> # avahi-browse -rt _ipp._tcp
> Command 'avahi-browse' not found, but can be installed with:
> apt install avahi-utils
> I then tested my secound installation (the one based on the Live-ISO)
> where I yesterday couldn't configure reliably my printer. I now realized
> the printer can be configured here, too. I *suspect* this may have
> happend because the printer wasn't switched off long enough or not at
> all between unsuccessfull attempts and thus remaind in an undefined
> state which then prevented a successfull configuration? Whether or not
> the browser cache (which I emptied before every new attempt) played a
> role, too ... I dont't know. Anyway, It now works here, too.
> So it's my default system where the ipp-usb <-> printer communication
> remains broken for whatever reason. This is a some years old and
> comprehensive installation where this printer used to work until about a
> year ago. Something subtle must have gone broken over time ... but I
> can live with the printer not using ipp-usb as PPD is what I've allways
> @ till.kamppeter
> As much as I'm willing to help, from what I can tell now I assume there
> is not much to debug *direktly* related to the printer. Tell me if you
> think otherwise.
> BTW (not related the this malfunction):
> There are already some OKI PPD files available in the cups config,
> including the PPD file for the preceding model. Could I do anything to
> help to include the appropriate vendor PPD file
> for my printer (freely availabe on their webite) in the
> printer-driver-oki package (or whichever package is the rightone)?
You would submit a wishlist bug against printer-driver-oki.
Thank you for your detailed report.