Certain BGP implementations support 4-byte ASN (see
draft-ietf-idr-as4bytes-13.txt) in the AS_PATH attribute.
Unfortunately there is nothing indicating if 2- or 4-byte ASN
are in use when capturing BGP update packets only; this is
agreed on during the BGP session setup between the peers.
Have modified print-bgp.c in the 3.9.5 tcpdump to use a simple
heuristics:
First check the AS_PATH segments assuming 2-byte ASN.
The check looks at the segment type - which must be a
known one - and uses the segment length to skip to the
next segment. If the overall AS_PATH attribute length
is exactly reached after skipping over all path segments
then the check is passed. In case the 2-byte check
fails we repeat the check assuming a 4-byte ASN. When
this check passes We use 4-byte ASN for the decoding of
the AS_PATH. In all other cases, even a failed/failed
for 2-/4-byte checks, we assume 2-byte ASN for the
decoding.
The procedure for this heuristic check is "check_asnbytes".
In case of 4-byte ASN the ASN is printed in the form
<16-bit>.<16-bit> to provide a clear indication that 4-byte ASN
are in use.
(The draft in question was published as RFC 4893.)
TLVs in decode_labeled_vpn_l2(), but don't format them unless there's
buffer space left. If snprintf() returns a negative value, assume we've
filled up the buffer - I think some platforms used to work that way. If
it returns a value greater than the amount of space left, also assume
we've filled up the buffer.
Fix a typo in a comment.
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".
