- dev - lists.frrouting.org

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

19 Mar '18

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 1465679: (RESOURCE_LEAK) /zebra/zebra_vty.c: 256 in zebra_static_route_holdem() /zebra/zebra_vty.c: 256 in zebra_static_route_holdem() ________________________________________________________________________________________________________ *** CID 1465679: (RESOURCE_LEAK) /zebra/zebra_vty.c: 256 in zebra_static_route_holdem() 250 } 251 252 /* 253 * If a person enters the same line again 254 * we need to silently accept it 255 */ >>> CID 1465679: (RESOURCE_LEAK) >>> Variable "shr" going out of scope leaks the storage it points to. 256 return CMD_SUCCESS; 257 } 258 259 listnode_add_sort(static_list, shr); 260 261 return CMD_SUCCESS; /zebra/zebra_vty.c: 256 in zebra_static_route_holdem() 250 } 251 252 /* 253 * If a person enters the same line again 254 * we need to silently accept it 255 */ >>> CID 1465679: (RESOURCE_LEAK) >>> Variable "shr" going out of scope leaks the storage it points to. 256 return CMD_SUCCESS; 257 } 258 259 listnode_add_sort(static_list, shr); 260 261 return CMD_SUCCESS; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

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

18 Mar '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 27 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 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 20 of 27 defect(s) ** CID 1465497: Control flow issues (DEADCODE) /zebra/zebra_netns_id.c: 253 in zebra_ns_id_get() ________________________________________________________________________________________________________ *** CID 1465497: Control flow issues (DEADCODE) /zebra/zebra_netns_id.c: 253 in zebra_ns_id_get() 247 break; 248 } 249 } 250 len = len - NETLINK_ALIGN(nlh->nlmsg_len); 251 nlh = (struct nlmsghdr *)((char *)nlh 252 + NETLINK_ALIGN(nlh->nlmsg_len)); >>> CID 1465497: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "ret == 0" inside this statement: "do { if (nlh->nlmsg_type...". 253 } while (len != 0 && return_nsid != NS_UNKNOWN && ret == 0); 254 255 if (ret <= 0) { 256 if (errno != EEXIST && ret != 0) { 257 zlog_err( 258 "netlink( %u) recvfrom() error 2 when reading: %s", ** CID 1465496: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1465496: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_vty.c: 6969 in clear_bgp_instance_ipv6_safi_prefix() 6963 /* [<view|vrf> VIEWVRFNAME] */ 6964 char *vrfview = argv_find(argv, argc, "VIEWVRFNAME", &idx_word) ? 6965 argv[idx_word]->arg : NULL; 6966 6967 argv_find_and_parse_safi(argv, argc, &idx_safi, &safi); 6968 >>> CID 1465496: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "prefix" to "bgp_clear_prefix", which dereferences it. 6969 return bgp_clear_prefix( 6970 vty, vrfview, prefix, 6971 AFI_IP6, safi, NULL); 6972 } 6973 6974 DEFUN (show_bgp_views, ** CID 1465495: Memory - illegal accesses (OVERRUN) /zebra/zserv.c: 2617 in zserv_handle_commands() ________________________________________________________________________________________________________ *** CID 1465495: Memory - illegal accesses (OVERRUN) /zebra/zserv.c: 2617 in zserv_handle_commands() 2611 2612 static inline void zserv_handle_commands(struct zserv *client, 2613 struct zmsghdr *hdr, 2614 struct stream *msg, 2615 struct zebra_vrf *zvrf) 2616 { >>> CID 1465495: Memory - illegal accesses (OVERRUN) >>> Overrunning array "zserv_handlers" of 79 8-byte elements at element index 632 (byte offset 5056) using index "hdr->command" (which evaluates to 632). 2617 if (hdr->command > sizeof(zserv_handlers) 2618 || zserv_handlers[hdr->command] == NULL) 2619 zlog_info("Zebra received unknown command %d", hdr->command); 2620 else 2621 zserv_handlers[hdr->command](client, hdr, msg, zvrf); 2622 ** CID 1465494: (STRING_NULL) /zebra/zebra_netns_notify.c: 169 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 169 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 169 in zebra_ns_notify_read() ________________________________________________________________________________________________________ *** CID 1465494: (STRING_NULL) /zebra/zebra_netns_notify.c: 169 in zebra_ns_notify_read() 163 struct inotify_event *event; 164 char buf[BUFSIZ]; 165 ssize_t len; 166 167 zebra_netns_notify_current = thread_add_read( 168 zebrad.master, zebra_ns_notify_read, NULL, fd_monitor, NULL); >>> CID 1465494: (STRING_NULL) >>> Function "read" does not terminate string "*buf". 169 len = read(fd_monitor, buf, sizeof(buf)); 170 if (len < 0) { 171 zlog_warn("NS notify read: failed to read (%s)", 172 safe_strerror(errno)); 173 return 0; 174 } /zebra/zebra_netns_notify.c: 169 in zebra_ns_notify_read() 163 struct inotify_event *event; 164 char buf[BUFSIZ]; 165 ssize_t len; 166 167 zebra_netns_notify_current = thread_add_read( 168 zebrad.master, zebra_ns_notify_read, NULL, fd_monitor, NULL); >>> CID 1465494: (STRING_NULL) >>> Function "read" does not terminate string "*buf". 169 len = read(fd_monitor, buf, sizeof(buf)); 170 if (len < 0) { 171 zlog_warn("NS notify read: failed to read (%s)", 172 safe_strerror(errno)); 173 return 0; 174 } /zebra/zebra_netns_notify.c: 169 in zebra_ns_notify_read() 163 struct inotify_event *event; 164 char buf[BUFSIZ]; 165 ssize_t len; 166 167 zebra_netns_notify_current = thread_add_read( 168 zebrad.master, zebra_ns_notify_read, NULL, fd_monitor, NULL); >>> CID 1465494: (STRING_NULL) >>> Function "read" does not terminate string "*buf". 169 len = read(fd_monitor, buf, sizeof(buf)); 170 if (len < 0) { 171 zlog_warn("NS notify read: failed to read (%s)", 172 safe_strerror(errno)); 173 return 0; 174 } ** CID 1465493: Memory - illegal accesses (UNINIT) /pimd/pim_igmp_mtrace.c: 269 in mtrace_un_forward_packet() ________________________________________________________________________________________________________ *** CID 1465493: Memory - illegal accesses (UNINIT) /pimd/pim_igmp_mtrace.c: 269 in mtrace_un_forward_packet() 263 zlog_warn( 264 "Dropping mtrace packet, " 265 "no route to destination"); 266 return -1; 267 } 268 >>> CID 1465493: Memory - illegal accesses (UNINIT) >>> Using uninitialized value "nexthop.interface". 269 if_out = nexthop.interface; 270 } else { 271 if_out = interface; 272 } 273 274 ret = pim_socket_bind(fd, if_out); ** CID 1465492: Resource leaks (RESOURCE_LEAK) /zebra/zserv.c: 599 in zsend_redistribute_route() ________________________________________________________________________________________________________ *** CID 1465492: Resource leaks (RESOURCE_LEAK) /zebra/zserv.c: 599 in zsend_redistribute_route() 593 api.mtu = re->mtu; 594 595 struct stream *s = stream_new(ZEBRA_MAX_PACKET_SIZ); 596 597 /* Encode route and send. */ 598 if (zapi_route_encode(cmd, s, &api) < 0) >>> CID 1465492: Resource leaks (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 599 return -1; 600 601 if (IS_ZEBRA_DEBUG_SEND) { 602 char buf_prefix[PREFIX_STRLEN]; 603 prefix2str(&api.prefix, buf_prefix, sizeof(buf_prefix)); 604 ** CID 1465491: (TAINTED_SCALAR) /pimd/mtracebis.c: 281 in recv_response() /pimd/mtracebis.c: 311 in recv_response() ________________________________________________________________________________________________________ *** CID 1465491: (TAINTED_SCALAR) /pimd/mtracebis.c: 281 in recv_response() 275 sum = ip->ip_sum; 276 ip->ip_sum = 0; 277 278 if (sum != in_cksum(ip, ip->ip_hl * 4)) 279 return -1; 280 >>> CID 1465491: (TAINTED_SCALAR) >>> Using tainted variable "4 * ip->ip_hl" as an index into an array "mtrace_buf". 281 mtrace = (struct igmp_mtrace *)(mtrace_buf + (4 * ip->ip_hl)); 282 283 mtrace_len = ntohs(ip->ip_len) - ip->ip_hl * 4; 284 285 if (mtrace_len < (int)MTRACE_HDR_SIZE) 286 return -1; /pimd/mtracebis.c: 311 in recv_response() 305 } 306 307 if (hops) 308 *hops = responses; 309 310 if (mtracer) >>> CID 1465491: (TAINTED_SCALAR) >>> Passing tainted variable "mtrace_len" to a tainted sink. 311 memcpy(mtracer, mtrace, mtrace_len); 312 313 return 0; 314 } 315 316 static int wait_for_response(int fd, int *hops, struct igmp_mtrace *mtrace, ** CID 1465490: Error handling issues (CHECKED_RETURN) /pimd/pim_igmp_mtrace.c: 664 in igmp_mtrace_recv_qry_req() ________________________________________________________________________________________________________ *** CID 1465490: Error handling issues (CHECKED_RETURN) /pimd/pim_igmp_mtrace.c: 664 in igmp_mtrace_recv_qry_req() 658 if (pim_if_connected_to_source(out_ifp, mtracep->src_addr)) 659 return mtrace_send_response(pim, mtracep, mtrace_len); 660 /* 661 * 6.4 Forwarding Traceroute Requests: 662 * Previous-hop router not known 663 */ >>> CID 1465490: Error handling issues (CHECKED_RETURN) >>> Calling "inet_aton" without checking return value (as is done elsewhere 114 out of 116 times). 664 inet_aton(MCAST_ALL_ROUTERS, &nh_addr); 665 } 666 667 if (mtracep->hops <= (last_rsp_ind + 1)) 668 return mtrace_send_response(pim, mtracep, mtrace_len); 669 ** CID 1465489: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1465489: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_vty_clippy.c: 144 in vpn_policy_nexthop() 138 } 139 #if 1 /* anything that can fail? */ 140 if (_failcnt) 141 return CMD_WARNING; 142 #endif 143 #endif >>> CID 1465489: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "nexthop" to "vpn_policy_nexthop_magic", which dereferences it. 144 return vpn_policy_nexthop_magic(self, vty, argc, argv, nexthop, nexthop_str); 145 } 146 147 /* show_ip_bgp_instance_updgrps_adj_s => "show [ip]$ip bgp [<view|vrf> VIEWVRFNAME$vrf] [<ipv4|ipv6>$afi <unicast|multicast|vpn>$safi] update-groups [SUBGROUP-ID]$sgid <advertise-queue|advertised-routes|packet-queue>$rtq" */ 148 DEFUN_CMD_FUNC_DECL(show_ip_bgp_instance_updgrps_adj_s) 149 #define funcdecl_show_ip_bgp_instance_updgrps_adj_s static int show_ip_bgp_instance_updgrps_adj_s_magic(\ ** CID 1465488: Error handling issues (CHECKED_RETURN) /zebra/zserv.c: 1163 in zread_route_add() ________________________________________________________________________________________________________ *** CID 1465488: Error handling issues (CHECKED_RETURN) /zebra/zserv.c: 1163 in zread_route_add() 1157 struct nexthop *nexthop = NULL; 1158 int i, ret; 1159 vrf_id_t vrf_id = 0; 1160 struct ipaddr vtep_ip; 1161 1162 s = msg; >>> CID 1465488: Error handling issues (CHECKED_RETURN) >>> Calling "zapi_route_decode" without checking return value (as is done elsewhere 12 out of 13 times). 1163 zapi_route_decode(s, &api); 1164 1165 if (IS_ZEBRA_DEBUG_RECV) { 1166 char buf_prefix[PREFIX_STRLEN]; 1167 prefix2str(&api.prefix, buf_prefix, sizeof(buf_prefix)); 1168 zlog_debug("%s: p=%s, ZAPI_MESSAGE_LABEL: %sset, flags=0x%x", ** CID 1465487: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_network.c: 458 in bgp_get_bound_name() ________________________________________________________________________________________________________ *** CID 1465487: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_network.c: 458 in bgp_get_bound_name() 452 return NULL; 453 454 if (peer->su.sa.sa_family != AF_INET 455 && peer->su.sa.sa_family != AF_INET6) 456 return NULL; // unexpected 457 >>> CID 1465487: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "peer" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 458 if (!peer) 459 return name; 460 /* For IPv6 peering, interface (unnumbered or link-local with interface) 461 * takes precedence over VRF. For IPv4 peering, explicit interface or 462 * VRF are the situations to bind. 463 */ ** CID 1465486: Memory - illegal accesses (UNINIT) /pimd/pim_igmp_mtrace.c: 645 in igmp_mtrace_recv_qry_req() ________________________________________________________________________________________________________ *** CID 1465486: Memory - illegal accesses (UNINIT) /pimd/pim_igmp_mtrace.c: 645 in igmp_mtrace_recv_qry_req() 639 else 640 rspp->fwd_code = fwd_code; 641 /* 6.5 Sending Traceroute Responses */ 642 return mtrace_send_response(pim, mtracep, mtrace_len); 643 } 644 >>> CID 1465486: Memory - illegal accesses (UNINIT) >>> Using uninitialized value "nexthop.interface". 645 out_ifp = nexthop.interface; 646 pim_out_ifp = out_ifp->info; 647 648 rspp->incoming = pim_out_ifp->primary_address; 649 rspp->prev_hop = nh_addr; 650 rspp->in_count = htonl(MTRACE_UNKNOWN_COUNT); ** CID 1465485: (RESOURCE_LEAK) /bgpd/bgp_mplsvpn.c: 474 in vpn_leak_from_vrf_update() /bgpd/bgp_mplsvpn.c: 533 in vpn_leak_from_vrf_update() /bgpd/bgp_mplsvpn.c: 566 in vpn_leak_from_vrf_update() /bgpd/bgp_mplsvpn.c: 638 in vpn_leak_from_vrf_update() ________________________________________________________________________________________________________ *** CID 1465485: (RESOURCE_LEAK) /bgpd/bgp_mplsvpn.c: 474 in vpn_leak_from_vrf_update() 468 s = ecommunity_ecom2str(info_vrf->attr->ecommunity, 469 ECOMMUNITY_FORMAT_ROUTE_MAP, 0); 470 } 471 472 zlog_debug("%s: info_vrf->type=%d, EC{%s}", __func__, 473 info_vrf->type, s); >>> CID 1465485: (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 474 } 475 476 if (!bgp_vpn) 477 return; 478 479 if (!afi) { /bgpd/bgp_mplsvpn.c: 533 in vpn_leak_from_vrf_update() 527 if (static_attr.ecommunity) { 528 s = ecommunity_ecom2str(static_attr.ecommunity, 529 ECOMMUNITY_FORMAT_ROUTE_MAP, 0); 530 } 531 zlog_debug("%s: post route map static_attr.ecommunity{%s}", 532 __func__, s); >>> CID 1465485: (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 533 } 534 535 /* 536 * Add the vpn-policy rt-list 537 */ 538 struct ecommunity *old_ecom; /bgpd/bgp_mplsvpn.c: 566 in vpn_leak_from_vrf_update() 560 if (static_attr.ecommunity) { 561 s = ecommunity_ecom2str(static_attr.ecommunity, 562 ECOMMUNITY_FORMAT_ROUTE_MAP, 0); 563 } 564 zlog_debug("%s: post merge static_attr.ecommunity{%s}", 565 __func__, s); >>> CID 1465485: (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 566 } 567 568 /* Nexthop */ 569 /* if policy nexthop not set, use 0 */ 570 if (CHECK_FLAG(bgp_vrf->vpn_policy[afi].flags, 571 BGP_VPN_POLICY_TOVPN_NEXTHOP_SET)) { /bgpd/bgp_mplsvpn.c: 638 in vpn_leak_from_vrf_update() 632 633 if (new_attr->ecommunity) { 634 s = ecommunity_ecom2str(new_attr->ecommunity, 635 ECOMMUNITY_FORMAT_ROUTE_MAP, 0); 636 } 637 zlog_debug("%s: new_attr->ecommunity{%s}", __func__, s); >>> CID 1465485: (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 638 } 639 640 /* Now new_attr is an allocated interned attr */ 641 642 bn = bgp_afi_node_get(bgp_vpn->rib[afi][safi], afi, safi, p, 643 &(bgp_vrf->vpn_policy[afi].tovpn_rd)); ** CID 1465484: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1465484: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_vty.c: 6940 in clear_bgp_ipv6_safi_prefix() 6934 int idx_ipv6_prefix = 0; 6935 safi_t safi = SAFI_UNICAST; 6936 char *prefix = argv_find(argv, argc, "X:X::X:X/M", &idx_ipv6_prefix) ? 6937 argv[idx_ipv6_prefix]->arg : NULL; 6938 6939 argv_find_and_parse_safi(argv, argc, &idx_safi, &safi); >>> CID 1465484: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "prefix" to "bgp_clear_prefix", which dereferences it. 6940 return bgp_clear_prefix( 6941 vty, NULL, prefix, AFI_IP6, 6942 safi, NULL); 6943 } 6944 6945 DEFUN (clear_bgp_instance_ipv6_safi_prefix, ** CID 1465483: Integer handling issues (NEGATIVE_RETURNS) ________________________________________________________________________________________________________ *** CID 1465483: Integer handling issues (NEGATIVE_RETURNS) /pimd/mtracebis_routeget.c: 87 in routeget() 81 82 ret = rtnl_open(&rth, 0); 83 84 if (ret < 0) 85 return ret; 86 >>> CID 1465483: Integer handling issues (NEGATIVE_RETURNS) >>> "rth.fd" is passed to a parameter that cannot be negative. 87 if (rtnl_talk(&rth, &req.n, 0, 0, &req.n, NULL, NULL) < 0) { 88 ret = -1; 89 goto close_rth; 90 } 91 92 ret = find_dst(&req.n, src, gw); ** CID 1465482: (NULL_RETURNS) /zebra/zebra_vty.c: 549 in static_config_install_delayed_routes() /zebra/zebra_vty.c: 549 in static_config_install_delayed_routes() ________________________________________________________________________________________________________ *** CID 1465482: (NULL_RETURNS) /zebra/zebra_vty.c: 549 in static_config_install_delayed_routes() 543 ozvrf = zebra_vrf_lookup_by_name(shr->vrf_name); 544 nh_zvrf = zebra_vrf_lookup_by_name(shr->nhvrf_name); 545 546 if (ozvrf != zvrf && nh_zvrf != zvrf) 547 continue; 548 >>> CID 1465482: (NULL_RETURNS) >>> Dereferencing a null pointer "ozvrf". 549 if (ozvrf->vrf->vrf_id == VRF_UNKNOWN 550 || nh_zvrf->vrf->vrf_id == VRF_UNKNOWN) 551 continue; 552 553 installed = zebra_static_route_leak( 554 NULL, ozvrf, nh_zvrf, shr->afi, shr->safi, NULL, /zebra/zebra_vty.c: 549 in static_config_install_delayed_routes() 543 ozvrf = zebra_vrf_lookup_by_name(shr->vrf_name); 544 nh_zvrf = zebra_vrf_lookup_by_name(shr->nhvrf_name); 545 546 if (ozvrf != zvrf && nh_zvrf != zvrf) 547 continue; 548 >>> CID 1465482: (NULL_RETURNS) >>> Dereferencing a null pointer "nh_zvrf". 549 if (ozvrf->vrf->vrf_id == VRF_UNKNOWN 550 || nh_zvrf->vrf->vrf_id == VRF_UNKNOWN) 551 continue; 552 553 installed = zebra_static_route_leak( 554 NULL, ozvrf, nh_zvrf, shr->afi, shr->safi, NULL, ** CID 1465481: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1465481: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_fsm.c: 1389 in bgp_start() 1383 "%s [FSM] In a VRF that is not initialised yet", 1384 peer->host); 1385 return -1; 1386 } 1387 1388 /* Register to be notified on peer up */ >>> CID 1465481: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "peer->bgp" to "bgp_flag_check", which dereferences it. 1389 if (peer->sort == BGP_PEER_EBGP && peer->ttl == 1 1390 && !CHECK_FLAG(peer->flags, PEER_FLAG_DISABLE_CONNECTED_CHECK) 1391 && !bgp_flag_check(peer->bgp, BGP_FLAG_DISABLE_NH_CONNECTED_CHK)) 1392 connected = 1; 1393 else 1394 connected = 0; ** CID 1465480: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1465480: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_mplsvpn.c: 496 in vpn_leak_from_vrf_update() 490 if (!vpn_leak_to_vpn_active(bgp_vrf, afi, &debugmsg)) { 491 if (debug) 492 zlog_debug("%s: skipping: %s", __func__, debugmsg); 493 return; 494 } 495 >>> CID 1465480: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "info_vrf->attr" to "bgp_attr_dup", which dereferences it. 496 bgp_attr_dup(&static_attr, info_vrf->attr); /* shallow copy */ 497 498 /* 499 * route map handling 500 */ 501 if (bgp_vrf->vpn_policy[afi].rmap[BGP_VPN_POLICY_DIR_TOVPN]) { ** CID 1465479: Resource leaks (RESOURCE_LEAK) /ospf6d/ospf6_asbr.c: 619 in ospf6_asbr_lsa_remove() ________________________________________________________________________________________________________ *** CID 1465479: Resource leaks (RESOURCE_LEAK) /ospf6d/ospf6_asbr.c: 619 in ospf6_asbr_lsa_remove() 613 route = ospf6_route_lookup(&prefix, ospf6->route_table); 614 if (route == NULL) { 615 if (IS_OSPF6_DEBUG_EXAMIN(AS_EXTERNAL)) { 616 prefix2str(&prefix, buf, sizeof(buf)); 617 zlog_debug("AS-External route %s not found", buf); 618 } >>> CID 1465479: Resource leaks (RESOURCE_LEAK) >>> Variable "route_to_del" going out of scope leaks the storage it points to. 619 return; 620 } 621 622 if (IS_OSPF6_DEBUG_EXAMIN(AS_EXTERNAL)) { 623 prefix2str(&prefix, buf, sizeof(buf)); 624 zlog_debug( ** CID 1465478: Resource leaks (RESOURCE_LEAK) /pimd/pim_igmp_mtrace.c: 266 in mtrace_un_forward_packet() ________________________________________________________________________________________________________ *** CID 1465478: Resource leaks (RESOURCE_LEAK) /pimd/pim_igmp_mtrace.c: 266 in mtrace_un_forward_packet() 260 261 if (ret != 0) { 262 if (PIM_DEBUG_MTRACE) 263 zlog_warn( 264 "Dropping mtrace packet, " 265 "no route to destination"); >>> CID 1465478: Resource leaks (RESOURCE_LEAK) >>> Handle variable "fd" going out of scope leaks the handle. 266 return -1; 267 } 268 269 if_out = nexthop.interface; 270 } else { 271 if_out = interface; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

New build dependency for documentation
by Quentin Young 18 Mar '18

18 Mar '18

Hi folks, we have switched to using RST+Sphinx as our documentation system. To build FRR you will need a Sphinx package. Most distributions offer a sufficiently up to date package. Details on which package you need to install on your platform can be found in the developer documentation under "Building". https://github.com/FRRouting/frr/tree/master/doc/developer Thanks, Quentin

1 0

BGP Route Leaking for VRF-Lite and VPN's
by Donald Sharp 15 Mar '18

15 Mar '18

All - During discussions this morning w/ Lou we discovered that we are both working towards a BGP solution for Route Leaking. We have enough differences between our approaches that we need to spend some time consolidating our approach. The current plan is to have the meeting at 3:30 EDT this Friday Jan 19. If you would like to attend please let me know and I will put you on the invite for it. donald

4 15

Tuesday's Meeting Notes
by Donald Sharp 15 Mar '18

15 Mar '18

Issues 1836 - Still open. Assigned to Philippe 1845 - still open issue, need more work. Assigned to Philippe 1850 - Discussion on issue when during convergence a path doesn’t have labels and other path has labels and how to resolve this. Renato/Donald/Paul discussing solution offline. 1851 - RFC says we should add to IPv6’s to RA. Open issue to be addressed 1856 - Donald will look at it 1857 - He fails installing rtrlib - Martin going to reply with package link 1859 - Needs to look at it - Marti will look at it 1862 - Install issue. Patrick got followed up 1864 - Don Slice addressing it 1865 - ipinlnd will do a pull request 1874 - Philippe found root cause (or at least part of the issue) and has a fix. Might be another VRF issue on ending up as VRF unknown (Max ID) or -1 written to vrf ID. Might require another issue 1877 - Was removed some time back (complicated code), might be difficult to secure (filter passwords etc). Might be addressed in Northbound API in future 1878 - Donald asking Chirag to look into it 1879 - Quentin looking at it PRs 1704 - Martin doing the centos6 doc update and Quentin doing the make clean fix, ok to merge afterwards 1880 - Donald will review it Out of time to discuss more PR’s - Send email or ping on slack if anything needs to be discussed.

1 0

ISIS 3-way Handshake has been Implemented
by Donald Sharp 14 Mar '18

14 Mar '18

All - I would like to thank Christian Franke for implementing ISIS 3-way handshake as per RFC 5303. This code is currently available on master for using. To disable this option please use `no isis three-way-handshake` under an interface you would not like to use it on. thanks! donald

1 0

Integrating DLEP with FRR
by Susheela Francis 09 Mar '18

09 Mar '18

Hi, I am trying to integrate an open source DLEP stack with FRR/Quagga. I am trying to manipulate the linux kernel routing table to include the DLEP routes in its routing table and then redistribute it to Quagga. I am new to this and have not been successful in doing this so far. Can you suggest a way ahead? Is there a better approach to solve this problem? Thanks & Regards, Susheela Francis Larsen & Toubro ltd. Larsen and Toubro Limited; L&T Heavy Engineering | Strategic Electronics Center "Komarla Solitaire", 145/2, Old Madras Road, CV Raman Nagar, Bangalore 560093 Tele: +91-80-6693 6245, Mobile: +91-8105228297 Mail: SUSHEELA.FRANCIS(a)LARSENTOUBRO.COM<mailto:SUSHEELA.FRANCIS@LARSENTOUBRO.COM> Web: www.lthed.com<http://www.lthed.com/>; www.larsentoubro.com<http://www.larsentoubro.com/>; Larsen & Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

