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 <g...@alum.mit.edu> wrote: > >> On Jan 5, 2017, at 9:59 PM, Scott Deandrea <sdeand...@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
