ipp-usb: Canon 3120L fails to print job by using driverless

Hi Tess,

the promised technical details first. Sometimes USB read request finishes quickly and returns 0 bytes, It is not necessarily an error and in most cases after several attempts finally device returns some data bytes. But often when device is about to stuck in response, there are many “zero-sized read” events, so there truncated response and zero-sized read are somehow associated. Some of devices never return zero bytes, other do it often.

I don’t quite understand, what zero-size read should mean. If device has currently no data to return and want to ask reader to wait, USB protocol provides special mechanisms for doing so, and read request should simply block until some data is available. But it happens, and without ability to look to the USB conversation from device’s point of view, I can only guess what actually goes on.

One hypothesis was that device and host lose synchronization at the signalling level, so I tried to send “unhalt” command to device. As we know, it didn’t help, and sometimes breaks things. I don’t know why it breaks things on ARM but doesn’t break on MIPS. May be it is because ARM and MIPS machines use different USB host controller.

So I decided to remove unhalt sent “just in case” and to send it only when device cleanly indicates that it is halted by returning appropriate error code (which was never actutally observed with printers so far).

If you have more questions, don’t hesitate to ask

Now about iR2625/2630 web console. Technically it is not difficult to override Location: header in the response. But if device’s web page really want to redirect to the external location, it will be broken in result.

So I need to think a little bit.

This is firmware bug. Firmware knows port (60000 in this case) from the Host: header in request and must mirror this value in every URL it returns in response (not only in HTTP headers, but in data as well, and most devices really do so).

Thank a lot for your feedback and testing effort.

A little bit of technical background, if you are interested.

Some devices sometimes return truncated response to the HTTP request. It happens not always, but with some probability. Once response is truncated, ipp-usb will wait forever for the missed bytes, which effectively block USB connection. Once all USB connections are blocked, device doesn’t work anymore.

Your device is the 3rd that have this problem. Previous 2 were HPs. The solution is the same in all cases: HTTP request sent to device should have “properly” set Connection header (either Connection: close or Connection: keep-alive, or no Connection header at all). Unfortunately, the “proper” setting is different for different devices.

Actually, this is firmware bug. Connection header should not affect IPP over USB at all, because unlike TCP, USB doesn’t have such thing as “connection close”. But in reality it does, and I have to live with it.

So I close this issue as resolved. The just created 0.9.9 release contains this fix.

Hi Tess,

may you play a little bit with Connection: close/Connection: keep-alive on ARM? May be we will find a working combination.

Every request that goes to device has a following header field: Host: localhost:60000. In theory, clients must set this fields by themselves (per HTTP/1.1 specification; client knows the port number it is connected to); ipp-usb enforces that this field is not missed, by adding it when appropriate (it also knows the port number). Firmware, when request comes from USB, cannot know port number, so it MUST reflect port number from the Host: header of the request.

Most likely, in the iR2625/2630 firmware HTTP requests, falling from USB, are internally routed to the same HTTP server, that serves requests coming from network, and instead of taking port number from the request header, it takes port number from its own network configuration. It would work correctly when HTTP server accessed from the network, both numbers would be the same at this case, but not when it is accessed from USB.

I can rewrite response header, fixing the port number. But if it appears within web bages (in HTPL, in JavaScript and so on) I can’t reliable detect and override it there