Add EXTRACT_U_1() calls as appropriate.
Use EXTRACT_IPV4_TO_HOST_ORDER(), rather than EXTRACT_BE_U_4(), when
extracting an IPv4 mask into host byte order.
Use %u, and u_int, for unsigned values.
Add ISO standard numbers for the protocols in a specification comment up
front.
Add EXTRACT_IPV4_TO_HOST_ORDER() and EXTRACT_IPV4_TO_NETWORK_ORDER();
the former extracts a possibly-unaligned IPv4 address, in network byte
order, returning a uint32_t in host byte order, and the latter extracts
a possibly-unaligned IPv4 address, in network byte order, returning a
uint32_t in *network* byte order. Some APIs take an address in network
byte order, and some operations are more easily done in host byte order,
so both are useful.
Remove the structure wrappers around nd_ipv4 and nd_ipv6; that makes it
easier to pass variables of those types to functions/macros that take a
byte pointer as an argument (because they might be used either with
pointers to structure members or raw buffer pointers), and the structure
probably wouldn't do much to prevent people from using EXTRACT_BE_U_4()
when they really want to extract the value in *network* byte order;
using the above EXTRACT_IPV4_ calls should do more to encourage that.
Use nd_ types for various packet structures, and use EXTRACT_ macros as
necessary. Get rid of & in EXTRACT_ macros if not necessary.
The 1-byte pad RPL suboption is called PAD1, not PAD0, in the RFC.
Rename rpl_dio_printopt() to rpl_printopts() because 1) it's for all RPL
messages and 2) it prints multiple options. Clean up its processing
loop.
Pass rpl_print() the ICMPv6 code, not a pointer to the full header; all
it needs is the code.
Use %u to print unsigned values.
In Node Information node address lists, the TTL comes before the
address, as per the RFC. Dissect it that way.
Thanks for making this hard to test on macOS, Apple. You *could*
continue to ship the headers for libcrypto even if you want to get
everybody to use your Shiny New SSL code rather than Boring Old OpenSSL
- just don't ship the headers for the SSL library - but nooooooo.
When showing a readdir verifier, using big-endian means that it shows
the verifier as a string of 16 octet values, from the first to the last,
which makes sense, and which means that the way we display it is
independent of the byte order of the host running tcpdump, which is a
Good Thing.
When showing a file handle, the same applies, although one could make a
case for not separating the 4-octet words with colons, and just showing
it as a sequence of octets.
Add some RFC numbers.
Structures with nd_ types work well if you overlay them on top of the
packet buffer, but not as well with an on-the-stack structure into which
you copy from the packet, which is ugly if you do *both* with the same
structure. Use overlaying uniformly.
Add EXTRACT_ macros as necessary for the nd_ types.
Make stuff unsigned if it's appropriate.
Use unsigned formats for unsigned values.
A number of routines are passed the length of a payload, so they don't
have to re-fetch that length themselves. That length has been
pre-checked to make sure it's big enough for the payload header; note
that in comments.
Don't copy structures out of the packet, access them in-place using the
EXTRACT_ macros as appropriate, as we already did for some packet types.
Declare the structures using nd_ types.
Rename bgp_header_print() to bgp_pdu_print(), because, after dissecting
and printing stuff from the header, it calls routines to dissect the
body.
The -s default is now large, so it's not as if you'll have to increase
it to get more packet data; you might have to *decrease* it to avoid
dropping packets.