Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1292218pxb; Thu, 16 Sep 2021 04:28:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDBNsovzVtrfXNCPnghW5ATqdymUqjJ2mmbPhT92Br3obHVkIKtfALHKBxf3HZDn07//41 X-Received: by 2002:a17:906:2613:: with SMTP id h19mr5763970ejc.66.1631791715916; Thu, 16 Sep 2021 04:28:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631791715; cv=none; d=google.com; s=arc-20160816; b=aemzZXKcg7JR+KwpiO8j1lHyer0G0yZ6U5AfgnmykHkvfG4h/wI/oNpbzmnpfJvub0 hzuX4buEobrpbdIcuLDHNAzh+hIjt7Gn8QkgANqzCeDjrgnB5XU5cvFb9tLwf7l80t1z ZP8WgCdCBFlXuPaRcnz7OLMQQ51kjLvVGoz0TcP8wC/VvcRzocDfZkmHEXDQ3FDB4Rya IGsZS1xj6B8sfPNcot8v278h/rVgotp/8hpzIAD6QoDOtwnK06NAhlKMu/hS8KD3BJJ1 XreQzOOXllDnhv6s9raMiEOjKcWfVoO5yHMAO/ekksJNKrBNcGD4RGA7TFg38Z0jInBo mwqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=XO0KkUFxcezXFMvFs3o4NNOp40qLkqNHcuamaWbjduc=; b=wucOlTE0QgEs0INBrmluhLTBTgAnJclS6wtlYsqk/qgkzoVywrQefTzkctYOCD3UZz sJoOxqibhfVxjzgHIBWluGqIyq3RJkCqVOPJvbcmqkm4yCFrZTkyEYi9QRbVqA56xz8e fwtlkx1WddLzDiD2XLKn53wqzVRgUiPGyR9+4Y+HMESkyViYXmhW0SaYDfOn7GBliCzI NdeE8V5VRRp+ZY9lydByazEFT09TApUe48Li0dPvWQPkUNRfsXOXDdf/fExEiu5ydurc FIwjJNZDuAcY3B3/UiW39rd6pLw39vTJzMYNJOXxNfbCAJMGvP+LfUPELLDjnkiRInFW RA+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s1si2719995ejn.348.2021.09.16.04.28.12; Thu, 16 Sep 2021 04:28:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237989AbhIPL2L (ORCPT + 99 others); Thu, 16 Sep 2021 07:28:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234769AbhIPL2K (ORCPT ); Thu, 16 Sep 2021 07:28:10 -0400 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2909DC061574; Thu, 16 Sep 2021 04:26:50 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1mQpXN-0002K7-IT; Thu, 16 Sep 2021 13:26:41 +0200 Date: Thu, 16 Sep 2021 13:26:41 +0200 From: Florian Westphal To: Cole Dishington Cc: pablo@netfilter.org, kadlec@netfilter.org, fw@strlen.de, davem@davemloft.net, kuba@kernel.org, shuah@kernel.org, linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, Anthony Lineham , Scott Parlane , Blair Steven Subject: Re: [PATCH net v4] net: netfilter: Fix port selection of FTP for NF_NAT_RANGE_PROTO_SPECIFIED Message-ID: <20210916112641.GC20414@breakpoint.cc> References: <20210916041057.459-1-Cole.Dishington@alliedtelesis.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210916041057.459-1-Cole.Dishington@alliedtelesis.co.nz> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Cole Dishington wrote: > + /* Avoid applying nat->range to the reply direction */ > + if (!exp->dir || !nat->range_info.min_proto.all || !nat->range_info.max_proto.all) { > + min = ntohs(exp->saved_proto.tcp.port); > + range_size = 65535 - min + 1; > + } else { > + min = ntohs(nat->range_info.min_proto.all); > + range_size = ntohs(nat->range_info.max_proto.all) - min + 1; > + } > + > /* Try to get same port: if not, try to change it. */ > - for (port = ntohs(exp->saved_proto.tcp.port); port != 0; port++) { > - int ret; > + first_port = ntohs(exp->saved_proto.tcp.port); > + if (min > first_port || first_port > (min + range_size - 1)) > + first_port = min; > > + for (i = 0, port = first_port; i < range_size; i++, port = (port - first_port + i) % range_size) { This looks complicated. As far as I understand, this could instead be written like this (not even compile tested): /* Avoid applying nat->range to the reply direction */ if (!exp->dir || !nat->range_info.min_proto.all || !nat->range_info.max_proto.all) { min = 1; max = 65535; range_size = 65535; } else { min = ntohs(nat->range_info.min_proto.all); max = ntohs(nat->range_info.max_proto.all); range_size = max - min + 1; } /* Try to get same port: if not, try to change it. */ port = ntohs(exp->saved_proto.tcp.port); if (port < min || port > max) port = min; for (i = 0; i < range_size; i++) { exp->tuple.dst.u.tcp.port = htons(port); ret = nf_ct_expect_related(exp, 0); if (ret != -EBUSY) break; port++; if (port > max) port = min; } if (ret != 0) { ... AFAICS this is the same, we loop at most range_size times, in case range_size is 64k, we will loop through all (hmmm, not good actually, but better make that a different change) else through given min - max range. If orig port was in-range, we try it first, then increment. If port exceeds upper bound, cycle back to min. What do you think?