Different IRP IDs for SCSI cmds and their statuses in UAS mode

[waseemR02]

As the title suggests, in BOT mode the IRP IDs are same for the commands issued as well as their statuses along with bunch of URBs. Wireshark takes advantage of this by forming a conversation and showing request and response frames.
But in UAS mode, the IRP IDs are different, only same for the command and it's URB ack(i guess), but the data phase and the status phase have different IRP IDs, hence wireshark is unable to form conversations.

This means I can't be sure the status and the data packet just after the cmd packet belong to that specific cmd, as lot of commands are queued. i also can't depend on the tag id present in the capdata because the tag id, even though supposed to be unique, can be reused if it has been completed by a previous commands.

Is there a way, I can be sure that the statuses and the datas belong to that specific command?

[desowin]

IRP ID is used only to group the IRP submit with IRP complete. Mass Storage dissector does not use IRP ID. The grouping in Mass Storage dissector in BOT mode is based on the fact that CBW always precedes CSW.

If Wireshark UAS dissector is not correctly grouping URBs then this sounds like a problem in Wireshark dissector and not in USBPcap itself.

[waseemR02]

Thanks @desowin ,
I had thought the grouping happens because of a common header as specified here from Wireshark repo

And while I was checking the packets in BOT mode, I had noticed that the IRP ids were same for these corresponding packets, which led to my assumption that the conversations where formed from this header

In the case of UAS, it doesn't even dissect because the length seems to be off by 1 (59). Am I correct to assume it comes from USBPcap, was there any change which broke the dissector, or is it host specific issue?

Sorry, if I am speaking in circles, I am just trying to wrap my head around this, and probably not asking the right question. My usecase was to capture a trace and extract data so that I can replay it. If the dissections are not proper then I can't just depend on the length of the headers or the ordering of the packets(since UAS queues) to identify them, hence my question. Any help or guidance would be immensely helpful to me.