My setup: - headless host A running cups 2.4.2-3+deb12u8, with printer connected via USB, makes the printer available to host B - host B running cups 2.4.2-3+deb12u7, printing from evince. Works like a charm. Then I: - upgrade cups on host B to 2.4.2-3+deb12u8 - restart evince, press CTRL+P, select the printer by clicking on it once in the printing dialog - this hangs displaying a (localized) message that I think might be something like "Retrieving printer information..." in the original. I tried other combination of versions. It seems 2.4.2-3+deb12u8 on host B is what breaks things. I'm more than happy to provide information on the configuration, just please let me know what to provide, printing remains a black magic to me :-( FWIW the printer looks the same in GNOME printer settings dialog on host B whether it works for evince or not - the printer address is "(null)" in both cases.
Hi Marcin, cups now makes more checks with the attributes it gets from the printer, so it would be great to know which printer you are using. Are there any messages in the error log on host A or host B? Are you still able to print on host A? Are you able to try a different printer (maybe even a different manufacturer) and check whether you have the same problems with it? Thorsten
Thanks for the quick response Thorsten!
pt., 4 paź 2024 o 13:15 Thorsten Alteholz <debian@alteholz.de> napisał(a):
It's an HP Smart Tank 720.
Indeed, on host B the following appears at the same time the print dialog
hangs in evince ("piec" is host A):
E [04/Oct/2024:13:29:44 +0200] HP_Smart_Tank_710_720_series_piec: Printer
returned invalid data: \"media-supported\": Bad keyword value \"\" -
invalid character (RFC 8011 section 5.1.4).
I had never tried before, but yes, "lpr -P ... file.pdf" worked! \o/
Are you able to try a different printer (maybe even a different
Sorry, I only have this one printer.
FWIW, I did "sudo grep -R media-supported /etc 2>/dev/null" and that came
back with nothing. So I guess it's a bug in the printer's firmware? Can I
work this around somehow on the cups side?
Marcin
Hi Marcin, yes, this message belongs to the new validation of attributes that was part of the latest patches. Unfortunately this printer does not behave correct, so I think this is rather a feature than a bug. yes, this is a bug in the printer's firmware. cups asks the printer about some properties and one of the answers contains a non RFC-conform character. Other such characters resulted in an RCE, so this check is somewhat important. If there is no other firmware available, I am afraid you have to build your own cups package. The culprit is in 0024-CVE-2024-47175-and-further-hardening.patch for scheduler/ipp.c Thorsten
pt., 4 paź 2024 o 14:05 Thorsten Alteholz <debian@alteholz.de> napisał(a): There is newer firmware, although I do not see a way to apply it from Debian :-( One thing I do not understand is why this invalid input is being accepted over USB, but is a fatal error over TCP? Thanks for the pointer! I'll probably be able to hack around it, but I'm afraid less technically savvy users might not be so lucky. Perhaps there should be a break-glass option to keep being able to use one's hardware? Marcin
I managed to upgrade the printer firmware using its embedded webserver UI (from SAYAWLPP1N001.2137A.00 created 2021-09-06, to SAYAWLPP1N002.2423A.00 to 2024-06-03). Unfortunately this did not help. However, I got my hands on the ipptool utility, and this is where it really gets interesting. I have now made the printer available via two channels: - directly over WiFi - via USB and Debian cups (host A), as before When I invoke the get-printer attributes on the printer directly like this: ipptool -j http://192.168.2.102:631/ipp/print get-printer-attributes.test > direct.json then the "media-supported" key in the output is correct - no empty values. However when I do it through the cups server on host A like this: ipptool -j http://192.168.192.1:631/printers/kotlownia2 get-printer-attributes.test > via-cups.json I get output with empty values, and an error just like the one found earlier in host B's error_log: "media-supported": Bad keyword value "" - invalid character (RFC 8011 section 5.1.4). So it looks like it's cups itself that injects the invalid empty values! The printer's response is (and probably was) correct! The exact difference of the critical part is as follows:--- direct_.json 2024-10-04 16:39:26.402511781 +0200 +++ via-cups_.json 2024-10-04 16:40:06.891135645 +0200 @@ -1,29 +1,36 @@ "media-supported": [ - "na_executive_7.25x10.5in", - "na_letter_8.5x11in", - "na_legal_8.5x14in", + "na_5x7_5x7in", + "oe_photo-l_3.5x5in", + "na_index-4x6_4x6in", + "na_foolscap_8.5x13in", "na_govt-letter_8x10in", - "na_invoice_5.5x8.5in", - "iso_a5_148x210mm", "iso_a4_210x297mm", + "iso_a5_148x210mm", + "iso_a6_105x148mm", "iso_b5_176x250mm", "jis_b5_182x257mm", - "jpn_oufuku_148x200mm", - "jpn_hagaki_100x148mm", - "iso_a6_105x148mm", - "na_index-4x6_4x6in", - "om_small-photo_100x150mm", - "na_5x7_5x7in", - "na_index-5x8_5x8in", + "na_legal_8.5x14in", "na_number-10_4.125x9.5in", - "iso_dl_110x220mm", "iso_c6_114x162mm", + "iso_dl_110x220mm", + "na_executive_7.25x10.5in", + "na_index-5x8_5x8in", + "na_letter_8.5x11in", "jpn_chou3_120x235mm", "jpn_chou4_90x205mm", - "oe_photo-l_3.5x5in", - "jpn_photo-2l_127x177.8mm", - "na_foolscap_8.5x13in", + "jpn_hagaki_100x148mm", + "custom_199.9x151.05mm_199.9x151.05mm", + "na_invoice_5.5x8.5in", + "oe_executive-fb_7.25x10.5in", + "oe_legal-fb_8.5x14in", + "oe_statement-fb_5.5x8.5in", + "om_b-5-fb_175.94x249.94mm", + "", + "om_envelope-dl-fb_109.98x219.96mm", + "om_envelope-c-6-fb_113.96x161.97mm", + "", + "oe_8-5x-13-fb_8.5x13in", "custom_min_3.5x5in", - "custom_max_8.5x14in" + "custom_max_5x14in" ], - "media-default": "iso_a4_210x297mm", + "media-default": "unknown",
Just in case it's useful in determining the cause for the corruption,
here's a diff over sorted lists:
$ diff -U 20 *_.json
--- direct_.json 2024-10-04 16:52:12.750114924 +0200
+++ via-cups_.json 2024-10-04 16:51:59.521916969 +0200
@@ -1,26 +1,33 @@
- "custom_max_8.5x14in",
+ "",
+ "",
+ "custom_199.9x151.05mm_199.9x151.05mm",
+ "custom_max_5x14in",
"custom_min_3.5x5in",
"iso_a4_210x297mm",
"iso_a5_148x210mm",
"iso_a6_105x148mm",
"iso_b5_176x250mm",
"iso_c6_114x162mm",
"iso_dl_110x220mm",
"jis_b5_182x257mm",
"jpn_chou3_120x235mm",
"jpn_chou4_90x205mm",
"jpn_hagaki_100x148mm",
- "jpn_oufuku_148x200mm",
- "jpn_photo-2l_127x177.8mm",
"na_5x7_5x7in",
"na_executive_7.25x10.5in",
"na_foolscap_8.5x13in",
"na_govt-letter_8x10in",
"na_index-4x6_4x6in",
"na_index-5x8_5x8in",
"na_invoice_5.5x8.5in",
"na_legal_8.5x14in",
"na_letter_8.5x11in",
"na_number-10_4.125x9.5in",
+ "oe_8-5x-13-fb_8.5x13in",
+ "oe_executive-fb_7.25x10.5in",
+ "oe_legal-fb_8.5x14in",
"oe_photo-l_3.5x5in",
- "om_small-photo_100x150mm",
+ "oe_statement-fb_5.5x8.5in",
+ "om_b-5-fb_175.94x249.94mm",
+ "om_envelope-c-6-fb_113.96x161.97mm",
+ "om_envelope-dl-fb_109.98x219.96mm",
I reported this issue upstream to https://github.com/OpenPrinting/cups/issues/1078 and it turned out that the root cause was some invalid names in the ppd file. It had an invalid character in some of the size names - the '#' in "Envelope#10", "JapaneseEnvelope#3.FB" and "JapaneseEnvelope#4.FB". I think it's still wrong for cups to respond with a syntactically invalid response to get-printer-attributes in this case, so I'm keeping this bug open for now. I'll clone it into another bug against hpcups which I think is responsible for the PPD file.
Hi, cups 2.4.11 (not yet packaged for Debian) is said in above issues/1078 to have a workaround for this. Regarding hplip, I looked at 3.24.4 upstream release (not yet packaged for Debian) and seems it still has the same problem. Looking at https://github.com/OpenPrinting/cups/issues/1078 I wonder if attached sed script acting on ppd files under ppd dir does fix this issue (I am a complete newbie to this and I do not have access to affected printer nor know at all about ppd format). Another thing, has this been reported to hplip upstream? Regards,
Hi, According to https://github.com/OpenPrinting/cups/issues/1078 this issue has been fixed upsteram in cups 2.4.11. Since cups 2.4.14 has already been uploaded to Debian I guess this bug report can be closed, at least in the cups side. Regards,
close 1084021 2.4.14-1 thanks