-
Notifications
You must be signed in to change notification settings - Fork 44
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
Dongle-based devices #23
Comments
I don't think the issue is related to "Dongle-based" devices, I tested a lot of them (keyboards, mouse, etc) and they usually works fine. The point is a bit more complex: the entire USB Host emulation is done via software. This means that timing issues are a thing. TinyUSB suggest to set the clock to 120 or 240 Mhz. But during my tests (done in the last year more or less), I realized that to achieve the wider compatibility I had to tweak this to a specific value, different from the recommended one. With this I have all the devices I ever tested working. But I'm sure that you can stumble in something not working, or not working all the times like in your case. I need to figure out a way to debug this without buying all the USB devices available in the world :-))) |
For example, the mouse Jiggler (which is potentially a malicious device) is recognized correctly. Amyway, thanks for your report. May be I'll ask your help if I need to make some tests ;-) |
Consider I know nothing about programming for Pico. Would it be technically possible to change the frequency on-the-fly? I tried a random google search and it seems to be possible (https://www.tomshardware.com/how-to/overclock-raspberry-pi-pico) Would it be possible to change Pico frequency in loops? Let's say 120 to 240, steps per 10MHz, that's 12 steps, it you make it change the freq every 0,33s, you cycle through frequencies each 4 seconds. Considering any HID device would be sending stream of data over time and not like just during one or 2 secs, this could potentially increase detections, as there is a chance you end up on a compatible frequency while the device is pushing something. |
Yes, it is possible, and it is actually what I'm doing now to set the "custom" frequency. For what regard your idea of "cycling" the frequencies...I'm not sure it is feasible...need to think about it. Thanks for the idea anyway. |
Shower thought: How about the "Keep it simple stupid method"? We don't need to loop all the frequencies. What if:
If that won't crash the other core while doing stuff, it could - with a bit of luck - work. The only thing to figure out would be a reasonable counter for each freq |
yeah, something like that make sense, but if it works (and I'm not sure, need to test on the field), we also have to consider how to manage the serial monitor (that prints out the activities) which could be broken by these frequency changes, the mass storage emulation, etc. A lot of things to clear out. |
First tests are not encouraging: looks like everything breaks :-))) |
I am unfortunately 5 days abroad now, but feel free to throw any test build on me, and I can check back on it on Saturday :) |
Hi, while playing with my USBValve, I found out, that although mice are supported, when I tried connecting my wireless mouse, USBValve does not behave correctly.
Now, I know, that the chance this would be a real world scenario is pretty low, but I want to mention it anyway (what worse can happen than this being closed ^_^
Anyway:
So technically, if a malicious device would exist, that mimics whatever protocol is behind this, it would be a potential gap ...
The text was updated successfully, but these errors were encountered: