Re: [tcpdump-workers] DLT_ request
Hi Guy,
Nothing has shipped with any version of macOS yet; indeed I’m trying to avoid
the mistake that was made with DLT_USER2 and PKTAP.
The link-layer header format is as follows:
struct
{
// Control information
uint16_t bcdVersion;// version of this structure
uint8_t headerLength; // length of this structure
uint8_t requestType; // tAppleUSBHostPacketFilterRequestType
// Transfer information
uint32_t ioLength; // amount of data requested/transferred
uint32_t ioStatus; // IOReturn
uint32_t ioFrameCount; // number of isoch frames following
uint64_t ioID; // unique id for this I/O
// Device information
uint32_t deviceLocation;// locationID of the device
uint8_t deviceSpeed; // tEndpointSpeed
uint8_t deviceAddress; // tUSBHostDeviceAddress
uint8_t endpointAddress; // Address and Direction
uint8_t endpointType; // tEndpointType
// Additional information
} __attribute__((packed, aligned(sizeof(uint32_t;
The packet payload is the raw USB data that was sent/received for I/O request.
Thanks,
—scott
> On Dec 7, 2016, at 3:44 PM, Guy Harris wrote:
>
> On Dec 1, 2016, at 10:34 AM, Scott Deandrea wrote:
>
>> We’ve been working to provide developers with a software packet capture
>> solution for USB transfers at Apple. To that end, I have implemented a
>> solution which uses BPF and is libpcap compatible but is currently using the
>> link type DLT_USER15.
>
> (Hopefully that hasn't shipped with any version of macOS, and is only being
> used internally to Apple, so that Apple hasn't repeated the mistake they made
> with DLT_USER2 and PKTAP.)
>
>> Therefore, I’m requesting a DLT_ value for this. Please let me know what
>> the proper procedure is for this
>
> We need a description of the link-layer header for the packets, and an
> indication of what the packet payload is - either a document at Apple we can
> link to, or something we can put into a document hosted on tcpdump.org.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT_ request
On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote:
> The link-layer header format is as follows:
> struct
> {
>// Control information
>uint16_t bcdVersion;// version of this structure
What's the current version? 0, 1, or something else?
>uint8_t headerLength; // length of this structure
Presumably length in bytes.
>uint8_t requestType; // tAppleUSBHostPacketFilterRequestType
So what are the possible values for requestType? (I don't see
tAppleUSBHostPacketFilterRequestType anywhere in the public XNU source or any
header from Xcode.)
>// Transfer information
>uint32_t ioLength; // amount of data requested/transferred
Presumably length in bytes.
>uint32_t ioStatus; // IOReturn
>uint32_t ioFrameCount; // number of isoch frames following
>uint64_t ioID; // unique id for this I/O
>
>// Device information
>uint32_t deviceLocation;// locationID of the device
>uint8_t deviceSpeed; // tEndpointSpeed
Is this an enumerated value, a bits/second value, or something else?
>uint8_t deviceAddress; // tUSBHostDeviceAddress
So that's just a standard 7-bit USB device address, presumably, as per the USB
3.1 spec:
A 7-bit value representing the address of a device on the USB. The
device address is the default address (00H) when the USB device is first
powered or the device is reset. Devices are assigned a unique device address by
the USB system software.
with the 8th bit zero?
>uint8_t endpointAddress; // Address and Direction
So that's the endpoint in the lower 4 bits, and the direction somewhere in the
upper 4 bits? What are the representations for IN and OUT?
>uint8_t endpointType; // tEndpointType
So what are the values for bulk, control, interrupt, and isochronous?
>// Additional information
So the additional information's presence would be indicated by a greater
headerLength and possibly also by a different bcdVersion value?
> } __attribute__((packed, aligned(sizeof(uint32_t;
>
> The packet payload is the raw USB data that was sent/received for I/O request.
So that would be the "data field" from section 8.3.4 "Data Field" from the USB
2.0 spec and the DWORDs following the 16-byte header from the USB 3.1 spec?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT_ request
On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote: > The link-layer header format is as follows: So are multi-byte integral fields in the byte order of the host providing the packets, always in little-endian order (if, for example, Apple were to go Power ISA again, they'd be little-endian even on those machines...), or always in big-endian order? (I.e., does the code that's generating these packets explicitly put them into a particular byte order or does it just put them into the header in the host byte order?) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT_ request
Hi Guy,
For the initial release I’m planning to use 0x0100 for the bcdVersion. All
length values are in bytes.
tAppleUSBHostPacketFilterRequestType doesn’t exist in public domain at this
point. It tracks when a request was enqueued and when it completed and it is
defined as follows:
enum tAppleUSBHostPacketFilterRequestType
{
kAppleUSBHostPacketFilterRequestSubmit = 0,
kAppleUSBHostPacketFilterRequestComplete = 1
};
The deviceSpeed is an enumerated value defined in IOUSBHostFamily.h
enum
{
kUSBHostConnectionSpeedLow = 0,
kUSBHostConnectionSpeedFull = 1,
kUSBHostConnectionSpeedHigh = 2,
kUSBHostConnectionSpeedSuper= 3,
kUSBHostConnectionSpeedSuperPlus= 4,
kUSBHostConnectionSpeedCount= 5
};
The deviceAddress is the 7-bit USB device address as you described.
The endpointAddress encodes both number and direction in the same manor as the
bEndpointAddress field of an endpoint descriptor as described in section 9.6.6
of the USB 2.0 spec.
The endpointType is an enumerated value defined in IOUSBHostFamily.h and
corresponds to the transfer type portion of the bmAttributes field of an
endpoint descriptor.
enum tEndpointType
{
kEndpointTypeControl= (kEndpointDescriptorTransferTypeControl >>
kEndpointDescriptorTransferTypePhase),
kEndpointTypeIsochronous= (kEndpointDescriptorTransferTypeIsochronous
>> kEndpointDescriptorTransferTypePhase),
kEndpointTypeBulk = (kEndpointDescriptorTransferTypeBulk >>
kEndpointDescriptorTransferTypePhase),
kEndpointTypeInterrupt = (kEndpointDescriptorTransferTypeInterrupt >>
kEndpointDescriptorTransferTypePhase)
};
which evaluates to:
enum tEndpointType
{
kEndpointTypeControl = 0,
kEndpointTypeIsochronous = 1,
kEndpointTypeBulk= 2,
kEndpointTypeInterrupt = 3
};
The additional information is indeed expected to increase the header length and
bcdVersion should it ever be required.
Correct, the captured data would be the data field of a usb packet as described
in section 8.3.4.
Finally, the multi-byte fields are currently enforced to be little-endian but
this can be changed to big or host if desired.
—scott
> On Dec 9, 2016, at 5:40 PM, Guy Harris wrote:
>
> On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote:
>
>> The link-layer header format is as follows:
>> struct
>> {
>> // Control information
>> uint16_t bcdVersion;// version of this structure
>
> What's the current version? 0, 1, or something else?
>
>> uint8_t headerLength; // length of this structure
>
> Presumably length in bytes.
>
>> uint8_t requestType; // tAppleUSBHostPacketFilterRequestType
>
> So what are the possible values for requestType? (I don't see
> tAppleUSBHostPacketFilterRequestType anywhere in the public XNU source or any
> header from Xcode.)
>
>> // Transfer information
>> uint32_t ioLength; // amount of data requested/transferred
>
> Presumably length in bytes.
>
>> uint32_t ioStatus; // IOReturn
>> uint32_t ioFrameCount; // number of isoch frames following
>> uint64_t ioID; // unique id for this I/O
>>
>> // Device information
>> uint32_t deviceLocation;// locationID of the device
>> uint8_t deviceSpeed; // tEndpointSpeed
>
> Is this an enumerated value, a bits/second value, or something else?
>
>> uint8_t deviceAddress; // tUSBHostDeviceAddress
>
> So that's just a standard 7-bit USB device address, presumably, as per the
> USB 3.1 spec:
>
> A 7-bit value representing the address of a device on the USB. The
> device address is the default address (00H) when the USB device is first
> powered or the device is reset. Devices are assigned a unique device address
> by the USB system software.
>
> with the 8th bit zero?
>
>> uint8_t endpointAddress; // Address and Direction
>
> So that's the endpoint in the lower 4 bits, and the direction somewhere in
> the upper 4 bits? What are the representations for IN and OUT?
>
>> uint8_t endpointType; // tEndpointType
>
> So what are the values for bulk, control, interrupt, and isochronous?
>
>> // Additional information
>
> So the additional information's presence would be indicated by a greater
> headerLength and possibly also by a different bcdVersion value?
>
>> } __attribute__((packed, aligned(sizeof(uint32_t;
>>
>> The packet payload is the raw USB data that was sent/received for I/O
>> request.
>
> So that would be the "data field" from section 8.3.4 "Data Field" from the
> USB 2.0 spec and the DWORDs following the 16-byte header from the USB 3.1
> spec?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
