Instead of having the Ethernet-type handler process the VLAN and Alteon
jumbo frame Ethernet type values, process them in the Ethernet (and
Linux cooked-mode) dissectors. This makes it easier for the right MAC
addresses to be printed for those packets.
As part of that, rename ether_encap_print() to ethertype_print() - it
doesn't print encapsulated Ethernet frames, it prints payloads whose
packet type is indicated by an Ethernet type field value - and remove
the no-longer-needed "extracted Ethernet type" argument. That also lets
us eliminate it from the SNAP print routine.
Make ether_print() take a function, and an argument to pass to that
function, as parameters, so that, for example, the ATM LANE printer can
use it and put the LEC ID into the link-layer headeer printout.
Use the EXTRACT_ macros to extract multi-byte integral values from
packets, rather than just dereferencing pointers into the packet; there
is no guarantee that the packet data will be aligned on the right
boundary, and there is no guarantee that, if they're not, a direct
access will work correctly.
Use the EXTRACT_ macros to extract multi-byte integral values from
packets, rather than just dereferencing pointers into the packet; there
is no guarantee that the packet data will be aligned on the right
boundary, and there is no guarantee that, if they're not, a direct
access will work correctly.
In some loops, don't loop just until we get an error, stop when we run
out of data to parse.
Also, add some comments to indicate what we know about lengths at
various points, before we do something with the length that happens to
assume what we know. Add some checks that this auditing found
necessary.
Use ForCES_HDRL, TLV_HDRL, and ILV_HDRL instead of various sizeof's, to
make it clearer what certain tests ensure are true (as, in other cases,
the #defines are subtracted from values that should be, at that point,
ensured not to be less than the #define in question).
Add TCHECK/TCHECK2 calls to make sure we are within the packet boundary
before fetching data. Make some length variables that could in theory
have values that don't fit in 16 bits 32 bits long.
Get rid of blanks before newlines.
There's no guarantee that those values are aligned on the appropriate
boundary, nor is there a guarantee that accessing misaligned values will
behave as desired.
There's no guarantee that those quantities will be properly aligned, nor
is there any guarantee that fetching an improperly-aligned quantity will
work as desired.
Use EXTRACT_16BITS() and EXTRACT_32BITS() to fetch 16-bit and 32-bit
big-endian quantities from the packet, as there's no guarantee that a
given 16-bit quantity will be aligned on a 2-byte boundary or that a
given 32-bit quantity will be aligned on a 4-byte boundary, nor is there
a guarantee that unaligned accesses will succeed (they might trap, or
they might not fetch an unaligned quantity).
When debugging NFS operations one may find it easier to get the actual access
flags decoded rather than having to look up the NFS access flags to find which
permissions were requested by the client.
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The configure script doesn't define BYTE_ORDER, so they can't validly be
compared against BYTE_ORDER; don't leave them around for people to think
they can.