4 8

Today's Technical Meeting Notes
by Donald Sharp 06 Mar '18

06 Mar '18

1803- waiting of feedback of PR fixes issue 1810 - waiting for PR merge, perhaps also bring over to 4.0 1835 - Cumulus has solution to syslog as solution. Command line option is also possible. Phillippe will take lead on proposing a solution. ??? Doc reformat - Donald to work with Lou PBR - discussion on architecture and if have need for iptable management in FRR (to support PBR and flowspec, and to deconflict with VRFs/other table uses) . Probably need a rules manager as well. donald

1 0

Re: [dev] FRR Technical Meeting Notes - 02/27/2018
by Quentin Young 05 Mar '18

05 Mar '18

Forgot cc > On Mar 3, 2018, at 6:42 PM, Quentin Young <qlyoung(a)cumulusnetworks.com> wrote: > >> Okay from a practical standpoint I think this means that we have to support centos 6.x in new FRR releases until one year before the “Maintenance Updates” phase ends as we only support FRR release (even security fixes) for ~1 year. Right? > > Can you elaborate on how you drew that conclusion from this: > >>>> For whatever the platform in question is, we do the same thing. Continue to ship updated FRR packages for platforms in the “Full Updates” phase. Then once they enter the “Maintenance Updates” phase we freeze the package at whatever version it is, or close to it depending on convenience, and then only back port security fixes / critical bug fixes. > > I don’t think I understand your interpretation. > > Quentin > >> On Mar 3, 2018, at 5:49 PM, Lou Berger <lberger(a)labn.net <mailto:lberger@labn.net>> wrote: >> >> Okay from a practical standpoint I think this means that we have to support centos 6.x in new FRR releases until one year before the “Maintenance Updates” phase ends as we only support FRR release (even security fixes) for ~1 year. Right? >> >> >> On 3/2/2018 12:45 PM, Lou Berger wrote: >>> >>> >>> >>> On 2/27/2018 2:49 PM, Quentin Young wrote: >>>> There’s two EOL dates in the table. Let’s not pretend that 1 of them is the ’true' EOL date. >>>> >>>> +---------------------+----------------------+ >>>> | Full Updates | May 10th, 2017 | >>>> +---------------------+----------------------+ >>>> | Maintenance Updates | November 30th, 2020 | >>>> +---------------------+----------------------+ >>>> >>>> Here is what I propose, since the majority of platforms follow something like the above, roughly: >>>> >>>> - “Full Updates” period, where packages are actively updated, new features, new kernels etc >>>> - “Maintenance Updates” i.e. only back porting security fixes / critical bug fixes >>>> >>>> For whatever the platform in question is, we do the same thing. Continue to ship updated FRR packages for platforms in the “Full Updates” phase. Then once they enter the “Maintenance Updates” phase we freeze the package at whatever version it is, or close to it depending on convenience, and then only back port security fixes / critical bug fixes. >>>> >>>> Does this sound reasonable to everyone? >>> At first glance, yes. >>> >>> But what does this really mean in practical terms, *we* don't expect to support an FRR release for more than say about year right? >>> >>> Are you saying we now need to keep old releases around for as long as we have a platform on which we're doing Maintenance Updates? (For example, 3.0 untilNovember 30th, 2020) >>> >>> What's your thinking / proposal here? >>> >>> Lou >>> >>> On Feb 27, 2018, at 2:31 PM, Lou Berger <lberger(a)labn.net <mailto:lberger@labn.net> <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote: >>>>> >>>>> Right. It says: >>>>> Maintenance Updates2 <https://wiki.centos.org/About/Product#fndef-a91b3c0c287c782f9af063daff9e64b… <https://wiki.centos.org/About/Product#fndef-a91b3c0c287c782f9af063daff9e64b…>> November 30th, 2020 >>>>> >>>>> On February 27, 2018 2:20:24 PM Quentin Young <qlyoung(a)cumulusnetworks.com <mailto:qlyoung@cumulusnetworks.com> <mailto:qlyoung@cumulusnetworks.com <mailto:qlyoung@cumulusnetworks.com>>> wrote: >>>>> >>>>>> As Donald said in his email, >>>>>> >>>>>>>> We are just trying to match what the EOL is from the centos website itself. >>>>>> >>>>>> https://wiki.centos.org/About/Product <https://wiki.centos.org/About/Product> >>>>>> >>>>>>> On Feb 27, 2018, at 2:15 PM, Lou Berger <lberger(a)labn.net <mailto:lberger@labn.net> <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote: >>>>>>> >>>>>>> fair point, based on a quick google: >>>>>>> >>>>>>> https://linuxlifecycle.com/ <https://linuxlifecycle.com/> >>>>>>> >>>>>>> CentOS 6 (released 10 Jul 2011, EOL 30 Nov 2020) >>>>>>> >>>>>>> Lou >>>>>>> >>>>>>> On 2/27/2018 2:01 PM, Donald Sharp wrote: >>>>>>>> Isn't that Redhat, not centos 6? Different distributions. We are >>>>>>>> just trying to match what the EOL is from the centos website itself. >>>>>>>> >>>>>>>> donald >>>>>>>> >>>>>>>> On Tue, Feb 27, 2018 at 1:34 PM, Lou Berger <lberger(a)labn.net <mailto:lberger@labn.net> <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote: >>>>>>>>> Thanks for the notes! >>>>>>>>> >>>>>>>>> On 2/27/2018 12:56 PM, Quentin Young wrote: >>>>>>>>>> - Seeing as Centos 6 went EOL in May 2017, it is no longer supported; to >>>>>>>>>> be >>>>>>>>>> noted in docs >>>>>>>>> >>>>>>>>> umm, per https://access.redhat.com/support/policy/updates/errata <https://access.redhat.com/support/policy/updates/errata> >>>>>>>>> Linux 6, EUS 6.7 (ends December 31, 2018) >>>>>>>>> V6 End of Maintenance Support 2 (Product retirement): June 30, 2024 >>>>>>>>> >>>>>>>>> I know of a fair number of folks still using 6.x, I think EOL support is >>>>>>>>> premature. >>>>>>>>> I think FRR support is needed through *at least* the end of this year. >>>>>>>>> >>>>>>>>> Lou >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> dev mailing list >>>>>>>>> dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> <mailto:dev@lists.frrouting.org <mailto:dev@lists.frrouting.org>> >>>>>>>>> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dev mailing list >>>>>>> dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> <mailto:dev@lists.frrouting.org <mailto:dev@lists.frrouting.org>> >>>>>>> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev> >>>>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> dev mailing list >>> dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> >>> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev>

