On Dec 11, 2013, at 12:22 PM, Guy Harris <g...@alum.mit.edu> wrote:
> On Dec 1, 2013, at 3:32 AM, Romain Francoise <rom...@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
