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

Dongle-based devices #23

Open
Zorakie opened this issue Mar 25, 2024 · 8 comments
Open

Dongle-based devices #23

Zorakie opened this issue Mar 25, 2024 · 8 comments

Comments

@Zorakie
Copy link

Zorakie commented Mar 25, 2024

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:

  1. When attaching a mouse dongle, there is no USB/HID detection message. Like 90% of time.
  2. Those other 10% the Pi "freaks out", sending 4 messages at once, 2 detections, and HID 2 data sending.
  3. When attached, no matter what I do with the mouse (movement, clicks, switch off and on again), no message is shown that the device would be sending some info.

So technically, if a malicious device would exist, that mimics whatever protocol is behind this, it would be a potential gap ...

@cecio
Copy link
Owner

cecio commented Mar 25, 2024

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 :-)))

@cecio
Copy link
Owner

cecio commented Mar 25, 2024

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 ;-)

@Zorakie
Copy link
Author

Zorakie commented Mar 25, 2024

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.

@cecio
Copy link
Owner

cecio commented Mar 25, 2024

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.

@Zorakie
Copy link
Author

Zorakie commented Mar 26, 2024

Shower thought: How about the "Keep it simple stupid method"? We don't need to loop all the frequencies. What if:

// Main Core1 loop: managing USB Host
int freqArr[] = { 144000, 230000}; //frequencies to loop
int loopsArr[] = { 50, 100}; //TBD number of loops spent on that freq, lower the freq, in theorz less loops as thez take more time
int index = 0;
int counter = 0;
void loop1() {
    USBHost.task();
    counter++;
    if (counter == loopsArr[index]) {
        index = (index + 1) % 2; //switch to other freq/counter
        counter = 0;
        set_sys_clock_khz(freqArr[index], true);
    }
}

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

@cecio
Copy link
Owner

cecio commented Mar 26, 2024

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.
I'll look into that.

@cecio
Copy link
Owner

cecio commented Mar 26, 2024

First tests are not encouraging: looks like everything breaks :-)))
But I'll keep looking into this.

@Zorakie
Copy link
Author

Zorakie commented Mar 26, 2024

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 :)

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

No branches or pull requests

2 participants