2 1

FRR Technical Meeting Notes - 02/27/2018
by Quentin Young 03 Mar '18

03 Mar '18

*********************************************** FRR Technical Meeting Notes - February 27, 2018 *********************************************** Policy on support for EOL platforms ----------------------------------- - Should we support EOL platforms? Group consensus = No - Moving forward we will not explicitly support EOL platforms - Keep these platforms in CI, but remove as soon as it becomes inconvenient to maintain - Seeing as Centos 6 went EOL in May 2017, it is no longer supported; to be noted in docs Kernel minimum version requirement discussion --------------------------------------------- - What should our policy be on minimum kernel version needed for networking features? - Paul Z: Zebra should warn if a user tries to configure a feature and it's not supported - Martin W: `show features` command to inform user would be useful - Others: Agreed on both counts - Donald: If we implement the above, developers should be mindful when implementing kernel-specific features to update both of these things and it will be something to look for in future code reviews. Issues ------ Updates in individual issues. #1777, #1778 - Discussion postponed until Lou is present #1794 - General group consensus to stick with kernel style in this regard #1803 - Some people recall this being fixed in the past, Renato to take a look Pull Requests ------------- Updates in individual PRs. - #1711: Namespace VRF now in, thanks Philippe - #1704: Some packaging nits to fix, then good to go; ETA < 1 week Topotest PEP8 ------------- Martin & Rafael not too keen on reformatting whole codebase right now due to activity, but agree it might be worth looking at in the future. See further discussion here: https://github.com/FRRouting/topotests/issues/73#issuecomment-368952010

6 11