From patchwork Mon Aug 8 05:23:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gert Doering X-Patchwork-Id: 2643 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director12.mail.ord1d.rsapps.net ([172.30.191.6]) by backend30.mail.ord1d.rsapps.net with LMTP id KMKIGQ8w8WISJwAAIUCqbw (envelope-from ) for ; Mon, 08 Aug 2022 11:47:27 -0400 Received: from proxy11.mail.ord1d.rsapps.net ([172.30.191.6]) by director12.mail.ord1d.rsapps.net with LMTP id CP9cGQ8w8WIQHQAAIasKDg (envelope-from ) for ; Mon, 08 Aug 2022 11:47:27 -0400 Received: from smtp26.gate.ord1d ([172.30.191.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy11.mail.ord1d.rsapps.net with LMTPS id 0FkDGQ8w8WJtYgAAgKDEHA (envelope-from ) for ; Mon, 08 Aug 2022 11:47:27 -0400 X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO X-Virus-Scanned: OK X-Orig-To: openvpnslackdevel@openvpn.net X-Originating-Ip: [216.105.38.7] Authentication-Results: smtp26.gate.ord1d.rsapps.net; iprev=pass policy.iprev="216.105.38.7"; spf=pass smtp.mailfrom="openvpn-devel-bounces@lists.sourceforge.net" smtp.helo="lists.sourceforge.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dmarc=none (p=nil; dis=none) header.from=greenie.muc.de X-Suspicious-Flag: YES X-Classification-ID: 66987e14-1731-11ed-8117-525400c5b129-1-1 Received: from [216.105.38.7] ([216.105.38.7:57952] helo=lists.sourceforge.net) by smtp26.gate.ord1d.rsapps.net (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id AB/F8-30889-E0031F26; Mon, 08 Aug 2022 11:47:26 -0400 Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.94.2) (envelope-from ) id 1oL4xT-0005cp-96; Mon, 08 Aug 2022 15:46:22 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oL4xR-0005cf-HL for openvpn-devel@lists.sourceforge.net; Mon, 08 Aug 2022 15:46:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:MIME-Version:Message-Id: Date:Subject:To:From:Sender:Reply-To:Cc:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ki2EADLhGH+K9JeVzBCE3jp69IWI6nlfGgVYF0EKev4=; b=f+Vs80GkEaK0QrxqyEmVAHYGYd Tn9Wfs3OHpjI6pbXoHlcgdWtk/Cu+XVay+DO60utzNJHKfTIaATekqMl8HkPot19gMQ+2KdZl94Io xdE0jetSEj23A0hzjsJg8vjvQ8Bxi8Z+6cGQ3X51umcqa+edJ0qPT0GdzwXO2eTvcMp4=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Type:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=ki2EADLhGH+K9JeVzBCE3jp69IWI6nlfGgVYF0EKev4=; b=b 546gEVDEPmYSu6TjARakIpeSC4ZN0QCPsMViQJQKIm/Npnoyf43eUboORqMpEIedsjXI0Gi8enIwS oaGYqW2R7eItb0ZJSCgXcQna2SzKvUrxT6wEBs8uOnHvtjf4+MWlMxH9sYYKoNxk/WzaoayKNbXPg 37lNOdG9BstkSkPA=; Received: from vmail1.greenie.net ([195.30.8.66]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.94.2) id 1oL4xM-007vU8-N7 for openvpn-devel@lists.sourceforge.net; Mon, 08 Aug 2022 15:46:20 +0000 Received: from nbsd81.ov.greenie.net (nbsd81.ov.greenie.net [IPv6:2001:608:0:814:0:0:f000:17]) by vmail1.greenie.net (8.17.1/8.16.1) with ESMTP id 278FNiNA050737 for ; Mon, 8 Aug 2022 17:23:44 +0200 (CEST) Received: by nbsd81.ov.greenie.net (Postfix, from userid 1000) id 6A29C7653D; Mon, 8 Aug 2022 17:23:44 +0200 (CEST) From: Gert Doering To: openvpn-devel@lists.sourceforge.net Date: Mon, 8 Aug 2022 17:23:44 +0200 Message-Id: <20220808152344.17539-1-gert@greenie.muc.de> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (vmail1.greenie.net [IPv6:2001:608:1:995a:20c:29ff:feb8:10eb]); Mon, 08 Aug 2022 17:23:44 +0200 (CEST) X-Spam-Report: Spam detection software, running on the system "util-spamd-1.v13.lw.sourceforge.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: - NetBSD "dynamic tap" (--dev tap -> tap) handling had special #ifdef'ed code inside open_tun_generic() - pull out, move to NetBSD open_tun(). Roughly the same amount of code, less #ifdef, cod [...] Content analysis details: (-2.0 points, 6.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [195.30.8.66 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_NONE SPF: sender does not publish an SPF Record X-Headers-End: 1oL4xM-007vU8-N7 Subject: [Openvpn-devel] [PATCH] cleanup open_tun() for TARGET_NETBSD X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox - NetBSD "dynamic tap" (--dev tap -> tap) handling had special #ifdef'ed code inside open_tun_generic() - pull out, move to NetBSD open_tun(). Roughly the same amount of code, less #ifdef, code flow is more clear. - fix one spurious warning about "remote" not being initialized - adjust NetBSD do_open() comments to actual code - the "pre NetBSD 4.0" code has long be removed, but the comment was still there. Signed-off-by: Gert Doering Acked-by: Antonio Quartulli --- src/openvpn/tun.c | 72 +++++++++++++++++++++++++---------------------- 1 file changed, 38 insertions(+), 34 deletions(-) diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 54f7d72c..9cba1c3a 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -1380,7 +1380,7 @@ do_ifconfig_ipv4(struct tuntap *tt, const char *ifname, int tun_mtu, } #elif defined(TARGET_NETBSD) - in_addr_t remote_end; /* for "virtual" subnet topology */ + in_addr_t remote_end = INADDR_ANY; /* for "virtual" subnet topology */ if (tun) { @@ -1762,29 +1762,6 @@ open_tun_generic(const char *dev, const char *dev_type, const char *dev_node, * explicit unit number. Try opening /dev/[dev]n * where n = [0, 255]. */ -#ifdef TARGET_NETBSD - /* on NetBSD, tap (but not tun) devices are opened by - * opening /dev/tap and then querying the system about the - * actual device name (tap0, tap1, ...) assigned - */ - if (strcmp(dev, "tap") == 0) - { - struct ifreq ifr; - if ((tt->fd = open( "/dev/tap", O_RDWR)) < 0) - { - msg(M_FATAL, "Cannot allocate NetBSD TAP dev dynamically"); - } - if (ioctl( tt->fd, TAPGIFNAME, (void *)&ifr ) < 0) - { - msg(M_FATAL, "Cannot query NetBSD TAP device name"); - } - CLEAR(dynamic_name); - strncpy( dynamic_name, ifr.ifr_name, sizeof(dynamic_name)-1 ); - dynamic_opened = true; - openvpn_snprintf(tunname, sizeof(tunname), "/dev/%s", dynamic_name ); - } - else -#endif if (!tun_name_is_fixed(dev)) { @@ -2759,24 +2736,51 @@ read_tun(struct tuntap *tt, uint8_t *buf, int len) #elif defined(TARGET_NETBSD) /* - * NetBSD before 4.0 does not support IPv6 on tun out of the box, - * but there exists a patch (sys/net/if_tun.c, 1.79->1.80, see PR 32944). - * - * NetBSD 4.0 and up do, but we need to put the tun interface into - * "multi_af" mode, which will prepend the address family to all packets - * (same as OpenBSD and FreeBSD). If this is not enabled, the kernel - * silently drops all IPv6 packets on output and gets confused on input. + * NetBSD 4.0 and up support IPv6 on tun interfaces, but we need to put + * the tun interface into "multi_af" mode, which will prepend the address + * family to all packets (same as OpenBSD and FreeBSD). * - * On earlier versions, multi_af is not available at all, so we have - * two different NetBSD code variants here :-( + * If this is not enabled, the kernel silently drops all IPv6 packets on + * output and gets confused on input. * + * Note: --dev tap3 works *if* the interface is created externally by + * "ifconfig tap3 create" + * (and for devices beyond tap3, "mknod /dev/tapN c ...") + * but we do not have code to do that inside OpenVPN */ void open_tun(const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt, openvpn_net_ctx_t *ctx) { - open_tun_generic(dev, dev_type, dev_node, tt); + /* on NetBSD, tap (but not tun) devices are opened by + * opening /dev/tap and then querying the system about the + * actual device name (tap0, tap1, ...) assigned + */ + if (strcmp(dev, "tap") == 0) + { + struct ifreq ifr; + if ((tt->fd = open( "/dev/tap", O_RDWR)) < 0) + { + msg(M_FATAL, "Cannot allocate NetBSD TAP dev dynamically"); + } + if (ioctl( tt->fd, TAPGIFNAME, (void *)&ifr ) < 0) + { + msg(M_FATAL, "Cannot query NetBSD TAP device name"); + } + set_nonblock(tt->fd); + set_cloexec(tt->fd); /* don't pass fd to scripts */ + msg(M_INFO, "TUN/TAP device %s opened", ifr.ifr_name); + + tt->actual_name = string_alloc(ifr.ifr_name, NULL); + } + else + { + /* dynamic / named tun can be handled by the generic function + * named tap ("tap3") is handled there as well, if pre-created + */ + open_tun_generic(dev, dev_type, dev_node, tt); + } if (tt->fd >= 0) {