this. Please
let me know what the proper procedure is for this or if you have any other
questions/concerns.
Regards,
Scott Deandrea
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump
016, 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
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:
>
>>
On Dec 10, 2016, at 6:48 PM, Guy Harris wrote:
>
> On Dec 9, 2016, at 6:40 PM, Scott Deandrea wrote:
>
>> For the initial release I’m planning to use 0x0100 for the bcdVersion.
>
> So I'm guessing "bcd" implies that either octets or nibble
> On Dec 10, 2016, at 7:00 PM, Guy Harris wrote:
>
> On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote:
>
>> uint32_t deviceLocation;// locationID of the device
>
> So is a locationID something defined by a USB specification, by Apple in a
> fashion specific t
t 8:12 AM, Scott Deandrea wrote:
>
>> The bcdVersion field is interpreted as described by the bcdUSB field of the
>> standard device descriptor in section 9.6.1:
>> The bcdUSB field contains a BCD version number. The value of the bcdUSB
>> field is 0xJJMN for version
[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 wrote:
>
> On Dec 11, 2016, at 8:32 AM, Scott Deandrea wrote:
>
>> The deviceLo
Yes, the control endpoint's submit packet contains the 8 byte setup packet
immediately following the link header.
—scott
> On Dec 12, 2016, at 6:09 PM, Guy Harris wrote:
>
> On Dec 12, 2016, at 10:21 AM, Scott Deandrea wrote:
>
>> The data is part of the complete p
/_index.html
<https://developer.apple.com/library/content/qa/qa1398/_index.html>).
—scott
> On Dec 12, 2016, at 9:49 PM, Guy Harris wrote:
>
> On Dec 12, 2016, at 6:11 PM, Scott Deandrea wrote:
>
>> The bus number is 0 based and the port numbers are 1 based.
>
>
Hi Guy,
Any update on allocating a DLT value? Perhaps #define DLT_MACOS_USB 266?
—scott
> On Dec 13, 2016, at 8:38 AM, Scott Deandrea wrote:
>
> Yes, if there are fewer tiers of hubs, the unused nibbles will be zero.
>
> Correct, the padding is only added if frameLength isn’
as it is
the same values returned by the real software stack so I don’t see any need to
change the format to nanoseconds.
—scott
> On Jan 5, 2017, at 8:23 PM, Guy Harris wrote:
>
> On Dec 13, 2016, at 8:38 AM, Scott Deandrea wrote:
>
>> The timestamps are in Mach A
at 8:08 PM, Guy Harris wrote:
>
> On Dec 12, 2016, at 6:11 PM, Scott Deandrea wrote:
>
>> I decided to implement isochronous transfers today and changed the structure
>> slightly:
>> struct
>> {
>> // Control information
>> uint32_t frameHe
Yes, that's the behavior I have implemented in Wireshark and our internal
tools.
--scott
> On Jan 5, 2017, at 8:52 PM, Guy Harris wrote:
>
>> On Jan 5, 2017, at 8:48 PM, Scott Deandrea wrote:
>>
>> The mach absolute time base is different between ARM and x86/x6
c 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
>> uint8_t headerLength; // le
> On Jan 5, 2017, at 9:35 PM, Guy Harris wrote:
>
>> On Jan 5, 2017, at 8:42 PM, Scott Deandrea wrote:
>>
>> The frameNumber is a USB spec defined value that correlates with the
>> start-of-frame packets frame number as defined in section 8.4.3
>> Start-
has no meaning on an isochronous pipe, only the
frameLength is valid (which will be equal to the amount of data that was
transferred).
—scott
> On Jan 5, 2017, at 10:33 PM, Guy Harris wrote:
>
>> On Jan 5, 2017, at 9:59 PM, Scott Deandrea wrote:
>>
>> The ioLength
at 10:11 PM, Scott Deandrea wrote:
>
>> An interrupt is generated when the frame number rolls over and we use this
>> to increment the upper bits so the frame number can grow beyond 11 bits.
>> This allows software consuming the frame number not to worry about the
On Jan 5, 2017, at 11:40 PM, Guy Harris wrote:
>
> On Jan 5, 2017, at 11:22 PM, Scott Deandrea wrote:
>
>> Correct, for a submitted request on the default control pipe is the maximum
>> amount of data requested. The ioLength for a completed request of
>> non-isoc
That draft looks correct and complete to me.
Thanks for your help,
—scott
> On Jan 6, 2017, at 8:34 AM, Guy Harris wrote:
>
> On Jan 4, 2017, at 4:19 PM, Scott Deandrea wrote:
>
>> Any update on allocating a DLT value? Perhaps #define DLT_MACOS_USB 266?
>
>
Excellent, thank you for all your help.
--scott
> On Jan 7, 2017, at 11:49 AM, Guy Harris wrote:
>
>> On Jan 6, 2017, at 10:22 AM, Scott Deandrea wrote:
>>
>> That draft looks correct and complete to me.
>
> OK, I've assigned 266 for LINKTYPE_USB_DARWIN/
Correct, but it will be set to kIOReturnInvalid (0xe001).
--scott
> On Jan 7, 2017, at 6:51 PM, Guy Harris wrote:
>
>> On Dec 12, 2016, at 6:11 PM, Scott Deandrea wrote:
>>
>> I decided to implement isochronous transfers today and changed the structure
21 matches
Mail list logo
