Driverless printer silently broken if the printer is not reachable upon creation

[rdiez]

I had a few "death by a thousand cuts" experiences with CUPS in the last days, both at home and at work, and I think I should report at least some of the issues here.

I am using CUPS version 2.4.1op1-1ubuntu4.4 which comes with Ubuntu 22.04.3.

I have recently bought a Brother HL-L2350DW, and CUPS autodetection seems iffy. When I turn the printer off, it takes a very long time for it to disapper from the CUPS GUI (system-config-printer).

Removing the printer with the GUI does not work. If I set it to disabled, it is re-enabled again the next time the printer is autodiscovered.

If I disable the printer, it is still shown as available in applications like LibreOffice Writer. I guess CUPS' idea of "disabling" is different from everybody else's, because the printer queue still accepts jobs and the printer is not grayed out.

In the GUI, option "View", "Discovered Printers" does not work, autodetected printers are always shown regardless. There is no easy way to disable printer autodetection in the GUI. The URI is "implicitclass://Brother_HL_L2350DW_series/", which is meaningless. I wonder what would happen if I had 2 identical printers on the network.

It was not clear what protocol or what IP address CUPS was using for the auto-detected printer. I mean that the GUI does not display anything like "IPP" and "IP address xx.xx.xx.xx".

The trouble is, printing on the autodetected printer was not reliable: sometimes, it printed my document straight away, but at other times, the jobs remained forever in the queue, even though the printer was reachable with ping.

So I decided to manually add the printer with a known address and known protocol, in the hope that printing was more stable. I learnt that driverless printer is the way to go nowadays, so after digging around in the documentation, I came up with the following command:

lpadmin -p OurBrotherPrinter -E -v ipp://BRWxxxxxxxxxxxx.local/ipp/print -m everywhere -o printer-is-shared=false

The xxxxxxxxxxxx is the MAC address of the printer, and the .local name is some sort of LAN DNS broadcasting.

Apparently, lpadmin's option "-E" is position dependent, which is not very user friendly. A first, easy workaround would be to introduce longer, unique option names, like "--accept-and-enable".

By the way, I do not understand why new printers are shared by default, especially autodetected printers which anybody can autodetect on the network. A few days ago I read about a recently-fixed CUPS security bug impacting shared printers.

On the first Linux laptop, adding the printer with lpadmin worked fine. But on the second one, it didn't. There was no error or warning message, but when I tried printing a single-page PDF, the printer just took all paper sheets from the tray and printed nothing on them.

After some head scratching, I saw that the "Make and Model" on the 1st laptop was "HL-L2350DW series - IPP Everywhere", but on the 2nd laptop it was "Local Raw Printer".

It turns out that the printer was not reachable when it was created on the 2nd laptop. Because I was only adding the printer with the same command, and had nothing to print at the time, I did not realise that the printer was not turned on when I created it.

By the way, there is no way to see the printer's "Make and Model" from the command line.

I am guessing that CUPS / lpadmin needs to contact the printer beforehand in order to find out its characteristics, and it the printer is unreachable, then it is clear that it is not going to work. However, that is no excuse to create a broken printer without warning or error.

[debiantriage]

Let us reduce the number of moving parts and concentrate on CUPS by doing apt purge cups-browsed. (It is reinstalled easily enough with apt install cups-browsed).

Now give the outputs from

avahi-browse -rt _ipp._tcp

lpstat -l -e

[rdiez]

What are you trying to achieve with those commands? Do you think that something in my description shouldn't be happening? If so, what part then?

[debiantriage]

What are you trying to achieve with those commands?

I asked my question first. Having information about your system that you did not give is desirable to make progress.

[zdohnal]

@rdiez you combine several different projects in the report - cups, cups-browsed, system-config-printer, libreoffice... - some of the issues you report is caused by cups-browsed running on the machine (reappearance, unable to disable) because cups-browsed is running in loop, picking up the printer in certain intervals, installing the printer permanently (so s-c-p sees it as permanent printer, not discovered).

@debiantriage tries to help you to set the things via CUPS only, where you don't need cups-browsed nor permanent printer installation - which are CUPS temporary queues. This features is supported by main applications in Linux nowadays.

But what you experienced with lpadmin is a known issue - https://github.com/OpenPrinting/cups/issues/760 - we are working on it.

[rdiez]

OK, thanks for the confirmation about the biggest issue. I have subscribed to #760.

From your quick bug closing action I am guessing that you deem the many other "small cuts" I described above as not worth pursuing.

[zdohnal]

Most of them are caused by different projects, covered by man page (order dependency for -E in CLI commands) or provided by other commands (you can see make-model by lpoptions -p <printer>).

