Description of problem: The system only ever prints one copy of a document, regardless of what is entered in the print dialog. Version-Release number of selected component (if applicable): 2.4.2 How reproducible: Print any document using the CUPS "driverless" printer. Steps to Reproduce: 1.Open document in relevant app. 2.Open print dialog. 3.Specify more than 1 copy. Actual results: Only 1 copy printed Expected results: Specified number of copies printed Additional info: The same printer will print multiple copies using the old-style socket & ppd setup.
Hi Neil! Thank you for reporting the issue! I can see from you previous bug - https://bugzilla.redhat.com/show_bug.cgi?id=2087730 - that the device reports the following: copies-default 1 copies-supported 1-9999 so it can be an issue on sw side (hopefully, because it is more easier to fix it...), or unfortunately the device is on of those who report an option, but it doesn't support it in the end. For debugging this further it would be great if you provided: - cups logs from the time of the job with copies - we can check whether the option is sent to the printer and what is the printer's response - the name of application you used for printing - a different apps use a different ways how to communicate with CUPS - the network traffic capture for your printer - see https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/#_backend_job_transport , the part for IPP Thank you in advance! P.S. A difference between driverless and PPD+socket here is that driverless usually converts the document to a format accepted by the printer, but don't apply most of the options, because they're passed as IPP attributes and the printer advertised before it supports those attributes if you send them to the printer. In PPD+socket process all options are applied in filters, because a binary which listens on socket at the printer is not capable of doing advanced stuff - it just prints all the data it receives. The problem with driverless happens if the device advertises something, but it can do the other...
Sorry but don't really have time to follow this up at the moment. Will try to get to it sometime soon!
(In reply to Neil Romig from comment #2) > Sorry but don't really have time to follow this up at the moment. Will try > to get to it sometime soon! Might have some time to devote to this soon, so can you tell me where I find the interface name of the printer for tcpdump so i can do the network traffic capture?
Hi Neil, it is actually the name of interface on your machine (like eth0 or so - depends on 'ip a' output) via which the communication happens. So if you communicate with printer via ethernet, it is the interface where the wired connection is set to. For example for my machine: $ ip a ... 2: enp9s0u2u1u2: ... $ sudo tcpdump -n -i enp9s0u2u1u2 -U -s0 -w ipp.pcap port ipp
OK I've tried to get some info but seems very little? I tried to print 2 copies of a document using LibreOffice Writer (v7.3.4.2). 1) sudo tcpdump -n -i enp6s0 -U -s0 -w ipp.pcap port ipp This produces a 24 byte file which looks like this (using 'od -x') 0000000 c3d4 a1b2 0002 0004 0000 0000 0000 0000 0000020 0000 0004 0001 0000 0000030 2) the systemd journal is : Jul 27 06:46:43 neil-pc cupsd[941]: REQUEST localhost - - "POST /printers/Kyocera-TASKalfa-2552ci HTTP/1.1" 200 258 Create-Job successful-ok Jul 27 06:46:43 neil-pc cupsd[941]: REQUEST localhost - - "POST /printers/Kyocera-TASKalfa-2552ci HTTP/1.1" 200 222503 Send-Document successful-ok Jul 27 06:47:11 neil-pc cupsd[941]: Kyocera-TASKalfa-2552ci neil 300 [27/Jul/2022:06:47:11 +0100] total 2 - localhost Service Number - - Jul 27 06:48:57 neil-pc cupsd[941]: REQUEST localhost - - "POST / HTTP/1.1" 200 344 Create-Printer-Subscriptions successful-ok Jul 27 06:49:03 neil-pc cupsd[941]: REQUEST localhost - - "POST / HTTP/1.1" 200 7055494 CUPS-Get-PPDs - Jul 27 06:50:27 neil-pc cupsd[941]: REQUEST localhost - - "POST /admin/ HTTP/1.1" 200 105 - - Jul 27 06:50:27 neil-pc cupsd[941]: REQUEST localhost - - "POST /admin/ HTTP/1.1" 200 9653 - -
Created attachment 1899581 [details] CUPS error log
Created attachment 1899582 [details] CUPS error log
I'm sorry, Neil, neither of those files contain the debug logging for the job you printed. (Thank you for figuring out that I wanted debug logs - I hadn't mentioned it in the comment, kudos for being on the same wave as me :) ). Would you mind attaching the debug logs which contain the job? Ad network capture - my bad! I'm that used to having IPP, but I see your uri contains dnssd backend, which is then switched to ipps, which has a different port and whole communication is encrypted, so I can't read it unless I have the private key of your printer :D . Would you mind turning of encryption on your printer, reinstall the queue (you can check the device uri just to be sure - it shouldn't contain any 'ipps' after you turn off encryption on the printer and reinstall the queue) and catch the packet traffic during reproducing the problem again? I'm really sorry for inconvenience :(
An interesting development... I enabled ipp:// connections to printer and using CUPS web interface at localhost:631 modified the printer by manually specifying connection as ipp://192.168.92.3/ and keeping the existing "driverless" driver. Now I can print more than one copy, so the problem looks to be with the dnssd connection that CUPS generates automatically. Since I now seem to have a workable fix I'm happy, but would you like any more info from me to resolve the fault with the dnssd connection?
Also, if I connect using a CUPS discovered address of dnssd://Kyocera%20TASKalfa%202552ci._ipp._tcp.local/?uuid=4509a320-0073-0083-004a-002507501bfd I can also print multiple copies, making it look like a problem with the ipps:// connection. A minor irritation is that I now get an automatically discovered entry in the Gnome printer settings (with no options or details) which doesn't appear in the CUPS web interface.
(In reply to Neil Romig from comment #10) > Also, if I connect using a CUPS discovered address of > dnssd://Kyocera%20TASKalfa%202552ci._ipp._tcp.local/?uuid=4509a320-0073-0083- > 004a-002507501bfd I can also print multiple copies, making it look like a > problem with the ipps:// connection. Interesting - I've never heard of printer attribute issues only via IPPS - it is supposed to be the same protocol, just encrypted via TLS (which causes a different port usage). Can you upload a debug log for printing copies via IPPS? I won't be able to verify what is sent over network because of encryption, but maybe debug logging will be able to tell us something. > > A minor irritation is that I now get an automatically discovered entry in > the Gnome printer settings (with no options or details) which doesn't appear > in the CUPS web interface. Good - this is a temporary queue, which looks odd in Gnome settings, but works fine in actual print dialogs (at least in those which support it - GTK based and Libreoffice). Can you print with this entry from 'Document reader' (evince) and Libreoffice? Even copies? In case you can and it doesn't miss any other features you use, you can remove the old permanent queue and use this one.
The two attachments are from the original 2-copy print over the auto-discovered ipps connection (time of print job 06:49). As for the temporary queue, it is using the ipps:// URI (the printer still accepts IPPS) and I don't want a buggy printer entry in my print dialogs! There is alot of discussion about the unwanted automatic creation of print queues so I have followed some Google advice and disabled the avahi/cups setup by setting "use-ipv4=no" & "use-ipv6=no" in avahi-daemon.conf, commenting out "browselocalprotocols dnssd" in /etc/cups/cupsd.conf, and uncommenting "CreateIPPPrinterQueues No" in /etc/cups/cups-browsed.conf. I've seen variations on this process so what the "correct" way is!
(In reply to Neil Romig from comment #12) > The two attachments are from the original 2-copy print over the > auto-discovered ipps connection (time of print job 06:49). > None of those files shows logs related to a print job - any printed job has '[Job ' string on its line, there are no such lines in both files. I see there logging of CGI programs connected to CUPS Web UI and IPP requests they trigger, but no print job. Please attach CUPS debug log where it contains the job when you printed copies via IPPS. > As for the temporary queue, it is using the ipps:// URI (the printer still > accepts IPPS) and I don't want a buggy printer entry in my print dialogs! I thought you've disabled IPPS on your printer, so the temp queue appeared as IPP only (IPPS is preferred if both are enabled) - would you mind disabling IPPS on your printer and trying the temp queue? Regarding no options for such entry, we are planning to improve it in the near future https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1877 . > There is alot of discussion about the unwanted automatic creation of print > queues so I have followed some Google advice and disabled the avahi/cups > setup by setting "use-ipv4=no" & "use-ipv6=no" in avahi-daemon.conf, > commenting out "browselocalprotocols dnssd" in /etc/cups/cupsd.conf, and > uncommenting "CreateIPPPrinterQueues No" in /etc/cups/cups-browsed.conf. > I've seen variations on this process so what the "correct" way is! I don't quite recommend that - if you disable avahi daemon, you won't be able to see any printers in the future, unless you do define a printer profile (text file in a certain format which libcups will read during listing printers - it is among features for CUPS 3.0, which removes printer drivers, divides CUPS into several modules and the CUPS Local Server module, the one who will accept print job requests, will work only with printers from mDNS and printer profiles). So in case your plain IPP temporary queue will work for you, then you don't have to install your printer anymore, but currently it won't work without mDNS.
I enabled IPP and didn't want to disable IPPS in case it disrupted any other print users (it is our office printer). But anyway, I have re-enabled the cups/avahi stuff on my PC (it caused problems printing) and now find that cups now offers me these 3 discovered URIs for the printer: 1) dnssd://Kyocera%20TASKalfa%202552ci._ipp._tcp.local/?uuid=4509a320-0073-0083-004a-002507501bfd 2) ipps://Kyocera%20TASKalfa%202552ci._ipps._tcp.local/ 3) socket://192.168.92.3 The dnssd ipps connection is no longer offered. Thanks for your help, but as I don't really have enough time to devote to this (it is too obscure and confusing for me) I am turning off SSL on the printer and going with the plain IPP connections.
Just as a last note, I now find Gnome (or cups) is creating a "local raw" printer (whatever that is) at ipp://km4e5e25.local:631/ipp/print and I can't get it to find the ipp:// URI and I have lost the will to cope with the nightmare that is Linux printing!
(In reply to Neil Romig from comment #14) > I enabled IPP and didn't want to disable IPPS in case it disrupted any other > print users (it is our office printer). That's the problem with permanently installed queues - if something changes in the network - like disabling IPPS - it breaks the setup. Temporary queues don't have this problem - they are created at the time the print dialog is brought up based on whatever shows up on mDNS and removed after successful printing. So they are recreated every time you print and you don't need to care whether you switched from IPP to IPPS on printer or vice versa. > > But anyway, I have re-enabled the cups/avahi stuff on my PC (it caused > problems printing) I would expect that, because Avahi does the mDNS resolution by default and you installed the permanent queue with uri which uses mDNS hostname :) > and now find that cups now offers me these 3 discovered > URIs for the printer: > > 1) > dnssd://Kyocera%20TASKalfa%202552ci._ipp._tcp.local/?uuid=4509a320-0073-0083- > 004a-002507501bfd > 2) ipps://Kyocera%20TASKalfa%202552ci._ipps._tcp.local/ > 3) socket://192.168.92.3 > > The dnssd ipps connection is no longer offered. Hmm... but the other uri shows ipps - maybe there is a race condition somewhere which causes dnssd _ipp showed instead of _ipps. Either way, you shouldn't care about what URI CUPS shows - because your printer is capable of using temporary queues, so the critical point here is whether the printer is shown in print dialog (window which opens when you want to print from application) and whether you can print to it. > > Thanks for your help, but as I don't really have enough time to devote to > this (it is too obscure and confusing for me) I am turning off SSL on the > printer and going with the plain IPP connections. No problem - in case you will find a time to try what I said and got the data, I can reopen the issue. (In reply to Neil Romig from comment #15) > Just as a last note, I now find Gnome (or cups) is creating a "local raw" > printer (whatever that is) at ipp://km4e5e25.local:631/ipp/print and I can't > get it to find the ipp:// URI and I have lost the will to cope with the > nightmare that is Linux printing! As I already wrote several times, use the temporary queue GNOME created for you automatically in case you turned off IPPS and otherwise the queue works for you. Manual installation is not needed, either via GNOME or CUPS, so you don't need to care what URI is found.
Just for my sake, I decided to uninstall cups and remove all directories and start with a clean install. I have now only the discovered printer in Gnome settings connected with an address of "http://Kyocera TASKalfa 2552ci._ipp._tcp.local:631" and this printer does not show in CUPS web interface. It does all work, excepting the lack of driver functionality (which I've mentioned in bug 2087730) for which I'll have to use a Windows PC!
FTR, what functionality is missing when using temporary queue? And which of the missing functionality is important for you (meaning you do use it often)? Can you get me the ipp.attr file from : $ ipptool --ippserver ipp.attr ipp://192.168.92.3:631/ipp/print get-printer-attributes.test if you find a time (I hope the IP is your printer's ip...)? BTW, I have a fix for 2087730 on the track, so you will be able to use Kyocera classic driver as well, in case you will want to switch back to the classic driver.
Created attachment 1899995 [details] IPP attributes Output from ipptool --ippserver ipp.attr ipp://192.168.92.3:631/ipp/print get-printer-attributes.test
Created attachment 1900000 [details] Temporary Queue Properties #1 Screenshot of print queue properties dialog
Created attachment 1900001 [details] Temporary Queue Properties #2 Screenshot of print queue properties dialog
My main issue is not being able to save print output to the printer's HDD for easy reprinting. This facility is called "Custom Box" and I guess it just saves to directories on the printer's HDD. It means our workshop can print out various forms without needing to sit at a desk and use the PC. It is only available using Kyocera's own software (kyodialog) so maybe not something that can be implemented via IPP? I can only get kyodialog to recognise a printer attached via the "old-fashioned" socket interface (which is how our Windows driver is set up). Alot of the other printer options are duplicated by LibreOffice (page scaling, multiple pages per sheet etc) so not too worried about those.
(In reply to Neil Romig from comment #22) > My main issue is not being able to save print output to the printer's HDD > for easy reprinting. This facility is called "Custom Box" and I guess it > just saves to directories on the printer's HDD. It means our workshop can > print out various forms without needing to sit at a desk and use the PC. I guess printing copies couldn't help you here, could it? Otherwise what I was able to find was reprinting from the PC (via CUPS web UI), which does not serve your needs. > It is only available using Kyocera's own software (kyodialog) so maybe not > something that can be implemented via IPP? I will ask on printing-architecture.org whether other people know something about it. IMHO something similar is already implemented in IPP (like CUPS web UI can reprint jobs, and it communicates with cupsd via IPP - there is an IPP Job Operation called IPP_OP_RESTART_JOB for this), but vendor didn't implement it in printer's firmware, either due old habit to have in driver, or due reason of free space in memory... I could imagine the printer having the same approach as cupsd (both are IPP implementations) - you could find the job in the log on the printer, and there would be a button which would reprint the job... but again, it would depend on firmware implementation. > I can only get kyodialog to > recognise a printer attached via the "old-fashioned" socket interface (which > is how our Windows driver is set up). > Alot of the other printer options are duplicated by LibreOffice (page > scaling, multiple pages per sheet etc) so not too worried about those.
The printer has a touch screen which is easy to select the documents for printing vs. finding a free desk (which might be Fedora or Windows) and printing from the application (fraught with pitfalls such as making sure print options are correct, and staff familiar with the software). The printer HDD saves the printout indefinitely, I don't know if CUPS (again assuming we are printing from Fedora rather than Windows) would be capable of this? What it boils down to is: 1) I don't want two printer queues for the Kyocera (one socket, and 1 temporary) 2) The printer's Custom Box is a facility we like and have got used to, but we managed without it (pre-Kyocera) so just looking for the convenient functionality to be kept.
(In reply to Neil Romig from comment #24) > The printer has a touch screen which is easy to select the documents for > printing vs. finding a free desk (which might be Fedora or Windows) and > printing from the application (fraught with pitfalls such as making sure > print options are correct, and staff familiar with the software). > > The printer HDD saves the printout indefinitely, I don't know if CUPS (again > assuming we are printing from Fedora rather than Windows) would be capable > of this? Once you put 'PreserveJobFiles yes' and 'PreserveJobHistory yes' into /etc/cups/cupsd.conf and restart cups service, you will be able to restart any job you've printed from your PC via CUPS Web UI at localhost:631. It is not the exactly the same functionality as IPP Job Storage is (you don't have access to print jobs of other users, which you would have if it is the proper job storage implementation), but it does the trick. In case you would like to reprint jobs of other people, you could set up a server on a separate machine, let the others print via the server and you will get access for reprinting any job which will come to the printer via that server. As you see in the email communication where I added you to, IPP standard already covers it, and some manufacturers already implemented it in printer's firmware - however your printer doesn't support it via IPP (according IPP output from comment #19), so even if CUPS had supported the exact operation as it had been defined in the standard, your printer wouldn't have been able to respond to it... > > What it boils down to is: > > 1) I don't want two printer queues for the Kyocera (one socket, and 1 > temporary) > 2) The printer's Custom Box is a facility we like and have got used to, but > we managed without it (pre-Kyocera) so just looking for the convenient > functionality to be kept. In case you are okay with reprinting via CUPS Web Interface and missing the default printer functionality, I would recommend using a temporary queue. Otherwise I would use the classic driver for now.