[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: error when printing to Samsung C410 series colour laser printer



On 2019-06-15 9:50 a.m., Brian wrote:
On Fri 14 Jun 2019 at 23:32:50 -0400, Gary Dale wrote:

I thought I'd figured it out - that the network printer shouldn't be
installed locally, because it's automagically discovered. I tested this by
As we have seen, it is the way you installed the queue on the client
(with a Samsung driver) that is the problem; a local driverless or
everywhere queue is no problem. But, as you say, why bother to do even
that if cups-browsed can do it for you. It's a user's choice.
Except that didn't work either.
deleting the local install of the network printer and, while it disappears
from the CUPS web interface, it still shows up in the list of printers when
I try to print a PDF from Okular. This seems somewhat reasonable...
Having this deleted queue show in Okular's dialog doesn't seem at all
reasonable to me.

It's not the deleted queue. This one showed up in addition to the queue I deleted. Once I deleted the local queue, this one remains. It's survived reboots so the only reasonable explanation is that Buster is detecting it as a network printer. It isn't the ghost of a deleted CUPS queue.

To verify this, I disconnected the network cable from the printer then rebooted my workstation. The printer vanished. When I reconnected the network cable, the printer showed up again. This doesn't seem to be a CUPS thing, since it doesn't show in the list of printers in the CUPS web interface but does show up in Okular's print dialogue. It also shows up in non-KDE apps like LibreOffice Calc.

Unfortunately, printing to it does nothing. The output disappears into the
ether(net).
The queue has been deleted. The job has nowhere to go!
Which would make sense if the queue actually had been deleted. However it appears to be auto-detected.
To be clear, the printer network connection is there. CUPs lists it multiple
times with its network address when I use the web interface to find new
printers. And I can ping its IP address.

I then fired up a Stretch VM and tried the same things. Under Stretch, the
printer doesn't show up except as the USB-shared printer from the server.
However, after installing the Samsung driver, it did show up when I tried to
find new printers from the CUPS web interface. I installed it using the
SEC30CDA71CB48A "address" and the normal C410 driver and was able to print
successfully.

CUPS is apparently working differently in Buster than in Stretch in its
handling of network-attached printers.
A little differently when the driverless aspect is factored in. But,
basically, the framework is still the same. CUPS/cups-filters has
changed because printers have changed.

No. The procedure that worked with Stretch - adding the printer with the normal C410 driver - doesn't work with Buster. In fact I can't print to the Samsung_C410_Series_SEC30CDA71CB48A printer from Buster with either the normal driver or the "driverless" driver.



Anyway, here's my current diagnostic output:

$ lpstat -l -e
Samsung_C410_Series_SEC30CDA71CB48A_ network none
ipp://Samsung%20C410%20Series%20(SEC30CDA71CB48A)._ipp._tcp.local/
I think that is the printer. We need avahi-browse to tell us more.
?

Samsung_C410_Series_TheLibrarian network none
ipps://Samsung%20C410%20Series%20%40%20TheLibrarian._ipps._tcp.local/cups
That's the queue set up automatically by cups-browsed using its
driverless utility.
Agreed. It works.

$ lpoptions -p Samsung_C410_Series_SEC30CDA71CB48A_
device-uri=ipp://Samsung%20C410%20Series%20(SEC30CDA71CB48A)._ipp._tcp.local/
printer-info='Samsung C410 Series (SEC30CDA71CB48A)' printer-location
printer-make-and-model='Samsung C410 Series' printer-type=16810060
Ok.
This is the printer that my desktop environment sees that CUPS doesn't autodetect. It is NOT a deleted queue. Note also the trailing "_" on the queue name. When I add it through CUPS, there isn't one by default. Something has tried to not step on CUPS names here.

$ lpoptions -p Samsung_C410_Series_TheLibrarian
device-uri=ipps://Samsung%20C410%20Series%20%40%20TheLibrarian._ipps._tcp.local/cups
printer-info='Samsung C410 Series @ TheLibrarian' printer-location='family
room' printer-make-and-model=ColorLaserPrinter printer-type=16781390
Ok.
# cupsfilter -p /etc/cups/ppd/Samsung_C410_Series_TheLibrarian_ppd -m
printer/foo -e --list-filters /etc/nsswitch.conf
cupsfilter: Unable to open PPD file: Unable to open PPD file on line 0.
Segmentation fault

# ls -l /etc/cups/ppd/
total 476
-rw-r----- 1 root lp 192111 Jun 14 21:01
EPSON_Stylus_Photo_R300_TheLibrarian.ppd
-rw-r----- 1 root lp  78398 Dec  9  2018 EPSON_XP-820_Series.ppd
-rw-r----- 1 root lp  78390 Nov  5  2018 EPSON_XP-820_Series.ppd.O
-rw-r----- 1 root lp  43299 Jun 14 21:01
HP_Color_LaserJet_CP1215_TheLibrarian.ppd
-rw-r----- 1 root lp  21016 Jun 14 21:01 PDF_TheLibrarian.ppd
-rw-r----- 1 root lp  32048 Jun 14 21:01
Samsung_C410_Series_TheLibrarian.ppd
-rw-r----- 1 root lp  27498 Jun 14 21:07 Samsung_ML_1210_TheLibrarian.ppd

Changing the _ppd to .ppd removes the error messages. Instead I get no
output.
There is no output because no processing through filters takes place on
the client now you are not using the Samsung driver.

Have a go at this:

1. Check that you can print the file /etc/nsswitch.conf from the server:
      lp -d Samsung_C410_Series /etc/nsswitch.conf
I do that all the time. Interestingly, this used to be the network interface queue from my Stretch server. Now it's the USB interface. It still works.

2. Stop cups-browsed on the client:
      systemctl stop cups-browsed

3. Check destinations:
      lpstat -l -e
Samsung_C410_Series_SEC30CDA71CB48A_ network none ipp://Samsung%20C410%20Series%20(SEC30CDA71CB48A)._ipp._tcp.local/ Samsung_C410_Series_TheLibrarian network none ipps://Samsung%20C410%20Series%20%40%20TheLibrarian._ipps._tcp.local/cups


4. Print the same file as before:
      lp -d Samsung_C410_Series_TheLibrarian /etc/nsswitch.conf
Works. As I corrected earlier, the problem is printing to the network connection from Stretch. Printing to the USB connection works. My original problem was I mixed up which server queue was the USB one. Now that I've simplified the connections, I only have the USB connection shared on the server.


Reply to: