Comment # 7
on bug 10025
from Sean O Stalley
(In reply to Bill Meier from comment #6)
> (In reply to Sean O Stalley from comment #5)
> > Created attachment 13015 [details]
> > a trace of MSD enumeration over TCP
> >
> > Bill:
> >
> > It also contains instances where MA USB packets span across multiple TCP
> > packets. These don't dissect properly.
> >
> > I hope this helps,
> >
> > -Sean
>
> Thanks
>
> Yes; while I was reviewing the code (and fixing another bug) I had a
> suspicion that the handling of certain re-assembly cases might not work as
> expected.
>
> To save me some time, can you indicate the approximate set of frames in the
> capture which aren't being dissected properly (when "USB packets span across
> multiple TCP packets")?
Sure thing, frame 461 is where it starts to get weird. In frame 461, there is 1
complete MAUSB packet (Sequence #22), followed by the start of another MAUSB
packet (sequence #23). frame 462 has part of the packets with sequence numbers
23 & 24. packet 24 is displayed when the packet is complete, but packet 23 is
not.
> Separately, using a global for 'mausb_num_pdus' in general won't work well
> if there happens to be two simultaneous different MAUSB TCP connections in
> the capture. (I don't know if two simultaneous TCP connections in a capture
> would be unlikely; I'll fix it anyway).
There was some discussion about a better way to go about counting PDUs here:
https://code.wireshark.org/review/#/c/1658/1
It is quite likely that 2 simultaneous MAUSB TCP could be in 1 trace. Consider
the case with 1 Host connected to 2 MAUSB devices. Each device would have a TCP
connection to the host.
> Again separately, I notice that dissection of [GET DESCRIPTOR RESPONSE
> DEVICE]
> MAUSB PDUs (e.g., frame 231) are showing as Malformed. Is this as expected ?
The USB dissectors don't like to dissect partial USB descriptors. For example,
in frame 221 there is only 8 bytes of the device descriptor. That's whats
causing that packet to be malformed.
For the others, it looks like the usb conversation is getting messed up... It
was working previously. I think that's what's causing the other packets to show
up as malformed. I'm investigating that now.
You are receiving this mail because:
- You are watching all bug changes.