Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
468 views
Skip to first unread message
Michael Hatzold
Feb 13, 2021, 3:30:03 PM2/13/21
to
Package: cups
Version: 2.3.3op2-3
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I tried to install an USB printer (oki B432).
* What exactly did you do (or not do) that was effective (or
ineffective)?
localhost:631/administration -> new printer
* What was the outcome of this action?
The printer is not listed anymore and thus I cannot select the neccesary ppd-
file, which used to work this way years ago (2017-2019/20). It still works
*reliably* on a debian/sid(uction) live_ISO from 2020.07. But on my up to date
installation it does not work anymore:
Investigating this on my computer I found the following:
# uname -r
5.10.0-3-amd64
printer switched off:
# lsmod | grep usb
usbhid 65536 0
hid 147456 2 usbhid,hid_generic
usbcore 323584 6
ehci_pci,usbhid,em28xx_dvb,ehci_hcd,em28xx,uhci_hcd
usb_common 16384 3 usbcore,ehci_hcd,uhci_hcd
# /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=8
printer switched on:
# lsmod | grep usb
usblp 28672 0
usbhid 65536 0
hid 147456 2 usbhid,hid_generic
usbcore 323584 8
ehci_pci,usbhid,usblp,em28xx_dvb,ehci_hcd,em28xx,uhci_hcd
usb_common 16384 3 usbcore,ehci_hcd,uhci_hcd
# /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
or
# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 95 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=9
DEBUG: Switching USB device configuration: 0 -> 1
DEBUG: Failed to set configuration 1 for 06bc:0357
DEBUG: Failed to set alternate interface 0 for 06bc:0357: Connection timed out
The difference I can't explain except for the following facts:
Today I downgraded cups and relatives to the version (cups_2.3.3-1_amd64.deb)
of the above Live_ISO. I added a missing package (libusbredirparser1).
Initially it worked, i.e. the printer was visible and installable in the web
admin panel after reloading the page some times. In the printing menue (for
example libreoffice) the printer showed up once. After rebooting and updating
the printer showed up with two slightly different names in the menues, and did
not show up in the administration anymore. I updated, used different kernels,
downgraded again. No more printer in the admin panel list. ***This is a
longstanding problem, not just today!***
I still reliably can install and use the printer using the above mentioned
live-ISO, but with my real installation, the few times I get it installed, it
does not work, as cups is "waiting for the printer becomming available"
(according to the cups job list), whereas the printer shows "ready to print" in
its LED panel.
To it seams usblp and libusb are blocking each other and/or there are timing
issues.
Any help or fix is very appreciated. If needed I could test. But my "skills"
are rather limited.
* What outcome did you expect instead?
Obviously I would like to install and configure my printer to then be able to
print
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cups depends on:
ii cups-client 2.3.3op2-3
ii cups-common 2.3.3op2-3
ii cups-core-drivers 2.3.3op2-3
ii cups-daemon 2.3.3op2-3
ii cups-filters 1.28.7-1
ii cups-ppdc 2.3.3op2-3
ii cups-server-common 2.3.3op2-3
ii debconf [debconf-2.0] 1.5.74
ii ghostscript 9.53.3~dfsg-7
ii libavahi-client3 0.8-5
ii libavahi-common3 0.8-5
ii libc6 2.31-9
ii libcups2 2.3.3op2-3
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii libusb-1.0-0 2:1.0.24-2
ii poppler-utils 20.09.0-3.1
ii procps 2:3.3.17-2
Versions of packages cups recommends:
ii avahi-daemon 0.8-5
ii colord 1.4.5-3
Versions of packages cups suggests:
pn cups-bsd <none>
pn cups-pdf <none>
ii foomatic-db 20200820-1
ii smbclient 2:4.13.4+dfsg-1
ii udev 247.3-1
-- debconf information:
cupsys/backend: lpd, socket, usb, snmp, dnssd
Version: 2.3.3op2-3
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I tried to install an USB printer (oki B432).
* What exactly did you do (or not do) that was effective (or
ineffective)?
localhost:631/administration -> new printer
* What was the outcome of this action?
The printer is not listed anymore and thus I cannot select the neccesary ppd-
file, which used to work this way years ago (2017-2019/20). It still works
*reliably* on a debian/sid(uction) live_ISO from 2020.07. But on my up to date
installation it does not work anymore:
Investigating this on my computer I found the following:
# uname -r
5.10.0-3-amd64
printer switched off:
# lsmod | grep usb
usbhid 65536 0
hid 147456 2 usbhid,hid_generic
usbcore 323584 6
ehci_pci,usbhid,em28xx_dvb,ehci_hcd,em28xx,uhci_hcd
usb_common 16384 3 usbcore,ehci_hcd,uhci_hcd
# /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=8
printer switched on:
# lsmod | grep usb
usblp 28672 0
usbhid 65536 0
hid 147456 2 usbhid,hid_generic
usbcore 323584 8
ehci_pci,usbhid,usblp,em28xx_dvb,ehci_hcd,em28xx,uhci_hcd
usb_common 16384 3 usbcore,ehci_hcd,uhci_hcd
# /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
or
# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 95 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=9
DEBUG: Switching USB device configuration: 0 -> 1
DEBUG: Failed to set configuration 1 for 06bc:0357
DEBUG: Failed to set alternate interface 0 for 06bc:0357: Connection timed out
The difference I can't explain except for the following facts:
Today I downgraded cups and relatives to the version (cups_2.3.3-1_amd64.deb)
of the above Live_ISO. I added a missing package (libusbredirparser1).
Initially it worked, i.e. the printer was visible and installable in the web
admin panel after reloading the page some times. In the printing menue (for
example libreoffice) the printer showed up once. After rebooting and updating
the printer showed up with two slightly different names in the menues, and did
not show up in the administration anymore. I updated, used different kernels,
downgraded again. No more printer in the admin panel list. ***This is a
longstanding problem, not just today!***
I still reliably can install and use the printer using the above mentioned
live-ISO, but with my real installation, the few times I get it installed, it
does not work, as cups is "waiting for the printer becomming available"
(according to the cups job list), whereas the printer shows "ready to print" in
its LED panel.
To it seams usblp and libusb are blocking each other and/or there are timing
issues.
Any help or fix is very appreciated. If needed I could test. But my "skills"
are rather limited.
* What outcome did you expect instead?
Obviously I would like to install and configure my printer to then be able to
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cups depends on:
ii cups-client 2.3.3op2-3
ii cups-common 2.3.3op2-3
ii cups-core-drivers 2.3.3op2-3
ii cups-daemon 2.3.3op2-3
ii cups-filters 1.28.7-1
ii cups-ppdc 2.3.3op2-3
ii cups-server-common 2.3.3op2-3
ii debconf [debconf-2.0] 1.5.74
ii ghostscript 9.53.3~dfsg-7
ii libavahi-client3 0.8-5
ii libavahi-common3 0.8-5
ii libc6 2.31-9
ii libcups2 2.3.3op2-3
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii libusb-1.0-0 2:1.0.24-2
ii poppler-utils 20.09.0-3.1
ii procps 2:3.3.17-2
Versions of packages cups recommends:
ii avahi-daemon 0.8-5
ii colord 1.4.5-3
Versions of packages cups suggests:
pn cups-bsd <none>
pn cups-pdf <none>
ii foomatic-db 20200820-1
ii smbclient 2:4.13.4+dfsg-1
ii udev 247.3-1
-- debconf information:
cupsys/backend: lpd, socket, usb, snmp, dnssd
mh
Feb 13, 2021, 3:50:03 PM2/13/21
to
# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb". DEBUG: Loaded 181
quirks. DEBUG: list_devices DEBUG: libusb_get_device_list=9 DEBUG2:
Printer found with device ID: MANUFACTURER:OKI DATA CORP;COMMAND
SET:PJL,PCL,IBMPPR,EPSONFX,POSTSCRIPT,PCLXL,IPDL,XPS;MODEL:B432;CLASS:PRINTER;DESCRIPTION:OKI
B432;COMPATIBLE ID:OK_N_7800; Device URI:
usb://OKI%20DATA%20CORP/B432?serial=AK76039718 direct
usb://OKI%20DATA%20CORP/B432?serial=AK76039718 "OKI DATA CORP B432"
"OKI DATA CORP B432" "MANUFACTURER:OKI DATA CORP;COMMAND
SET:PJL,PCL,IBMPPR,EPSONFX,POSTSCRIPT,PCLXL,IPDL,XPS;MODEL:B432;CLASS:PRINTER;DESCRIPTION:OKI
B432;COMPATIBLE ID:OK_N_7800;" ""
I wonder why here are 181 quirks!
Brian Potkin
Feb 13, 2021, 6:40:03 PM2/13/21
to
On Sat 13 Feb 2021 at 21:23:19 +0100, Michael Hatzold wrote:
> Package: cups
> Version: 2.3.3op2-3
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> * What led up to the situation?
>
> I tried to install an USB printer (oki B432).
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> localhost:631/administration -> new printer
>
> * What was the outcome of this action?
>
> The printer is not listed anymore and thus I cannot select the neccesary ppd-
> file, which used to work this way years ago (2017-2019/20). It still works
> *reliably* on a debian/sid(uction) live_ISO from 2020.07. But on my up to date
> installation it does not work anymore:
Thank you for your report, Michael, Let's see what we can do about this.
> Package: cups
> Version: 2.3.3op2-3
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> * What led up to the situation?
>
> I tried to install an USB printer (oki B432).
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> localhost:631/administration -> new printer
>
> * What was the outcome of this action?
>
> The printer is not listed anymore and thus I cannot select the neccesary ppd-
> file, which used to work this way years ago (2017-2019/20). It still works
> *reliably* on a debian/sid(uction) live_ISO from 2020.07. But on my up to date
> installation it does not work anymore:
Are you using a USB connection? If so, give what you get for
lsusb -v | grep -A 3 bInterfaceClass.*7
Regards,
Brian.
Brian Potkin
Feb 14, 2021, 6:30:03 AM2/14/21
to
On Sun 14 Feb 2021 at 01:04:57 +0100, mh wrote:
> Am Sat, 13 Feb 2021 23:30:04 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
[...]
> > Thank you for your report, Michael, Let's see what we can do about
> > this.
> >
> > Are you using a USB connection? If so, give what you get for
> >
>
> Hi Brian,
>
> thanks for trying to help.
>
> Yes, I am using an USB connection.
> bInterfaceSubClass 1 Printer
> bInterfaceProtocol 2 Bidirectional
> iInterface 4 OKI B432 Printer
> --
> bInterfaceClass 7 Printer
> bInterfaceSubClass 1 Printer
> bInterfaceProtocol 4
> iInterface 6 OKI B432 IPP0
> --
> bInterfaceClass 7 Printer
> bInterfaceSubClass 1 Printer
> bInterfaceProtocol 4
> iInterface 9 OKI B432 IPP1
Michael, don't forget to mail the bug; I sent the last one there for
you.
"bInterfaceProtocol 4" indicates that the printer understands
IPP=over-USB. Now give
systemctl list-units "ipp-usb*" | grep service
and
lpstat -t
Regards,
Brian.
>
>
> >
> > Regards,
> >
> > Brian.
> Am Sat, 13 Feb 2021 23:30:04 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
[...]
> > Thank you for your report, Michael, Let's see what we can do about
> > this.
> >
> > Are you using a USB connection? If so, give what you get for
> >
>
>
> thanks for trying to help.
>
> Yes, I am using an USB connection.
>
>
> > lsusb -v | grep -A 3 bInterfaceClass.*7
>
>
> bInterfaceClass 7 Printer
>
> > lsusb -v | grep -A 3 bInterfaceClass.*7
>
>
> bInterfaceSubClass 1 Printer
> bInterfaceProtocol 2 Bidirectional
> iInterface 4 OKI B432 Printer
> --
> bInterfaceClass 7 Printer
> bInterfaceSubClass 1 Printer
> bInterfaceProtocol 4
> iInterface 6 OKI B432 IPP0
> --
> bInterfaceClass 7 Printer
> bInterfaceSubClass 1 Printer
> bInterfaceProtocol 4
> iInterface 9 OKI B432 IPP1
Michael, don't forget to mail the bug; I sent the last one there for
you.
"bInterfaceProtocol 4" indicates that the printer understands
IPP=over-USB. Now give
systemctl list-units "ipp-usb*" | grep service
and
lpstat -t
Regards,
Brian.
>
>
> >
> > Regards,
> >
> > Brian.
mh
Feb 14, 2021, 7:00:03 AM2/14/21
to
Am Sun, 14 Feb 2021 11:21:45 +0000
Thanks. I wondered whether I should respond to your mail address. Now I
did CC 982...@bugs.debian.org if that's what you suggested.
>
> "bInterfaceProtocol 4" indicates that the printer understands
> IPP=over-USB. Now give
>
> systemctl list-units "ipp-usb*" | grep service
# systemctl list-units "ipp-usb*" | grep service
~#
>
> and
>
> lpstat -t
# lpstat -t
Zeitplandienst läuft
Keine systemvoreingestellten Ziele
lpstat: Keine Druckziele hinzugefügt.
lpstat: Keine Druckziele hinzugefügt.
lpstat: Keine Druckziele hinzugefügt.
lpstat: Keine Druckziele hinzugefügt.
Meaning:
time table service running
No preconfigured system targets
lpstat: No printing targets added.
BTW: I had IPP-USB configured once, but for that to happen I had to
connect the printer using a LAN cable. And I could not print either.
But there may have been other misconfigurations be involved, too, as I
didn't really understand how to configure a LAN connection for the
printer.
*As a layman* I am guessing whether this USB mess happens due to timing
issues (live ISO is runing in RAM, so runs very responsive). Shouldn't
any solution involve solving the apparent conflict between libusb and
usblp?
Anyway, thanks so far.
Michael
>
> Regards,
>
> Brian.
> >
> >
> > >
> > > Regards,
> > >
> > > Brian.
did CC 982...@bugs.debian.org if that's what you suggested.
>
> "bInterfaceProtocol 4" indicates that the printer understands
> IPP=over-USB. Now give
>
> systemctl list-units "ipp-usb*" | grep service
~#
>
> and
>
> lpstat -t
# lpstat -t
Zeitplandienst läuft
Keine systemvoreingestellten Ziele
lpstat: Keine Druckziele hinzugefügt.
lpstat: Keine Druckziele hinzugefügt.
lpstat: Keine Druckziele hinzugefügt.
lpstat: Keine Druckziele hinzugefügt.
Meaning:
time table service running
No preconfigured system targets
lpstat: No printing targets added.
BTW: I had IPP-USB configured once, but for that to happen I had to
connect the printer using a LAN cable. And I could not print either.
But there may have been other misconfigurations be involved, too, as I
didn't really understand how to configure a LAN connection for the
printer.
*As a layman* I am guessing whether this USB mess happens due to timing
issues (live ISO is runing in RAM, so runs very responsive). Shouldn't
any solution involve solving the apparent conflict between libusb and
usblp?
Anyway, thanks so far.
Michael
>
> Regards,
>
> Brian.
> >
> >
> > >
> > > Regards,
> > >
> > > Brian.
Brian Potkin
Feb 14, 2021, 8:10:03 AM2/14/21
to
On Sun 14 Feb 2021 at 12:56:11 +0100, mh wrote:
> Am Sun, 14 Feb 2021 11:21:45 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> Am Sun, 14 Feb 2021 11:21:45 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> > Michael, don't forget to mail the bug; I sent the last one there for
> > you.
>
> Thanks. I wondered whether I should respond to your mail address. Now I
> did CC 982...@bugs.debian.org if that's what you suggested.
That's better. Thanks.
> > you.
>
> Thanks. I wondered whether I should respond to your mail address. Now I
> did CC 982...@bugs.debian.org if that's what you suggested.
> >
> > "bInterfaceProtocol 4" indicates that the printer understands
> > IPP=over-USB. Now give
> >
> > systemctl list-units "ipp-usb*" | grep service
>
> # systemctl list-units "ipp-usb*" | grep service
> ~#
systemctl start ipp-usb
and
systemctl status ipp-usb
with the printer connected and disconnected?
> >
> > and
> >
> > lpstat -t
>
> # lpstat -t
> Zeitplandienst läuft
> Keine systemvoreingestellten Ziele
> lpstat: Keine Druckziele hinzugefügt.
> lpstat: Keine Druckziele hinzugefügt.
> lpstat: Keine Druckziele hinzugefügt.
> lpstat: Keine Druckziele hinzugefügt.
>
> Meaning:
> time table service running
> No preconfigured system targets
> lpstat: No printing targets added.
> BTW: I had IPP-USB configured once, but for that to happen I had to
> connect the printer using a LAN cable. And I could not print either.
> But there may have been other misconfigurations be involved, too, as I
> didn't really understand how to configure a LAN connection for the
> printer.
at
https://wiki.debian.org/CUPSDriverlessPrinting
> *As a layman* I am guessing whether this USB mess happens due to timing
> issues (live ISO is runing in RAM, so runs very responsive). Shouldn't
> any solution involve solving the apparent conflict between libusb and
> usblp?
the printing system is working as designed.
Regards,
Brian.
mh
Feb 14, 2021, 9:00:03 AM2/14/21
to
Am Sun, 14 Feb 2021 13:06:09 +0000
~#
# systemctl status ipp-usb
● ipp-usb.service - Daemon for IPP over USB printer support
Loaded: loaded (/lib/systemd/system/ipp-usb.service; static)
Active: active (running) since Sun 2021-02-14 14:01:53 CET; 32min
ago Docs: man:ipp-usb(8)
Main PID: 854 (ipp-usb)
Tasks: 10 (limit: 4634)
Memory: 7.9M
CPU: 52ms
CGroup: /system.slice/ipp-usb.service
└─854 /sbin/ipp-usb udev
Feb 14 14:01:53 neutower systemd[1]: Started Daemon for IPP over USB
printer support.
> and disconnected?
(printer switched off)
~# systemctl status ipp-usb
● ipp-usb.service - Daemon for IPP over USB printer support
Loaded: loaded (/lib/systemd/system/ipp-usb.service; static)
Active: inactive (dead)
Docs: man:ipp-usb(8)
Feb 14 14:01:53 neutower systemd[1]: Started Daemon for IPP over USB
printer support. Feb 14 14:37:24 neutower systemd[1]: ipp-usb.service:
Succeeded. Feb 14 14:38:18 neutower systemd[1]: Started Daemon for IPP
over USB printer support. Feb 14 14:38:18 neutower systemd[1]:
ipp-usb.service: Succeeded.
>
> > >
> > > and
> > >
> > > lpstat -t
> >
> > # lpstat -t
> > Zeitplandienst läuft
> > Keine systemvoreingestellten Ziele
> > lpstat: Keine Druckziele hinzugefügt.
> > lpstat: Keine Druckziele hinzugefügt.
> > lpstat: Keine Druckziele hinzugefügt.
> > lpstat: Keine Druckziele hinzugefügt.
> >
> > Meaning:
> > time table service running
> > No preconfigured system targets
> > lpstat: No printing targets added.
>
> This is the expected output if ipp-usb is not active.
>
> > BTW: I had IPP-USB configured once, but for that to happen I had to
> > connect the printer using a LAN cable. And I could not print either.
> > But there may have been other misconfigurations be involved, too,
> > as I didn't really understand how to configure a LAN connection for
> > the printer.
>
> IPP-over-USB is for a USB connection only. See sections 13, 14 and 15
> at
>
> https://wiki.debian.org/CUPSDriverlessPrinting
Thanks for the info.
>
>
> > *As a layman* I am guessing whether this USB mess happens due to
> > timing issues (live ISO is runing in RAM, so runs very responsive).
> > Shouldn't any solution involve solving the apparent conflict
> > between libusb and usblp?
>
> I am not skilled in USB matters and first wanted to discover whether
> the printing system is working as designed.
Ok, understood.
>
> Regards,
>
> Brian.
Greetings from Germany
Michael
schrieb Brian Potkin <clarem...@gmail.com>:
> On Sun 14 Feb 2021 at 12:56:11 +0100, mh wrote:
>
> > Am Sun, 14 Feb 2021 11:21:45 +0000
> > schrieb Brian Potkin <clarem...@gmail.com>:
> >
> > > Michael, don't forget to mail the bug; I sent the last one there
> > > for you.
> >
> > Thanks. I wondered whether I should respond to your mail address.
> > Now I did CC 982...@bugs.debian.org if that's what you suggested.
>
> That's better. Thanks.
>
> > >
> > > "bInterfaceProtocol 4" indicates that the printer understands
> > > IPP=over-USB. Now give
> > >
> > > systemctl list-units "ipp-usb*" | grep service
> >
> > # systemctl list-units "ipp-usb*" | grep service
> > ~#
>
> An empty output is unexpected. What happens with
>
> systemctl start ipp-usb
>
> and
>
> systemctl status ipp-usb
>
> with the printer connected
# systemctl start ipp-usb
> On Sun 14 Feb 2021 at 12:56:11 +0100, mh wrote:
>
> > Am Sun, 14 Feb 2021 11:21:45 +0000
> > schrieb Brian Potkin <clarem...@gmail.com>:
> >
> > > Michael, don't forget to mail the bug; I sent the last one there
> > > for you.
> >
> > Thanks. I wondered whether I should respond to your mail address.
> > Now I did CC 982...@bugs.debian.org if that's what you suggested.
>
> That's better. Thanks.
>
> > >
> > > "bInterfaceProtocol 4" indicates that the printer understands
> > > IPP=over-USB. Now give
> > >
> > > systemctl list-units "ipp-usb*" | grep service
> >
> > # systemctl list-units "ipp-usb*" | grep service
> > ~#
>
> An empty output is unexpected. What happens with
>
> systemctl start ipp-usb
>
> and
>
> systemctl status ipp-usb
>
> with the printer connected
~#
# systemctl status ipp-usb
● ipp-usb.service - Daemon for IPP over USB printer support
Loaded: loaded (/lib/systemd/system/ipp-usb.service; static)
Active: active (running) since Sun 2021-02-14 14:01:53 CET; 32min
ago Docs: man:ipp-usb(8)
Main PID: 854 (ipp-usb)
Tasks: 10 (limit: 4634)
Memory: 7.9M
CPU: 52ms
CGroup: /system.slice/ipp-usb.service
└─854 /sbin/ipp-usb udev
Feb 14 14:01:53 neutower systemd[1]: Started Daemon for IPP over USB
printer support.
> and disconnected?
(printer switched off)
~# systemctl status ipp-usb
● ipp-usb.service - Daemon for IPP over USB printer support
Loaded: loaded (/lib/systemd/system/ipp-usb.service; static)
Active: inactive (dead)
Docs: man:ipp-usb(8)
Feb 14 14:01:53 neutower systemd[1]: Started Daemon for IPP over USB
printer support. Feb 14 14:37:24 neutower systemd[1]: ipp-usb.service:
Succeeded. Feb 14 14:38:18 neutower systemd[1]: Started Daemon for IPP
over USB printer support. Feb 14 14:38:18 neutower systemd[1]:
ipp-usb.service: Succeeded.
>
> > >
> > > and
> > >
> > > lpstat -t
> >
> > # lpstat -t
> > Zeitplandienst läuft
> > Keine systemvoreingestellten Ziele
> > lpstat: Keine Druckziele hinzugefügt.
> > lpstat: Keine Druckziele hinzugefügt.
> > lpstat: Keine Druckziele hinzugefügt.
> > lpstat: Keine Druckziele hinzugefügt.
> >
> > Meaning:
> > time table service running
> > No preconfigured system targets
> > lpstat: No printing targets added.
>
> This is the expected output if ipp-usb is not active.
>
> > BTW: I had IPP-USB configured once, but for that to happen I had to
> > connect the printer using a LAN cable. And I could not print either.
> > But there may have been other misconfigurations be involved, too,
> > as I didn't really understand how to configure a LAN connection for
> > the printer.
>
> IPP-over-USB is for a USB connection only. See sections 13, 14 and 15
> at
>
> https://wiki.debian.org/CUPSDriverlessPrinting
>
>
> > *As a layman* I am guessing whether this USB mess happens due to
> > timing issues (live ISO is runing in RAM, so runs very responsive).
> > Shouldn't any solution involve solving the apparent conflict
> > between libusb and usblp?
>
> I am not skilled in USB matters and first wanted to discover whether
> the printing system is working as designed.
>
> Regards,
>
> Brian.
Greetings from Germany
Michael
Brian Potkin
Feb 14, 2021, 9:40:03 AM2/14/21
to
queue. Anything from 'lpstat -t' now? How about 'lpstat -l -e' and
'avahi-browse -rt _ipp._tcp'?
Regards,
Brian.
mh
Feb 14, 2021, 10:30:03 AM2/14/21
to
Am Sun, 14 Feb 2021 14:35:53 +0000
Nothing
> How about 'lpstat -l -e' and
Nothing
> 'avahi-browse -rt _ipp._tcp'?
Nothing
But to be clear: Currently there is *no printer installed* here in this
system. It has been, but as I could not print I purged cups* entierly
and than reinstalled it as described in my initial report. And now in
the cups admin webpanel no Oki or USB printer is visible to select a PPD
file for (whereas it works fine and reliably in a live ISO system).
>
> Regards,
>
> Brian.
Greetings
Michael
> How about 'lpstat -l -e' and
> 'avahi-browse -rt _ipp._tcp'?
Nothing
But to be clear: Currently there is *no printer installed* here in this
system. It has been, but as I could not print I purged cups* entierly
and than reinstalled it as described in my initial report. And now in
the cups admin webpanel no Oki or USB printer is visible to select a PPD
file for (whereas it works fine and reliably in a live ISO system).
>
> Regards,
>
> Brian.
Greetings
Michael
Brian Potkin
Feb 14, 2021, 10:50:03 AM2/14/21
to
On Sun 14 Feb 2021 at 16:17:34 +0100, mh wrote:
> Am Sun, 14 Feb 2021 14:35:53 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> > On Sun 14 Feb 2021 at 14:47:42 +0100, mh wrote:
> >
[...]
> Am Sun, 14 Feb 2021 14:35:53 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> > On Sun 14 Feb 2021 at 14:47:42 +0100, mh wrote:
> >
> > > # systemctl start ipp-usb
> > > ~#
> > >
> > > # systemctl status ipp-usb
> > > ● ipp-usb.service - Daemon for IPP over USB printer support
> > > Loaded: loaded (/lib/systemd/system/ipp-usb.service; static)
> > > Active: active (running) since Sun 2021-02-14 14:01:53 CET;
> > > 32min ago Docs: man:ipp-usb(8)
> > > Main PID: 854 (ipp-usb)
> > > Tasks: 10 (limit: 4634)
> > > Memory: 7.9M
> > > CPU: 52ms
> > > CGroup: /system.slice/ipp-usb.service
> > > └─854 /sbin/ipp-usb udev
> > >
> > > Feb 14 14:01:53 neutower systemd[1]: Started Daemon for IPP over USB
> > > printer support
> >
> > That's exactly what should happen. cups-browsed should now install a
> > queue. Anything from 'lpstat -t' now?
>
> Nothing
>
> > How about 'lpstat -l -e' and
>
> Nothing
>
> > 'avahi-browse -rt _ipp._tcp'?
>
> Nothing
commands. I hope you did not type the apostrophes (' ').
> But to be clear: Currently there is *no printer installed* here in this
> system. It has been, but as I could not print I purged cups* entierly
> and than reinstalled it as described in my initial report. And now in
> the cups admin webpanel no Oki or USB printer is visible to select a PPD
> file for (whereas it works fine and reliably in a live ISO system).
which you have shown is active on your machine. There is no need for
you to select a PPD or a vendor driver.
Regards,
Brian.
mh
Feb 14, 2021, 12:00:05 PM2/14/21
to
Am Sun, 14 Feb 2021 15:39:51 +0000
I did not ;-)
>
> > But to be clear: Currently there is *no printer installed* here in
> > this system. It has been, but as I could not print I purged cups*
> > entierly and than reinstalled it as described in my initial report.
> > And now in the cups admin webpanel no Oki or USB printer is visible
> > to select a PPD file for (whereas it works fine and reliably in a
> > live ISO system).
>
> The whole point is that the printer installion is done via ipp-usb,
> which you have shown is active on your machine. There is no need for
> you to select a PPD or a vendor driver.
If I could have all features my printer offers available this way, then
yes. OTOH the whole problem does not seam to be the protocol used,
but cups administration not seeing the printer.
Is there a way to completly resett systemd/udev/avahi/whatever? Month
ago I tried "apt install --reinstall systemd udev" as an attempt to
exclude any malfunction.
thanks
Michael
>
> Regards,
>
> Brian.
>
> > But to be clear: Currently there is *no printer installed* here in
> > this system. It has been, but as I could not print I purged cups*
> > entierly and than reinstalled it as described in my initial report.
> > And now in the cups admin webpanel no Oki or USB printer is visible
> > to select a PPD file for (whereas it works fine and reliably in a
> > live ISO system).
>
> The whole point is that the printer installion is done via ipp-usb,
> which you have shown is active on your machine. There is no need for
> you to select a PPD or a vendor driver.
yes. OTOH the whole problem does not seam to be the protocol used,
but cups administration not seeing the printer.
Is there a way to completly resett systemd/udev/avahi/whatever? Month
ago I tried "apt install --reinstall systemd udev" as an attempt to
exclude any malfunction.
thanks
Michael
>
> Regards,
>
> Brian.
Brian Potkin
Feb 14, 2021, 12:40:04 PM2/14/21
to
On Sun 14 Feb 2021 at 17:44:20 +0100, mh wrote:
> Am Sun, 14 Feb 2021 15:39:51 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> Am Sun, 14 Feb 2021 15:39:51 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> > The whole point is that the printer installion is done via ipp-usb,
> > which you have shown is active on your machine. There is no need for
> > you to select a PPD or a vendor driver.
>
> If I could have all features my printer offers available this way, then
> yes. OTOH the whole problem does not seam to be the protocol used,
> but cups administration not seeing the printer.
>
> Is there a way to completly resett systemd/udev/avahi/whatever? Month
> ago I tried "apt install --reinstall systemd udev" as an attempt to
> exclude any malfunction.
Is avahi-daemon active?
> > which you have shown is active on your machine. There is no need for
> > you to select a PPD or a vendor driver.
>
> If I could have all features my printer offers available this way, then
> yes. OTOH the whole problem does not seam to be the protocol used,
> but cups administration not seeing the printer.
>
> Is there a way to completly resett systemd/udev/avahi/whatever? Month
> ago I tried "apt install --reinstall systemd udev" as an attempt to
> exclude any malfunction.
systemctl status avahi-daemon
Do you have a firewall?
Regards,
Brian.
mh
Feb 14, 2021, 1:00:04 PM2/14/21
to
Am Sun, 14 Feb 2021 17:35:47 +0000
# systemctl status avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled;
vendor preset: enabled) Active: active (running) since Sun 2021-02-14
14:01:53 CET; 4h 38min ago TriggeredBy: ● avahi-daemon.socket
Main PID: 711 (avahi-daemon)
Status: "avahi-daemon 0.8 starting up."
Tasks: 2 (limit: 4634)
Memory: 1.7M
CPU: 402ms
CGroup: /system.slice/avahi-daemon.service
├─711 avahi-daemon: running [neutower.local]
└─749 avahi-daemon: chroot helper
Feb 14 14:01:51 neutower avahi-daemon[711]: Found user 'avahi' (UID
106) and group 'avahi' (GID 114). Feb 14 14:01:51 neutower
avahi-daemon[711]: Successfully dropped root privileges. Feb 14
14:01:51 neutower avahi-daemon[711]: avahi-daemon 0.8 starting up. Feb
14 14:01:53 neutower avahi-daemon[711]: Successfully called chroot().
Feb 14 14:01:53 neutower avahi-daemon[711]: Successfully dropped
remaining capabilities. Feb 14 14:01:53 neutower avahi-daemon[711]:
Loading service file /services/apt-cacher-ng.service. Feb 14 14:01:53
neutower avahi-daemon[711]: Network interface enumeration completed.
Feb 14 14:01:53 neutower avahi-daemon[711]: Server startup complete.
Host name is neutower.local. Local service cookie is 294> Feb 14
14:01:53 neutower avahi-daemon[711]: Service "apt-cacher-ng proxy on
neutower" (/services/apt-cacher-ng.service) succe> Feb 14 14:01:53
neutower systemd[1]: Started Avahi mDNS/DNS-SD Stack. lines 1-23/23
(END)
>
> Do you have a firewall?
No.
>
> Regards,
>
> Brian.
Greetings
Michael
schrieb Brian Potkin <clarem...@gmail.com>:
> On Sun 14 Feb 2021 at 17:44:20 +0100, mh wrote:
>
> > Am Sun, 14 Feb 2021 15:39:51 +0000
> > schrieb Brian Potkin <clarem...@gmail.com>:
> >
> > > The whole point is that the printer installion is done via
> > > ipp-usb, which you have shown is active on your machine. There is
> > > no need for you to select a PPD or a vendor driver.
> >
> > If I could have all features my printer offers available this way,
> > then yes. OTOH the whole problem does not seam to be the protocol
> > used, but cups administration not seeing the printer.
> >
> > Is there a way to completly resett systemd/udev/avahi/whatever?
> > Month ago I tried "apt install --reinstall systemd udev" as an
> > attempt to exclude any malfunction.
>
> Is avahi-daemon active?
>
> systemctl status avahi-daemon
Yes.
> On Sun 14 Feb 2021 at 17:44:20 +0100, mh wrote:
>
> > Am Sun, 14 Feb 2021 15:39:51 +0000
> > schrieb Brian Potkin <clarem...@gmail.com>:
> >
> > > The whole point is that the printer installion is done via
> > > ipp-usb, which you have shown is active on your machine. There is
> > > no need for you to select a PPD or a vendor driver.
> >
> > If I could have all features my printer offers available this way,
> > then yes. OTOH the whole problem does not seam to be the protocol
> > used, but cups administration not seeing the printer.
> >
> > Is there a way to completly resett systemd/udev/avahi/whatever?
> > Month ago I tried "apt install --reinstall systemd udev" as an
> > attempt to exclude any malfunction.
>
> Is avahi-daemon active?
>
> systemctl status avahi-daemon
# systemctl status avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled;
vendor preset: enabled) Active: active (running) since Sun 2021-02-14
14:01:53 CET; 4h 38min ago TriggeredBy: ● avahi-daemon.socket
Main PID: 711 (avahi-daemon)
Status: "avahi-daemon 0.8 starting up."
Tasks: 2 (limit: 4634)
Memory: 1.7M
CPU: 402ms
CGroup: /system.slice/avahi-daemon.service
├─711 avahi-daemon: running [neutower.local]
└─749 avahi-daemon: chroot helper
Feb 14 14:01:51 neutower avahi-daemon[711]: Found user 'avahi' (UID
106) and group 'avahi' (GID 114). Feb 14 14:01:51 neutower
avahi-daemon[711]: Successfully dropped root privileges. Feb 14
14:01:51 neutower avahi-daemon[711]: avahi-daemon 0.8 starting up. Feb
14 14:01:53 neutower avahi-daemon[711]: Successfully called chroot().
Feb 14 14:01:53 neutower avahi-daemon[711]: Successfully dropped
remaining capabilities. Feb 14 14:01:53 neutower avahi-daemon[711]:
Loading service file /services/apt-cacher-ng.service. Feb 14 14:01:53
neutower avahi-daemon[711]: Network interface enumeration completed.
Feb 14 14:01:53 neutower avahi-daemon[711]: Server startup complete.
Host name is neutower.local. Local service cookie is 294> Feb 14
14:01:53 neutower avahi-daemon[711]: Service "apt-cacher-ng proxy on
neutower" (/services/apt-cacher-ng.service) succe> Feb 14 14:01:53
neutower systemd[1]: Started Avahi mDNS/DNS-SD Stack. lines 1-23/23
(END)
>
> Do you have a firewall?
>
> Regards,
>
> Brian.
Greetings
Michael
Brian Potkin
Feb 14, 2021, 2:10:03 PM2/14/21
to
On Sun 14 Feb 2021 at 18:47:18 +0100, mh wrote:
> Am Sun, 14 Feb 2021 17:35:47 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> Am Sun, 14 Feb 2021 17:35:47 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
lpinfo -v
and
ippfind -T 5
Cheers,
Brian.
mh
Feb 14, 2021, 2:40:04 PM2/14/21
to
Am Sun, 14 Feb 2021 19:04:48 +0000
# lpinfo -v
file cups-brf:/
network beh
serial serial:/dev/ttyS0?baud=115200
network ipp
network https
network socket
network ipps
network lpd
network http
network smb
>
> and
>
> ippfind -T 5
# ippfind -T 5
~#
>
> Cheers,
>
> Brian.
Greetings
Michael
file cups-brf:/
network beh
serial serial:/dev/ttyS0?baud=115200
network ipp
network https
network socket
network ipps
network lpd
network http
network smb
>
> and
>
> ippfind -T 5
# ippfind -T 5
~#
>
> Cheers,
>
> Brian.
Greetings
Michael
Brian Potkin
Feb 15, 2021, 5:40:04 AM2/15/21
to
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.
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.
[...]
> # ippfind -T 5
> ~#
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.
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.
Till Kamppeter
Feb 15, 2021, 6:10:03 AM2/15/21
to
Alexander,
on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982742
Michael Hatzold (CCed) reports a problem with ipp-usb. The printer
provides a 7/1/4 interface on USB, meaning that it supports IPP-over-USB
and with this, according to the standards, driverless printing (and
scanning if it is a MFP).
This particular model seems to have some bug though. Due to it providing
7/1/4 ipp-usb attaches to it but it does not provide driverless IPP
printing then.
As this can possibly be a bug in ipp-usb or the need of a quirk
exception in ipp-usb, I want to ask you whether you could debug this
together with Michael as you also had made my scanner work together with me.
Thanks in advance.
Till
on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982742
Michael Hatzold (CCed) reports a problem with ipp-usb. The printer
provides a 7/1/4 interface on USB, meaning that it supports IPP-over-USB
and with this, according to the standards, driverless printing (and
scanning if it is a MFP).
This particular model seems to have some bug though. Due to it providing
7/1/4 ipp-usb attaches to it but it does not provide driverless IPP
printing then.
As this can possibly be a bug in ipp-usb or the need of a quirk
exception in ipp-usb, I want to ask you whether you could debug this
together with Michael as you also had made my scanner work together with me.
Thanks in advance.
Till
mh
Feb 15, 2021, 8:40:03 AM2/15/21
to
Am Mon, 15 Feb 2021 10:26:52 +0000
schrieb Brian Potkin <clarem...@gmail.com>:
> 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
configured.
>
> 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.
Thanks.
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.
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:
# /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
support
# lpstat -t
Zeitplandienst läuft
Keine systemvoreingestellten Ziele
Gerät für OKI_DATA_CORP_B432:
ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
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
ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
OKI_DATA_CORP_B432 permanent
ipp://localhost/printers/OKI_DATA_CORP_B432
ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
# 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
used.
@ 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)?
Thanks
Michael
schrieb Brian Potkin <clarem...@gmail.com>:
> 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.
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
configured.
>
> 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.
printer. So I could configure it using the vendor PPD file. Printing
menue (Libreoffice) shows one OKI printer. Print succeeded.
Thanks.
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.
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:
# /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
support
# lpstat -t
Zeitplandienst läuft
Keine systemvoreingestellten Ziele
ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
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
ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
OKI_DATA_CORP_B432 permanent
ipp://localhost/printers/OKI_DATA_CORP_B432
ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
# 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
used.
@ 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)?
Thanks
Michael
Alexander Pevzner
Feb 15, 2021, 9:30:04 AM2/15/21
to
Michael,
On 2/15/21 2:01 PM, Till Kamppeter wrote:
> Michael Hatzold (CCed) reports a problem with ipp-usb. The printer
> provides a 7/1/4 interface on USB, meaning that it supports IPP-over-USB
> and with this, according to the standards, driverless printing (and
> scanning if it is a MFP).
I'm the author of ipp-usb, and I want to investigate this problem.
May I ask you to gather ipp-usb logs? To do so, please do the following:
1. Remove all old ipp-usb logs (rm /var/log/ipp-usb/*)
2. Restart ipp-usb and reproduce a problem
3. Send me all files from the /var/log/ipp-usb/ directory
--
Wishes, Alexander Pevzner (p...@apevzner.com)
On 2/15/21 2:01 PM, Till Kamppeter wrote:
> Michael Hatzold (CCed) reports a problem with ipp-usb. The printer
> provides a 7/1/4 interface on USB, meaning that it supports IPP-over-USB
> and with this, according to the standards, driverless printing (and
> scanning if it is a MFP).
May I ask you to gather ipp-usb logs? To do so, please do the following:
1. Remove all old ipp-usb logs (rm /var/log/ipp-usb/*)
2. Restart ipp-usb and reproduce a problem
3. Send me all files from the /var/log/ipp-usb/ directory
--
Wishes, Alexander Pevzner (p...@apevzner.com)
Till Kamppeter
Feb 15, 2021, 9:40:03 AM2/15/21
to
On 15/02/2021 14:27, mh wrote:
> I then investigated the LIVE-ISO. To my surprise ipp-usb is installed
> within the LIVE-ISO.
ipp-usb is part of the standard installation in Debian and Ubuntu, to
> I then investigated the LIVE-ISO. To my surprise ipp-usb is installed
> within the LIVE-ISO.
support printers which do driverless IPP printing. Standard-conforming
printers should work out-of-the-box with that.
> 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:
>
> # /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
>
by some process here, not knowing that it is actually ipp-usb and not
the "usblp" kernel module. The method for getting rid of the kernel
module seems no to remove the connection of ipp-usb.
> # systemctl list-units "ipp-usb*" | grep service
> ipp-usb.service loaded active running Daemon for IPP over USB printer
> support
>
> # lpstat -t
> Zeitplandienst läuft
> Keine systemvoreingestellten Ziele
> Gerät für OKI_DATA_CORP_B432:
> ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
> 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
> ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
> OKI_DATA_CORP_B432 permanent
> ipp://localhost/printers/OKI_DATA_CORP_B432
> ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/
>
Could you run these two commands:
lp -d OKI_B432_010E46_USB_ ~/.bashrc
lp -d OKI_DATA_CORP_B432 ~/.bashrc
Do you get something printed? If yes, by the first command? By the
second? Both?
> # avahi-browse -rt _ipp._tcp
> Command 'avahi-browse' not found, but can be installed with:
> apt install avahi-utils
>
sudo apt install avahi-utils
Then run the command again and post the output here.
>
> @ 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.
>
all is OK. But if it is not capable of that but pretends to be capable
then somewhere is a bug, in our software or in the printer, in the
latter case we caould perhaps work around in our software.
>
> 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.
Debian or Ubuntu? Or did you download it directly from Oki?
> 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)?
OpenPrinting (and this way to all distributions and also the PostScript
Printer Application).
Till
Brian Potkin
Feb 15, 2021, 10:20:04 AM2/15/21
to
On Mon 15 Feb 2021 at 14:27:59 +0100, mh wrote:
> Am Mon, 15 Feb 2021 10:26:52 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> > 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
> configured.
I've tried to help with understanding by quoting a wiki link.
> Am Mon, 15 Feb 2021 10:26:52 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> > 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
> configured.
> > 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.
> Thanks.
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.
https://wiki.debian.org/SystemPrinting#The_CUPS_Web_Interface
> 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.
have
--
bInterfaceClass 7 Printer
bInterfaceSubClass 1 Printer
bInterfaceProtocol 4
iInterface 6 OKI B432 IPP0
--
bInterfaceClass 7 Printer
bInterfaceSubClass 1 Printer
bInterfaceProtocol 4
iInterface 9 OKI B432 IPP1
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:
lpstat -e and avahi-browse give empty outputs on Debian unstable? Are
the Debian and Live ISO versions of ipp-usb the same?
Thank you for your detailed report.
Brian.
mh
Feb 15, 2021, 12:50:03 PM2/15/21
to
Am Mon, 15 Feb 2021 15:28:57 +0100
schrieb Till Kamppeter <till.ka...@gmail.com>:
Hi Till,
thanks for your efforts to help. But to avoid any confusion I summarize
the situation:
(A)
My printer works fine with this computer under the following
conditions:
Booting a LIVE-ISO (Debain/sid based ISO from siduction.org) or booting
an installation based on this LIVE-ISO which then got dist-upgraded.
On both installations I can configure and then print either using
OKI-B432_010E46_USB (which seams to be the driverless IPP printer) or
OKI_DATA_CORP_B432 (which seams to be the printer configured using the
vendor PPD file). No problem whatsoever (allthough avahi-utils not
installed here).
(B)
The problem occured in my years old comprehensive installation which I
use daily. Here the printer used to work
initially (printer bought 2017) until it stopped working about a year
ago.
Now, with Brians help, we could narrow down the problem to ipp-usb
not working correctly. On this installation, removing ipp-usb makes
the printer visible and configurable using the vendor PPD file in the
cups administration. (BTW, avahi-utils installed here).
So my overall conclusion is the following:
(A) indicates, there is no HW failure and ipp-usb works fine and
reliably with this printer.
(B) There is a flaw somewhere within this installation which *affects*
ipp-usb without ipp-usb neccessarily being the cause.
So if we still dig deeper into this it boils down to searching for
whatever flaw prevents ipp-usb to work correctly *on this installation
(B)*.
I therefor reinstalled ipp-usb here (B).
I am not sure whether it's worth to investigate the (A) situation, as
there all is working fine. But as you think
> lp -d OKI_B432_010E46_USB_ ~/.bashrc
> lp -d OKI_DATA_CORP_B432 ~/.bashrc
Both commands successfully printed.
Note: this is not the installation I have problems with!
The same on the problematic installation (B) with ipp-usb reinstalled
and rebooted:
$ lp -d OKI_B432_010E46_USB_ ~/.bashrc
lp: Error - The printer or class does not exist.
~$ lp -d OKI_DATA_CORP_B432 ~/.bashrc
Anfrage-ID ist OKI_DATA_CORP_B432-5 (1 Datei(en))
but NO print. And in the cups joblist the same long known error:
"Warte darauf dass der Drucker verfügbar wird."
Waiting for the printer to become available
And the printer's little LCD is showing: Ready to print.
And the moment I purge ipp-usb again, the printer starts to
print without the job being sent again.
> >
> > 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.
>
> What do you mean with this? Is there a PPD for your printer included
> in Debian or Ubuntu? Or did you download it directly from Oki?
>
> > 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)?
>
> If the PPDs are under a free software license we can add them to
> OpenPrinting (and this way to all distributions and also the
> PostScript Printer Application).
>
> Till
No PPD on Debian or Ubuntu, and yes, I downloaded directly from OKI:
https://www.oki.com/de/printing/support/drivers-and-utilities/?id=46398401FZ01&tab=drivers-and-utilities&productCategory=mono&sku=45762012&os=ab33&lang=ac5
The licence shown on this site is rather restricted.
I file a wish-bug as suggested by Brian.
Regards
Michael
schrieb Till Kamppeter <till.ka...@gmail.com>:
Hi Till,
thanks for your efforts to help. But to avoid any confusion I summarize
the situation:
(A)
My printer works fine with this computer under the following
conditions:
Booting a LIVE-ISO (Debain/sid based ISO from siduction.org) or booting
an installation based on this LIVE-ISO which then got dist-upgraded.
On both installations I can configure and then print either using
OKI-B432_010E46_USB (which seams to be the driverless IPP printer) or
OKI_DATA_CORP_B432 (which seams to be the printer configured using the
vendor PPD file). No problem whatsoever (allthough avahi-utils not
installed here).
(B)
The problem occured in my years old comprehensive installation which I
use daily. Here the printer used to work
initially (printer bought 2017) until it stopped working about a year
ago.
Now, with Brians help, we could narrow down the problem to ipp-usb
not working correctly. On this installation, removing ipp-usb makes
the printer visible and configurable using the vendor PPD file in the
cups administration. (BTW, avahi-utils installed here).
So my overall conclusion is the following:
(A) indicates, there is no HW failure and ipp-usb works fine and
reliably with this printer.
(B) There is a flaw somewhere within this installation which *affects*
ipp-usb without ipp-usb neccessarily being the cause.
So if we still dig deeper into this it boils down to searching for
whatever flaw prevents ipp-usb to work correctly *on this installation
(B)*.
I therefor reinstalled ipp-usb here (B).
there all is working fine. But as you think
DEBUG: Failed to detach "usblp" module from 06bc:0357
points to a problem, I'll do some testing:
> lp -d OKI_B432_010E46_USB_ ~/.bashrc
> lp -d OKI_DATA_CORP_B432 ~/.bashrc
Note: this is not the installation I have problems with!
The same on the problematic installation (B) with ipp-usb reinstalled
and rebooted:
$ lp -d OKI_B432_010E46_USB_ ~/.bashrc
lp: Error - The printer or class does not exist.
~$ lp -d OKI_DATA_CORP_B432 ~/.bashrc
Anfrage-ID ist OKI_DATA_CORP_B432-5 (1 Datei(en))
but NO print. And in the cups joblist the same long known error:
"Warte darauf dass der Drucker verfügbar wird."
Waiting for the printer to become available
And the printer's little LCD is showing: Ready to print.
And the moment I purge ipp-usb again, the printer starts to
print without the job being sent again.
> >
> > 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.
>
> What do you mean with this? Is there a PPD for your printer included
> in Debian or Ubuntu? Or did you download it directly from Oki?
>
> > 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)?
>
> If the PPDs are under a free software license we can add them to
> OpenPrinting (and this way to all distributions and also the
> PostScript Printer Application).
>
> Till
https://www.oki.com/de/printing/support/drivers-and-utilities/?id=46398401FZ01&tab=drivers-and-utilities&productCategory=mono&sku=45762012&os=ab33&lang=ac5
The licence shown on this site is rather restricted.
I file a wish-bug as suggested by Brian.
Regards
Michael
Till Kamppeter
Feb 15, 2021, 1:00:03 PM2/15/21
to
OK, no I understand, fresh installation or live ISO all works perfectly
as intended, old installation shows the problem, so further
investigations only on the old installation ...
Till
as intended, old installation shows the problem, so further
investigations only on the old installation ...
Till
Brian Potkin
Feb 15, 2021, 2:10:03 PM2/15/21
to
On Mon 15 Feb 2021 at 18:40:25 +0100, mh wrote:
> Am Mon, 15 Feb 2021 15:28:57 +0100
> schrieb Till Kamppeter <till.ka...@gmail.com>:
>
> Hi Till,
>
> thanks for your efforts to help. But to avoid any confusion I summarize
> the situation:
>
> (A)
> My printer works fine with this computer under the following
> conditions:
> Booting a LIVE-ISO (Debain/sid based ISO from siduction.org) or booting
> an installation based on this LIVE-ISO which then got dist-upgraded.
siduction is based on Debian unstable, so, if (A) and (B) are fully
> Am Mon, 15 Feb 2021 15:28:57 +0100
> schrieb Till Kamppeter <till.ka...@gmail.com>:
>
> Hi Till,
>
> thanks for your efforts to help. But to avoid any confusion I summarize
> the situation:
>
> (A)
> My printer works fine with this computer under the following
> conditions:
> Booting a LIVE-ISO (Debain/sid based ISO from siduction.org) or booting
> an installation based on this LIVE-ISO which then got dist-upgraded.
uo to date, the printing systems should be identical. You have shown
that ipp-usb works fine on the siduction installation. That is what
(to me at least) is so puzzling.
I realise you are now happy with your printing situation, so thanks
for continuing to engage with this ipp-usb issue.
> On both installations I can configure and then print either using
> OKI-B432_010E46_USB (which seams to be the driverless IPP printer) or
> OKI_DATA_CORP_B432 (which seams to be the printer configured using the
> vendor PPD file). No problem whatsoever (allthough avahi-utils not
> installed here).
>
>
> (B)
> The problem occured in my years old comprehensive installation which I
> use daily. Here the printer used to work
> initially (printer bought 2017) until it stopped working about a year
> ago.
> Now, with Brians help, we could narrow down the problem to ipp-usb
> not working correctly. On this installation, removing ipp-usb makes
> the printer visible and configurable using the vendor PPD file in the
> cups administration. (BTW, avahi-utils installed here).
>
> So my overall conclusion is the following:
> (A) indicates, there is no HW failure and ipp-usb works fine and
> reliably with this printer.
> (B) There is a flaw somewhere within this installation which *affects*
> ipp-usb without ipp-usb neccessarily being the cause.
> > lp -d OKI_B432_010E46_USB_ ~/.bashrc
> > lp -d OKI_DATA_CORP_B432 ~/.bashrc
>
> Both commands successfully printed.
> Note: this is not the installation I have problems with!
>
>
>
> The same on the problematic installation (B) with ipp-usb reinstalled
> and rebooted:
>
> $ lp -d OKI_B432_010E46_USB_ ~/.bashrc
> lp: Error - The printer or class does not exist.
>
> ~$ lp -d OKI_DATA_CORP_B432 ~/.bashrc
> Anfrage-ID ist OKI_DATA_CORP_B432-5 (1 Datei(en))
>
> but NO print. And in the cups joblist the same long known error:
>
> "Warte darauf dass der Drucker verfügbar wird."
> Waiting for the printer to become available
>
> And the printer's little LCD is showing: Ready to print.
>
> And the moment I purge ipp-usb again, the printer starts to
> print without the job being sent again.
systemctl stop ipp-usb
Do you get an output from 'lpstat -l -e'?
> > > 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.
> >
> > What do you mean with this? Is there a PPD for your printer included
> > in Debian or Ubuntu? Or did you download it directly from Oki?
> >
> > > 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)?
> >
> > If the PPDs are under a free software license we can add them to
> > OpenPrinting (and this way to all distributions and also the
> > PostScript Printer Application).
> >
> > Till
>
> No PPD on Debian or Ubuntu, and yes, I downloaded directly from OKI:
>
> https://www.oki.com/de/printing/support/drivers-and-utilities/?id=46398401FZ01&tab=drivers-and-utilities&productCategory=mono&sku=45762012&os=ab33&lang=ac5
>
> The licence shown on this site is rather restricted.
Cheers,
Brian.
mh
Feb 15, 2021, 3:40:04 PM2/15/21
to
Am Mon, 15 Feb 2021 18:57:44 +0000
schrieb Brian Potkin <clarem...@gmail.com>:
> ...
last year. I was about to buy a new printer ... until, as a
last-ditch attempt I wrote this bug report. So thanks again.
But the thing that makes me hesitant is the following: I migrated his
installation multiple times from one partition and disk to another. And
it once had serious systemd problems during a dist-upgrade due to the
drive giving up slowly. I could
repair/overwrite/reinstall/whatever-one-would-call-it this installtion
years ago. And it worked since. But I can't exclude there's a sutble
flaw hidden in some corner.
On the bright side: The printer worked the first years.
> ...
> > The same on the problematic installation (B) with ipp-usb
> > reinstalled and rebooted:
> >
> > $ lp -d OKI_B432_010E46_USB_ ~/.bashrc
> > lp: Error - The printer or class does not exist.
> >
> > ~$ lp -d OKI_DATA_CORP_B432 ~/.bashrc
> > Anfrage-ID ist OKI_DATA_CORP_B432-5 (1 Datei(en))
> >
> > but NO print. And in the cups joblist the same long known error:
> >
> > "Warte darauf dass der Drucker verfügbar wird."
> > Waiting for the printer to become available
> >
> > And the printer's little LCD is showing: Ready to print.
> >
> > And the moment I purge ipp-usb again, the printer starts to
> > print without the job being sent again.
>
> Just to clear up something: would you stop ipp-usb on (B):
>
> systemctl stop ipp-usb
>
> Do you get an output from 'lpstat -l -e'?
# systemctl stop ipp-usb
~#
# lpstat -l -e
OKI_DATA_CORP_B432 permanent
ipp://localhost/printers/OKI_DATA_CORP_B432
usb://OKI%20DATA%20CORP/B432?serial=AK76039718
> ...
> The file I downloaded has the PPDs under the General Public License.
Didn't know PPD is text. You are right. That's in contrast to what the
linked document on the website says. All the better. I updated my
wishlist bug accordingly.
>
> Cheers,
>
> Brian.
Thanks
Michael
schrieb Brian Potkin <clarem...@gmail.com>:
> ...
> siduction is based on Debian unstable, so, if (A) and (B) are fully
> uo to date, the printing systems should be identical. You have shown
> that ipp-usb works fine on the siduction installation. That is what
> (to me at least) is so puzzling.
The same goes for me. That's the situation which drove me crazy the
> uo to date, the printing systems should be identical. You have shown
> that ipp-usb works fine on the siduction installation. That is what
> (to me at least) is so puzzling.
last year. I was about to buy a new printer ... until, as a
last-ditch attempt I wrote this bug report. So thanks again.
>
> I realise you are now happy with your printing situation, so thanks
> for continuing to engage with this ipp-usb issue.
Sure. See above ;-)
> I realise you are now happy with your printing situation, so thanks
> for continuing to engage with this ipp-usb issue.
But the thing that makes me hesitant is the following: I migrated his
installation multiple times from one partition and disk to another. And
it once had serious systemd problems during a dist-upgrade due to the
drive giving up slowly. I could
repair/overwrite/reinstall/whatever-one-would-call-it this installtion
years ago. And it worked since. But I can't exclude there's a sutble
flaw hidden in some corner.
On the bright side: The printer worked the first years.
> ...
> > (B) There is a flaw somewhere within this installation which
> > *affects* ipp-usb without ipp-usb neccessarily being the cause.
>
> A fair assessment.
> ...
> > *affects* ipp-usb without ipp-usb neccessarily being the cause.
>
> A fair assessment.
> > The same on the problematic installation (B) with ipp-usb
> > reinstalled and rebooted:
> >
> > $ lp -d OKI_B432_010E46_USB_ ~/.bashrc
> > lp: Error - The printer or class does not exist.
> >
> > ~$ lp -d OKI_DATA_CORP_B432 ~/.bashrc
> > Anfrage-ID ist OKI_DATA_CORP_B432-5 (1 Datei(en))
> >
> > but NO print. And in the cups joblist the same long known error:
> >
> > "Warte darauf dass der Drucker verfügbar wird."
> > Waiting for the printer to become available
> >
> > And the printer's little LCD is showing: Ready to print.
> >
> > And the moment I purge ipp-usb again, the printer starts to
> > print without the job being sent again.
>
> Just to clear up something: would you stop ipp-usb on (B):
>
> systemctl stop ipp-usb
>
> Do you get an output from 'lpstat -l -e'?
~#
# lpstat -l -e
OKI_DATA_CORP_B432 permanent
ipp://localhost/printers/OKI_DATA_CORP_B432
usb://OKI%20DATA%20CORP/B432?serial=AK76039718
> ...
> The file I downloaded has the PPDs under the General Public License.
linked document on the website says. All the better. I updated my
wishlist bug accordingly.
>
> Cheers,
>
> Brian.
Thanks
Michael
Brian Potkin
Feb 15, 2021, 3:50:04 PM2/15/21
to
On Mon 15 Feb 2021 at 19:36:29 +0100, mh wrote:
> Am Mon, 15 Feb 2021 15:12:49 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> Only for curiosity:
> On systems where there is NO problem, why do I see one printer in cups
> config (network printer) resulting in two printers in the printing menu?
Possibly because one is a manual queue and one a cups-browsed queue.
https://wiki.debian.org/CUPSDriverlessPrinting#dups
Follow our wiki advice or purge cups-browsed.
> > 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?
>
> It is all Debian/unstable. And it does not depend on the version of
> ipp-usb ( 0.9.16-1 and 0.9.17-1 ). Both work on live-iso (from
> 2021.02, the 2020.07 version didn't ship ipp-usb ) or new installation
> (2021.02 dist-upgraded), neither work with my old installation. I know
> this for a fact because the problem persist longer than 0.9.17-1 exists.
>
> I can live without ipp-usb working on this installation. But if someone
> tells me how to investigate the flaw, I am happy to investigate, too.
I have asked for a little bit of information about lpstat in another
post. Maybe the ipp-usb logs Alex requested logs may help. Otherwise,
I am at a loss to suggest a good debugging technique.
Awaiting inspiration!
Brian.
> Am Mon, 15 Feb 2021 15:12:49 +0000
> schrieb Brian Potkin <clarem...@gmail.com>:
>
> Only for curiosity:
> On systems where there is NO problem, why do I see one printer in cups
> config (network printer) resulting in two printers in the printing menu?
Possibly because one is a manual queue and one a cups-browsed queue.
https://wiki.debian.org/CUPSDriverlessPrinting#dups
Follow our wiki advice or purge cups-browsed.
> > 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?
>
> ipp-usb ( 0.9.16-1 and 0.9.17-1 ). Both work on live-iso (from
> 2021.02, the 2020.07 version didn't ship ipp-usb ) or new installation
> (2021.02 dist-upgraded), neither work with my old installation. I know
> this for a fact because the problem persist longer than 0.9.17-1 exists.
>
> I can live without ipp-usb working on this installation. But if someone
> tells me how to investigate the flaw, I am happy to investigate, too.
I have asked for a little bit of information about lpstat in another
post. Maybe the ipp-usb logs Alex requested logs may help. Otherwise,
I am at a loss to suggest a good debugging technique.
Awaiting inspiration!
Brian.
mh
Feb 15, 2021, 4:40:04 PM2/15/21
to
Am Tue, 16 Feb 2021 00:00:47 +0300
schrieb Alexander Pevzner <p...@apevzner.com>:
> Hi Michael,
>
> On 2/15/21 11:45 PM, mh wrote:
> > Thanks. Let me know any time how I can help.
>
> Thanks for logs. Looks like something goes wrong with Avahi. To
> check, please do the following experiment.
>
> 1. From one console, run: avahi-publish -s test _test._tcp 0
>
> This command should print "Established under name 'test'", and should
> not exit.
That's how it is.
>
> 2. From another console, run: avahi-browse -rt _test._tcp
>
> I want to see output of this command.
No output:
# avahi-browse -rt _test._tcp
~#
>
> And one more question: what Debian version do you use
it is Debian/sid(uction) up to date, booted with
# uname -r
5.10.0-3-amd64
standard Debian Kernel. (this siduction installation was made based on a
siduction live-ISO years ago)
Siduction is pure Debian/sid with some artwork and own kernel (not
booted here).
> and what Avahi
> version do you use?
>
avahi-daemon:
Installiert: 0.8-5
avahi-utils:
Installiert: 0.8-5
Thanks
Michael
schrieb Alexander Pevzner <p...@apevzner.com>:
> Hi Michael,
>
> On 2/15/21 11:45 PM, mh wrote:
> > Thanks. Let me know any time how I can help.
>
> Thanks for logs. Looks like something goes wrong with Avahi. To
> check, please do the following experiment.
>
> 1. From one console, run: avahi-publish -s test _test._tcp 0
>
> This command should print "Established under name 'test'", and should
> not exit.
That's how it is.
>
> 2. From another console, run: avahi-browse -rt _test._tcp
>
> I want to see output of this command.
No output:
# avahi-browse -rt _test._tcp
~#
>
> And one more question: what Debian version do you use
it is Debian/sid(uction) up to date, booted with
# uname -r
5.10.0-3-amd64
standard Debian Kernel. (this siduction installation was made based on a
siduction live-ISO years ago)
Siduction is pure Debian/sid with some artwork and own kernel (not
booted here).
> and what Avahi
> version do you use?
>
avahi-daemon:
Installiert: 0.8-5
avahi-utils:
Installiert: 0.8-5
Thanks
Michael
Alexander Pevzner
Feb 15, 2021, 5:20:04 PM2/15/21
to
Hi,
with a help of Michael, I've investigated this problem down to its root
cause, which appeared to be a misbehabing Avahi daemon.
If in one console the following command is being running:
avahi-browse -rt _test._tcp
As I'm not very familiar with Avahi troubleshooting, any help or ideas
are welcome.
with a help of Michael, I've investigated this problem down to its root
cause, which appeared to be a misbehabing Avahi daemon.
If in one console the following command is being running:
avahi-publish -s test _test._tcp 0
The following command running in another console prints nothing:
avahi-browse -rt _test._tcp
As I'm not very familiar with Avahi troubleshooting, any help or ideas
are welcome.
mh
Feb 15, 2021, 6:10:08 PM2/15/21
to
Am Tue, 16 Feb 2021 01:11:32 +0300
schrieb Alexander Pevzner <p...@apevzner.com>:
Hi Alexander. Thanks for helping here.
>
> As I'm not very familiar with Avahi troubleshooting, any help or
> ideas are welcome.
>
Do you suspect some configuration issue or anything which leaves traces
within the file system?
If so, is there a way (other than comparing file by file looking at it)
to compare the avahi settings (or whatever) of my working installation
with to one not working?
I could mount one system somewhere into the other. Is there a
software or command to compare the relevant directories? Would this
help at all?
Or would it help to purge avahi* together with the few depending
packages and reinstall them?
Greetings
Michael
schrieb Alexander Pevzner <p...@apevzner.com>:
Hi Alexander. Thanks for helping here.
>
> As I'm not very familiar with Avahi troubleshooting, any help or
> ideas are welcome.
>
within the file system?
If so, is there a way (other than comparing file by file looking at it)
to compare the avahi settings (or whatever) of my working installation
with to one not working?
I could mount one system somewhere into the other. Is there a
software or command to compare the relevant directories? Would this
help at all?
Or would it help to purge avahi* together with the few depending
packages and reinstall them?
Greetings
Michael
mh
Feb 15, 2021, 8:40:02 PM2/15/21
to
Hi to all,
comparing avahi settings was much less pain then I expected.
On the installation with ipp-usb not working the file
/etc/avahi/avahi-daemon.conf
had an active (non commented out) line:
allow-interfaces=eth9
On my installation with ipp-usb working this line in the respective
file reads:
#allow-interfaces=eth0
So it is commented out and names a different interface.
After commenting out this line in the problematic installation the
printer is visible and configurable in the cups administration. As with
the other installations, two printers show up in the print menue
(Libreoffice) and I can print successfully.
I have no idea how this setting ended up in /etc/avahi/avahi-daemon.conf
Thanks to all who helped finding the flaw. Feel free to contact me if
you think I could help here in the region where I live (Aachen/Germany).
Greetings
Michael
comparing avahi settings was much less pain then I expected.
On the installation with ipp-usb not working the file
/etc/avahi/avahi-daemon.conf
had an active (non commented out) line:
allow-interfaces=eth9
On my installation with ipp-usb working this line in the respective
file reads:
#allow-interfaces=eth0
So it is commented out and names a different interface.
After commenting out this line in the problematic installation the
printer is visible and configurable in the cups administration. As with
the other installations, two printers show up in the print menue
(Libreoffice) and I can print successfully.
I have no idea how this setting ended up in /etc/avahi/avahi-daemon.conf
Thanks to all who helped finding the flaw. Feel free to contact me if
you think I could help here in the region where I live (Aachen/Germany).
Greetings
Michael
Alexander Pevzner
Feb 16, 2021, 1:40:03 AM2/16/21
to
On 2/16/21 4:31 AM, mh wrote:
> comparing avahi settings was much less pain then I expected.
Congratulations!
> comparing avahi settings was much less pain then I expected.
> had an active (non commented out) line:
>
> allow-interfaces=eth9
interfaces, including the loopback interface.
Nice that this problem has been finally solved.
0 new messages