length is >= the value. (In theory, if that check isn't done, the
prefix length will overflow, and, as it's unsigned, that'd make it very
large, and rejected by the other sanity check - but it's cleaner to
check explicitly.)
In decode_rt_routing_info(), fix the checks for the prefix length -
according to draft-marques-ppvpn-rt-constrain-01, the default route
target has a 0-length prefix, and all others have a length between 32
and 96.
Don't make the last statement in a loop a break statement, as that means
the body of the loop will be executed at most once.
When looping over the data in a TCP segment containing BGP packets, loop
until we reach the first of the end of the captured data or the end of
the segment, not just the end of the captured data.
and put it to its new home l2vpn.{c|h}
rework bgp, ldp, lsp-ping to use the common l2vpn_encaps tokenlist
update FILES list to acommodate the recent file additions
CONFED_AS_SET and CONFED_AS_SEQUENCE codepoints have changed;
- rework the SEQ and SET display output in accordance with contemporary
routing software
( AS ) indicates an CONFED AS SEQUENCE segment
{ AS } indicates an AS SET segment
({ AS }) indicates an CONFED AS SET segment
appropriately, and that GNUmakefile and the MSVC++ project file define
it apppriately, as we do with libpcap, rather than defining it in
"interface.h".
Undo the rcsid-shuffling and addition of extra #includes, as we no
longer need to arrange that "interface.h" be included before using _U_
in an RCS ID or copyright.
use "_U_" in the definitions of "rcsid[]", to eliminate
complaints about those variables being unused;
move the definitions after the include of "interface.h", or add
an include of "interface.h", so that "_U_" is defined.
Include "config.h" before including "tcpdump-stdinc.h" in
"missing/datalinks.c".
- additional support for 4-byte AS number format #2
- get rid of lots of copy&paste code ans usage of bittok2str() for flag parsing
- misc cleanups
- replace datap with tptr in the bgp_cap decoder
-
check the header length to make sure it's at least the minimum length,
so we don't, for example, go into an infinite loop if the header length
is 0.
Get rid of some blank lines at the end of the file.
as defined in draft-rosen-vpns-ospf-bgp-mpls-06.xt
- bugfix for reading out the correct router-type field
- better handling (more verbose) display for unknown community formats
A denial of service vulnerability exists in the print-bgp
module in the way IPv4 Withdrawal prefix lengths are validated. If IPv6 is
not enabled, the function decode_prefix4() is called to breakout the
prefix length and network prefix fields of the UPDATE message. In
bgp_update_print, a pointer (i) is incremented with the returned length
and thus traverses all withdrawn routes in the UPDATE message. However, if
the prefix length is > 32, decode_prefix4() returns -1. As the pointer "i"
then decrements, instead of incrementing, an infinite loop is created,
halting any further packet analysis and creating a very nice cpu sponge.
The patch addresses the loop problem, and also intervenes
whenever the length exceeds 32 bits (in IPv4) regardless
of message type:
compile with Sun C, as "interface.h" isn't being included before the
structures are being declared.
Furthermore, in the files that Sun C *can* compile, it doesn't cause Sun
C to generate code that's safe with unaligned accesses, as
"__attribute__" is defined as a do-nothing macro with compilers that
don't support it.
Therefore, we get rid of that tag on the structures to which it was
added, and instead use "EXTRACT_16BIT()" and "EXTRACT_32BIT()" to fetch
16-bit and 32-bit big-endian quantities from packets. We also fix some
other references to multi-byte quantities to get rid of code that tries
to do unaligned loads on platforms that don't support them.
We also throw in a hack that makes those macros use
"__attribute__((packed))" on structures containing only one 16-bit or
32-bit integer to get the compiler to generate unaligned-safe code
rather than doing it by hand. (GCC on SPARC produces the same code that
doing it by hand does; I don't know if GCC on any other big-endian
strict-alignment processor generates better code for that case. On
little-endian processors, as "ntohs()" and "ntohl()" might be functions,
that might actually produce worse code.)
Fix some places to use "%u" rather than "%d" to print unsigned
quantities.
