Overflow with USB Stress Ball #4
Comments
|
Some additional debugging information from libusb: |
|
I installed libusb-1.0-0-dev and compiled this tool tonight on my Ubuntu 15.10 laptop. Unfortunately I did not replicate your situation yet. It then continues to repeat with lots of errors and scattered responses from the device. |
|
What version of which OS are you using? Are you on special hardware, like a Raspberry PI or other non-typical device? Does this device work for anyone else or with any other drivers? I would love to eliminate a hardware issue as the cause of the problem. Here's the stuff that I see from my logs that doesn't seem to match yours: And here's the stuff from your logs: Could be a difference that's coming up with the next version of the libusb library? |
|
I'm running arch linux, updated, on a Thinkpad T420 (about as bog-standard and supported as they come).
|
|
Oh, and my USB tree: |
|
Digging more:
I think I will have to make a VM or Docker container and experiment for a while to get this to work (fail?) properly. Since I really don't know USB that well, I may need to ask people for help on this one. I don't want to admit this, but this tool is mostly just hobbled together from little bits and snippets. It's almost as bad as a Stack Overflow post. |
|
What's the maximum packet you send? I've got the line |
|
(Also, if you have something you want tried, let me know. I do know my way around a C compiler, I just make a habit of avoiding it in my own work.) |
|
Well, it happens in Python, too: https://gist.github.com/astronouth7303/d5cea052a0b33e423b312ddbd1c00441 |
|
I created a VM in VirtualBox and installed Arch from a freshly downloaded ISO. Reminded me a lot of Gentoo. Strangely I get a different problem with VirtualBox. How sad. I guess some experimentation is in order. @astronouth7303 would you mind editing line 305 to read as follows? It could work if we just ignore overflow errors.... maybe. if (ret != 8 && ret != LIBUSB_ERROR_OVERFLOW && ret != LIBUSB_ERROR_IO) { |
|
For the adventurous, here's the full set of libusb logs from the VirtualBox instance. |
|
Huh. If I change lines 305 and 320, it starts working intermittently, so as well as it did before. |
|
Hm. Ran a long-running test with Edit: Oh, might be a feature of the device? Using it gets the rate back up. |
|
To answer your previous question, the packet size I send (and the size I receive) is 8 bytes, which matches the protocol docs ... well, it matches as much as I understand them. I use Perhaps Dream Cheeky is abusing the USB standard. Perhaps I am. I think I'll ask the developers of libusb to help take a look at this problem. To that end, the following is just a log of what I've done to try to eliminate or find this error. I've downloaded the libusb from git in my virtual machine and compiled it. Ran I tried the rest of the Dream Cheeky buttons I own with the VirtualBox arch linux (different products, none with analog outputs) and they work as expected. I do get the occasional "Error getting interrupt data: -7" but I've experienced that in the past and no amount of slowdown actually eliminates that problem. After that I tried compiling and using the libusb from git on my main Ubuntu system. It worked! Then I installed Lubuntu in a virtual machine and it failed with -9. I suspect VirtualBox is the source of my errors for -9, but that doesn't give me any clues about why you are getting -8. For the record, the Lubuntu is using libusb 1.0.19.10903 with kernel 4.2.0-16-generic. I have no other things I can check at this moment so I will be asking for help from the libusb developers mailing list. I hope they can help decide if my code is crap or if there might be an obscure problem that's showing up with either Arch or a newer Linux kernel. Protocol information: http://files.dreamcheeky.com.s3.amazonaws.com/uploads/dc/808/StresSBall-DeveloperManualv1.0.pdf |
|
I suspect the VM's seeing -9 is just VirtualBox reinterpreting USB problems. My suggestion to suss that would be to try different virtualization systems or even containers. I'm still not sure why Ubuntu and Arch are giving different errors, unless it's a recent change in the kernel. I also wonder if something in the stack/chain is reporting an underflow as an overflow. |
|
The libusb developers have responded a bit: Alan:
Tim then quoted the bit about me having issues with VirtualBox and asked ...
@astronouth7303, feel like digging into usbmon a bit? I'll try hard to find some time this weekend to do the same. I also might steal my wife's laptop to install Arch just so I can reproduce this problem. |
|
Quick intro to usbmon the wireshark way: # on my system, it is root:root 600 by default.
echo 'SUBSYSTEM=="usbmon", GROUP="wireshark", MODE="0640"' > /etc/udev/rules/wireshark-usbmon.rules
modprobe usbmon
# or "udevadm trigger -s usbmon" if module was already loadedThen, as a regular user member of the wireshark group, run |
|
I'm going to start digging into this, but here's the wireshark file: Should be able to extract, open in wireshark, and get results. |
|
@fidian I still think that the different errors represent the same base problem, and that Arch and Ubuntu aren't handling it fundamentally differently. They're just exposing it with more detail. But please prove me wrong! |
|
I also captured pcap files for both the host Ubuntu system and guest Arch machine. They're in tshark.zip. I decided to sudo instead of modifying udev rules, so I hope @vpelletier doesn't mind and I also hope that this still produces the results that were desired. Very brief: |
|
@fidian: I don't mind, but I did not intend to analyse the content of the dump either :) . I came here from the bug report @astronouth7303 filled about my python libusb wrapper module, so i'm a tourist/spectator here. AFAIK wireshark produces pcap files too, so it should actually be just the same format (it uses pcap's ability to interface with usbmon, after all). Also, yes, I do not know how safe it is to grant a regular user read access to low-level usb buses (it certainly allows keylogging for example). My overall train of thought about this setup is (and the last point is very important for security):
|
|
@vpelletier Don't worry - I wasn't intending to have you inspect the USB traffic. Instead, I was merely calling out that I didn't follow your instructions. I do love your last comment - very thorough. :-) Anyway, my zip file was mostly for the libusb developers mailing list so they could help inspect my traffic. And, for reference (mostly by myself or maybe astronouth7303) here is their analysis of my zip. It gives me a place to start looking and a direction to take when looking at the other zip that contained astronouth7303's USB packets.
Before I follow up on the mailing list I will need to inspect my code again, test this more on my computer, capture the "working" packet dump, and compare versus the broken packet dumps. Probably won't get solved this week - that's a lot of stuff to do and, like everyone I know, my idle time at home is limited. |
|
Hello, Fidian asked me to check the stress ball device on my Arch linux installation: It appears to work fine if I plug the device in through a double usb hubs (one powered) as my keyboard is plugged into my monitor and my monitor into my laptop. However when plugging in directly it appears to crash within seconds. It seems to me the failures I experience are to do with the stressball hardware not being particularly reliable. Some details: Output of failures directly connected to laptop. Output of failure when connected through monitor and keyboard usb hubs. The failures occurs when I give shake the stressball if I leave it lying on the table undisturbed it seems to run fine for extended periods. |
|
I can not replicate the issue with my device. As you can see, when it is shaken it must short out or something. For your issue I suspect your hardware is also a little crazy (like mine) or there's something unique to your setup. Closing this issue. |
Thank you for writing this! However, I just compiled
master(83894e2) and I'm getting a runtime error:The libusb documentation reports this as simply "overflow".
Not sure how this happens or why.
Yes, I tried unplugging it, plugging it back in, and immediately re-running bonkers.
The text was updated successfully, but these errors were encountered: