January 2020 - dev - lists.frrouting.org

Regarding support for rsvp-te support in free routing
by Rhene Kavi 20 Feb '20

20 Feb '20

Hi All, Do we have any plans to support rsvp-te Thanks in advance KaviRhene

4 3

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

31 Jan '20

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 15 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 47 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 15 of 15 defect(s) ** CID 1491106: Incorrect expression (USELESS_CALL) ________________________________________________________________________________________________________ *** CID 1491106: Incorrect expression (USELESS_CALL) /bgpd/bgp_vty.c: 9606 in bgp_show_neighbor_graceful_restart_capability_per_afi_safi() 9600 vty_out(vty, " %s :\n", 9601 get_afi_safi_str(afi, safi, false)); 9602 9603 vty_out(vty, 9604 " F bit : "); 9605 } else >>> CID 1491106: Incorrect expression (USELESS_CALL) >>> Calling "get_afi_safi_str(afi, safi, true)" is only useful for its return value, which is ignored. 9606 get_afi_safi_str(afi, safi, true); 9607 9608 if (peer->nsf[afi][safi] 9609 && CHECK_FLAG( 9610 peer->af_cap[afi][safi], 9611 PEER_CAP_RESTART_AF_PRESERVE_RCV)) { ** CID 1491105: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1491105: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_route.c: 10724 in show_ip_bgp_regexp() 10718 return CMD_WARNING; 10719 10720 // get index of regex 10721 if (argv_find(argv, argc, "REGEX", &idx)) 10722 regstr = argv[idx]->arg; 10723 >>> CID 1491105: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "regstr" to "bgp_show_regexp", which dereferences it. 10724 return bgp_show_regexp(vty, bgp, (const char *)regstr, afi, safi, 10725 bgp_show_type_regexp, uj); 10726 } 10727 10728 DEFUN (show_ip_bgp_instance_all, 10729 show_ip_bgp_instance_all_cmd, ** CID 1491104: (CHECKED_RETURN) /lib/agentx.c: 71 in agentx_read() /lib/agentx.c: 79 in agentx_read() ________________________________________________________________________________________________________ *** CID 1491104: (CHECKED_RETURN) /lib/agentx.c: 71 in agentx_read() 65 if (-1 == flags) 66 return -1; 67 68 if (flags & O_NONBLOCK) 69 nonblock = true; 70 else >>> CID 1491104: (CHECKED_RETURN) >>> Calling "fcntl(t->u.fd, 4, flags | 0x800)" without checking return value. This library function may fail and return an error code. 71 fcntl(THREAD_FD(t), F_SETFL, flags | O_NONBLOCK); 72 73 FD_ZERO(&fds); 74 FD_SET(THREAD_FD(t), &fds); 75 snmp_read(&fds); 76 /lib/agentx.c: 79 in agentx_read() 73 FD_ZERO(&fds); 74 FD_SET(THREAD_FD(t), &fds); 75 snmp_read(&fds); 76 77 /* Reset the flag */ 78 if (!nonblock) >>> CID 1491104: (CHECKED_RETURN) >>> Calling "fcntl(t->u.fd, 4, flags)" without checking return value. This library function may fail and return an error code. 79 fcntl(THREAD_FD(t), F_SETFL, flags); 80 81 netsnmp_check_outstanding_agent_requests(); 82 agentx_events_update(); 83 return 0; 84 } ** CID 1302522: (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 2002 in ospfVirtIfLookup() /ospfd/ospf_snmp.c: 2009 in ospfVirtIfLookup() /ospfd/ospf_snmp.c: 1985 in ospfVirtIfLookup() ________________________________________________________________________________________________________ *** CID 1302522: (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 2002 in ospfVirtIfLookup() 1996 len = IN_ADDR_SIZE; 1997 oid2in_addr(name + v->namelen, len, area_id); 1998 1999 len = *length - v->namelen - IN_ADDR_SIZE; 2000 if (len > IN_ADDR_SIZE) 2001 len = IN_ADDR_SIZE; >>> CID 1302522: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "name + v->namelen" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 2002 oid2in_addr(name + v->namelen + IN_ADDR_SIZE, len, neighbor); 2003 2004 vl_data = ospf_snmp_vl_lookup_next(area_id, neighbor, first); 2005 2006 if (vl_data) { 2007 *length = v->namelen + IN_ADDR_SIZE + IN_ADDR_SIZE; /ospfd/ospf_snmp.c: 2009 in ospfVirtIfLookup() 2003 2004 vl_data = ospf_snmp_vl_lookup_next(area_id, neighbor, first); 2005 2006 if (vl_data) { 2007 *length = v->namelen + IN_ADDR_SIZE + IN_ADDR_SIZE; 2008 oid_copy_addr(name + v->namelen, area_id, IN_ADDR_SIZE); >>> CID 1302522: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "name + v->namelen" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 2009 oid_copy_addr(name + v->namelen + IN_ADDR_SIZE, 2010 neighbor, IN_ADDR_SIZE); 2011 return vl_data; 2012 } 2013 } 2014 return NULL; /ospfd/ospf_snmp.c: 1985 in ospfVirtIfLookup() 1979 1980 if (exact) { 1981 if (*length != v->namelen + IN_ADDR_SIZE + IN_ADDR_SIZE) 1982 return NULL; 1983 1984 oid2in_addr(name + v->namelen, IN_ADDR_SIZE, area_id); >>> CID 1302522: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "name + v->namelen" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1985 oid2in_addr(name + v->namelen + IN_ADDR_SIZE, IN_ADDR_SIZE, 1986 neighbor); 1987 1988 return ospf_snmp_vl_lookup(area_id, neighbor); 1989 } else { 1990 first = 0; ** CID 1302521: (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 1043 in ospfLsdbLookup() /ospfd/ospf_snmp.c: 961 in ospfLsdbLookup() /ospfd/ospf_snmp.c: 1048 in ospfLsdbLookup() /ospfd/ospf_snmp.c: 1018 in ospfLsdbLookup() /ospfd/ospf_snmp.c: 953 in ospfLsdbLookup() ________________________________________________________________________________________________________ *** CID 1302521: (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 1043 in ospfLsdbLookup() 1037 /* Fill in length. */ 1038 *length = v->namelen + OSPF_LSDB_ENTRY_OFFSET; 1039 1040 /* Fill in value. */ 1041 offset = name + v->namelen; 1042 oid_copy_addr(offset, area_id, IN_ADDR_SIZE); >>> CID 1302521: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1043 offset += IN_ADDR_SIZE; 1044 *offset = lsa->data->type; 1045 offset++; 1046 oid_copy_addr(offset, &lsa->data->id, 1047 IN_ADDR_SIZE); 1048 offset += IN_ADDR_SIZE; /ospfd/ospf_snmp.c: 961 in ospfLsdbLookup() 955 /* Type. */ 956 *type = *offset; 957 offset++; 958 959 /* LS ID. */ 960 oid2in_addr(offset, IN_ADDR_SIZE, ls_id); >>> CID 1302521: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 961 offset += IN_ADDR_SIZE; 962 963 /* Router ID. */ 964 oid2in_addr(offset, IN_ADDR_SIZE, router_id); 965 966 /* Lookup LSDB. */ /ospfd/ospf_snmp.c: 1048 in ospfLsdbLookup() 1042 oid_copy_addr(offset, area_id, IN_ADDR_SIZE); 1043 offset += IN_ADDR_SIZE; 1044 *offset = lsa->data->type; 1045 offset++; 1046 oid_copy_addr(offset, &lsa->data->id, 1047 IN_ADDR_SIZE); >>> CID 1302521: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1048 offset += IN_ADDR_SIZE; 1049 oid_copy_addr(offset, &lsa->data->adv_router, 1050 IN_ADDR_SIZE); 1051 1052 return lsa; 1053 } /ospfd/ospf_snmp.c: 1018 in ospfLsdbLookup() 1012 len = IN_ADDR_SIZE; 1013 1014 oid2in_addr(offset, len, ls_id); 1015 } 1016 1017 /* Router ID. */ >>> CID 1302521: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1018 offset += IN_ADDR_SIZE; 1019 offsetlen -= IN_ADDR_SIZE; 1020 len = offsetlen; 1021 1022 if (len <= 0) 1023 router_id_next = 1; /ospfd/ospf_snmp.c: 953 in ospfLsdbLookup() 947 948 /* Lookup area first. */ 949 oid2in_addr(offset, IN_ADDR_SIZE, area_id); 950 area = ospf_area_lookup_by_area_id(ospf, *area_id); 951 if (!area) 952 return NULL; >>> CID 1302521: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 953 offset += IN_ADDR_SIZE; 954 955 /* Type. */ 956 *type = *offset; 957 offset++; 958 ** CID 1302520: Incorrect expression (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 1814 in ospfIfMetricLookup() ________________________________________________________________________________________________________ *** CID 1302520: Incorrect expression (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 1814 in ospfIfMetricLookup() 1808 oi = ospf_snmp_if_lookup_next(ifaddr, ifindex, ifaddr_next, 1809 ifindex_next); 1810 if (oi) { 1811 *length = v->namelen + IN_ADDR_SIZE + 1 + 1; 1812 offset = name + v->namelen; 1813 oid_copy_addr(offset, ifaddr, IN_ADDR_SIZE); >>> CID 1302520: Incorrect expression (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1814 offset += IN_ADDR_SIZE; 1815 *offset = *ifindex; 1816 offset++; 1817 *offset = OSPF_SNMP_METRIC_VALUE; 1818 return oi; 1819 } ** CID 1302519: (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 2441 in ospfExtLsdbLookup() /ospfd/ospf_snmp.c: 2390 in ospfExtLsdbLookup() /ospfd/ospf_snmp.c: 2418 in ospfExtLsdbLookup() ________________________________________________________________________________________________________ *** CID 1302519: (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 2441 in ospfExtLsdbLookup() 2435 /* Fill in value. */ 2436 offset = name + v->namelen; 2437 2438 *offset = OSPF_AS_EXTERNAL_LSA; 2439 offset++; 2440 oid_copy_addr(offset, &lsa->data->id, IN_ADDR_SIZE); >>> CID 1302519: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 2441 offset += IN_ADDR_SIZE; 2442 oid_copy_addr(offset, &lsa->data->adv_router, 2443 IN_ADDR_SIZE); 2444 2445 return lsa; 2446 } /ospfd/ospf_snmp.c: 2390 in ospfExtLsdbLookup() 2384 2385 if (lsa_type != *type) 2386 return NULL; 2387 2388 /* LS ID. */ 2389 oid2in_addr(offset, IN_ADDR_SIZE, ls_id); >>> CID 1302519: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 2390 offset += IN_ADDR_SIZE; 2391 2392 /* Router ID. */ 2393 oid2in_addr(offset, IN_ADDR_SIZE, router_id); 2394 2395 return ospf_lsdb_lookup_by_id(ospf->lsdb, *type, *ls_id, /ospfd/ospf_snmp.c: 2418 in ospfExtLsdbLookup() 2412 len = offsetlen; 2413 if (len > IN_ADDR_SIZE) 2414 len = IN_ADDR_SIZE; 2415 2416 oid2in_addr(offset, len, ls_id); 2417 >>> CID 1302519: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 2418 offset += IN_ADDR_SIZE; 2419 offsetlen -= IN_ADDR_SIZE; 2420 2421 /* Router ID. */ 2422 len = offsetlen; 2423 if (len > IN_ADDR_SIZE) ** CID 1302518: (SIZEOF_MISMATCH) /bgpd/bgp_snmp.c: 736 in bgp4PathAttrLookup() /bgpd/bgp_snmp.c: 702 in bgp4PathAttrLookup() /bgpd/bgp_snmp.c: 793 in bgp4PathAttrLookup() ________________________________________________________________________________________________________ *** CID 1302518: (SIZEOF_MISMATCH) /bgpd/bgp_snmp.c: 736 in bgp4PathAttrLookup() 730 else { 731 if (len > IN_ADDR_SIZE) 732 len = IN_ADDR_SIZE; 733 734 oid2in_addr(offset, len, &addr->prefix); 735 >>> CID 1302518: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 736 offset += IN_ADDR_SIZE; 737 offsetlen -= IN_ADDR_SIZE; 738 739 if (offsetlen > 0) 740 addr->prefixlen = *offset; 741 else /bgpd/bgp_snmp.c: 702 in bgp4PathAttrLookup() 696 if (*length - v->namelen != BGP_PATHATTR_ENTRY_OFFSET) 697 return NULL; 698 699 /* Set OID offset for prefix. */ 700 offset = name + v->namelen; 701 oid2in_addr(offset, IN_ADDR_SIZE, &addr->prefix); >>> CID 1302518: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 702 offset += IN_ADDR_SIZE; 703 704 /* Prefix length. */ 705 addr->prefixlen = *offset; 706 offset++; 707 /bgpd/bgp_snmp.c: 793 in bgp4PathAttrLookup() 787 *length = 788 v->namelen + BGP_PATHATTR_ENTRY_OFFSET; 789 790 offset = name + v->namelen; 791 oid_copy_addr(offset, &rn->p.u.prefix4, 792 IN_ADDR_SIZE); >>> CID 1302518: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 793 offset += IN_ADDR_SIZE; 794 *offset = rn->p.prefixlen; 795 offset++; 796 oid_copy_addr(offset, 797 &min->peer->su.sin.sin_addr, 798 IN_ADDR_SIZE); ** CID 1302517: Incorrect expression (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 1649 in ospfIfLookup() ________________________________________________________________________________________________________ *** CID 1302517: Incorrect expression (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 1649 in ospfIfLookup() 1643 oi = ospf_snmp_if_lookup_next(ifaddr, ifindex, ifaddr_next, 1644 ifindex_next); 1645 if (oi) { 1646 *length = v->namelen + IN_ADDR_SIZE + 1; 1647 offset = name + v->namelen; 1648 oid_copy_addr(offset, ifaddr, IN_ADDR_SIZE); >>> CID 1302517: Incorrect expression (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1649 offset += IN_ADDR_SIZE; 1650 *offset = *ifindex; 1651 return oi; 1652 } 1653 } 1654 return NULL; ** CID 1302516: (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 1192 in ospfAreaRangeLookup() /ospfd/ospf_snmp.c: 1214 in ospfAreaRangeLookup() /ospfd/ospf_snmp.c: 1163 in ospfAreaRangeLookup() ________________________________________________________________________________________________________ *** CID 1302516: (SIZEOF_MISMATCH) /ospfd/ospf_snmp.c: 1192 in ospfAreaRangeLookup() 1186 len == 0 ? 1 : 0); 1187 1188 if (area == NULL) 1189 return NULL; 1190 1191 do { >>> CID 1302516: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1192 offset += IN_ADDR_SIZE; 1193 offsetlen -= IN_ADDR_SIZE; 1194 len = offsetlen; 1195 1196 if (len < 0) 1197 len = 0; /ospfd/ospf_snmp.c: 1214 in ospfAreaRangeLookup() 1208 *length = v->namelen + IN_ADDR_SIZE 1209 + IN_ADDR_SIZE; 1210 1211 /* Fill in value. */ 1212 offset = name + v->namelen; 1213 oid_copy_addr(offset, area_id, IN_ADDR_SIZE); >>> CID 1302516: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1214 offset += IN_ADDR_SIZE; 1215 oid_copy_addr(offset, range_net, IN_ADDR_SIZE); 1216 1217 return range; 1218 } 1219 } while ((area = ospf_area_lookup_next(ospf, area_id, 0)) /ospfd/ospf_snmp.c: 1163 in ospfAreaRangeLookup() 1157 oid2in_addr(offset, IN_ADDR_SIZE, area_id); 1158 1159 area = ospf_area_lookup_by_area_id(ospf, *area_id); 1160 if (!area) 1161 return NULL; 1162 >>> CID 1302516: (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (struct in_addr) */" to pointer "offset" of type "oid *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 8 bytes, of the pointed-to type, "oid". Most likely, "sizeof (struct in_addr)" is extraneous and should be replaced with 1. 1163 offset += IN_ADDR_SIZE; 1164 1165 /* Lookup area range. */ 1166 oid2in_addr(offset, IN_ADDR_SIZE, range_net); 1167 p.prefix = *range_net; 1168 ** CID 1302506: Null pointer dereferences (NULL_RETURNS) /ospfd/ospf_snmp.c: 812 in ospfStubAreaLookup() ________________________________________________________________________________________________________ *** CID 1302506: Null pointer dereferences (NULL_RETURNS) /ospfd/ospf_snmp.c: 812 in ospfStubAreaLookup() 806 return NULL; 807 808 oid2in_addr(name + v->namelen, sizeof(struct in_addr), addr); 809 810 area = ospf_area_lookup_by_area_id(ospf, *addr); 811 >>> CID 1302506: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "area", which is known to be "NULL". 812 if (area->external_routing == OSPF_AREA_STUB) 813 return area; 814 else 815 return NULL; 816 } else { 817 len = *length - v->namelen; ** CID 1302468: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1302468: Memory - corruptions (ARRAY_VS_SINGLETON) /zebra/zebra_snmp.c: 371 in get_fwtable_route_node() 365 /* For exact: search matching entry in rib table. */ 366 367 if (exact) { 368 if (policy) /* Not supported (yet?) */ 369 return; 370 for (*np = route_top(table); *np; *np = route_next(*np)) { >>> CID 1302468: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "&(*np)->p.u.prefix" to function "in_addr_cmp" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 371 if (!in_addr_cmp(&(*np)->p.u.prefix, 372 (uint8_t *)&dest)) { 373 RNODE_FOREACH_RE (*np, *re) { 374 if (!in_addr_cmp((uint8_t *)&(*re)->nhe 375 ->nhg->nexthop 376 ->gate.ipv4, ** CID 1302467: (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1302467: (ARRAY_VS_SINGLETON) /zebra/zebra_snmp.c: 269 in check_replace() 263 if (!*np) { 264 *np = np2; 265 *re = re2; 266 return; 267 } 268 >>> CID 1302467: (ARRAY_VS_SINGLETON) >>> Passing "&np2->p.u.prefix" to function "in_addr_cmp" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 269 if (in_addr_cmp(&(*np)->p.u.prefix, &np2->p.u.prefix) < 0) 270 return; 271 if (in_addr_cmp(&(*np)->p.u.prefix, &np2->p.u.prefix) > 0) { 272 *np = np2; 273 *re = re2; 274 return; /zebra/zebra_snmp.c: 271 in check_replace() 265 *re = re2; 266 return; 267 } 268 269 if (in_addr_cmp(&(*np)->p.u.prefix, &np2->p.u.prefix) < 0) 270 return; >>> CID 1302467: (ARRAY_VS_SINGLETON) >>> Passing "&np2->p.u.prefix" to function "in_addr_cmp" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 271 if (in_addr_cmp(&(*np)->p.u.prefix, &np2->p.u.prefix) > 0) { 272 *np = np2; 273 *re = re2; 274 return; 275 } 276 ** CID 1302466: (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1302466: (ARRAY_VS_SINGLETON) /zebra/zebra_snmp.c: 392 in get_fwtable_route_node() 386 387 /* Search next best entry */ 388 389 for (np2 = route_top(table); np2; np2 = route_next(np2)) { 390 391 /* Check destination first */ >>> CID 1302466: (ARRAY_VS_SINGLETON) >>> Passing "&np2->p.u.prefix" to function "in_addr_cmp" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 392 if (in_addr_cmp(&np2->p.u.prefix, (uint8_t *)&dest) > 0) 393 RNODE_FOREACH_RE (np2, re2) { 394 check_replace(np2, re2, np, re); 395 } 396 397 if (in_addr_cmp(&np2->p.u.prefix, (uint8_t *)&dest) /zebra/zebra_snmp.c: 397 in get_fwtable_route_node() 391 /* Check destination first */ 392 if (in_addr_cmp(&np2->p.u.prefix, (uint8_t *)&dest) > 0) 393 RNODE_FOREACH_RE (np2, re2) { 394 check_replace(np2, re2, np, re); 395 } 396 >>> CID 1302466: (ARRAY_VS_SINGLETON) >>> Passing "&np2->p.u.prefix" to function "in_addr_cmp" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 397 if (in_addr_cmp(&np2->p.u.prefix, (uint8_t *)&dest) 398 == 0) { /* have to look at each re individually */ 399 RNODE_FOREACH_RE (np2, re2) { 400 int proto2, policy2; 401 402 proto2 = proto_trans(re2->type); ** CID 1302465: (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1302465: (ARRAY_VS_SINGLETON) /zebra/zebra_snmp.c: 271 in check_replace() 265 *re = re2; 266 return; 267 } 268 269 if (in_addr_cmp(&(*np)->p.u.prefix, &np2->p.u.prefix) < 0) 270 return; >>> CID 1302465: (ARRAY_VS_SINGLETON) >>> Passing "&(*np)->p.u.prefix" to function "in_addr_cmp" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 271 if (in_addr_cmp(&(*np)->p.u.prefix, &np2->p.u.prefix) > 0) { 272 *np = np2; 273 *re = re2; 274 return; 275 } 276 /zebra/zebra_snmp.c: 269 in check_replace() 263 if (!*np) { 264 *np = np2; 265 *re = re2; 266 return; 267 } 268 >>> CID 1302465: (ARRAY_VS_SINGLETON) >>> Passing "&(*np)->p.u.prefix" to function "in_addr_cmp" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 269 if (in_addr_cmp(&(*np)->p.u.prefix, &np2->p.u.prefix) < 0) 270 return; 271 if (in_addr_cmp(&(*np)->p.u.prefix, &np2->p.u.prefix) > 0) { 272 *np = np2; 273 *re = re2; 274 return; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Northbound discussion
by Santosh P K 31 Jan '20

31 Jan '20

Meeting invite for ongoing northbound discussions.

1 0

Northbound discussion
by Santosh P K 30 Jan '20

30 Jan '20

Meeting invite for ongoing northbound discussions.

1 0

Re: [dev] Northbound regular meeting
by Santosh P K 30 Jan '20

30 Jan '20

Hello All, I have attached example we have tried for nexthop mandatory keys. Also below are the topics we would like to discuss. 1. Nexthop groups and keys example. 2. Static we have addressed all review comments and it is ready for review and merge. 3. Nexthop yang have addressed all review comments and it is ready for review and merge. 4. Common routing is ready for review and merge. 5. BGP yang we would like to bring up for review and discussion. Thanks Santosh P K On 24/01/20, 5:29 PM, "dev on behalf of Santosh P K via dev" <dev-bounces(a)lists.frrouting.org on behalf of dev(a)lists.frrouting.org> wrote: _______________________________________________ dev mailing list dev(a)lists.frrouting.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frr…

1 0

2nd Telco meeting
by olivier.dugeon＠orange.com 30 Jan '20

30 Jan '20

When: Wednesday, February 05, 2020 3:00 PM-4:00 PM. (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna Where: BlueJean https://bluejeans.com/9192742159 *~*~*~*~*~*~*~*~*~* Hi all, This is an invite for the 2nd Telco's meeting. Preliminary agenda is as follow: * Agenda approval * Approval of Doodle pool (best choice is for now bi-weekly meeting the Wednesdat from 15h to 16h (GMT+1) * Traffic Engineering Data Base technical discussion * AOB Don't hesisate to answer the Doodle pool if not already done. 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.

1 0

Telco / SP feature planning in FRR -- Proposed Agenda for Wednesday 1/22 call. 17:00 CET / 11:00 ET / 08:00 PT
by Alistair Woodman 30 Jan '20

30 Jan '20

https://bluejeans.com/9192742159 (thanks to Donald for the Blue Jeans channel use) All, Here is a proposed agenda for tomorrow's call on Telco / SP feature planning in FRR. (Note: I will not be on the call as I'll be on a plane. Feel free to adjust the agenda to meet your needs) The primary purpose Olivier and I had for the call is to allow everyone with an interest in this space to share their interest and explain their existing work. As such, I've set up this first meeting to act as a method of information dissemination of who is doing what and interested in what. (No one expect resolution of architectural choices on this first call) I'm personally aware that Orange, LabN, Volta and NetDEF all have interest in this space. Others may also want to share their interest / activates. I've attached a one page description of NetDEF's activities in this space. Any org / individual wanting to share their activates should please use this slide as a template to produce their own "Show & Tell" slide Draft Agenda (adjust, as the group sees fit) 1) Interested Parties "Show & Tell" slides (5 mins per slide. No deep dive, just a brief overview to describe their resources and focus) a. Orange b. LabN c. NetDEF d. Volta e. <any other org / person> 2) Discussion of how often we should have calls (weekly ? bi-weekly ?) 3) Discussion of where to share code / work (Olivier has a development branch: Should we use this ? Any other ideas ?)(Set up a Slack Channel ?) 4) Any questions about Olivier's Presentation from today's call (should there be any time left) /a

4 3

downgrading to a deb frr package
by Yasuhiro Ohara 30 Jan '20

30 Jan '20

Hi. (Please forward me to an appropriate mailing list if this is not the place.) Regarding the Debian packages <https://deb.frrouting.org/>, is there any way to downgrade to an older frr debian package? I just upgraded from frr-7.1 to frr-7.2, but for some reason (in a production environment) I might want to get back to the previous frr-7.1 version, which I tested and am sure it's okay for my specific production use. (Sorry if this is a newbie deb question...) Thanks in advance. Best regards, Yasu

1 0

Re: [dev] Northbound regular meeting
by Santosh P K 24 Jan '20

24 Jan '20

Hello All, Today we would like to discuss below PRs which are ready for review and merge. Routing protocol - https://github.com/FRRouting/frr/pull/5530 (All protocols are dependent on this) Nexthop - https://github.com/FRRouting/frr/pull/5578 (All comments addressed) Static - https://github.com/FRRouting/frr/pull/5460 (All comments addressed and nexthop yang changes are being used) Also we would like https://github.com/FRRouting/frr/pull/5183 which is route-map which does not include BGP specific match and set action. We have wanted to augment and facing issues. We have proposal for the same so that all protocols can augment to generic route-map. Thanks Santosh P K On 08/01/20, 12:52 AM, "dev on behalf of Santosh P K via dev" <dev-bounces(a)lists.frrouting.org on behalf of dev(a)lists.frrouting.org> wrote: _______________________________________________ dev mailing list dev(a)lists.frrouting.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frr…

1 0

Re: [dev] my second question
by Quentin Young 22 Jan '20

22 Jan '20

Mike- Error message: "Please ensure that the daemon is not already running" Scenario: "The daemon is running" You can't run two instances of FRR at the same time (unless they're namespaced, etc etc). If you want to restart it you need to kill the existing process(es) and launch a new one. Quentin On Tue, Jan 21, 2020 at 8:13 AM Mike Mazarick < mike.mazarick(a)virtudatacenter.com> wrote: > I typed: > > mazarick@virtusecure:~$ sudo frr.bgpd-debug > > [sudo] password for mazarick: > > > > I got: > > 2020/01/21 07:49:16 errors: BGP: [EC 100663303] Could not lock pid_file > /var/snap/frr/87/bgpd.pid (Resource temporarily unavailable), exiting. > Please ensure that the daemon is not already running > > > > I did some looking. The daemon is running and the file that controls it > (/var/snap/frr/87bgpd.id) is a zero length file. > > > > -HELP!! > > > > I want to thank Eric Frazier for assistance getting me this far by using > “sudo snap install frr” and Phil Wiggins for pointing out PPA problems from > my previous efforts (before I was on this mailing list). I asked Phil for > the name of the command, but I figured it out. > > > > Mike Mazarick > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev >

1 0