search

OpenPrinting / ipp-usb

ipp-usb -- HTTP reverse proxy, backed by IPP-over-USB connection to device
BSD 2-Clause "Simplified" License
135 stars 14 forks source link

Canon TR4500 series rejects any request... #29

Closed booti386 closed 3 years ago

booti386 commented 3 years ago

... that has not the Host header set to either localhost:[port] or 127.0.0.1:[port]

Examples of success:

10-05-2021 17:14:47: > HTTP[005]: POST http://127.0.0.1:60001/ipp/print
10-05-2021 17:14:47: > HTTP[005]: request body: got 170 bytes; EOF
10-05-2021 17:14:47: > HTTP[005]: body is small (170 bytes), prefetched before sending
10-05-2021 17:14:47: > HTTP[005]: HTTP request header:
10-05-2021 17:14:47: >   POST /ipp/print HTTP/1.1
10-05-2021 17:14:47: >   Host: 127.0.0.1:60001
10-05-2021 17:14:47: >   User-Agent: CUPS/2.3.3 (Linux 5.8.0-52-generic; x86_64) IPP/2.0
10-05-2021 17:14:47: >   Content-Length: 170
10-05-2021 17:14:47: >   Accept-Encoding: deflate, gzip, identity
10-05-2021 17:14:47: >   Content-Type: application/ipp
10-05-2021 17:14:47: >   Date: Mon, 10 May 2021 15:14:47 GMT
10-05-2021 17:14:47: >
10-05-2021 17:14:47:   USB[1]: connection allocated, 1 in use: --- a--
10-05-2021 17:14:47:   HTTP[005]: connection 1 allocated
10-05-2021 17:14:47: > USB[1]: write: wanted 417 sent 417 total 417
10-05-2021 17:14:47: < USB[1]: read: wanted 4096 got 17 total 17
10-05-2021 17:14:47: < USB[1]: read: wanted 4096 got 19 total 36
10-05-2021 17:14:47: < USB[1]: read: wanted 4096 got 28 total 64
10-05-2021 17:14:47: < USB[1]: read: wanted 4096 got 81 total 145
10-05-2021 17:14:47: < HTTP[005]: POST http://127.0.0.1:60001/ipp/print - 200 OK
10-05-2021 17:14:47: < HTTP[005]: HTTP response header:
10-05-2021 17:14:47: <   HTTP/1.1 200 OK
10-05-2021 17:14:47: <   Connection: Keep-Alive
10-05-2021 17:14:47: <   Content-Type: application/ipp
10-05-2021 17:14:47: <   Keep-Alive: timeout=30
10-05-2021 17:14:47: <   Mime-Version: 1.0
10-05-2021 17:14:47: <   Transfer-Encoding: chunked
10-05-2021 17:14:47: <
10-05-2021 17:14:47: < USB[1]: read: wanted 4096 got 5 total 150
10-05-2021 17:17:31: > HTTP[003]: POST http://localhost:60001/ipp/print
10-05-2021 17:17:31: > HTTP[003]: request body: got 170 bytes; EOF
10-05-2021 17:17:31: > HTTP[003]: body is small (170 bytes), prefetched before sending
10-05-2021 17:17:31: > HTTP[003]: HTTP request header:
10-05-2021 17:17:31: >   POST /ipp/print HTTP/1.1
10-05-2021 17:17:31: >   Host: localhost:60001
10-05-2021 17:17:31: >   User-Agent: CUPS/2.3.3 (Linux 5.8.0-52-generic; x86_64) IPP/2.0
10-05-2021 17:17:31: >   Content-Length: 170
10-05-2021 17:17:31: >   Accept-Encoding: deflate, gzip, identity
10-05-2021 17:17:31: >   Content-Type: application/ipp
10-05-2021 17:17:31: >   Date: Mon, 10 May 2021 15:17:31 GMT
10-05-2021 17:17:31: >
10-05-2021 17:17:31:   USB[1]: connection allocated, 1 in use: --- a--
10-05-2021 17:17:31:   HTTP[003]: connection 1 allocated
10-05-2021 17:17:31: > USB[1]: write: wanted 417 sent 417 total 417
10-05-2021 17:17:31: < USB[1]: read: wanted 4096 got 17 total 17
10-05-2021 17:17:31: < USB[1]: read: wanted 4096 got 19 total 36
10-05-2021 17:17:31: < USB[1]: read: wanted 4096 got 28 total 64
10-05-2021 17:17:31: < USB[1]: read: wanted 4096 got 81 total 145
10-05-2021 17:17:31: < HTTP[003]: POST http://localhost:60001/ipp/print - 200 OK
10-05-2021 17:17:31: < HTTP[003]: HTTP response header:
10-05-2021 17:17:31: <   HTTP/1.1 200 OK
10-05-2021 17:17:31: <   Connection: Keep-Alive
10-05-2021 17:17:31: <   Content-Type: application/ipp
10-05-2021 17:17:31: <   Keep-Alive: timeout=30
10-05-2021 17:17:31: <   Mime-Version: 1.0
10-05-2021 17:17:31: <   Transfer-Encoding: chunked
10-05-2021 17:17:31: <
10-05-2021 17:17:31: < USB[1]: read: wanted 4096 got 5 total 150
[...]

