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>