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:
- Re: Failing tcpdump 4.5.1 testsuite Guy Harris (Feb 03)