On Jan 10, 2014, at 12:04 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> On Jan 10, 2014, at 11:21 AM, Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx> 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.