| 2020-08-11 11:39:29 |
Till Kamppeter |
bug |
|
|
added bug |
| 2020-08-11 11:40:10 |
Till Kamppeter |
description |
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. |
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. |
|
| 2020-08-11 11:58:49 |
Till Kamppeter |
description |
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. |
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.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
It is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2020-08-11 12:17:57 |
Till Kamppeter |
description |
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.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
It is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
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.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
It is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
The package does not use debconf at all.
ipp-usb is maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
(only closed ones currently)
The author, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2020-08-11 12:18:32 |
Till Kamppeter |
bug task added |
|
golang-github-openprinting-goipp (Ubuntu) |
|
| 2020-08-11 12:18:42 |
Till Kamppeter |
golang-github-openprinting-goipp (Ubuntu): importance |
Undecided |
High |
|
| 2020-08-11 12:18:50 |
Till Kamppeter |
golang-github-openprinting-goipp (Ubuntu): milestone |
|
ubuntu-20.10 |
|
| 2020-08-11 13:27:29 |
Till Kamppeter |
description |
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.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
It is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
The package does not use debconf at all.
ipp-usb is maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
(only closed ones currently)
The author, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
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.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
The package does not use debconf at all.
ipp-usb is maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
(only closed ones currently)
The author, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2020-08-11 13:42:20 |
Till Kamppeter |
description |
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.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
The package does not use debconf at all.
ipp-usb is maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
(only closed ones currently)
The author, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
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.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2020-08-11 13:53:09 |
Till Kamppeter |
description |
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.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
[Maintenance]
[Background information] |
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.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
|
| 2020-08-11 13:55:12 |
Till Kamppeter |
bug |
|
|
added subscriber MIR approval team |
| 2020-08-11 14:31:18 |
Till Kamppeter |
description |
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.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
|
| 2020-08-11 15:47:17 |
Till Kamppeter |
description |
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
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 also here:
https://github.com/OpenPrinting/ippusbxd#before-you-begin-ippusbxd-or-ipp-usb
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
|
| 2020-08-11 15:51:45 |
Till Kamppeter |
description |
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 also here:
https://github.com/OpenPrinting/ippusbxd#before-you-begin-ippusbxd-or-ipp-usb
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
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 also here:
https://github.com/OpenPrinting/ippusbxd#before-you-begin-ippusbxd-or-ipp-usb
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
Both packages have debian/watch files and the content of the files seems to be correct.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
|
| 2020-08-14 12:16:14 |
Till Kamppeter |
description |
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 also here:
https://github.com/OpenPrinting/ippusbxd#before-you-begin-ippusbxd-or-ipp-usb
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
Both packages have debian/watch files and the content of the files seems to be correct.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
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 also here:
https://github.com/OpenPrinting/ippusbxd#before-you-begin-ippusbxd-or-ipp-usb
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
Due to this most other Linux distributions are also migrating to ipp-usb. Chrome OS was the last system sticking with ippusbxd but they have introduced their own replacement, ippusb_bridge (https://github.com/dgreid/platform2/tree/master/ippusb_bridge) now.
From the README.md of ippusb_bridge:
----------
The impetus for creating this was that ippusbxd has lost a lot of interest since the release of ipp-usb, a similar project written in Golang. Upstream provides only some oversight, and the code is pure C and has security bugs.
----------
With this the interest in ippusbxd has gone and ippusbxd can get considered deprecated.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
Both packages have debian/watch files and the content of the files seems to be correct.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
|
| 2020-08-17 14:07:15 |
Christian Ehrhardt |
bug task added |
|
golang-gopkg-ini.v1 (Ubuntu) |
|
| 2020-08-17 14:07:26 |
Christian Ehrhardt |
golang-gopkg-ini.v1 (Ubuntu): status |
New |
Incomplete |
|
| 2020-08-17 14:07:28 |
Christian Ehrhardt |
golang-github-openprinting-goipp (Ubuntu): status |
New |
Incomplete |
|
| 2020-08-17 14:07:42 |
Christian Ehrhardt |
ipp-usb (Ubuntu): assignee |
|
Ubuntu Security Team (ubuntu-security) |
|
| 2020-08-19 09:35:26 |
Till Kamppeter |
golang-github-openprinting-goipp (Ubuntu): status |
Incomplete |
New |
|
| 2020-08-19 09:35:32 |
Till Kamppeter |
golang-gopkg-ini.v1 (Ubuntu): status |
Incomplete |
Invalid |
|
| 2020-08-19 09:49:30 |
Till Kamppeter |
description |
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 also here:
https://github.com/OpenPrinting/ippusbxd#before-you-begin-ippusbxd-or-ipp-usb
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
Due to this most other Linux distributions are also migrating to ipp-usb. Chrome OS was the last system sticking with ippusbxd but they have introduced their own replacement, ippusb_bridge (https://github.com/dgreid/platform2/tree/master/ippusb_bridge) now.
From the README.md of ippusb_bridge:
----------
The impetus for creating this was that ippusbxd has lost a lot of interest since the release of ipp-usb, a similar project written in Golang. Upstream provides only some oversight, and the code is pure C and has security bugs.
----------
With this the interest in ippusbxd has gone and ippusbxd can get considered deprecated.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
Both packages have debian/watch files and the content of the files seems to be correct.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team.
[Background information]
See introduction above. |
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 also here:
https://github.com/OpenPrinting/ippusbxd#before-you-begin-ippusbxd-or-ipp-usb
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.
Here are the issues of ippusbxd:
https://github.com/OpenPrinting/ippusbxd/issues
Especially
https://github.com/OpenPrinting/ippusbxd/issues/15
shows that packets of canceled connections can get stuck in buffer and spilled out on next connection. Problems of ippusbxd's architecture and lack of useful C libraries to solve this is discussed here.
https://github.com/OpenPrinting/ippusbxd/issues/14
The flakiness of the web admin interface is caused by above problems.
Due to this most other Linux distributions are also migrating to ipp-usb. Chrome OS was the last system sticking with ippusbxd but they have introduced their own replacement, ippusb_bridge (https://github.com/dgreid/platform2/tree/master/ippusb_bridge) now.
From the README.md of ippusb_bridge:
----------
The impetus for creating this was that ippusbxd has lost a lot of interest since the release of ipp-usb, a similar project written in Golang. Upstream provides only some oversight, and the code is pure C and has security bugs.
----------
With this the interest in ippusbxd has gone and ippusbxd can get considered deprecated.
goipp
-----
goipp (Debian/Ubuntu package: golang-github-openprinting-goipp) is a simple IPP support library in Go needed by ipp-usb and created together with ipp-usb.
Original description from
https://github.com/OpenPrinting/goipp:
----------
The goipp library is fairly complete implementation of IPP core protocol in pure Go. Essentially, it is IPP messages parser/composer. Transport is not implemented here, because Go standard library has an excellent built-in HTTP client, and it doesn't make a lot of sense to wrap it here.
High-level requests, like "print a file" are also not implemented, only the low-level stuff.
----------
[Availability]
Both ipp-usb and goipp got initially packaged in Debian and synced into Universe:
https://launchpad.net/ubuntu/+source/ipp-usb/0.9.10-2
https://launchpad.net/ubuntu/+source/golang-github-openprinting-goipp/0.0~git20200517.da79ff1-3
They build on all currently supported architectures.
[Rationale]
See introduction above. Replaces ippusbxd.
[Security]
For both ipp-usb and goipp:
No CVE on http://cve.mitre.org/cve/search_cve_list.html
No mention on https://www.openwall.com/lists/oss-security/
Not listed on http://people.ubuntu.com/~ubuntu-security/cve/universe.html
No SUID/SGID
ipp-usb is a system daemon, running as root, triggered by plugging a supported device (USB printing device with IPP protocol, 7/1/4) via UDEV and systemd. In default configuration the daemon listens only on localhost, port 60000 (and following ports if more than one device is connected). So the device is not exposed to the network and communication with it stays on the local machine.
goipp is a Go library, the only binary package of it, golang-github-openprinting-goipp-dev contains only Go source code and documentation.
[Quality assurance]
To use ipp-usb one simply installs it and plugs the device(s) to USB. The devices get auto-detected by UDEV and the daemon automatically started. It immediately advertises the device via DNS-SD only on localhost where CUPS and SANE auto-discover it. So it immediately gets available for the user, for both printing and scanning.
goipp is a Go library only needed to build ipp-usb, it does not need to be installed by the end user.
Both packages do not use debconf at all.
Both ipp-usb and goipp are maintained upstream very well and actively developed.
Upstream site:
https://github.com/OpenPrinting/ipp-usb
https://github.com/OpenPrinting/gipp
Recent commits:
https://github.com/OpenPrinting/ipp-usb/commits/master
https://github.com/OpenPrinting/goipp/commits/master
Bugs:
https://github.com/OpenPrinting/ipp-usb/issues
https://github.com/OpenPrinting/goipp/issues
(only closed ones in ipp-usb currently, none at all in goipp)
The author of both, Alexander Pevzner, is very responsive, usually answers on the same day. He is actively working on driverless scanning (will mentor 2 students in LFMP on IPP Scan in Sep-Nov).
No known bugs in Debian and Ubuntu (Launchpad only lists this MIR for both).
Debian maintainer OdyX also very responsive.
No exotic hardware required, is for supporting the absolute standard hardware, most modern printers and multi-function devices, even very cheap ones. See introduction above.
Both packages have debian/watch files and the content of the files seems to be correct.
No dependencies on obsolete stuff.
[Dependencies]
ipp-usb build-depends on goipp, therefore this MIR is for both. They both were developed together and there is (yet) no other consumer than ipp-usb for goipp.
Otherwise build-depends on usual Go stack.
Run-time dependencies are only Avahi and libusb which are all in Main.
Avahi needs to support localhost, but Ubuntu's Avahi does this already for some years.
[Standards compliance]
Packages fulfill the standards concerning FHS and Go. Both ipp-usb and goipp packages declare Debian's "Standards-Version" as 4.5.0, Debian maintainer takes care of verifying and updating this. debian/ directories and debian/rules files are simple, fairly standard.
[Maintenance]
See [Quality assurance] above for upstream and Debian maintenance. I have subscribed myself to bugs in both packages and also the Ubuntu Printing Team. Also "Desktop Packages" (~desktop-packages) is subscribed to sane-airscan.
[Background information]
See introduction above. |
|
| 2020-08-19 13:09:52 |
Christian Ehrhardt |
golang-github-openprinting-goipp (Ubuntu): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2020-08-19 14:24:50 |
Christian Ehrhardt |
golang-github-openprinting-goipp (Ubuntu): assignee |
Christian Ehrhardt (paelzer) |
Ubuntu Security Team (ubuntu-security) |
|
| 2020-08-20 12:03:27 |
Didier Roche-Tolomelli |
golang-gopkg-ini.v1 (Ubuntu): assignee |
|
Didier Roche (didrocks) |
|
| 2020-08-26 11:15:46 |
Christian Ehrhardt |
golang-gopkg-ini.v1 (Ubuntu): assignee |
Didier Roche (didrocks) |
|
|
| 2020-09-27 21:28:18 |
Eric Jacolin |
bug |
|
|
added subscriber Eric Jacolin |
| 2020-10-08 02:39:08 |
Seth Arnold |
ipp-usb (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2020-10-08 02:40:07 |
Seth Arnold |
ipp-usb (Ubuntu): status |
New |
In Progress |
|
| 2020-10-08 02:47:51 |
Ikuya Awashiro |
bug |
|
|
added subscriber Ikuya Awashiro |
| 2020-10-08 06:48:20 |
Christian Ehrhardt |
ipp-usb (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2020-10-08 15:24:41 |
Steve Langasek |
ipp-usb (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2020-10-09 02:57:52 |
Seth Arnold |
golang-github-openprinting-goipp (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2020-10-09 02:57:56 |
Seth Arnold |
golang-github-openprinting-goipp (Ubuntu): status |
New |
In Progress |
|
| 2020-10-09 05:27:29 |
Christian Ehrhardt |
golang-github-openprinting-goipp (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2020-10-14 14:31:18 |
Didier Roche-Tolomelli |
golang-github-openprinting-goipp (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2020-11-27 20:04:34 |
Martin Kingsley |
bug |
|
|
added subscriber Martin Kingsley |
