- dev - lists.frrouting.org

Fwd: [NetDev-People] CFS for Netdev 0x13 open!
by Donald Sharp 05 Nov '18

05 Nov '18

All - Netdev has opened up submissions for the upcoming conference in prague. It would be a great idea to consider presenting something for the community to have as well as consider attending to meet and discuss with your fellow co-developers upcoming projects!. donald ---------- Forwarded message --------- From: Jamal Hadi Salim via people <people(a)lists.netdevconf.org> Date: Mon, Nov 5, 2018 at 3:42 PM Subject: [NetDev-People] CFS for Netdev 0x13 open! To: people <people(a)netdevconf.org> Cc: linux-wireless <linux-wireless(a)vger.kernel.org>, netdev(a)vger.kernel.org <netdev(a)vger.kernel.org>, <netfilter-devel(a)vger.kernel.org>, <lwn(a)lwn.net> We are pleased to announce the opening of call for submissions(CFS) for Netdev 0x13. For overview of topics, submissions and requirements please visit: https://netdevconf.org/0x13/submit-proposal.html Sessions are selected via a blind review process carried out by the Program Committee and Shepherd. Please refer to: https://www.netdevconf.org/0x13/pc_review.html Important dates: Closing of CFS: Tue, January 15, 2019. Acceptance or rejection notification by: Fri, January 18, 2019 Conference dates: Wed, March 20 to Fri, March 22. cheers, jamal _______________________________________________ people mailing list people(a)netdevconf.org https://lists.netdevconf.org/cgi-bin/mailman/listinfo/people

1 0

Northbound API and the new libyang dependency
by Renato Westphal 05 Nov '18

05 Nov '18

Hi all, I'd like to announce that the Northbound API PR [1] was merged a couple of days ago. This is only the beginning of a long journey to modernize FRR with a model-driven architecture based on the YANG modeling language. The goal of this initiative is to provide better interfaces to configure and monitor FRR programatically, since the good old CLI is unfit for that purpose. Examples of new management interfaces include the NETCONF and RESTCONF protocols (supported though the ConfD and Sysrepo plugins). There's also a new gRPC-based northbound plugin under development and the CLI will of course continue to be available, now with new features like support for configuration transactions and rollbacks (please check the demos [2]). It's important to say, however, that only daemons converted to the new northbound model will be able to take advantage of the new northbound capabilities. As of now, only the ripd daemon was converted (ripd was chosen for being one of the simplest daemons we have). This means we can configure/monitor ripd using NETCONF for example, but the same doesn't apply to the other daemons yet. The remaining daemons should be converted within the next few months, and everyone from the community is welcome to collaborate :) For more information about the new Northbound API, please check the documentation [3]. As a consequence of this work, FRR will have a new mandatory dependency: libyang [4]. Everyone please check the updated FRR build instructions to see how to obtain and install this library for your platform. Thanks everyone who collaborated to make this possible! Best Regards, Renato. [1] https://github.com/FRRouting/frr/pull/2705 [2] https://github.com/opensourcerouting/frr/wiki/Demos [3] https://github.com/opensourcerouting/frr/wiki/Architecture [4] https://github.com/CESNET/libyang

1 0

Open source routing @ ietf meetup -- Tuesday Lunch
by Lou Berger 05 Nov '18

05 Nov '18

Hi, We're continuing with the informal Open source routing @ ietf meetup. Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to "Borophimarn 3 on the 3rd floor" on *Tuesday* during lunch (noon). There is no agenda or slides. Please feel free to bring a topic that you'd like to discuss or just come and listen. Cheers, Lou https://datatracker.ietf.org/meeting/103/floor-plan#3rd-floor

1 0

slack request
by Felt, Patrick 02 Nov '18

02 Nov '18

I’d like to request an account in the slack. Thanks,

2 1

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 01 Nov '18

01 Nov '18

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. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1475322: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1475322: Null pointer dereferences (FORWARD_NULL) /ripd/rip_cli_clippy.c: 1531 in ip_rip_authentication_mode() 1525 } 1526 #if 0 /* anything that can fail? */ 1527 if (_failcnt) 1528 return CMD_WARNING; 1529 #endif 1530 #endif >>> CID 1475322: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "mode" to "ip_rip_authentication_mode_magic", which dereferences it. 1531 return ip_rip_authentication_mode_magic(self, vty, argc, argv, mode, auth_length); 1532 } 1533 1534 /* no_ip_rip_authentication_mode => "no ip rip authentication mode [<md5 [auth-length <rfc|old-ripd>]|text>]" */ 1535 DEFUN_CMD_FUNC_DECL(no_ip_rip_authentication_mode) 1536 #define funcdecl_no_ip_rip_authentication_mode static int no_ip_rip_authentication_mode_magic(\ ** CID 1475321: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1475321: Null pointer dereferences (FORWARD_NULL) /lib/northbound_cli_clippy.c: 672 in yang_module_translator_unload_family() 666 } 667 #if 0 /* anything that can fail? */ 668 if (_failcnt) 669 return CMD_WARNING; 670 #endif 671 #endif >>> CID 1475321: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "translator_family" to "yang_module_translator_unload_family_magic", which dereferences it. 672 return yang_module_translator_unload_family_magic(self, vty, argc, argv, translator_family); 673 } 674 675 /* show_config_transaction => "show configuration transaction [ (1-4294967296)$transaction_id [<json$json|xml$xml> [translate WORD$translator_family]] [< with-defaults$with_defaults |changes$changes >] ]" */ 676 DEFUN_CMD_FUNC_DECL(show_config_transaction) 677 #define funcdecl_show_config_transaction static int show_config_transaction_magic(\ ** CID 1475320: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1475320: Null pointer dereferences (FORWARD_NULL) /ripd/rip_cli_clippy.c: 1612 in ip_rip_authentication_string() 1606 } 1607 #if 0 /* anything that can fail? */ 1608 if (_failcnt) 1609 return CMD_WARNING; 1610 #endif 1611 #endif >>> CID 1475320: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "password" to "ip_rip_authentication_string_magic", which dereferences it. 1612 return ip_rip_authentication_string_magic(self, vty, argc, argv, password); 1613 } 1614 1615 /* no_ip_rip_authentication_string => "no ip rip authentication string [LINE]" */ 1616 DEFUN_CMD_FUNC_DECL(no_ip_rip_authentication_string) 1617 #define funcdecl_no_ip_rip_authentication_string static int no_ip_rip_authentication_string_magic(\ ** CID 1475319: Security best practices violations (SECURE_TEMP) /lib/northbound_cli.c: 419 in nb_write_config() ________________________________________________________________________________________________________ *** CID 1475319: Security best practices violations (SECURE_TEMP) /lib/northbound_cli.c: 419 in nb_write_config() 413 { 414 int fd; 415 struct vty *file_vty; 416 int ret = 0; 417 418 snprintf(path, pathlen, "/tmp/frr.tmp.XXXXXXXX"); >>> CID 1475319: Security best practices violations (SECURE_TEMP) >>> Calling "mkstemp" without securely setting umask first. 419 fd = mkstemp(path); 420 if (fd < 0) { 421 flog_warn(EC_LIB_SYSTEM_CALL, "%s: mkstemp() failed: %s", 422 __func__, safe_strerror(errno)); 423 return -1; 424 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Reminder/Warning: weekly call might be earlier/later in some timezones due to DST
by David Lamparter 30 Oct '18

30 Oct '18

Hi all, just a heads-up/reminder/warning: since some countries move out/in to daylight savings time, and the date and direction differs between countries. So, the weekly meeting might be at a different local time for some of us. (e.g.: it's an hour earlier this week for everyone in the EU.) For today: it's in 20 minutes! Cheers, -David

1 0

Debian packaging Python2 deprecation
by David Lamparter 27 Oct '18

27 Oct '18

Hi all, as I'm currently cleaning up the Debian packaging and trying to get it shipped, I've been asked (on Debian channels) about the python2 dependencies that we still have in the package. First of all, I've converted all of them to "python2 | python3" dependencies. Since PR#3074 [https://github.com/FRRouting/frr/pull/3074 "frr-reload.py: Python3 compatibility"], frr-reload.py should also be working correctly on Py3. However, even this is rather unwelcome in Debian, especially for "new" packages. Since all of our supported Debian-based targets (i.e. starting at Debian 8/jessie and Ubuntu 14.04) have python3, I don't see a good reason to retain python2 in our Debian packaging. If you see any such reasons, please voice them now. NB(1): this is only about the DEBIAN PACKAGING. Everything in FRR, including clippy, works with either python2 or python3 and will continue to do so. However, the Debian packages will just list python3 as a dependency. NB(2): as far as I know, Debian will stop shipping python2 in 2019. I don't know what exactly that implies (you can probably still install it somehow.) NB(3): https://python3statement.org/ NB(4): Python2 will be EOL on January 1st, 2020 [https://www.python.org/dev/peps/pep-0373/] NB(5): the "frr-pythontools" package / frr-reload.py cannot ship with a "2 or 3" dependency. It needs to choose between python2 and python3 to get the #! shebang correct. This will absolutely be Python3; that's the only viable choice from an integration perspective. Cheers, -David

1 0

Multicast Protocol
by Tamar Cohen 25 Oct '18

25 Oct '18

Hi all, My name is Tamar and I have the release 5.0.1 of the FRRouting, it is an excellent IP routing protocol suite! I try to use frr in multicast traffic. 1) Is frr support multicast traffic? (I ask because I tried without success) I write this commands: ip multicast ip pim rp IP ADDR inteface INTERFACE ip pim sm\\ in all interfaces Also I add an ospf: router ospf 1 network 0.0.0.0 0.0.0.0 area 0 my setup include tow PC and one additional router (VM of cisco) [cid:image004.jpg@01D46B90.20365000] This setup does not foreword a multicast traffic unfortunately ... 2) I try to debug the traffic in the frr with the "debug" commands but it does not print to the screen anything. In the manual [cid:image006.jpg@01D46B90.20365000] When I wrote the command I got [cid:image007.png@01D46B8F.489CADB0] Why? 3) Is the frr support pim protocol? It is written in the manual but not work in my setup I would be very grateful if you could help me with this. Thank you! Tamar [cid:image002.jpg@01D26F1D.BF96EE00] Tamar Cohen NFV SW Engineer T: +972-73-270-7625 F: +972-08-6436791 | tamar_c(a)rad.com<mailto:tamar_c@rad.com> www.rad.com<http://www.rad.com/> | Follow RAD on LinkedIn<http://www.linkedin.com/company/7369/> | Facebook<http://www.facebook.com/pages/RAD-Data-Communications/72479223117> | Twitter<http://twitter.com/raddatacomms> | YouTube<http://www.youtube.com/user/radwebmaster#g/u>

