- dev - lists.frrouting.org

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 16 Jul '20

16 Jul '20

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 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 3 of 3 defect(s) ** CID 1496376: Null pointer dereferences (NULL_RETURNS) /zebra/zebra_rib.c: 1948 in rib_count_installed_nh() ________________________________________________________________________________________________________ *** CID 1496376: Null pointer dereferences (NULL_RETURNS) /zebra/zebra_rib.c: 1948 in rib_count_installed_nh() 1942 } else { 1943 if (CHECK_FLAG(nexthop->flags, NEXTHOP_FLAG_ACTIVE)) 1944 count++; 1945 } 1946 } 1947 >>> CID 1496376: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "rib_get_fib_backup_nhg(re)", which is known to be "NULL". 1948 for (ALL_NEXTHOPS_PTR(rib_get_fib_backup_nhg(re), nexthop)) { 1949 if (CHECK_FLAG(nexthop->flags, NEXTHOP_FLAG_FIB)) 1950 count++; 1951 } 1952 1953 return count; ** CID 1496375: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1496375: Memory - corruptions (OVERRUN) /zebra/zebra_mpls.c: 3408 in mpls_lsp_uninstall() 3402 nhlfe = nhlfe_find(&lsp->nhlfe_list, type, gtype, gate, 3403 ifindex); 3404 if (!nhlfe) 3405 return 0; 3406 3407 if (IS_ZEBRA_DEBUG_MPLS) { >>> CID 1496375: Memory - corruptions (OVERRUN) >>> Overrunning array "buf" of 76 bytes by passing it to a function which accesses it at byte offset 8191 using argument "8192". 3408 nhlfe2str(nhlfe, buf, BUFSIZ); 3409 zlog_debug("Del LSP in-label %u type %d nexthop %s flags 0x%x", 3410 in_label, type, buf, nhlfe->flags); 3411 } 3412 3413 if (CHECK_FLAG(lsp->flags, LSP_FLAG_INSTALLED) || ** CID 1495424: Error handling issues (CHECKED_RETURN) /zebra/zebra_rnh.c: 1190 in send_client() ________________________________________________________________________________________________________ *** CID 1495424: Error handling issues (CHECKED_RETURN) /zebra/zebra_rnh.c: 1190 in send_client() 1184 nhg = NULL; 1185 1186 if (nhg) { 1187 for (ALL_NEXTHOPS_PTR(nhg, nh)) 1188 if (rnh_nexthop_valid(re, nh)) { 1189 zapi_nexthop_from_nexthop(&znh, nh); >>> CID 1495424: Error handling issues (CHECKED_RETURN) >>> Calling "zapi_nexthop_encode" without checking return value (as is done elsewhere 5 out of 6 times). 1190 zapi_nexthop_encode(s, &znh, 1191 0 /* flags */); 1192 num++; 1193 } 1194 } 1195 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Reg: Questions about FRR APIs
by Thilak T 14 Jul '20

14 Jul '20

Hello, community, I am reasonably new to the FRR space and trying to find resources to manage the FRR instance via code. Programmatically access protocol states ( for example, show ip bgp summary) or apply configuration like changing the route-map applied to neighbors, etc. I went through the FRR docs, and I see the VTYSH session touching upon this topic in the context of the shell. How do I get started with an API ( golang, python ) to do what we can do via the vtysh? Thank you in advance for pointing me in the right direction Thanks, Thilak

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 10 Jul '20

10 Jul '20

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 1496314: Null pointer dereferences (REVERSE_INULL) /isisd/isis_circuit.c: 724 in isis_circuit_down() ________________________________________________________________________________________________________ *** CID 1496314: Null pointer dereferences (REVERSE_INULL) /isisd/isis_circuit.c: 724 in isis_circuit_down() 718 #ifndef FABRICD 719 /* send northbound notification */ 720 isis_notif_if_state_change(circuit, true); 721 #endif /* ifndef FABRICD */ 722 723 /* log adjacency changes if configured to do so */ >>> CID 1496314: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "circuit->area" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 724 if (circuit->area && circuit->area->log_adj_changes) { 725 struct isis_adjacency *adj = NULL; 726 if (circuit->circ_type == CIRCUIT_T_P2P) { 727 adj = circuit->u.p2p.neighbor; 728 if (adj) 729 isis_log_adj_change( ** CID 1496313: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1496313: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_bmp.c: 959 in bmp_wrsync() 953 */ 954 if (!bmp->syncrdpos) 955 bmp->syncrdpos = bgp_table_top(table); 956 957 /* look for a valid mid-layer table */ 958 do { >>> CID 1496313: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "bmp->syncrdpos" when calling "bgp_dest_get_bgp_table_info". 959 table = bgp_dest_get_bgp_table_info(bmp->syncrdpos); 960 if (table) { 961 break; 962 } 963 bmp->syncrdpos = bgp_route_next(bmp->syncrdpos); 964 } while (bmp->syncrdpos); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0

Re: [dev] Northbound discussion
by Santosh P K 02 Jul '20

02 Jul '20

Today’s meeting is cancelled as there is not much agenda. Please request for review as all PRs are updated and ready for review. Thanks Santosh P K

1 1

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 01 Jul '20

01 Jul '20

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 1496146: Control flow issues (UNREACHABLE) /bgpd/bgp_main.c: 142 in sighup() ________________________________________________________________________________________________________ *** CID 1496146: Control flow issues (UNREACHABLE) /bgpd/bgp_main.c: 142 in sighup() 136 * that is not setup properly again in bgp_rest. 137 * I see no easy way to do this nor do I see that 138 * this is a desirable way to reload config 139 * given the yang work. 140 */ 141 /* Terminate all thread. */ >>> CID 1496146: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "bgp_terminate();". 142 bgp_terminate(); 143 bgp_reset(); 144 zlog_info("bgpd restarting!"); 145 146 /* Reload config file. */ 147 vty_read_config(NULL, bgpd_di.config_file, config_default); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0

Ubuntu 20.04 package?
by Oliver O'Boyle 30 Jun '20

30 Jun '20

Hello, I'm in need of a package for Ubuntu 20.04. I'm building and will soon be releasing a router VM on this platform for internal use but we have at least 50 of these that will need to be deployed soon. More after that. Is there any chance a package can be released for 20.04 in the next week or so? Regards, Oliver

4 6

Re: [dev] About how the LSA of ospf6d is stored in an LSDB?
by yanhc519 30 Jun '20

30 Jun '20

1 0

回复：[dev] About how the LSA of ospf6d is stored in an LSDB?
by yanhc519 29 Jun '20

29 Jun '20

Hi, all. I am currently reading the source code of ospf6d. I found it hard to understand the link state data base (LSDB) part. After some digging, I make some conclusions as follows. Could anyone tell me whether my understanding is right or not? The lib/table.c implements some kind of Trie. I guess it is Patricia Trie, am I right? I make some search about Trie and found that LSDB use some parameters of link state advertisement (LSA) as the key to store each LSA into the Trie. The key is constituted by 2 byte type + 4 byte adv_router and 4 byte link state ID and totally 80 bit. (ospf6_lsdb_add() in ospf6_lsdb.c) The key is stored in a prefix_ipv6 structure. In summary, the LSDBuses route table in lib/table.c to store the LSA and also borrow the prefix_ipv6 structure to store the key. The lib/table.c not only stores the route for a route table, but also stores LSA for an LSDB. Am I right? ps. I don't know why the email I sent do not have the text and the dev Archives display "An HTML attachment was scrubbed...". So I reply the thread with the text again. Sorry for bother you. Thanks. York. ------------------------------------------------------------------ 发件人：yanhc519 via dev <dev(a)lists.frrouting.org> 发送时间：2020年6月29日(星期一) 21:48 收件人：dev(a)lists.frrouting.org <dev(a)lists.frrouting.org> 主　题：[dev] About how the LSA of ospf6d is stored in an LSDB? _______________________________________________ dev mailing list dev(a)lists.frrouting.org https://lists.frrouting.org/listinfo/dev

1 0

About how the LSA of ospf6d is stored in an LSDB?
by yanhc519 29 Jun '20

29 Jun '20

1 0

ODL BGPCEP Magnesium Retrospective and Roadmap for Aluminium presentation
by olivier.dugeon＠orange.com 24 Jun '20

24 Jun '20

Dear all, As promise during the telco meeting, here it is the indication to join my talk on PCE during the LFN virtual Developer Day Forum event. I will present what has been develop and possible cooperation with FRR to automate OpenDayLight tests. Regards Olivier -- What: ODL BGPCEP Magnesium Retrospective and Roadmap for Aluminium When: Thu Jun 25 2020 from 14:00 to 15:00 (Time zone: Paris) Calendar: LFN Events > Virtual Developer & Testing Form > Cross-Community, LFN Events > Virtual Developer & Testing Form > OpenDaylight Who: Olivier Dugeon Meeting Link: https://zoom.us/j/96665493200 Minutes: https://wiki.opendaylight.org/x/IAsF Description: This retrospective will present a quick overview of PCE new functionalities introduced in Magnesium. In particular the Graph model and Path Computation Algorithms that enable full support of RFC5440. It will be followed by a short demo of new features. Then, roadmap to upcoming features for Aluminium release will be presented. Meeting ID: 966 6549 3200 Find your local number: https://zoom.us/u/acvVzQ7WiV Link: https://teamup.com/event/show/id/Kd9jTADTPqLnjLNoZnek7k2FT9NG61 Event exported from Teamup

1 0