Also I can't scan anything with Simple Scan, but surely that's due to the same issue.

Hi Michael,

(In reply to Michael Catanzaro from comment #0)
> Mar 21 20:19:23 chargestone-cave hp[3559]: io/hpmud/musb.c 515: invalid
> claim_interface 7/1/4: Device or resource busy

this message tells us (in addition to the original meaning of the message :) ) your device is actually capable of IPP-over-USB device, so no hplip and its proprietary plugin are needed for your device to work :) and it supports driverless printing at least. According supported devices[1] for sane-airscan, the device supports eSCL as well, so driverless scanning for you as well :) .

For printing, you can remove the old print queue and either work with CUPS temporary queue[2], which is supported by modern print dialogs, or install the new queue permanently by:

$ lpadmin -p <queue_name> -v ipp://localhost:60000/ipp/print -m everywhere -E

For scanning, sane-airscan should automatically kick in - are you sure there isn't another device in Simple Scan dialog, where you choose the device for scanning?

In case you don't have other HP device and ipp-usb meets your needs, you can remove hplip as whole itself. On the other hand, if hplip classic driver is better for you, ipp-usb-0.9.20 provides a quirk functionality, where you can block ipp-usb from taking the device.

More detailed info will arrive today on devel and users list.


[1] https://github.com/alexpevzner/sane-airscan
[2] https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/#_temporary_print_queues

Thanks for looking at this, Zdenek. I didn't realize that my printer was new enough for driverless printing. That's cool.

That said, understanding that I *can* uninstall hplip and *can* run that lpadmin command if I want my printer to work properly... I'm not going to do that, because I want to use the default out-of-the-box Fedora experience that other Fedora users will see. Hopefully there's a way to unbreak this without needing to do anything special.

> For scanning, sane-airscan should automatically kick in - are you sure there isn't another device in Simple Scan dialog, where you choose the device for scanning?

The only option provided by Simple Scan is "HP Officejet 4630 series"

(In reply to Michael Catanzaro from comment #3)
> Thanks for looking at this, Zdenek. I didn't realize that my printer was new
> enough for driverless printing. That's cool.

Well, the device has the IPP-over-USB interface at least :)

> 
> That said, understanding that I *can* uninstall hplip and *can* run that
> lpadmin command if I want my printer to work properly... I'm not going to do
> that, because I want to use the default out-of-the-box Fedora experience
> that other Fedora users will see. Hopefully there's a way to unbreak this
> without needing to do anything special.

Ok, so the default out-of-the-box Fedora experience is the temporary queue, which appears in modern print dialogs - GTK based dialog, Libreoffice. There's no way for the old print queue to work again with ipp-usb conflict on the port.

So for new installation the usage is the user doesn't install anything, so the users with old setup (installed print queue) are expected to remove the old print queue, or remove the driver package.

