Re: DLT_ request

[Guy Harris <guy () alum mit edu>]

On Jan 5, 2017, at 11:22 PM, Scott Deandrea <sdeandrea () 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