- dev - lists.frrouting.org

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

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

27 Feb '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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1535272: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1535272: Null pointer dereferences (FORWARD_NULL) /pimd/pim6_mld.c: 2474 in gm_show_if_vrf() 2468 2469 if (js) { 2470 js_if = json_object_new_object(); 2471 json_object_object_add(js_vrf, ifp->name, js_if); 2472 } 2473 >>> CID 1535272: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "tt" to "gm_show_if_one", which dereferences it. 2474 gm_show_if_one(vty, ifp, js_if, tt); 2475 } 2476 2477 /* Dump the generated table. */ 2478 if (!js && !detail) { 2479 table = ttable_dump(tt, "\n"); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Implementation for FRR C based APIs
by Bhanu Priya Bhardwaj 26 Feb '23

26 Feb '23

Hi, The intent of this mail is to use FRR APIs programmatically. We have C as the existing code base. Please suggest how we can integrate FRR APIs into our code. Regards Bhanupriya Bhardwaj DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.

1 0

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

21 Feb '23

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1534617: Uninitialized variables (UNINIT) /bgpd/bgp_rpki.c: 1417 in show_rpki_prefix_magic() ________________________________________________________________________________________________________ *** CID 1534617: Uninitialized variables (UNINIT) /bgpd/bgp_rpki.c: 1417 in show_rpki_prefix_magic() 1411 } 1412 1413 struct pfx_record *matches = NULL; 1414 unsigned int match_count = 0; 1415 enum pfxv_state result; 1416 >>> CID 1534617: Uninitialized variables (UNINIT) >>> Using uninitialized value "as" when calling "pfx_table_validate_r". 1417 if (pfx_table_validate_r(rtr_config->pfx_table, &matches, &match_count, 1418 as, &addr, prefix->prefixlen, 1419 &result) != PFX_SUCCESS) { 1420 if (!json) 1421 vty_out(vty, "Prefix lookup failed\n"); 1422 return CMD_WARNING; ** CID 1534616: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_route.c: 6985 in bgp_static_set_safi() ________________________________________________________________________________________________________ *** CID 1534616: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_route.c: 6985 in bgp_static_set_safi() 6979 bgp_static->valid = 0; 6980 bgp_static->igpmetric = 0; 6981 bgp_static->igpnexthop.s_addr = INADDR_ANY; 6982 bgp_static->label = label; 6983 bgp_static->prd = prd; 6984 >>> CID 1534616: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "rd_str" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 6985 if (rd_str) 6986 bgp_static->prd_pretty = XSTRDUP(MTYPE_BGP, rd_str); 6987 if (rmap_str) { 6988 XFREE(MTYPE_ROUTE_MAP_NAME, bgp_static->rmap.name); 6989 route_map_counter_decrement(bgp_static->rmap.map); 6990 bgp_static->rmap.name = ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0