- dev - lists.frrouting.org

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

05 Apr '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 1424529: (FORWARD_NULL) /isisd/isis_lsp.c: 1654 in lsp_build() /isisd/isis_lsp.c: 1710 in lsp_build() ________________________________________________________________________________________________________ *** CID 1424529: (FORWARD_NULL) /isisd/isis_lsp.c: 1654 in lsp_build() 1648 lsp_debug("ISIS (%s): No DIS for circuit, not adding te-style IS neighbor.", 1649 area->area_tag); 1650 } 1651 else 1652 { 1653 /* Check if MPLS_TE is activate */ >>> CID 1424529: (FORWARD_NULL) >>> Dereferencing null pointer "circuit->interface". 1654 if (IS_MPLS_TE(isisMplsTE) && HAS_LINK_PARAMS(circuit->interface)) 1655 /* Add SubTLVs & Adjust real size of SubTLVs */ 1656 te_is_neigh->sub_tlvs_length = add_te_subtlvs(te_is_neigh->sub_tlvs, circuit->mtc); 1657 else 1658 /* Or keep only TE metric with no SubTLVs if MPLS_TE is off */ 1659 te_is_neigh->sub_tlvs_length = 0; /isisd/isis_lsp.c: 1710 in lsp_build() 1704 te_is_neigh = XCALLOC (MTYPE_ISIS_TLV, 1705 sizeof (struct te_is_neigh)); 1706 memcpy (te_is_neigh->neigh_id, nei->sysid, ISIS_SYS_ID_LEN); 1707 metric = circuit->te_metric[level - 1]; 1708 SET_TE_METRIC(te_is_neigh, metric); 1709 /* Check if MPLS_TE is activate */ >>> CID 1424529: (FORWARD_NULL) >>> Dereferencing null pointer "circuit->interface". 1710 if (IS_MPLS_TE(isisMplsTE) && HAS_LINK_PARAMS(circuit->interface)) 1711 /* Update Local and Remote IP address for MPLS TE circuit parameters */ 1712 /* NOTE sure that it is the pertinent place for that updates */ 1713 /* Local IP address could be updated in isis_circuit.c - isis_circuit_add_addr() */ 1714 /* But, where update remote IP address ? in isis_pdu.c - process_p2p_hello() ? */ 1715 ________________________________________________________________________________________________________ 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

Re: [dev] Technical steering committee recomendations
by David Lamparter 05 Apr '17

05 Apr '17

Hiya, I'd like to nominate Donald Sharp to be on the steering committee. Donald has been continuously driving the entire project forward, pulling us together into a coherent group with a direction. He is contributing on all fronts - code, review, design and buerocracy; and he has shown that he is able to suggest agreements and ways forward in areas where we have diverging interests in the group :) Cheers, -David

1 0

BFD
by Raymond Burkholder 05 Apr '17

05 Apr '17

I see bfd code attached in the bgp, ospf and lib directories. But I don't see any bfd examples in the documentation. On a features page I can no longer find, it indicated that bfd was not being worked on. Would some one be able to provide enlightenment on if bfd is in a usable state at the present time? And if so, how to activate it/check it/make use of it? Thanx. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 1

Technical steering committee recomendations
by Donald Sharp 05 Apr '17

05 Apr '17

I know I might be jumping the gun here a bit(my apologies Alistair). I would like to nominate David Lamparter to be on the steering committee. David has continously shown a deep understanding of routing as well as his ability to deliver new and innovative solutions too the frr project. He has the drive, expertise and the deep caring about frr that would make him an excellent addition to the steering committee. I would also like to nominate Lou Berger to the steering committee. Lou brings a deep understanding of BGP as well a keen mind that quickly understands the issue that is being discussed. His attention to detail as well as his focus on what we need to do next to get us where we want to go would serve the frr project well. Thanks! Donald

1 0

Stable/3.0
by Donald Sharp 05 Apr '17

05 Apr '17

Stable/3.0 has been pulled. As a guide we expect pull requests for these broad categories against these branches: Stable/2.0 - bug fixes to features specific to old features and new 2.0 features, or Security fixes discovered. Basically we will only be releasing point releases to fix/address new issues. Stable/3.0 - Stabilization work to all the work on master that has been going on. Small tweaks to features added in the last couple of months. We expect to stabilize and release sooner rather than later. Master - new features. I expect that we will merge down from stable/2.0 and stable/3.0 into master. If we have a bug fix from 2.0 we will have to cherry pick that change into 3.0, I imagine. Suggestions welcome here. I'd like people to think about our stance on a release schedule as well as how long we want to support a released stable branch to be discussed at the next technical meeting and where it will be documented. Thanks! Donald

1 0

Quick FYI regarding todays snmp code changes
by Donald Sharp 04 Apr '17

04 Apr '17

All - The snmp loadable module support has a couple of issues. If you are attempting to build and do *not* have the snmp build libraries installed it will fail. Also these snmp changes really would like a `make distclean`...... to make them happy. As such you have 2 choices right now: 1) Install the needed library 2) Wait an hour or so, till David and I get the fix for this in place. Thanks! donald

1 1

Re: [dev] FRR 2.0 Package now released in Ubuntu Snap store
by Rodny Molina 04 Apr '17

04 Apr '17

Donald, before you upload these debian packages, you may want to check this out… Have you tried to install/run these .deb images? If so, are you observing this too (see further below)? I’m able to build .deb packages for Debian-Jessie, but typical installation instructions are missing in frr’s debian/rules (e.g. cp /usr/lib/frr/frr /etc/init.d/; update-rc.d frr defaults). In consequence, frr is not initiated as a service, nor we are giving users the chance of doing so, which is something quagga takes care of as part of its dpkg-building process. As a fix, we could either defer ‘frr.service’ initialization to debian’s postinst-phase (quagga’s approach), or we can go ahead and insert these instructions in debian/rule itself. @Martin, do you have any suggestion? I can propose a fix but i’m far from being a deb-packager expert ;-) $ dpkg-buildpackage -rfakeroot -b -us -uc -d … dh_systemd_enable: Could not find "frr.service" in the /lib/systemd/system directory of frr-dbg. This could be a typo, or using Also= with a service file from another package. Please check carefully that this message is harmless. dh_systemd_enable: Cannot open(frr.service) for extracting the Also= line(s) dh_systemd_enable: Could not find "frr.service" in the /lib/systemd/system directory of frr-doc. This could be a typo, or using Also= with a service file from another package. Please check carefully that this message is harmless. dh_systemd_enable: Cannot open(frr.service) for extracting the Also= line(s) make[1]: Leaving directory '/sonic/src/frr' ... /Rodny > On Apr 3, 2017, at 11:50 AM, Donald Sharp via dev <dev(a)lists.frrouting.org> wrote: > > > From: Donald Sharp <sharpd(a)cumulusnetworks.com> > Subject: Re: [dev] FRR 2.0 Package now released in Ubuntu Snap store > Date: April 3, 2017 at 11:50:40 AM PDT > To: Martin Winter <mwinter(a)opensourcerouting.org> > Cc: JR Rivers <jrrivers(a)cumulusnetworks.com>, dev(a)lists.frrouting.org > > > I have built .deb packages for FRR for ubuntu 16.04. Do we want to > put them up on the github page? While we wait for more official > packaging? > > donald > > On Mon, Apr 3, 2017 at 2:47 PM, Martin Winter > <mwinter(a)opensourcerouting.org> wrote: >> We don’t have a official .deb or .rpm package yet. >> >> I’m working with Silas (who is way better on deb packages than I am) >> to get debian packages fixed. (RPMs should be easier than debian packages) >> >> - Martin >> >> On 3 Apr 2017, at 7:24, JR Rivers wrote: >> >> Any thoughts on RPM and DEB? >> >> On Mon, Apr 3, 2017 at 7:13 AM, Jafar Al-Gharaibeh <jafar(a)atcorp.com> wrote: >>> >>> Great work everyone, and thank you Martin for the update! >>> >>> The link from your previous email: https://uappexplorer.com/app/frr.osr >>> >>> shows only download option for arm64. Are the other architectures just >>> slow to show up? >>> >>> Cheers, >>> Jafar >>> >>> >>> On 4/3/2017 4:40 AM, Martin Winter wrote: >>>> >>>> The binary Snap Package for FRR 2.0 is now released in the snap store >>>> >>>> Snap binary is currently available for amd64, i386, armhf and arm64 with >>>> ppc64el >>>> probably following in 1..2 days >>>> >>>> I’ve also made the associated Snapcraft CI Testplan (and Store >>>> deployment) public as well >>>> (See https://ci1.netdef.org/browse/FRR-SNAP and >>>> https://ci1.netdef.org/deploy/viewAllDeploymentProjects.action ) >>>> >>>> Enjoy, >>>> >>>> - Martin >>>> >>>> _______________________________________________ >>>> dev mailing list >>>> dev(a)lists.frrouting.org >>>> https://lists.frrouting.org/listinfo/dev >>> >>> >>> >>> _______________________________________________ >>> dev mailing list >>> dev(a)lists.frrouting.org >>> https://lists.frrouting.org/listinfo/dev >> >> >> >> _______________________________________________ >> dev mailing list >> dev(a)lists.frrouting.org >> https://lists.frrouting.org/listinfo/dev >> > > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

