The following reply was made to PR kern/166501; it has been noted by GNATS.
From: Sergey Smitienko <hun...@comsys.com.ua>
To: bug-follo...@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--
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