Examples of failure:

10-05-2021 17:18:41: > HTTP[004]: POST http://127.0.0.2:60001/ipp/print
10-05-2021 17:18:41: > HTTP[004]: request body: got 170 bytes; EOF
10-05-2021 17:18:41: > HTTP[004]: body is small (170 bytes), prefetched before sending
10-05-2021 17:18:41: > HTTP[004]: HTTP request header:
10-05-2021 17:18:41: >   POST /ipp/print HTTP/1.1
10-05-2021 17:18:41: >   Host: 127.0.0.2:60001
10-05-2021 17:18:41: >   User-Agent: CUPS/2.3.3 (Linux 5.8.0-52-generic; x86_64) IPP/2.0
10-05-2021 17:18:41: >   Content-Length: 170
10-05-2021 17:18:41: >   Accept-Encoding: deflate, gzip, identity
10-05-2021 17:18:41: >   Content-Type: application/ipp
10-05-2021 17:18:41: >   Date: Mon, 10 May 2021 15:18:41 GMT
10-05-2021 17:18:41: >
10-05-2021 17:18:41:   USB[0]: connection allocated, 1 in use: a-- ---
10-05-2021 17:18:41:   HTTP[004]: connection 0 allocated
10-05-2021 17:18:41: > USB[0]: write: wanted 417 sent 417 total 417
10-05-2021 17:18:41: < USB[0]: read: wanted 4096 got 26 total 26
10-05-2021 17:18:41: < USB[0]: read: wanted 4096 got 19 total 45
10-05-2021 17:18:41: < USB[0]: read: wanted 4096 got 28 total 73
10-05-2021 17:18:41: < USB[0]: read: wanted 4096 got 19 total 92
10-05-2021 17:18:41: < USB[0]: read: wanted 4096 got 2 total 94
10-05-2021 17:18:41: < HTTP[004]: POST http://127.0.0.2:60001/ipp/print - 400 Bad Request
10-05-2021 17:18:41: < HTTP[004]: HTTP response header:
10-05-2021 17:18:41: <   HTTP/1.1 400 Bad Request
10-05-2021 17:18:41: <   Mime-Version: 1.0
10-05-2021 17:18:41: <   Transfer-Encoding: chunked
10-05-2021 17:18:41: <
10-05-2021 17:18:41: < USB[0]: read: wanted 4096 got 5 total 99
10-05-2021 17:18:41: < HTTP[004]: response body: got 0 bytes; EOF
10-05-2021 17:19:24: > HTTP[005]: POST http://localhost.localdomain:60001/ipp/print
10-05-2021 17:19:24: > HTTP[005]: request body: got 182 bytes; EOF
10-05-2021 17:19:24: > HTTP[005]: body is small (182 bytes), prefetched before sending
10-05-2021 17:19:24: > HTTP[005]: HTTP request header:
10-05-2021 17:19:24: >   POST /ipp/print HTTP/1.1
10-05-2021 17:19:24: >   Host: localhost.localdomain:60001
10-05-2021 17:19:24: >   User-Agent: CUPS/2.3.3 (Linux 5.8.0-52-generic; x86_64) IPP/2.0
10-05-2021 17:19:24: >   Content-Length: 182
10-05-2021 17:19:24: >   Accept-Encoding: deflate, gzip, identity
10-05-2021 17:19:24: >   Content-Type: application/ipp
10-05-2021 17:19:24: >   Date: Mon, 10 May 2021 15:19:24 GMT
10-05-2021 17:19:24: >
10-05-2021 17:19:24:   USB[1]: connection allocated, 1 in use: --- a--
10-05-2021 17:19:24:   HTTP[005]: connection 1 allocated
10-05-2021 17:19:24: > USB[1]: write: wanted 441 sent 441 total 441
10-05-2021 17:19:24: < USB[1]: read: wanted 4096 got 26 total 26
10-05-2021 17:19:24: < USB[1]: read: wanted 4096 got 19 total 45
10-05-2021 17:19:24: < USB[1]: read: wanted 4096 got 28 total 73
10-05-2021 17:19:24: < USB[1]: read: wanted 4096 got 19 total 92
10-05-2021 17:19:24: < USB[1]: read: wanted 4096 got 2 total 94
10-05-2021 17:19:24: < HTTP[005]: POST http://localhost.localdomain:60001/ipp/print - 400 Bad Request
10-05-2021 17:19:24: < HTTP[005]: HTTP response header:
10-05-2021 17:19:24: <   HTTP/1.1 400 Bad Request
10-05-2021 17:19:24: <   Mime-Version: 1.0
10-05-2021 17:19:24: <   Transfer-Encoding: chunked
10-05-2021 17:19:24: <
10-05-2021 17:19:24: < USB[1]: read: wanted 4096 got 5 total 99
10-05-2021 17:19:24: < HTTP[005]: response body: got 0 bytes; EOF

