tcpdump mailing list archives

Re: DLT_ request


From: Guy Harris <guy () alum mit edu>
Date: Sun, 11 Dec 2016 18:37:09 -0800

On Dec 11, 2016, at 8:32 AM, Scott Deandrea <sdeandrea () apple com> wrote:

The deviceLocation is an Apple specific property that describes the bus topology to which the device is connected.  
The most significant byte contains the bus number; a unique value given to a host controller and also used when 
generating the interface numbers.  The following nibbles correspond to the port number(s) through which the device is 
connected.  For example:

FaceTime HD Camera (Built-in)@1a110000  <class IOUSBHostDevice, id 0x10000f263, registered, matched, active, busy 0 
(9 ms), retain 24>
The bus number is 0x1a and the camera is connected to port 1 of the hub that is connected to root port 1 on the host 
controller.

So are ports numbered from 0 or from 1?  If I'm reading 8.9.3 "Port Number" correctly:

        The specific port on a hub to which the packet is directed is identified by the value in the Route String Port 
field. When addressing the hub controller then the Port Number field at the hub’s tier level shall be set to zero in 
the Route String. The hub’s downstream ports are addressed beginning with one and count up sequentially.

that would indicate that they're numbered from 1, so that a port number of 0 indicates the end of the route.

The ioFrameCount field, though not currently supported, is intended to be used for isochronous endpoints as their I/O 
model is slightly different in that you pass down a vector describing I/O for multiple USB frames.  On completion you 
would receive the header followed by and ioFrameCount array of isochronous header followed by the packet data.  The 
isochronous header is currently defined as follows:
struct
{
   // Control information
   uint32_t frameHeaderLength;

   // Frame information
   uint32_t frameLength;
   uint64_t frameNumber;
   uint64_t ioTimestamp;
} __attribute__((packed, aligned (sizeof(uint32_t))));

So the frameHeaderLength would be 24 in the current version (the length of that structure), and the data for the first 
frame would start right after the header and go on for array[0].frameLength bytes, with the data for the second frame 
starting right after than and going on for array[1].frameLength bytes, and so on?

Presumably that field would be ignored if the endpoint isn't an isochronous endpoint, right?
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Current thread: