Re: Byte ordering for dissectors

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

On Jan 10, 2014, at 12:04 PM, Guy Harris <guy () alum mit edu> wrote:

> On Jan 10, 2014, at 11:21 AM, Jakub Zawadzki <darkjames-ws () darkjames pl> wrote:
>
> > In packet-nflog.c I'm trying to guess endianess (nflog_tvb_byte_order())
>
> Sadly, nflog doesn't have a fixed amount of fixed-format data that is in host byte order, with everything else in a 
> standard byte order, so guessing the byte endianness is the best you can do.

...and, happily, the T and L of the TLV are in host byte order, but the V is either in network byte order, is a string 
in an encoding where byte order doesn't matter, or is raw packet data (if you can't get raw packet data byte order 
right, you have problems with far more than just nflog...), so, as long as the code that reads capture files ensures 
that the type and length in the TLVs are presented to its caller in the host byte order of the machine *reading* the 
file, rather than the byte order indicated by the file header (pcap) or section header block (pcap-ng), there's no need 
to guess the byte order.

Libpcap, as of some recent checkins, ensures that the type and length in the TLVs are presented to its caller in the 
host byte order of the machine reading the file; we need to change libwiretap to do the same thing - see 
pcap_read_post_process() in wiretap/pcap-common.c, where we need to put in a case for WTAP_ENCAP_NFLOG similar to the 
case for WTAP_ENCAP_USB_LINUX and WTAP_ENCAP_USB_LINUX_MMAPPED, with a routine scanning the TLV list byte-swapping the 
type and length.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe