Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A failed libusb1::bulkRead() operation can cause Packetry to display a PID Malformed does not indicate a direction error. #179

Closed
antoinevg opened this issue Aug 22, 2024 · 4 comments · Fixed by #182
Labels

Comments

@antoinevg
Copy link
Member

When I am capturing a transaction and libusb1 is performing a bulkRead() operation that fails with a LIBUSB_ERROR_PIPE exception that causes the host program to exit abruptly the following occurs:

  1. Packetry pops up the following dialog: PID Malformed does not indicate a direction
  2. Subsequent attempts to start a new capture pops up the following dialog: Could not be opened for exclusive access
  3. Restarting Packetry allows me to resume capturing.

When I simply swallow the LIBUSB_ERROR_PIPE exception in the host program Packetry does not display any dialogs and continues to capture without any problems.

@martinling
Copy link
Member

Running with RUST_BACKTRACE=1 should get you a backtrace in the dialog.

Could you also try using the command-line capture mode from #136 to get a capture of the traffic that triggers this. That mode just dumps to pcap without running the decoder, so should avoid triggering the bug.

@martinling martinling added the bug label Aug 23, 2024
@antoinevg
Copy link
Member Author

Tx!

Exceptions:

PID Malformed
Could not be opened for exclusive access

Traffic capture using cynthion-cli: cynthion.pcap.gz

The capture file handily reproduces the PID Malformed exception when loaded into packetry which says all kinds of cool things about packetry's design :-)

Finally, a little bit more info:

This was happening when the host issued a CLEAR HALT on the bulk endpoint which was not handled by the device.

@martinling
Copy link
Member

Thanks, I'll take a look.

@martinling
Copy link
Member

The first error is fixed in #182. The packet that caused the problem was an SOF packet with a bad CRC. It was preceded by two IN packets with bad CRCs, but those didn't trigger the same bug:

image

I expect the second error is just a side effect of the first error: the device cannot be opened because there is a handle to it still left open by the capture/decoding process which failed.

martinling added a commit to martinling/packetry that referenced this issue Aug 29, 2024
@martinling martinling linked a pull request Aug 29, 2024 that will close this issue
@miek miek closed this as completed in #182 Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants