Pass through a bunch of BGP_EVENT_ADD's and make
the code use a proper connection instead of a
peer->connection. There still are a bunch
of places where peer->connection is used and
later commits will probably go through and
clean these up more.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Modify all the receive functions to pass around the actual
connection being acted upon. Modify the collision detection
function to look at the possible two connections.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Modify bgp_fsm_change_status to be connection oriented and
also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection
oriented as well. Attempt to make peer_xfer_conn a bit more
understandable because, frankly it was/is confusing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The usage of BGP_EVENT_FLUSH is unnecessarily abstracting the
call into event_cancel_event_ready and in addtion the macro
was not always being used! Just convert to using the actual
event_cancel_event_ready function directly.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Only attempt to install in netlink iprules that include supported
actions; ignore requests with actions that aren't supported by
netlink.
Signed-off-by: Mark Stapp <mjs@labn.net>
Currently evpn passes into bgp_path_info_cmp the pfx_buf
uninitialized. The bgp_path_info_cmp functionality actually
expects this value to be initialized. Additionally the
evpn section of bgp_path_info_comp was resetting the
new_buf and exist_buf values that were already being
set above to the same values if !debug was on( which
precluded it ever from happening )
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
... by converting the hash table to a typesafe hash.
Honestly I was just looking around for things to convert to the typesafe
hash table code, but then I noticed that cpu_record_clear() deletes
items from inside the hash_iterate() callback :(
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is noted in doc/developer/lists.rst, but judging by the previous
commit that's not where people look for this thing. Let's try a comment
in the header file.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This reverts commit 72eae2c3cb.
`frr_each_const(X, ...)` is not needed since it is the same as
`frr_each(X_const, ...)`.
The fact that it wasn't properly set up for clang-format, and that then
work-arounded with "clang-format off" is all the more reason to not do
this.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
If the kernel sends us bad data then the kind_str
will be NULL and a later strcmp operation will
cause a crash.
As a note: If the kernel is not sending us properly
formated netlink messages then we got bigger problems
than zebra crashing. But at least let's prevent zebra
from crashing.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The `-disable-rr-semantics` or `--enable-rr-senamtics` configure
option is never used. Let's just remove it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Addressed a memory leak in OSPF by fixing the improper deallocation of
area range nodes when removed from the table. Introducing a new function,
`ospf_range_table_node_destroy` for proper node cleanup, resolved the issue.
The ASan leak log for reference:
```
Direct leak of 56 byte(s) in 2 object(s) allocated from:
#0 0x7faf661d1d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7faf65bce1e9 in qcalloc lib/memory.c:105
#2 0x55a66e0b61cd in ospf_area_range_new ospfd/ospf_abr.c:43
#3 0x55a66e0b61cd in ospf_area_range_set ospfd/ospf_abr.c:195
#4 0x55a66e07f2eb in ospf_area_range ospfd/ospf_vty.c:631
#5 0x7faf65b51548 in cmd_execute_command_real lib/command.c:993
#6 0x7faf65b51f79 in cmd_execute_command_strict lib/command.c:1102
#7 0x7faf65b51fd8 in command_config_read_one_line lib/command.c:1262
#8 0x7faf65b522bf in config_from_file lib/command.c:1315
#9 0x7faf65c832df in vty_read_file lib/vty.c:2605
#10 0x7faf65c83409 in vty_read_config lib/vty.c:2851
#11 0x7faf65bb0341 in frr_config_read_in lib/libfrr.c:977
#12 0x7faf65c6cceb in event_call lib/event.c:1979
#13 0x7faf65bb1488 in frr_run lib/libfrr.c:1213
#14 0x55a66dfb28c4 in main ospfd/ospf_main.c:249
#15 0x7faf651c9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s).
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
