Re: Two DLT Requests For Bluetooth RF Captures

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

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.

We have examples of all three types of data in pseudo-headers, so there's no obvious precedent for any of {big-endian, 
little-endian, host-that-wrote-the-file-endian}.

If the pseudo-header is extensible and the code to byte-swap the files in libpcap wouldn't be able to handle arbitrary 
extensions, a standard byte order should be used.  In other cases (for example, a fixed-format pseudo-header, or a 
pseudo-header with TLVs where the T and L are host-endian but the V is in a standard byte order, like 
LINKTYPE_BLUETOOTH_LINUX_MONITOR), host-that-wrote-the-file-endian is acceptable.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers