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
>> slightly:
>> struct
>> {
>> //
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 frameHeaderLength; // 28
>
>// Frame information
>uint32_t frameLength; // Amount of da
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/DLT_USB_DARWIN. The changes
> are
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/DLT_USB_DARWIN. The changes are
checked into the master branch of libpcap, so it should appear in a future 1.9
release of libpcap (which macOS 10.1
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?
>
> So here's a draft of the header
On Jan 4, 2017, at 4:19 PM, Scott Deandrea wrote:
> Any update on allocating a DLT value? Perhaps #define DLT_MACOS_USB 266?
So here's a draft of the header format:
http://gharris.users.sonic.net/LINKTYPE_USB_DARWIN.html
It won't look exactly like this, as this doesn't have the www.tc
Okay, I understand what the check you are referring to now. The USB stack
guarantees that those conditions will not happen by doing exactly as you’ve
suggested with BPF.
The vernacular I generally hear and speak would be something similar to using
either “over USB” or “over the bus”.
For a co
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-isochronous pipes will be equal to the amount of data payload transferred
> on the bus. I
Yes, you can think of the lower bits the frame number and the upper bits the
number of overflows.
There isn’t any reason to interpret it as anything other than a 64-bit integer
nor to specify the division.
—scott
> On Jan 5, 2017, at 10:35 PM, Guy Harris wrote:
>
> On Jan 5, 2017, at 10:11 P
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-isochronous pipes will be equal to the amount of data payload transferred
on the bus. I’m not following what/how you would check that. The link-lay
On Jan 5, 2017, 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 frame wrap
> when
On Jan 5, 2017, at 9:59 PM, Scott Deandrea wrote:
> The ioLength for a submitted request will the the amount of data requested in
> the data stage.
So, for a submitted request on the Default Control Pipe, the ioLength won't be
8 for the setup data, it'll be the maximum amount of data requested
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 frame wrap
when scheduling isochronous I/O.
Yes, time *at* which…
—scott
The ioLength for a submitted request will the the amount of data requested in
the data stage. The ioLength for a completed request will be the actual amount
of data transferred in the data stage. It’s quite similar to any other data
pipe.
Just to note, it may be acceptable for a device to sen
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-of-Frame Packets.
So only 11 of the 64 bits are used?
> The ioTimestamp is in the same Mach Absolu
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
>uint8_t headerLength; // length of this structure
>uint8_t requestType; // t
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/x64 though
>> developers won’t
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-of-Frame
Packets.
The ioTimestamp is in the same Mach Absolute Time.
Yes, the way you have described the padding is correct.
—scott
> On Jan 5, 2017, at
On Jan 5, 2017, at 8:48 PM, Scott Deandrea wrote:
> The mach absolute time base is different between ARM and x86/x64 though
> developers won’t have access to packet capture on iOS devices (internally the
> packet capture is used on iOS devices). The developers that would be using
> this softw
The mach absolute time base is different between ARM and x86/x64 though
developers won’t have access to packet capture on iOS devices (internally the
packet capture is used on iOS devices). The developers that would be using
this software capture are familiar with the Mach Absolute Time format
On Dec 13, 2016, at 8:38 AM, Scott Deandrea wrote:
> The timestamps are in Mach Absolute Time Units
> (https://developer.apple.com/library/content/qa/qa1398/_index.html).
That says
This unit is CPU dependent, so you can't just multiply it by a constant
to get a real world value. Rathe
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’t a multiple of 4
Yes, if there are fewer tiers of hubs, the unused nibbles will be zero.
Correct, the padding is only added if frameLength isn’t a multiple of 4. This
should be considered the final version. The timestamps are in Mach Absolute
Time Units (https://developer.apple.com/library/content/qa/qa1398/_i
On Dec 12, 2016, at 6:11 PM, Scott Deandrea wrote:
> The bus number is 0 based and the port numbers are 1 based.
So if there are fewer than 6 ports in the route, the unused nibbles will be
zero.
> I decided to implement isochronous transfers today and changed the structure
> slightly:
> struc
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 packet regardless if the hos
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; // Amoun
On Dec 12, 2016, at 10:21 AM, Scott Deandrea wrote:
> The data is part of the complete packet regardless if the host is sending or
> receiving data to/from the device.
So the only submit packets with data would be packets sent to control
endpoints, which would contain setup data?
_
The bcdVersion field is a version number of the header using the same 0xJJMN
syntax.
The data is part of the complete packet regardless if the host is sending or
receiving data to/from the device.
—scott
> On Dec 11, 2016, at 6:27 PM, Guy Harris wrote:
>
> On Dec 11, 2016, at 8:12 AM, Scott
On Dec 11, 2016, at 8:32 AM, Scott Deandrea 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 generat
On Dec 11, 2016, at 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 JJ.M.N (JJ – ma
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
Hi,
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 JJ.M.N (JJ – major version number, M – minor version
number, N – sub-m
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 to Darwin, or something else? What is the format of a
locationID?
>uint32_t ioFrameCo
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 nibbles represent digits;
is that the case?
> tAppleUSBHostPacketFilterRequestType doesn’t exist in public domain at t
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 t
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 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
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 head
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_
Yes, live serial port capture does sound like a useful
enhancement. However, for now I am going to keep it
file-based and write code that extracts the LLC data
from a log file and outputs it in libpcap. In
conjunction with LLC, RLC/MAC blocks (the next layer
'down' on the air interface side) are be
marc hermstein wrote:
When developing a handset, some manufacturers dump
debugging data from the protocol stack out the serial
port on the bottom of the handset. This is what I
meant by a "logger".
So you'll be writing, or have written, a piece of code that reads from
the serial port and writes to
When developing a handset, some manufacturers dump
debugging data from the protocol stack out the serial
port on the bottom of the handset. This is what I
meant by a "logger".
This feature doesn't get enabled on the production
version of the handset, but a handset with it enabled
will sometimes be
On Dec 6, 2004, at 9:16 AM, marc hermstein wrote:
I would like to request a DLT_ number for usage with
raw GPRS LLC frames (DLT_GPRS_LLC). On a mobile, this
is an output format that some loggers use.
"Loggers" in what sense?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to u
marc hermstein wrote:
I would like to request a DLT_ number for usage with
raw GPRS LLC frames (DLT_GPRS_LLC). On a mobile, this
is an output format that some loggers use. Having it
defined as a possible link-layer type would allow me
to have the GPRS_LLC dissector in ethereal register
with that en
44 matches
Mail list logo
