> The current versions of
>
> http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html
>
> and
>
> http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html
>
> say "All multi-octet fields are expressed in little-endian format." I
> presume that means that's now
On Feb 16, 2014, at 6:08 PM, Guy Harris wrote:
> On Feb 14, 2014, at 7:41 PM, Chris Kilgour wrote:
>
>> It seems some folks choose little-endian for multi-byte fields and others
>> choose network/big-endian. It there a preference here? Is it acceptable to
>> define these fields as having t
On Feb 14, 2014, at 7:41 PM, Chris Kilgour wrote:
> It seems some folks choose little-endian for multi-byte fields and others
> choose network/big-endian. It there a preference here? Is it acceptable to
> define these fields as having the same endianness as the pcap file header (or
> pcap-n
On Feb 16, 2014, at 2:03 PM, Chris Kilgour wrote:
> There may be editorial changes for typos and the like.
(Speaking of typos, it's "multi-octet", not "multi-octect".)
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.s
On Feb 16, 2014, at 5:02 PM, Chris Kilgour wrote:
> Sure, I will keep hosting these pages.
OK, I've assigned:
LINKTYPE_BLUETOOTH_BREDR_BB/DLT_BLUETOOTH_BREDR_BB - 255
LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR/DLT_BLUETOOTH_LE_LL_WITH_PHDR - 256
and will update the Link-Layer Header Types page soon.
On 02/16/2014 03:32 PM, Guy Harris wrote:
>>
>> [1] http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html
>> [2] http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html
>
> So, at this point, would you rather that tcpdump.org, rather than you, host
> those documents?
>
> I
On Feb 14, 2014, at 7:41 PM, Chris Kilgour wrote:
> The motivation was classic pcap. I was up on pcap-ng, but did not realize
> the pcap format has an updated variant with higher-precision timestamps.
Yup. Use 0xa1b23c4d, rather than 0xa1b2c3d4, as the magic number, as per
http://ww
On Feb 16, 2014, at 2:03 PM, Chris Kilgour wrote:
> I have established the following two documents that I can confirm will not be
> changed in any technically-significant way. There may be editorial changes
> for typos and the like. And, if there are any further libpcap-related
> technical
On 02/14/2014 04:50 PM, Guy Harris wrote:
>
> On Feb 14, 2014, at 4:46 PM, Guy Harris wrote:
>
>> Translating them into the style in the pages under
>> http://www.tcpdump.org/linktypes would be helpful. It avoids worrying about
>> C/C-derived-language data structure names - or anything *else*
On 02/14/2014 04:46 PM, Guy Harris wrote:
>
> What is the "nanosecond offset to pcap timestamp"? pcap-ng lets you specify
> the resolution of time stamps, and even pcap lets you, at least with newer
> versions of libpcap and Wireshark, specify nanosecond resolution with a
> different magic num
On Feb 14, 2014, at 4:46 PM, Guy Harris wrote:
> Translating them into the style in the pages under
> http://www.tcpdump.org/linktypes would be helpful. It avoids worrying about
> C/C-derived-language data structure names - or anything *else* about C and
> languages derived from it - and als
On Feb 14, 2014, at 12:18 PM, Chris Kilgour wrote:
> I'd like to request two LINKTYPE/DLT allocations for RF Bluetooth Captures,
> with the details described here [2].
What is the "nanosecond offset to pcap timestamp"? pcap-ng lets you specify
the resolution of time stamps, and even pcap let
12 matches
Mail list logo
