https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5370
--- Comment #15 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2010-11-23 13:21:11 PST ---
(In reply to comment #13)
> As you can see this only contains the transfer type, but *not* the direction.
> This is handled wrongly in Wireshark several places.
OK, I was going by the current, apparently incorrect, handling of the
transfer_type. Maybe another patch to correct those issues will be forthcoming
later? :)
> The data is the byte array to where the iso_off points. The data bytes are
> starting at iso_off offset and has the length iso_len. The padding is a
> different thing here, it is coming from the struct mon_bin_isodesc. There is,
> however sometimes padding bytes between the data blocks also, but they are not
> handled by this patch. See the example capture file from comment #12.
The capture file will definitely help. I'll try to review this part again now
that I have a capture file when I get a chance, assuming nobody beats me to it.
> This is following the style of the "URB length [bytes]" and "Data length
> [bytes]". I think it is always a good idea to have the unit shown near to the
> value. Is this maybe handled differently in other parts of Wireshark?
Yeah, I would remove those as well. A few dissectors indicate units via
"(byte)", "length (in bytes)" or variations thereof, but overall, I don't think
it's particularly useful, and I don't think most dissectors do this since it's
obvious what the units are. (For example, take a look at IP, UDP, TCP, ...)
Maybe if the length was in units other than bytes it might be useful to
indicate it. Well, that's just my opinion. This won't hold up the patch like
the byte-swapping stuff will.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.