Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Mar 2012 01:00:49 +0300
From:      Sergey Smitienko <hunter@comsys.com.ua>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: FreeBSD 9.0 generates incorrect SEQ/ACK numbers under load
Message-ID:  <4F762D11.1080604@comsys.com.ua>
In-Reply-To: <4F75CD8A.2050509@freebsd.org>
References:  <4F7463CF.8010206@comsys.com.ua> <4F759DB3.2060706@freebsd.org> <4F75AF4D.1040203@comsys.com.ua> <4F75CD8A.2050509@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
30.03.12 18:13, Andre Oppermann wrote:
> On 30.03.2012 15:04, Sergey Smitienko wrote:
>> Here you go, two sessions, one with win set in Syn/Ack packet and other
>> with separate "windows open" Ack packet.
>
> Thanks for the tcpdumps.  The window update issue seems to be separate
> from the seq#ack# problem.
No, it's not. You gave me an idea.

I have pf running on the server.  It's has basic ruleset.
We have table <trusted> with 4k+ networks of our usual visitors.
pf rules looks like this:

pass in quick from <trusted> to <me> port 80 keep state
pass in quick from any to <me> port 80 synproxy state.

So, in case of synproxy pf anwers Syn packet with Syn/Ack without
knowledge of window size,
and then passes connection to the kernel tcp stack and generates "window
open" Ack packet.
I've replaced "synproxy state" with usual "keep state" in pf and I don't
see any Syn/Ack packets
with zero window size.

>From the over side, I have 20Gb of tcpdump files with 10^8 packets recorded.
I've wrote a simple parser, which can detect sessions with incorrect
sec/ack numbers. Then I've
checked all IP addresses with failed TCP sessions and non of them was
from <trusted> set.
So, 100% of failed sessions was comming through pf synproxy state.
Synproxy state also include
modulate state function, which is basicky an addition of random number
to seq/ack numbers.
So, I think there is a case, then tcp comming from kernel is not
properly modulated/demodulated
by pf and this causes generation of incorrect seq/ack numbers.

> Why do set the recvspace to the very low value of 8192?
8K is big enough for usual GET request or for POST with login or comment.

-- 
Sergey Smitienko





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F762D11.1080604>