2 5

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

23 Oct '18

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. 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 3 of 3 defect(s) ** CID 1475200: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1475200: Null pointer dereferences (FORWARD_NULL) /sharpd/sharp_vty_clippy.c: 235 in vrf_label() 229 } 230 #if 1 /* anything that can fail? */ 231 if (_failcnt) 232 return CMD_WARNING; 233 #endif 234 #endif >>> CID 1475200: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "name" to "vrf_label_magic", which dereferences it. 235 return vrf_label_magic(self, vty, argc, argv, ipv4, ipv6, name, label, label_str); 236 } 237 238 /* remove_routes => "sharp remove routes A.B.C.D$start (1-1000000)$routes [instance (0-255)$instance]" */ 239 DEFUN_CMD_FUNC_DECL(remove_routes) 240 #define funcdecl_remove_routes static int remove_routes_magic(\ ** CID 1475199: Error handling issues (CHECKED_RETURN) /pbrd/pbr_zebra.c: 364 in pbr_zebra_nexthop_update() ________________________________________________________________________________________________________ *** CID 1475199: Error handling issues (CHECKED_RETURN) /pbrd/pbr_zebra.c: 364 in pbr_zebra_nexthop_update() 358 zebra_size_t length, vrf_id_t vrf_id) 359 { 360 struct zapi_route nhr; 361 char buf[PREFIX2STR_BUFFER]; 362 uint32_t i; 363 >>> CID 1475199: Error handling issues (CHECKED_RETURN) >>> Calling "zapi_nexthop_update_decode" without checking return value (as is done elsewhere 4 out of 5 times). 364 zapi_nexthop_update_decode(zclient->ibuf, &nhr); 365 366 if (DEBUG_MODE_CHECK(&pbr_dbg_zebra, DEBUG_MODE_ALL)) { 367 368 DEBUGD(&pbr_dbg_zebra, "%s: Received Nexthop update: %s", 369 __PRETTY_FUNCTION__, ** CID 1475198: Error handling issues (CHECKED_RETURN) /sharpd/sharp_zebra.c: 226 in sharp_zebra_nexthop_watch() ________________________________________________________________________________________________________ *** CID 1475198: Error handling issues (CHECKED_RETURN) /sharpd/sharp_zebra.c: 226 in sharp_zebra_nexthop_watch() 220 { 221 int command = ZEBRA_NEXTHOP_REGISTER; 222 223 if (!watch) 224 command = ZEBRA_NEXTHOP_UNREGISTER; 225 >>> CID 1475198: Error handling issues (CHECKED_RETURN) >>> Calling "zclient_send_rnh" without checking return value (as is done elsewhere 4 out of 5 times). 226 zclient_send_rnh(zclient, command, p, true, VRF_DEFAULT); 227 } 228 229 static int sharp_nexthop_update(int command, struct zclient *zclient, 230 zebra_size_t length, vrf_id_t vrf_id) 231 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

TSC Election Results...
by Alistair Woodman 23 Oct '18

23 Oct '18

All, The following individuals were nominated by the community to stand for the 6 slots on the TSC David Lamparter Donald Sharp Martin Winter Philippe Guibert Quentin Young Russ White Because the nominees also numbered 6, their election was 'unopposed' and as such, I announce them to be the dually elected TSC Congratulations. /a

1 0