Reactivating printing for Kyocera P6021cdn

I could occasionally print something also with my local device.
Unfortunately, I observed that another print test for a small text file with a program like KWrite 25.04.1 does not work as expected at the moment.

Markus_Elfring@Sonne:~> lsusb
…
Bus 001 Device 005: ID 0482:063e Kyocera Corp. Kyocera ECOSYS P6021cdn
…

I took also another look into the “Connection Wizard” of the system configuration module “YaST2 printer”.
I wonder why no connection settings are displayed for the USB port there.

The driver “ECOSYS P6021cdn KPDL” was accordingly configured so far.
The test page printout succeeded once more.

:eyes: It seems that the file “/var/log/cups/error_log” does not directly indicate clues for undesirable software behaviour today.

I would appreciate further advices.

Supports AirPrint, Mopria, PCL 6, PostScript 3, etc.
Can work without Kyocera drivers.

Open CUPS in your browser by going to http://localhost:631/

Here you should be able to find the printer and print a test page.

The OP claimed that a test print did succeed. What might be useful is to see the print queue as currently defined…

lpstat -t
and verbose output from
lsusb -v
(Specifically the output block pertaining to the printer device)

The OP should also know that this printer is supported by IPP apparently (no driver required)…

For a USB connected printer, ipp-usb needs to be installed first, then the printer will appear as a localhost connected device. CUPS should automatically find it.

https://man.archlinux.org/man/extra/ipp-usb/ipp-usb.8.en

I am trying to find adjustments for an other printer model.

Use the CUPS web interface:
http://localhost:631/printers/

:thought_balloon: This would be nice also for my system.

Markus_Elfring@Sonne:~> rpm -qi ipp-usb
…
Source RPM  : ipp-usb-0.9.30-1.1.src.rpm
Build Date  : Mo 17 Mär 2025 23:22:14 CET
…

It seems that some configuration challenges need still to be resolved for the desired printer detection. :thinking:
I would appreciate further hints for the selection of corresponding IPP-USB settings.

I find the following information questionable.

Sonne:~ # systemctl restart ipp-usb && ipp-usb status && systemctl status ipp-usb
Get "http://localhost/status": ipp-usb daemon not running
…
     Loaded: loaded (/usr/lib/systemd/system/ipp-usb.service; enabled; preset: disabled)
     Active: active (running) since Tue 2025-05-27 18:10:29 CEST; 37ms ago
…
        CPU: 20ms
…
May 27 18:10:29 Sonne systemd[1]: Started Daemon for IPP over USB printer support.
May 27 18:10:29 Sonne systemd[1]: ipp-usb.service: Deactivated successfully.

:crystal_ball: How will the clarification evolve further for such software components?

That is how it is designed. The service triggers when the rule in /usr/lib/udev/rules.d/71-ipp-usb.rules is matched.

Show the results from lsub -vwhen the printer is connected.

Background information:

Sonne:~ # lsusb -v
…
Bus 002 Device 005: ID 0482:063e Kyocera Corp. Kyocera ECOSYS P6021cdn
Negotiated speed: High Speed (480Mbps)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0482 Kyocera Corp.
  idProduct          0x063e Kyocera ECOSYS P6021cdn
  bcdDevice            0.00
  iManufacturer           1 Kyocera
  iProduct                2 Kyocera ECOSYS P6021cdn
  iSerial                 3 LW44818568
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0020
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         7 Printer
      bInterfaceSubClass      1 Printer
      bInterfaceProtocol      2 Bidirectional
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered
…

See also for further considerations:

Sonne:~ # ipp-usb check
Configuration files: OK
No IPP over USB devices found

Ok, this is the issue…

  bInterfaceClass         7 Printer
  bInterfaceSubClass      1 Printer
  bInterfaceProtocol      2 Bidirectional

The printer doesn’t advertise itself as capable of IPP support, despite it being listed online as supporting IPP. It might just be that it needs to be network connected. Have you considered connecting it to your LAN instead?

You could try creating a custom rule to handle the protocol it advertises eg “/etc/udev/rules.d/50-kyocera.rules” with

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:070102:*", OWNER="root", GROUP="lp", MODE="0664", TAG+="systemd", ENV{SYSTEMD_WANTS}+="ipp-usb.service"

No promises though.

:crystal_ball: Would such information become relevant for another “quirk”?

Not yet. ‒ :thought_balloon: The network interface is optional for this device, isn’t it?

Sorry, I don’t understand.

Yes, it is just an option. Use what you prefer.

Back to your first post in this topic…

Can you explain what happened? How did the print job fail? No printing occurred, or some other issue?

I have tried the proposed rule addition out.
Unfortunately, I wonder still about the following information.

Sonne:~ # ipp-usb check
Configuration files: OK
No IPP over USB devices found

Forget trying to use that then (at least while you are using the printer via USB). Remove the custom rule. Return to your opening post and answer my questions about that.

:crystal_ball: Can further refinements become helpful for device rule properties?
Is there a need to reconsider the filter for a field like bInterfaceProtocol any more?

  • The print attempt is indicated by a printer icon in the notification area of my desktop session.
  • I can click on the corresponding icon.
  • I get informed that a device is in use according to the processing “Sending data to printer” (while a circle keeps turning there).

:eyes: I can inspect the printer waiting queue accordingly.
The information “Filter failed” is displayed there.

Yes. (I cancelled such “activities” after a while.)

:thought_balloon: Questionable software dependencies?

I have noticed a moment ago that the file “/var/log/cups/error_log” contains information (like the following) for a few print attempts.

…
D [28/May/2025:08:21:41 +0200] [Job 142] Printing on printer with URI: usb://Kyocera/ECOSYS%20P6021cdn?serial=LW44818568
D [28/May/2025:08:21:41 +0200] [Job 142] File \"/usr/lib/cups/filter/kyofilter_pre_H\", line 12, in <module>
D [28/May/2025:08:21:41 +0200] [Job 142] from PyPDF3 import PdfFileWriter, PdfFileReader
D [28/May/2025:08:21:41 +0200] [Job 142] ModuleNotFoundError: No module named \'PyPDF3\'
D [28/May/2025:08:21:41 +0200] [Job 142] libusb_get_device_list=8
D [28/May/2025:08:21:41 +0200] [Job 142] STATE: +connecting-to-device
…

:crystal_ball: Under which circumstances can such a software dependency become usable again?

No, there isn’t.