Bug description: frr_init load zebra_fpm.so error. Zebra can't
find function `zfpm_protobuf_encode_route` in symbol table.
Bug trigger condition ( CI have this set ):
./configure --enable-protobuf=no --enable-fpm=yes
/usr/lib/frr/zebra -M fpm
Cause: Macro `HAVE_PROTOBUF` and compile condition variable
`HAVE_PROTOBUF` in `configure.ac ` is not consistent. When
configure `disable-protobuf`, compile condition variable
`HAVE_PROTOBUF` is 0, but the macro is 1. It leads to zebra
load protobuf module, but protobuf module is not linked.
Fix: add a same condition statement to the macro define.
Signed-off-by: 乐倚 <lwb406054@alibaba-inc.com>
The newly created LSA `new` is now properly freed to prevent memory leaks when
a non-self-originated Grace LSA which is not in LSDB is received.
The ASan leak log for reference:
```
Direct leak of 400 byte(s) in 2 object(s) allocated from:
#0 0x7f70e984bd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f70e92481c5 in qcalloc lib/memory.c:105
#2 0x55b35068c975 in ospf6_lsa_alloc ospf6d/ospf6_lsa.c:710
#3 0x55b35068c9f9 in ospf6_lsa_create ospf6d/ospf6_lsa.c:725
#4 0x55b35065ab2c in ospf6_receive_lsa ospf6d/ospf6_flood.c:912
#5 0x55b3506a1413 in ospf6_lsupdate_recv ospf6d/ospf6_message.c:1621
#6 0x55b3506a1413 in ospf6_read_helper ospf6d/ospf6_message.c:1896
#7 0x55b3506a1413 in ospf6_receive ospf6d/ospf6_message.c:1925
#8 0x7f70e92e6ccb in event_call lib/event.c:1979
#9 0x7f70e922b488 in frr_run lib/libfrr.c:1213
#10 0x55b35064345e in main ospf6d/ospf6_main.c:250
#11 0x7f70e8843c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 72 byte(s) in 2 object(s) allocated from:
#0 0x7f70e984bb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f70e9247ee5 in qmalloc lib/memory.c:100
#2 0x55b35068c987 in ospf6_lsa_alloc ospf6d/ospf6_lsa.c:711
#3 0x55b35068c9f9 in ospf6_lsa_create ospf6d/ospf6_lsa.c:725
#4 0x55b35065ab2c in ospf6_receive_lsa ospf6d/ospf6_flood.c:912
#5 0x55b3506a1413 in ospf6_lsupdate_recv ospf6d/ospf6_message.c:1621
#6 0x55b3506a1413 in ospf6_read_helper ospf6d/ospf6_message.c:1896
#7 0x55b3506a1413 in ospf6_receive ospf6d/ospf6_message.c:1925
#8 0x7f70e92e6ccb in event_call lib/event.c:1979
#9 0x7f70e922b488 in frr_run lib/libfrr.c:1213
#10 0x55b35064345e in main ospf6d/ospf6_main.c:250
#11 0x7f70e8843c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 472 byte(s) leaked in 4 allocation(s).
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
```
3 0x00007f423aa42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26
4 0x00007f423aef9740 in core_handler (signo=11, siginfo=0x7fffc414deb0, context=<optimized out>) at lib/sigevent.c:246
5 <signal handler called>
6 0x0000564dea2fc71e in route_set_aspath_prepend (rule=0x564debd66d50, prefix=0x7fffc414ea30, object=0x7fffc414e400)
at bgpd/bgp_routemap.c:2258
7 0x00007f423aeec7e0 in route_map_apply_ext (map=<optimized out>, prefix=prefix@entry=0x7fffc414ea30,
match_object=match_object@entry=0x7fffc414e400, set_object=set_object@entry=0x7fffc414e400, pref=pref@entry=0x0) at lib/routemap.c:2690
8 0x0000564dea2d277e in bgp_input_modifier (peer=peer@entry=0x7f4238f59010, p=p@entry=0x7fffc414ea30, attr=attr@entry=0x7fffc414e770,
afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_UNICAST, rmap_name=rmap_name@entry=0x0, label=0x0, num_labels=0, dest=0x564debdd5130)
at bgpd/bgp_route.c:1772
9 0x0000564dea2df762 in bgp_update (peer=peer@entry=0x7f4238f59010, p=p@entry=0x7fffc414ea30, addpath_id=addpath_id@entry=0,
attr=0x7fffc414eb50, afi=afi@entry=AFI_IP, safi=<optimized out>, safi@entry=SAFI_UNICAST, type=9, sub_type=0, prd=0x0, label=0x0,
num_labels=0, soft_reconfig=0, evpn=0x0) at bgpd/bgp_route.c:4374
10 0x0000564dea2e2047 in bgp_nlri_parse_ip (peer=0x7f4238f59010, attr=attr@entry=0x7fffc414eb50, packet=0x7fffc414eaf0)
at bgpd/bgp_route.c:6249
11 0x0000564dea2c5a58 in bgp_nlri_parse (peer=peer@entry=0x7f4238f59010, attr=attr@entry=0x7fffc414eb50,
packet=packet@entry=0x7fffc414eaf0, mp_withdraw=mp_withdraw@entry=false) at bgpd/bgp_packet.c:339
12 0x0000564dea2c5d66 in bgp_update_receive (peer=peer@entry=0x7f4238f59010, size=size@entry=109) at bgpd/bgp_packet.c:2024
13 0x0000564dea2c901d in bgp_process_packet (thread=<optimized out>) at bgpd/bgp_packet.c:2933
14 0x00007f423af0bf71 in event_call (thread=thread@entry=0x7fffc414ee40) at lib/event.c:1995
15 0x00007f423aebb198 in frr_run (master=0x564deb73c670) at lib/libfrr.c:1213
16 0x0000564dea261b83 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:505
```
With the configuration:
```
frr version 9.1-dev-MyOwnFRRVersion
frr defaults traditional
hostname ip-172-31-13-140
log file /tmp/debug.log
log syslog
service integrated-vtysh-config
!
debug bgp keepalives
debug bgp neighbor-events
debug bgp updates in
debug bgp updates out
!
router bgp 100
bgp router-id 9.9.9.9
no bgp ebgp-requires-policy
bgp bestpath aigp
neighbor 172.31.2.47 remote-as 200
!
address-family ipv4 unicast
neighbor 172.31.2.47 default-originate
neighbor 172.31.2.47 route-map RM_IN in
exit-address-family
exit
!
route-map RM_IN permit 10
set as-path prepend 200
exit
!
```
The issue is that we try to process NLRIs even if the attribute length is 0.
Later bgp_update() will handle route-maps and a crash occurs because all the
attributes are NULL, including aspath, where we dereference.
According to the RFC 4271:
A value of 0 indicates that neither the Network Layer
Reachability Information field nor the Path Attribute field is
present in this UPDATE message.
But with a fuzzed UPDATE message this can be faked. I think it's reasonable
to skip processing NLRIs if both update_len and attribute_len are 0.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Previously when updating vertices, edges and subnets, when no update was required
due to existing value matching the new one, memory associated with the new object
was not being freed leading to memory leaks. This commit fixes memory leak by
freeing memory associated with new object when update is unnecessary.
The ASan leak log for reference:
```
Direct leak of 312 byte(s) in 3 object(s) allocated from:
#0 0x7faf3afbfa37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7faf3ab5dbcf in qcalloc ../lib/memory.c:105
#2 0x7faf3ab42e00 in ls_parse_prefix ../lib/link_state.c:1323
#3 0x7faf3ab43c87 in ls_parse_msg ../lib/link_state.c:1373
#4 0x7faf3ab476a5 in ls_stream2ted ../lib/link_state.c:1885
#5 0x564e045046aa in sharp_opaque_handler ../sharpd/sharp_zebra.c:792
#6 0x7faf3aca35a9 in zclient_read ../lib/zclient.c:4410
#7 0x7faf3ac47474 in event_call ../lib/event.c:1979
#8 0x7faf3ab318b4 in frr_run ../lib/libfrr.c:1213
#9 0x564e044fdc6f in main ../sharpd/sharp_main.c:177
#10 0x7faf3a6f4d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: 312 byte(s) leaked in 3 allocation(s).
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Without this, the Debian package build fails because dplane_sample_plugin.so gets compiled but not installed.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
This is based on @donaldsharp's work
The current code base is the struct bgp_node data structure.
The problem with this is that it creates a bunch of
extra data per route_node.
The table structure generates ‘holder’ nodes
that are never going to receive bgp routes,
and now the memory of those nodes is allocated
as if they are a full bgp_node.
After splitting up the bgp_node into bgp_dest and route_node,
the memory of ‘holder’ node which does not have any bgp data
will be allocated as the route_node, not the bgp_node,
and the memory usage is reduced.
The memory usage of BGP node will be reduced from 200B to 96B.
The total memory usage optimization of this part is ~16.00%.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Yuqing Zhao <xiaopanghu99@163.com>
The code that handles the protodown_rc setting for
VRRP interfaces in zebra is sending a interface
to be set into a protodown state *before* the
interface has been learned by the kernel. Resulting
in crashes when the data plane sends the ctx back
to us saying hey man you are uncool.
Additionally change the protodown code to refuse
to send any protodown_rc codes *until* the interface
has actually been learned about from the kernel.
Ticket: 3582375
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This commit ensures proper cleanup by clearing the `algo->pdst` pointer if it points to a path that is being deleted.
It addresses memory leaks by freeing memory held by `algo->pdst` that might not have been released during the cleanup of processed paths.
The ASan leak log for reference:
```
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7fbffcec9a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fbffca67a81 in qcalloc ../lib/memory.c:105
#2 0x7fbffc9d1a54 in cpath_new ../lib/cspf.c:44
#3 0x7fbffc9d2829 in cspf_init ../lib/cspf.c:256
#4 0x7fbffc9d295d in cspf_init_v4 ../lib/cspf.c:287
#5 0x5601dcd34d3f in show_sharp_cspf_magic ../sharpd/sharp_vty.c:1262
#6 0x5601dcd2c2be in show_sharp_cspf sharpd/sharp_vty_clippy.c:1869
#7 0x7fbffc9afd61 in cmd_execute_command_real ../lib/command.c:993
#8 0x7fbffc9b00ee in cmd_execute_command ../lib/command.c:1052
#9 0x7fbffc9b0dc0 in cmd_execute ../lib/command.c:1218
#10 0x7fbffcb611c7 in vty_command ../lib/vty.c:591
#11 0x7fbffcb660ac in vty_execute ../lib/vty.c:1354
#12 0x7fbffcb6c4aa in vtysh_read ../lib/vty.c:2362
#13 0x7fbffcb51324 in event_call ../lib/event.c:1979
#14 0x7fbffca3b872 in frr_run ../lib/libfrr.c:1213
#15 0x5601dcd11c6f in main ../sharpd/sharp_main.c:177
#16 0x7fbffc5ffd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fbffcec9a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fbffca67a81 in qcalloc ../lib/memory.c:105
#2 0x7fbffca3c108 in list_new ../lib/linklist.c:49
#3 0x7fbffc9d1acc in cpath_new ../lib/cspf.c:47
#4 0x7fbffc9d2829 in cspf_init ../lib/cspf.c:256
#5 0x7fbffc9d295d in cspf_init_v4 ../lib/cspf.c:287
#6 0x5601dcd34d3f in show_sharp_cspf_magic ../sharpd/sharp_vty.c:1262
#7 0x5601dcd2c2be in show_sharp_cspf sharpd/sharp_vty_clippy.c:1869
#8 0x7fbffc9afd61 in cmd_execute_command_real ../lib/command.c:993
#9 0x7fbffc9b00ee in cmd_execute_command ../lib/command.c:1052
#10 0x7fbffc9b0dc0 in cmd_execute ../lib/command.c:1218
#11 0x7fbffcb611c7 in vty_command ../lib/vty.c:591
#12 0x7fbffcb660ac in vty_execute ../lib/vty.c:1354
#13 0x7fbffcb6c4aa in vtysh_read ../lib/vty.c:2362
#14 0x7fbffcb51324 in event_call ../lib/event.c:1979
#15 0x7fbffca3b872 in frr_run ../lib/libfrr.c:1213
#16 0x5601dcd11c6f in main ../sharpd/sharp_main.c:177
#17 0x7fbffc5ffd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Under heavy system load we can see that the static_simple
test is giving up too early in this micronet run:
8-17 15:00:27,105 DEBUG: topo: Waiting for [0.1]s as initial delay
2023-08-17 15:00:27,206 DEBUG: r1: cmd_status("/bin/bash -c 'ip -4 route show'")
2023-08-17 15:00:28,209 DEBUG: r1:
stdout: 101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:28,209 DEBUG: topo: checking kernel routing table:
101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:28,210 INFO: topo: Function raised exception: Failed to find
'10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20'
in
'101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
'
assert None
+ where None = <function search at 0x7f405b7bb0a0>('10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20', '101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1 \n')
+ where <function search at 0x7f405b7bb0a0> = re.search
2023-08-17 15:00:28,210 DEBUG: topo: Sleeping 2s until next retry with 3.0 retry time left
2023-08-17 15:00:30,211 DEBUG: r1: cmd_status("/bin/bash -c 'ip -4 route show'")
2023-08-17 15:00:31,703 DEBUG: r1:
stdout: 101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:31,703 DEBUG: topo: checking kernel routing table:
101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:31,704 INFO: topo: Function raised exception: Failed to find
'10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20'
in
'101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
'
assert None
+ where None = <function search at 0x7f405b7bb0a0>('10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20', '101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1 \n')
+ where <function search at 0x7f405b7bb0a0> = re.search
2023-08-17 15:00:31,704 INFO: topo: Retry timeout of 3s reached
2023-08-17 15:00:31,704 INFO: topo: Spawn collection of support bundle for r1
2023-08-17 15:00:31,704 DEBUG: r1: cmd_status("/bin/bash -c 'mkdir -p /tmp/topotests/static_simple.test_static_simple/r1/support_bundles/test_static_cli'")
2023-08-17 15:00:31,710 DEBUG: r1: popen("/usr/lib/frr/generate_support_bundle.py --log-dir=/tmp/topotests/static_simple.test_static_simple/r1/support_bundles/test_static_cli")
2023-08-17 15:00:31,711 DEBUG: topo: Waiting on support bundle for r1
2023-08-17 15:00:31,751 DEBUG: topo: RETRY DIAG: [failure] Sleeping 2s until next retry with 2.2 retry time left - too see if timeout was too short
2023-08-17 15:00:33,751 DEBUG: r1: cmd_status("/bin/bash -c 'ip -4 route show'")
2023-08-17 15:00:35,137 DEBUG: r1:
stdout: 10.0.0.0/8 nhid 12 via 101.0.0.2 dev r1-eth0 proto 196 metric 20...
2023-08-17 15:00:35,137 DEBUG: topo: checking kernel routing table:
10.0.0.0/8 nhid 12 via 101.0.0.2 dev r1-eth0 proto 196 metric 20
101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
2023-08-17 15:00:35,137 DEBUG: topo: Function returned None
2023-08-17 15:00:35,138 WARN: topo: RETRY DIAGNOSTIC: SUCCEED after FAILED with requested timeout of 3.0s; however, succeeded in 8.0s, investigate timeout timing
2023-08-17 15:00:35,138 INFO: topo: Function raised exception: Failed to find
'10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20'
in
'101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1
'
assert None
+ where None = <function search at 0x7f405b7bb0a0>('10.0.0.0/8(?: nhid [0-9]+)? via 101.0.0.2 dev r1-eth0 proto (static|196) metric 20', '101.0.0.0/24 dev r1-eth0 proto kernel scope link src 101.0.0.1 \n')
+ where <function search at 0x7f405b7bb0a0> = re.search
2023-08-17 15:00:35,138 DEBUG: topo: RETRY DIAG: [failure] Sleeping 2s until next retry with 0.2 retry time left - too see if timeout was too short
2023-08-17 15:00:37,139 DEBUG: r1: cmd_status("/bin/bash -c 'ip -4 route show'")
2023-08-17 15:00:37,247 DEBUG: r1:
stdout: 10.0.0.0/8 nhid 12 via 101.0.0.2 dev r1-eth0 proto 196 metric 20...
Of course it works in the extra couple of times it tries but the test still fails.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Make sure we don't exceed the maximum of BGP_MAX_SOFT_VERSION.
The Capability Length SHOULD be no greater than 64.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Found when fuzzing:
```
==3470861==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xffff77801ef7 at pc 0xaaaaba7b3dbc bp 0xffffcff0e760 sp 0xffffcff0df50
READ of size 2 at 0xffff77801ef7 thread T0
0 0xaaaaba7b3db8 in __asan_memcpy (/home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgpd+0x363db8) (BuildId: cc710a2356e31c7f4e4a17595b54de82145a6e21)
1 0xaaaaba81a8ac in ptr_get_be16 /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/./lib/stream.h:399:2
2 0xaaaaba819f2c in bgp_attr_aigp_valid /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:504:3
3 0xaaaaba808c20 in bgp_attr_aigp /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:3275:7
4 0xaaaaba7ff4e0 in bgp_attr_parse /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:3678:10
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This commit ensures that sequence data
and associated structures are correctly deleted to prevent memory leaks
The ASan leak log for reference:
```
Direct leak of 432 byte(s) in 1 object(s) allocated from:
#0 0x7f911ebaba37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f911e749a4e in qcalloc ../lib/memory.c:105
#2 0x564fd444b2d3 in pbrms_get ../pbrd/pbr_map.c:527
#3 0x564fd443a82d in pbr_map ../pbrd/pbr_vty.c:90
#4 0x7f911e691d61 in cmd_execute_command_real ../lib/command.c:993
#5 0x7f911e6920ee in cmd_execute_command ../lib/command.c:1052
#6 0x7f911e692dc0 in cmd_execute ../lib/command.c:1218
#7 0x7f911e843197 in vty_command ../lib/vty.c:591
#8 0x7f911e84807c in vty_execute ../lib/vty.c:1354
#9 0x7f911e84e47a in vtysh_read ../lib/vty.c:2362
#10 0x7f911e8332f4 in event_call ../lib/event.c:1979
#11 0x7f911e71d828 in frr_run ../lib/libfrr.c:1213
#12 0x564fd4425795 in main ../pbrd/pbr_main.c:168
#13 0x7f911e2e1d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
In scenarios where no backup paths are available, ensure proper
memory management by deleting `q_space->vertex_list`. This prevents
memory leaks.
The ASan leak log for reference:
```
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fcf8c70aa37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fcf8c2a8a45 in qcalloc ../lib/memory.c:105
#2 0x7fcf8c27d0cc in list_new ../lib/linklist.c:49
#3 0x55d6e8385e35 in ospf_spf_init ../ospfd/ospf_spf.c:540
#4 0x55d6e838c30d in ospf_spf_calculate ../ospfd/ospf_spf.c:1736
#5 0x55d6e83933cf in ospf_ti_lfa_generate_q_spaces ../ospfd/ospf_ti_lfa.c:673
#6 0x55d6e8394214 in ospf_ti_lfa_generate_p_space ../ospfd/ospf_ti_lfa.c:812
#7 0x55d6e8394c63 in ospf_ti_lfa_generate_p_spaces ../ospfd/ospf_ti_lfa.c:923
#8 0x55d6e8396390 in ospf_ti_lfa_compute ../ospfd/ospf_ti_lfa.c:1101
#9 0x55d6e838ca48 in ospf_spf_calculate_area ../ospfd/ospf_spf.c:1811
#10 0x55d6e838cd73 in ospf_spf_calculate_areas ../ospfd/ospf_spf.c:1840
#11 0x55d6e838cfb0 in ospf_spf_calculate_schedule_worker ../ospfd/ospf_spf.c:1871
#12 0x7fcf8c3922e4 in event_call ../lib/event.c:1979
#13 0x7fcf8c27c828 in frr_run ../lib/libfrr.c:1213
#14 0x55d6e82eeb6d in main ../ospfd/ospf_main.c:249
#15 0x7fcf8bd59d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Properly free the dynamically allocated memory held by `str` after its use.
The change also maintains the return value of `nb_cli_apply_changes` by using `ret` variable.
The ASan leak log for reference:
```
Direct leak of 55 byte(s) in 2 object(s) allocated from:
#0 0x7f16f285f867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f16f23fda11 in qmalloc ../lib/memory.c:100
#2 0x7f16f23a01a0 in frrstr_join ../lib/frrstr.c:89
#3 0x7f16f23418c7 in argv_concat ../lib/command.c:183
#4 0x55aba24731f2 in set_aspath_exclude_access_list_magic ../bgpd/bgp_routemap.c:6327
#5 0x55aba2455cf4 in set_aspath_exclude_access_list bgpd/bgp_routemap_clippy.c:836
#6 0x7f16f2345d61 in cmd_execute_command_real ../lib/command.c:993
#7 0x7f16f23460ee in cmd_execute_command ../lib/command.c:1052
#8 0x7f16f2346dc0 in cmd_execute ../lib/command.c:1218
#9 0x7f16f24f7197 in vty_command ../lib/vty.c:591
#10 0x7f16f24fc07c in vty_execute ../lib/vty.c:1354
#11 0x7f16f250247a in vtysh_read ../lib/vty.c:2362
#12 0x7f16f24e72f4 in event_call ../lib/event.c:1979
#13 0x7f16f23d1828 in frr_run ../lib/libfrr.c:1213
#14 0x55aba2269e52 in main ../bgpd/bgp_main.c:510
#15 0x7f16f1dbfd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
The BGP FSM was using the peer as the unit of work
but the FSM is connection focused. So let's switch
it over to using that.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
As part of the conversion to a `struct peer_connection` it will
be desirable to have 2 pointers one for when we open a connection
and one for when we receive a connection. Start this actual
conversion over to this in `struct peer`. If this sounds confusing
take a look at the bgp state machine for connections and how
it resolves the processing of this router opening -vs- this
router receiving an open. At some point in time the state
machine decides that we are keeping one of the two connections.
Future commits will allow us to untangle the peer/doppelganger
duality with this abstraction.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The status and ostatus are a function of the `struct peer_connection`
move it into that data structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Move PEER_THREAD_WRITES_ON and PEER_THREAD_READS_ON to
be a part of the `struct peer_connection` since this is
a connection oriented bit of data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Move the peer->t_write and peer->t_read into `struct peer_connection`
as that these are properties of the connection.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
P# Please enter the commit message for your changes. Lines starting
