- dev - lists.frrouting.org

Northbound meeting starting now
by Lou Berger 05 Jun '20

05 Jun '20

Northbound discussion Location: https://bluejeans.com/9192742159 When: Occurs every Friday

1 0

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

05 Jun '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. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1495426: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_mpls.c: 1354 in nhlfe_backup_add() ________________________________________________________________________________________________________ *** CID 1495426: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_mpls.c: 1354 in nhlfe_backup_add() 1348 nhlfe = nhlfe_alloc(lsp, lsp_type, gtype, gate, ifindex, num_labels, 1349 labels); 1350 1351 SET_FLAG(nhlfe->flags, NHLFE_FLAG_IS_BACKUP); 1352 1353 /* Enqueue to LSP, at tail of list. */ >>> CID 1495426: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "nhlfe" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1354 if (nhlfe) 1355 nhlfe_list_add_tail(&lsp->backup_nhlfe_list, nhlfe); 1356 1357 return nhlfe; 1358 } 1359 ** CID 1495425: Memory - corruptions (OVERRUN) /zebra/zebra_mpls.c: 1570 in nhlfe_print() ________________________________________________________________________________________________________ *** CID 1495425: Memory - corruptions (OVERRUN) /zebra/zebra_mpls.c: 1570 in nhlfe_print() 1564 vty_out(vty, " dev %s", 1565 ifindex2ifname(nexthop->ifindex, 1566 nexthop->vrf_id)); 1567 break; 1568 case NEXTHOP_TYPE_IPV6: 1569 case NEXTHOP_TYPE_IPV6_IFINDEX: >>> CID 1495425: Memory - corruptions (OVERRUN) >>> Overrunning array "buf" of 1024 bytes by passing it to a function which accesses it at byte offset 8191 using argument "8192U". 1570 vty_out(vty, " via %s", 1571 inet_ntop(AF_INET6, &nexthop->gate.ipv6, buf, BUFSIZ)); 1572 if (nexthop->ifindex) 1573 vty_out(vty, " dev %s", 1574 ifindex2ifname(nexthop->ifindex, 1575 nexthop->vrf_id)); ** CID 1495424: Error handling issues (CHECKED_RETURN) /zebra/zebra_rnh.c: 1050 in send_client() ________________________________________________________________________________________________________ *** CID 1495424: Error handling issues (CHECKED_RETURN) /zebra/zebra_rnh.c: 1050 in send_client() 1044 num = 0; 1045 nump = stream_get_endp(s); 1046 stream_putc(s, 0); 1047 for (ALL_NEXTHOPS(re->nhe->nhg, nh)) 1048 if (rnh_nexthop_valid(re, nh)) { 1049 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 4 out of 5 times). 1050 zapi_nexthop_encode(s, &znh, 0 /* flags */); 1051 num++; 1052 } 1053 stream_putc_at(s, nump, num); 1054 } else { 1055 stream_putc(s, 0); // type ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0

PCEPlib repo, as mentioned in the telco meeting yesterday
by Brady Johnson 28 May '20

28 May '20

Hello, This is my first email to FRR :) I work for Volta Networks and I am based out of Madrid, Spain. Yesterday in the FRR Telco meeting, Sebastien from Netdef presented the work we have been doing together on the pathd daemon for SR-TE and a PCEP PCC. We mentioned the PCEPlib library that I wrote that pathd links-in for the PCEP protocol communication. We mentioned that we would be upstreaming the PCEPlib library soon. Well, I created a repo in our public github with the PCEPlib code [1] The PCEPlib is LGPL 2 licensed. The PCEPlib has 3 branches: - master (no dev allowed here) - devel (new development here) - devel-1.0 (release branch) The devel-1.0 branch is the latest tested version used with pathd. The devel branch is where new development happens, but it has not been completely tested with pathd yet. When designing and developing the PCEPlib, I had a requirement that it MUST work without FRR, so you will notice that it has its own timers and socket handling. I have new code in the devel branch that allows for callbacks to be plugged-in to the PCEPlib so that it uses memory, timers, and socket infrastructure from FRR. There are more details about this in the README [2]. We can discuss the next steps forward with the PCEPlib when we discuss merging the pathd. Meanwhile, constructive comments are welcome :) Regards, Brady [1] https://github.com/volta-networks/pceplib [2] https://github.com/volta-networks/pceplib/tree/devel#pceplib-threading-model

2 1

build failure on recent FreeBSD of legacy version
by mike tancsa 27 May '20

27 May '20

I know 3.x isnt supported anymore, but I needed to build the binary for various reasons and ran into a build failure on bgpd.c and bgp_routemap.c cc -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc/frr/\" -I. -I.. -I.. -I.. -I../lib -I../lib -Irfapi -I../bgpd/rfp-example/librfp -I/usr/local/include -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fno-omit-frame-pointer -Wall -Wextra -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -MT bgp_aspath.o -MD -MP -MF $depbase.Tpo -c -o bgp_aspath.o bgp_aspath.c &&\ mv -f $depbase.Tpo $depbase.Po bgpd.c:6210:22: error: use of undeclared identifier 'FALSE' int if_pg_printed = FALSE; ^ bgpd.c:6211:23: error: use of undeclared identifier 'FALSE' int if_ras_printed = FALSE; ^ bgpd.c:6233:20: error: use of undeclared identifier 'TRUE' if_pg_printed = TRUE; ^ bgpd.c:6236:21: error: use of undeclared identifier 'TRUE' if_ras_printed = TRUE; ^ bgpd.c:6239:21: error: use of undeclared identifier 'TRUE' if_ras_printed = TRUE; ^ bgpd.c:6242:21: error: use of undeclared identifier 'TRUE' if_ras_printed = TRUE; ^ 6 errors generated. I am compiling with FreeBSD clang version 8.0.1 and GNU Make 4.3. I dont see 'TRUE' nor 'FALSE' defined anywhere ? I think with previous versions of gmake and the auto* tools it was ok? Is it safe to just cram in a #define TRUE 1 and #define FALSE 0 ? in bgpd.c and bgp_routemap.c as a work around ? ---Mike

2 1

some zebra nexthop-tracking questions
by Mark Stapp 27 May '20

27 May '20

I've got a couple of questions about nexthop-tracking in zebra - these are a bit down in the details, but I thought I'd ask if any of the folks on the list have some insight... 1. the nht code makes a copy (mostly) of the route_entry that satisfies some client registration. the code copies all of the nexthops - even the recursive ones, even ones that are not ACTIVE. the code that sends nexthops to the nht client(s) has an rnh_nexthop_valid() function that is pretty strict about what will actually be sent. would it be reasonable to have the nht code capture only a list of the nexthops that are actually valid, that actually will be sent to the clients? 2. the show command for nht, ‘sho ip nht’, only shows the top-level nexthops - not the actual installed nexthops that, again, will be sent to the clients. would it be ok to change that, to try to have the show command show what will actually be sent to clients? 3. the route-map filtering in there also operates only on the top-level nexthops, not the exact ones that are "valid" and will be sent to clients. is that intentional, or should the route-map get a shot at the nexthops that the nht code would try to send? Thanks, Mark

1 0

Northbound call cancelled <This week>
by Santosh P K 22 May '20

22 May '20

Hello All, I have an hard conflict today. So will not be able to have this meeting this week. Will have meeting next week. Thanks Santosh P K

1 0

Farewell
by Donatas Abraitis 19 May '20

19 May '20

Hello, guys, the last time I have no time at all and I decided to leave this project and let other people do amazing things. It was an unforgettable experience, thank you all of you. FRRouting is awesome! Please remove me from the maintainer list. -- Donatas

2 1

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

30 Apr '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 1492772: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1492772: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_nht.c: 965 in bgp_nht_dereg_enhe_cap_intfs() 959 if (peer != bnc->nht_info) 960 return; 961 962 for (nhop = bnc->nexthop; nhop; nhop = nhop->next) { 963 ifp = if_lookup_by_index(nhop->ifindex, nhop->vrf_id); 964 >>> CID 1492772: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "ifp" when calling "zclient_send_interface_radv_req". 965 zclient_send_interface_radv_req(zclient, nhop->vrf_id, ifp, 0, 966 0); 967 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0

Canceled: Northbound discussion
by Santosh P K 30 Apr '20

30 Apr '20

Cancelling only for this week as few folks required have holiday tomorrow. Thanks Santosh P K

1 0

fd80 prefix allocation
by Tran (US), Katherine K 21 Apr '20

21 Apr '20

Hello, I asked this question to the FROG mailing list. But, I was wondering if it might be more of a developer question. I am trying to switch from Quagga to FRR. Would anyone know how FRR treats "fd80" prefixes? My configuration assigns "fd80" prefixes as Unique Local IPv6 Unicast Addresses (IETF RFC 4193), which can be routed. But, when looking at the added BGP routes, FRR shows "fe80" prefixes as the next-hop address. The next-hop address should have a "fd80" prefix. Note: Quagga displays the correct "fd80" prefix whereas FRR does not. Thank you, Katherine

2 2