Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

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 >uint8_t headerLength; // length of this structure >uint8_t

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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; //

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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,

Re: [tcpdump-workers] DLT_ request

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

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

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

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

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

Re: [tcpdump-workers] DLT_ request

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

[tcpdump-workers] DLT_ request

Hi, 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. Therefore, I’m requesting a DLT_ value for

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

Re: [tcpdump-workers] DLT_ request

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

[tcpdump-workers] DLT_ request

Hello, 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 encapsulation