March 2023 - dev - lists.frrouting.org

FRR 8.4 Release
by Jafar Al-Gharaibeh 10 Aug '23

10 Aug '23

Dear FRR Community, We are pleased to announce FRR 8.4 release. Big thanks to all contributors. Packages are available at: Debian Packages - https://deb.frrouting.org RPM Packages - https://rpm.frrouting.org Snaps - https://snapcraft.io/frr Docker - frrouting/frr:v8.4.0 For release notes and a list of notable bug fixes, please visit: https://frrouting.org/release/8.4/ https://github.com/FRRouting/frr/releases/tag/frr-8.4 Cheers, The FRR Development Team!

1 3

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 24 Mar '23

24 Mar '23

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1536876: Null pointer dereferences (NULL_RETURNS) /pimd/pim_zebra.c: 80 in pim_zebra_interface_vrf_update() ________________________________________________________________________________________________________ *** CID 1536876: Null pointer dereferences (NULL_RETURNS) /pimd/pim_zebra.c: 80 in pim_zebra_interface_vrf_update() 74 pim_ifp = ifp->info; 75 if (!pim_ifp) 76 return 0; 77 78 pim_ifp->pim->mcast_if_count--; 79 pim_ifp->pim = pim; >>> CID 1536876: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "pim_ifp->pim", which is known to be "NULL". 80 pim_ifp->pim->mcast_if_count++; 81 82 return 0; 83 } 84 85 #ifdef PIM_DEBUG_IFADDR_DUMP ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Re: [dev] SONIC FRR version @ https://github.com/sonic-net/sonic-frr (v7.0 & 8.2.2)
by Jafar Al-Gharaibeh 24 Mar '23

24 Mar '23

You should bring this up with the SONIC folks, we (FRR maintainers) have no control over their code/tags. --Jafar On 3/10/23 00:09, raja.2001--- via dev wrote: > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 23 Mar '23

23 Mar '23

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 6 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1536832: Memory - corruptions (OVERLAPPING_COPY) /mgmtd/mgmt_history.c: 85 in mgmt_history_create_cmt_rec() ________________________________________________________________________________________________________ *** CID 1536832: Memory - corruptions (OVERLAPPING_COPY) /mgmtd/mgmt_history.c: 85 in mgmt_history_create_cmt_rec() 79 80 new = XCALLOC(MTYPE_MGMTD_CMT_INFO, sizeof(struct mgmt_cmt_info_t)); 81 gettimeofday(&cmt_recd_tv, NULL); 82 mgmt_realtime_to_string(&cmt_recd_tv, new->time_str, 83 sizeof(new->time_str)); 84 mgmt_history_hash(new->time_str, new->cmtid_str); >>> CID 1536832: Memory - corruptions (OVERLAPPING_COPY) >>> In the call to function "snprintf", the object pointed to by argument "new->cmtid_str" may overlap with the object pointed to by argument "new->cmt_json_file". 85 snprintf(new->cmt_json_file, sizeof(new->cmt_json_file), 86 MGMTD_COMMIT_FILE_PATH, new->cmtid_str); 87 88 if (mgmt_cmt_infos_count(&mm->cmts) == MGMTD_MAX_COMMIT_LIST) { 89 FOREACH_CMT_REC (mm, cmt_info) 90 last_cmt_info = cmt_info; ** CID 1536831: Error handling issues (NEGATIVE_RETURNS) /mgmtd/mgmt_be_server.c: 123 in mgmt_be_server_start() ________________________________________________________________________________________________________ *** CID 1536831: Error handling issues (NEGATIVE_RETURNS) /mgmtd/mgmt_be_server.c: 123 in mgmt_be_server_start() 117 118 MGMTD_BE_SRVR_DBG("Started MGMTD Backend Server!"); 119 return; 120 121 mgmt_be_server_start_failed: 122 if (sock) >>> CID 1536831: Error handling issues (NEGATIVE_RETURNS) >>> "sock" is passed to a parameter that cannot be negative. 123 close(sock); 124 125 mgmt_be_listen_fd = -1; 126 exit(-1); 127 } 128 ** CID 1536830: Resource leaks (RESOURCE_LEAK) /mgmtd/mgmt_history.c: 146 in mgmt_history_read_cmt_record_index() ________________________________________________________________________________________________________ *** CID 1536830: Resource leaks (RESOURCE_LEAK) /mgmtd/mgmt_history.c: 146 in mgmt_history_read_cmt_record_index() 140 sizeof(struct mgmt_cmt_info_t)); 141 memcpy(new, &cmt_info, sizeof(struct mgmt_cmt_info_t)); 142 mgmt_cmt_infos_add_tail(&mm->cmts, new); 143 } else { 144 zlog_err("More records found in index file %s", 145 MGMTD_COMMIT_INDEX_FILE_NAME); >>> CID 1536830: Resource leaks (RESOURCE_LEAK) >>> Variable "fp" going out of scope leaks the storage it points to. 146 return false; 147 } 148 149 cnt++; 150 } 151 ** CID 1536829: Error handling issues (NEGATIVE_RETURNS) /mgmtd/mgmt_fe_server.c: 123 in mgmt_fe_server_start() ________________________________________________________________________________________________________ *** CID 1536829: Error handling issues (NEGATIVE_RETURNS) /mgmtd/mgmt_fe_server.c: 123 in mgmt_fe_server_start() 117 118 MGMTD_FE_SRVR_DBG("Started MGMTD Frontend Server!"); 119 return; 120 121 mgmt_fe_server_start_failed: 122 if (sock) >>> CID 1536829: Error handling issues (NEGATIVE_RETURNS) >>> "sock" is passed to a parameter that cannot be negative. 123 close(sock); 124 125 mgmt_fe_listen_fd = -1; 126 exit(-1); 127 } 128 ** CID 1536828: Possible Control flow issues (DEADCODE) /mgmtd/mgmt_txn.c: 1859 in mgmt_txn_get_config() ________________________________________________________________________________________________________ *** CID 1536828: Possible Control flow issues (DEADCODE) /mgmtd/mgmt_txn.c: 1859 in mgmt_txn_get_config() 1853 mgmt_txn_get_config_failed: 1854 1855 if (pending_list) { 1856 /* 1857 * Move the transaction to corresponding pending list. 1858 */ >>> CID 1536828: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (req_list) mgmt_txn_re...". 1859 if (req_list) 1860 mgmt_txn_reqs_del(req_list, txn_req); 1861 txn_req->pending_be_proc = true; 1862 mgmt_txn_reqs_add_tail(pending_list, txn_req); 1863 MGMTD_TXN_DBG( 1864 "Moved Req: %p for Txn: %p from Req-List to Pending-List", ** CID 1536827: Null pointer dereferences (NULL_RETURNS) /mgmtd/mgmt_ds.c: 526 in mgmt_ds_delete_data_nodes() ________________________________________________________________________________________________________ *** CID 1536827: Null pointer dereferences (NULL_RETURNS) /mgmtd/mgmt_ds.c: 526 in mgmt_ds_delete_data_nodes() 520 /* 521 * Return a special error code so the caller can choose 522 * whether to ignore it or not. 523 */ 524 return NB_ERR_NOT_FOUND; 525 /* destroy dependant */ >>> CID 1536827: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "nb_node", which is known to be "NULL". 526 if (nb_node->dep_cbs.get_dependant_xpath) { 527 nb_node->dep_cbs.get_dependant_xpath(dnode, dep_xpath); 528 529 dep_dnode = yang_dnode_get( 530 ds_ctx->config_ds ? ds_ctx->root.cfg_root->dnode 531 : ds_ctx->root.dnode_root, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Re: [dev] Need help to avoid ips getting published in LDP address message
by Renato Westphal 19 Mar '23

19 Mar '23

You can try one of the following commands under the LDP address family node: * *label local allocate for ACCESSLIST_NAME*: use an ACL to select which prefixes should have a local label allocated * *label local allocate host-routes*: allocate labels for host routes only (/32's and /128's) Em sex., 17 de mar. de 2023 às 08:59, Girish Patoliya via dev < dev(a)lists.frrouting.org> escreveu: > > > > ---------- Forwarded message ---------- > From: Girish Patoliya <girishkumar.patoliya(a)mavenir.com> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 17 Mar 2023 11:23:34 +0000 > Subject: Need help to avoid ips getting published in LDP address message > > Hi > > > > I am using FRR version 8.1 for OSPF, LDP & BGP. > I am enabling LDP on interface eth2, however once LDP is operational, it > shares Ips of eth0 & eth1 in address message with “IN USE” as NO. > > I want to completely avoid ips of eth0 & eth1 getting published via LSD > address message. > is there any way ? > > > > Thanks > > Girish > > > ------------------------------ > > This e-mail message may contain confidential or proprietary information of > Mavenir Systems, Inc. or its affiliates and is intended solely for the use > of the intended recipient(s). If you are not the intended recipient of this > message, you are hereby notified that any review, use or distribution of > this information is absolutely prohibited and we request that you delete > all copies in your control and contact us by e-mailing to > security(a)mavenir.com. This message contains the views of its author and > may not necessarily reflect the views of Mavenir Systems, Inc. or its > affiliates, who employ systems to monitor email messages, but make no > representation that such messages are authorized, secure, uncompromised, or > free from computer viruses, malware, or other defects. Thank You > > > > ---------- Forwarded message ---------- > From: Girish Patoliya via dev <dev(a)lists.frrouting.org> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 17 Mar 2023 11:23:34 +0000 > Subject: [dev] Need help to avoid ips getting published in LDP address > message > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > -- Renato Westphal

1 0

Need help to avoid ips getting published in LDP address message
by Girish Patoliya 17 Mar '23

17 Mar '23

Hi I am using FRR version 8.1 for OSPF, LDP & BGP. I am enabling LDP on interface eth2, however once LDP is operational, it shares Ips of eth0 & eth1 in address message with "IN USE" as NO. I want to completely avoid ips of eth0 & eth1 getting published via LSD address message. is there any way ? Thanks Girish ________________________________ This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to security(a)mavenir.com. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects. Thank You

1 0

Weekly FRR YANG Meeting
by Pushpasis Sarkar 13 Mar '23

13 Mar '23

Rescheduling this adjusting for daylight changes. Hi Resending the meeting invite for the weekly YANG meeting. Whoever are interested in the ongoing YANG related work in FRR community, are welcome to join this Bluejeans meeting. https://bluejeans.com/377688464 Thanks and regards, -Pushasis

1 0

SONIC FRR version @ https://github.com/sonic-net/sonic-frr (v7.0 & 8.2.2)
by raja.2001＠yahoo.com 10 Mar '23

10 Mar '23

Hi, We have a copy of FRR code for SONIC at https://github.com/sonic-net/sonic-frr which is dated back to May 2019 (7.0 FRR version) But the tags at https://github.com/sonic-net/sonic-frr/tags indicate 8.2.2 FRR version. Can someone please help clarify if the old copy of FRR code above in SONIC is no longer being used and 8.2.2 is the latest FRR version integrated with SONIC ? If FRR releases from https://github.com/FRRouting/frr/releases are being used for SONIC, it will help to delete the sonic-frr copy of the code to avoid confusion. Thank you Best Regards

1 1

Stop sorting routing table for static routes
by Alireza Arzehgar 07 Mar '23

07 Mar '23

After adding a new static route in the router via vtysh or some shells, FRR will add this route to its routing table. I think everythings stored on `struct route_table`. Using `show ip route` will display sorted routes. Even when we add a new route on configuration, It will store sorted. How can we stop sorting default routes on our router ?

1 0