Re: DLT_ request

[Scott Deandrea <sdeandrea () apple com>]

Hi Guy,

The bus number is 0 based and the port numbers are 1 based.

I decided to implement isochronous transfers today and changed the structure slightly:
struct
{
    // Control information
    uint32_t frameHeaderLength;  // 28
    
    // Frame information
    uint32_t frameLength;   // Amount of data sent/received this frame
    uint32_t frameStatus;    // IOReturn result of the I/O this frame 
    uint64_t frameNumber; // Frame number on which this was scheduled/executed by the controller
    uint64_t ioTimestamp;  // Time in which the frame completed
} __attribute__((packed, aligned (sizeof(uint32_t))));   

Therefore, the isochronous format for a request with type kAppleUSBHostPacketFilterRequestComplete is as follows:
Link Header
padding, if required to force 4-byte alignment
Isochronous Frame[0] Header (frameHeaderLength bytes in length)
Isochronous Frame[0] Data (frameLength bytes)
…
padding, if required to force 4-byte alignment
Isochronous Frame[linkHeader.ioFrameCount - 1] Header (aligned to 4 bytes, frameHeaderLength bytes in length)
Isochronous Frame[linkHeader.ioFrameCount - 1] Data (frameLength bytes)

The isochronous format for a request with type kAppleUSBHostPacketFilterRequestSubmit is similar (no data following the 
isochronous frame header):
Link Header
padding, if required to force 4-byte alignment
Isochronous Frame[0] Header (frameHeaderLength bytes in length)
…
padding, if required to force 4-byte alignment
Isochronous Frame[linkHeader.ioFrameCount - 1] Header (aligned to 4 bytes, frameHeaderLength bytes in length)

Non-ischronous endpoints will always have an ioFrameCount of 0. 

—scott

> On Dec 11, 2016, at 6:37 PM, Guy Harris <guy () alum mit edu> wrote:
>
> 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