Iirc the linux tool for this was lpr ...ie; lpr -l <postscript file> [destination printer] ....I believe it did ip_addr:port for dest. as well as local device.

Printing is a bit different in the world of Unix. Most printer systems expect the device at the end of the print queue to accept plain text or postscript. If your device doesnt support that input natively, and needs a driver, sending anything to the printer is generally going to cause it to go crazy.

It's why in most scenarios on UNIX like systems it is usually easier to use a network device that talks lpd and accepts either PCL or vanilla PostScript.

Yes, essentially you have every option available, as long as you have a print driver in linux, or even better, the printer supports postscript natively. There is also a new web printing standard (forgot the name) which also allows for generic drivers.

lpr is the command line tool to send print jobs. Cups is the print system that application can integrate with directly too. Cups supports IPP, the internet print protocol for sending jobs over TCP/IP. Finally, hplip is the HP printer driver, if you are interested in those printers.

How about using a laptop or a MiniPC with at least a currently supported version of Windows and possibly Linux installed for printer testing purposes.

If there is a doubt about user hardware issue, booting a PC from a USB flash drive with a Windows To Go installation on it could be an option [1].

[1]
https://www.intowindows.com/rufus-to-create-w … o-go-usb-drive/

Couldn't you use netcat to dump a raw file to a printer port?

Thanks for all the answers.

As keenerb said, netcat was the right answer. I was able to send a test file using nc <ip> 9100 < test.pdf. I've used port 9100 because I think port 515 requires some kind of "talk" between the host and the printer before printing (opposed to 9100 that seem to print everything is thrown at).

Also keep in mind that my test printer supports PCL, PS and PDF (as well as it's own PDL), so sending that page had no issues. I remember having some issues sendind PCL files and plain text, so I'll test each PDL.

Still I don't know if I can do the same trick using USB (like that usblist2.exe tool I mentioned).

The goal is to "print" tests bypassing almost everything on the computer (spooler, driver and queues) to check if the problem is on the printer or the software.