For information:

$ host localhost
localhost has address 127.0.0.1
$ host localhost.localdomain
localhost.localdomain has address 127.0.0.1
$
alexpevzner commented 3 years ago

Cc: @tillkamppeter, @michaelrsweet

Unfortunately, this problem cannot be fixed here. Under some circumstances Avahi announces localhost devices under name different from localhost. ipp-usb cannot control it.

Most of the printers still work in this situation, but few models are more restrictive.

Ideally, it should be fixed at the Avahi side. But experience shows that getting something fixed at Avahi is nearly hopeless. Alternatively, workaround could be added to CUPS to always set Host: localhost:port, if printer's address is 127.0.0.1 or ::1, regardless of printer's host name, obtained from Avahi

booti386 commented 3 years ago

I tried to fix it by creating a quirk for ipp-usb (http-host = localhost:6000), but it didn't work and the header value remained the same in the logs. I also tried with http-text = bla, to make sure I didn't messed up, and this time the test header properly showed up in the logs.

I suspect it's because the http backend overwrites automagically the host field by default, but couldn't it be useful to add the ability to override it anyway using quirks?

tillkamppeter commented 3 years ago

Ideally, it should be fixed at the Avahi side. But experience shows that getting something fixed at Avahi is nearly hopeless. Alternatively, workaround could be added to CUPS to always set Host: localhost:port, if printer's address is 127.0.0.1 or ::1, regardless of printer's host name, obtained from Avahi

@alexpevzner please report an issue on CUPS.

alexpevzner commented 3 years ago

@booti386,

this issue cannot be fixed as in #30. The problem is that responses to some IPP requests may contains URLs, and because in the IPP over USB case device has no idea regardless its hostname, it simply mirrors hostname from the Host: header of request.

If we override the Host: reader in request, URLs response will point to different domain that request was sent to. It may cause unobvious problems.

booti386 commented 3 years ago

I see, quite a dumb problem I'm not sure it should prevent this patch to be merged tho (removed the reference to this issue), as any header should be overridable anyway

alexpevzner commented 3 years ago

ipp-usb allocates TCP ports dynamically, so in any case, Host: cannot be overriden with a constant string.

booti386 commented 3 years ago

I would like to understand something, tho. The printer answers with HTTP 400 Bad Request to each request that does not have 127.0.0.1: or localhost: as Host Then how sharing this printer over the LAN is supposed to work, unless ipp-usb patches request (=> localhost) and answers (=> back to origin) on the fly?

alexpevzner commented 3 years ago

Then how sharing this printer over the LAN is supposed to work

For this particular printer, only via CUPS.

My current position: ipp-usb should not attempt to modify or somehow "improve" the content of HTTP "messages" passed through it. All modifications of HTTP requests it performs doesn't change semantics of these requests and affects only transport-level handling of them.

My reasons are following:

  1. This is a fair amount of work, taking in account there are 3 types of data, travelling through the ipp-usb: IPP printing, eSCL scanning, web console
  2. For the IPP data, though normally URLs are encoded as a special king of strings, there is no guarantee that some buggy firmware will not return URL as a generic string
  3. For eSCL data, in theory, it can be implemented; the protocol is really simple
  4. For web console, it cannot be implemented in a reliable way: there are too many places in the HTML traffic, where URL can be hidden (for example, it may be computed by JS script)
booti386 commented 3 years ago

Thank you for your detailed answer, I understand the whole picture better. I'm closing the issue as it cannot be fixed in ipp-usb.