tcpdump mailing list archives

Re: Failing tcpdump 4.5.1 testsuite


From: Guy Harris <guy () alum mit edu>
Date: Mon, 3 Feb 2014 00:46:59 -0800


On Dec 11, 2013, at 12:22 PM, Guy Harris <guy () alum mit edu> wrote:

On Dec 1, 2013, at 3:32 AM, Romain Francoise <romain () orebokech com> wrote:

- the nflog-e testcase requires a little-endian host, the NFLOG TLV
length is in host byte order and the capture file was generated on a
little-endian machine, so it can't be read successfully on a
big-endian build host.

That means that the libpcap code should, if the byte order of the host that generated (that section of) the file is 
different from the byte order of the host on which the code is running, byte-swap the TLVs.

Which, as of some recent checkins on the trunk and 1.5 branch, it now does.

If the TLV *data* is in host byte order

From a quick look at the Linux kernel code, it's not - it's either

        1) a character string that's neither UCS-2 or UTF-16 nor UCS-4;

        2) a big-endian value or a structure containing big-endian values;

        3) a link-layer header from a packet;

        4) the stuff in a packet following the link-layer header;


and:

        the byte order doesn't matter for 1);

        the byte order is standardized for 2);

        the byte order is specified by the protocol standard for 3) and 4), and if there's a case where there's a 
problem, it's also a problem with regular network traffic of that type.

So the problem should be solved with the libpcap code on the trunk and in the 1.5 branch.  (I tested that code with the 
latest trunk and 4.5-branch tcpdump, and the regression tests passed on SPARC/Solaris, PA-RISC/HP-UX, and Power 
ISA/AIX.)
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Current thread: