- dev - lists.frrouting.org

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

09 Nov '17

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 1461297: Null pointer dereferences (REVERSE_INULL) /bgpd/rfapi/bgp_rfapi_cfg.c: 1468 in vnc_export_nvegroup() ________________________________________________________________________________________________________ *** CID 1461297: Null pointer dereferences (REVERSE_INULL) /bgpd/rfapi/bgp_rfapi_cfg.c: 1468 in vnc_export_nvegroup() 1462 if (rfg_new == NULL) { 1463 rfg_new = bgp_rfapi_cfg_match_byname(bgp, argv[5]->arg, 1464 RFAPI_GROUP_CFG_VRF); 1465 vnc_add_vrf_opener(bgp, rfg_new); 1466 } 1467 >>> CID 1461297: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "rfg_new" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1468 if (rfg_new == NULL) { 1469 vty_out(vty, "Can't find group named \"%s\".\n", argv[5]->arg); 1470 return CMD_WARNING_CONFIG_FAILED; 1471 } 1472 1473 if (argv[2]->arg[0] == 'b') { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Slack access
by Juergen Werner 07 Nov '17

07 Nov '17

Hi, my name is Juergen and I recently raised my first pull request. An acquaintance of mine, @cfra, pointed me to this project and I would like to contribute to it. Is this the right place to ask for access to the Slack channel? Best regards, Juergen

3 2

Last Notice: TSC Voting ends in a few hours....
by Alistair Woodman 07 Nov '17

07 Nov '17

Dear FRR maintainers, Voting for the TSC will close before tomorrow's call. If you have not voted, but intend to, you only have a few hours.

1 0

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

06 Nov '17

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 1461144: Memory - illegal accesses (BUFFER_SIZE_WARNING) /ospfd/ospf_vty.c: 4162 in show_ip_ospf_neighbor_sub() ________________________________________________________________________________________________________ *** CID 1461144: Memory - illegal accesses (BUFFER_SIZE_WARNING) /ospfd/ospf_vty.c: 4162 in show_ip_ospf_neighbor_sub() 4156 4157 if (nbr->state == NSM_Attempt && 4158 nbr->router_id.s_addr == 0) 4159 strncpy(neigh_str, "neighbor", 4160 INET_ADDRSTRLEN); 4161 else >>> CID 1461144: Memory - illegal accesses (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "neigh_str" of size 16 bytes might leave the destination string unterminated. 4162 strncpy(neigh_str, 4163 inet_ntoa(nbr->router_id), 4164 INET_ADDRSTRLEN); 4165 4166 json_object_object_get_ex(json, neigh_str, 4167 &json_neigh_array); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click 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 03 Nov '17

03 Nov '17

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 1460438: Uninitialized variables (UNINIT) /eigrpd/eigrp_reply.c: 173 in eigrp_reply_receive() ________________________________________________________________________________________________________ *** CID 1460438: Uninitialized variables (UNINIT) /eigrpd/eigrp_reply.c: 173 in eigrp_reply_receive() 167 eigrp->topology_table, &dest_addr); 168 /* 169 * Destination must exists 170 */ 171 if (!dest) { 172 char buf[PREFIX_STRLEN]; >>> CID 1460438: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "buf" when calling "strlen". 173 zlog_err("%s: Received prefix %s which we do not know about", 174 __PRETTY_FUNCTION__, 175 prefix2str(&dest_addr, buf, strlen(buf))); 176 continue; 177 } 178 ** CID 1460437: Resource leaks (RESOURCE_LEAK) /eigrpd/eigrp_reply.c: 160 in eigrp_reply_receive() ________________________________________________________________________________________________________ *** CID 1460437: Resource leaks (RESOURCE_LEAK) /eigrpd/eigrp_reply.c: 160 in eigrp_reply_receive() 154 continue; 155 156 struct prefix dest_addr; 157 158 stream_set_getp(s, s->getp - sizeof(u_int16_t)); 159 >>> CID 1460437: Resource leaks (RESOURCE_LEAK) >>> Overwriting "tlv" in "tlv = eigrp_read_ipv4_tlv(s)" leaks the storage that "tlv" points to. 160 tlv = eigrp_read_ipv4_tlv(s); 161 162 dest_addr.family = AF_INET; 163 dest_addr.u.prefix4 = tlv->destination; 164 dest_addr.prefixlen = tlv->prefix_length; 165 struct eigrp_prefix_entry *dest = ** CID 1460436: Control flow issues (DEADCODE) /eigrpd/eigrp_query.c: 240 in eigrp_send_query() ________________________________________________________________________________________________________ *** CID 1460436: Control flow issues (DEADCODE) /eigrpd/eigrp_query.c: 240 in eigrp_send_query() 234 new_packet = true; 235 } 236 } 237 238 if (!has_tlv) { 239 if (ep) >>> CID 1460436: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "eigrp_packet_free(ep);". 240 eigrp_packet_free(ep); 241 return; 242 } 243 244 if ((ei->params.auth_type == EIGRP_AUTH_TYPE_MD5) 245 && ei->params.auth_keychain != NULL) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

A question about the # of vrf per router or switch can support by FRR?
by Jay Chen 03 Nov '17

03 Nov '17

Is there a limit that the # of vrf can support for a single switch or router by using FRR? Thanks, Jay

5 9

[Action] Nominations for the TSC...
by Alistair Woodman 27 Oct '17

27 Oct '17

Dear Maintainers, I'm looking for nominations for the TSC election. (Per the by-laws this election is due this month). I intend to follow the following process. 1) ask you (the maintainers) for new nominations to the TSC. (These can include self nominations) 2) assume existing TSC members will wish to continue (i.e. They are automatically nominated) (Any exiting TSC member wishing to stand down may unicast me) 3) create the union of the two sets 4) run the election per the "Multi-winner Single Transferable Vote" process per the TSC doc. Please provide me with nominations by COB this Friday the 27th. /a Sent from my iPad

2 2

FRR Zebra/FPM interactions
by Donald Sharp 25 Oct '17

25 Oct '17

Thorvald - Hi! I'm Donald Sharp, I'm working on FRR, I'm discussing with you this PR: https://github.com/FRRouting/frr/pull/1350 First I'd like to apologize for the slow response to your enquiries on the PR. I decided to reach out directly to you because I feel like email might be a bit better medium to talk about what our plans are and to describe what I see the future of zebra is. Our plans are not currently set in stone but we do have some broad strokes of what we want to accomplish: 1) Separate the south bound API in such a manner that we use a starting function call. Currently both the FPM interactions and zebra/rt.h are our south bound interfaces As an example rib_install_kernel does this: rib_install_kernel hook_call (rib_update) -> FPM interactions kernel_route_rib -> Rib install for kernel we are working on. if (success) Set some values We want it to do this: rib_install_kernel kernel_route_rib -> List of hooks to call: FPM Interactions Rib install for kernel we are working on Anything else we add as a rib_update hook if (success) Call kernel_route_rib_success() function Now rinse/repeat this for all rt.h southbound api's. 2) Separate processing of southbound api into it's own true pthread( not lib/thread.h ): Currently the FPM has a TAILQ_ENTRY(rib_dest_t_) in rib_dest_t(rib.h) to track and process FPM install/deletes/whatever.. I would like to convert this data structure to the control point for what has been communicated south bound. Then allow the southbound api's to bundle the installation into whatever however they would like to do so in a timeframe that it would like to do so as well. I think this would allow us to do things like bundling of netlink messages to the kernel. Kernel insertion on linux as it stands is absurdly slow and needs to be sped up. 3) Arbitrary hook levels: We would also like the ability for FPM interactions and Rib install hooks have the ability to have sub hooks as well if they would like to as well. As an example the rib interactions could have a route-map application hook before passing to the kernel. 4) Allow which hooks to be used via a control mechanism( this is what you were really asking for ) to control who get's called. As you noticed it would be nice to have a way to control which soutbound hooks are actually installed and used. Now where to start? I personally think we need to start with #1. #2 and #4 will flow from that imo. donald PS - If you would like more immediate access than email, we use a public slack (frrouting.slack.com) if you would like an invite please let me know.

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 25 Oct '17

25 Oct '17

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. 24 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 1458607: Uninitialized variables (UNINIT) /vtysh/vtysh.c: 811 in vtysh_rl_describe() ________________________________________________________________________________________________________ *** CID 1458607: Uninitialized variables (UNINIT) /vtysh/vtysh.c: 811 in vtysh_rl_describe() 805 } else if (rl_end && isspace((int)rl_line_buffer[rl_end - 1])) 806 vector_set(vline, NULL); 807 808 fprintf(stdout, "\n"); 809 810 /* Ambiguous and no match error. */ >>> CID 1458607: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 811 switch (ret) { 812 case CMD_ERR_AMBIGUOUS: 813 cmd_free_strvec(vline); 814 fprintf(stdout, "%% Ambiguous command.\n"); 815 rl_on_new_line(); 816 return 0; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

VTY status 13 while sending config over vty socket
by $iddhe$h Divekar 23 Oct '17

23 Oct '17

Hi, Am getting following error when sending config over vty socket. VTY status 13. Below is the config am trying to send. It happens when "redistribute connected" is sent over the socket. configure terminal router bgp 1234 vrf foo neighbor 2.2.2.2 remote-as 3456 neighbor 2.2.2.2 shutdown address-family ipv6 unicast redistribute connected exit-address-family address-family ipv6 unicast redistribute static exit-address-family address-family ipv4 unicast redistribute connected exit-address-family address-family ipv4 unicast redistribute static exit-address-family end If I do show running I see following config applied. router bgp 1234 vrf foo neighbor 2.2.2.2 remote-as 3456 neighbor 2.2.2.2 shutdown ! address-family ipv6 unicast redistribute connected exit-address-family ! Is there anything wrong with the config. Copy pasting the config directly works fine. -- -$iddhesh.

2 3