Thank you for your report, Sam. On Sat 26 Oct 2019 at 12:57:48 +0100, Sam Morris wrote: > Package: cups-daemon > Version: 2.3.0-5 > Severity: normal > File: /usr/lib/cups/backend/ipp > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I turned my trusty Dell 2330dn back on today and found that my Debian > machine is no longer able to print to it via IPP. > > Printing via WS-Print from a Windows machine works, so it's a problem > on the CUPS side. > > I've attached a pcapng file capturing all communication between CUPS and > the printer. I'm having a bit of trouble interpreting it: you can see > the Validate-Job request split between frames 102 and 103, followed > immediately by the connection being closed *by the IPP backend* in frame > 104! My skills do not extend to interpreting this file. > But here's what CUPS logs (edited, but see the attached error_log.gz for > everything) > > D [26/Oct/2019:12:34:32 +0100] [Job 228] Validate-Job IPP/1.1 > D [26/Oct/2019:12:34:32 +0100] [Job 228] printer-uri=\"ipp://192.168.2.103:631/prt0\" > D [26/Oct/2019:12:34:32 +0100] [Job 228] requesting-user-name=\"sam\" > D [26/Oct/2019:12:34:32 +0100] [Job 228] job-name=\"228 - Test Page\" > D [26/Oct/2019:12:34:32 +0100] [Job 228] document-format=\"application/octet-stream\" > D [26/Oct/2019:12:34:32 +0100] [Job 228] IPP/1.1 Validate-Job #3 > D [26/Oct/2019:12:34:32 +0100] [Job 228] ---- operation-attributes-tag ---- > D [26/Oct/2019:12:34:32 +0100] [Job 228] attributes-charset charset utf-8 > D [26/Oct/2019:12:34:32 +0100] [Job 228] attributes-natural-language naturalLanguage en-us > D [26/Oct/2019:12:34:32 +0100] [Job 228] printer-uri uri ipp://192.168.2.103:631/prt0 > D [26/Oct/2019:12:34:32 +0100] [Job 228] requesting-user-name nameWithoutLanguage sam > D [26/Oct/2019:12:34:32 +0100] [Job 228] job-name nameWithoutLanguage 228 - Test Page > D [26/Oct/2019:12:34:32 +0100] [Job 228] document-format mimeMediaType application/octet-stream > D [26/Oct/2019:12:34:32 +0100] [Job 228] ---- end-of-attributes-tag ---- > D [26/Oct/2019:12:34:32 +0100] [Job 228] Validate-Job: server-error-internal-error (Success) > D [26/Oct/2019:12:34:32 +0100] [Job 228] ---- end-of-attributes-tag ---- > D [26/Oct/2019:12:34:32 +0100] [Job 228] PID 12609 (/usr/lib/cups/backend/ipp) stopped with status 4. > I [26/Oct/2019:12:34:32 +0100] [Job 228] Backend returned status 4 (stop printer) > I [26/Oct/2019:12:34:32 +0100] [Job 228] Printer stopped due to backend errors; please consult the /var/log/cups/error_log file for details. > > Here it looks like the IPP backend has decided that the printer told it > that there was a problem in response to its Validate-Job request, but > the network traffic says otherwise! > > There's one other relevant piece of the puzzle. When I originally set > the printer up (years ago), I did so using the ipp14 backend. I don't > remember the reason why, but it could have been that the ipp backend > didn't work in the manner described above, but since the ipp14 backend > _did_ work, I didn't bother to report the problem. My recollection is that the CUPS ipp backend was further developed to conform more closely to IPP standards and its introduction led to some older printers failing to work with it. The ipp14 backend was the older less stringent backend and was kept for a while in Debian as a fallback. > Now of course, the ipp14 backend has been removed and I've changed the > queue over to using the ipp backend, and run into this problem as a > result. Upstream CUPS has occasionally remarked on IPP implementation in older printers not being up to scratch. I have attached the ipp14 backend to this post; perhaps you can test if it still works for you. It is also worthwhile doing 'nmap 192.168.2.103' to see whether the device has an open port 9100. Then socket://192.168.2.103 could be tried as the URI. Regards, Brian.
Attachment:
ipp14.gz
Description: application/gzip