Closed nametable closed 3 years ago
JohnDMcMaster
commented
3 years ago H! TLDR: Please 1) update to newest git 2) remove --device and let me know if this fixes your issue
Details: Looks like there are two issues: -Don't specify "--device". By default it will select the highest numbered device (in this case "2", not "7160") -Your kernel is generating a different data flow than I tested. I've updated code to reflect it
nametable
commented
3 years ago I now see that the generated script is not all warnings anymore. However, I am having an issue where I get a usb error when I try to run the generated script (I can create a different github issue for this if you want). Here's what the error looks like though:
Bus 001 Device 021: ID 0c45:7160
Traceback (most recent call last):
File "/tmp/USB-Fan/Wireshark captures/Data send/long.py", line 2450, in <module>
dev.claimInterface(0)
File "/home/logan/.local/lib/python3.9/site-packages/usb1/__init__.py", line 1168, in claimInterface
mayRaiseUSBError(
File "/home/logan/.local/lib/python3.9/site-packages/usb1/__init__.py", line 127, in mayRaiseUSBError
__raiseUSBError(value)
File "/home/logan/.local/lib/python3.9/site-packages/usb1/__init__.py", line 119, in raiseUSBError
raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorBusy: LIBUSB_ERROR_BUSY [-6]Maybe this just indicates that the usb device is not setup correctly (udev settings or permissions) but I'm not really sure... btw, I manually inserted the device into the script: (Bus 001 Device 021: ID 0c45:7160 Microdia XY LED FAN)
JohnDMcMaster
commented
3 years ago No it's fine to continue here
Can you try adding "sudo" to the front of your replay command? This might be a permissions issue
nametable
commented
3 years ago No change when I run sudo python long.py
Not sure if it helps, but heres the dmesg output when I connect the USB device:
[432637.579043] usb 1-5: new low-speed USB device number 23 using xhci_hcd
[432637.735713] usb 1-5: New USB device found, idVendor=0c45, idProduct=7160, bcdDevice= 1.03
[432637.735715] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[432637.735716] usb 1-5: Product: XY LED FAN
[432637.735716] usb 1-5: Manufacturer: XY-SUN
[432637.754856] hid-generic 0003:0C45:7160.014F: No inputs registered, leaving
[432637.754902] hid-generic 0003:0C45:7160.014F: hidraw0: USB HID v1.00 Device [XY-SUN XY LED FAN ] on usb-0000:06:00.1-5/input0I think maybe the device is being claimed by Linux as a HID. Maybe I can blacklist the device or "unclaim" it
nametable
commented
3 years ago I tried something else and got a different error. Under the idea that somehow the USB device was claimed, I did the following:
sudo su root
cd /sys/bus/usb/drivers/usbhid
echo -n "1-5:1.0" > unbindIt now seems to get further, making it to the first controlWrite before failing:
sudo python long.py
Scanning for devices...
Found device
Bus 001 Device 029: ID 0c45:7160
Traceback (most recent call last):
File "/tmp/USB-Fan/Wireshark captures/Data send/long.py", line 2452, in <module>
replay(dev)
File "/tmp/USB-Fan/Wireshark captures/Data send/long.py", line 46, in replay
controlWrite(0x40, 0x40, 0x2A06, 0x0017, b"")
File "/tmp/USB-Fan/Wireshark captures/Data send/long.py", line 31, in controlWrite
dev.controlWrite(bRequestType, bRequest, wValue, wIndex, data,
File "/usr/lib/python3.9/site-packages/usb1/__init__.py", line 1349, in controlWrite
return self._controlTransfer(request_type, request, value, index, data,
File "/usr/lib/python3.9/site-packages/usb1/__init__.py", line 1326, in _controlTransfer
mayRaiseUSBError(result)
File "/usr/lib/python3.9/site-packages/usb1/__init__.py", line 127, in mayRaiseUSBError
__raiseUSBError(value)
File "/usr/lib/python3.9/site-packages/usb1/__init__.py", line 119, in raiseUSBError
raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorPipe: LIBUSB_ERROR_PIPE [-9]```Hmm IIRC this usually means the device didn't like the data sent to it. Some suggestions: -Verify you didn't miss an initialization sequence, such as when the device is first plugged in -Check the USB output in say Wireshark reasonably matches the python code -Capture Windows traffic and compare to Linux traffic. Ideally as a Windows VM such that both use same Linux usbmon interface and so can be directly compared
nametable
commented
3 years ago I will give that a try tomorrow. I think there was some captures of the USB device connecting that I didn't take into account.
On Wed, Dec 23, 2020, 2:43 AM John Mcmaster notifications@github.com wrote:
Hmm IIRC this usually means the device didn't like the data sent to it. Some suggestions: -Verify you didn't miss an initialization sequence, such as when the device is first plugged in -Check the USB output in say Wireshark reasonably matches the python code -Capture Windows traffic and compare to Linux traffic. Ideally as a Windows VM such that both use same Linux usbmon interface and so can be directly compared
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/JohnDMcMaster/usbrply/issues/45#issuecomment-749990056, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEUF42VWRGJ2TBEV4AYN5LDSWGNQRANCNFSM4VESZGAQ .
nametable
commented
3 years ago Okay, so I tried monitoring usb traffic to a Windows vm, which was successful using Wireshark. I was able to record everything from connect to data transfer. However, in this new capture I now have a different problem which seems quite unrelated. For reference I captured traffic with usbmon on Archlinux with Wireshark Version 3.4.2. I started capture right before telling virt-manager to redirect usb to the vm.
Here's the new error I'm getting:
$ python ../../../usbrply/main.py --wrapper -p logan_cap.pcapng > doit.py
Traceback (most recent call last):
File "/tmp/USB-Fan/Wireshark captures/Data send/../../../usbrply/main.py", line 131, in <module>
main()
File "/tmp/USB-Fan/Wireshark captures/Data send/../../../usbrply/main.py", line 127, in main
usbrply.printers.run(args.ofmt, filtered, argsj=argsj)
File "/tmp/usbrply/usbrply/printers.py", line 14, in run
printer.run(j)
File "/tmp/usbrply/usbrply/pyprinter.py", line 229, in run
for d in j["data"]:
File "/tmp/usbrply/usbrply/setup_filter.py", line 31, in gen_data
for data in datas:
File "/tmp/usbrply/usbrply/com_pcap.py", line 75, in gen_data
if not parser.next(self.loop_cb):
File "/tmp/usbrply/usbrply/pcap_util.py", line 84, in next
loop_cb(block.captured_len, block.packet_data, block.timestamp)
File "/tmp/usbrply/usbrply/lin_pcap.py", line 322, in loop_cb
assert len(self.pcomments) == 0, ("unhandled comment", self.pcomments)
AssertionError: ('unhandled comment', ['Generated from packet 67/74'])Here is my new .pcapng zipped up: logan_cap.zip
JohnDMcMaster
commented
3 years ago This looks like https://github.com/JohnDMcMaster/usbrply/issues/42
I'll take a quick stab at it in the near future though using your data as a reference
JohnDMcMaster
commented
3 years ago I've made a quick effort to support Linux interrupts. Please update and let me know if it helps. Sample output:
# Generated from packet 67/74
buff = interruptRead(0x81, 0x0002)
validate_read(b"\x24\x80", buff, "packet 67/74")Yes, it definitely helped! No errors during python script generation. After unbinding my device to avoid the usb1.USBErrorBusy: LIBUSB_ERROR_BUSY [-6] error, I was able to run the generated script, which did what was expected on the target device! One of the devices LED's blinked indicating the LED FAN was being programmed.
Thanks for all your help (and very quick too)!
JohnDMcMaster
commented
3 years ago Great to hear it's working! Glad to be of help. Closing the issue as it seems this is resolved
When I try to create a replay of a USB-FAN device, I just get a bunch of "WARNING: Packet X missing submit." The capture file is included below in the zip: capture.zip Original source of file: https://github.com/Ventto/pearlfan/issues/11#issuecomment-513711300
This is some of the output in
replay()