2 2

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

04 Apr '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. 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 3 of 3 defect(s) ** CID 1424372: Security best practices violations (STRING_OVERFLOW) /zebra/if_netlink.c: 315 in get_iflink_speed() ________________________________________________________________________________________________________ *** CID 1424372: Security best practices violations (STRING_OVERFLOW) /zebra/if_netlink.c: 315 in get_iflink_speed() 309 int rc; 310 311 /* initialize struct */ 312 memset(&ifdata, 0, sizeof(ifdata)); 313 314 /* set interface name */ >>> CID 1424372: Security best practices violations (STRING_OVERFLOW) >>> Note: This defect has an elevated risk because the source argument is a parameter of the current function. 315 strcpy(ifdata.ifr_name, ifname); 316 317 /* initialize ethtool interface */ 318 memset(&ecmd, 0, sizeof(ecmd)); 319 ecmd.cmd = ETHTOOL_GSET; /* ETHTOOL_GLINK */ 320 ifdata.ifr_data = (__caddr_t) &ecmd; ** CID 1424371: (DEADCODE) /bgpd/bgpd.c: 7389 in bgp_config_write() /bgpd/bgpd.c: 7409 in bgp_config_write() /bgpd/bgpd.c: 7456 in bgp_config_write() /bgpd/bgpd.c: 7536 in bgp_config_write() ________________________________________________________________________________________________________ *** CID 1424371: (DEADCODE) /bgpd/bgpd.c: 7389 in bgp_config_write() 7383 vty_out (vty, " bgp router-id %s%s", 7384 inet_ntoa (bgp->router_id_static), VTY_NEWLINE); 7385 7386 /* BGP log-neighbor-changes. */ 7387 if (!!bgp_flag_check (bgp, BGP_FLAG_LOG_NEIGHBOR_CHANGES) 7388 != DFLT_BGP_LOG_NEIGHBOR_CHANGES) >>> CID 1424371: (DEADCODE) >>> Execution cannot reach the expression ""no "" inside this statement: "vty_out(vty, " %sbgp log-ne...". 7389 vty_out (vty, " %sbgp log-neighbor-changes%s", 7390 bgp_flag_check (bgp, BGP_FLAG_LOG_NEIGHBOR_CHANGES) ? "" : "no ", 7391 VTY_NEWLINE); 7392 7393 /* BGP configuration. */ 7394 if (bgp_flag_check (bgp, BGP_FLAG_ALWAYS_COMPARE_MED)) /bgpd/bgpd.c: 7409 in bgp_config_write() 7403 vty_out (vty, " bgp default local-preference %d%s", 7404 bgp->default_local_pref, VTY_NEWLINE); 7405 7406 /* BGP default show-hostname */ 7407 if (!!bgp_flag_check(bgp, BGP_FLAG_SHOW_HOSTNAME) 7408 != DFLT_BGP_SHOW_HOSTNAME) >>> CID 1424371: (DEADCODE) >>> Execution cannot reach the expression ""no "" inside this statement: "vty_out(vty, " %sbgp defaul...". 7409 vty_out (vty, " %sbgp default show-hostname%s", 7410 bgp_flag_check (bgp, BGP_FLAG_SHOW_HOSTNAME) ? "" : "no ", 7411 VTY_NEWLINE); 7412 7413 /* BGP default subgroup-pkt-queue-max. */ 7414 if (bgp->default_subgroup_pkt_queue_max != BGP_DEFAULT_SUBGROUP_PKT_QUEUE_MAX) /bgpd/bgpd.c: 7456 in bgp_config_write() 7450 if (bgp_flag_check (bgp, BGP_FLAG_ENFORCE_FIRST_AS)) 7451 vty_out (vty, " bgp enforce-first-as%s", VTY_NEWLINE); 7452 7453 /* BGP deterministic-med. */ 7454 if (!!bgp_flag_check (bgp, BGP_FLAG_DETERMINISTIC_MED) 7455 != DFLT_BGP_DETERMINISTIC_MED) >>> CID 1424371: (DEADCODE) >>> Execution cannot reach the expression ""no "" inside this statement: "vty_out(vty, " %sbgp determ...". 7456 vty_out (vty, " %sbgp deterministic-med%s", 7457 bgp_flag_check (bgp, BGP_FLAG_DETERMINISTIC_MED) ? "" : "no ", 7458 VTY_NEWLINE); 7459 7460 /* BGP update-delay. */ 7461 bgp_config_write_update_delay (vty, bgp); /bgpd/bgpd.c: 7536 in bgp_config_write() 7530 vty_out (vty, "%s", VTY_NEWLINE); 7531 } 7532 7533 /* BGP network import check. */ 7534 if (!!bgp_flag_check (bgp, BGP_FLAG_IMPORT_CHECK) 7535 != DFLT_BGP_IMPORT_CHECK) >>> CID 1424371: (DEADCODE) >>> Execution cannot reach the expression ""no "" inside this statement: "vty_out(vty, " %sbgp networ...". 7536 vty_out (vty, " %sbgp network import-check%s", 7537 bgp_flag_check (bgp, BGP_FLAG_IMPORT_CHECK) ? "" : "no ", 7538 VTY_NEWLINE); 7539 7540 /* BGP flag dampening. */ 7541 if (CHECK_FLAG (bgp->af_flags[AFI_IP][SAFI_UNICAST], ** CID 1424370: Error handling issues (CHECKED_RETURN) ________________________________________________________________________________________________________ *** CID 1424370: Error handling issues (CHECKED_RETURN) /isisd/isis_pfpacket.c: 329 in isis_recv_pdu_p2p() 323 struct sockaddr_ll s_addr; 324 325 memset (&s_addr, 0, sizeof (struct sockaddr_ll)); 326 addr_len = sizeof (s_addr); 327 328 /* we can read directly to the stream */ >>> CID 1424370: Error handling issues (CHECKED_RETURN) >>> Calling "stream_recvfrom(circuit->rcv_stream, circuit->fd, circuit->interface->mtu, 0, (struct sockaddr *)&s_addr, (socklen_t *)&addr_len)" without checking return value. It wraps a library function that may fail and return an error code. 329 stream_recvfrom (circuit->rcv_stream, circuit->fd, 330 circuit->interface->mtu, 0, 331 (struct sockaddr *) &s_addr, 332 (socklen_t *) &addr_len); 333 334 if (s_addr.sll_pkttype == PACKET_OUTGOING) ________________________________________________________________________________________________________ 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

Technical Meeting Notes 4/4
by Donald Sharp 04 Apr '17

04 Apr '17

1) Moment of Reflection Thanks Everyone! 2) Technical Steering Committee 2 week nomination period. Alistair is the Awesome person to be in charge of handling who is nominated and voting Send to the alias who you want to nominate. 3) Mailing List Some mails are coming through as attachments and we are getting 2 copies. Demark policy is causing issues. This was turned on to allow cumulus's email to not end in spam. Donald to talk with is IT dudes again about this issue. Setup a security list for reports, TSC to formalize more once it is formed 4) 2.0 stable issues Some bugs have been filed against 2.0. We need to address them stable/2.0 is for 2.0.X releases 5) New Issues 6) PR's Next release is going to be 3.0. Merge down from stable/2.0 and create a stable/3.0 Some discussion of MT. Since it is high risk we would like to discuss more and to get this in( if so decided ) after stable/3.0 pulled. Hopefully Quentin can attend, else I will move the discussion to the dev alias. 7) ISIS Quick discussion of where what Christian is going to be doing. donald

1 0

Re: [dev] Technical Meeting Today 3/28 11 AM EDT
by Donald Sharp 04 Apr '17

04 Apr '17

I forgot to include the meeting link: https://bluejeans.com/9192742159 donald On Mon, Apr 3, 2017 at 12:03 PM, Donald Sharp via dev <dev(a)lists.frrouting.org> wrote: > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > > > ---------- Forwarded message ---------- > From: Donald Sharp <sharpd(a)cumulusnetworks.com> > To: frr(a)lists.nox.tf > Cc: > Bcc: > Date: Mon, 3 Apr 2017 12:03:25 -0400 > Subject: Re: Technical Meeting Today 3/28 11 AM EDT > All - > > 5) Technical Steering Committee > I would like everyone to start thinking about nominations for the > Technical Steering Committee > > 6) Moment of Reflection > > On Tue, Mar 28, 2017 at 8:35 AM, Donald Sharp > <sharpd(a)cumulusnetworks.com> wrote: >> https://bluejeans.com/9192742159 >> >> I will be attending IETF today. Martin has graciously agreed to run >> today's meeting >> >> 1) 2.0 stable issues >> >> 2) New Issues >> >> 3) PR's >> >> 4) Anything Else >> >> thanks! >> >> donald > >

1 0