Comment 0 for bug 1891157

IPP-over-USB

ipp-usb is the second implementation of the IPP-over-USB standard. This allows the PWG's Internet Printing Protocol (IPP) which is currently the most common communication protocol for network printers also to be used via USB, simply by a network printer being emulated on localhost. Advantages are:

- IPP is a high-level bi-directional packet-based protocol for printing, scanning, and fax
- Full device capabilities can be polled from the device, together with using standardized
  printing and scanning data format driverless printing and scanning is possible
- Status, like loaded paper, toner levels, ... can get polled
- Printing and scanning can be performed simultaneously and independently
- The administration web interface can get accessed

ipp-usb detects supported devices automatically and advertises their full functionality via DNS-SD on localhost, CUPS and the appropriate SANE backends discover the device automatically then and it is immediately available, no drivers needed, it just works.

This makes thousands of printers, scanners, and multi-function devices work on USB, USB-only devices, like the scanner Canon Lide 400 get working for the first time.

Why ipp-usb? There is ippusbxd already.

ippusbxd was the first implementation of IPP-over-USB, with the very same intentions, but it has problems which were not easily to be solved in C and so after a short discussion with me the author of the driverless scanning SANE backend sane-airscan (https://github.com/alexpevzner/sane-airscan) created a first draft of ipp-usb in Go within a few hours, which solved these problems. The project has matured with the time and seems to work perfectly.

See the original README for the rationale of ipp-usb:

https://github.com/OpenPrinting/ipp-usb

----------
Unfortunately, the naive implementation, which simply relays a TCP connection to USB, does not work. It happens because closing the TCP connection on the client side has a useful side effect of discarding all data sent to this connection from the server side, but it does not happen with USB connections. In the case of USB, all data not received by the client will remain in the USB buffers, and the next time the client connects to the device, it will receive unexpected data, left from the previous abnormally completed request.

Actually, it is an obvious flaw in the IPP-over-USB standard, but we have to live with it.

So the implementation, once the HTTP request is sent, must read the entire HTTP response, which means that the implementation must understand the HTTP protocol, and effectively implement a HTTP reverse proxy, backed by the IPP-over-USB connection to the device.

And this is what the ipp-usb program actually does.
----------

Many users reported this to work perfectly and I am using it since its creation in January 2020 on a daily basis without problems.

Availability:

ipp-usb got initially packaged in Debian and synced into Universe:

https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2

It builds on all currently supported architectures.