[rdiez]

covered by man page (order dependency for -E in CLI commands)

OK, so I gather you think that lpadmin's -E is user friendly enough, as it is documented on the man page, and you do not think that my suggestion about adding longer, unique option names, like "--accept-and-enable" is worth pursuing.

I did miss that "lpoptions -p" outputs the "Make and Model", thanks for the hint. This is what the output looks like: copies=1 device-uri=ipp://169.254.123.123/ipp/print finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 media=6 number-up=1 option=true output-bin=face-down print-color-mode=monochrome printer-info=MyNonExistingPrinter printer-is-accepting-jobs=true printer-is-shared=true printer-is-temporary=false printer-location printer-make-and-model='Local Raw Printer' printer-state=3 printer-state-change-time=1693914215 printer-state-reasons=none printer-type=4 printer-uri-supported=ipp://localhost/printers/MyNonExistingPrinter sides=two-sided-long-edge

Is there a way to get just one option? I tried with -o, to no avail. Writing a regular expression to isolate an option is not easy, because the strings can be quoted or have quoted characters inside, like 'Local Raw Printer'.

As a user, for me it is all CUPS. But I could do some bureaucratic work on behalf of the maintainers and file each issue in the right "bucket". That would require some bureaucratic effort from me. This is my first interaction with the CUPS project / organisation. Do you think it is worth pursuing the other "small cuts"?

Take for example my view that creating new printers as shared by default is a bad idea, especially after the recent security issue regarding printer sharing. Would lpadmin be a different "project" that I should file such a suggestion to? Or do you think it is fine like that anyway?

[debiantriage]

OK, so I gather you think that lpadmin's -E is user friendly enough, as it is documented on the man page, and you do not think that my suggestion about adding longer, unique option names, like "--accept-and-enable" is worth pursuing.

Explained here.

Take for example my view that creating new printers as shared by default is a bad idea, especially after the recent security issue regarding printer sharing. Would lpadmin be a different "project" that I should file such a suggestion to? Or do you think it is fine like that anyway?

Sharing printer queues on the network by default is, AFAIK, a distro matter, but it is not done on Debian or Ubuntu.

BTW, are you minded to make information sharing a two-way process? The output of

avahi-browse -rt _ipp._tcp

would be useful to add to my records.

[michaelrsweet]

... and you do not think that my suggestion about adding longer, unique option names, like "--accept-and-enable" is worth pursuing.

Given that lpadmin (as it currently exists) doesn't have too many years left, I don't think we want to expand options at this point. But for CUPS 3 we will definitely be cleaning things up.

Take for example my view that creating new printers as shared by default is a bad idea, especially after the recent security issue regarding printer sharing. Would lpadmin be a different "project" that I should file such a suggestion to? Or do you think it is fine like that anyway?

This is controlled by the DefaultShared option in the "cupsd.conf" file. For the lazy admin this can be changed with:

cupsctl DefaultShared=no

or via the web interface on the main admin page.

[rdiez]

Thanks for the information. For the record, I am running Ubuntu 22.04.3 (as stated at the beginning) on several computers, and the sharing is on by default. File /etc/cups/cupsd.conf has no DefaultShared option, so I guess that must be CUPS' default.

I do not print much, but CUPS has always been a pain. I am not alone, many people have talked and written about it for years. The interaction in this bug report has confirmed my expectations. But I am sure you are aware of all this, I cannot image otherwise.

While I really hope that CUPS 3 improves things, I wouldn't really count on it, especially in the short or even midterm. If this were my project, I would attempt to improve the situation now, with the current 2.x series.

I will give you a simple example: The main problem I am reporting here has been known under #760 for over 2 years, and still there is no warning or hint about it in the documentation, including section "Setting Up Printer Queues" in https://openprinting.github.io/cups/ . That means you are needlessly letting users fall again and again in the same "trap". In my personal notes, I have written a reminder to check that the installed printer has the right "Make and Model", to avoid that pitfall.

I have invested quite a few hours learning how to overcome all the little difficulties, and I hope you understand that I don't really want to spend any more time in this matter. I hope that you do manage to significantly improve CUPS quickly and prove my pessimistic prediction wrong.

[debiantriage]

@michaelrsweet I tend to think of cupsctl DefaultShared=yes (the default on Debian and Ubuntu) as giving individual printers the potential to be advertised on the network. The actual publicising (not the default on Debian and Ubuntu) is done by cupsctl --share-printers.

[debiantriage]

If this were my project, I would attempt to improve the situation now, with the current 2.x series.

Your success would surely partly depend on users not being averse or disinclined to respond to queries to clarify matters or improve the knowledge base.