JohnDMcMaster / usbrply

Replay USB messages from Wireshark (.cap) files

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Replaying USB_INTERRUPT Packet, replay.py is blank?

reydus opened this issue · comments

I'm trying to immitate a packet, which I captured using USBcap and filtered through Wireshark until there was only one. It sends a few bytes (rgb data) to device 1.14.2 (device 14, endpoint 2, My Corsair gaming keyboard with LEDs)

While I do reply.py in my CMD, it does not send the package. Wireshark is still running filtering for packages with destination 1.14.2, yet it does not sniff any package sent. It only detects packages when I run them from the original source (Corsair's LED managing prioritary software)

I noticed that, in comparison to the test win1.pcapng. my reply.py, generated by the command python usbrply --device-hi -p ..\..\usbrply\make_green_filtered.pcapng > replay.py is rather... blank?

I leave resulting reply.py and original single-packet make_green_filtered.pcapng

Cheerio!
replay py

make_green_filtered pcapng

Not forgotten, but it may take me a bit to look at this. Ping me in a week if you don't hear back

My brief understanding is that you've filtered out certain kernel messages for an out URB that should be present in a full capture. You've provided the submit packet (FDO2PDO), but are missing the complete packet (PDO2FDO). This is why (using master which recently improved error logging) you would get:

# WARNING: 1 pending complete requests

I could potentially support these incomplete transactions, but I'm not sure it would add a lot given they should be in normal .pcap captures.

For reference here's verbose output using master:

$ python3 main.py --verbose 2021-03-07_issue46/make_green_filtered.pcapng 
# Generated by usbrply
# cmd: main.py --verbose 2021-03-07_issue46/make_green_filtered.pcapng

parsing from range 0 to inf



WIN PACKET 1
00000000  1B 00 10 00 DC 63 07 B4  FF FF 00 00 00 00 09 00  |.....c..........|
00000010  00 01 00 0E 00 02 01 40  00 00 00 07 25 00 00 00  |.......@....%...|
00000020  FF 00 00 FF 00 00 FF 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00                 |...........     |
Pending (0):
Length 91
ID 0xFFFFB40763DC0010, 64 post-urb bytes
URB id: 0xFFFFB40763DC0010
 pcap_hdr_len: 27
 irp_status: 0
 usb_func: BULK_OR_INTERRUPT_TRANSFER
 irp_info: FDO2PDO (0x00)
 bus_id: 1
 device: 14
 endpoint: 0x02
 transfer_type: 1
 data_length: 64
Added pending interrupt URB 18446660542565974032
gen_data: 4 new JSON entries
# Generated by usbrply
# Source: Windows pcap (USBPcap)
# cmd: main.py --verbose 2021-03-07_issue46/make_green_filtered.pcapng
# PCapGen device hi: selected device 14
# WARNING: 1 pending complete requests
# PcapGen: generated 2 packets
# PcapGen device filter: dropped 0 / 2 packets
# SetupFilter: dropped 0 / 7 entries

Also FYI if you are using the older pip release note its a bit outdated: #47

In particular some interrupt handling bug fixes have not been officially released. I'll try to push this out soon

I don't have the device with me at the time of writing, but once I get it back I will try so.

I can't say I am an expert in URB but Wireshark was only ever showing those packages listed there.

The packet was sent when using the proprietary program to set the colour, and didn't receive anything afterwards, the keyboard just changed the color as expected. I can de-filter until there are several packages in a row, do you think this would work? What PDO2FPO should I be looking for?

It sounds like the short version is don't filter the wireshark captures and you should be fine. Latest usbrply can filter based on things like vid/pid which should make it easy for you to pick out just the packets you care about.

Sounds like this is solved? Please re-open if you need additional assistance.