USBvalve icon indicating copy to clipboard operation
USBvalve copied to clipboard

Dongle-based devices

Open Zorakie opened this issue 1 year ago • 8 comments

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 ...

Zorakie avatar Mar 25 '24 22:03 Zorakie

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 avatar Mar 25 '24 23:03 cecio

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

cecio avatar Mar 25 '24 23:03 cecio

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.

Zorakie avatar Mar 25 '24 23:03 Zorakie

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.

cecio avatar Mar 25 '24 23:03 cecio

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

Zorakie avatar Mar 26 '24 00:03 Zorakie

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 avatar Mar 26 '24 00:03 cecio

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

cecio avatar Mar 26 '24 08:03 cecio

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

Zorakie avatar Mar 26 '24 09:03 Zorakie