Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ippusbxd returns invalid data to TCP clients #15

Open
alexpevzner opened this issue Jan 5, 2020 · 7 comments
Open

ippusbxd returns invalid data to TCP clients #15

alexpevzner opened this issue Jan 5, 2020 · 7 comments

Comments

@alexpevzner
Copy link
Member

@alexpevzner alexpevzner commented Jan 5, 2020

HTTP request, sent to one TCP connection, may eventually be replied to another unrelated connection.

The scenario is following:

  • Client connects to TCP port and sends HTTP request. It causes an USB interface to be allocated for the client connection
  • Client disconnects before reply is fully received or even before reply is created. USB interface becomes "free" and returned to the pool of free interfaces
  • HTTP reply is not discarded by device at this case, but remains buffered on per-USB-interface buffer.
  • Client establishes another TCP connection, which receives previously USB interface with reply data pending. This data will be sent to this new TCP connection, surprising a client

This problem comes from the fact, that USB is not TCP, and "closing USB connection" doesn't have a semantics of closing TCP connection, where all data is rejected.

Note, even ippusbxd restart doesn't drain buffered USB data

To fix this problem, ippusbxd must always read an entire HTTP reply, even if client already disconnected and even if it takes half an hour. There are 2 methods how HTTP/1.1 server may indicate end of data stream: it either announces stream size in a reply Content-Length header, or uses HTTP chunked encoding; server is free to choose any of these methods on a per-request basics, and ippusbxd MUST understand both. Effectively it means, ippusbxd MUST implement a HTTP reverse proxy rather that just a simple TCP relay.

BTW, #14 most likely a related issue

@tillkamppeter

This comment has been minimized.

Copy link
Member

@tillkamppeter tillkamppeter commented Jan 6, 2020

@DavieV, any ideas?

@tillkamppeter

This comment has been minimized.

Copy link
Member

@tillkamppeter tillkamppeter commented Jan 10, 2020

@alexpevzner, I have now tested everything currently possible (IPP print with CUPS, AirScan/eSCL with both SANE backends, web admin interface including the built-in web scan) on my HP OfficeJet Pro 8730 with your ipp-usb daemon and it works all perfectly and reliably. So what we need is to transfer this into ippusbxd.

@DavieV

This comment has been minimized.

Copy link

@DavieV DavieV commented Jan 10, 2020

This is great to hear! Please let me know if there's anything you would like me to assist with. Once this newer system has been integrated into ippusbxd I will work on integrating it with Chrome OS.

@tillkamppeter

This comment has been minimized.

Copy link
Member

@tillkamppeter tillkamppeter commented Jan 10, 2020

@DavieV, what you could cooperate with us now, is testing @alexpevzner's ipp-usb daemon, especially whether it works under Chrome OS and also with all the hardware devices you have access to.

@DavieV

This comment has been minimized.

Copy link

@DavieV DavieV commented Jan 21, 2020

Unfortunately it turns out that Go projects aren't allowed in Chrome OS due to their large binary sizes.

In the meantime, I think we'll maintain a fork of the current ippusbxd and work towards implementing the changes that exist in ipp-usb.

@tillkamppeter

This comment has been minimized.

Copy link
Member

@tillkamppeter tillkamppeter commented Jan 21, 2020

If you are working on taking over the changes of ipp-usb into ippusbxd you are very welcome with this and I would suggest you to submit them here to make ippusbxd better. If you would do it in rather short term (up to mid-February 2020) I would stay with ippusbxd in Ubuntu and not consider a switchover to ipp-usb, only if this is a long-term project, which you will finish only in a year or longer, I will probably go the ipp-usb way in Ubuntu.

@alexpevzner

This comment has been minimized.

Copy link
Member Author

@alexpevzner alexpevzner commented Jan 22, 2020

Heh, programming language from Google cannot be used on operating system from Google.

Executable size is large, I agree.

However, ipp-usb itself uses memory very carefully. For example, images are streamed between host and device, ipp-usb doesn't try to load entire image into its memory before forwarding it. And it doesn't have any external dependencies, except Avahi and libusb. So final memory footprint may be comparable with pure-C version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.