Merge tcpdump 4.7.4 to head

[pkelsey]

Summary

Following the vendor import and tag of the 4.7.4 dist, I executed the
merge as follows:

1. Merged vendor/tcpdump/dist to head/contrib/tcpdump (there were no

file conflicts)

2. Reviewed the 3-way diff between vendor/tcpdump/4.6.2 (the prior

vendor merge), head/contrib/tcpdump before I merged in 4.7.4, and
head/contrib/tcpdump after I merged in 4.7.4 and verified that no
local changes made since the 4.6.2 merge to head were lost.

3. Restored the local changes made in r272451 and r272653 that were

lost in the merge of 4.6.2 and that are not part of the 4.7.4 dist
(https://lists.freebsd.org/pipermail/svn-src-head/2015-February/067853.html)

4. Added two (u_int) casts to print-isoclns.c to avoid build failure

due to signed/unsigned comparison.

5. In head/usr.sbin/tcpdump/tcpdump, I adjusted Makefile to

include newly added sources and to build print-ip6.c
unconditionally, modified config.h to reflect added/changed
configuration controls in vendor/tcpdump/dist/config.h.in, and
manually merged changes to vendor/tcpdump/dist/tcpdump.1.in into
tcpdump.1.

6. Built and ad-hoc tested it on an 11-CURRENT machine, verifying

basic capture works and that Bug 199568 is resolved. Reviewed man
page changes via 'man tcpdump'.

[hiren]

Thanks a lot for doing this!

[wblock]

Are the local changes FreeBSD-specific? To put it another way, can they be submitted upstream to avoid being lost on the next import? The man page changes look that way, at least.

[pkelsey]

In D3007#59268, @wblock wrote:

Are the local changes FreeBSD-specific? To put it another way, can they be submitted upstream to avoid being lost on the next import? The man page changes look that way, at least.

The man page changes are not local changes, but were merged in from the vendor man page source. I updated item 5 in the summary to clarify this.

The other local changes that I am aware of are:

1. If using capsicum, we also use capsicum DNS. I don't know the backstory here - whether capsicum DNS is available on Linux also and if there has been any attempt to upstream this. It is certainly not in the upstream head.

2. When using capsicum, we add CAP_EVENT the capture file descriptor rights so that the netmap-backed version of libpcap can be used with tcpdump. netmap and capsicum support for Linux exists, so this should be a candidate for upstreaming. This is not currently in the upstream head. I will check with Luigi et al. to see if there has been any attempt to upstream this in the past and what their thoughts are here.

3. The (uint_t) casts I added to print-isoclns.c during this merge so the build did not fail with a signed/unsigned mismatch. I will report this upstream once this merge concludes.

[brooks]

In D3007#59316, @pkelsey wrote:

In D3007#59268, @wblock wrote:

Are the local changes FreeBSD-specific? To put it another way, can they be submitted upstream to avoid being lost on the next import? The man page changes look that way, at least.

The man page changes are not local changes, but were merged in from the vendor man page source. I updated item 5 in the summary to clarify this.

The other local changes that I am aware of are:

1. If using capsicum, we also use capsicum DNS. I don't know the backstory here - whether capsicum DNS is available on Linux also and if there has been any attempt to upstream this. It is certainly not in the upstream head.

2. When using capsicum, we add CAP_EVENT the capture file descriptor rights so that the netmap-backed version of libpcap can be used with tcpdump. netmap and capsicum support for Linux exists, so this should be a candidate for upstreaming. This is not currently in the upstream head. I will check with Luigi et al. to see if there has been any attempt to upstream this in the past and what their thoughts are here.

3. The (uint_t) casts I added to print-isoclns.c during this merge so the build did not fail with a signed/unsigned mismatch. I will report this upstream once this merge concludes.

FreeBSD has been terrible about upstreaming local tcpdump changes. All of these should probably be submitted as pull requests to the tcpdump github.

[brooks]

Looks good to me