Put mptcp.h into the release tarball.
Fix MPTCP support

Added:
 * option length check
 * option type and TCP flags check
 * more information printed

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix some compiler warnings from the previous checkin.
Avoid bitfields, unaligned accesses, packed structures, and PRI[ux]{16,32}.

Bitfields are not one of C's shining points.  There is *NO* guarantee in
what order bitfields are put within a structure - it's *NOT* necessarily
the same as the byte order of the machine, and it's *ESPECIALLY* not
guaranteed to be correlated with the value of the LBL_ALIGN definition
(that definition has to do with whether unaligned accesses are supported
by the hardware).  In addition, even if they're declared as unsigned,
that doesn't mean they're guaranteed to *be* unsigned.  Don't use them.

Unaligned accesses are not guaranteed to work, and fields in packets are
not guaranteed to be naturally aligned.  Use the EXTRACT_nBITS() macros.

__attribute((packed))__ is a GCCism, and is not guaranteed to be
supported by all compilers with which tcpdump can be compiled.  Make
integral fields > 1 byte arrays of u_int8_t's (which also lets us avoid
the & in the EXTRACT_nBITS() macros).

Some systems don't define the PRI[doux]16 and PRI[doux]32 macros, and
others define them infelicitously (i.e., for PRI[doux]32, with an "l";
our 32-bit integer types are *not* longs, as we don't care about
16-bit-"int" platforms).
Fix off-by-one error in print-rx.c

Avoid dereferencing rx_cache[RX_CACHE_SIZE], which is one past the last
valid element.

(This fixes SF bug 3599633 / GH bug 287. I could not identify the name
or email address of the original contributor. -- Denis)
fix year for 4.3.0 in CHANGES
unset executable bit on a few .h and .c files
DHCPv6 decoder update
- Rename option 31 as SNTP_SERVERS (see RFC4075)
- Add decoder for option 56 (NTP_SERVER) from RFC5908
.gitignore: add autom4te.cache/
Not all platforms on which we compile define PRI[doux]16.

So don't use it; it's not necessary on any of the platforms on which we
work.  (The *only* ones that are needed are PRI[doux]64, because
sometimes you need %ll[doux], sometimes you need %l[doux], and with MSVC
you need whatever its run-time library requires.)
Rename a variable to attempt to fix an AIX compile error.

On AIX 5.1, at least when compiling with xlc, the statement

       struct mp_remove_addr *rem_addr = (struct mp_remove_addr *) opt;

gets a complaint "Syntax error: possible missing '{'?"

"/usr/include/sys/xmem.h" #defines rem_addr; I've no idea whether we're
indirectly including that, but maybe we are and maybe that's causing the
problem.
fix bug #303 (DLT_IEEE802_11_RADIO ext. bitmaps)

This bug was discovered and pinned down by Wim Torfs.

The code in question handles DLT_IEEE802_11_RADIO datalink type, which
consists of a variable-sized header, a variable number of fields and the
actual 802.11 frame. The integers contained in the fields are aligned,
properly extracting them is exactly the purpose of the existing "cpack"
module. The issue with the current code is that it sets alignment base
for cpack at the end of the variable-sized header, in other words,
64-bit integers would be properly extracted only so long as the header
is 64-bit long, which only happens when the total number of bitmaps in
it is odd (the minimum number of bitmaps is one). Once this condition
isn't met, as is with two bitmaps, decoding becomes incorrect. The
reporter's point that the alignment base must be the beginning of the
variable-sized header is accurate.

This commit adds a new cpack_advance() function to fast-forward the
"c_next" pointer of a cpack_state context by an arbitrary number of
octets. The ieee802_11_radio_print() function now uses it to skip the
header and all its bitmaps, and the alignment base is now the header
start.
new test for DLT_IEEE802_11_RADIO w/ext. bitmap

I modified the mac80211 and ath9k kernel module such that extra
information regarding rssi, etc are available, which is why I needed the
extra bitmap. Capturing the packets is simply a matter of using tcpdump
-i wlan0 -w dumpfile.

Test-file-not-changed-due-to-doing-pulls-in-the-wrong-order-by: Guy Harris <guy@alum.mit.edu>
Fix error in my previous commit.
DHCPv6 decoder update
- In dhcp6opt_print() constify tp
- Add decoder for option 21 (SIP_SERVER_D - RFC3319)
DHCPv6 decoder update (RFC3646, DNS options)
- Add decoder for option 24 (DOMAIN_LIST)
- Rename option 23 as DNS_SERVERS
- Rename option 24 as DOMAIN_LIST
- In dhcp6opt_print() constify dh6o
With .devel, use -W flags iff the compiler supports them.

Don't base the question of whether to use a particular -W flag on
whether we're compiling with GCC or not, and on which version of GCC
we're using; some compilers, such as clang, also support many of those
-W flags.  Base it on whether the compiler complains if we use it (which
means, for clang, that we have to force it to exit with a non-zero exit
status if it doesn't like a flag; otherwise, we'll specify it, and clang
will warn about it on every compile).
Don't try -W flags with HP's C compiler.

HP's C compiler cannot be made to exit with a non-zero exit status when
given an unknown compiler flag, so you can't use that to figure out if a
flag is supported, but it *will* print a warning, which we don't want.

In addition, it doesn't support -W flags for warnings in any case, so
let's not bother with them.
Get rid of extra blank line.
Support dependency generation with some non-GCC compilers.

Also, if we don't support it with a given compiler, have "make depend"
not run mkdep, as it won't do anything useful.