- dev - lists.frrouting.org

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

21 Nov '19

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. 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 2 of 2 defect(s) ** CID 1488737: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1488737: Null pointer dereferences (FORWARD_NULL) /ospfd/ospf_nsm.c: 246 in ospf_db_summary_add() 240 241 /* Stay away from any Local Translated Type-7 LSAs */ 242 if (CHECK_FLAG(lsa->flags, OSPF_LSA_LOCAL_XLT)) 243 return 0; 244 245 if (IS_LSA_MAXAGE(lsa)) >>> CID 1488737: Null pointer dereferences (FORWARD_NULL) >>> Passing "nbr" to "ospf_ls_retransmit_add", which dereferences null "nbr->oi". 246 ospf_ls_retransmit_add(nbr, lsa); 247 else 248 ospf_lsdb_add(&nbr->db_sum, lsa); 249 250 return 0; 251 } ** CID 1488736: Incorrect expression (COPY_PASTE_ERROR) /bgpd/bgp_route.c: 3473 in bgp_update() ________________________________________________________________________________________________________ *** CID 1488736: Incorrect expression (COPY_PASTE_ERROR) /bgpd/bgp_route.c: 3473 in bgp_update() 3467 3468 if (pi->extra && pi->extra->bgp_orig) 3469 bgp_nexthop = pi->extra->bgp_orig; 3470 3471 nh_afi = BGP_ATTR_NH_AFI(afi, pi->attr); 3472 >>> CID 1488736: Incorrect expression (COPY_PASTE_ERROR) >>> "bgp" in "bgp_find_or_add_nexthop(bgp, bgp_nexthop, nh_afi, pi, NULL, connected)" looks like a copy-paste error. 3473 if (bgp_find_or_add_nexthop(bgp, bgp_nexthop, nh_afi, 3474 pi, NULL, connected) 3475 || CHECK_FLAG(peer->flags, PEER_FLAG_IS_RFAPI_HD)) 3476 bgp_path_info_set_flag(rn, pi, BGP_PATH_VALID); 3477 else { 3478 if (BGP_DEBUG(nht, NHT)) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Opensource routing @ ietf meetup -- Monday Lunch
by Lou Berger 18 Nov '19

18 Nov '19

Hi, We're continuing with the informal Open Source routing @ ietf meetup. Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to "Bras Basah" on *Monday* during lunch (noon). There is no agenda or slides. Please feel free to bring a topic that you'd like to discuss or just come and listen. Cheers, Lou

3 2

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 15 Nov '19

15 Nov '19

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 7 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 13 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 7 of 7 defect(s) ** CID 1487863: Incorrect expression (DIVIDE_BY_ZERO) ________________________________________________________________________________________________________ *** CID 1487863: Incorrect expression (DIVIDE_BY_ZERO) /bgpd/bgp_route.c: 12126 in bgp_damp_set() 12120 if (suppress < reuse) { 12121 vty_out(vty, 12122 "Suppress value cannot be less than reuse value \n"); 12123 return 0; 12124 } 12125 >>> CID 1487863: Incorrect expression (DIVIDE_BY_ZERO) >>> In function call "bgp_damp_enable", division by expression "reuse" which may be zero has undefined behavior. 12126 return bgp_damp_enable(bgp, bgp_node_afi(vty), bgp_node_safi(vty), half, 12127 reuse, suppress, max); 12128 } 12129 12130 DEFUN (bgp_damp_unset, 12131 bgp_damp_unset_cmd, ** CID 1487862: Incorrect expression (DIVIDE_BY_ZERO) ________________________________________________________________________________________________________ *** CID 1487862: Incorrect expression (DIVIDE_BY_ZERO) /bgpd/bgp_damp.c: 171 in bgp_reuse_timer() 165 bgp_damp_info_free(bdi, 1, bdc->afi, bdc->safi); 166 else 167 BGP_DAMP_LIST_ADD(bdc, bdi); 168 } else 169 /* Re-insert into another list (See RFC2439 Section 170 * 4.8.6). */ >>> CID 1487862: Incorrect expression (DIVIDE_BY_ZERO) >>> In function call "bgp_reuse_list_add", division by expression "bdc->reuse_limit" which may be zero has undefined behavior. 171 bgp_reuse_list_add(bdi, bdc); 172 } 173 174 return 0; 175 } 176 ** CID 1487861: (DIVIDE_BY_ZERO) ________________________________________________________________________________________________________ *** CID 1487861: (DIVIDE_BY_ZERO) /bgpd/bgp_route.c: 12126 in bgp_damp_set() 12120 if (suppress < reuse) { 12121 vty_out(vty, 12122 "Suppress value cannot be less than reuse value \n"); 12123 return 0; 12124 } 12125 >>> CID 1487861: (DIVIDE_BY_ZERO) >>> In function call "bgp_damp_enable", division by expression "half" which may be zero has undefined behavior. 12126 return bgp_damp_enable(bgp, bgp_node_afi(vty), bgp_node_safi(vty), half, 12127 reuse, suppress, max); 12128 } 12129 12130 DEFUN (bgp_damp_unset, 12131 bgp_damp_unset_cmd, /bgpd/bgp_route.c: 12126 in bgp_damp_set() 12120 if (suppress < reuse) { 12121 vty_out(vty, 12122 "Suppress value cannot be less than reuse value \n"); 12123 return 0; 12124 } 12125 >>> CID 1487861: (DIVIDE_BY_ZERO) >>> In function call "bgp_damp_enable", division by expression "half" which may be zero has undefined behavior. 12126 return bgp_damp_enable(bgp, bgp_node_afi(vty), bgp_node_safi(vty), half, 12127 reuse, suppress, max); 12128 } 12129 12130 DEFUN (bgp_damp_unset, 12131 bgp_damp_unset_cmd, ** CID 1487860: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1487860: Memory - corruptions (OVERRUN) /zebra/rt_netlink.c: 2481 in netlink_request_nexthop() 2475 memset(&req, 0, sizeof(req)); 2476 req.n.nlmsg_type = type; 2477 req.n.nlmsg_flags = NLM_F_ROOT | NLM_F_MATCH | NLM_F_REQUEST; 2478 req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct nhmsg)); 2479 req.nhm.nh_family = family; 2480 >>> CID 1487860: Memory - corruptions (OVERRUN) >>> Overrunning struct type nlmsghdr of 16 bytes by passing it to a function which accesses it at byte offset 23 using argument "req.n.nlmsg_len" (which evaluates to 24). 2481 return netlink_request(&zns->netlink_cmd, &req.n); 2482 } 2483 2484 2485 /** 2486 * netlink_nexthop_read() - Nexthop read function using netlink interface ** CID 1487859: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1487859: Null pointer dereferences (NULL_RETURNS) /isisd/isis_zebra.c: 97 in isis_zebra_if_address_add() 91 if (p->family == AF_INET) 92 zlog_debug("connected IP address %s", buf); 93 if (p->family == AF_INET6) 94 zlog_debug("connected IPv6 address %s", buf); 95 #endif /* EXTREME_DEBUG */ 96 if (if_is_operative(c->ifp)) >>> CID 1487859: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "circuit_scan_by_ifp(c->ifp)" when calling "isis_circuit_add_addr". 97 isis_circuit_add_addr(circuit_scan_by_ifp(c->ifp), c); 98 99 return 0; 100 } 101 102 static int isis_zebra_if_address_del(ZAPI_CALLBACK_ARGS) ** CID 1487858: Memory - illegal accesses (USE_AFTER_FREE) /ospfd/ospf_interface.c: 908 in ospf_vl_if_delete() ________________________________________________________________________________________________________ *** CID 1487858: Memory - illegal accesses (USE_AFTER_FREE) /ospfd/ospf_interface.c: 908 in ospf_vl_if_delete() 902 903 static void ospf_vl_if_delete(struct ospf_vl_data *vl_data) 904 { 905 vl_data->vl_oi->address->u.prefix4.s_addr = 0; 906 vl_data->vl_oi->address->prefixlen = 0; 907 ospf_if_free(vl_data->vl_oi); >>> CID 1487858: Memory - illegal accesses (USE_AFTER_FREE) >>> Dereferencing freed pointer "vl_data->vl_oi". 908 if_delete(&vl_data->vl_oi->ifp); 909 vlink_count--; 910 } 911 912 /* for a defined area, count the number of configured vl 913 */ ** CID 20290: Control flow issues (MISSING_BREAK) /lib/command_parse.c: 1001 in yytnamerr() ________________________________________________________________________________________________________ *** CID 20290: Control flow issues (MISSING_BREAK) /lib/command_parse.c: 1001 in yytnamerr() 995 switch (*++yyp) 996 { 997 case '\'': 998 case ',': 999 goto do_not_strip_quotes; 1000 >>> CID 20290: Control flow issues (MISSING_BREAK) >>> The case for value "'\\'" is not terminated by a 'break' statement. 1001 case '\\': 1002 if (*++yyp != '\\') 1003 goto do_not_strip_quotes; 1004 else 1005 goto append; 1006 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

regarding - ospf-loop issue with the given topology
by Palpandi Perumal 14 Nov '19

14 Nov '19

Hi All, Please find the topology attached. Whenever the node "uspine02" was rebooted, we ended in an ospf loop intermittently. We are seeing one anomaly sequence and we are not able to get the trigger point of it. Once we ended up in the promatic state. >From the debug log, The rebooted us-spine2 says, the received network-lsa is originated from me, so i should ignore that lsa to flood in broadcast domain and set the max-age that i have already installed.In this case, LS ack will not be sent from us-spine2, so gh-core1 again will add that LSA in re-transmit list and will process next 10s interval. In the mean-time, us-spine2 will broadcast the max-age LSA to ghcore for removing that route. Once that route was removed by us-spine2 max-age network-lsa, us-spine1 will send proper network-lsa immediately to ghcore1 to re-install that route so after that event, re-transmit list will be processed again on gh-core1, will send that network-lsa to us-spine2 and us-spine2 will be seeing that lsa as self-originated LSA and will do the above thing again. ----------> this anomaly sequence led our switches in that state. It is a timing problem. That is the reason we are not hitting consistently. *Root cause:* Before uspine2 goes to reboot, it would have been in DR and would have generated one network-lsa to this broadcast domain area 204. That LSA would have received on ghcore1. ghcore1 considered that LSA as proper LSA and installed it and ghcore1 flood that LSA again to area 204 at that time uspine2 would have established back with BDR and received the same LSA and considered that LSA as self-originated LSA. *Potential fix based on the RFC 2328 section 13:* Before flooding the LSA to broadcast domain.Check whether the received is self-originated. diff -r dc50bb05b29e usr/src/cmd/FRRouting/frr-master/ospfd/ospf_flood.c --- a/usr/src/cmd/FRRouting/frr-master/ospfd/ospf_flood.c Tue Nov 05 05:44:37 2019 -0800 +++ b/usr/src/cmd/FRRouting/frr-master/ospfd/ospf_flood.c Tue Nov 05 08:51:51 2019 -0800 @@ -925,6 +925,26 @@ old->retransmit_counter--; ospf_lsdb_delete(&nbr->ls_rxmt, old); } + /* + * Please refer section 13.1 in RFC 2328 + * Flooding procedure is not applicable for self + * originating lsa. Unfortunately we ended up the + * self-originated lsa to be added in retransmit list + * through flood caller. + * while adding this lsa to re-transmit list, + * need to confirm whether this is self-originated lsa. + * If its, it should get remove in lsdb and shouldnt add + * in retransmit list. + */ + if (ospf_lsa_is_self_originated(nbr->oi->ospf, lsa)) { + if (IS_DEBUG_OSPF(lsa, LSA_FLOODING)) + zlog_debug("self originated RXmtL(%lu)++," + " NBR(%s), LSA[%s]", + ospf_ls_retransmit_count(nbr), + inet_ntoa(nbr->router_id), + dump_lsa_key(lsa)); + return; + } Thanks Palpandi P

2 2

FRR 7.2 Ubuntu 18 package
by Vasco Matos 12 Nov '19

12 Nov '19

Dear developers, Are you going to create a package for the FRR 7.2 ? The BFD with vrf support is a feature that I would need to have implemented but I would like to install everything through an official package. Since it is a stable version why not implement it in Debian/Ubuntu as well ? Thanks and keep up the good work Vasco Matos

2 2

frr compiling with ospf support encountered a problem
by elahe jahani 11 Nov '19

11 Nov '19

Hi. ّ I can't compile the frr service on freebsd 12.1. My frr version is 1.1. I would like enable ospfd on frr, Therefore, I added --enable-ospfd on Makefile.onestep. I get the following error when compiling the frr source code: ospfd/ospf_neighbor.c: In function 'ospf_nbr_lookup': ospfd/ospf_neighbor.c:410:45: error: taking address of packed member of 'struct ip' may result in an unaligned pointer value [-Werror=address-of-packed-member] 410 | return (ospf_nbr_lookup_by_addr(oi->nbrs, &iph->ip_src)); I searched a lot of, but found nothing. Thank you for wasting time to help me.

2 1

Re: [dev] Bug#944392: frr: /usr/share/man/man8/vrrpd.8.gz is already shipped by vrrpd
by David Lamparter 09 Nov '19

