BIRD passed string from configuration to openlog(), which kept it
internally. After reconfiguration the old string was freed, therefore
openlog had invalid copy.
Thanks to Chris Caputo for the original patch.
Kernel protocol calls rt_export_merged(), which used @rte_update_pool for
temporary allocations, supposing it is called from other functions from
rt-table.c that handles locking and flushing of the linpool. Therefore,
linpool was not flushed properly and memory leaked.
Add linpool argument to rt_export_merged() and use @krt_filter_lp when
called from kernel protocol.
Thanks to Justin Cattle and Alexander Frolkin for the bugreport.
(Commit squashed and updated by Ondrej Zajicek)
==00:00:00:02.831 2468== Syscall param socketcall.setsockopt(optval) points to uninitialised byte(s)
==00:00:00:02.831 2468== at 0x513BDEA: setsockopt (in /usr/lib/libc-2.23.so)
==00:00:00:02.831 2468== by 0x45C7AF: sk_setup (io.c:1216)
==00:00:00:02.831 2468== by 0x45CDFF: sk_open (io.c:1417)
==00:00:00:02.831 2468== by 0x44B562: rip_open_socket (packets.c:740)
==00:00:00:02.831 2468== by 0x4481A7: rip_iface_locked (rip.c:616)
==00:00:00:02.831 2468== by 0x4133E4: olock_run_event (locks.c:177)
==00:00:00:02.831 2468== by 0x45A6DE: ev_run (event.c:85)
==00:00:00:02.831 2468== by 0x45A7AD: ev_run_list (event.c:142)
==00:00:00:02.831 2468== by 0x45E0FC: io_loop (io.c:2066)
==00:00:00:02.831 2468== by 0x463B56: main (main.c:845)
==00:00:00:02.831 2468== Address 0xffefffd24 is on thread 1's stack
==00:00:00:02.831 2468== in frame #1, created by sk_setup (io.c:1188)
==00:00:00:02.831 2468== Uninitialised value was created by a stack allocation
==00:00:00:02.831 2468== at 0x45C6BB: sk_setup (io.c:1188)
Add code for manipulation with TCP-MD5 keys in the IPsec SA/SP database
at FreeBSD systems. Now, BGP MD5 authentication (RFC 2385) keys are
handled automatically on both Linux and FreeBSD.
Based on patches from Pavel Tvrdik.
In BIRD, RX has lower priority than TX with the exception of RX from
control socket. The patch replaces heuristic based on socket type with
explicit mark and uses it for both control socket and BGP session waiting
to be established.
This should avoid an issue when during heavy load, outgoing connection
could connect (TX event), send open, but then failed to receive OPEN /
establish in time, not sending notifications between and therefore
got hold timer expired error from the neighbor immediately after it
finally established the connection.
When a kernel route changed, function krt_learn_scan() noticed that and
replaced the route in internal kernel FIB, but after that, function
krt_learn_prune() failed to propagate the new route to the nest, because
it confused the new route with the (removed) old best route and decided
that the best route did not changed.
Wow, the original code (and the bug) is almost 17 years old.
Since 2.6.19, the netlink API defines RTA_TABLE routing attribute to
allow 32-bit routing table IDs. Using this attribute to index routing
tables at Linux, instead of 8-bit rtm_table field.
Symbol lookup by cf_find_symbol() not only did the lookup but also added
new void symbols allocated from cfg_mem linpool, which gets broken when
lookups are done outside of config parsing, which may lead to crashes
during reconfiguration.
The patch separates lookup-only cf_find_symbol() and config-modifying
cf_get_symbol(), while the later is called only during parsing. Also
new_config and cfg_mem global variables are NULLed outside of parsing.
If the number of sockets is too much for select(), we should at least
handle it with proper error messages and reject new sockets instead of
breaking the event loop.
Thanks to Alexander V. Chernikov for the patch.
When a new route was imported from kernel and chosen as preferred, then
the old best route was propagated as a withdraw to the kernel protocol.
Under some circumstances such withdraw propagated to the BSD kernel could
remove the new alien route and thus reverting the import.
When an interface goes down, (Linux) kernel removes routes pointing to
that ifacem but does not send withdraws for them. We rescan the
kernel table to ensure synchronization.
Thanks to Alexander Demenshin for the bugreport.
