Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
Upstream report updated. https://github.com/OpenPrinting/cups-filters/issues/472#issuecomment-1173388702 I have added the following comments: 'It is notable that no such issues exist on Debian 10.0 (Buster) with the latest cups-oldstable,now available - driverless queues are created and everything prints as expected - and no trace of avahi, whereas cups[-browsed?] seems to depend on it in 11.3, where avahi cannot be purged without removing very much else too. It is also notable that when adding the driverless MFC-L2740DW printer in cups-web on Buster, there is no "Fax, driverless" option. The fax details seem to be included in driverless PPDs on Bullseye whether a "model" including "Fax" is chosen or not.'
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
I had forgotten that the testing in my previous message was with cups 2.3.3op2-3+deb11u1 where deleting all queues and restarting cups at least results in reliable queue creation for the autodetected printer. The situation is worse with 2.3.3op2-3+deb11u2. The queue for the auto-detected printer is only created if no other queue already exists. It still doesn't print. And even worse: $ sudo lpadmin -p testqhostname -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. lpadmin: Unable to open PPD "/tmp/3986562c28d87": Missing PPD-Adobe-4.x header on line 0. No queue is created even after reboot, retry. I will update upstream with the details of both sets of problems. Thanks, Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
tags 1013437 - unreproducible thanks On Sun 03 Jul 2022 at 06:00:28 +0100, Gareth Evans wrote: > On Sat 2 Jul 2022, at 23:43, Brian Potkin wrote: > [...] > > On Fri 01 Jul 2022 at 13:37:07 +0100, Gareth Evans wrote: > >> Driverless queues don't seem to work > >> no matter how set up. > > > > Yet earlier (and at OpenPrinting) you said: > > > > Having deleted all printers from system-config-printer, > > $ sudo lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m > > driverless:ipp://192.168.0.14/ipp/print > > now succeeds, and so does printing to it. > > Apologies, driverless queues only work if set up by lpadmin. > Everywhere queues work from cups-web. OK. That's clear enough. > > May I suggest you may not be able to reproduce the bug as you (said > you) don't have a fax-capable printer? Indeed you may. It had slipped my mind but it was the reason I thought upstream was a reasonable place to go. > It seems to me that my driverless print jobs end up in a fax queue if > the queue is created by cups-web or s-c-p. If this is the main > symptom, I would be grateful if you would advise if this changes what > the bug should be reported against. The PPD generated by everywhere suits queues set up by lpadmin and the CUPS web interface. One of the queues set up with cups-filters, driverless doesn't work. I'd stick with cups-filters for the time being. > I respect that you may no longer wish to be involved with this issue - > thanks for your help - here is some further info for info's sake :) > > At least one other user seems to have a similar problem: > > "However, printing does not work, although the printer gets data, but > then hangs." > https://lists.debian.org/debian-user/2022/06/msg00558.html > > The printer concerned there also appears to have airprint/fax > https://productz.com/en/samsung-xpress-sl-c480fw/p/wxnG7 > > Substituting "gives up" for "hangs", this reflects my issue too. > > I can find no significant difference between driverless PPDs, though > everywhere PPDs do not include fax details, and everywhere queues > added from cups-web succeed in printing. Might this be another > pointer to the issue? You are making a good case. > > $ history | grep testq-drvless > sudo lpadmin -p testq-drvless -v ipp://192.168.0.14/ipp/print -E -m > driverless:ipp://192.168.0.14/ipp/print > > $ sudo cat testq-drvless.ppd | grep -i fax > *NickName: "Brother MFC-L2740DW series, Fax, driverless, cups-filters 1.28.7" > *cupsIPPFaxOut: True > *OpenUI *faxPrefix/Pre-Dial Number: PickOne > *OrderDependency: 10 AnySetup *faxPrefix > *DefaultfaxPrefix: None > *faxPrefix None: "" > *CloseUI: *faxPrefix > *CustomfaxPrefix True: "" > *ParamCustomfaxPrefix Text: 1 string 0 64 > > $ history | grep ippeve > sudo lpadmin -p testq-ippeve -v ipp://192.168.0.14/ipp/print -E -m everywhere > > $ sudo cat testq-ippeve.ppd | grep -i fax > $ > > > Though even testq-drvless sometimes shows strange job attribs in s-c-p: > > "job-printer-state-message: Phone number for fax not valid! Fax cannot be > sent" > "job-printer-uri: ipp://localhost/printers/testq-drvless" > > though the job (from geany) actually printed. > > > $ sudo diff CUPSWEBDL.ppd testq-drvless.ppd > 20c20 > < *APSupplies: "http://mfcl2740dw.local./net/net/airprint.html; > --- > > *APSupplies: "http://192.168.0.14/net/net/airprint.html; > > $ sudo diff CUPSWEBDL.ppd SCPDL.ppd > $ > > $ ping mfcl2740dw.local > PING mfcl2740dw.local (192.168.0.14) 56(84) bytes of data. > 64 bytes from 192.168.0.14 (192.168.0.14): icmp_seq=1 ttl=255 time=9.80 ms > > $ ping mfcl2740dw.local. > PING mfcl2740dw.local. (192.168.0.14) 56(84) bytes of data. > 64 bytes from 192.168.0.14 (192.168.0.14): icmp_seq=1 ttl=255 time=3.62 ms > > $ sudo lpadmin -p testqhostname -v ipp://mfcl2740dw.local/ipp/print -E -m > driverless:ipp://mfcl2740dw.local/ipp/print > lpadmin: Printer drivers are deprecated and will stop working in a future > version of CUPS. > > $ sudo diff testqhostname.ppd CUPSWEBDL.ppd > $ > > > $ lp -d testqhostname /etc/nsswitch.conf > request id is testqhostname-56 (1 file(s)) > > Succeeds. Good. > /var/log/cups/error_log > [...] > 2833 D [03/Jul/2022:02:05:45 +0100] Create-Job > ipp://localhost/printers/testqhostname > [...] > 3359 D [03/Jul/2022:02:05:46 +0100] [Client 605] Processing GET > /printers/testqhostname.ppd > 3360 D [03/Jul/2022:02:05:46 +0100] [Client 605] > filename="/etc/cups/ppd/testqhostname.ppd", type=application/vnd.cups-ppd > [...] > 3794 D [03/Jul/2022:02:05:47 +0100] [Job 56] job-uri uri > ipp://mfcl2740dw.local:631/ipp/print/job-225 > 3805 D [03/Jul/2022:02:05:47 +0100] [Job 56] printer-uri uri > ipp://mfcl2740dw.local:631/ipp/print > > > $ lp -d CUPSWEBDL /etc/nsswitch.conf > request id is CUPSWEBDL-55 (1 file(s)) > > Fails. Not good, obviously. > /var/log/cups/error_log > [...] > 70 D [03/Jul/2022:02:04:51 +0100] Create-Job > ipp://localhost/printers/CUPSWEBDL > [from line 1349] > 71 D
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Sat 2 Jul 2022, at 23:43, Brian Potkin wrote: [...] > On Fri 01 Jul 2022 at 13:37:07 +0100, Gareth Evans wrote: >> Driverless queues don't seem to work >> no matter how set up. > > Yet earlier (and at OpenPrinting) you said: > > Having deleted all printers from system-config-printer, > $ sudo lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m > driverless:ipp://192.168.0.14/ipp/print > now succeeds, and so does printing to it. Apologies, driverless queues only work if set up by lpadmin. Everywhere queues work from cups-web. May I suggest you may not be able to reproduce the bug as you (said you) don't have a fax-capable printer? It seems to me that my driverless print jobs end up in a fax queue if the queue is created by cups-web or s-c-p. If this is the main symptom, I would be grateful if you would advise if this changes what the bug should be reported against. I respect that you may no longer wish to be involved with this issue - thanks for your help - here is some further info for info's sake :) At least one other user seems to have a similar problem: "However, printing does not work, although the printer gets data, but then hangs." https://lists.debian.org/debian-user/2022/06/msg00558.html The printer concerned there also appears to have airprint/fax https://productz.com/en/samsung-xpress-sl-c480fw/p/wxnG7 Substituting "gives up" for "hangs", this reflects my issue too. I can find no significant difference between driverless PPDs, though everywhere PPDs do not include fax details, and everywhere queues added from cups-web succeed in printing. Might this be another pointer to the issue? $ history | grep testq-drvless sudo lpadmin -p testq-drvless -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print $ sudo cat testq-drvless.ppd | grep -i fax *NickName: "Brother MFC-L2740DW series, Fax, driverless, cups-filters 1.28.7" *cupsIPPFaxOut: True *OpenUI *faxPrefix/Pre-Dial Number: PickOne *OrderDependency: 10 AnySetup *faxPrefix *DefaultfaxPrefix: None *faxPrefix None: "" *CloseUI: *faxPrefix *CustomfaxPrefix True: "" *ParamCustomfaxPrefix Text: 1 string 0 64 $ history | grep ippeve sudo lpadmin -p testq-ippeve -v ipp://192.168.0.14/ipp/print -E -m everywhere $ sudo cat testq-ippeve.ppd | grep -i fax $ Though even testq-drvless sometimes shows strange job attribs in s-c-p: "job-printer-state-message: Phone number for fax not valid! Fax cannot be sent" "job-printer-uri: ipp://localhost/printers/testq-drvless" though the job (from geany) actually printed. $ sudo diff CUPSWEBDL.ppd testq-drvless.ppd 20c20 < *APSupplies: "http://mfcl2740dw.local./net/net/airprint.html; --- > *APSupplies: "http://192.168.0.14/net/net/airprint.html; $ sudo diff CUPSWEBDL.ppd SCPDL.ppd $ $ ping mfcl2740dw.local PING mfcl2740dw.local (192.168.0.14) 56(84) bytes of data. 64 bytes from 192.168.0.14 (192.168.0.14): icmp_seq=1 ttl=255 time=9.80 ms $ ping mfcl2740dw.local. PING mfcl2740dw.local. (192.168.0.14) 56(84) bytes of data. 64 bytes from 192.168.0.14 (192.168.0.14): icmp_seq=1 ttl=255 time=3.62 ms $ sudo lpadmin -p testqhostname -v ipp://mfcl2740dw.local/ipp/print -E -m driverless:ipp://mfcl2740dw.local/ipp/print lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. $ sudo diff testqhostname.ppd CUPSWEBDL.ppd $ $ lp -d testqhostname /etc/nsswitch.conf request id is testqhostname-56 (1 file(s)) Succeeds. /var/log/cups/error_log [...] 2833 D [03/Jul/2022:02:05:45 +0100] Create-Job ipp://localhost/printers/testqhostname [...] 3359 D [03/Jul/2022:02:05:46 +0100] [Client 605] Processing GET /printers/testqhostname.ppd 3360 D [03/Jul/2022:02:05:46 +0100] [Client 605] filename="/etc/cups/ppd/testqhostname.ppd", type=application/vnd.cups-ppd [...] 3794 D [03/Jul/2022:02:05:47 +0100] [Job 56] job-uri uri ipp://mfcl2740dw.local:631/ipp/print/job-225 3805 D [03/Jul/2022:02:05:47 +0100] [Job 56] printer-uri uri ipp://mfcl2740dw.local:631/ipp/print $ lp -d CUPSWEBDL /etc/nsswitch.conf request id is CUPSWEBDL-55 (1 file(s)) Fails. /var/log/cups/error_log [...] 70 D [03/Jul/2022:02:04:51 +0100] Create-Job ipp://localhost/printers/CUPSWEBDL [from line 1349] 71 D [03/Jul/2022:02:04:55 +0100] [Client 581] Processing GET /printers/CUPSWEBDL.ppd 72 D [03/Jul/2022:02:04:55 +0100] [Client 581] filename="/etc/cups/ppd/CUPSWEBDL.ppd", type=application/vnd.cups-ppd [...] 1495 D [03/Jul/2022:02:04:56 +0100] [Job 55] job-uri uri ipp://mfcl2740dw.local:631/ipp/faxout/job-224 1506 D [03/Jul/2022:02:04:56 +0100] [Job 55] printer-uri uri ipp://mfcl2740dw.local:631/ipp/faxout lpstat -t shows cups-web created devices as: device for CUPSWEBDL: ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/ vs device for testq-drvless: ipp://192.168.0.14/ipp/print device for testq-ippeve: ipp://192.168.0.14/ipp/print - does the ipp:// string come from Avahi for cups-web created queues? That's the only place I can find that
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
tags 1013437 unreproducible thanks On Fri 01 Jul 2022 at 13:37:07 +0100, Gareth Evans wrote: > On Fri 1 Jul 2022, at 12:54, Brian Potkin wrote: > [...] > > Unexpected and not understandable. There is enough going on in this > > issue not to want to take it further. Your MFC-L2740DW understands > > Apple raster (image/urf): > > > > pdl=application/octet-stream,image/urf,image/pwg-rastei > > > > and /etc/nsswitch.conf should print. > > > > > Anyway, you report that everywhere and driverless queues work. > > Everywhere queues work if added via lpadmin or (I have just > discovered) cups web interface. Fine. It seems there aren't any CUPS or cups-filters bugs there. > Driverless queues don't seem to work > no matter how set up. Yet earlier (and at OpenPrinting) you said: Having deleted all printers from system-config-printer, $ sudo lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print now succeeds, and so does printing to it. > System-config-printer lists the printer twice under > > Add Printer > "Network Printer" > > one listing per connection - "IPP network printer via DNS-SD" or > "Driverless IPP" - neither of which print. The first will not (in general) print without a Brother vendor driver on the system. The second works for me. I think you see my problem in being unable to reproduce your observation. Apart from the printer model, our bullseye printing systems are (or should be) identical. > I am grateful for your help and quite understand the reluctance to > continue with a situation that doesn't make sense. It is the inability to reproduce your experience that makes me leery of seeing any bug in the printing system. > However, given that > > - airprint works from iphone The iphone will be sending Apple raster directly to the printer. It is obliged to by Apple's AirPrint specication. CUPS is not involved. It prints, whereas your dierct sending of Apple raster, for whatever reson, did not. > - driverless IPP works from cups 2.4 on Ubuntu 22.04 It works for me on Debian 11.3. > - I get the same behaviour from an identical printer on a > different network with the same Debian 11.3 system, and the original > printer with a different Debian 11.0 system > > there does seem to be a Debian-related bug somewhere. > > Is there anyone else you would suggest referring this to, or any other > package to consider filing against? `> > What chance is there of Debian updating cups in stable? Is there a > way to request consideration of this? > > Meanwhile, is using the cups 2.4 testing packages in stable unwise? > Or a known-working Buster version? > > I can manage well enough with everywhere printing, but the users I > support (if I upgrade them to Bullseye) will not appreciate the cups > web interface or lpadmin, s-c-p is preferred. I do not feel competent to triage this issue any further. s-c-p is not even uder the printin system umbrella. Cheers, Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Fri 1 Jul 2022, at 12:54, Brian Potkin wrote: [...] > Unexpected and not understandable. There is enough going on in this > issue not to want to take it further. Your MFC-L2740DW understands > Apple raster (image/urf): > > pdl=application/octet-stream,image/urf,image/pwg-rastei > > and /etc/nsswitch.conf should print. > > Anyway, you report that everywhere and driverless queues work. Everywhere queues work if added via lpadmin or (I have just discovered) cups web interface. Driverless queues don't seem to work no matter how set up. System-config-printer lists the printer twice under Add Printer > "Network Printer" one listing per connection - "IPP network printer via DNS-SD" or "Driverless IPP" - neither of which print. I am grateful for your help and quite understand the reluctance to continue with a situation that doesn't make sense. However, given that - airprint works from iphone - driverless IPP works from cups 2.4 on Ubuntu 22.04 - I get the same behaviour from an identical printer on a different network with the same Debian 11.3 system, and the original printer with a different Debian 11.0 system there does seem to be a Debian-related bug somewhere. Is there anyone else you would suggest referring this to, or any other package to consider filing against? What chance is there of Debian updating cups in stable? Is there a way to request consideration of this? Meanwhile, is using the cups 2.4 testing packages in stable unwise? Or a known-working Buster version? I can manage well enough with everywhere printing, but the users I support (if I upgrade them to Bullseye) will not appreciate the cups web interface or lpadmin, s-c-p is preferred. Many thanks again, Gareth > Also, > the error_logs show all filters completing successfully and cupsfilter > produces valid output. There do not appear to be any bugs in cups or > cups-filters. > > I would suggest closing #472 at OpenPrinting. > > Cheers, > > Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Thu 30 Jun 2022 at 23:18:42 +0100, Gareth Evans wrote: > On Thu 30 Jun 2022, at 14:57, Brian Potkin wrote: [...] > > 5. Send both files directly to the printer with > >netcat 192.168.0.14 9100 < ippeve.urf > > Command seemed to hang or await job completion. > > Printer printed a good 30-odd pages, either blank or containing a line > or two of binary/gibberish. > > Device job cancel button did not respond. Opened paper tray, pressed > cancel button, job stopped. Re-inserted tray, job continued. Opened > tray, cancelled job, ^C to stop netcat, power cycled printer, order > restored. > > >netcat 192.168.0.14 9100 < drvless.urf > > Same, though this time I stopped it after a few pages Unexpected and not understandable. There is enough going on in this issue not to want to take it further. Your MFC-L2740DW understands Apple raster (image/urf): pdl=application/octet-stream,image/urf,image/pwg-rastei and /etc/nsswitch.conf should print. Anyway, you report that everywhere and driverless queues work. Also, the error_logs show all filters completing successfully and cupsfilter produces valid output. There do not appear to be any bugs in cups or cups-filters. I would suggest closing #472 at OpenPrinting. Cheers, Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Thu 30 Jun 2022, at 23:18, Gareth Evans wrote: >> 1. Set up queues >>lpadmin -p testq-ippeve -v ipp://192.168.0.14/ipp/print -E -m everywhere >>lpadmin -p testq-drvless -v ipp://192.168.0.14/ipp/print -E -m >>driverless:ipp://192.168.0.14/ipp/print > > OK > Though lpadmin requires sudo. This doesn't seem to be significant (but not sure) as everywhere printing works via this method.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Thu 30 Jun 2022, at 14:57, Brian Potkin wrote: [...] > 1. Set up queues >lpadmin -p testq-ippeve -v ipp://192.168.0.14/ipp/print -E -m everywhere >lpadmin -p testq-drvless -v ipp://192.168.0.14/ipp/print -E -m >driverless:ipp://192.168.0.14/ipp/print OK > 2. As root, do >cupsfilter -p /etc/cups/ppd/testq-ippeve.ppd -m printer/foo -e > /etc/nsswitch.conf > ippeve.urf >cupsfilter -p /etc/cups/ppd/testq-drvless.ppd -m printer/foo -e > /etc/nsswitch.conf > drvless.urf OK > 3. Open ippeve.urf and drvless.urf with less and check for UNIRAST at >the top left corner. Present in both files > Give the file sizes. $ ls -l *.urf -rw-r--r-- 1 user user 195639 Jun 30 22:58 drvless.urf -rw-r--r-- 1 user user 48332 Jun 30 22:57 ippeve.urf > View the files with >rasterview. Both look fine > 4. Check the printer has an open port 9100. $ nmap 192.168.0.14 Starting Nmap 7.80 ( https://nmap.org ) at 2022-06-30 23:01 BST Nmap scan report for 192.168.0.14 Host is up (0.030s latency). Not shown: 993 closed ports PORT STATE SERVICE 21/tcp open ftp 23/tcp open telnet 80/tcp open http 443/tcp open https 515/tcp open printer 631/tcp open ipp 9100/tcp open jetdirect > 5. Send both files directly to the printer with >netcat 192.168.0.14 9100 < ippeve.urf Command seemed to hang or await job completion. Printer printed a good 30-odd pages, either blank or containing a line or two of binary/gibberish. Device job cancel button did not respond. Opened paper tray, pressed cancel button, job stopped. Re-inserted tray, job continued. Opened tray, cancelled job, ^C to stop netcat, power cycled printer, order restored. >netcat 192.168.0.14 9100 < drvless.urf Same, though this time I stopped it after a few pages Thanks, Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Thu 30 Jun 2022 at 01:03:27 +0100, Gareth Evans wrote: > Does that mean cups-filters is not the appropriate package to file > against? If so, do you have any suggestions as to which might be? It indicates the everywhere and driverless models are behaving as expected. Let's continue this line of inquiry: 1. Set up queues lpadmin -p testq-ippeve -v ipp://192.168.0.14/ipp/print -E -m everywhere lpadmin -p testq-drvless -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print 2. As root, do cupsfilter -p /etc/cups/ppd/testq-ippeve.ppd -m printer/foo -e /etc/nsswitch.conf > ippeve.urf cupsfilter -p /etc/cups/ppd/testq-drvless.ppd -m printer/foo -e /etc/nsswitch.conf > drvless.urf 3. Open ippeve.urf and drvless.urf with less and check for UNIRAST at the top left corner. Give the file sizes. View the files with rasterview. 4. Check the printer has an open port 9100. 5. Send both files directly to the printer with netcat 192.168.0.14 9100 < ippeve.urf netcat 192.168.0.14 9100 < drvless.urf Cheers, Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
Does that mean cups-filters is not the appropriate package to file against? If so, do you have any suggestions as to which might be? Thanks, Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Tue 28 Jun 2022 at 11:47:57 +0100, Gareth Evans wrote: > OK thanks for your help. I have updated the upstream report and will > update here when further info is available. For printing your log shows: D [28/Jun/2022:02:55:42 +0100] [Job 42] 6 filters for job: D [28/Jun/2022:02:55:42 +0100] [Job 42] bannertopdf (application/vnd.cups-pdf-banner to application/pdf, cost 32) D [28/Jun/2022:02:55:42 +0100] [Job 42] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66) D [28/Jun/2022:02:55:42 +0100] [Job 42] gstoraster (application/vnd.cups-pdf to application/vnd.cups-raster, cost 99 ) D [28/Jun/2022:02:55:42 +0100] [Job 42] rastertopwg (application/vnd.cups-raster to image/urf, cost 100) D [28/Jun/2022:02:55:42 +0100] [Job 42] - (image/urf to printer/cupsweb3/image/urf, cost 0) D [28/Jun/2022:02:55:42 +0100] [Job 42] - (printer/cupsweb3/image/urf to printer/cupsweb3, cost 0) Searching for "exited with no errors" shows they all the filters completed successfully. The everywhere model uses the same filter chain. Cheers, Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
OK thanks for your help. I have updated the upstream report and will update here when further info is available.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Tue 28 Jun 2022 at 11:03:14 +0100, Brian Potkin wrote: > I am not certain, but it probably is. Please send the log to the > upstream bug report. I think a .txt suffix will have to be added > for it to be accepred. Forgot to mention: I do not have a fax-enabled device to test further. -- Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Tue 28 Jun 2022 at 03:07:52 +0100, Gareth Evans wrote:
> And FWIW, attached is an end-of-log extract of creating a driverless IPP
> printer ("cupsweb3") from cups web interface, then printing a test page.
> Again, s-c-p reports job completed, but nothing printed.
>
> There are continued references to "ipp/faxout" - and no references to
> ipp/print.
>
> Eg:
>
> line
> 2584 D [28/Jun/2022:02:55:42 +0100] [Job 42] Calling
> FindDeviceById(cups-cupsweb3)
> 2585 D [28/Jun/2022:02:55:42 +0100] [Job 42] Resolved as
> \"ipp://mfcl2740dw.local:631/ipp/faxout\"...
>
> Might this be relevant?
I am not certain, but it probably is. Please send the log to the
upstream bug report. I think a .txt suffix will have to be added
for it to be accepred.
Cheers,
Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
And FWIW, attached is an end-of-log extract of creating a driverless IPP
printer ("cupsweb3") from cups web interface, then printing a test page.
Again, s-c-p reports job completed, but nothing printed.
There are continued references to "ipp/faxout" - and no references to ipp/print.
Eg:
line
2584 D [28/Jun/2022:02:55:42 +0100] [Job 42] Calling
FindDeviceById(cups-cupsweb3)
2585 D [28/Jun/2022:02:55:42 +0100] [Job 42] Resolved as
\"ipp://mfcl2740dw.local:631/ipp/faxout\"...
Might this be relevant?
Thanks,
Gareth
cupsweb.txt.xz
Description: application/xz
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
Sorry, I forgot to compress the log. Added printer name is "DLIPP", logging relating to which seems to start at line 1537. Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022 at 19:31:11 +0100, Brian Potkin wrote: > >/var/lod/error_log /var/log/error_log, of course. -- Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022 at 18:43:16 +0100, Gareth Evans wrote: > On Mon 27 Jun 2022, at 18:41, Till Kamppeter wrote: > [...] > > Seems that it is able to access the printer for sending a job to it > > (done as user "lp"?) but not to poll the printer's capabilities via IPP > > (when running the "lpadmin" command). > > The printer/queue was not created, so I didn't get as far as testing printing. > > Which is to say that testqq didn't appear in system-config-printer. ipp://192.168.0.14/ipp/print is the most fundamental URI available. Assuming the IP address is unchanged, do (as root) cupsctl --debug-logging >/var/lod/error_log Set up a driverless queue as before. Compress error_log with gz or xz and send it here. Cheers, Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022, at 18:41, Till Kamppeter wrote: [...] > Seems that it is able to access the printer for sending a job to it > (done as user "lp"?) but not to poll the printer's capabilities via IPP > (when running the "lpadmin" command). The printer/queue was not created, so I didn't get as far as testing printing. Which is to say that testqq didn't appear in system-config-printer.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On 27/06/2022 19:26, Gareth Evans wrote: "testq" already exists, so I changed the queue name to avoid any potential caching effects etc in case that were possible. $ sudo lpadmin -p testqq -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. lpadmin: Unable to open PPD "/tmp/075ef62bac756": Missing PPD-Adobe-4.x header on line 0. That's the first time I've seen this error message. Seems that it is able to access the printer for sending a job to it (done as user "lp"?) but not to poll the printer's capabilities via IPP (when running the "lpadmin" command).
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022, at 18:04, Brian Potkin wrote: [...] > Set up > > lpadmin -p testeveq -v ipp://192.168.0.14/ipp/print -E -m everywhere > > and print to testeveq as before. We expect this to work. Yes, it prints > Now > > lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m > driverless:ipp://192.168.0.14/ipp/print > > and print to testq. How does that go? "testq" already exists, so I changed the queue name to avoid any potential caching effects etc in case that were possible. $ sudo lpadmin -p testqq -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. lpadmin: Unable to open PPD "/tmp/075ef62bac756": Missing PPD-Adobe-4.x header on line 0. That's the first time I've seen this error message. Thanks, Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022 at 17:22:22 +0100, Gareth Evans wrote: > On Mon 27 Jun 2022, at 17:11, Till Kamppeter wrote: > > And are you able to print now? > > > > Till > > > > Only to the queue added via lpadmin ... everywhere > > No autodetected printers appear in system-config-printer or application print > dialogs. > > $ sudo lpadmin -p testq -v > "ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local" -E -m > driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local" > [sudo] password for user: > lpadmin: Printer drivers are deprecated and will stop working in a future > version of CUPS. > > $ lp -d testq /etc/nsswitch.conf > request id is testq-12 (1 file(s)) > > Nothing prints over 5GHz, nor 2.5GHz wifi connections. > > Same behaviour as before in both cases - printer lights up but nothing prints. The problem I have here is in understanding. A queue set up with the cups-filters driverless for -m is based strongly on CUPS everywhere. Here is a URI for the device. It is equivalent to what you already have: ipp://192.168.0.14/ipp/print Set up lpadmin -p testeveq -v ipp://192.168.0.14/ipp/print -E -m everywhere and print to testeveq as before. We expect this to work. Now lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print and print to testq. How does that go? Cheers, Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022, at 17:11, Till Kamppeter wrote: > And are you able to print now? > > Till > Only to the queue added via lpadmin ... everywhere No autodetected printers appear in system-config-printer or application print dialogs. $ sudo lpadmin -p testq -v "ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local" -E -m driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local" [sudo] password for user: lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. $ lp -d testq /etc/nsswitch.conf request id is testq-12 (1 file(s)) Nothing prints over 5GHz, nor 2.5GHz wifi connections. Same behaviour as before in both cases - printer lights up but nothing prints. Thanks, Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
And are you able to print now? Till On 27/06/2022 17:57, Gareth Evans wrote: However that is when the laptop is connected to 5GHz wifi. If I change to the 2.5GHz connection (same router) on which (router and frequency) the printer is connected: $ avahi-browse -rt _ipp._tcp + wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local = wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local hostname = [mfcl2740dw.local] address = [192.168.0.14] port = [631] txt = ["print_wfds=T" "UUID=e3248000-80ce-11db-8000-30055ca3d8ec" "PaperMax=legal-A4" "kind=document,envelope,label" "URF=W8,CP1,IS4-1,MT1-3-4-5-8,OB10,PQ4,RS200-300-600,V1.3,DM1" "rfo=ipp/faxout" "TBCP=F" "Transparent=T" "Binary=T" "PaperCustom=T" "Scan=T" "Fax=T" "Duplex=T" "Copies=T" "Color=F" "usb_CMD=PJL,PCL,PCLXL,URF" "usb_MDL=MFC-L2740DW series" "usb_MFG=Brother" "priority=25" "adminurl=http://mfcl2740dw.local./net/net/airprint.html; "product=(Brother MFC-L2740DW series)" "ty=Brother MFC-L2740DW series" "note=" "rp=ipp/print" "pdl=application/octet-stream,image/urf,image/pwg-raster" "qtotal=1" "txtvers=1"] $ avahi-browse -rt _uscan._tcp $
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022, at 16:57, Gareth Evans wrote: > However that is when the laptop is connected to 5GHz wifi. > If I change to the 2.5GHz connection (same router) on which (router and > frequency) the printer is connected [...] Switching back to 5GHz $ avahi-browse -rt _ipp._tcp now provides the same output as above. Thanks, Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022, at 16:50, Gareth Evans wrote: > $ avahi-browse -rt _ipp._tcp > + wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet > Printer local > Failed to resolve service 'Brother MFC-L2740DW series' of type > '_ipp._tcp' in domain 'local': Timeout reached > > $ avahi-browse -rt _uscan._tcp > $ However that is when the laptop is connected to 5GHz wifi. If I change to the 2.5GHz connection (same router) on which (router and frequency) the printer is connected: $ avahi-browse -rt _ipp._tcp + wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local = wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local hostname = [mfcl2740dw.local] address = [192.168.0.14] port = [631] txt = ["print_wfds=T" "UUID=e3248000-80ce-11db-8000-30055ca3d8ec" "PaperMax=legal-A4" "kind=document,envelope,label" "URF=W8,CP1,IS4-1,MT1-3-4-5-8,OB10,PQ4,RS200-300-600,V1.3,DM1" "rfo=ipp/faxout" "TBCP=F" "Transparent=T" "Binary=T" "PaperCustom=T" "Scan=T" "Fax=T" "Duplex=T" "Copies=T" "Color=F" "usb_CMD=PJL,PCL,PCLXL,URF" "usb_MDL=MFC-L2740DW series" "usb_MFG=Brother" "priority=25" "adminurl=http://mfcl2740dw.local./net/net/airprint.html; "product=(Brother MFC-L2740DW series)" "ty=Brother MFC-L2740DW series" "note=" "rp=ipp/print" "pdl=application/octet-stream,image/urf,image/pwg-raster" "qtotal=1" "txtvers=1"] $ avahi-browse -rt _uscan._tcp $ Thanks Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Mon 27 Jun 2022, at 13:20, Brian Potkin wrote: > [...] Please give > > avahi-browse -rt _ipp._tcp > avahi-browse -rt _uscan._tcp > Given that there is one manually set-up printer/queue (via lpadmin ... everywhere) $ avahi-browse -rt _ipp._tcp + wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local Failed to resolve service 'Brother MFC-L2740DW series' of type '_ipp._tcp' in domain 'local': Timeout reached $ avahi-browse -rt _uscan._tcp $ Thanks, Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Fri 24 Jun 2022 at 22:23:06 +0100, Gareth Evans wrote: > On Fri 24 Jun 2022, at 18:55, Brian Potkin wrote: [...] > > Print: > > > > lp -d testq /etc/nsswitch.conf > > > > The result? > > $ lp -d testq /etc/nsswitch.conf > request id is testq-8 (1 file(s)) > > Printer lights up and looks like business, but nothing prints. > > Job shows as "completed" in system-config-printer queue monitor, job > attributes include > > job-state-reasons: processing-to-stop-print I was a little remiss in not pursuing this further before going upstrean. Please give avahi-browse -rt _ipp._tcp avahi-browse -rt _uscan._tcp avahi-browse is in the avahi-utils package. Cheers, Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Fri 24 Jun 2022, at 23:08, Brian Potkin wrote: [...] > Everywhere works. driverless doesn't work and neither does s-c-p. > s-c-p uses driverless. > > Please reprt upstream: > > https://github.com/OpenPrinting/cups-filters/issues > > Cheers, > > Brian. Reported here https://github.com/OpenPrinting/cups-filters/issues/472 Many thanks Gareth
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On Fri 24 Jun 2022, at 18:55, Brian Potkin wrote: > tags 1013437 moreinfo > thanks > > > > On Thu 23 Jun 2022 at 17:00:31 +0100, Gareth Evans wrote: > >> Package: cups >> Version: 2.3.3op2-3+deb11u2 >> Severity: normal >> X-Debbugs-Cc: donots...@fastmail.fm >> >> Dear Maintainer, >> >> *** Reporter, please consider answering these questions, where appropriate >> *** >> >>* What led up to the situation? >> >> Attempting to print to driverless printer queue for airprint printer. >> >>* What exactly did you do (or not do) that was effective (or >> ineffective)? >> >> Brother MFC-L2740DW with print/fax/scan/copy abilities has stopped printing >> from queues not added with lpadmin. >> >> Autodetected queues, as well as those added via cups web interface or system- >> config-printer, do not produce output. >> >> This worked until recently, though I don't print often so don't know when it >> changed. >> >> Printing only works if a queue is added by using the lpadmin command: >> >> $ sudo lpadmin -p MFC-L2740DW -v >> ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/ -E -m everywhere >> >> Autodetected printer queues are not created if a maually-added printer is >> already set up. >> >>* What was the outcome of this action? >> >> No physical output from printer. > > Thank you for your report, Gareth. > > Set up > > lpadmin -p testq -v > "ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" -E -m > driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" $ sudo lpadmin -p testq -v "ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" -E -m driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. > > Print: > > lp -d testq /etc/nsswitch.conf > > The result? $ lp -d testq /etc/nsswitch.conf request id is testq-8 (1 file(s)) Printer lights up and looks like business, but nothing prints. Job shows as "completed" in system-config-printer queue monitor, job attributes include job-state-reasons: processing-to-stop-print $ lpstat -t scheduler is running system default destination: MFC-L2740DW device for MFC-L2740DW: ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/ device for testq: ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local MFC-L2740DW accepting requests since Sun 19 Jun 2022 14:55:14 BST testq accepting requests since Fri 24 Jun 2022 22:16:04 BST printer MFC-L2740DW is idle. enabled since Sun 19 Jun 2022 14:55:14 BST printer testq is idle. enabled since Fri 24 Jun 2022 22:16:04 BST Thanks Gareth > > Regards, > > Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
tags 1013437 moreinfo thanks On Thu 23 Jun 2022 at 17:00:31 +0100, Gareth Evans wrote: > Package: cups > Version: 2.3.3op2-3+deb11u2 > Severity: normal > X-Debbugs-Cc: donots...@fastmail.fm > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > Attempting to print to driverless printer queue for airprint printer. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Brother MFC-L2740DW with print/fax/scan/copy abilities has stopped printing > from queues not added with lpadmin. > > Autodetected queues, as well as those added via cups web interface or system- > config-printer, do not produce output. > > This worked until recently, though I don't print often so don't know when it > changed. > > Printing only works if a queue is added by using the lpadmin command: > > $ sudo lpadmin -p MFC-L2740DW -v > ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/ -E -m everywhere > > Autodetected printer queues are not created if a maually-added printer is > already set up. > >* What was the outcome of this action? > > No physical output from printer. Thank you for your report, Gareth. Set up lpadmin -p testq -v "ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" -E -m driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" Print: lp -d testq /etc/nsswitch.conf The result? Regards, Brian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
Package: cups Version: 2.3.3op2-3+deb11u2 Severity: normal X-Debbugs-Cc: donots...@fastmail.fm Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Attempting to print to driverless printer queue for airprint printer. * What exactly did you do (or not do) that was effective (or ineffective)? Brother MFC-L2740DW with print/fax/scan/copy abilities has stopped printing from queues not added with lpadmin. Autodetected queues, as well as those added via cups web interface or system- config-printer, do not produce output. This worked until recently, though I don't print often so don't know when it changed. Printing only works if a queue is added by using the lpadmin command: $ sudo lpadmin -p MFC-L2740DW -v ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/ -E -m everywhere Autodetected printer queues are not created if a maually-added printer is already set up. * What was the outcome of this action? No physical output from printer. lpstat -t at varying times, shows "Waiting for job to complete". "No suitable Destination Host found by cups-browsed" "Printer disappeared or cups-browsed shutdown" Sometimes jobs apparently succeed, according to queue monitors and lpstat, but still nothing prints. The printer lights up and whirrs as expected, but no output emerges. Documents print as expected via cups on ubuntu 22.04, as well as via airprint from iphone. Printer prints reports from its own console menus as expected. * What outcome did you expect instead? Documents print. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups depends on: ii cups-client2.3.3op2-3+deb11u2 ii cups-common2.3.3op2-3+deb11u2 ii cups-core-drivers 2.3.3op2-3+deb11u2 ii cups-daemon2.3.3op2-3+deb11u2 ii cups-filters 1.28.7-1+deb11u1 ii cups-ppdc 2.3.3op2-3+deb11u2 ii cups-server-common 2.3.3op2-3+deb11u2 ii debconf [debconf-2.0] 1.5.77 ii ghostscript9.53.3~dfsg-7+deb11u2 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.31-13+deb11u3 ii libcups2 2.3.3op2-3+deb11u2 ii libgcc-s1 10.2.1-6 ii libstdc++6 10.2.1-6 ii libusb-1.0-0 2:1.0.24-3 ii poppler-utils 20.09.0-3.1 ii procps 2:3.3.17-5 Versions of packages cups recommends: ii avahi-daemon 0.8-5 ii colord1.4.5-3 Versions of packages cups suggests: pn cups-bsd pn cups-pdf pn foomatic-db-compressed-ppds | foomatic-db ii smbclient 2:4.13.13+dfsg-1~deb11u3 ii udev 247.3-7 -- debconf information: cupsys/raw-print: true
