From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48388C433FE for ; Fri, 17 Sep 2021 14:04:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2FA1C60E08 for ; Fri, 17 Sep 2021 14:04:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241440AbhIQOFr (ORCPT ); Fri, 17 Sep 2021 10:05:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234531AbhIQOFl (ORCPT ); Fri, 17 Sep 2021 10:05:41 -0400 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 080F7C061574; Fri, 17 Sep 2021 07:04:18 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1mRETI-0002CE-9i; Fri, 17 Sep 2021 16:04:08 +0200 Date: Fri, 17 Sep 2021 16:04:08 +0200 From: Florian Westphal To: Cole Dishington Cc: "fw@strlen.de" , "coreteam@netfilter.org" , "netfilter-devel@vger.kernel.org" , "davem@davemloft.net" , "pablo@netfilter.org" , Anthony Lineham , "shuah@kernel.org" , "kadlec@netfilter.org" , "linux-kernel@vger.kernel.org" , "kuba@kernel.org" , "netdev@vger.kernel.org" , Blair Steven , Scott Parlane Subject: Re: [PATCH net v4] net: netfilter: Fix port selection of FTP for NF_NAT_RANGE_PROTO_SPECIFIED Message-ID: <20210917140408.GD15906@breakpoint.cc> References: <20210916041057.459-1-Cole.Dishington@alliedtelesis.co.nz> <20210916112641.GC20414@breakpoint.cc> <77b0addceb098af07f3bb20fbb708d190ae58b03.camel@alliedtelesis.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77b0addceb098af07f3bb20fbb708d190ae58b03.camel@alliedtelesis.co.nz> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Cole Dishington wrote: > On Thu, 2021-09-16 at 13:26 +0200, Florian Westphal wrote: > > >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; > > } > > The original code defined the range as [ntohs(exp->saved_proto.tcp.port), 65535]. The above would > cause a change in behaviour, should we try to avoid it? Oh indeed, oversight on my part. Good question, current loop is not good either as it might take too long to complete. Maybe best to limit/cap the range to 128, e.g. try to use port as-is, then pick a random value between 1024 and 65535 - 128, make 128 tries and if all is taken, error out. I will leave it up to you on how you'd like to handle this. One way would be to make a small preparation patch and then built the range patch on top of it.