Okay, I understand what the check you are referring to now. The USB stack
guarantees that those conditions will not happen by doing exactly as you’ve
suggested with BPF.
The vernacular I generally hear and speak would be something similar to using
either “over USB” or “over the bus”.
For a completed isochronous request the ioLength is set to the sum of
frameHeader.frameLength over all the completed frames (the total amount of data
that was actually transferred for the request). It can/should be displayed but
it only provides a high-level overview of the actual result.
—scott
> On Jan 5, 2017, at 11:40 PM, Guy Harris <g...@alum.mit.edu> wrote:
>
> On Jan 5, 2017, at 11:22 PM, Scott Deandrea <sdeand...@apple.com> wrote:
>
>> Correct, for a submitted request on the default control pipe is the maximum
>> amount of data requested. The ioLength for a completed request of
>> non-isochronous pipes will be equal to the amount of data payload
>> transferred on the bus. I’m not following what/how you would check that.
>
> In Wireshark, it'd be
>
> {Dissect link-layer header; when done, "offset" is the offset of the
> first byte past the link-layer header. Save the value of ioLength in a
> variable called "ioLength", and the protocol tree item for it in a variable
> called "ti_ioLength".}
>
> if (tvb_reported_length_remaining(tvb, offset) < ioLength)
> add an expert info to ti_ioLength saying "packet is missing
> data from the transfer"
> else if (tvb_reported_length_remaining(tvb, offset) > ioLength)
> add an expert info to ti_ioLength saying "packet has extra data
> past the end of the transfer"
>
> I.e., if the on-the-wire length of the packet is less than the amount of data
> payload transferred on the bus, note that the packet doesn't have all the
> data transferred (*not* because the packet was arbitrarily cut short by a
> snapshot length - that would be a comparison against
> tvb_captured_length_remaining(tvb, offset), and would be handled by an
> exception being thrown while dissecting the payload - and if the on-the-wire
> length of the packet is greater than the amount of data payload transferred
> on the bus, note that the packet has extra stuff at the end that didn't come
> from the transfer.
>
> However, if the USB stack guarantees that neither of those will happen, i.e.
> if the code that constructs the packet and submits it to BPF sets the
> on-the-wire length in the BPF header (bh_datalen) to the sum of the length of
> the header and the amount of data transferred, then those checks aren't
> necessary.
>
>> The link-layer headers, etc, for all packet types is handled entirely by the
>> USB controller hardware and is not visible to host software in any way. To
>> describe it another way, the host software is only ever aware of the data
>> portion of the transfer as the link layer information is added/stripped by
>> the controller hardware itself. Therefore, any bounds checking should be
>> performed with respect to the captured length.
>
> Note that when I say "link-layer header", I'm referring to the pseudo-header
> you've described, not any link-layer header information transmitted over the
> USB bus.
>
> (Speaking of which, "USB bus" is redundant, but "over the USB" sounds weird;
> do we just live with it the same way we live with "ATM machine" and "PIN
> number"?)
>
>> For isochronous pipes, the ioLength for a submitted request is just the
>> length sum of frameHeader.frameLength over all the submitted frames.
>
> That could, in theory, be checked, but I'm guessing that the code that
> constructs a packet and hands it to BPF explicitly calculates the ioLength as
> the sum of frameHeader.frameLength over all the submitted frames, so a check
> is pointless.
>
>> For a completed request, the ioLength has no meaning on an isochronous pipe,
>> only the frameLength is valid (which will be equal to the amount of data
>> that was transferred).
>
> Is it set to the sum of frameHeader.frameLength over all the submitted
> frames, or is it some random value that shouldn't even be displayed, much
> less checked?
>
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
