tcpdump mailing list archives
Re: DLT_ request
From: Scott Deandrea <sdeandrea () apple com>
Date: Fri, 06 Jan 2017 07:44:01 -0800
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 <guy () alum mit edu> wrote: 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
Current thread:
- Re: DLT_ request, (continued)
- Re: DLT_ request Scott Deandrea (Jan 05)
- Re: DLT_ request Guy Harris (Jan 05)
- Re: DLT_ request Scott Deandrea (Jan 05)
- Re: DLT_ request Guy Harris (Jan 05)
- Re: DLT_ request Scott Deandrea (Jan 05)
- Re: DLT_ request Guy Harris (Jan 05)
- Re: DLT_ request Scott Deandrea (Jan 05)
- Re: DLT_ request Scott Deandrea (Jan 05)
- Re: DLT_ request Guy Harris (Jan 05)
- Re: DLT_ request Scott Deandrea (Jan 05)
- Re: DLT_ request Guy Harris (Jan 06)
- Re: DLT_ request Scott Deandrea (Jan 06)
- Re: DLT_ request Scott Deandrea (Jan 08)