09 Nov '19

On Sat, Nov 09, 2019 at 03:33:05AM +0100, Andreas Beckmann wrote: > Package: frr > Version: 7.2-1 > Severity: serious > > during a test with piuparts I noticed your package failed to install > because it tries to overwrite other packages files. [...] > dpkg: error processing archive /tmp/apt-dpkg-install-3pfMjQ/16-frr_7.2-1_amd64.deb (--unpack): > trying to overwrite '/usr/share/man/man8/vrrpd.8.gz', which is also in package vrrpd 1.0-2+b2 Hi Andreas, Thanks for catching this. vrrpd is one of FRR's "protocol" daemons, installed to /usr/lib/frr/ (hence the binary isn't colliding), but obviously the manpage doesn't have this private directory. I need to go dig through the Debian policy on what it says about this. I'm guessing we should just rename our manpages to "frr-<daemon>". The binary isn't in PATH either, i.e. you can't run FRR vrrpd by just typing "vrrpd", so not getting the manpage with "man vrrpd" is consistent. (It does make sense for vrrpd to be installed in parallel with FRR, in particular since VRRP support is a recent FRR addition and existing setups may very well want to stick with a vrrpd+FRR configuration.) (Cc'ing onto FRR dev list for further comment. Please keep the debian bugtracker address in Cc:. Also opening an issue on FRR github.) Cheers, -David

1 0

Request for a BGP-LS development branch
by olivier.dugeon＠orange.com 08 Nov '19

08 Nov '19

Dear all, I got request from FRR developers to share our respective work on BGP Link State (BGP-LS a.k.a RFC7752) This new functionality has been identify in the feature request list (see https://github.com/FRRouting/frr/wiki/Feature-Requests) following issue 3520 (see https://github.com/FRRouting/frr/issues/3520) The development branch is necessary as: - No one have a complete solution and we would build a global solution without redeveloping everything from scratch: we have parser & serializer, others have integration in latest FRR version ... - This is a complex feature which re-use BGP as transport protocol, but which is completely new in FRR and need large amount of work - BGP-LS needs to collect Link State information from OSPF or IS-IS. For that purpose, new Traffic Engineering Database will be introduce in lib directory. This TED will be fulfil by OSPF or IS-IS and modification sent to BGP through new ZAPI message. This method will avoid to code an OSPF parser and an IS-IS parser inside BGP-LS code and reduce the amount of data that transit through zebra layer. Please inform me once the branch created. Regards Olivier _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

3 3

Request for a Development Branch for ISIS Segment Routing
by olivier.dugeon＠orange.com 01 Nov '19

01 Nov '19

Dear all, Following decision taken during the meeting of 29th of October 2019, I would request the creation of a development branch for IS-IS Segment Routing. This new functionality has been identify in the feature request list (see https://github.com/FRRouting/frr/wiki/Feature-Requests) following issue 2639 (see https://github.com/FRRouting/frr/issues/2639) The development branch is necessary in order to converge both development that have been submitted recently (see https://github.com/FRRouting/frr/pull/4945 and https://github.com/FRRouting/frr/pull/4800) Please inform me once the branch created. Regards Olivier _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

3 3

TSC Voting Results.
by Alistair Woodman 01 Nov '19

01 Nov '19

All 17 maintainers have finished voting in the TSC Election for the 2019-2020 session. By the single transferable vote algorithm, the following candidates are elected to the TSC. (in alphabetical, not ranked order) . Lou Berger . Donald Sharp . Sri Mohana Singamsetty . Russ White . Martin Winter . Quentin Young Your elections officer /a

1 0