Failing tcpdump 4.5.1 testsuite

[Romain Francoise]

Hi,

FYI, the tcpdump 4.5.1 testsuite has new two testcases which we may want
to disable by default:
- the pppoes_id testcase requires a pcap version which supports PPPoE
session ID filtering (>= 1.5)
- 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.

Thanks.

[Guy Harris]

Post by Romain Francoise
- 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.

If the TLV *data* is in host byte order, however, I would suggest that libpcap refuse to allow LINKTYPE_NFLOG files to be opened if the byte order of the file (if pcap) or the first section of the file (if pcap-ng) isn't the byte order of the host running the code. Having the host get the byte order by calling pcap_is_swapped() wouldn't be sufficient if, for example, a program running on a host with a different byte order from the byte order of the capture file reads the file and writes out a modified version of the file, unless that program either byte-swaps the file or writes it out with a byte order indication appropriate for the host on which the capture is done.

[Guy Harris]

Post by Guy Harris

Post by Romain Francoise
- 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.

Post by Guy Harris
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.)

[Michael Richardson]

Post by Romain Francoise
- the pppoes_id testcase requires a pcap version which supports PPPoE
session ID filtering (>= 1.5)

True... I'm not sure that we have, up until now, considered this a problem.
Perhaps we should note a minimum pcap version in the test meta-info?

Post by Romain Francoise
- 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.

Okay, so in fact the nflog printing code is broken, period.
How can we get travis-CI to give us a big-endian test machine?!?

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[Romain Francoise]

Post by Michael Richardson
True... I'm not sure that we have, up until now, considered this a problem.

I don't think we've ever had this problem; at least I always update
tcpdump first in Debian (just in case) and this is the first time this
happens.

[Petar]

Post by Romain Francoise

Post by Michael Richardson
True... I'm not sure that we have, up until now, considered this a problem.

I don't think we've ever had this problem; at least I always update
tcpdump first in Debian (just in case) and this is the first time this
happens.
_______________________________________________
tcpdump-workers mailing list
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Should simple C endianess test be done before decoding nflog TVL length?
Is this considered as the solution?