- dev - lists.frrouting.org

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

25 Apr '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. 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 2 of 2 defect(s) ** CID 1430487: Possible Control flow issues (DEADCODE) /pimd/pim_nht.c: 303 in pim_update_rp_nh() ________________________________________________________________________________________________________ *** CID 1430487: Possible Control flow issues (DEADCODE) /pimd/pim_nht.c: 303 in pim_update_rp_nh() 297 __PRETTY_FUNCTION__, rp_str, 298 rp_info->rp.source_nexthop.interface->name); 299 } 300 } 301 302 if (ret) >>> CID 1430487: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 0;". 303 return 0; 304 305 return 1; 306 307 } 308 ** CID 1399390: Security best practices violations (STRING_OVERFLOW) /pimd/pim_register.c: 193 in pim_register_send() ________________________________________________________________________________________________________ *** CID 1399390: Security best practices violations (STRING_OVERFLOW) /pimd/pim_register.c: 193 in pim_register_send() 187 return; 188 } 189 190 if (PIM_DEBUG_PIM_REG) 191 { 192 char rp_str[INET_ADDRSTRLEN]; >>> CID 1399390: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 16-character fixed-size string "rp_str" by copying the return value of "inet_ntoa" without checking the length. 193 strcpy (rp_str, inet_ntoa (rpg->rpf_addr.u.prefix4)); 194 zlog_debug ("%s: Sending %s %sRegister Packet to %s on %s", 195 __PRETTY_FUNCTION__, up->sg_str, 196 null_register ? "NULL " : "", rp_str, ifp->name); 197 } 198 ________________________________________________________________________________________________________ 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…

2 1

VRF support with netns
by Philippe Guibert 22 Apr '17

22 Apr '17

Hi all, About VRF support of frrouting 2.0, regarding [0], the following is indicated: - VRF Lite (Linux VRF device support, Zebra and BGP) Instructions ([1]) This is good information that VRF lite is now supported in frrouting. However, I would like to draw your attention to the following: * the VRF feature in frrouting is lost for kernels not supporting [1], whereas it was working on Quagga. * it is not possible to rely on kernel netns, whereas in Quagga the netns solution was used. An issue has been created for that in [4]. On behalf of 6WIND, we want to fix those two issues, but would like to ensure that the proposed solution is aligned, and does not conflict with frrouting/other roadmap. Code investigation in frrouting showed the following : - The netns support has been moved to a lib/netns libary ( see commit illustration in [2]). This change made useless the ns support ) - The VRF support has been mapped to vrf kernel feature ( as illustrated in [3], file lib/vrf.h) The most obvious solution is the following. It consists in configuring at runtime frrouting, so that the frrouting VRF mecanism will rely either on VRF or on Netns feature. The fact is the clients that have a quagga based solution, would like to benefit for frrouting, without having to change their configuration. Either because the kernel is not yet up to date, or because this is not part of their plan to move to vrf kernel implementation. Like that, the user will be able to choose with a minimum configuration change to be on VRF mode or on Netns mode. Any remarks about the proposal to solve [4] ? Best Regards, Philippe [0] https://github.com/FRRouting/frr/wiki/Quagga-1.1-%E2%86%92-FRR-2.0 [1] https://www.kernel.org/doc/Documentation/networking/vrf.txt [2] https://github.com/FRRouting/frr/commit/13460c44a2241 [3] https://github.com/FRRouting/frr/commit/216b18efe144b [4] https://github.com/FRRouting/frr/issues/385

3 2

per-platform/os defaults
by Rodny Molina 21 Apr '17

21 Apr '17

Hi folks, Wondering if there’s any policy in regards to the location in which we should place building/config/default files corresponding to specific platform/os? I see that there’s already a ‘cumulus’ folder containing this kind of stuff. Can we go ahead and do something equivalent for SONiC? At this point I’ve pushed this info to SONiC repos (e.g. enable ‘fpm’, default /etc/ values, etc), but i’m pondering the possibility of pushing this info to frr repo to prevent inconsistencies on either side breaking the build. What’s your take on this? Thanks. /Rodny

2 2

Need helps for for Frrouting installation
by Badou DIOUF 20 Apr '17

20 Apr '17

Hi, I've a problem with the installation of Frrouting. when I tape this command: sudo adduser --system --ingroup frr --groups frrvty --home /var/run/frr/ \ --gecos "FRR suite" --shell /sbin/nologin frr the result is unknow: option groups when I change groups to group I've this message specify only one name in this mode. so I don't know what i must to do. help me please. the rest work normally: git clone, ./bootstrap.sh and ./configure. when I want to start the deamon zebra with this command zebra -d i receive this message: privs_init: user(frr) is not part of vty group specified(frrvty) thanks you -- *Badou DIOUF* *Etudiant à Sup Galilée-* *Ecole d'ingénieurs-3ème année* *Spécialité Télécommunications et Réseaux-* * Université Paris 13* *email: badoudiouf3(a)gmail.com <badoudiouf3(a)gmail.com>* *Tél: 07 81 63 76 42*

3 2

pimd MSDP
by Evgeny Matuzov 20 Apr '17

20 Apr '17

Hi! I am trying to test MSDP functionality in virtual environment: FRR <-> cisco, FRR <-> juniper I have not found information about MSDP CLI commands in manual https://frrouting.org/manual/ I would be happy if you can point to some description on how to use MSDP in FRR. Maybe there is new version of manual in development? Best regards, Evgeny

3 6

Weekly Technical Meeting 4/18 11 am EDT
by Donald Sharp 19 Apr '17

19 Apr '17

https://bluejeans.com/9192742159 Agenda 1) TSC Voting by maintainers ( Nominations have been under separate email ) 2) Criteria for inclusion on the FRR Website ( Alistair ) 3) Branch names to prevent cornfusion ( Martin ) 4) Issue #335 discussion, split lib/vty.c into separate library ( osmoc ) 5) Stable/3.0 Issues 6) New Issues 7) PR's 8) Anything else? This looks like a heavy week of issues that will be discussed. Let's extend the meeting an additional 1/2 hour to 12:30 EDT? donald

1 1

Re: [dev] Technical steering committee recomendations
by Jeff Tantsura 18 Apr '17

18 Apr '17

+1 for both nominations! Cheers, Jeff > On Apr 4, 2017, at 18:50, Donald Sharp via dev <dev(a)lists.frrouting.org> wrote: > > > From: Donald Sharp <sharpd(a)cumulusnetworks.com> > Subject: Technical steering committee recomendations > Date: April 4, 2017 at 18:50:05 PDT > To: dev(a)lists.frrouting.org > > > 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 > > > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

9 10

Heads-up for IS-IS development
by Christian Franke 16 Apr '17

16 Apr '17

Hello everyone, just to provide a heads-up, I am currently working on some enhancements to the FRR IS-IS implementation, in the first place there is the addition of MT support according to RFC5120. Also, I would like to reimplement the serializer/deserializer for the wireformat of the IS-IS PDUs as the current implementation is not very robust and not very extensible. That new serializer/deserializer can then also be used as a basis to make the regeneration of LSP fragments more efficient. I'll be on the technical call today, feel free to give any comments or ask any questions you might have there, or to inquire here on the list. All Best, Christian

2 4

Help Strings with no newline termination
by Donald Sharp 15 Apr '17

15 Apr '17

If someone is looking for a quick project, I keep running across this type of issue: "Prepend to the as-path\n" "Use the peer's AS-number\n" - "Number of times to insert") + "Number of times to insert\n") { return set_aspath_prepend_asn (self, vty, argc, argv); } While visual inspection works, it would be nice if someone wrote a script to find all the cases where we have the various DEFUNS with a non null terminated string. thanks! donald

1 0

Renaming branch stable/3.0 to dev/3.0 ???
by Martin Winter 14 Apr '17

14 Apr '17

Curious on an opinion here… Our branches on the github seem to be confusing to newcomers. Most people seem to assume stable/3.0 branch (or master) is the one they should be building from for a stable version. I don’t see much we can do about the master (except maybe update the description to make it clear that this is the most cutting edge version). But I would propose we rename stable/3.0 to dev/3.0 until we get to a more “stable” version of it. I’m also thinking about having some auto-merge of commits from the 3.0 branch into master for the time being (at least for the non-conflicting commits) to keep master up to date. Thoughts? - Martin

4 6