Ad print dialogs - some native print dialogs still does not support the temporary queues :( - I've tried to reach f.e. firefox maintainers https://bugzilla.redhat.com/show_bug.cgi?id=1983403 for adding the temp queue feature, but the conversation stopped from firefox people side...

So it would be great if you tried to print a PDF from evince to the temporary queue.

> 
> > For scanning, sane-airscan should automatically kick in - are you sure there isn't another device in Simple Scan dialog, where you choose the device for scanning?
> 
> The only option provided by Simple Scan is "HP Officejet 4630 series"

Hmm... can you check the printer settings on the device whether scanning settings are all enabled? According sane-airscan README, the device should support eSCL, so it would be great if you checked if all scanning connected settings are enabled on the device.

Once you verify that, please follow the steps for debugging sane-airscan[1], debugging discovery[2] and scanning process[3] via scanimage for now and attach the requested files.

Thank you in advance!

Zdenek

[1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Debugging_sane-airscan

[2] https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-problems/#_debugging_scanner_discovery

[3] https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-problems/#_debugging_scanning_process

(In reply to Zdenek Dohnal from comment #4)
> So for new installation the usage is the user doesn't install anything, so
> the users with old setup (installed print queue) are expected to remove the
> old print queue, or remove the driver package.

Can we make this happen automatically? Sounds like we are upgrading users from a working situation into a broken situation?

Is there any harm in removing the old print queue on upgrade? Will it get recreated if it's actually needed?

> So it would be great if you tried to print a PDF from evince to the temporary queue.

I will try to figure out how to do this.

> Hmm... can you check the printer settings on the device whether scanning settings are all enabled? According sane-airscan README, the device should support eSCL, so it would be great if you checked if all scanning connected settings are enabled on the device.

I don't know that the printer has any settings for scanning. Prior to F36, it was automatically detected by Simple Scan and worked fine via Simple Scan.

> Once you verify that, please follow the steps for debugging sane-airscan[1], debugging discovery[2] and scanning process[3] via scanimage for now and attach the requested files.

OK, will try this....

(In reply to Michael Catanzaro from comment #5)
> > So it would be great if you tried to print a PDF from evince to the temporary queue.
> 
> I will try to figure out how to do this.

Is the temporary queue not created if the original queue still exists? Again, I don't want to remove the original print queue since typical users upgrading from F35 will not know to do this.

(In reply to Michael Catanzaro from comment #5)
> Can we make this happen automatically? Sounds like we are upgrading users
> from a working situation into a broken situation?

It would be great if you read the email I'd sent to devel list. Unfortunately there is no automatic migrate path for this, so IMO an announcement is the best approach I can do. 

> 
> Is there any harm in removing the old print queue on upgrade?

See the email. Since the printer's being turned on during upgrade is unrealistic requirement, you would have needed to remove all USB print queues alike, even the ones which don't support IPP-over-USB.

Additionally, it won't work on Silverblue and maybe CoreOS?, since RPM scriptlets are run on the server side (that's what I recall from conversation when systemd-resolved went into Fedora - there was an issue which was supposed to be fixed by scriptlet, and Colin Walters mentioned there it won't work on Silverblue, because scriptlets are run differently there...).

> Will it get
> recreated if it's actually needed?

Permanent queues are not recreated - basically a permanent queue is a classic printer installation from the past. You need an user intervention to create one - so if you remove USB printers indiscriminately, users with no-IPP-over-USB printers will have to install the queue again (even if we ignore Silverblue).

> 
> > So it would be great if you tried to print a PDF from evince to the temporary queue.
> 
> I will try to figure out how to do this.

Hopefully, there isn't much to figure out (unless you modified Avahi) - you just open evince, open a PDF there and go to 'Print' - the queue should appear there right away.

If not, you can use this[1] for further debug.

> 
> > Hmm... can you check the printer settings on the device whether scanning settings are all enabled? According sane-airscan README, the device should support eSCL, so it would be great if you checked if all scanning connected settings are enabled on the device.
> 
> I don't know that the printer has any settings for scanning. Prior to F36,
> it was automatically detected by Simple Scan and worked fine via Simple Scan.

Since you'd mentioned there is only one scanning device in the dialog and it does not work, I've expected it is hpaio device (from hplip) and airscan backend didn't find anything, so it could mean eSCL is somehow disabled on the device - but we will see more from logs.

In reply to Michael Catanzaro from comment #6)
> Is the temporary queue not created if the original queue still exists?

The temporary queue is created regardless of original permanent queue, if the device is advertised by ipp-usb via mDNS. You can check it via 'avahi-browse -avrt' from 'avahi-tools'. 

> Again, I don't want to remove the original print queue since typical users
> upgrading from F35 will not know to do this.

That's why I've sent the email to users list as well.



[1] https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_setup_cups_temporary_queues_with_usb_printer

(In reply to Zdenek Dohnal from comment #7)
> It would be great if you read the email I'd sent to devel list.
> Unfortunately there is no automatic migrate path for this, so IMO an
> announcement is the best approach I can do. 

Oops, I missed it! I've read it now.

> > Is there any harm in removing the old print queue on upgrade?
> 
> See the email. Since the printer's being turned on during upgrade is
> unrealistic requirement, you would have needed to remove all USB print
> queues alike, even the ones which don't support IPP-over-USB.
> 
> Additionally, it won't work on Silverblue and maybe CoreOS?, since RPM
> scriptlets are run on the server side (that's what I recall from
> conversation when systemd-resolved went into Fedora - there was an issue
> which was supposed to be fixed by scriptlet, and Colin Walters mentioned
> there it won't work on Silverblue, because scriptlets are run differently
> there...).

Alas.

Anyway, I have manually deleted the old print queues via System Settings -> Printers -> Remove Printer.

> > > So it would be great if you tried to print a PDF from evince to the temporary queue.
> > 
> > I will try to figure out how to do this.
> 
> Hopefully, there isn't much to figure out (unless you modified Avahi) - you
> just open evince, open a PDF there and go to 'Print' - the queue should
> appear there right away.

Well it appears, but it is not usable. It gets stuck on "Getting printer information...". If I close the dialog and reopen, it says "Rejecting Jobs."
 
> If not, you can use this[1] for further debug.

Will try that next.

> Since you'd mentioned there is only one scanning device in the dialog and it
> does not work, I've expected it is hpaio device (from hplip) and airscan
> backend didn't find anything, so it could mean eSCL is somehow disabled on
> the device - but we will see more from logs.

OK, still need to get you these logs.

> In reply to Michael Catanzaro from comment #6)
> > Is the temporary queue not created if the original queue still exists?
> 
> The temporary queue is created regardless of original permanent queue, if
> the device is advertised by ipp-usb via mDNS. You can check it via
> 'avahi-browse -avrt' from 'avahi-tools'. 

Hm, it's there today. Maybe I just missed it before.

> Hmm... can you check the printer settings on the device whether scanning
> settings are all enabled? According sane-airscan README, the device should
> support eSCL, so it would be great if you checked if all scanning connected
> settings are enabled on the device.
> 
> Once you verify that, please follow the steps for debugging sane-airscan[1],
> debugging discovery[2] and scanning process[3] via scanimage for now and
> attach the requested files.
> 
> Thank you in advance!
> 
> Zdenek
> 
> [1]
> https://fedoraproject.org/wiki/How_to_debug_printing_problems#Debugging_sane-
> airscan
> 
> [2]
> https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-
> problems/#_debugging_scanner_discovery
> 
> [3]
> https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-
> problems/#_debugging_scanning_process

I will make a TODO to try this out and report a separate bug for my scanning woes.

> Well it appears, but it is not usable. It gets stuck on "Getting printer
> information...". If I close the dialog and reopen, it says "Rejecting Jobs."

I see this error in my journal:

Mar 27 14:51:06 chargestone-cave cupsd[2205]: HP_Officejet_4630_series_3DF5DF_USB: PPD creation failed: No IPP attributes.

> > If not, you can use this[1] for further debug.
> 
> Will try that next.

Briefly reviewing that link, I have no clue what you want me to do. :)

(I will probably need to remove ipp-usb soon, because I really do need to use my printer....)

(In reply to Michael Catanzaro from comment #10)
> > Well it appears, but it is not usable. It gets stuck on "Getting printer
> > information...". If I close the dialog and reopen, it says "Rejecting Jobs."
> 
> I see this error in my journal:
> 
> Mar 27 14:51:06 chargestone-cave cupsd[2205]:
> HP_Officejet_4630_series_3DF5DF_USB: PPD creation failed: No IPP attributes.
> 
> > > If not, you can use this[1] for further debug.
> > 
> > Will try that next.
> 
> Briefly reviewing that link, I have no clue what you want me to do. :)
> 
> (I will probably need to remove ipp-usb soon, because I really do need to
> use my printer....)

Is the print queue seen in every command except for the last 'lpinfo -l -v'?

If so, please try to print from Libreoffice and via 'lp' command (the queue name will find out from 'lpstat -e' which shows existing queues which cupsd can see - if you don't have any permanent queues installed - which you can find out by checking the list of accepting queues 'lpstat -a' - the only remaining is the temporary queue - let's say it is HP_Officejet_4630_series_3DF5DF_USB here):

$ lp -d HP_Officejet_4630_series_3DF5DF_USB <a pdf> -P 1

'-P 1' option's tuple is for printing only the first page, in case the pdf has more pages.

Does the printing work from Libreoffice and lp?

If it does, there can be a bug in GTK itself.

Once you find out the printing status from Libreoffice and lp, it would be great if you followed this link[1] and provided the requested information.

Thank you in advance for the cooperation and debugging!


Zdenek



[1] https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/#_my_printer_doesnt_print_correctly_or_at_all_but_i_can_see_the_printer_in_print_dialog

(In reply to Zdenek Dohnal from comment #11)
> Is the print queue seen in every command except for the last 'lpinfo -l -v'?

I really do not understand what commands you are asking me to run.

I do see the temporary print queue with 'lpstat -e':

$ lpstat -e
HP_Officejet_4630_series_3DF5DF_USB

And no permanent print queues remain, because I deleted them, because you asked me to:

$ lpstat -t
scheduler is running
no system default destination
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.

> If so, please try to print from Libreoffice 

Oh wow... that actually worked! LibreOffice is able to print without difficulty.

After printing once from LibreOffice, *I'm able to successfully print from evince again!* Looks like LibreOffice created a new permanent print queue?

$ lpstat -t
scheduler is running
no system default destination
device for HP_Officejet_4630_series_3DF5DF_USB: ipp://localhost:60000/ipp/print
HP_Officejet_4630_series_3DF5DF_USB accepting requests since Mon 28 Mar 2022 09:35:59 AM CDT
printer HP_Officejet_4630_series_3DF5DF_USB is idle.  enabled since Mon 28 Mar 2022 09:35:59 AM CDT

> and via 'lp' command (the queue
> name will find out from 'lpstat -e' which shows existing queues which cupsd
> can see - if you don't have any permanent queues installed - which you can
> find out by checking the list of accepting queues 'lpstat -a' - the only
> remaining is the temporary queue - let's say it is
> HP_Officejet_4630_series_3DF5DF_USB here):
> 
> $ lp -d HP_Officejet_4630_series_3DF5DF_USB <a pdf> -P 1
> 
> '-P 1' option's tuple is for printing only the first page, in case the pdf
> has more pages.
> 
> Does the printing work from Libreoffice and lp?

Printing from lp works fine too.
 
> If it does, there can be a bug in GTK itself.

Maybe.
 
> Once you find out the printing status from Libreoffice and lp, it would be
> great if you followed this link[1] and provided the requested information.

> [1]
> https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-
> problems/
> #_my_printer_doesnt_print_correctly_or_at_all_but_i_can_see_the_printer_in_pr
> int_dialog

OK, will try this next....

Hm, I'm once again unable to print from evince. It's back to "Getting printer information..." and "Rejecting jobs" like it was before.

The permanent queue seems to have disappeared from 'lpstat -t':

$ lpstat -t
scheduler is running
no system default destination
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.

Compare to what I saw before, right after printing from LibreOffice:

$ lpstat -t
scheduler is running
no system default destination
device for HP_Officejet_4630_series_3DF5DF_USB: ipp://localhost:60000/ipp/print
HP_Officejet_4630_series_3DF5DF_USB accepting requests since Mon 28 Mar 2022 09:35:59 AM CDT
printer HP_Officejet_4630_series_3DF5DF_USB is idle.  enabled since Mon 28 Mar 2022 09:35:59 AM CDT

If I try printing from LibreOffice again:

$ lpstat -t
scheduler is running
no system default destination
device for HP_Officejet_4630_series_3DF5DF_USB: ipp://localhost:60000/ipp/print
HP_Officejet_4630_series_3DF5DF_USB accepting requests since Mon 28 Mar 2022 09:47:25 AM CDT
printer HP_Officejet_4630_series_3DF5DF_USB now printing HP_Officejet_4630_series_3DF5DF_USB-204.  enabled since Mon 28 Mar 2022 09:47:25 AM CDT
	Rendering completed
HP_Officejet_4630_series_3DF5DF_USB-204 mcatanzaro       17408   Mon 28 Mar 2022 09:47:25 AM CDT

Then it looks like evince is willing to accept jobs again.

This time, printing from LibreOffice failed. It printed about half a page, then the printer got stuck. The printer itself says "Now printing..." but it just stopped halfway through the first page, and refused to continue until I pressed Cancel on the printer itself. This time, 'lpstat -t' shows:

$ lpstat -t
scheduler is running
no system default destination
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.

So it looks like LibreOffice does something that makes my printer work, but only for only a short while before it breaks again. And in this case, that happened only halfway through the first page. :D

Next: I should follow your "how to debug" instructions....

Created attachment 1868778 [details]
whole log

OK, a job log is probably not relevant because I cannot submit jobs from evince, so I attached a whole log. Hopefully there's something interesting there.

Other tasks:

 [-] attach your printer PPD file from /etc/cups/ppd/ if available: nothing there
 [-] attach the file you wanted to print: irrelevant, happens with all files
 [✓] tell what application you printed from: evince 42~rc-1.fc36
 [✓] mention your printer model: HP_Officejet_4630
 [✓] attach files with output of lsusb -v...: I assume it will suffice to attach just the printer
 [✓] and from /var/log/ipp-usb if the device is connected by USB: I will attach this entire directory in a private attachment since I'm not sure what all is there

Created attachment 1868781 [details]
lsusb

Created attachment 1868782 [details]
/var/log/ipp-usb

(In reply to Michael Catanzaro from comment #17)
> Created attachment 1868782 [details]
> /var/log/ipp-usb

(Everything here looks super boring, so I decided to make this attachment public.)

> Hmm... can you check the printer settings on the device whether scanning
> settings are all enabled? According sane-airscan README, the device should
> support eSCL, so it would be great if you checked if all scanning connected
> settings are enabled on the device.
> 
> Once you verify that, please follow the steps for debugging sane-airscan[1],
> debugging discovery[2] and scanning process[3] via scanimage for now and
> attach the requested files.
> 
> Thank you in advance!

I've reported bug #2069277 for this scanning issue.

(In reply to Michael Catanzaro from comment #13)
> Hm, I'm once again unable to print from evince. It's back to "Getting
> printer information..." and "Rejecting jobs" like it was before.

Temporary queue is basically a permanent queue, which gets found automatically and has a timer after which it disappears.

You were able to print from evince because you used a temporary queue created by Libreoffice.

> This time, printing from LibreOffice failed. It printed about half a page,
> then the printer got stuck. The printer itself says "Now printing..." but it
> just stopped halfway through the first page, and refused to continue until I
> pressed Cancel on the printer itself. This time, 'lpstat -t' shows:
> 
> $ lpstat -t
> scheduler is running
> no system default destination
> lpstat: No destinations added.
> lpstat: No destinations added.
> lpstat: No destinations added.
> lpstat: No destinations added.
> 
> So it looks like LibreOffice does something that makes my printer work, but
> only for only a short while before it breaks again. And in this case, that
> happened only halfway through the first page. :D

Haven't you had the Libreoffice print dialog opened for some time? I would expect the queue is created right after you've opened the dialog, and if the dialog does not implement any refresh, I can imagine something like this can happen.

From the cups log:

=====
Mar 28 10:42:34 chargestone-cave cupsd[118003]: add_printer_filter: HP_Officejet_4630_series_3DF5DF_USB: adding filter application/vnd.cups-postscript printer/HP_Officejet_4630_series_3DF5DF_USB 0 -
Mar 28 10:42:34 chargestone-cave cupsd[118003]: cupsdRegisterPrinter(p=0x560225debfb0(HP_Officejet_4630_series_3DF5DF_USB))
Mar 28 10:42:34 chargestone-cave cupsd[118003]: CUPS-Create-Local-Printer successful-ok: Local printer created.
Mar 28 10:42:34 chargestone-cave cupsd[118003]: add_printer_state_reasons(0x560225e79900[1025], 0x560225debfb0[HP_Officejet_4630_series_3DF5DF_USB])
...
Mar 28 10:42:34 chargestone-cave cupsd[118003]: HP_Officejet_4630_series_3DF5DF_USB: Generating PPD file from "ipp://chargestone-cave.local:60000/ipp/print"...
...
Mar 28 10:42:34 chargestone-cave cupsd[118003]: HP_Officejet_4630_series_3DF5DF_USB: Connected to chargestone-cave.local:60000, sending Get-Printer-Attributes request...
Mar 28 10:42:34 chargestone-cave cupsd[118003]: HP_Officejet_4630_series_3DF5DF_USB: Get-Printer-Attributes returned server-error-internal-error (Success)
Mar 28 10:42:34 chargestone-cave cupsd[118003]: HP_Officejet_4630_series_3DF5DF_USB: PPD creation failed: No IPP attributes.
=====

IPP response for IPP request get-printer-attributes failed with internal error, that's why PPD creation failed.

ipp-usb log doesn't show anything out of the order for 10:42:34:

====
28-03-2022 10:42:34: < USB[1]: read: wanted 4096 got 0 total 0
28-03-2022 10:42:34: ! USB[1]: zero-size read
====

I've checked 9:42:34 as well (time shift at the weekend :)) but no IPP communication happened there neither.

Can you run the same request which cupsd did with ipptool?

$ ipptool -tv ipp://chargestone-cave.local:60000/ipp/print get-printer-attributes.test

Now when I think about it:

Working case:

(In reply to Michael Catanzaro from comment #13)
> device for HP_Officejet_4630_series_3DF5DF_USB: ipp://localhost:60000/ipp/print
                                                        ^^^^^^^^^

Not working case:

(In reply to Zdenek Dohnal from comment #20)
> Mar 28 10:42:34 chargestone-cave cupsd[118003]: HP_Officejet_4630_series_3DF5DF_USB: Generating PPD file from
> "ipp://chargestone-cave.local:60000/ipp/print"...
         ^^^^^^^^^^^^^^^^^^^^^^

I'm starting to smell some mDNS problem...

With the printer turned on:

$ ipptool -tv ipp://chargestone-cave.local:60000/ipp/print get-printer-attributes.test
"/usr/share/cups/ipptool/get-printer-attributes.test":
    Get-Printer-Attributes:
        attributes-charset (charset) = utf-8
        attributes-natural-language (naturalLanguage) = en
        printer-uri (uri) = ipp://chargestone-cave.local:60000/ipp/print
        requested-attributes (1setOf keyword) = all,media-col-database
    Get printer attributes using get-printer-attributes                  [FAIL]
        RECEIVED: 0 bytes in response
        status-code = server-error-service-unavailable (Host is down)
        IPP request failed with status server-error-service-unavailable (Host is down)

Just for fun, I also tried:

$ ipptool -tv ipp://localhost:60000/ipp/print get-printer-attributes.test
"/usr/share/cups/ipptool/get-printer-attributes.test":
    Get-Printer-Attributes:
        attributes-charset (charset) = utf-8
        attributes-natural-language (naturalLanguage) = en
        printer-uri (uri) = ipp://localhost:60000/ipp/print
        requested-attributes (1setOf keyword) = all,media-col-database
    Get printer attributes using get-printer-attributes                  [FAIL]
        RECEIVED: 0 bytes in response
        status-code = server-error-internal-error (No request sent.)
        IPP request failed with status server-error-internal-error (No request sent.)

BTW: I notice that printing from LibreOffice no longer works since I uninstalled hplip, and reinstalling it (and adding the printer again in System Settings -> Printers) doesn't help. Seems like removing hplip was a pretty big mistake, since I really do need to print stuff. :D

Ok, I've gone to our minilab with ipp-over-usb supported printer (Canon MF 440) just to make sure.

Both ipptool requests passed for me, I was able to print from all apps we mentioned - evince, libreoffice, lp.

So it looks like an issue with the specific model, or you've hit a specific situation - in the past it looked the printer's sleep mode was causing issues - wasn't printer in sleep mode? Was ipp-usb running during those requests?

After uninstalling hplip and removing the printer in System Settings, even the temporary queue is gone. I don't know how to get the temporary queue back.

Trying to get back to a working state, I've now reinstalled hplip and uninstalled ipp-usb. However, my printer is still totally busted. Unless you have any grand ideas, I'm likely going to have to reinstall F35, because I really need to print my tax forms. :P I thought removing ipp-usb and reinstalling hplip would be sufficient to restore me to the way printing worked in F35?

(In reply to Zdenek Dohnal from comment #23)
> Ok, I've gone to our minilab with ipp-over-usb supported printer (Canon MF
> 440) just to make sure.
> 
> Both ipptool requests passed for me, I was able to print from all apps we
> mentioned - evince, libreoffice, lp.
> 
> So it looks like an issue with the specific model, or you've hit a specific
> situation - in the past it looked the printer's sleep mode was causing
> issues - wasn't printer in sleep mode?

Well the printer's display is always off except for a minute or two after printing something or if I touch it. So yeah, maybe it was in sleep mode. Of course that shouldn't stop it from printing.

> Was ipp-usb running during those
> requests?

I'm not sure. I can't go back and check because the temporary queue seems to have permanently disappeared.

Proposing this for CommonBugs because it is expected that printers will break after upgrade from F35 -> F36, see:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BISRSRAUSMMKK34UBAGP44QL7MPZ74GI/

In my case, I've wound up in a state where my printer seems to be busted even after attempting to follow the recommended manual interventions. I don't know if that will be a common problem, though.

P.S. Zednek, if there's anything else you think I should try for debugging, either with ipp-usb or just to try to get hplip to work again like it used to, please suggest so ASAP. I'm planning to reinstall F35 *tomorrow* because I cannot wait longer to print stuff again.

(In reply to Michael Catanzaro from comment #24)
> After uninstalling hplip and removing the printer in System Settings, even
> the temporary queue is gone. I don't know how to get the temporary queue
> back.

I would go by the following steps:

0) turn off and unplug the device, then plug it in and turn on again 

1) check whether ipp-usb service is running

2) if it does, check its logs in /var/log/ipp-usb/main.log whether it added the device

3) check mDNS communication - avahi-browse -avrt - whether you see the device

4) check 'lpstat -e' whether the device is seen by CUPS

Let me know if it helps.

> 
> Trying to get back to a working state, I've now reinstalled hplip and
> uninstalled ipp-usb. However, my printer is still totally busted. Unless you
> have any grand ideas, I'm likely going to have to reinstall F35, because I
> really need to print my tax forms. :P I thought removing ipp-usb and
> reinstalling hplip would be sufficient to restore me to the way printing
> worked in F35?

You can set a quirk in /etc/ipp-usb/quirks for your device - see the email or ipp-usb man page.

Then ipp-usb will ignore the device and hplip can work with it.

> 
> (In reply to Zdenek Dohnal from comment #23)
> > Ok, I've gone to our minilab with ipp-over-usb supported printer (Canon MF
> > 440) just to make sure.
> > 
> > Both ipptool requests passed for me, I was able to print from all apps we
> > mentioned - evince, libreoffice, lp.
> > 
> > So it looks like an issue with the specific model, or you've hit a specific
> > situation - in the past it looked the printer's sleep mode was causing
> > issues - wasn't printer in sleep mode?
> 
> Well the printer's display is always off except for a minute or two after
> printing something or if I touch it. So yeah, maybe it was in sleep mode. Of
> course that shouldn't stop it from printing.

It depends whether the device is still seen on the bus - if the device sends via libusb some ending message, ipp-usb bails out because there is no device on the bus, and starts only after the device is connected (there is an ADD action in udev) again.

So if device generates some kind of 'end communication' message when it goes to sleep, CUPS cannot bring it up during printing...

(In reply to Zdenek Dohnal from comment #26) 
> I would go by the following steps:
> 
> 0) turn off and unplug the device, then plug it in and turn on again 

Done

> 1) check whether ipp-usb service is running

Reinstalled it. Now the service is running, according to systemd.

And my temporary print queue is back (though as before, it has the state "Rejecting jobs" and still does not work for printing).
 
> 2) if it does, check its logs in /var/log/ipp-usb/main.log whether it added
> the device

It's seen:

29-03-2022 09:42:55:   ===============================
29-03-2022 09:42:55:   ipp-usb started in "udev" mode, pid=6005
29-03-2022 09:42:55: + HOTPLUG: added Bus 001 Device 001
29-03-2022 09:42:55: + HOTPLUG: added Bus 001 Device 004
29-03-2022 09:42:55: + HOTPLUG: added Bus 001 Device 002
29-03-2022 09:42:55: + HOTPLUG: added Bus 001 Device 003
29-03-2022 09:42:55: + HOTPLUG: added Bus 002 Device 001
29-03-2022 09:42:55: + HOTPLUG: added Bus 003 Device 001
29-03-2022 09:42:55: + HOTPLUG: added Bus 003 Device 006
29-03-2022 09:42:55: + HOTPLUG: added Bus 003 Device 003
29-03-2022 09:42:55: + HOTPLUG: added Bus 003 Device 004
29-03-2022 09:42:55: + HOTPLUG: added Bus 003 Device 005
29-03-2022 09:42:55: + HOTPLUG: added Bus 004 Device 001
29-03-2022 09:42:55: + HOTPLUG: added Bus 005 Device 001
29-03-2022 09:42:55: + HOTPLUG: added Bus 006 Device 001
29-03-2022 09:42:55: + PNP Bus 003 Device 006: added
 
> 3) check mDNS communication - avahi-browse -avrt - whether you see the device

It's there:

$ avahi-browse -avrt
Server version: avahi 0.8; Host name: chargestone-cave-2.local
E Ifce Prot Name                                          Type                 Domain
+     lo IPv4 0301                                          _ipp-usb._tcp        local
+     lo IPv4 HP Officejet 4630 series [3DF5DF] (USB)       _http._tcp           local
+     lo IPv4 HP Officejet 4630 series [3DF5DF] (USB)       _uscan._tcp          local
+     lo IPv4 HP Officejet 4630 series [3DF5DF] (USB)       _ipp._tcp            local
+     lo IPv4 HP Officejet 4630 series [3DF5DF] (USB)       _printer._tcp        local
=     lo IPv4 0301                                          _ipp-usb._tcp        local
   hostname = [chargestone-cave-2.local]
   address = [127.0.0.1]
   port = [60000]
   txt = []
=     lo IPv4 HP Officejet 4630 series [3DF5DF] (USB)       _http._tcp           local
   hostname = [chargestone-cave-2.local]
   address = [127.0.0.1]
   port = [60000]
   txt = []
=     lo IPv4 HP Officejet 4630 series [3DF5DF] (USB)       _uscan._tcp          local
   hostname = [chargestone-cave-2.local]
   address = [127.0.0.1]
   port = [60000]
   txt = ["duplex=F" "is=platen,adf" "cs=color,grayscale" "UUID=1c852a4d-b800-1f08-abcd-5820b13df5df" "adminurl=http://localhost:60000/#hId-pgAirPrint" "representation=http://localhost:60000/webApps/images/printer-small.png" "pdl=application/octet-stream,application/pdf,image/jpeg" "ty=Officejet 4630 series" "rs=eSCL" "vers=2.1" "txtvers=1"]
=     lo IPv4 HP Officejet 4630 series [3DF5DF] (USB)       _ipp._tcp            local
   hostname = [chargestone-cave-2.local]
   address = [127.0.0.1]
   port = [60000]
   txt = ["air=none" "rp=ipp/print" "priority=50" "kind=document,envelope,photo" "PaperMax=legal-A4" "URF=CP1,MT1-2-8-9-10-11,OB9,OFU0,PQ3-4-5,RS300-600,SRGB24,W8-16,DEVW8-16,DEVRGB24-48,ADOBERGB24-48,DM3,IS1,V1.3" "UUID=1c852a4d-b800-1f08-abcd-5820b13df5df" "Color=F" "Duplex=T" "note=" "qtotal=1" "usb_MDL=Officejet 4630 series" "usb_MFG=HP" "usb_CMD=PCL3GUI,PJL,Automatic,JPEG,PCLM,AppleRaster,DW-PCL,802.11,DESKJET,DYN" "ty=HP Officejet 4630 series" "product=(HP Officejet 4630 series)" "pdl=application/vnd.hp-PCL,image/jpeg,application/PCLm,image/urf,application/octet-stream" "txtvers=1" "adminurl=http://localhost:60000/#hId-pgAirPrint" "Fax=F" "Scan=T"]
=     lo IPv4 HP Officejet 4630 series [3DF5DF] (USB)       _printer._tcp        local
   hostname = [chargestone-cave-2.local]
   address = [127.0.0.1]
   port = [0]
   txt = []

(followed by some more stuff not related to my printer)

> 4) check 'lpstat -e' whether the device is seen by CUPS

$ lpstat -e
HP_Officejet_4630_series_3DF5DF_USB
Officejet-4630

> Let me know if it helps.

It helped a lot, because my temporary queue is back. So I was able to print one blank page from LibreOffice, and then I could print a document that I needed from evince. I actually tried printing two documents, but it didn't work: the second one did not print, and I was unable to print any more blank pages from LibreOffice. At this point, I turned off and unplugged my printer again, then turned it back on. I was then able to print one more blank page from LibreOffice, and then one more document from evince.

So I think I can reliably print now, so long as I turn off and unplug my printer between each job, and print one page from LibreOffice before printing the document that I really want to print. Accordingly, I no longer plan to downgrade to F35, which would have been a huge waste of time. Thanks. ;)

> You can set a quirk in /etc/ipp-usb/quirks for your device - see the email
> or ipp-usb man page.
> 
> Then ipp-usb will ignore the device and hplip can work with it.

OK, I might try to do this next.

Ok, so now we know sleep mode is sending an ending message via USB and causes ipp-usb to turn off. We can try to have ipp-usb running in standalone mode (it doesn't exit after the device is 'disconnected') and see if it helps.

Now please try the ipptool commands from comment #21 (before you print from Libreoffice, which creates a local queue for some time, so evince can see it and print to it as well). Make sure you can see the temp queue before you issue the commands.

Additionally, the Canon printer worked even if I had printed from evince first...

(In reply to Zdenek Dohnal from comment #28)
> Ok, so now we know sleep mode is sending an ending message via USB and
> causes ipp-usb to turn off. 

We do? The systemd service seems to be constantly running, as does the ipp-usb process. I printed from LibreOffice just now and ipp-usb is still running a few minutes later, long after the printer stopped accepting jobs.

> Now please try the ipptool commands from comment #21 (before you print from
> Libreoffice, which creates a local queue for some time, so evince can see it
> and print to it as well). Make sure you can see the temp queue before you
> issue the commands.

I think you meant comment #20 or comment #22, right? I turned off the printer, unplugged it, turned it back on, and plugged it back in, then ran:

$ ipptool -tv ipp://chargestone-cave.local:60000/ipp/print get-printer-attributes.test
"/usr/share/cups/ipptool/get-printer-attributes.test":
    Get-Printer-Attributes:
        attributes-charset (charset) = utf-8
        attributes-natural-language (naturalLanguage) = en
        printer-uri (uri) = ipp://chargestone-cave.local:60000/ipp/print
        requested-attributes (1setOf keyword) = all,media-col-database
    Get printer attributes using get-printer-attributes                  [

This time it just hung there for a long time instead of failing quickly, like before. After several minutes, I gave up and hit Ctrl+C and tried again, but it hung once again.

But if I instead run:

$ ipptool -tv ipp://localhost:60000/ipp/print get-printer-attributes.test
"/usr/share/cups/ipptool/get-printer-attributes.test":

then I see it print a large amount of printer attributes, which I did not see when I ran that command previously. So that is interesting.

lpstat -e shows the temporary queue and also the permanent queue:

$ lpstat -e
HP_Officejet_4630_series_3DF5DF_USB
Officejet-4630

I'm not sure, but I *think* the temporary queue only works if hplip is installed and the permanent queue exists. I'm hesitant to remove them to test this theory, though, because my printer is currently in the semi-working state, and I need to keep it that way for a few more days, at least until my taxes are done. :P

(In reply to Michael Catanzaro from comment #29)
> We do? The systemd service seems to be constantly running, as does the
> ipp-usb process. I printed from LibreOffice just now and ipp-usb is still
> running a few minutes later, long after the printer stopped accepting jobs.

The printer appears to be in sleep mode currently, but ipp-usb is still running and the second ipptool command from comment #29 still works fine. Let me attach the output of that command.

Created attachment 1869100 [details]
get-printer-attributes

Proposed as a Blocker for 36-final by Fedora user chrismurphy using the blocker tracking app because:

 "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_panel_functionality

(In reply to Michael Catanzaro from comment #29)
> (In reply to Zdenek Dohnal from comment #28)
> > Ok, so now we know sleep mode is sending an ending message via USB and
> > causes ipp-usb to turn off. 
> 
> We do? The systemd service seems to be constantly running, as does the
> ipp-usb process. I printed from LibreOffice just now and ipp-usb is still
> running a few minutes later, long after the printer stopped accepting jobs.

Hmm, then it would be helpful to see the CUPS logs for the job which didn't print from Libreoffice + logs from ipp-usb.

The key prerequisites are ipp-usb is running and the queue is seen in mDNS communication - then temporary queue should appear in dialogs.

> 
> > Now please try the ipptool commands from comment #21 (before you print from
> > Libreoffice, which creates a local queue for some time, so evince can see it
> > and print to it as well). Make sure you can see the temp queue before you
> > issue the commands.
> 
> I think you meant comment #20 or comment #22, right? I turned off the
> printer, unplugged it, turned it back on, and plugged it back in, then ran:
> 
> $ ipptool -tv ipp://chargestone-cave.local:60000/ipp/print
> get-printer-attributes.test
> "/usr/share/cups/ipptool/get-printer-attributes.test":
>     Get-Printer-Attributes:
>         attributes-charset (charset) = utf-8
>         attributes-natural-language (naturalLanguage) = en
>         printer-uri (uri) = ipp://chargestone-cave.local:60000/ipp/print
>         requested-attributes (1setOf keyword) = all,media-col-database
>     Get printer attributes using get-printer-attributes                  [
> 
> This time it just hung there for a long time instead of failing quickly,
> like before. After several minutes, I gave up and hit Ctrl+C and tried
> again, but it hung once again.
> 
> But if I instead run:
> 
> $ ipptool -tv ipp://localhost:60000/ipp/print get-printer-attributes.test
> "/usr/share/cups/ipptool/get-printer-attributes.test":
> 
> then I see it print a large amount of printer attributes, which I did not
> see when I ran that command previously. So that is interesting.

IMHO there is something fishy with mDNS as well, in addition to other issues.

Printing stack recommends nss-mdns package for resolving mDNS addresses, since it doesn't require any manual configuration from user.

I have nss-mdns installed (f35->f36 upgraded machine, installed last month), GTK uses 'fedora.local' address and I'm able to get printout from evince.

> 
> lpstat -e shows the temporary queue and also the permanent queue:
> 
> $ lpstat -e
> HP_Officejet_4630_series_3DF5DF_USB
> Officejet-4630

lpstat -e shows existing queues on the local machine - permanent and temporary. Have you installed the permanent queue by yourself? There is an automatic USB printer installator in OS, but it should ignore IPP-over-USB devices.

> 
> I'm not sure, but I *think* the temporary queue only works if hplip is
> installed and the permanent queue exists. I'm hesitant to remove them to
> test this theory, though, because my printer is currently in the
> semi-working state, and I need to keep it that way for a few more days, at
> least until my taxes are done. :P

I understand - it would be great if you tried those steps with hplip installed - IMHO hplip being installed doesn't have the impact on temporary queue being available - the printer was probably stuck and unplugging+turning off fixed it, but we can see further down.

mcatanzaro: what does `grep hosts /etc/nsswitch.conf` give?

$ grep hosts /etc/nsswitch.conf
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

> lpstat -e shows existing queues on the local machine - permanent and temporary. Have you installed the permanent queue by yourself? There is an automatic USB printer installator in OS, but it should ignore IPP-over-USB devices.

Yes I did install the permanent queue myself. Do you want me to remove it again?

(In reply to Zdenek Dohnal from comment #33)
> (In reply to Michael Catanzaro from comment #29)
> > We do? The systemd service seems to be constantly running, as does the
> > ipp-usb process. I printed from LibreOffice just now and ipp-usb is still
> > running a few minutes later, long after the printer stopped accepting jobs.
> 
> Hmm, then it would be helpful to see the CUPS logs for the job which didn't
> print from Libreoffice + logs from ipp-usb.

To be clear: jobs from LibreOffice initially print successfully. Then, for a limited amount of time, it becomes temporarily possible to print from evince. After some time passes (2-3 minutes?), it is no longer possible to print from LibreOffice. Sometimes LibreOffice displays the error message "Could not start printer. Please check your printer configuration." Other times, it just doesn't do anything.

When I followed the instructions to collect job logs here:

https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/#_get_a_job_log_for_a_specific_job_id

E.g.:

$ journalctl -u cups JID=`lpstat -W all | awk '{print $1}' | awk -F '-' '{print $NF}' | tail -n 1` > cups_job_log

I sadly just wound up with empty logs that say:

-- No entries --

Seems the temporary queue disappears after some time. At first I saw this:

$ lpstat -W all
HP_Officejet_4630_series_3DF5DF_USB-221 mcatanzaro        2048   Wed 30 Mar 2022 06:00:38 PM CDT
HP_Officejet_4630_series_3DF5DF_USB-222 mcatanzaro        2048   Wed 30 Mar 2022 06:03:18 PM CDT

The job at 6:00 succeeded, while the job at 6:03 silently failed. But now I see nothing:

$ lpstat -W all

Manually collecting the logs did not work either:

$ journalctl -u cups JID=HP_Officejet_4630_series_3DF5DF_USB-222 > cups_job_log

Also resulted in "-- No entries --". So I will just give you all my logs from CUPS since I restarted the service .

> IMHO there is something fishy with mDNS as well, in addition to other issues.
> 
> Printing stack recommends nss-mdns package for resolving mDNS addresses,
> since it doesn't require any manual configuration from user.
> 
> I have nss-mdns installed (f35->f36 upgraded machine, installed last month),
> GTK uses 'fedora.local' address and I'm able to get printout from evince.

I do have nss-mdns installed.

> > I'm not sure, but I *think* the temporary queue only works if hplip is
> > installed and the permanent queue exists. I'm hesitant to remove them to
> > test this theory, though, because my printer is currently in the
> > semi-working state, and I need to keep it that way for a few more days, at
> > least until my taxes are done. :P
> 
> I understand - it would be great if you tried those steps with hplip
> installed - IMHO hplip being installed doesn't have the impact on temporary
> queue being available - the printer was probably stuck and
> unplugging+turning off fixed it, but we can see further down.

You want me to *install* or *uninstall* hplip? It is currently installed, and that seems best to me because it will be installed for other Fedora users.

Created attachment 1869580 [details]
whole log (again)

(In reply to Michael Catanzaro from comment #36)
> To be clear: jobs from LibreOffice initially print successfully. Then, for a
> limited amount of time, it becomes temporarily possible to print from
> evince. After some time passes (2-3 minutes?), it is no longer possible to
> print from LibreOffice. Sometimes LibreOffice displays the error message
> "Could not start printer. Please check your printer configuration." Other
> times, it just doesn't do anything.

Thanks! Any detailed info is appreciated!

> 
> When I followed the instructions to collect job logs here:
> 
> https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-
> problems/#_get_a_job_log_for_a_specific_job_id
> 
> E.g.:
> 
> $ journalctl -u cups JID=`lpstat -W all | awk '{print $1}' | awk -F '-'
> '{print $NF}' | tail -n 1` > cups_job_log
> 
> I sadly just wound up with empty logs that say:
> 
> -- No entries --
> 

Curious - I've tried the command on my machine and it got the correct logs of the last job, which was printed several minutes ago. Getting a specific job log for a job which is older than one day is not possible with default cupsd configuration, because job history is cleaned up after one day.

I've echoed your `lpstat -W all` output into the chain of commands mentioned on the page, and got the correct JID.

I would pursue this further after we solve the initial issue.

> Seems the temporary queue disappears after some time. At first I saw this:
> 
> $ lpstat -W all
> HP_Officejet_4630_series_3DF5DF_USB-221 mcatanzaro        2048   Wed 30 Mar
> 2022 06:00:38 PM CDT
> HP_Officejet_4630_series_3DF5DF_USB-222 mcatanzaro        2048   Wed 30 Mar
> 2022 06:03:18 PM CDT
> 
> The job at 6:00 succeeded, while the job at 6:03 silently failed. But now I 
> see nothing:
> 
> $ lpstat -W all
> 
> Manually collecting the logs did not work either:
> 
> $ journalctl -u cups JID=HP_Officejet_4630_series_3DF5DF_USB-222 >
> cups_job_log

JID is only the number - the example on the page, but I can see the description can be misleading - I've updated the docs.

> You want me to *install* or *uninstall* hplip? It is currently installed,
> and that seems best to me because it will be installed for other Fedora
> users.

I'm sorry - I wrote this one par in hurry and didn't check afterwards - I meant 'uninstall' just to make sure everything works even without it.

In the meantime I've checked the logs:


The error from cups log:

Mar 30 18:04:30 chargestone-cave cupsd[230955]: [Job 222] Job aborted because the destination printer/class has gone away.

and the backend gets stopped at that time. Then the last messages from the ipp-usb main.log are:

30-03-2022 17:58:39: + HOTPLUG: added Bus 006 Device 001
30-03-2022 17:58:39: + PNP Bus 003 Device 011: added

so the device is not removed. At last I check 03f0-c611-CN57D6914T05Y0-HP-Officejet-4630-series.log.0.gz:

30-03-2022 18:04:14: < HTTP[071]: POST http://localhost:60000/ipp/print - 200 OK
30-03-2022 18:04:14: < HTTP[071]: HTTP response header:
30-03-2022 18:04:14: <   HTTP/1.1 200 OK
30-03-2022 18:04:14: <   Cache-Control: must-revalidate, max-age=0
30-03-2022 18:04:14: <   Content-Length: 282
30-03-2022 18:04:14: <   Pragma: no-cache
30-03-2022 18:04:14: <   Server: HP HTTP Server; HP Officejet 4630 series - B4L03A; Serial Number: CN57D6914T05Y0; Built:Thu Dec 04, 2014 11:06:46AM {MYM1FN1449AR}
30-03-2022 18:04:14: <
30-03-2022 18:04:14: < USB[3]: read: wanted 4096 got 282 total 523
30-03-2022 18:04:14: < HTTP[071]: response body: got 282 bytes; EOF
30-03-2022 18:04:14:   USB[3]: connection released, 1 in use: --- ar- --- ---
30-03-2022 18:04:14: < USB[1]: read: wanted 4096 got 0 total 0
30-03-2022 18:04:14: ! USB[1]: zero-size read 
30-03-2022 18:04:15: < USB[1]: read: wanted 4096 got 0 total 0

then 'zero-size read' messages repeat till the end - so the USB connection release causes the issue. The previous issue with mDNS is caused by that as well, because the ipp-usb log shows the same messages as now - so we can try quirks before I move this to upstream.

Please create a new .conf file at /etc/ipp-usb/quirks with content:

[HP OfficeJet 4630 series]
  http-connection = keep-alive


, restart ipp-usb, turn off, plug out, plug in, turn on the printer and try to print and see if it helps.

Hi Kamil,

thank you for creating the common issue on ask.fedoraproject.org!

Just a few additional notes which would be great if they made into the issue (I've tried to log at ask.fedoraproject.org, but it rejected me due IP...):

- USB scanner which support driverless standard IPP-over-USB are affected as well - if you want to use the classic driver, reject the device in ipp-usb quirks, if you are okay with driverless, then there will be a dysfunctional scanner entry with the classic driver. I'm planning to add quirks to sane-backends as well, so you can disable the scanner for classic driver - right now you can comment out the backend in /etc/sane.d/dll.conf or in /etc/sane.d/dll.d/ directory.

- F36 can be affected if you install your driverless printer with classic driver and you don't reject the device in ipp-usb quirks. Scanners are affected either way, since discovery process is automatic even for classic drivers and the process doesn't open the device, just report the device exists, so you end up with broken device in dialog. However, there should be another device (in print dialog and scanning dialog) available which should work.

- Regarding the workarounds mentioned there - ipp-usb is a weak dependency of CUPS, so it will be brought in with next cups update, breaking the setup of people who still choose to use classic driver with driverless device. The workaround you should use for such cases is to add a quirk for ipp-usb which will reject the device - see 'man ipp-usb'.

Hi Zdenek, I already replied to your devel email [1] with lots of questions. I plan to work on that Common Issue based on your feedback. Scanners will probably get a separate Common Issue, once I feel I understand printers and can move on :) Thanks for your clarifications here. Let's continue to fine-tune it in the devel thread, if that's ok with you.

[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BISRSRAUSMMKK34UBAGP44QL7MPZ74GI/

OK, I've uninstalled hplip.

> Please create a new .conf file at /etc/ipp-usb/quirks with content:
> 
> [HP OfficeJet 4630 series]
>   http-connection = keep-alive
> 
> 
> , restart ipp-usb, turn off, plug out, plug in, turn on the printer and try
> to print and see if it helps.

Sadly, this quirk does not make any difference.

I also tried to blacklist it:

[HP OfficeJet 4630 series]
  blacklist = true

But this quirk did not work either: the temporary queue is still created after restarting ipp-usb. Are you sure the syntax is correct?

It should be iManufacturer+iProduct strings from 'lsusb -v' output - at least that was what blacklisted Canon printer from the lab. According to your lsusb -v output, it should be the string you've used.

In my case I created a quirk file called /etc/ipp-usb/quirks/canon.conf (I'm recalling this one part - I'm at home with another laptop now and here I don't have ipp-usb supported printer - so there maybe discrepancies):

[Canon MF440]
  blacklist = true

Do you have the latest ipp-usb? 0.9.20? The older ipp-usb doesn't support quirks in /etc/ipp-usb/quirks, but only in /usr/share/ipp-usb/quirks, where are quirks from the package.

In the end I thank you a lot for cooperating with me and brainstorming! I understand it is really frustrating, but I appreciate all the time you've spent here with me on the issue.

(In reply to Zdenek Dohnal from comment #44)
> It should be iManufacturer+iProduct strings from 'lsusb -v' output - at
> least that was what blacklisted Canon printer from the lab. According to
> your lsusb -v output, it should be the string you've used.
> 
> In my case I created a quirk file called /etc/ipp-usb/quirks/canon.conf (I'm
> recalling this one part - I'm at home with another laptop now and here I
> don't have ipp-usb supported printer - so there maybe discrepancies):
> 
> [Canon MF440]
>   blacklist = true
> 
> Do you have the latest ipp-usb? 0.9.20?

Yup. I have this currently:

$ cat /etc/ipp-usb/quirks/mcatanzaro.conf 
[HP OfficeJet 4630 series]
  blacklist = true

#  http-connection = keep-alive

ipp-usb is no longer recommended by cups package in F36+, which IMHO solves the blocker for now - there has to be at least some migration path in the future - either by a specific daemon, or in ipp-usb itself.

The relevant updates:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f4925bd0a
https://bodhi.fedoraproject.org/updates/FEDORA-2022-b55f661c6a

With that, I'm removing the blocker tracker.

And the relevant updates for sane-airscan:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-0ad820e3cc
https://bodhi.fedoraproject.org/updates/FEDORA-2022-5eac55ee86

$ lsusb -v:

  iManufacturer           1 Canon
  iProduct                2 MF440 Series

$ cat /etc/ipp-usb/quirks/canon.conf:
"
[Canon MF440 Series]
  blacklist = true

# http-connection = keep-alive
"
$ cat /var/log/ipp-usb/main.log:
...
04-04-2022 17:49:14: ! PNP Bus 001 Device 005: Device is blacklisted
04-04-2022 17:49:16: + PNP Bus 001 Device 005: retry
04-04-2022 17:49:16: ! PNP Bus 001 Device 005: Device is blacklisted

So currently I don't know what's wrong with your quirk :( - I can't reproduce this issue. Are you able to debug the ipp-usb in gdb or in dlv? It is written in golang, so delve is a nice debugger for it https://opensource.com/article/20/6/debug-go-delve .

I'm re-adding the FinalBlocker proposal. The reason is that those updates from comment 46 and 47 are not stable, and freeze starts tomorrow. That means unless we push those updates through the freeze (i.e. due to an accepted blocker proposal, or at least a freeze exception), ipp-usb will stay on the install medium, will get installed by default, and will affect all users.

(In reply to Zdenek Dohnal from comment #48)
> So currently I don't know what's wrong with your quirk :( - I can't
> reproduce this issue. Are you able to debug the ipp-usb in gdb or in dlv? It
> is written in golang, so delve is a nice debugger for it
> https://opensource.com/article/20/6/debug-go-delve .

That's getting too intense for me, sorry. :/

Discussed during the 2022-04-04 blocker review meeting: [1]

The decision to classify this bug as an AcceptedBlocker was made:

"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." 

Note that it shouldn’t be too much longer before the fix lands in stable.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-04/f36-blocker-review.2022-04-04-16.00.log.html

(In reply to Michael Catanzaro from comment #50)
> (In reply to Zdenek Dohnal from comment #48)
> > So currently I don't know what's wrong with your quirk :( - I can't
> > reproduce this issue. Are you able to debug the ipp-usb in gdb or in dlv? It
> > is written in golang, so delve is a nice debugger for it
> > https://opensource.com/article/20/6/debug-go-delve .
> 
> That's getting too intense for me, sorry. :/

Ok, no problem - before we turn this upstream, the quirks should accept wildcards as well. Can you try substituting '*' for 'HP OfficeJet 4630 series'? If quirks work, it should reject any USB machine ipp-usb is run with.

(In reply to Zdenek Dohnal from comment #52)
> Ok, no problem - before we turn this upstream, the quirks should accept
> wildcards as well. Can you try substituting '*' for 'HP OfficeJet 4630
> series'? If quirks work, it should reject any USB machine ipp-usb is run
> with.

Yes, the blacklist quirk works if I change [HP OfficeJet 4630 series] to [*].

I tried the http-connection = keep-alive quirk again using [*], but it does not seem to fix anything.

Nice to know quirks in /etc works at least - not so nice to know that `lsusb -v` returns different values than libusb_get_string_descriptor_ascii() does... but that would be usbutils/libusb1 bug.

Can you play a little with the header entry '[HP OfficeJet 4630 series]' to find out which is the correct string for it? If I were you I would try at least:

[HP, Inc Officejet 4630 series]
[HP*]
[Hewlett-Packard*]

the first entry is from 'lsusb -v' as well, but it is not combination of iManufacturer+iProduct which worked for me. Other two are common issues - some tools can report HP products as HP, others with its full name...

Once we have the correct string for quirk, I'll report this to usbutils/libusb1 - ipp-usb uses concatenation of iManufacturer+iProduct in quirks and compares it with data taken from libusb_get_string_descriptor_ascii(). lsusb takes data directly from opened libusb device, so it should get the same results...

===========================================================================================================

Ad the ipp-usb issue - I'd revisited both situation which you provided logs for when I was about to write upstream issue and I've noticed this:
====================================

Ad the pair of logs from 30th Mar 
---------------------------------
- I've missed this log from the device in CUPS log, specifically it is a response to IPP request GET-PRINTER-ATTRIBUTES, which is done to check the printer's status:

```
Mar 30 18:03:20 chargestone-cave cupsd[230955]: [Job 222] printer-state-reasons keyword spool-area-full-report
```

I get this report on my printer when I send too big document to it (usually by error) - IMO it should mean the spool area on the printer (where the printer gets the document which it will print), but it seems some firmware implementations (https://www.pwg.org/archives/ipp/2015/018399.html) uses it as 'work in progress' report. Currently I wasn't able to fix this report on my printer by any other way than restarting it...

So this state of printer keeps the job in the processing state - either because the printer is working on the job or it stuck - for more than one minute. Slightly before the limit, ipp-usb stops communicating with the device:


```
3288 30-03-2022 18:04:14: <   Pragma: no-cache
3289 30-03-2022 18:04:14: <   Server: HP HTTP Server; HP Officejet 4630 series - B4L03A; Serial Number: CN57D6914T05Y0; Built:Thu Dec 04, 2014 11:06:46AM          {MYM1FN1449AR}
3290 30-03-2022 18:04:14: <
3291 30-03-2022 18:04:14: < USB[3]: read: wanted 4096 got 282 total 523
3292 30-03-2022 18:04:14: < HTTP[071]: response body: got 282 bytes; EOF
3293 30-03-2022 18:04:14:   USB[3]: connection released, 1 in use: --- ar- --- ---
3294 30-03-2022 18:04:14: < USB[1]: read: wanted 4096 got 0 total 0
3295 30-03-2022 18:04:14: ! USB[1]: zero-size read
3296 30-03-2022 18:04:15: < USB[1]: read: wanted 4096 got 0 total 0
3297 30-03-2022 18:04:15: ! USB[1]: zero-size read
```

and then the following message in CUPS log comes:

```
Mar 30 18:04:19 chargestone-cave cupsd[230955]: cupsdDeletePrinter(p=0x55edad824db0(HP_Officejet_4630_series_3DF5DF_USB), update=0)
```

like 'wait, why we are removing a printer with running job?' and there is the reason in CUPS, scheduler/printers.c:

```
 885 void
 886 cupsdDeleteTemporaryPrinters(int force) /* I - Force deletion instead of auto? */
 887 {
...
892  /*
 893   * Allow temporary printers to stick around for 60 seconds after the last job
 894   * completes.
 895   */
 896 
 897   unused_time = time(NULL) - 60;
...
 901     if (p->temporary && (force || p->state_time < unused_time))
 902       cupsdDeletePrinter(p, 0);
```

p->state_time was updated when the printer accepted the new job (it is updated when the printer changes the state, this time from 'idle' to 'processing'), so because the printer was still processing for more than 1 minute, cupsd cleaned it up...


I've sent a patch for this issue here https://github.com/OpenPrinting/cups/pull/364 . However the connection breakup with device starts before the queue is cleaned up.


With that, I've looked into logs from 28th Mar:
-----------------------------------------------

I wanted to check whether the same report about spool area being full caused the issue there as well - but CUPS log doesn't contain the messages from the time when ipp-usb stopped exchanging data with device:

```
2246 28-03-2022 09:48:25: <   Server: HP HTTP Server; HP Officejet 4630 series - B4L03A; Serial Number: CN57D6914T05Y0; Built:Thu Dec 04, 2014 11:06:46AM          {MYM1FN1449AR}
2247 28-03-2022 09:48:25: <
2248 28-03-2022 09:48:25: < USB[0]: read: wanted 4096 got 287 total 528
2249 28-03-2022 09:48:25: < HTTP[169]: response body: got 287 bytes; EOF
2250 28-03-2022 09:48:25:   USB[0]: connection released, 1 in use: --- ar- --- ---
2251 28-03-2022 09:48:25: < USB[1]: read: wanted 4096 got 0 total 0
2252 28-03-2022 09:48:25: ! USB[1]: zero-size read
2253 28-03-2022 09:48:26: < USB[1]: read: wanted 4096 got 0 total 0
```

and cups log starts at:

```
Mar 28 10:40:48 chargestone-cave cupsd[118003]: [Client 1020] cupsdReadClient: error=0, used=0, state=HTTP_STATE_WAITING, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=0, request=(nil)(), file=-1
Mar 28 10:40:48 chargestone-cave cupsd[118003]: [Client 1020] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
Mar 28 10:40:48 chargestone-cave cupsd[118003]: [Client 1020] Closing connection.
```

To sum it up:
-------------

Michael,

1) it would be great if you experimented with the quirk name for me to find out which is the correct name, so I could report the issue to libusb1. The suggestions are in the first part of the previous comment.


2) it would be great if you tried to get the printing issue with ipp-usb again - I would like to see whether the same report about spool area being full causes the other issues as well. The critical thing is to have CUPS and ipp-usb logs for time frame since ipp-usb recognizes the device until the communication hangs.

You can find out the communication breakage when you check one of the /var/log/ipp-usb/03f0-c611-CN57D6914T05Y0-HP-Officejet-4630-series.log files. When the logs start to show only:

```
2251 28-03-2022 09:48:25: < USB[1]: read: wanted 4096 got 0 total 0
2252 28-03-2022 09:48:25: ! USB[1]: zero-size read
2253 28-03-2022 09:48:26: < USB[1]: read: wanted 4096 got 0 total 0
2254 28-03-2022 09:48:26: ! USB[1]: zero-size read
2255 28-03-2022 09:48:27: < USB[1]: read: wanted 4096 got 0 total 0
2256 28-03-2022 09:48:27: ! USB[1]: zero-size read
2257 28-03-2022 09:48:28: < USB[1]: read: wanted 4096 got 0 total 0
2258 28-03-2022 09:48:28: ! USB[1]: zero-size read
2259 28-03-2022 09:48:29: < USB[1]: read: wanted 4096 got 0 total 0
...
```

then I expect the breakage happened right at that moment.

Otherwise reported upstream https://github.com/OpenPrinting/ipp-usb/issues/47

Since this bug became more device-specific, I've created new bugs which will harbor the Common Bugs link and the Final Blocker tracker.

Final blocker bug -> https://bugzilla.redhat.com/show_bug.cgi?id=2072470

Common bug -> https://bugzilla.redhat.com/show_bug.cgi?id=2072448

Ok, back from upstream:

Ad quirks:

Running:

$ sudo /usr/sbin/ipp-usb check

should print out the configuration, where we should find the correct name for the quirk. It would be great if you tried that command and applied on the quirk accordingly.

Additionally upstream recommends to try quirk:

http-connection = close


Would you mind trying that quirk?


Thank you in advance!

I think the ipp-usb path is a negative.  It would be nice if it can be made to be cooperative with other things using that usb port, but as-is does not work well and the user with a USB printer that NEEDS to use the printer driver is stuck in an either-or quandry.  They must either give up features of the printer that are provided by the driver or must give up full use of ipp.  I personally have been instrumental in aiding at least 4 others to fix their HP printer issues this has caused.  In all cases removal of the ipp-usb package fixed the problem.

I use exclusively HP printers over wifi and so ipp-usb has not directly affected me, but the plan for CUPS to remove support for printer drivers WILL AFFECT ME when that happens.

HP (and other brands) do have some proprietary features that can only be accessed through their driver support.  Specifically, the HP MFP printers can only access the scanner by using hplip and the proprietary plugin for the scanner.  Removing support for hplip WILL eliminate the ability to use the scanner unless somehow the need for both the driver and plugin is solved.

(In reply to Zdenek Dohnal from comment #58)
> Ok, back from upstream:
> 
> Ad quirks:
> 
> Running:
> 
> $ sudo /usr/sbin/ipp-usb check
> 
> should print out the configuration, where we should find the correct name
> for the quirk. It would be great if you tried that command and applied on
> the quirk accordingly.

Ah, running that command, I found the problem: I have "HP Officejet 4630 series" with a lowercase 'j', whereas from comment #39 you had me using an uppercase 'J'. Oops. :) With that, I'm able to blacklist only the affected printer.

> Additionally upstream recommends to try quirk:
>
> http-connection = close
>
>
> Would you mind trying that quirk?

Sadly, this doesn't work.

(In reply to Jeff from comment #59)
> I think the ipp-usb path is a negative.  It would be nice if it can be made
> to be cooperative with other things using that usb port, but as-is does not
> work well and the user with a USB printer that NEEDS to use the printer
> driver is stuck in an either-or quandry.  They must either give up features
> of the printer that are provided by the driver or must give up full use of
> ipp.

Currently you can kind of mix up IPP and driver - you can install a queue with IPP backend, which makes your job to be sent via IPP, and have the options from the classic driver. The possible downside can be that you don't find out options from your printer, since you don't create driverless driver via IPP.

Regarding common issue of IPP not having all options as a classic driver, IMO it is chicken-egg problem. Manufacturers don't implement the same set of options for IPP, because there is no demand from the current user base of driverless - mobile devices - they are fine with current set. Users from desktops, which are used to installing drivers, then won't use driverless standards, because it can miss some of the options which the classic driver has. And so manufacturers probably don't see the demand for updating firmware...

>  I personally have been instrumental in aiding at least 4 others to fix
> their HP printer issues this has caused.  In all cases removal of the
> ipp-usb package fixed the problem.

It would be great if you reported such issues instead of 'fixing them' by removing ipp-usb. If the device provides IPP-over-USB interface, we need to investigate whether there is a way how make it work with ipp-usb. Of course, there are already some devices, which reports the correct interface, but in the end they're useless with IPP-over-USB standard, but still it is good to know which models they are, so we can systematically reject them in ipp-usb, so other owners don't need to tackle the same thing.

Additionally, ipp-usb will be bring with next CUPS and sane-airscan updates in the future, since it provides driverless interfaces for printing and scanning.

> 
> I use exclusively HP printers over wifi and so ipp-usb has not directly
> affected me, but the plan for CUPS to remove support for printer drivers
> WILL AFFECT ME when that happens.

If you use wifi connection and your printers are capable of using driverless, you can use driverless standards suited for network devices - such as IPP Everywhere/AirPrint etc.
ipp-usb uses IPP-over-USB standard to provide an interface for those driverless standards as well.

> 
> HP (and other brands) do have some proprietary features that can only be
> accessed through their driver support.

That can be the case, but sometimes I found out some proprietary features are already covered by IPP standard, thus they're not proprietary and it depends on manufacturer, whether they implement its support in their firmware.

If there are still proprietary features that can't be migrated to IPP, there is a possibility of implementing a native printer application - see what a printer application is here https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/#_printer_applications .

> Specifically, the HP MFP printers
> can only access the scanner by using hplip and the proprietary plugin for
> the scanner.  Removing support for hplip WILL eliminate the ability to use
> the scanner unless somehow the need for both the driver and plugin is solved.

Regarding scanning, you can still download proprietary plugin and then SANE backend hpaio will use it - currently there is no specific plan for deprecating scanner drivers. However, if your device can do eSCL or WSD, you can use sane-airscan for driverless scanning without any plugins. If the device is connected via USB, you can turn on ipp-usb and then scan via sane-airscan, the same as HP Officejet 4630 can.

(In reply to Michael Catanzaro from comment #60)
> Ah, running that command, I found the problem: I have "HP Officejet 4630
> series" with a lowercase 'j', whereas from comment #39 you had me using an
> uppercase 'J'. Oops. :) With that, I'm able to blacklist only the affected
> printer.

Heh, and lsusb command shows the same... that's what I get for not copying the string and writing instead. Sorry for the noise.

> 
> > Additionally upstream recommends to try quirk:
> >
> > http-connection = close
> >
> >
> > Would you mind trying that quirk?
> 
> Sadly, this doesn't work.

Ok, so let's see what Alex Pevzner, the upstream maintainer, will find out.

Hi Michael,

Alex thinks there can be an issue or a trigger which causes firmware to hang in the print job you send to the printer - the easiest thing we can change is the document you send to the printer. The PDF you've used in testing looks like a PDF which was previously a text file which got converted to PDF (guessing it by the 'untitled document' title), so I would like to ask you to try some original PDF document. You can try to print the first page from /usr/share/doc/valgrind/valgrind_manual.pdf or something like this.

 
Would you mind trying to print an original PDF from your system? Some existing manual or similar (the first page suffices).


Other thing Alex recommends is to play with your PPD which gets generated if you install the virtual queue generated by ipp-usb permanently. You can install your driverless ipp-usb device permanently by:

$ lpadmin -p <chosen name> -v ipp://localhost:60000/ipp/print -m everywhere -E


Would you mind installing the queue permanently and trying to print via it? (Note: there is a new CUPS version, which contains the fix I mentioned in comment #54 - please install it from updates testing repo)



If both (printing a different document and using a permanent queue) fails, put here all logs (CUPS debug logs and ipp-usb logs) and let's inform Alex - because I'm not sure what he meant specifically by playing with PPD - AFAIK what can help is that we enforce a different document format by the PPD, but that's probably all.

(In reply to Zdenek Dohnal from comment #63)
> Hi Michael,
> 
> Alex thinks there can be an issue or a trigger which causes firmware to hang
> in the print job you send to the printer - the easiest thing we can change
> is the document you send to the printer. The PDF you've used in testing
> looks like a PDF which was previously a text file which got converted to PDF
> (guessing it by the 'untitled document' title), so I would like to ask you
> to try some original PDF document. You can try to print the first page from
> /usr/share/doc/valgrind/valgrind_manual.pdf or something like this.
> 
>  
> Would you mind trying to print an original PDF from your system? Some
> existing manual or similar (the first page suffices).

This does not work. Evince's print dialog initially gets stuck at "Getting printer information...", and later transitions to "Rejecting Jobs", same as if I try to print anything else.

> Other thing Alex recommends is to play with your PPD which gets generated if
> you install the virtual queue generated by ipp-usb permanently. You can
> install your driverless ipp-usb device permanently by:
> 
> $ lpadmin -p <chosen name> -v ipp://localhost:60000/ipp/print -m everywhere
> -E
> 
> 
> Would you mind installing the queue permanently and trying to print via it?

Hm, it prints perfectly fine if installed permanently. Interesting! The temporary queue remains nonfunctional.

> (Note: there is a new CUPS version, which contains the fix I mentioned in
> comment #54 - please install it from updates testing repo)

I didn't actually install this new version of CUPS, but I guess it's not important since printing via the permanent queue worked?

Good to know!

It would be great if you could attach CUPS and ipp-usb logs for following cases:

1) print a PDF from evince via temporary queue

2) print the same PDF from evince via permanent driverless queue

3) print the same PDF via 'lp' command using temporary queue - you can find out which one is temporary by using 'lpstat -a' and 'lpstat -e' commands - the print queue which is missing from 'lpstat -a' but is present in 'lpstat -e' is the temporary one. Here I would like to ask to test this more thoroughly, because I would like to know whether the whole temporary queue concept is broken for your printer, or if there is a problem in print dialog.


The reason why I'm asking this is to have a comparison between how temporary and permanent queue works for you, and then how/whether temporary queue straight from CUPS works, so if the temporary queue printing via lp works, its implementation bits can be used to fix print dialog for regular users.

(In reply to Zdenek Dohnal from comment #65)
> Good to know!
> 
> It would be great if you could attach CUPS and ipp-usb logs for following
> cases:
> 
> 1) print a PDF from evince via temporary queue

Again, this is impossible unless I print from LibreOffice first. Is the debug log really going to be useful if I do that? It will not show the typical problem.

> 2) print the same PDF from evince via permanent driverless queue

No problem.

> 3) print the same PDF via 'lp' command using temporary queue - you can find
> out which one is temporary by using 'lpstat -a' and 'lpstat -e' commands -
> the print queue which is missing from 'lpstat -a' but is present in 'lpstat
> -e' is the temporary one. Here I would like to ask to test this more
> thoroughly, because I would like to know whether the whole temporary queue
> concept is broken for your printer, or if there is a problem in print dialog.

I'll try.

Created attachment 1886363 [details]
Job log: print from evince using permanent driverless queue

Using the temporary driverless queue with 'lp' instead of evince works fine. I ran:

$ lp -P 1 -d HP_Officejet_4630_series_3DF5DF_USB /usr/share/doc/valgrind/valgrind_manual.pdf

Created attachment 1886364 [details]
Job log: print from lp using temporary driverless queue

(In reply to Michael Catanzaro from comment #66)
> (In reply to Zdenek Dohnal from comment #65)
> > 1) print a PDF from evince via temporary queue
> 
> Again, this is impossible unless I print from LibreOffice first. Is the
> debug log really going to be useful if I do that? It will not show the
> typical problem.
> 

It is just for the record - it is better to have the latest logs rather than finding out later there was a slight change which mattered.

Hi Michael,

are you able to reproduce the issue with ipp-usb via temp queue in Evince? (getting 'Rejecting jobs' in print dialog)

Would you mind getting two separate CUPS whole logs, one for 'printing' via Evince - when you get 'Rejecting jobs', and the other for printing via lp?

I would like to have the current, full and time limited logs for both use cases, so I can see how we should adjust GTK to make it working more reliable.


Thank you in advance and for the patience!

(In reply to Zdenek Dohnal from comment #72)
> are you able to reproduce the issue with ipp-usb via temp queue in Evince?
> (getting 'Rejecting jobs' in print dialog)

Yes.

> Would you mind getting two separate CUPS whole logs, one for 'printing' via
> Evince - when you get 'Rejecting jobs', and the other for printing via lp?
> 
> I would like to have the current, full and time limited logs for both use
> cases, so I can see how we should adjust GTK to make it working more
> reliable.

I will try to follow your instructions on the wiki. They are complicated, though!

Sorry, can you post more instructions for specifically what you want me to do to take these logs?

https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/#_my_printer_doesnt_print_correctly_or_at_all_but_i_can_see_the_printer_in_print_dialog - basically you can omit the steps 6, 8 and 9.

Your trigger in evince is to open the print dialog, click on the print queue and see 'Rejecting jobs' - if you are able to print, print as well.

The trigger with lp printing is issuing the command: `lp -d HP_Officejet_4630_series_3DF5DF_USB <file>`.

Use the same file in both scenarios, upload two separate CUPS whole logs (ipp-usb log can be only one) and do the evince printing first, and then 'lp' printing.

Don't forget to remove the printer from ipp-usb quirks :)

Created attachment 1913566 [details]
whole log (evince)

Created attachment 1913567 [details]
Test document (not important, any document will reproduce the issue)

Created attachment 1913568 [details]
lsusb again

(In reply to Zdenek Dohnal from comment #75)
> The trigger with lp printing is issuing the command: `lp -d
> HP_Officejet_4630_series_3DF5DF_USB <file>`.

Note: this caused the test document to actually print, and since it's >100 pages long I canceled it right away. That will probably show up in the logs.

Created attachment 1913569 [details]
whole log (lp)

Hi Michael,

thanks for the files!

So the difference here is that GTK (evince) uses the mDNS hostname directly from Avahi and asks CUPS to create a temp queue for the printer lying under it - the problem is the virtual printer from ipp-usb lives on localhost:60000 , and something (most probably Avahi, or maybe resolved) sometimes is able to resolve your .local address to 127.0.0.1, but sometimes it does not (I've talked with DNS SME about this and he told me this is how resolved behaves sometimes, which is incorrect - your .local address should never be resoled as 127.0.0.1...).

In CUPS upstream we worked it around by a patch, which is applied in this scratch build - https://koji.fedoraproject.org/koji/taskinfo?taskID=92286432 - can you test it if it helps? (The basic idea of the patch is if the printer's hostname matches with your hostname, we substitute the hostname for localhost) .

Note that in Fedora, we let avahi resolve mDNS before systemd-resolved sees anything:

$ cat /etc/nsswitch.conf | grep hosts
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

And we also have systemd-resolved configured with mDNS disabled:

$ cat /etc/systemd/resolved.conf | grep Multicast
#MulticastDNS=no

So it must be avahi that is handling the mDNS.

Anyway, I tested your updated CUPS and it works! This bug is, finally... *resolved.* ;)

FEDORA-2022-988793d1ac has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-988793d1ac

FEDORA-2022-23a7d39e5b has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-23a7d39e5b

FEDORA-2022-988793d1ac has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-988793d1ac`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-988793d1ac

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-23a7d39e5b has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-23a7d39e5b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-23a7d39e5b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-23a7d39e5b has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-988793d1ac has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.