tcpdump mailing list archives
Re: DLT_ request
From: Scott Deandrea <sdeandrea () apple com>
Date: Mon, 12 Dec 2016 18:11:09 -0800
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
Current thread:
- Re: DLT_ request, (continued)
- Re: DLT_ request Guy Harris (Dec 10)
- Re: DLT_ request Scott Deandrea (Dec 11)
- Re: DLT_ request Guy Harris (Dec 11)
- Re: DLT_ request Scott Deandrea (Dec 12)
- Re: DLT_ request Guy Harris (Dec 12)
- Re: DLT_ request Scott Deandrea (Dec 12)
- Re: DLT_ request Guy Harris (Dec 09)
- Re: DLT_ request Guy Harris (Dec 10)
- Re: DLT_ request Scott Deandrea (Dec 11)
- Re: DLT_ request Guy Harris (Dec 11)
- Re: DLT_ request Scott Deandrea (Dec 12)
- Re: DLT_ request Guy Harris (Dec 12)
- Re: DLT_ request Scott Deandrea (Dec 13)