Puppy Linux Discussion Forum

@tosim: If you read the entire thread, you will see that these Ubuntu users are installing a 32bit compatibility environment.

Are you reporting that this technique also works in Puppy?

vtpup wrote: ↑Sat Sep 19, 2020 6:00 pmAll I know is, it is typical of my experiences with versions of CUPS over the years. I cannot think of another piece of software I've run on Linux that is to me so likely to give odd results, setup issues, and is so recalcitrant toward my solving those problems

Maybe that's because Puppy has not implemented CUPS as it would be in a mainstream Linux.

I am currently using CUPS 2.2.10 in the Starter Kit and it is rock-solid.

@vtpup:-

Just as an aside - bearing in mind your own description of CUPS 'oddities' over the years! - I too have had to follow some slightly unorthodox procedures at times.

I'm a long-standing fan of Epsons; never bothered trying anything else, 'cos they're so amazingly reliable. A bit on the agricultural side perhaps - to some - but they just keep chugging away, year after year... Most only get "binned" when the waste ink pad gets full, and after a preset number of runs a message is triggered that declares you must take it to an Epson service centre, to have X, Y and Z done to it.....it basically quits working until you do. At this point, it's cheaper to buy a new model....

Anyway; Epson provide .deb packages - once you've got past their customer service people all declaring loudly,"We don't DO Linux drivers..!!" Which is odd, given that

a) Their Linux stuff was all developed for them by their Japanese 'sister' company, Avasys (who had a bang-on reputation for their code before selling-out to Epson), and
b) They were one of the original founding members of the Linux Foundation..!

The .debs have always installed flawlessly. However; in 32-bit Pups, I've always had to install the printer firstly with a generic Epson 'Escp-r' .pet package Bill produced, followed by 'modifying' to the correct specific driver after that.

For the 64-bitzers, I've had far better luck using the 'Eppi' command-line installer package Bill put together. If I click-installed the .deb driver packages directly, CUPS could never, EVER "see" the printer.....


Mike.

tosim wrote: ↑Sat Sep 19, 2020 6:34 pm            Install Driver for Dell c1760 Color Laser
http://askubuntu.com/questions/513943/h ... ith-ubuntu
If you have a 64-bit system, copy and paste this into  Terminal
          sudo apt-get install libcupsimage2:i386
     If you have a 32-bit system, ignore that terminal command and proceed.
 Download the Ubuntu .deb drivers from Xerox for their Phaser 6000 model. It comes packaged in a .zip file:
https://www.support.xerox.com/support/p ... ived=false
(The Dell C1760nw is a "repackaged" version of this model, which means that the core printing device works the same as a Xerox Phaser 6000 because it came from the same factory, but it is assembled and sold to retailers by Dell instead of Xerox.)
 You will need to save this .zip file, and extract its contents with a right-click if you are looking at it in the File Manager. A folder will be extracted, and therein will be a .deb package file. You should double-click this to open it.
 You may encounter a window saying that the package is of "bad quality". You can safely ignore this; it's coming up because of an incorrectly entered variable that declares the creator of the file.
 Then, install the printer. If you are prompted to choose a printer manufacturer and model, enter it as a Xerox 6000b. It works!
 Note that all of these steps are still required to use the printer over the network.
               ***Above worked great for me.***
install(all three) libcups2 in Synaptik
https://forums.linuxmint.com/viewtopic.php?t=152946
http://en.community.dell.com/support-fo ... t/19525015
http://codefucius.blogspot.com/2014/03/ ... er-up.html
http://linuxibos.blogspot.com/2012/05/s ... linux.html

Tosim, I realize you are only trying to help, but you don't seem to have read my second post in this thread, where all of this was already tried. This attempt at a solution assumes we don't have a working driver (we do). and we are trying to get it working on a 64 bit system (we aren't, for present test purposes.

To clarify the issue, taking rcrsn51's suggestion, we tested on a 32 bit system: (Bionic32) using that driver, and tried printing via USB. Everything worked.

Then using the exact same setup, merely switched from USB to a netaddress of http://192.168.1.1:631/printers/Dell and got the "Filter Failed" message. The netaddress above is absolutely correct, as verified by the print server manual, and also verified in an existing 32 bit puppy system, Tahrpup32. Where printing has been working with that driver and that address in CUPS 1.4.8 for years.

rcrsn51 (and my) conclusion is that the newer CUPS 2.2.7 system in BionicPup32 is broken in this regard, either in its code (a program or dependency bug), or its setup and implementation in Bionicpup32 (an OS bug). Something is clearly wrong.

CUPs should print, given a working driver, proven via USB, and a correct network address.

It doesn't

@vtpup: Did you ever try the driver on Bionic64 with the compatibility pack on USB?

rcrsn51 do you mean the 32 bit compatibility sfs? or is there something else? I will if that's what you mean....

Also, I really think it's in networking, though, going back to Bionic32.

Do you think it could be a ipv6 vs ipv4 problem? Something simple like that?

E [17/Sep/2020:08:48:16 -0400] Unable to open listen socket for address [v1.::1]:631 - Address family not supported by protocol.

Connect the printer by USB.
Run BIonic64
Load the Bionic 32bit compatibility pack (I got it from Quickpet).
Install and test the printer.

I did a simulated test of this setup and the driver worked.

I have not read all posts, so this may have been done.

Bionicpup64 8.0 has some updates and bug fixes.
Run Quickpet->Info->Bionicpup updates
Save and Reboot so changes are now being used.

@vtpup: If you can get the driver working in Bionic64, then here is your best long-term solution.

Get a little Ethernet-USB print server box. Plug it into a free Ethernet port. Connect the printer by USB. The box should provide the more friendly socket protocol instead of the troublesome ipp.

If CUPS cannot auto-detect the server, scan your LAN with PeasyPort for Port 9100. Install the printer manually in CUPS.

@vtpup: I own an Ethernet-USB print server. I connected it to my LAN and plugged in an Epson printer.

I ran Bionic64 and installed the Epson driver.

I ran PeasyPort and located the server.

I ran CUPS and manually installed the printer using ipp. The server queue is called LP1, so the URI was This worked correctly. So Bionic64 is capable of handling the ipp protocol.

rcrn51, my working BP64 system (with 32 bit compat sfs already installed) works fine with the printer and driver via USB.

As with BP32, throws "Filter Failed" message when trying ipp.

I'm not keen to buy a print server, just to overcome CUPS 2.2.7/Bionic issues serving on a network, and there's no guarantee socket 9100 will work any better, but if I do not figure out how to get CUPS to work, I guess I'll have to try that.

Looking on ebay, I see lots of reasonable $ USB-ethernet print servers, but they don't specify whether they use 9100 or ipp. Can you suggest a specific one that does?

I have an old IOGear print server.

In /etc/cups/cupsd.conf , have you turned on "LogLevel debug"?

I would really like to know the specifics of the "filter failed" error.

Maybe you could post your FULL /var/log/cups/error_log. Zip it first.

Bionic64 has ipv6 turned OFF. Maybe CUPS needs it turned ON in order to see the print server on your router. Test the printer.

rcrn51, thanks. The ipv6 module addition didn't change anything, unfortunately.

I can also give you a full zip of error log if you want, but here is the important section (the render operation and failure) already in this thread. Note these are with a clean BP64 + 32bit compat-sfs. The first shows with debug off, and the second shows with it on.
viewtopic.php?f=4&t=798&start=11

If you need more, apologies, and I'll repeat and zip it as you asked.

I'd like to see the whole thing. That error refers to Ghostscript, but we know that it doesn't occur over USB.

Sorry, I should have done that in the first place. I've just stopped CUPS, then cleared out the file /var/log/cups/error_log, then restarted CUPS and tried to print the CUPS test page. Then zipped error_log. I'm attaching that here.

I'm working from a BP64 with 32bit compat sfs, and the ipv6 module loaded. Let me know if you want that unloaded, or anything else.

There are two show-stopper errors at lines 105 and 108, but they appear to have different causes. And I don't know why they only affect the ipp version.

I'm guessing that 108 would NOT be present with Bionic32.

So I don't know whether getting a separate print server box will fix this.

Thanks rcrsn51, while you were looking at that, I did another clean run of BP64 + updates + 32bit compat sfs, no ipv6 module and did a USB print with a clean var log. I don't know if this will shed any light, but just wanted to compare.

How much RAM does the host computer have?

4 gigs plus 32 gig swap.

Maybe there was a problem with that first error log not being on a perfectly clean OS.

I've just now used exactly the same brand new system as I just did for the last message USB listing. With a clean var/log and am attaching it here.

I don't see exactly those same show stoppers, but it is much more verbose, so maybe I'm missing something. These two logs should be one-for-one comparable in exactly the same totally clean system, never rebooted.

One other thing noticed:

The test page that actually gets printed via USB in BP64 is not the usual older (and BP32) CUPS printer test banner page, but an Ubuntu printer test banner page with the Ubuntu symbol.

I don't know how large that is, or if it is a problem. Yet, it can't be, if it is able to print the same page via USB. I can't imagine printing over the network means the file would be larger than printing via USB.

There are references to a "dirty" file in the error log. No idea what that means either.

In the final log, you can see the filter fail at line 696. At line 716, there is an error involving ipp. From 633 to 690, there is a bunch of stuff about ipp. It looks like CUPS is trying to get IPP information from the server and fails.

In my Bionic64 setup with the IOGEAR print server, CUPS succeeds in getting this IPP info.

So a separate print server box running socket (or maybe ipp) might work.

It would be interesting to see what the log looks like in Tahrpup where ipp works.

Regarding the socket network printing protocol: unlike IPP, CUPS does not need to acquire information from a socket server before sending a print job. It just writes data to Port 9100 and hopes for the best.

Did you ever check to see if Port 515 (LPT printing) is open on your router?

Any updates on this situation?

No reply from vtpup in a week. I hope he's OK.

Maybe he's gone into hiding to escape the craziness in his country.

Sorry to leave this hanging like that rcrsn51. I really appreciate all the effort you've made investigating. Sorry, I just had to take care of other life requirements after spending 3 days on the printer filter problem. I will check the port on the router today. Feel free to abandon this problem if it's a rabbit hole for you as well. I can stay with Tahr if need be. And yes there is craziness more broadly here, but that's another rabbit hole.

Not a problem. But I wouldn't mind seeing the CUPS error log from Tahrpup for the sake of comparison.

Bill

Bill, thanks, kindly. I erased the error log contents in my working Tahrpup32 installation to start with a clean slate. Switched its CUPS 1.4.8 to Debug mode, Then successfully printed a CUPS (Printer> Maintenance) test page. Zipped the error.log (attached)

Thanks. You can see in the Tahrpup error log how CUPS queried the IPP server on the router and got the info it wanted.

For some reason, the CUPS 2.x in Bionic fails to do this. I suspect it is because CUPS is expanding the use of the ipp: protocol to handle things like AirPrint. So it has lost compatibility with your particular IPP server.

I expect that switching to a separate Ethernet-USB print server box with the socket: protocol would bypass the problem.