Date: Fri, 30 Mar 2012 22:10:13 GMT From: Sergey Smitienko <hunter@comsys.com.ua> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/166501: FreeBSD 9.0 generates incorrect SEQ/ACK numbers under load Message-ID: <201203302210.q2UMADM1035770@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/166501; it has been noted by GNATS.
From: Sergey Smitienko <hunter@comsys.com.ua>
To: bug-followup@FreeBSD.org
Cc:
Subject: Re: kern/166501: FreeBSD 9.0 generates incorrect SEQ/ACK numbers
under load
Date: Sat, 31 Mar 2012 01:07:40 +0300
This is a multi-part message in MIME format.
--------------080707000708040403050503
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
I have pf running on the server. It's has basic ruleset.
I have table <trusted> with 4k+ networks of our web site 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.
In the tcpdump in report you can see Syn/Ack packet with 0 window size.
And then one more packet with 8K tcp window.
This packet is generated by pf 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.
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
seq/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 includes modulate state function, which is basicky an addition
of strong 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.
--
Sergey Smitienko
--------------080707000708040403050503
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<pre wrap="">I have pf running on the server. It's has basic ruleset.
I have table <trusted> with 4k+ networks of our web site 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.
In the tcpdump in report you can see Syn/Ack packet with 0 window size.
And then one more packet with 8K tcp window.
This packet is generated by pf 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.
From the over side, I have 20Gb of tcpdump files with 10<sup class="moz-txt-sup"><span style="display:inline-block;width:0;height:0;overflow:hidden">^</span>8</sup> packets recorded.
I've wrote a simple parser, which can detect sessions with incorrect
seq/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 includes modulate state function, which is basicky an addition
of strong 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.
--
Sergey Smitienko
</pre>
</body>
</html>
--------------080707000708040403050503--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203302210.q2UMADM1035770>