| Message ID | 20191103053053.17996-1-tom.ty89@gmail.com |
|---|---|
| State | New |
| Headers |
Return-Path: <openvpn-devel-bounces@lists.sourceforge.net> Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director8.mail.ord1d.rsapps.net ([172.30.191.6]) by backend30.mail.ord1d.rsapps.net with LMTP id mGCeMXxmvl2kXgAAIUCqbw for <patchwork@openvpn.net>; Sun, 03 Nov 2019 01:32:44 -0400 Received: from proxy15.mail.ord1d.rsapps.net ([172.30.191.6]) by director8.mail.ord1d.rsapps.net with LMTP id +Ld4MXxmvl28JAAAfY0hYg ; Sun, 03 Nov 2019 01:32:44 -0400 Received: from smtp18.gate.ord1d ([172.30.191.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy15.mail.ord1d.rsapps.net with LMTP id kPs4MXxmvl1yeQAAAY1PeQ ; Sun, 03 Nov 2019 01:32:44 -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: smtp18.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; dkim=fail (signature verification failed) header.d=gmail.com; dmarc=fail (p=none; dis=none) header.from=gmail.com X-Suspicious-Flag: YES X-Classification-ID: 5c6cad4a-fdfb-11e9-aefa-5254005167a7-1-1 Received: from [216.105.38.7] ([216.105.38.7:46690] helo=lists.sourceforge.net) by smtp18.gate.ord1d.rsapps.net (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 48/56-30396-C766EBD5; Sun, 03 Nov 2019 01:32:44 -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.90_1) (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) id 1iR8UE-0006y0-LA; Sun, 03 Nov 2019 05:31:38 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <tom.ty89@gmail.com>) id 1iR8UD-0006xr-5c for openvpn-devel@lists.sourceforge.net; Sun, 03 Nov 2019 05:31:37 +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:Cc:To:From:Sender:Reply-To: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=S3b6EUyp5cHxzYyoJKzY60tiFFSYZb7bzdI42DYbyPg=; b=EX41sBt6EDDT0TTWAR/ErjWxT2 SrmbJyhqJigDaSxRlujOt7b94FExetkGqdlriqxFxKmqPeNImEbKFGAJI2/h0eq1GnOcDsngPbDWg 8f7tUmDub9RmrGHBL+QH4tbxY02pT55ghS9nz5rip6lqPWQRSAyt1F/U32teEoV5aCcQ=; 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:Cc:To:From :Sender:Reply-To: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=S3b6EUyp5cHxzYyoJKzY60tiFFSYZb7bzdI42DYbyPg=; b=m mplyRQk9Dm+9IFhExWYJ8Ysqo3M8NQLwD9kgKQqeU7QazvS/9oAj8xiHTq9ytoYlRUCNLGe5XQNIQ 93V79xHc3ofMzKuda7kTHvpbC39c0EOicasG7a/cPk2tnUB7Gw2O2eOWBm91AsoGyJ1j3E+MDpW4E MJkBsRDvMgSbbzWg=; Received: from mail-pl1-f176.google.com ([209.85.214.176]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.2) id 1iR8UB-00FepS-SA for openvpn-devel@lists.sourceforge.net; Sun, 03 Nov 2019 05:31:37 +0000 Received: by mail-pl1-f176.google.com with SMTP id a18so5031337plm.10 for <openvpn-devel@lists.sourceforge.net>; Sat, 02 Nov 2019 22:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=S3b6EUyp5cHxzYyoJKzY60tiFFSYZb7bzdI42DYbyPg=; b=sDOooqqVVCWbuSHdqv+IbQKF76X4GtuKPYTHEEmx75wdvFqEyzVLFsAYs1wMhnQ536 ATWmfr/29ooK3qPdjoVlJmsdhsWA8S9gszfMAFFj5dOf2W90muEuVKYzy2w6n/awZvOc IXPAIspW3exogEQYTL9Qn3CiizMzaPzPOxKGCYLmwDxTD7isQgxlX767aUsCD/bdI12R HDQ2a/clQ8DMcGqCDueLhOrDqezi8B5i3Qrm/7YiD8EnRiGkQYz00cggyvkb2/6XQIs7 pSTUjezWPZcdQQtcj8+qOQcGPtMtpGQXTQCNgPUfuKuZH38URaT12digmA/PwpcoBbUN uN1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=S3b6EUyp5cHxzYyoJKzY60tiFFSYZb7bzdI42DYbyPg=; b=fFXjfP17xR6JYmk3Pz551GfERyoCLEWXodt3qKU4RRl0DK+d1UR1z4qrPHK/Nhaj2+ gk9QD5tInraVcUckOzK8m6FWkW8pOTb1sPnF9tAlxIjUuRD1fiJEeT8qDPGjFWIKyKE+ vE3pvaYXy0dyxBQf0dSMJ4Kqt7Vd34YDIhEgw09uJ8MJfXQYRohbs9yJyolnUKX7YdB7 bIVNdK+PEZZNZIauGtm6v1P8n6TOPxvEDGyBbNWLz01LByugcBCMOvjrdTA3lPb7oOOM mYdrGWKVi4wnwImR/2fAQd2/cu2lFhYlFXJ5BnpByyCPmSgLYeXsoSdEf5WbDVLluEK0 s/ug== X-Gm-Message-State: APjAAAV0OMpbR/v7BrH2Hzvyk/DH+rjeX7eaAfO2Ox3/7dGEfTbzJhl0 0mKU4TEeQvbiEfCQnYdqrHQmFfsl X-Google-Smtp-Source: APXvYqzsJn3YuqUKHL0FlPId7fH6mrRYZxpVBNS7ySTpDVoxMcnbcx3NMAONVeVaDZG1ksCXo2sADg== X-Received: by 2002:a17:902:6807:: with SMTP id h7mr20453393plk.230.1572759089751; Sat, 02 Nov 2019 22:31:29 -0700 (PDT) Received: from localhost.localdomain (123202047155.ctinets.com. [123.202.47.155]) by smtp.gmail.com with ESMTPSA id c21sm11648464pgh.25.2019.11.02.22.31.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Nov 2019 22:31:29 -0700 (PDT) From: Tom Yan <tom.ty89@gmail.com> To: openvpn-devel@lists.sourceforge.net Date: Sun, 3 Nov 2019 13:30:53 +0800 Message-Id: <20191103053053.17996-1-tom.ty89@gmail.com> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tom.ty89[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (tom.ty89[at]gmail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.214.176 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.214.176 listed in list.dnswl.org] X-Headers-End: 1iR8UB-00FepS-SA Subject: [Openvpn-devel] [PATCH] networking/iproute2: support 31-bit ipv4 prefix (RFC 3021) X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: <openvpn-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/options/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel> List-Post: <mailto:openvpn-devel@lists.sourceforge.net> List-Help: <mailto:openvpn-devel-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox |
| Series |
[Openvpn-devel] networking/iproute2: support 31-bit ipv4 prefix (RFC 3021)
|
|
Commit Message
Tom Yan
Nov. 2, 2019, 6:30 p.m. UTC
--- src/openvpn/networking_iproute2.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Comments
Hi Tom, first of all, thanks a lot for your contribution! On 03/11/2019 06:30, Tom Yan wrote: > --- > src/openvpn/networking_iproute2.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/openvpn/networking_iproute2.c b/src/openvpn/networking_iproute2.c > index 1ddeb5cf..4e2435c1 100644 > --- a/src/openvpn/networking_iproute2.c > +++ b/src/openvpn/networking_iproute2.c > @@ -98,8 +98,10 @@ net_addr_v4_add(openvpn_net_ctx_t *ctx, const char *iface, > const char *addr_str = print_in_addr_t(*addr, 0, &ctx->gc); > const char *brd_str = print_in_addr_t(*broadcast, 0, &ctx->gc); > > - argv_printf(&argv, "%s addr add dev %s %s/%d broadcast %s", iproute_path, > - iface, addr_str, prefixlen, brd_str); > + argv_printf(&argv, "%s addr add dev %s %s/%d", iproute_path, > + iface, addr_str, prefixlen); > + if (prefixlen < 31) > + argv_printf_cat(&argv, " broadcast %s", brd_str); Unfortunately I am not able to grasp this fix entirely.. (maybe because I don't know RFC3021). Would you mind explaining *why* this is needed? What is this change fixing? Can you make an example where the actual code fails and how this change is fixing it? It would also be very nice if you could add such information to the commit message, so that it will remain in the git history. Thanks a lot! Regards, > argv_msg(M_INFO, &argv); > openvpn_execve_check(&argv, ctx->es, S_FATAL, "Linux ip addr add failed"); > >
Hello Antonio, With 31-bit IPv4 prefix, only two addresses can be provided with the single host bit. Neither the network address nor the broadcast address makes sense anymore in such "subnet", as it's basically for point-to-point link. Assigning such address with a broadcast address will prevent it from working properly anyway. While we can achieve the equivalence with the soon-to-be-removed p2p topology, or using a 30-bit prefix to avoid the bug (that "wastes" two addresses), I don't see why it shouldn't be fixed, as it's a proper standard (even though it may not be supported on every platform). Note that this has nothing to do with the net30 topology but the subnet topology. Sorry for not having elaborated in the commit message, as I thought the RFC is well-known and the patch already speaks for itself. If you are okay with it I can resend it with the above as its commit message. Regards, Tom On Sun, 3 Nov 2019 at 18:43, Antonio Quartulli <a@unstable.cc> wrote: > > Hi Tom, > > first of all, thanks a lot for your contribution! > > On 03/11/2019 06:30, Tom Yan wrote: > > --- > > src/openvpn/networking_iproute2.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/src/openvpn/networking_iproute2.c b/src/openvpn/networking_iproute2.c > > index 1ddeb5cf..4e2435c1 100644 > > --- a/src/openvpn/networking_iproute2.c > > +++ b/src/openvpn/networking_iproute2.c > > @@ -98,8 +98,10 @@ net_addr_v4_add(openvpn_net_ctx_t *ctx, const char *iface, > > const char *addr_str = print_in_addr_t(*addr, 0, &ctx->gc); > > const char *brd_str = print_in_addr_t(*broadcast, 0, &ctx->gc); > > > > - argv_printf(&argv, "%s addr add dev %s %s/%d broadcast %s", iproute_path, > > - iface, addr_str, prefixlen, brd_str); > > + argv_printf(&argv, "%s addr add dev %s %s/%d", iproute_path, > > + iface, addr_str, prefixlen); > > + if (prefixlen < 31) > > + argv_printf_cat(&argv, " broadcast %s", brd_str); > > Unfortunately I am not able to grasp this fix entirely.. (maybe because > I don't know RFC3021). > > Would you mind explaining *why* this is needed? > > What is this change fixing? Can you make an example where the actual > code fails and how this change is fixing it? > > > It would also be very nice if you could add such information to the > commit message, so that it will remain in the git history. > > > Thanks a lot! > Regards, > > > argv_msg(M_INFO, &argv); > > openvpn_execve_check(&argv, ctx->es, S_FATAL, "Linux ip addr add failed"); > > > > > > -- > Antonio Quartulli
Btw, is there a particular reason that we don't simply use "broadcast +" and let `ip` handle it? We won't even need to do the prefix length check if we aren't setting the broadcast address explicitly. Regards, On Sun, 3 Nov 2019 at 19:32, Tom Yan <tom.ty89@gmail.com> wrote: > > Hello Antonio, > > With 31-bit IPv4 prefix, only two addresses can be provided with the > single host bit. Neither the network address nor the broadcast address > makes sense anymore in such "subnet", as it's basically for > point-to-point link. Assigning such address with a broadcast address > will prevent it from working properly anyway. > > While we can achieve the equivalence with the soon-to-be-removed p2p > topology, or using a 30-bit prefix to avoid the bug (that "wastes" two > addresses), I don't see why it shouldn't be fixed, as it's a proper > standard (even though it may not be supported on every platform). > > Note that this has nothing to do with the net30 topology but the > subnet topology. > > Sorry for not having elaborated in the commit message, as I thought > the RFC is well-known and the patch already speaks for itself. If you > are okay with it I can resend it with the above as its commit message. > > Regards, > Tom > > On Sun, 3 Nov 2019 at 18:43, Antonio Quartulli <a@unstable.cc> wrote: > > > > Hi Tom, > > > > first of all, thanks a lot for your contribution! > > > > On 03/11/2019 06:30, Tom Yan wrote: > > > --- > > > src/openvpn/networking_iproute2.c | 6 ++++-- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/src/openvpn/networking_iproute2.c b/src/openvpn/networking_iproute2.c > > > index 1ddeb5cf..4e2435c1 100644 > > > --- a/src/openvpn/networking_iproute2.c > > > +++ b/src/openvpn/networking_iproute2.c > > > @@ -98,8 +98,10 @@ net_addr_v4_add(openvpn_net_ctx_t *ctx, const char *iface, > > > const char *addr_str = print_in_addr_t(*addr, 0, &ctx->gc); > > > const char *brd_str = print_in_addr_t(*broadcast, 0, &ctx->gc); > > > > > > - argv_printf(&argv, "%s addr add dev %s %s/%d broadcast %s", iproute_path, > > > - iface, addr_str, prefixlen, brd_str); > > > + argv_printf(&argv, "%s addr add dev %s %s/%d", iproute_path, > > > + iface, addr_str, prefixlen); > > > + if (prefixlen < 31) > > > + argv_printf_cat(&argv, " broadcast %s", brd_str); > > > > Unfortunately I am not able to grasp this fix entirely.. (maybe because > > I don't know RFC3021). > > > > Would you mind explaining *why* this is needed? > > > > What is this change fixing? Can you make an example where the actual > > code fails and how this change is fixing it? > > > > > > It would also be very nice if you could add such information to the > > commit message, so that it will remain in the git history. > > > > > > Thanks a lot! > > Regards, > > > > > argv_msg(M_INFO, &argv); > > > openvpn_execve_check(&argv, ctx->es, S_FATAL, "Linux ip addr add failed"); > > > > > > > > > > -- > > Antonio Quartulli
diff --git a/src/openvpn/networking_iproute2.c b/src/openvpn/networking_iproute2.c index 1ddeb5cf..4e2435c1 100644 --- a/src/openvpn/networking_iproute2.c +++ b/src/openvpn/networking_iproute2.c @@ -98,8 +98,10 @@ net_addr_v4_add(openvpn_net_ctx_t *ctx, const char *iface, const char *addr_str = print_in_addr_t(*addr, 0, &ctx->gc); const char *brd_str = print_in_addr_t(*broadcast, 0, &ctx->gc); - argv_printf(&argv, "%s addr add dev %s %s/%d broadcast %s", iproute_path, - iface, addr_str, prefixlen, brd_str); + argv_printf(&argv, "%s addr add dev %s %s/%d", iproute_path, + iface, addr_str, prefixlen); + if (prefixlen < 31) + argv_printf_cat(&argv, " broadcast %s", brd_str); argv_msg(M_INFO, &argv); openvpn_execve_check(&argv, ctx->es, S_FATAL, "Linux ip addr add failed");