Re: Two DLT Requests For Bluetooth RF Captures

[Guy Harris <guy () alum mit edu>]

On Feb 16, 2014, at 6:08 PM, Guy Harris <guy () alum mit edu> wrote:

> On Feb 14, 2014, at 7:41 PM, Chris Kilgour <techie () whiterocker com> 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