From owner-freebsd-current@FreeBSD.ORG Fri Nov 23 17:35:28 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7CD816A468 for ; Fri, 23 Nov 2007 17:35:28 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 769B313C4CC for ; Fri, 23 Nov 2007 17:35:28 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id lANHAdti080739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 09:10:40 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47470993.2060707@errno.com> Date: Fri, 23 Nov 2007 09:10:43 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-dcc-servers-Metrics: om; whitelist Cc: Kip Macy , Mike Silbersack , current@freebsd.org Subject: Re: TCP RST+data! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2007 17:35:29 -0000 Ian FREISLICH wrote: > "Kip Macy" wrote: > >> On Nov 22, 2007 12:14 PM, Ian FREISLICH wrote: >> >>> Hi >>> >>> I have a device (sip/iax phone) that has a web interface and a >>> poorly documented CLI. The only thing is it sends a RST with its >>> last data packet. "Stevens" seems to indicate an RST should discard >>> buffered data and I suspect that's what's happening when I try to >>> browse to it. >>> >>> However, Windows and MacOs both pull up the web page. Is this a >>> bug in our TCP implimentation or in theirs? >>> >>> Here's a tcpdump of seamonkey trying to retrieve the document index: >>> >>> 22:07:53.728516 IP (tos 0x0, ttl 64, id 24507, offset 0, flags [DF], proto >>> > TCP (6), length 60) 196.7.162.28.50118 > 196.7.162.30.80: S, cksum 0xdbdd (corr > ect), 2746220400:2746220400(0) win 65535 p 16267181 0> > >>> 22:07:53.731512 IP (tos 0x0, ttl 64, id 36, offset 0, flags [DF], proto TCP >>> > (6), length 60) 196.7.162.30.80 > 196.7.162.28.50118: S, cksum 0xbdba (correct > ), 2416404465:2416404465(0) ack 2746220401 win 8192 nop,timestamp 2333 16267181> > >>> 22:07:53.731543 IP (tos 0x0, ttl 64, id 24508, offset 0, flags [DF], proto >>> > TCP (6), length 52) 196.7.162.28.50118 > 196.7.162.30.80: ., cksum 0xe8f5 (corr > ect), 1:1(0) ack 1 win 8326 > >>> 22:07:53.731593 IP (tos 0x0, ttl 64, id 24509, offset 0, flags [DF], proto >>> > TCP (6), length 428) 196.7.162.28.50118 > 196.7.162.30.80: P 1:377(376) ack 1 w > in 8326 > >>> 22:07:53.770545 IP (tos 0x0, ttl 64, id 37, offset 0, flags [DF], proto TCP >>> > (6), length 52) 196.7.162.30.80 > 196.7.162.28.50118: ., cksum 0xe948 (correct > ), 1:1(0) ack 377 win 7867 > >>> 22:07:54.004963 IP (tos 0x0, ttl 64, id 38, offset 0, flags [DF], proto TCP >>> > (6), length 61) 196.7.162.30.80 > 196.7.162.28.50118: P, cksum 0xcdea (correct > ), 1:10(9) ack 377 win 8192 > >>> 22:07:54.018027 IP (tos 0x0, ttl 64, id 39, offset 0, flags [DF], proto TCP >>> > (6), length 638) 196.7.162.30.80 > 196.7.162.28.50118: RP 10:608(598) ack 377 > win 8192 [!RST+ 200 OK\015\012Server: Rapid Logic/1.] > >> Looking at your later trace, data with the RST is a red herring. The >> only thing that stands out to me as being odd and perhaps is the >> issue, is that the window size for the SYN and the ack are >> inconsistent on FreeBSD but are consistent on OS X. I'm not sure off >> hand where the number 8326 comes from. It could be that when the SIP's >> stack is generating the ack for the GET it concludes that the window >> accounting state is incorrect. >> >> Perhaps Mike can shed some light when he gets back online. >> > > I see. Playing around with net.inet.tcp sysctls, disabling delayed_ack > fixes the problem with this phone. Do you think that this is a bug > in the phone's TCP stack? > Is there a proxy involved or is this session end-to-end? Not sure if you described the setup but it might be useful (e.g. is the phone using wireless). Sam