April 2017 - dev - lists.frrouting.org

Proposal to change CLI syntax of 'show ip rib <u_addr> to 'show ip pim rib <u_addr>
by Chirag Shah 02 May '17

02 May '17

Hello All, The CLI command 'show ip rib <unicast addr> is in pim_cmd.c which invokes zebra lookup for nexthops and return the first available path to user. Ideally the command is for PIMd (Zebra Client for nexthop info). I would like to propose to change to CLI to specific to PIMd 'show ip *pim *rib <uincat addr> rather generic than "ip rib" term. Please share your opinion. Kind Regards, Chirag Shah P.S. : Cli implementation from pim_cli.c DEFUN (show_ip_rib, show_ip_rib_cmd, "*show ip rib A.B.C.D*", SHOW_STR IP_STR RIB_STR "Unicast address\n") { struct in_addr addr; const char *addr_str; struct pim_nexthop nexthop; char nexthop_addr_str[PREFIX_STRLEN]; int result; memset (&nexthop, 0, sizeof (nexthop)); addr_str = argv[0]; result = inet_pton(AF_INET, addr_str, &addr); if (result <= 0) { vty_out(vty, "Bad unicast address %s: errno=%d: %s%s", addr_str, errno, safe_strerror(errno), VTY_NEWLINE); return CMD_WARNING; } if (*pim_nexthop_lookup*(&nexthop, addr, 0)) { vty_out(vty, "Failure querying RIB nexthop for unicast address %s%s", addr_str, VTY_NEWLINE); return CMD_WARNING; } vty_out(vty, "Address NextHop Interface Metric Preference%s", VTY_NEWLINE); pim_addr_dump("<nexthop?>", &nexthop.mrib_nexthop_addr, nexthop_addr_str, sizeof(nexthop_addr_str)); vty_out(vty, "%-15s %-15s %-9s %6d %10d%s", addr_str, nexthop_addr_str, nexthop.interface ? nexthop.interface->name : "<ifname?>", nexthop.mrib_route_metric, nexthop.mrib_metric_preference, VTY_NEWLINE); return CMD_SUCCESS; }

3 3

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

28 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 1432078: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1432078: Memory - corruptions (OVERRUN) /isisd/isis_spf.c: 943 in isis_spf_preload_tent() 937 continue; 938 if (spftree->mtid == ISIS_MT_IPV4_UNICAST && !speaks (&adj->nlpids, spftree->family)) 939 continue; 940 switch (adj->sys_type) 941 { 942 case ISIS_SYSTYPE_ES: >>> CID 1432078: Memory - corruptions (OVERRUN) >>> Overrunning array "adj->sysid" of 6 bytes by passing it to a function which accesses it at byte offset 6. 943 isis_spf_add_local (spftree, VTYPE_ES, adj->sysid, adj, 944 circuit->te_metric[spftree->level - 1], 945 parent); 946 break; 947 case ISIS_SYSTYPE_IS: 948 case ISIS_SYSTYPE_L1_IS: ________________________________________________________________________________________________________ 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 26 Apr '17

26 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. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1431868: Memory - corruptions (OVERRUN) /zebra/zserv.c: 1602 in zread_ipv6_add() ________________________________________________________________________________________________________ *** CID 1431868: Memory - corruptions (OVERRUN) /zebra/zserv.c: 1602 in zread_ipv6_add() 1596 /* For labeled-unicast, each nexthop is followed by label. */ 1597 if (CHECK_FLAG (message, ZAPI_MESSAGE_LABEL)) 1598 { 1599 label = (mpls_label_t)stream_getl (s); 1600 labels[nh_count++] = label; 1601 } >>> CID 1431868: Memory - corruptions (OVERRUN) >>> Overrunning array "nexthops" of 64 16-byte elements at element index 64 (byte offset 1024) using index "nh_count++" (which evaluates to 64). 1602 nexthops[nh_count++] = nhop_addr; 1603 } 1604 break; 1605 case NEXTHOP_TYPE_IFINDEX: 1606 if (if_count < multipath_num) { 1607 ifindices[if_count++] = stream_getl (s); ** CID 1431867: Null pointer dereferences (FORWARD_NULL) /lib/nexthop.c: 108 in nexthop_labels_match() ________________________________________________________________________________________________________ *** CID 1431867: Null pointer dereferences (FORWARD_NULL) /lib/nexthop.c: 108 in nexthop_labels_match() 102 103 nhl1 = nh1->nh_label; 104 nhl2 = nh2->nh_label; 105 if ((nhl1 && !nhl2) || (!nhl1 && nhl2)) 106 return 0; 107 >>> CID 1431867: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "nhl1". 108 if (nhl1->num_labels != nhl2->num_labels) 109 return 0; 110 111 if (memcmp (nhl1->label, nhl2->label, nhl1->num_labels)) 112 return 0; 113 ** CID 1431866: Error handling issues (CHECKED_RETURN) /zebra/zebra_mpls.c: 922 in lsp_schedule() ________________________________________________________________________________________________________ *** CID 1431866: Error handling issues (CHECKED_RETURN) /zebra/zebra_mpls.c: 922 in lsp_schedule() 916 static void 917 lsp_schedule (struct hash_backet *backet, void *ctxt) 918 { 919 zebra_lsp_t *lsp; 920 921 lsp = (zebra_lsp_t *) backet->data; >>> CID 1431866: Error handling issues (CHECKED_RETURN) >>> Calling "lsp_processq_add" without checking return value (as is done elsewhere 5 out of 6 times). 922 lsp_processq_add (lsp); 923 } 924 925 /* 926 * Process a LSP entry that is in the queue. Recalculate best NHLFE and 927 * any multipaths and update or delete from the kernel, as needed. ________________________________________________________________________________________________________ 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 26 Apr '17

26 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. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1431864: (NO_EFFECT) /ldpd/ldpe.c: 146 in ldpe_init() /ldpd/ldpe.c: 148 in ldpe_init() ________________________________________________________________________________________________________ *** CID 1431864: (NO_EFFECT) /ldpd/ldpe.c: 146 in ldpe_init() 140 } 141 142 void 143 ldpe_init(struct ldpd_init *init) 144 { 145 /* drop privileges */ >>> CID 1431864: (NO_EFFECT) >>> Comparing an array to null is not useful: "init->user", since the test will always evaluate as true. 146 if (init->user) 147 ldpe_privs.user = init->user; 148 if (init->group) 149 ldpe_privs.group = init->group; 150 zprivs_init(&ldpe_privs); 151 /ldpd/ldpe.c: 148 in ldpe_init() 142 void 143 ldpe_init(struct ldpd_init *init) 144 { 145 /* drop privileges */ 146 if (init->user) 147 ldpe_privs.user = init->user; >>> CID 1431864: (NO_EFFECT) >>> Comparing an array to null is not useful: "init->group", since the test will always evaluate as true. 148 if (init->group) 149 ldpe_privs.group = init->group; 150 zprivs_init(&ldpe_privs); 151 152 /* listen on ldpd control socket */ 153 strlcpy(ctl_sock_path, init->ctl_sock_path, sizeof(ctl_sock_path)); ** CID 1431863: (NO_EFFECT) /ldpd/lde.c: 167 in lde_init() /ldpd/lde.c: 169 in lde_init() ________________________________________________________________________________________________________ *** CID 1431863: (NO_EFFECT) /ldpd/lde.c: 167 in lde_init() 161 } 162 163 void 164 lde_init(struct ldpd_init *init) 165 { 166 /* drop privileges */ >>> CID 1431863: (NO_EFFECT) >>> Comparing an array to null is not useful: "init->user", since the test will always evaluate as true. 167 if (init->user) 168 lde_privs.user = init->user; 169 if (init->group) 170 lde_privs.group = init->group; 171 zprivs_init(&lde_privs); 172 /ldpd/lde.c: 169 in lde_init() 163 void 164 lde_init(struct ldpd_init *init) 165 { 166 /* drop privileges */ 167 if (init->user) 168 lde_privs.user = init->user; >>> CID 1431863: (NO_EFFECT) >>> Comparing an array to null is not useful: "init->group", since the test will always evaluate as true. 169 if (init->group) 170 lde_privs.group = init->group; 171 zprivs_init(&lde_privs); 172 173 #ifdef HAVE_PLEDGE 174 if (pledge("stdio recvfd unix", NULL) == -1) ________________________________________________________________________________________________________ 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

Time to start thinking about moving meeting time
by Donald Sharp 25 Apr '17

25 Apr '17

All - The Weekly meeting is currently at 11 am EDT( 15:00 GMT I believe ) on Tuesdays. I'd like to keep the meeting on Tuesday but think about changing the time. We are starting to get enough people and it's been ~6months since we last changed it. My goal is to move the meeting around every 6 months or so, so that it is eventually painful for everyone. If you would like to attend the meeting or do attend the meeting, please take a minute or so responding to this email with times that you are available to meet based upon GMT time and hopefully we can work out a new time for people to attend. I am available all day on Tuesdays 11 am GMT -> onwards donald

8 8

Technical Meeting Agenda 4/25/27 11 am EDT
by Donald Sharp 25 Apr '17

25 Apr '17

https://bluejeans.com/9192742159 1) Meeting Time. Received 1 email, please update your time! 2) TSC election news. 3) branch rename status 4) 3.0 issues 5) PR's 6) Anything else people would like to talk about? donald

1 1

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

24 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