On Dec 12, 2016, at 6:11 PM, Scott Deandrea <sdeand...@apple.com> wrote:
> The bus number is 0 based and the port numbers are 1 based. So if there are fewer than 6 ports in the route, the unused nibbles will be zero. > 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) So the headers and data are interleaved; the padding would presumably be needed only if frameLength isn't a multiple of 4. Is this the final version, or should the format of a payload of a packet for an isochronous endpoint be left unspecified for now until it's finalized? Also, what are the formats of the time stamps? What are the units, and is there a specified origin or are they just relative to an unspecified base time? _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers