tcpdump mailing list archives

Re: DLT_ request


From: Guy Harris <guy () alum mit edu>
Date: Sat, 7 Jan 2017 18:51:31 -0800

On Dec 12, 2016, at 6:11 PM, Scott Deandrea <sdeandrea () apple com> wrote:

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)

So, for a "submit" request, the frameStatus fields are presumably not meaningful, as they reports the status of the 
completed transfer, right?
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Current thread: