Todo This Week
- Make 6 parallel connections bring up same webpage as single connection browsers.
- Handle http messages larger than 8KB
- Complete all the TODOs in http.c
Completed This Week
- Support large http packets
- Fixed some crashes
- Fixed some data loss
- Fixed a bunch of TODOs
Todo Next Week
- Fix things
This week consisted of bug fixing and tracking down broken code. I’m not proud to say that things are no really working. I now realize that things only worked a few weeks ago because of another bug. I thought TCP and USB were requiring known message sizes but really they were still passing data back & forth as packets came in.
I’ve fixed many of the bugs but I’m still hitting bugs like this:
01. Note: USB: Getting 262144 bytes of 0 02. Note: USB: Got 320 bytes 03. Note: USB: Getting 8704 bytes of 8953 04. Note: USB: Got 2048 bytes 05. Note: USB: Getting 6656 bytes of 8953 06. Note: USB: Got 2048 bytes 07. Note: USB: Getting 260096 bytes of 0 08. Note: USB: Got 2048 bytes 09. Note: USB: Getting 4608 bytes of 8953 11. Note: USB: Got 2048 bytes 12. Note: USB: Getting 2560 bytes of 8953 13. Note: USB: Got 441 bytes 14. Note: USB: Getting 2048 bytes of 8953 15. Note: USB: Got 336 bytes 16. Note: USB: Getting 260096 bytes of 0 17. Segmentation fault (コアダンプ)
On line 1 of this fresh server responce we see USB did not know what size to expect so it asked libusb for enough data to fill its buffer.
On line 2 USB received from the printer the message’s header. We can guess this because 320 bytes is an average header size.
Line 3 confirms our header guess because now USB knows how large the HTTP packet will be.
On line 7 USB somehow forgets how large the packet will be, so it asks for a full buffer.
Lines 8 to 15 look normal. Keep in mind in the “Getting X” the X has been rounded up to the nearest multiple of 512. This is something required by libusb so a precaution incase the usb device sends a full 512 byte packet instead of what we expect.
Then on line 16 USB forgets the message size again, just as it did on line 7. Also note how it thinks the buffer has the same amount of spare capacity as it did on line 7.
Then we segfault.
The above bug is something I hit while tracing a different bug where USB was getting data and could not find the packet size at all.
This past week I’ve been adding more and more tracing statements and it has helped. I cannot print the messages themselves since they are too large and the binary requests often break my terminal. Then since data has been left in the USB pipe any new requests are going to get malformed responses, which requires rebooting the printer to clear.
So, I’ve got four full weeks until GSoC ends. I plan to work more afterwards but I don’t want to ask my mentor to “Just trust me, I promise to fix it afterwards”. Instead ippusbxd needs to work. As well there is the Openprinting Summit starting on the 12th and I want to demo ippusbxd there.
The core things which need to get done are:
- ippusbxd needs to work
- udev-config-printer needs to startup ippusbxd
- udev-config-printer needs to add a print queue to cups
- cups should identify the printer between reboots
Its hard to estimate how long fixing ippusbxd will take but I cannot see it taking less than 1 week and I cannot afford for it to take more than 3 weeks.
So I’ll plan for it to take 2 weeks.