Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

Since commit ba281d3d040, ospfd uses NEXTHOP_IPV4_IFINDEX
routes. The API between zebra and bgpd which is used to query
nexthops for recursive routes did not support this nexthop
type and therefore, ospf changes (or any other IGP changes
which use NEXTHOP_IPV4_IFINDEX) would never trigger any
recursive route update.

Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

When neighbor disable-connected-check was used, bgpd would accept routes
with unconnected nexthop as indended, however those routes would be
invalidated on the next bgp_scan run as that function did not know about
disable-connected-check.

Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

switching the socket to blocking may well block the entire bgpd process
for some time if our peer is overloaded (which may well be the original
reason for the NOTIFY)

The error handling is slightly different from the previous ML discussion
on this;  buffer exhaustion isn't technically a fatal TCP error, and we
should probably proceed with FSM actions according to a sent NOTIFY
(adjusting timers) even if we didn't manage to get the NOTIFY onto the
wire.

Acked-by: Leonid Rosenboim <lrosenbo@wrs.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

bgp_interface_down() and bgp_exit() both proceed to delete the address
from bgpd's interface representation, so the second call gets a NULL
result from the hash lookup and subsequently crashes.

Signed-off-by: Rakesh Garimella <rakesh.garimella@sophos.com>
[reformatted]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

Keepalives and updates are not expected in OpenSent, prior to receiving
the peer's open message.  Terminate the session with the proper
notification.

From: Leonid Rosenboim <lrosenbo@wrs.com>
[split off FSM changes, some reordering & cleanup.  read handling needs
 to be separately addressed]
Signed-off-by: David Lamparter <equinox@diac24.net>

By forcing the hash table size to be a power of 2, a potentially
expensive divide can be replaced by a mask operation. Almost all
usage of the hash table was using default size of 1024. Only places
with different size was thread library (1011) and bgp aspath.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

This patch resolves the significance of order of group and password
statements.

It prevents passwords from being lost in cases where all
three conditions apply:
  1. the peer is member of a group with or without group password
  2. the peer has an individual password set
  3. the peer is added to a group within an address-family ipv6
     section

In addition this patch prevents the same issue in cases, where an IPv4
peer's password is set first and the peer is added to a group
afterwards.

Adding a peer to a group cancels his individual password. Without ipv6
this is not a problem, because choosing the right order of config
statements will do (set password only after adding peer to group).

When adding the peer to a group within the address-family
section, his password is definitely lost. The same workaround (ie.
setting the password after the address-family section) can not be used,
because "show run" will print the configuration statements in the wrong
order.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

Commit 8692c50652 introduced a bug where bgpd would crash on
soft-reconfiguration.

This happens e.g. when there are filtered unicast routes because
rn->info is NULL in that case, which the code did not account for.

Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

commit fe9bb64... "bgpd: CVE-2012-1820, DoS in bgp_capability_orf()"
made the length test in bgp_capability_orf_entry() stricter and is now
causing us to refuse (with CEASE) ORF capabilites carrying any excess
data.  This does not conform to the robustness principle as laid out by
RFC1122 ("be liberal in what you accept").

Even worse, RFC5291 is quite unclear on how to use the ORF capability
with multiple AFI/SAFIs.  It can be interpreted as either "use one
instance, stuff everything in" but also as "use multiple instances".
So, if not for applying robustness, we end up clearing sessions from
implementations going by the former interpretation.  (or if anyone dares
add a byte of padding...)

Cc: Denis Ovsienko <infrastation@yandex.ru>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>