On shutdown, interfaces are deleted but if the bfd session
is down we retain the interface pointer. Remove the retained
pointer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Valgrind reports:
2052866-==2052866==
2052866-==2052866== Syscall param sendmsg(msg.msg_name) points to uninitialised byte(s)
2052866:==2052866== at 0x49C8E13: sendmsg (sendmsg.c:28)
2052866-==2052866== by 0x11DC08: bp_udp_send (bfd_packet.c:823)
2052866-==2052866== by 0x11DD76: ptm_bfd_echo_snd (bfd_packet.c:179)
2052866-==2052866== by 0x114C2D: ptm_bfd_echo_xmt_TO (bfd.c:469)
2052866-==2052866== by 0x114C2D: ptm_bfd_echo_start (bfd.c:498)
2052866-==2052866== by 0x114C2D: bs_echo_timer_handler (bfd.c:1199)
2052866-==2052866== by 0x11E478: bfd_recv_cb (bfd_packet.c:702)
2052866-==2052866== by 0x4904846: thread_call (thread.c:1681)
2052866-==2052866== by 0x48CB4DF: frr_run (libfrr.c:1126)
2052866-==2052866== by 0x113044: main (bfdd.c:403)
2052866-==2052866== Address 0x1ffefff3e8 is on thread 1's stack
In ptm_bfd_echo_snd, for the v4 case we were memsetting the v6 memory
then setting the v4 memory. Just fix it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Valgrind reports:
2172861-==2172861==
2172861-==2172861== Syscall param write(buf) points to uninitialised byte(s)
2172861:==2172861== at 0x49B4FB3: write (write.c:26)
2172861-==2172861== by 0x48A4EA0: buffer_write (buffer.c:475)
2172861-==2172861== by 0x4915AD9: zclient_send_message (zclient.c:298)
2172861-==2172861== by 0x12AE08: isis_ldp_sync_state_req_msg (isis_ldp_sync.c:152)
2172861-==2172861== by 0x12B74B: isis_ldp_sync_adj_state_change (isis_ldp_sync.c:305)
2172861-==2172861== by 0x16DE04: hook_call_isis_adj_state_change_hook.isra.0 (isis_adjacency.c:141)
2172861-==2172861== by 0x16EE27: isis_adj_state_change (isis_adjacency.c:371)
2172861-==2172861== by 0x16F1F3: isis_adj_process_threeway (isis_adjacency.c:242)
2172861-==2172861== by 0x13BCCA: process_p2p_hello (isis_pdu.c:283)
2172861-==2172861== by 0x13BCCA: process_hello (isis_pdu.c:781)
2172861-==2172861== by 0x13BCCA: isis_handle_pdu (isis_pdu.c:1700)
Sending of request includes uninited memory at the end of the interface
name string. Fix
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Valgrind reports:
2174600-==2174600==
2174600-==2174600== Syscall param write(buf) points to uninitialised byte(s)
2174600:==2174600== at 0x49C7FB3: write (write.c:26)
2174600-==2174600== by 0x48A4EA0: buffer_write (buffer.c:475)
2174600-==2174600== by 0x4915AD9: zclient_send_message (zclient.c:298)
2174600-==2174600== by 0x12DB97: ospf_ldp_sync_state_req_msg (ospf_ldp_sync.c:114)
2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_if_start (ospf_ldp_sync.c:160)
2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_ism_change (ospf_ldp_sync.c:339)
2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_ism_change (ospf_ldp_sync.c:332)
2174600-==2174600== by 0x12C6A2: hook_call_ospf_ism_change (ospf_ism.c:46)
2174600-==2174600== by 0x12C6A2: ism_change_state (ospf_ism.c:540)
2174600-==2174600== by 0x12C6A2: ospf_ism_event (ospf_ism.c:600)
2174600-==2174600== by 0x4904846: thread_call (thread.c:1681)
When we send the request structure we are sending the whole thing and the
interface name string has junk at the end. Not a big deal, but cleans
up valgrind going wumple on us.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
valgrind is finding:
2141982-==2141982== Conditional jump or move depends on uninitialised value(s)
2141982:==2141982== at 0x11A7A6: eigrp_metrics_is_same (eigrp_metric.c:134)
2141982-==2141982== by 0x120360: eigrp_topology_update_distance (eigrp_topology.c:374)
2141982-==2141982== by 0x124F01: eigrp_get_fsm_event (eigrp_fsm.c:284)
2141982-==2141982== by 0x12519E: eigrp_fsm_event (eigrp_fsm.c:419)
2141982-==2141982== by 0x1206A1: eigrp_topology_neighbor_down (eigrp_topology.c:518)
2141982-==2141982== by 0x11AB3A: eigrp_nbr_delete (eigrp_neighbor.c:178)
2141982-==2141982== by 0x124494: eigrp_finish_final (eigrpd.c:271)
2141982-==2141982== by 0x1245A8: eigrp_finish (eigrpd.c:247)
2141982-==2141982== by 0x124630: eigrp_terminate (eigrpd.c:240)
2141982-==2141982== by 0x11344B: sigint (eigrp_main.c:112)
2141982-==2141982== by 0x48F5F32: quagga_sigevent_process (sigevent.c:130)
Prevent this from happening.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The calling function of ospf_nbr_nbma_lookup_next calls
this function and then immediately returns when it
gets the NULL. Just cleanup a bit more code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
I am not even sure what the goal of this code was in any
way shape fashion or form. But since it's pbr_nht.c
I as the original author should know... But I don't.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Looks like the #if 0 code in this place was for ESI support
on solaris. We do not support solaris anymore. So let's
remove with prejudice.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The #if 0 code in ospfd, has not been compiled since at least
2012. If we are at least 9 years old at this point with no effort
to use or save, we should just get rid of it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Unconfig not resetting the peer-group member allowas_in[afi][safi]
This is causing remote route to be accept.
Signed-off-by: Kishore Kunal <kishorekunal01@broadcom.com>
If we are using a nexthop for a MPLS VPN route make sure the
nexthop is over a labeled path. This new check mirrors the one
in validate_paths (where routes are enabled when a nexthop
becomes reachable). The check is introduced to the code path
where routes are added and the nexthop is looked up.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
In 5a3cf85391 the trailing empty line
following the "show ip(v6) route" header was removed. Restore it for
consistency.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
In test_converge_protocols() use sed to match the "show ip(v6) route"
header and strip it, rather than using tail which requires hardcoding
the expected length of the header (which is subject to change).
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
`valid_command` now causes static analyzer complaints since it no
longer assumes `optarg` is non-NULL. If this was the case then
`valid_command` would return `false` (or 0) because it would mean the
string is empty and doesn't contain the '%s' it expects.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When removing ospfv3 from an interface that has been previously
put into wait state, there is a possible use after free of the
oi because the wait_timer could have been started for the interface.
This is because the wait_timer was not tracked by the interface
and we just created a thread for it without storing the thread
pointer.
Issue: #7932
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
