Re: [tcpdump-workers] Two DLT Requests For Bluetooth RF Captures

2014-02-18 Thread Guy Harris

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 the same endianness as the pcap file header 
>> (or pcap-ng section header)?
> 
> Choosing a standard byte order means that libpcap and Wireshark's Wiretap 
> library don't have to, when reading a capture file, byte-swap fields in the 
> pseudo-header if it's being read on a host with a byte order different from 
> the host that wrote the file being read.
> 
> Using "byte order of the host that wrote the file" means that the code 
> writing the file doesn't have to put the header in a standard byte order.

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 the specification, so libpcap doesn't need to byte-swap 
anything, and programs dissecting those packets should extract the values as if 
they're little-endian.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] Two DLT Requests For Bluetooth RF Captures

2014-02-18 Thread Chris Kilgour
> 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 the specification, so libpcap doesn't need to 
> byte-swap anything, and programs dissecting those packets should extract the 
> values as if they're little-endian.
> 

Yes, I didn't want to break new ground with the former host-endian definition, 
given your earlier statement.  Since BT itself is little-endian oriented, and 
the majority of BT-sniffer users are likely Intel-based, little-endian seems 
the way to go.

And by the way, thanks for the quick turnaround on the DLT allocations.

Chris Kilgour
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers