- dev - lists.frrouting.org

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

30 May '17

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. 10 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 1438075: Program hangs (ORDER_REVERSAL) /lib/thread.c: 936 in thread_cancel() ________________________________________________________________________________________________________ *** CID 1438075: Program hangs (ORDER_REVERSAL) /lib/thread.c: 936 in thread_cancel() 930 { 931 struct thread_list *list = NULL; 932 struct pqueue *queue = NULL; 933 struct thread **thread_array = NULL; 934 935 pthread_mutex_lock (&thread->mtx); >>> CID 1438075: Program hangs (ORDER_REVERSAL) >>> Calling "pthread_mutex_lock" acquires lock "thread_master.mtx" while holding lock "thread.mtx" (count: 1 / 5). 936 pthread_mutex_lock (&thread->master->mtx); 937 938 assert (pthread_self() == thread->master->owner); 939 940 switch (thread->type) 941 { ** CID 1438074: Control flow issues (DEADCODE) /pimd/pim_cmd.c: 5950 in ip_pim_bfd() ________________________________________________________________________________________________________ *** CID 1438074: Control flow issues (DEADCODE) /pimd/pim_cmd.c: 5950 in ip_pim_bfd() 5944 { 5945 VTY_DECLVAR_CONTEXT(interface, ifp); 5946 struct pim_interface *pim_ifp = NULL; 5947 struct bfd_info *bfd_info = NULL; 5948 5949 if (!ifp) >>> CID 1438074: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 0;". 5950 return CMD_SUCCESS; 5951 pim_ifp = ifp->info; 5952 if (!pim_ifp) 5953 return CMD_SUCCESS; 5954 bfd_info = pim_ifp->bfd_info; 5955 ________________________________________________________________________________________________________ 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

Package Discussion (Doodle for times)
by Martin Winter 30 May '17

30 May '17

https://doodle.com/poll/5bx4c7krsb3xctxu Pick your times if you want to be part of the discussion… - Martin

5 7

(no subject)
by Bingen Eguzkitza 30 May '17

30 May '17

Hi all, as we talked during last weekly technical meeting, here you have a Doodle to set up a meeting to discuss the Zebra Dataplane module: https://doodle.com/poll/uwyy7t6edqbg2ucu For reference, this is the PR: https://github.com/FRRouting/frr/pull/602 Choose the options that work for you if you want to be part of the discussion. Thanks, ßingen.

1 0

Items for Agenda for next (or soon) weekly call
by Martin Winter 26 May '17

26 May '17

Just a quick note for agenda items on a tuesday call (or do we prefer to discuss on list?) - Process on updating website not current process, but how to do this in future and how to get there and who is doing it - Testcases for new features We are getting a lot of new features in which are not yet covered by any test cases in our CI system. I assume most/all contributors test them on their own before submitting, but should we have some requirement to provide some tests with any/most new features? Could be a hard requirement like additions to unit test or topotest (or any other kind of test) or some soft requirement in a description on how it was tested I don’t see any of these urgent, but would love to have some discussion… - Martin

1 0

Package discussion & Init scripts
by Martin Winter 24 May '17

24 May '17

So to start this discussion on the packaging, I would like to base this discussion on 2 decisions which need to be done first: -- 1) Do we want to use 'vtysh integrated-config' for FRR 2.0 packages ? I believe we all agree that this is the way to go in the future. I'm certain we had this discussion before (but can't find pointers in my email). My understanding is that we decided to use per-daemon config for 2.0, but plan to move to integrated configs soon after. The main discussion point was the migration path from classic Quagga (with separate configs) and the lack of the capability for each daemon to read directly from the integrated config (which requires the extra step of vtysh to re-load configs if a daemon restart). There is also the issue for users not running zebra (or does integrated config work for a deployment with only BGP?) I thought we agreed to somehow address these issues before we push users to the integrated config. Anyone remembers this discussion? (Or remembers it different?) -- 2) Do we want the packages on each platform as close to each other as possible or do we want it to follow the conventions of each distro as close as possible? I assume (on the short term), we end up at least with packages for - Debian (Ubuntu 14.04, 16.04, Debian 8) - Redhat (RedHat 6, 7, CentOS 6, 7, Fedora) - FreeBSD - Snap packages I thought about the packages as reference packages for package maintainers to build on (and the merging changes from the back in as far as possible) Each platform has differences in capabilities and guidelines for building them: - Conventions where configs and binaries should be installed - Startup system (init.d, systemd and others) - Configuration location (ie /etc/sysconfig for redhat, /etc/debian for debian etc) Each system also provides functions and examples for startup scripts. After this is decided, then I think we can talk about the issues on exceptions Technical challenges like: - everything runs under root with apparmor (ie Snap's) - Some required packages are not available from standard repo (ie Python 2.7 or ipaddr python module for Redhat 6) -- My preferred short term solution: I would still prefer to get the redhat changes in as they are now for the stable/2.0 branch (and the debian changes as soon as possible as well). We could reopen this discussion later once we actually have working packages for at least these 2 platforms -- I really like to get more opinions here - beside mine and Donald's. Specially if you have experience with packages or you know someone you could ask. - Martin Here is a link to some basic description of an init file for RedHat based systems: http://www.sensi.org/~alec/unix/redhat/sysvinit.html (Original is provided on a redhat system in /usr/share/doc/initscripts-*/sysvinitfiles)

4 9

Todays Technical Meeting Agenda
by Donald Sharp 23 May '17

23 May '17

11 AM EST https::/bluejeans.com/9192742159 1) Bingen's PR's (since we skipped them last week ) 2) New Issues 3) PR's 4) Plans for dropping encap safi support 5) Anything Else? donald

1 1

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

23 May '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 1437234: Resource leaks (RESOURCE_LEAK) /ospf6d/ospf6_area.c: 230 in ospf6_area_create() ________________________________________________________________________________________________________ *** CID 1437234: Resource leaks (RESOURCE_LEAK) /ospf6d/ospf6_area.c: 230 in ospf6_area_create() 224 snprintf (oa->name, sizeof (oa->name), "%u", ntohl (area_id)); 225 break; 226 case OSPF6_AREA_FMT_DOTTEDQUAD: 227 inet_ntop (AF_INET, &area_id, oa->name, sizeof (oa->name)); 228 break; 229 default: >>> CID 1437234: Resource leaks (RESOURCE_LEAK) >>> Variable "oa" going out of scope leaks the storage it points to. 230 return NULL; 231 } 232 233 oa->area_id = area_id; 234 oa->if_list = list_new (); 235 ________________________________________________________________________________________________________ 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 20 May '17

20 May '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 1436535: (RESOURCE_LEAK) /bgpd/bgp_updgrp_packet.c: 454 in bpacket_reformat_for_peer() /bgpd/bgp_updgrp_packet.c: 545 in bpacket_reformat_for_peer() ________________________________________________________________________________________________________ *** CID 1436535: (RESOURCE_LEAK) /bgpd/bgp_updgrp_packet.c: 454 in bpacket_reformat_for_peer() 448 offset_nh += 8; 449 break; 450 default: 451 /* TODO: handle IPv6 nexthops */ 452 zlog_warn ("%s: %s: invalid MP nexthop length (AFI IP): %u", 453 __func__, peer->host, nhlen); >>> CID 1436535: (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 454 return NULL; 455 } 456 457 stream_get_from (&v4nh, s, offset_nh, IPV4_MAX_BYTELEN); 458 mod_v4nh = &v4nh; 459 /bgpd/bgp_updgrp_packet.c: 545 in bpacket_reformat_for_peer() 539 offset_nhlocal += 8 * 2 + IPV6_MAX_BYTELEN; 540 break; 541 default: 542 /* TODO: handle IPv4 nexthops */ 543 zlog_warn ("%s: %s: invalid MP nexthop length (AFI IP6): %u", 544 __func__, peer->host, nhlen); >>> CID 1436535: (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 545 return NULL; 546 } 547 548 stream_get_from (&v6nhglobal, s, offset_nhglobal, IPV6_MAX_BYTELEN); 549 if (route_map_sets_nh) 550 { ________________________________________________________________________________________________________ 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

Multithreading call tomorrow (Fri) 11:00 East / 17:00 EU
by David Lamparter 20 May '17

20 May '17

Hi all, as polled on Doodle (and with Lou's side-input), the Multithreading design call mentioned in our last weekly meeting will be tomorrow (Friday) 08:00 PDT (US West Coast -0700) 11:00 EDT (US East Coast -0400) 17:00 CEST (EU Central +0200) I'll also send out calendar invites. Cheers, -David

4 8

Support for maximum-paths in OSPF
by Akshata Danivasa 19 May '17

19 May '17

Hi, Is there a plan to support maximum-paths in FRR for OSPF? Thanks, Akshata

2 1