Re: DLT_ request

[Scott Deandrea <sdeandrea () apple com>]

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.  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.

For isochronous pipes, the ioLength for a submitted request is just the length sum of frameHeader.frameLength over all 
the submitted frames.  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).

—scott

> On Jan 5, 2017, at 10:33 PM, Guy Harris <guy () alum mit edu> wrote:
>
> > On Jan 5, 2017, at 9:59 PM, Scott Deandrea <sdeandrea () apple com> wrote:
> >
> > The ioLength for a submitted request will the the amount of data requested in the data stage.
>
> So, for a submitted request on the Default Control Pipe, the ioLength won't be 8 for the setup data, it'll be the 
> maximum amount of data requested? 
>
> > The ioLength for a completed request will be the actual amount of data transferred in the data stage.
>
> So, at least for a non-isochronous endpoint, it *should* be equal to the amount of payload, i.e. on-the-wire length 
> minus link-layer header length?
>
> Is there any reason to check that?  Or should we just trust the on-the-wire length (and captured length, for bounds 
> checking), when dissecting the payload?
>
> What about an isochronous endpoint?  I'm guessing it won't be equal to the total number of bytes of isochronous 
> headers plus frame data plus padding.
>
> > Just to note, it may be acceptable for a device to send less than the amount requested so the values may differ 
> > between a submit and a complete.  For example, a usb ethernet driver could always perform reads of MTU sizes but the 
> > actual amount read will usually be less.
>
> So the submitted request will have an ioLength reflecting the MTU, and the completed request will have an ioLength 
> reflecting the actual packet size.  That's not unexpected.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers