March 2022 - dev - lists.frrouting.org

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 16 Mar '22

16 Mar '22

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 1515356: Uninitialized members (UNINIT_CTOR) /lib/northbound_grpc.cpp: 139 in RpcStateBase::RpcStateBase(const char *)() ________________________________________________________________________________________________________ *** CID 1515356: Uninitialized members (UNINIT_CTOR) /lib/northbound_grpc.cpp: 139 in RpcStateBase::RpcStateBase(const char *)() 133 { 134 public: 135 virtual void do_request(::frr::Northbound::AsyncService *service, 136 ::grpc::ServerCompletionQueue *cq, 137 bool no_copy) = 0; 138 >>> CID 1515356: Uninitialized members (UNINIT_CTOR) >>> Non-static class member "entered_state" is not initialized in this constructor nor in any functions that it calls. 139 RpcStateBase(const char *name) : name(name){}; 140 141 virtual ~RpcStateBase() = default; 142 143 CallState get_state() const 144 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

bgp connection between 2 Nodes with IPv6 on global IPs and want to route via global ipv6 address not via ipv6 link local address
by SANDEEP KUMAR 15 Mar '22

15 Mar '22

Hi All, BGP connection between 2 Nodes with IPv6 on global IPs and want to route via global ipv6 address not via ipv6 link local address I have made the bgp connection with global ipv6 address of interface and advertising the ipv6 route when advertising the route then bgp route added on Node2 for *2003:4001:5001::/64 via **fe80::6548:ed45:d5d:b578:link address of Node1 **but i want route with via * *5001:1::9 global ipv6 address (**2003:4001:5001::/64 via **5001:1::9) * Similarly when we advertise 8001:1::/64 from Node2, *So want help so that I can achieve the bgp route added on Node1 and Node2 via global ipv6 address not with ipv6 link address* 2003:4001:5001::/64 ------------[Node1]<===========================>[Node2]------------- 8001:1::/64 ASN:65001 ASN:65002 *5001:1::9:global * *5001:1::10:global* *fe80::6548:ed45:d5d:b578:link * *fe80::2938:1046:591:8387:link* *[Node1 configuration and interface info]* [root@localhost centosecmp]#* ifconfig ens5|grep inet* inet 10.5.10.9 netmask 255.255.255.0 broadcast 10.5.10.255 *inet6 5001:1::9 prefixlen 64 scopeid 0x0<global>* *inet6 fe80::6548:ed45:d5d:b578 prefixlen 64 scopeid 0x20<link>* localhost.localdomain(config-router)# *do show running-config* Building configuration... Current configuration: ! frr version 7.2 frr defaults traditional hostname localhost.localdomain ! *router bgp 65001 bgp router-id 1.1.1.1 no bgp default ipv4-unicast neighbor 5001:1::10 remote-as 65002 ! address-family ipv6 unicast network 2003:4001:5001::/64 neighbor 5001:1::10 activate exit-address-family* ! line vty ! end localhost.localdomain(config-router)#* do show ip bgp ipv6 summary* IPv6 Unicast Summary: BGP router identifier 1.1.1.1, local AS number 65001 vrf-id 0 BGP table version 2 RIB entries 3, using 552 bytes of memory Peers 1, using 20 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd *5001:1::10 4 65002 7 7 0 0 0 00:02:13 1* Total number of neighbors 1 localhost.localdomain(config-router)# *do show ipv6 route bgp* Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route *B>* 8001:1::/64 [20/0] via fe80::2938:1046:591:8387, ens5, 00:02:19* *[Node2 configuration and interface info]* [root@localhost centosecmp]# *ifconfig ens4|grep inet* inet 10.5.10.10 netmask 255.255.255.0 broadcast 10.5.10.255 *inet6 fe80::2938:1046:591:8387 prefixlen 64 scopeid 0x20<link>* * inet6 5001:1::10 prefixlen 64 scopeid 0x0<global>* localhost.localdomain(config-router)# *do show running-config* Building configuration... Current configuration: ! frr version 7.2 frr defaults traditional hostname localhost.localdomain ! *router bgp 65002 bgp router-id 222.222.222.222 no bgp default ipv4-unicast neighbor 5001:1::9 remote-as 65001 ! address-family ipv6 unicast network 8001:1::/64 neighbor 5001:1::9 activate exit-address-family* ! line vty ! end localhost.localdomain(config-router)# *do show ip bgp ipv6 summary* IPv6 Unicast Summary: BGP router identifier 222.222.222.222, local AS number 65002 vrf-id 0 BGP table version 2 RIB entries 3, using 552 bytes of memory Peers 1, using 20 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd *5001:1::9 4 65001 9 9 0 0 0 00:04:48 1* Total number of neighbors 1 localhost.localdomain(config-router)# *do show ipv6 route bgp* Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route *B>* 2003:4001:5001::/64 [20/0] via fe80::6548:ed45:d5d:b578, ens4, 00:05:08* Thanks & Regards, Sandeep Kumar

2 1

Announcing FRR Release 8.2.2
by Jafar Al-Gharaibeh 14 Mar '22

14 Mar '22

Hi all, We are pleased to announce FRR 8.2.2 release. This release brings a long list of enhancements and fixes with more than 800 commits from 58 developers. Packages: Debian Packages - https://deb.frrouting.org/ <https://deb.frrouting.org/> RPM Packages - https://rpm.frrouting.org/ <https://rpm.frrouting.org/> Snaps - https://snapcraft.io/frr <https://snapcraft.io/frr> Docker - frrouting/frr:v8.2.2 https://hub.docker.com/layers/frrouting/frr/v8.2.2/images/sha256-b236f9d9d6… Some major highlights: - BGP Long-lived graceful restart capability (http://docs.frrouting.org/en/stable-8.2/bgp.html#long-lived-graceful-restart) - BGP Extended Optional Parameters Length for BGP OPEN Message (http://docs.frrouting.org/en/stable-8.2/bgp.html#clicmd-neighbor-PEER-exten…) - BGP Extended BGP Administrative Shutdown Communication - IS-IS Link State Traffic Engineering support (http://docs.frrouting.org/en/stable-8.2/isisd.html#traffic-engineering) - OSPFv3 Support for NSSA Type-7 address ranges (http://docs.frrouting.org/en/stable-8.2/ospf6d.html#ospf6-area) - PBR VLAN actions support (http://docs.frrouting.org/en/stable-8.2/pbr.html#pbr-maps) Please see the release notes for the detailed changelog: * Github release: https://github.com/FRRouting/frr/releases/tag/frr-8.2.2 * FRRouting website: https://frrouting.org/release/8.2.2/ Thanks to all contributors! Cheers, The FRR Development Team!

1 0

Re: [dev] How to communicate on /run/frr/ldpd.vty unix socket
by William Herrin 11 Mar '22

11 Mar '22

On Fri, Mar 11, 2022 at 12:10 PM Girish Patoliya via dev <dev(a)lists.frrouting.org> wrote: > currently write() is failing with bad file descriptor error. Since it's a socket not a pipe, maybe you have to send() instead of write()? -- William Herrin bill(a)herrin.us https://bill.herrin.us/

2 1

How to communicate on /run/frr/ldpd.vty unix socket
by Girish Patoliya 11 Mar '22

11 Mar '22

Hi I am trying to configure below sequence of commands from a C application. enable configure terminal mpls ldp router-id 1.1.1.1 I am connecting on /run/frr/ldpd.vty unix socket and trying to write about command on socket fd. currently write() is failing with bad file descriptor error. by debugging I found that ldpd.vty is owned by frr:frrvty while my application runs as root. to avoid this I compiled frr with --enable-user/group=root and vty group as root, still observed same issue. is there any way to communicate with ldpd.vty from separate C application process? Thanks Girish ________________________________ This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to security(a)mavenir.com. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects. Thank You

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 11 Mar '22

11 Mar '22

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. 6 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 1515041: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1515041: Null pointer dereferences (NULL_RETURNS) /pimd/pim_cmd_common.c: 592 in pim_process_no_rp_cmd() 586 vty_out(vty, "%% Unable to find specified RP\n"); 587 return NB_OK; 588 } 589 590 group_dnode = yang_dnode_get(vty->candidate_config->dnode, group_xpath); 591 >>> CID 1515041: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "group_dnode" when calling "yang_is_last_list_dnode". 592 if (yang_is_last_list_dnode(group_dnode)) 593 nb_cli_enqueue_change(vty, rp_xpath, NB_OP_DESTROY, NULL); 594 else 595 nb_cli_enqueue_change(vty, group_list_xpath, NB_OP_DESTROY, 596 group_str); 597 ** CID 1515040: Concurrent data access violations (MISSING_LOCK) /lib/northbound_grpc.cpp: 1281 in grpc_pthread_start(void *)() ________________________________________________________________________________________________________ *** CID 1515040: Concurrent data access violations (MISSING_LOCK) /lib/northbound_grpc.cpp: 1281 in grpc_pthread_start(void *)() 1275 GRPC_ARG_HTTP2_MIN_RECV_PING_INTERVAL_WITHOUT_DATA_MS, 5000); 1276 std::unique_ptr<grpc::ServerCompletionQueue> cq = 1277 builder.AddCompletionQueue(); 1278 std::unique_ptr<grpc::Server> server = builder.BuildAndStart(); 1279 s_server = server.get(); 1280 >>> CID 1515040: Concurrent data access violations (MISSING_LOCK) >>> Accessing "grpc_running" without holding lock "s_server_lock". Elsewhere, "grpc_running" is accessed with "s_server_lock" held 2 out of 3 times (2 of these accesses strongly imply that it is necessary). 1281 grpc_running = true; 1282 1283 /* Schedule all RPC handlers */ 1284 REQUEST_NEWRPC(GetCapabilities, NULL); 1285 REQUEST_NEWRPC(CreateCandidate, &candidates); 1286 REQUEST_NEWRPC(DeleteCandidate, &candidates); ** CID 1515039: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1515039: Insecure data handling (TAINTED_SCALAR) /vtysh/vtysh.c: 3704 in vtysh_log_read() 3698 "%d log messages from %s lost (vtysh reading too slowly)\n", 3699 lost_msgs, vclient->name); 3700 } 3701 } 3702 3703 text = buf.text + sizeof(buf.hdr.argpos[0]) * buf.hdr.n_argpos; >>> CID 1515039: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted expression "buf.hdr.n_argpos" to "vtysh_log_print", which uses it as a loop boundary. 3704 vtysh_log_print(vclient, &buf.hdr, text); 3705 3706 if (stderr_stdout_same) 3707 rl_forced_update_display(); 3708 3709 return; ** CID 1515038: Memory - illegal accesses (WRAPPER_ESCAPE) /lib/northbound_grpc.cpp: 1279 in grpc_pthread_start(void *)() ________________________________________________________________________________________________________ *** CID 1515038: Memory - illegal accesses (WRAPPER_ESCAPE) /lib/northbound_grpc.cpp: 1279 in grpc_pthread_start(void *)() 1273 builder.RegisterService(&service); 1274 builder.AddChannelArgument( 1275 GRPC_ARG_HTTP2_MIN_RECV_PING_INTERVAL_WITHOUT_DATA_MS, 5000); 1276 std::unique_ptr<grpc::ServerCompletionQueue> cq = 1277 builder.AddCompletionQueue(); 1278 std::unique_ptr<grpc::Server> server = builder.BuildAndStart(); >>> CID 1515038: Memory - illegal accesses (WRAPPER_ESCAPE) >>> The internal representation of local "server" escapes into "s_server", but is destroyed when it exits scope. 1279 s_server = server.get(); 1280 1281 grpc_running = true; 1282 1283 /* Schedule all RPC handlers */ 1284 REQUEST_NEWRPC(GetCapabilities, NULL); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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

01 Mar '22

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. 9 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 1514597: Memory - illegal accesses (OVERRUN) /vtysh/vtysh.c: 3594 in vtysh_log_print() ________________________________________________________________________________________________________ *** CID 1514597: Memory - illegal accesses (OVERRUN) /vtysh/vtysh.c: 3594 in vtysh_log_print() 3588 vis = &visual_prios[hdr->prio]; 3589 3590 localtime_r(&ts, &tm); 3591 strftime(ts_buf, sizeof(ts_buf), "%Y-%m-%d %H:%M:%S", &tm); 3592 3593 if (!stderr_tty) { >>> CID 1514597: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 128 bytes at byte offset 128 by dereferencing pointer "vis". 3594 const char *label = vis->label + strlen(vis->label) - 4; 3595 3596 fprintf(stderr, "%s.%03u [%s] %s: %.*s\n", ts_buf, 3597 hdr->ts_nsec / 1000000U, label, vclient->name, 3598 (int)textlen, text); 3599 return; ** CID 1514596: Control flow issues (UNEXPECTED_CONTROL_FLOW) /vtysh/vtysh.c: 222 in vtysh_client_receive() ________________________________________________________________________________________________________ *** CID 1514596: Control flow issues (UNEXPECTED_CONTROL_FLOW) /vtysh/vtysh.c: 222 in vtysh_client_receive() 216 cmh->cmsg_len = CMSG_LEN(sizeof(int)); 217 memset(CMSG_DATA(cmh), -1, sizeof(int)); 218 219 do { 220 ret = recvmsg(vclient->fd, &mh, 0); 221 if (ret < 0 && (errno == EINTR || errno == EAGAIN)) >>> CID 1514596: Control flow issues (UNEXPECTED_CONTROL_FLOW) >>> A "continue" statement within a "do ... while (...)" loop only continues execution of the loop body if the loop continuation condition is still true. Since the condition will never be true in a "do ... while (false)" loop, the "continue"statement has the same effect as a "break" statement. Did you intend execution to continue at the top of the loop? 222 continue; 223 } while (false); 224 225 if (cmh->cmsg_len == CMSG_LEN(sizeof(int))) { 226 int fd; 227 ** CID 1514595: (STRING_NULL) /vtysh/vtysh.c: 3657 in vtysh_log_read() ________________________________________________________________________________________________________ *** CID 1514595: (STRING_NULL) /vtysh/vtysh.c: 3682 in vtysh_log_read() 3676 puts("\r"); 3677 #endif 3678 fflush(stdout); 3679 } 3680 3681 text = buf.text + sizeof(buf.hdr.argpos[0]) * buf.hdr.n_argpos; >>> CID 1514595: (STRING_NULL) >>> Passing unterminated string "text" to "vtysh_log_print", which expects a null-terminated string. 3682 vtysh_log_print(vclient, &buf.hdr, text); 3683 3684 if (stderr_stdout_same) 3685 rl_forced_update_display(); 3686 3687 return; /vtysh/vtysh.c: 3657 in vtysh_log_read() 3651 snprintfrr(buf.text, sizeof(buf.text), 3652 "log monitor connection error: %m"); 3653 else 3654 snprintfrr( 3655 buf.text, sizeof(buf.text), 3656 "log monitor connection closed unexpectedly"); >>> CID 1514595: (STRING_NULL) >>> Passing unterminated string "buf.text" to "strlen", which expects a null-terminated string. 3657 buf.hdr.textlen = strlen(buf.text); 3658 3659 THREAD_OFF(vclient->log_reader); 3660 close(vclient->log_fd); 3661 vclient->log_fd = -1; 3662 ** CID 1514594: Memory - corruptions (OVERRUN) /lib/yang_wrappers.c: 719 in yang_dnode_get_binary_buf() ________________________________________________________________________________________________________ *** CID 1514594: Memory - corruptions (OVERRUN) /lib/yang_wrappers.c: 719 in yang_dnode_get_binary_buf() 713 char *value_str; 714 struct base64_decodestate s; 715 716 canon = YANG_DNODE_XPATH_GET_CANON(dnode, xpath_fmt); 717 cannon_len = strlen(canon); 718 decode_len = cannon_len; >>> CID 1514594: Memory - corruptions (OVERRUN) >>> Allocating insufficient memory for the terminating null of the string. 719 value_str = (char *)malloc(decode_len); 720 base64_init_decodestate(&s); 721 cnt = base64_decode_block(canon, cannon_len, value_str, &s); 722 723 ret_len = size > cnt ? cnt : size; 724 memcpy(buf, value_str, ret_len); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0