Age | Commit message (Collapse) | Author |
|
it to let the main process to prepare new listening sockets (socket() and
bind()) on behalf of the session engine, which of course cannot bind() to
ports < 1024 any more once it dropped privileges. with some help from theo,
claudio ok
|
|
we used a ststic one with OPEN_MAX entries, which is a rather arbitary limit
as OPEN_MAX is _not_ the max # of open fds we can have, but just a default
for that setting.
in the same move we have to allocate the peer_l array, basically there
for pfd-index to peer pointers to prevent peer list scans all time,
dynamiccaly to. we overallocate a little and use that reserve until we
have to realloc again later to prevent reallocs for every single control
connection or a single flapping peer.
help & ok claudio
|
|
supported address familiy, keep a tailq of an arbitary number of them.
the new struct listen_addr contains the sockaddr and the fd.
this fixes quite some nasty behaviour which was a consequence of the previous
model.
looks right deraadt@, and discussed with claudio
|
|
at runtime and disable said subsystems if so. helps the guys porting bgpd
to $otherBSD, and is actually the right thing to do. claudio ok
|
|
|
|
blackhole routes or to make network announcements dependent on a external
state (e.g. for carp setups) OK henning@
|
|
|
|
|
|
2 octets, thus we need to transform it from/to network byte order...
fixes capability announcement and -parsing
|
|
receiving a "unsupported capabilities" notification. Speeds capability
negotiation up quite a bit with peers that like to whine about caoabilities
they don't understand
|
|
|
|
but only of tcp md5sig or ipsec is in use. excellent idea by ryan some time
ago, claudio and theo agree
|
|
write buffers are cleared, but there could be imsgs from the RDE for that peer
(e. g. UPDATEs) in the read buffers for the pipe to the RDE or buffered in
the RDE or somesuch. Thus, in session_update(), explicitely check for the
session state and just drop the message if the session is not in state
ESTABLISHED.
claudio ok
|
|
|
|
|
|
to send a NOTIFICATION and thus ternminating the session when it sees a
capability it doesn't support (who would guess: zebra does so), parse the
data section of the notifcication to find out what what capabilties it didn't
like and do not advertise them the next time the session gets up. In case we
get a notification about unsupported capabilities with an empty data part
(don't ask for RFCs... and guess who does that), disable capabilty announcement
alltogether.
claudio ok
|
|
|
|
add a generic "method" field that expresses what method
(none/md5sig/ipsec manual/ipsec ike) is in use
markus ok
|
|
|
|
|
|
|
|
|
|
process incoming route refresh request and notify the RDE
not advertised via capabilities yet, claudio ok
|
|
|
|
this implies ourgoing capabilities annoucnement is there and just needs the
values to be filled in for other shitz we'll support soonish
|
|
|
|
so noop
|
|
message for cloned neighbors, claudio ok
|
|
|
|
|
|
instead of the neighbor's IP address. WHen a connection comes in matching
that mask we clone the neighbor spec.
IPv6 match code by itojun, rde feeding by claudio, ok claudio
|
|
on inet only kernels again, claudio ok
|
|
for IPv6 transport
parts based on a diff from Brent Graveland
ok itojun@ claudio@
|
|
|
|
|
|
the peer struct, claudio ok
|
|
|
|
to the peer, and we get a connection from exactly that peer, we used to
refuse it (because we already had a - tho only half-open - connection).
this diff changes that so that the connection request from the neighbor is
preferred in only that specific case, and the existing half-open connection
is teared down. this can speed up session re-establishment quite a bit,
especially with multihop.
claudio ok
|
|
(lives in /var/run, i. e. outside chroot) and privdrop.
claudio ok
|
|
claudio ok
|
|
|
|
|
|
the members after fork
|
|
|
|
the list entries and the head there after forking
|
|
pipes and clear buffers afterwards
|
|
|
|
this includes handling "unsupported optional parameter" notifications from the
peer and retrying without capability announcement. claudio ok
|
|
|
|
RFC 3392. we don't support any capability yet but this at least avoids one
session teardown and reestablishment when talking to peers which do support
capability announcement (as in: basically any) and we'll start supporting
some soon.
|