Open villu164 opened 1 month ago
Also tried with,
Bus 001 Device 002: ID 0781:5596 SanDisk Corporation Ultra T C Serial: 4C530001110718113092
still fails, but for some reason I see Google Chrome having some fingers there
Added some dmesg-s
4811907_thumb1_chrome_closed.txt 4812031_thumb2_chrome_closed.txt 4812142_thumb3_chrome_open.txt
Thank you for the report, it sounds like the Cynthion SoC firmware is losing the connection to the proxied device.
Will follow up with more questions if I can't reproduce it on my side!
same issue with multiple devices.
LIBUSB_ERROR_NOT_FOUND as user LIBUSB_ERROR_BUSY with sudo privileges
This change appears to fix the issue:
diff --git a/facedancer/proxy.py b/facedancer/proxy.py
index 6f053d9..26bca33 100644
--- a/facedancer/proxy.py
+++ b/facedancer/proxy.py
@@ -354,7 +354,10 @@ class LibUSB1Device:
for interface in active_configuration:
number = interface[0].getNumber()
cls.device_handle.releaseInterface(number)
- cls.device_handle.attachKernelDriver(number)
+ try:
+ cls.device_handle.attachKernelDriver(number)
+ except:
+ pass
cls.device_handle.close()
cls.device_handle = None
@@ -374,7 +377,10 @@ class LibUSB1Device:
if active_configuration:
for interface in active_configuration:
number = interface[0].getNumber()
- cls.device_handle.detachKernelDriver(number)
+ try:
+ cls.device_handle.detachKernelDriver(number)
+ except:
+ pass
cls.device_handle.claimInterface(number)
return cls.device_handle
I'm guessing the problem is that an interface might currently have an altsetting that does not have a kernel driver attached and thus detaching the driver fails.
I've implemented a similar solution in https://github.com/greatscottgadgets/facedancer/pull/104 which has a couple advantages over the above patch.
If someone else is struggling still with this issue, following worked for me (in ARM macOS and Intel Debian)
firmware
using cargo run --release
, do notice that this will fail during last step but doesn't matter (due to reset)If all above works, this will work now:
cd cynthion.git/firmware/moondancer
./scripts/moondancer-info.py
# outputs something like:
Found a Cynthion in Moondancer mode!
Board ID: 16
Firmware version: r1.0
Part ID: a0000...
Serial number: <REDACTED>
Exactly the same happens for me in macOS and Debian. With this approach everything works until Cynthion is reseted (or rebooted). If this happens, you just need to rerun flashing part:
cargo run --release
Once again, good way to test it before use:
cd cynthion.git/firmware/moondancer
./scripts/moondancer-info.py
One more finding; if I do a apollo flash-info
, I will have to reflash Cynthion again to make it work. It seems that this part
causes it to happen. This was found by monitoring UART.
One more finding; if I do a
apollo flash-info
, I will have to reflash Cynthion again to make it work.
That's correct. The FPGA shares the USB port with the microcontroller running Apollo. This makes it possible to handover control from the FPGA to Apollo but the microcontroller has no corresponding mechanism to return control to the FPGA.
If you do a cargo flash facedancer
you can always get back by just pressing the RESET
button without having to reload the Facedancer bitstream.
I'm guessing it might be the HUB (see dmesg from below), I'll see if I can find some USB C device, that doesn't need the HUB
throws exception
I can visually see, that the python script is able to do something to the mouse connection
https://github.com/user-attachments/assets/d9ee0a18-28cc-4098-a0a2-0da9d75e7dfa
And also from the dmesg, I see some activity