The added sanity check was: packet length >= capture length.
Thus update packet length to be capture length if lower.
This change is a followup to commit 9e6ba479d8.
Add 3 tests to test that we can properly dissect Broadcom tags. Two are
for DSA_TAG_BRCM where the tag is between Ethernet MAC SA and
Type/Length and one for DSA_TAG_BRCM_PREPEND where the tag is
encapsulating the Ethernet frame (thus requires -e to be shown).
This adds support for decoding the Broadcom Ethernet switches tags which
are are 4byte in length and are located between the Ethernet MAC SA and
the Type/Length field (DSA_TAG_BRCM) as well as the pre-pended Broadcom
tag (DSA_TAG_BRCM_PREPEND) which are located in front of the standard
Ethernet header.
This makes use of the recently introduced ether_print_hdr_len() to allow
specifying the non-standard Ethernet header length of 12 + 4 + 2 bytes.
A fair number of proprietary Ethernet switch tagging protocols, such as
Broadcom tags for instance, will place their tag between the MAC SA and
the Type/Length field.
Move the body of ether_print() into ether_print_hdr_len() and specify
the Ethernet header length as an argument to that function.
ether_print() calls ether_print_hdr_len() with a standard Ethernet
header lenght of 14 bytes, while other callers could specify an
arbitrary length. We still assume that the first Length/Type field to
parse is located 2 bytes before the end of that Ethernet header length.
This will be used in a subsequent commit to parse Broadcom tags.
When using all three switches (-C -G and -W), the behavior is
practically identical to only using -C and -G, as the -W flag will only
affect the filename suffix.
Fixes#695
Mostly, we just throw in casts of values already known to be in the
range of values supported by the lvalue's type to that type.
Also, for the IPX SAP table, we make the SAP value a uint16_t, as SAP
values are 16-bit.
Make a hash table index unsigned, Just Because.
This means we get the same behavior in Turkish locales (where, if we
aren't in the C locale, we might get lower-case "i" mapped to upper-case
"I with dot" and upper-case "I" mapped to lower-case "i without dot),
and may also suppress some shortening warnings from MSVC.
This reverts commit 76ed0bb392.
It doesn't help.
We may just want to suppress the warning, as in "trust us, we know what
we're doing", although it'd be nice if the format string passed to those
functions could be checked to make sure it is one that takes exactly one
integer argument.
Declare the format-string argument to tok2strbuf(), tok2str(),
bittok2str(), and bittok2str_nosep() as such, to see whether that gets
MSVC not to complain - or if it just gets upset because there's no "..."
argument list for it.
Make the count of 2-octet values to dump an unsigned value.
Make the variables into which we fetch those octets unsigned as well.
Cast the result of the "is the character printable ASCII? If so, it's
the character, otherwise it's '.'" to char, to squelch narrowing
warnings.
We're returning the calculated checksum result modulo 65536, given that
Internet checksums are 16-bit; throw in a cast to let MSVC know that
this is intended.
Clamp the on-the-wire length values of the packets at 262144, so that we
hand the packets to the BFD printer, rather than just bailing out before
we ever get there.
This reverts commit b7fff70582 (partially)
The sanity check in print.c/pretty_print_packet() function, packet length
(length) >= capture length (caplen), apply when the ether_print()
function is called by ether_if_print(), netanalyzer_if_print() or
netanalyzer_transparent_if_print().
But the ether_print() function is called in some other cases, thus not
sure length always >= caplen.
Apparently, if you have an interface in monitor mode, capturing on the
"any" device can get packets that have a SLL hatype of 803, which is the
ARPHRD_ value for radiotap, and with the payload containing a radiotap
header, followed by an 802.11 header, followed by the 802.11 payload.
Handle that.
