Open villu164 opened 1 month ago
villu164
commented
1 month ago Also tried with,
Bus 001 Device 002: ID 0781:5596 SanDisk Corporation Ultra T C Serial: 4C530001110718113092still 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
antoinevg
commented
1 month ago 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!
dominikfehr
commented
3 weeks ago same issue with multiple devices.
LIBUSB_ERROR_NOT_FOUND as user LIBUSB_ERROR_BUSY with sudo privileges
xairy
commented
3 weeks ago 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_handleI'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.
mossmann
commented
2 weeks ago I've implemented a similar solution in https://github.com/greatscottgadgets/facedancer/pull/104 which has a couple advantages over the above patch.
tomikoski
commented
1 week ago 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 --releaseOnce again, good way to test it before use:
cd cynthion.git/firmware/moondancer
./scripts/moondancer-info.pyOne 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.
antoinevg
commented
1 week ago 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