Hi,

The bcdVersion field is interpreted as described by the bcdUSB field of the 
standard device descriptor in section 9.6.1:
The bcdUSB field contains a BCD version number. The value of the bcdUSB field 
is 0xJJMN for version JJ.M.N (JJ – major version number, M – minor version 
number, N – sub-minor version number), e.g., version 2.1.3 is represented with 
value 0x0213 and version 2.0 is represented with a value of 0x0200.

Yes, for every USB request issued by the host there’s a 
kAppleUSBHostPacketFilterRequestSubmit packet emitted at request time and a 
kAppleUSBHostPacketFilterRequestComplete packet emitted when the request 
completes with the same ioID value.  For control endpoints, the submit packet 
also contains the setup data.  For all other endpoint types, the submit packet 
is only this header.  The complete packet contains any data that was 
transferred.

—scott


> On Dec 10, 2016, at 6:48 PM, Guy Harris <g...@alum.mit.edu> wrote:
> 
> On Dec 9, 2016, at 6:40 PM, Scott Deandrea <sdeand...@apple.com> wrote:
> 
>> For the initial release I’m planning to use 0x0100 for the bcdVersion. 
> 
> So I'm guessing "bcd" implies that either octets or nibbles represent digits; 
> is that the case?
> 
>> tAppleUSBHostPacketFilterRequestType doesn’t exist in public domain at this 
>> point.  It tracks when a request was enqueued and when it completed and it 
>> is defined as follows:
>> enum tAppleUSBHostPacketFilterRequestType
>> {
>>   kAppleUSBHostPacketFilterRequestSubmit   = 0,
>>   kAppleUSBHostPacketFilterRequestComplete = 1
>> };
> 
> So does that mean that, for every USB request issued by the host, there's a 
> kAppleUSBHostPacketFilterRequestSubmit packet emitted at request time and a 
> kAppleUSBHostPacketFilterRequestComplete packet emitted when the request is 
> complete, with the same ioID value, and with each request getting its own 
> ioID value (unless the system has been up long enough to make more than 2^32 
> USB requests...)?
> 
>> The additional information is indeed expected to increase the header length 
>> and bcdVersion should it ever be required.
> 
> So if the bcdVersion is 0x0100, the length should always be 32?
> 
>> Correct, the captured data would be the data field of a usb packet as 
>> described in section 8.3.4.
> 
> So is there a way to determine whether the payload begins with Setup data?  
> Would that be the case for all submitted requests with an endpointType of 
> kEndpointTypeControl (0) and an endpointAddress with an endpoint number of 0 
> (Default Control Pipe)?

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Reply via email to