From: Phil Oester <kernel@linuxace.com>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] Fix NAT TCP sequence adjustment
Date: Sun, 3 Apr 2005 21:40:33 -0700 [thread overview]
Message-ID: <20050404044033.GA1847@linuxace.com> (raw)
In-Reply-To: <20050403235320.GB28850@linuxace.com>
[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]
On Sun, Apr 03, 2005 at 04:53:20PM -0700, Phil Oester wrote:
> On Sun, Apr 03, 2005 at 09:26:22PM +0200, Patrick McHardy wrote:
> > Great work Phil. One question though: You want to store the pre-adjusted
> > sequence number. What if the packet is a retransmission and
> > offset_before has been applied? If I understand correctly, depending
> > on the delta between offset_after and offset_before, this might cause
> > the before(...) test to give a false positive and screw up the state.
> > In case I'm wrong, could you a patch containing only the necessary
> > changes? I think the final fix for this problem should go in -stable,
> > ideally it would only be a single line "seq -= this_way->offset_after".
>
> I think you are correct, retransmission would falsely trigger the before.
> Testing a new patch...will likely submit tomorrow.
If the retransmitted packet were the same packet as the last one which was
mangled, the seq will be adjusted by offset_before, which at this point is
the same adjustment as the first packet received via offset_after. So,
seq == correction_pos for the retransmitted packet, and this is fairly trivial
to handle. This is the only case where I can see before() triggering a false
positive.
As per your request, below is only the bare minimum patch for -stable,
but the other patch to ip_conntrack_ftp for u16->u32 is likely another good
candidate for -stable.
On another note, It would be helpful if you published your tree somewhere so
patches could be based upon it...then I would not have wasted time sending
the u16->u32 patch which someone else submitted but which is not yet in
mainline or -bk. Time to consider a -nf snapshot?
Phil
Signed-off-by: Phil Oester <kernel@linuxace.com>
[-- Attachment #2: patch-ftpstable --]
[-- Type: text/plain, Size: 1042 bytes --]
diff -ru linux-orig/net/ipv4/netfilter/ip_nat_helper.c linux-stable/net/ipv4/netfilter/ip_nat_helper.c
--- linux-orig/net/ipv4/netfilter/ip_nat_helper.c 2005-03-02 02:37:49.000000000 -0500
+++ linux-stable/net/ipv4/netfilter/ip_nat_helper.c 2005-04-04 00:22:28.929366600 -0400
@@ -76,11 +76,14 @@
* correction, record it: we don't handle more than one
* adjustment in the window, but do deal with common case of a
* retransmit */
- if (this_way->offset_before == this_way->offset_after
- || before(this_way->correction_pos, seq)) {
- this_way->correction_pos = seq;
- this_way->offset_before = this_way->offset_after;
- this_way->offset_after += sizediff;
+ if (seq != this_way->correction_pos) {
+ seq -= this_way->offset_after;
+ if (this_way->offset_before == this_way->offset_after
+ || before(this_way->correction_pos, seq)) {
+ this_way->correction_pos = seq;
+ this_way->offset_before = this_way->offset_after;
+ this_way->offset_after += sizediff;
+ }
}
UNLOCK_BH(&ip_nat_seqofs_lock);
next prev parent reply other threads:[~2005-04-04 4:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-02 20:24 [PATCH] Fix NAT TCP sequence adjustment Phil Oester
2005-04-03 12:26 ` Milos Wimmer
2005-04-03 19:26 ` Patrick McHardy
2005-04-03 23:53 ` Phil Oester
2005-04-04 4:40 ` Phil Oester [this message]
2005-04-04 8:27 ` Patrick McHardy
2005-04-04 20:47 ` Phil Oester
2005-04-05 7:32 ` Patrick McHardy
2005-04-05 13:33 ` Patch lifetime " Amin Azez
2005-04-10 20:49 ` Harald Welte
2005-04-06 4:48 ` Phil Oester
2005-04-18 1:42 ` Patrick McHardy
2005-04-19 0:58 ` Phil Oester
2005-04-20 15:03 ` Patrick McHardy
2005-04-20 15:53 ` Phil Oester
2005-04-20 16:07 ` Patrick McHardy
2005-04-20 17:24 ` Phil Oester
2005-04-20 17:50 ` Patrick McHardy
2005-04-20 18:25 ` Phil Oester
2005-04-20 21:39 ` Martijn Lievaart
2005-04-21 1:41 ` Patrick McHardy
2005-04-21 1:38 ` Patrick McHardy
2005-04-21 12:31 ` Milos Wimmer
2005-04-21 12:32 ` Patrick McHardy
2005-04-21 13:31 ` Jonas Berlin
2005-04-21 23:01 ` Patrick McHardy
2005-04-27 0:44 ` Rusty Russell
2005-04-27 10:27 ` Patrick McHardy
2005-05-31 9:17 ` Rusty Russell
2005-05-31 13:02 ` Patrick McHardy
2005-05-31 13:48 ` Rusty Russell
2005-05-31 14:35 ` Patrick McHardy
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=20050404044033.GA1847@linuxace.com \
--to=kernel@linuxace.com \
--cc=kaber@trash.net \
--cc=netfilter-devel@lists.netfilter.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.