All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cole Dishington <Cole.Dishington@alliedtelesis.co.nz>
To: "fw@strlen.de" <fw@strlen.de>
Cc: "coreteam@netfilter.org" <coreteam@netfilter.org>,
	"netfilter-devel@vger.kernel.org"
	<netfilter-devel@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"pablo@netfilter.org" <pablo@netfilter.org>,
	Anthony Lineham <Anthony.Lineham@alliedtelesis.co.nz>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"kadlec@netfilter.org" <kadlec@netfilter.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Blair Steven <Blair.Steven@alliedtelesis.co.nz>,
	Scott Parlane <Scott.Parlane@alliedtelesis.co.nz>
Subject: Re: [PATCH net v4] net: netfilter: Fix port selection of FTP for NF_NAT_RANGE_PROTO_SPECIFIED
Date: Thu, 16 Sep 2021 20:30:37 +0000	[thread overview]
Message-ID: <77b0addceb098af07f3bb20fbb708d190ae58b03.camel@alliedtelesis.co.nz> (raw)
In-Reply-To: <20210916112641.GC20414@breakpoint.cc>

On Thu, 2021-09-16 at 13:26 +0200, Florian Westphal wrote:
> Cole Dishington <Cole.Dishington@alliedtelesis.co.nz> 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;
> 	}

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?

> 
>   	/* 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?
Looks good, just the one question above.

Thanks for your time reviewing!

  reply	other threads:[~2021-09-16 20:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16  4:10 [PATCH net v4] net: netfilter: Fix port selection of FTP for NF_NAT_RANGE_PROTO_SPECIFIED Cole Dishington
2021-09-16 11:26 ` Florian Westphal
2021-09-16 20:30   ` Cole Dishington [this message]
2021-09-17 14:04     ` Florian Westphal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=77b0addceb098af07f3bb20fbb708d190ae58b03.camel@alliedtelesis.co.nz \
    --to=cole.dishington@alliedtelesis.co.nz \
    --cc=Anthony.Lineham@alliedtelesis.co.nz \
    --cc=Blair.Steven@alliedtelesis.co.nz \
    --cc=Scott.Parlane@alliedtelesis.co.nz \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=kadlec@netfilter.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.