- dev - lists.frrouting.org

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

31 Jul '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. 3 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 1452282: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 186 in ipv6_route() ________________________________________________________________________________________________________ *** CID 1452282: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 186 in ipv6_route() 180 DEFUN_CMD_FUNC_TEXT(ipv6_route) 181 { 182 int _i; 183 unsigned _fail = 0, _failcnt = 0; 184 const char *no = NULL; 185 struct prefix_ipv6 prefix = { }; >>> CID 1452282: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "prefix_str" = "NULL". 186 const char *prefix_str = NULL; 187 struct prefix_ipv6 from = { }; 188 const char *from_str = NULL; 189 struct in6_addr gate = IN6ADDR_ANY_INIT; 190 const char *gate_str = NULL; 191 const char *ifname = NULL; ** CID 1452281: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 23 in ip_mroute_dist() ________________________________________________________________________________________________________ *** CID 1452281: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 23 in ip_mroute_dist() 17 DEFUN_CMD_FUNC_TEXT(ip_mroute_dist) 18 { 19 int _i; 20 unsigned _fail = 0, _failcnt = 0; 21 const char *no = NULL; 22 struct prefix_ipv4 prefix = { }; >>> CID 1452281: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "prefix_str" = "NULL". 23 const char *prefix_str = NULL; 24 struct in_addr gate = { INADDR_ANY }; 25 const char *gate_str = NULL; 26 const char *ifname = NULL; 27 long distance = 0; 28 const char *distance_str = 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

Backtraces and best way to check cause
by Nigel Kukard 30 Jul '17

30 Jul '17

Hi guys, I'm wondering what would be the best way to try track the cause of these two backtraces. I'm trying to replace a Quagga 1.1.1 box with FRR 2.0 but am blocked by the below. There are about 30 or so external peers. 4 internal private peers. About 40 or so route maps and maybe 100 prefix lists. Jul 30 01:43:36 x-01-x zebra[12658]: Assertion `object->next_best == *updptr || !*updptr' failed in file plist.c, line 613, function trie_install_fn Jul 30 01:43:36 x-01-x zebra[12658]: Backtrace for 15 stack frames: Jul 30 01:43:36 x-01-x zebra[12658]: [bt 0] /usr/lib/x86_64-linux-gnu/libfrr.so.0(zlog_backtrace+0x3a) [0x7f89359acada] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 1] /usr/lib/x86_64-linux-gnu/libfrr.so.0(_zlog_assert_failed+0x67) [0x7f89359ad027] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 2] /usr/lib/x86_64-linux-gnu/libfrr.so.0(+0x415c1) [0x7f89359ae5c1] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 3] /usr/lib/x86_64-linux-gnu/libfrr.so.0(+0x42195) [0x7f89359af195] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 4] /usr/lib/x86_64-linux-gnu/libfrr.so.0(+0x42858) [0x7f89359af858] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 5] /usr/lib/x86_64-linux-gnu/libfrr.so.0(+0x42b67) [0x7f89359afb67] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 6] /usr/lib/x86_64-linux-gnu/libfrr.so.0(+0x29c24) [0x7f8935996c24] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 7] /usr/lib/x86_64-linux-gnu/libfrr.so.0(cmd_execute_command+0xd0) [0x7f8935998180] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 8] /usr/lib/x86_64-linux-gnu/libfrr.so.0(+0x22dd2) [0x7f893598fdd2] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 9] /usr/lib/x86_64-linux-gnu/libfrr.so.0(+0x23103) [0x7f8935990103] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 10] /usr/lib/x86_64-linux-gnu/libfrr.so.0(+0x2468b) [0x7f893599168b] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 11] /usr/lib/x86_64-linux-gnu/libfrr.so.0(thread_call+0x6b) [0x7f893599ccdb] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 12] /usr/lib/frr/zebra(main+0x508) [0x555b24ff47b8] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f8934b70b45] Jul 30 01:43:36 x-01-x zebra[12658]: [bt 14] /usr/lib/frr/zebra(+0x1c9de) [0x555b24ff49de] Jul 30 01:43:36 x-01-x zebra[12658]: Current thread function vtysh_read, scheduled from file vty.c, line 2710 Jul 30 02:07:16 x-01-x bgpd[19976]: memory allocation count underflow for "BGP peer hostname" Jul 30 02:07:16 x-01-x bgpd[19976]: Backtrace for 10 stack frames: Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 0] /usr/lib/x86_64-linux-gnu/libfrr.so.0(zlog_backtrace+0x3a) [0x7f0903fafada] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 1] /usr/lib/x86_64-linux-gnu/libfrr.so.0(qfree+0x4e) [0x7f0903fc464e] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 2] /usr/lib/frr/bgpd(peer_group_delete+0xd4) [0x557425e9a244] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 3] /usr/lib/frr/bgpd(bgp_delete+0x145) [0x557425e9aa05] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 4] /usr/lib/frr/bgpd(sigint+0x68) [0x557425e91778] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 5] /usr/lib/x86_64-linux-gnu/libfrr.so.0(quagga_sigevent_process+0x50) [0x7f0903fbc790] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 6] /usr/lib/x86_64-linux-gnu/libfrr.so.0(thread_fetch+0x5d) [0x7f0903f9f77d] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 7] /usr/lib/frr/bgpd(main+0x4c8) [0x557425e901c8] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 8] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f0902e72b45] Jul 30 02:07:16 x-01-x bgpd[19976]: [bt 9] /usr/lib/frr/bgpd(+0x3f3dc) [0x557425e913dc] Kind Regards Nigel

1 0

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

27 Jul '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 1452064: Code maintainability issues (UNUSED_VALUE) /bgpd/bgp_attr.c: 2042 in bgp_attr_encap() ________________________________________________________________________________________________________ *** CID 1452064: Code maintainability issues (UNUSED_VALUE) /bgpd/bgp_attr.c: 2042 in bgp_attr_encap() 2036 stlv_last->next = tlv; 2037 } else { 2038 attr->vnc_subtlvs = tlv; 2039 } 2040 #endif 2041 } >>> CID 1452064: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "tlv" to "stlv_last" here, but that stored value is overwritten before it can be used. 2042 stlv_last = tlv; 2043 } 2044 2045 if (BGP_ATTR_ENCAP == type) { 2046 attr->encap_tunneltype = tunneltype; 2047 } ________________________________________________________________________________________________________ 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

Today's Technical Meeting 7/25
by Donald Sharp 25 Jul '17

25 Jul '17

https://bluejeans.com/9192742159 1) 3.0 issues 2) New Issues 3) PR's 4) Anything else? donald

2 1

NOTICE: Planned style conversion Monday, Jul 17
by Quentin Young 24 Jul '17

24 Jul '17

Hi folks, In a technical meeting many weeks ago we decided to restyle the codebase to Linux kernel style with the intent of easing maintenance burdens, increasing readability and having a common standard across all FRR components. With our pull request backlog presently at a minimum, the plan is to bite the bullet and convert FRR's master branch to Linux kernel style on Monday, July 17. The tooling for this task will be a Python wrapper for the clang-format <https://clang.llvm.org/docs/ClangFormat.html> source code formatter. The script and configuration file for clang-format will be checked in over the coming days prior to conversion. This patch will not be submitted in a pull request. This will be a direct push to master. All stable branches will remain as-is. Code submissions against those branches -- which should by now be limited to bug fixes -- should continue to follow the style guide present in those branches. Going forward we will require all patch submissions against master to conform to Linux kernel style, with some exceptions (DEFUNS primarily) that will be documented prior to conversion and which the Python script knows about. Recommended procedure will be to run the indent script over new code prior to submission. David has offered to write a helper script to ease merges / rebases for currently open pull requests and local branches. Please familiarize yourself with the kernel style guide located here: https://www.kernel.org/doc/html/v4.10/process/coding-style.html It will also be useful to have passing familiarity with clang-format: https://clang.llvm.org/docs/ClangFormat.html https://clang.llvm.org/docs/ClangFormatStyleOptions.html The first page contains instructions on how to integrate it with Vim and Emacs should you wish to do so. The tools are located in the LLVM clang repository, which you can clone by following the instructions here: https://clang.llvm.org/get_started.html Quentin

3 3

Open source routing @ ietf meetup
by Lou Berger 20 Jul '17

20 Jul '17

Hi, Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to "London" on Thursday during lunch (noon). There is no agenda or slides... Cheers, Lou

4 5

Возможная блокировка github в Российской федерации / Possible blocking of github in the Russian Federation
by Алексей Болдырев 20 Jul '17

20 Jul '17

Обращаю внимание разработчиков и тестеров из России, что в России готовится закон о запрете анонимайзеров и VPN для частных лиц: https://www.linux.org.ru/forum/talks/13555716 Также возможно то, что в России будет возможно заблокирован github, что создаст сложности разработчикам и тестировщикам из Российской федерации. По этому я предлагаю сделать копию кода FRRouting на локальный сервер, а также поддерживать этот локальный сервер. -- I draw the attention of developers and testers from Russia that the law on banning anonymizers and VPN for private individuals is being prepared in Russia: Https://www.linux.org.ru/forum/talks/13555716 It is also possible that github will be blocked in Russia, which will create difficulties for developers and testers from the Russian Federation. Therefore, I propose to make a copy of the FRRouting code on the local server, and also support this local server.

2 1

FRR Technical Meeting Digest
by Quentin Young 18 Jul '17

18 Jul '17

PR's ------- #554 zebra: remove duplicate nexthop 1. waiting on donald for test results #783 add pseudowire mgmt in zebra: 1. Donald + Renato, waiting on your review 2. Bingen -> see static analysis issue and martin's comment re: json output #797 pim vrf 1. Waiting on reviewers #805 Add OSPF API and FRR Hacking documents 1. This brings up need for better API / developer's documentation overall 2. Olivier to open an issue & start a mailing list thread regarding this 3. OSPF docs w/o frr-hacking.md merged. Open Issues ------------ See comments and assignees on issue pages. General ------- All -- if you own a pull request that has merge conflicts, these are likely due to whitespace changes. Please see Friday's email for information on how to update your code to Linux kernel style and resolve the conflicts so we can get your patch in.

1 0

EVPN (and L3VPN) configuration
by Vivek Venkatraman 18 Jul '17

18 Jul '17

About 3 weeks ago, I submitted PR 619 ( https://github.com/FRRouting/frr/pull/619) which provides the standardized EVPN control plane for VxLAN. This is the EVPN implementation that is available/shipping with Cumulus Linux, just merged with the FRR 'master' branch. The PR provides a summary of the functionality. The essential configuration involves only two steps as documented in the file doc/evpn.md: 1. Enable (activate) the EVPN (AFI/SAFI 25/70) address-family between BGP speakers 2. Enable EVPN itself on the local system - to advertise local VNIs and MACs and Neighbors (ARP/ND) associated with those VNIs using BGP/EVPN procedures. The RD and RT parameters will be automatically derived as specified in these procedures and/or prevalent best practice. Step #2 is of course not needed on a Route Reflector. In addition, there are commands to configure the RD and RTs if auto-derivation is not desired - for e.g., peering with third-party BGP system. The syntax for this is shown through an example configuration below (which also shows steps #1 and #2). router bgp 65001 address-family l2vpn evpn neighbor SPINE activate vni 10100 rd 1:10100 route-target import 1:10100 exit-vni advertise-all-vni exit-address-family One topic of discussion is regarding this optional VNI configuration. Instead of the keyword being "vni", should it be "vni-policy" to match with "vrf-policy"? I don't think "vni-policy", or for that matter, "vrf-policy" is the best choice due to the following two main reasons: 1. A "policy" is a fairly familiar construct in routing parlance. It commonly refers to a set of rules or definitions that are generically specified and can then be applied to different "attach points". In FRR, a "route-map" would be a good example of such a policy. It may be misleading to call the specific configuration for a VNI or VRF as "policy", particularly when the VNI/VRF may later support import/export policies (route-maps). 2. The configuration syntax that emerged for VRFs after the last round of discussions separates out the "CE side" configuration (e.g., CE neighbors, redistribution etc.) from the "PE side" configuration (e.g., RD and RT configuration). From the user/operator's perspective, I do not see any value add in this separation, only a potential source of confusion since the same entity (VRF) needs to be configured in multiple places. It can also be debatable where a configuration lies. For e.g., should "vrf-import-policy" reside on the "PE side" as it deals with received L3VPN routes or on the "CE side" as it decides which routes to import into which VRF table? I see it as being very useful to have all the configuration relevant to a VRF (or VNI) in one place. The purpose of this email is to solicit wider feedback since only a few people participated in the earlier discussion and their positions are very likely unchanged. My suggestion would be to have the initial deliberations on the list and if that does not converge or indicates the need for a meeting, the maintainers will call one. Based on the consensus that emerges, I shall update my PR and/or introduce modifications in a subsequent PR - if needed. Vivek

3 11

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

17 Jul '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 4 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 7 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 4 of 4 defect(s) ** CID 1451363: Null pointer dereferences (FORWARD_NULL) /ospf6d/ospf6_lsdb.c: 392 in ospf6_lsdb_show() ________________________________________________________________________________________________________ *** CID 1451363: Null pointer dereferences (FORWARD_NULL) /ospf6d/ospf6_lsdb.c: 392 in ospf6_lsdb_show() 386 return; 387 } 388 389 if (level == OSPF6_LSDB_SHOW_LEVEL_NORMAL) 390 ospf6_lsa_show_summary_header(vty); 391 >>> CID 1451363: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "type". 392 end = ospf6_lsdb_head(lsdb, !!type + !!(type && adv_router), *type, 393 *adv_router, &lsa); 394 while (lsa) { 395 if ((!adv_router || lsa->header->adv_router == *adv_router) 396 && (!id || lsa->header->id == *id)) 397 (*showfunc)(vty, lsa); ** CID 1451362: Null pointer dereferences (REVERSE_INULL) /ospf6d/ospf6_lsdb.c: 395 in ospf6_lsdb_show() ________________________________________________________________________________________________________ *** CID 1451362: Null pointer dereferences (REVERSE_INULL) /ospf6d/ospf6_lsdb.c: 395 in ospf6_lsdb_show() 389 if (level == OSPF6_LSDB_SHOW_LEVEL_NORMAL) 390 ospf6_lsa_show_summary_header(vty); 391 392 end = ospf6_lsdb_head(lsdb, !!type + !!(type && adv_router), *type, 393 *adv_router, &lsa); 394 while (lsa) { >>> CID 1451362: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "adv_router" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 395 if ((!adv_router || lsa->header->adv_router == *adv_router) 396 && (!id || lsa->header->id == *id)) 397 (*showfunc)(vty, lsa); 398 399 lsa = ospf6_lsdb_next(end, lsa); 400 } ** CID 1451361: Null pointer dereferences (REVERSE_INULL) /lib/command_match.c: 598 in disambiguate() ________________________________________________________________________________________________________ *** CID 1451361: Null pointer dereferences (REVERSE_INULL) /lib/command_match.c: 598 in disambiguate() 592 vector vline, unsigned int n) 593 { 594 // doesn't make sense for these to be inequal length 595 assert(first->count == second->count); 596 assert(first->count == vector_active(vline) - n + 1); 597 >>> CID 1451361: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "second" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 598 struct listnode *fnode = listhead(first), *snode = listhead(second); 599 struct cmd_token *ftok = listgetdata(fnode), *stok = listgetdata(snode), 600 *best = NULL; 601 602 // compare each token, if one matches better use that one 603 for (unsigned int i = n; i < vector_active(vline); i++) { ** CID 1451360: Null pointer dereferences (FORWARD_NULL) /ospf6d/ospf6_lsdb.c: 392 in ospf6_lsdb_show() ________________________________________________________________________________________________________ *** CID 1451360: Null pointer dereferences (FORWARD_NULL) /ospf6d/ospf6_lsdb.c: 392 in ospf6_lsdb_show() 386 return; 387 } 388 389 if (level == OSPF6_LSDB_SHOW_LEVEL_NORMAL) 390 ospf6_lsa_show_summary_header(vty); 391 >>> CID 1451360: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "adv_router". 392 end = ospf6_lsdb_head(lsdb, !!type + !!(type && adv_router), *type, 393 *adv_router, &lsa); 394 while (lsa) { 395 if ((!adv_router || lsa->header->adv_router == *adv_router) 396 && (!id || lsa->header->id == *id)) 397 (*showfunc)(vty, lsa); ________________________________________________________________________________________________________ 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