The checksum only covers the header, not the encapsulated packet, so
only checksum that. However, if that checksum fails, try checksumming
the entire packet, as, according to RFC 4601, packets with the entire
packet checksummed should also be accepted, for interoperability.
For unrecognized LLC packets, don't print the raw packet if we've been
told to suppress that.
For unrecognized Ethertype packets, print the Ethertype if we haven't
already done so.
Add IS_NOT_NEGATIVE macro.
Avoid these warnings:
- comparison of unsigned expression >= 0 is always true [-Wtype-limits],
- comparison is always true due to limited range of data type [-Wtype-limits].
Rewrite get_data_src_dst_mac() to test To DS and From DS only once; that
also more clearly means that there's no way to escape from that function
without setting both pointers, so the compiler doesn't think there's a
way to do so.
That let me find what might have been the bulk of the 579(!) instances
of "Deconst" reported in
http://www.cl.cam.ac.uk/~dc552/papers/asplos15-memory-safe-c.pdf
and, hopefully, will prevent more from creeping in.
There are some remaining ones - and they represent attempts to overwrite
the packet bytes handed to tcpdump by libpcap, which could well *fail*
with, for example, memory-mapped capture mechanisms!
We have a choice between "your OS's header files suck" warnings on HP-UX
and -Wcast-qual warnings on all platforms. I vote for the former, as
the latter let us find cases where we're casting constness away, and we
really don't want to cast constness away if we can possibly avoid it.
I'm *guessing* that the item being fetched is big-endian; the "vt"
protocol might be old enough that they developed it on (non-Sun386i) Sun
workstations, assuming they didn't just say "this is an Internet
protocol, hence fields are big-endian").
That also prevents problems on platforms that don't support unaligned
accesses.
*Don't* fetch it with a pointer cast and dereference! That will fail on
little-endian machines and may fail on machines that don't handle
unaligned references.
This header can be used with Marvell switches to direct packets in/out
of a specific port in a tree of interconnected switches. The header
uses its own Ethertype of 0xdada.
By default, only brief output is printed, showing the switch device,
port, and vlan the packet is to/from. However if -e is given, to print
the link-level header, all fields are printed.
This prevents the compiler issue mentioned in GitHub issue #451, and
also cleans up some other signed vs. unsigned stuff.
While we're at it, clean up bittok2str_internal() (just pass it the
separator string, not a Boolean value that's tested to choose the
separator string), and print unknown arguments to the bittok2str
routines in hex, not decimal.
Print them the same way other headers are printed ("src > dst, length l").
For FDDI, always print the frame control field symbolically
For Token Ring, print the AC and FC fields unless the -q flag was given,
just as we do for the FC field for FDDI.
Have llc_print() return the length of the LLC header, plus the length of
the SNAP header, if available - or, if it couldn't dissect the payload,
return the *negative* of that sum. Use that return value in link-layer
printers.
Don't print LLC header information for SNAP packets; if we have a SNAP
header, just call snap_print() and return its return value, regardless
of whether it's 1 or 0, don't fall into the code to print raw LLC header
information - and don't print it with -e, either.
If llc_print() returns 0, just call the default packet printer, don't
print the MAC-layer header or the extracted ethertype - llc_print() will
print the source and destination MAC addresses and whatever type
information is in the LLC or SNAP headers.
If we don't know the DSAP/LSAP, and it's an information frame (numbered
or not) and not an XID frame, return 0, so that we give a hex dump of
the raw payload.
In addition, print the length when printing SNAP header information with
-e.
It's also used for WPA/WPA2, so it's a generic "protected by encryption"
flag. Update the name of the macro that checks it, and report it as
"Protected" rather than "WEP Encrypted".
Have ieee_802_11_hdr_print() unconditionally print the MAC header, call
it before any payload dissection if -e is specified, call it if
llc_print() fails and -e *isn't* specified, and print "WEP Encrypted"
for protected management and control frames if -e isn't specified.
Pull the extraction of source and destination addresses out of
ieee_802_11_hdr_print(), and do it only for data frames, as it's not
needed for management or control frames.
