netdev
[Top] [All Lists]

Re: [PATCH] Make netfilter handle SACK in NAT'ed connections (was Re: Fw

To: kuznet@xxxxxxxxxxxxx
Subject: Re: [PATCH] Make netfilter handle SACK in NAT'ed connections (was Re: Fw: oops/bug in tcp, SACK doesn't work?)
From: Harald Welte <laforge@xxxxxxxxxxxx>
Date: Mon, 28 Jan 2002 19:19:23 +0100
Cc: netdev@xxxxxxxxxxx
In-reply-to: <200201281738.UAA00878@xxxxxxxxxxxxx>; from kuznet@xxxxxxxxxxxxx on Mon, Jan 28, 2002 at 08:38:32PM +0300
References: <20020127095716.H16571@xxxxxxxxxxxxxxxxxxxxxxx> <200201281738.UAA00878@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.3.17i
On Mon, Jan 28, 2002 at 08:38:32PM +0300, Alexey Kuznetsov wrote:
> Hello!

Hi Alexey.

> > The only question remaining is:  Is it worth the effort?  What do the
> > core linux developers think? 
> 
> About complexity... does not matter, "complexity" happens when something
> is logically not quite trivial. SACK mangling is just straight hand work
> rather than complexity. It is even not long looking at the patch. :-)

Mh. Ok, I will consider submitting it to the kernel after it was tested
for some more time.


> BTW what is this?
> 
>                       /* Half a match?  This means a partial retransmisison.
>                          It's a cracker being funky. */
> 
> From code I cannot guess, what does it mean. Does this mean that NAT can
> block some valid data?

It means that the connection tracking has found something to be modified
(like ftp PORT or irc DCC) by the nat module between two particular 
sequence number (e.g. start and end of the PORT command), but the packet
arriving at the nat helper (which is called after the conntrack helper) 
is operating on a packet which doesn't contain the full PORT command.

Because in this case the conntrack helper has already seen the full PORT
command, the nat helper is definitely dealing with a partial retransmission.

this partial retransmission is dropped, assuming that the next retransmission
will be a retransmission of the whole packet, as we have seen it before.

I'm not really sure what rusty's exact reasoning about this was, but I 
guess it was too complicated to replace only a part of the expectation-
causing string (PORT command).

We could handle this correctly, if we'd really try hard. But there are
a lot of cases (i.e. PORT command split over two seperate packets) where
we could deal better but it's just way more than you want to have inside
your kernel.  transparent proxies are better if you want to be perfect in
this.

> Alexey

-- 
Live long and prosper
- Harald Welte / laforge@xxxxxxxxxxxx               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

<Prev in Thread] Current Thread [Next in Thread>