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
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/
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?
>
>
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
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
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
> 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-
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
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
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
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
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’
/_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.
>
>
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
[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
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
> 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
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
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:
>
>>
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
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
21 matches
Mail list logo