From owner-freebsd-questions@FreeBSD.ORG Sat Mar 24 12:00:01 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AE0B16A402 for ; Sat, 24 Mar 2007 12:00:01 +0000 (UTC) (envelope-from rleippe@bellsouth.net) Received: from imf02aec.mail.bellsouth.net (imf02aec.mail.bellsouth.net [205.152.59.50]) by mx1.freebsd.org (Postfix) with ESMTP id 486E113C455 for ; Sat, 24 Mar 2007 12:00:01 +0000 (UTC) (envelope-from rleippe@bellsouth.net) Received: from ibm60aec.bellsouth.net ([68.18.179.203]) by imf19aec.mail.bellsouth.net with ESMTP id <20070324114103.WVTP1489.imf19aec.mail.bellsouth.net@ibm60aec.bellsouth.net> for ; Sat, 24 Mar 2007 07:41:03 -0400 Received: from [192.168.1.96] (really [68.18.179.203]) by ibm60aec.bellsouth.net with ESMTP id <20070324114102.LRGW1536.ibm60aec.bellsouth.net@[192.168.1.96]> for ; Sat, 24 Mar 2007 07:41:02 -0400 From: Richard To: freebsd-questions@freebsd.org In-Reply-To: <86odmlhzn8.fsf@king.swox.se> References: <868xdqnnzd.fsf@king.swox.se> <86odmlhzn8.fsf@king.swox.se> Content-Type: text/plain Date: Sat, 24 Mar 2007 07:40:50 -0400 Message-Id: <1174736450.52355.113.camel@darkstar> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: TCP conection problems IBM VM -> FreeBSD X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rleippe@bellsouth.net List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2007 12:00:01 -0000 > These are the ones the correspond. They come in bursts like that. If > I let it run a little longer, I get output like this: > > 19:45:56.939958 IP vm.se.lsoft.com.58679 > bang.swox.se.smtp: S 678305700:678305700(0) win 8192 > 19:45:56.940154 IP bang.swox.se.smtp > vm.se.lsoft.com.58679: S 3183232720:3183232720(0) ack 678305701 win 57344 > 19:45:56.974421 IP vm.se.lsoft.com.58679 > bang.swox.se.smtp: R 678305701:678305701(0) win 0 > 19:45:59.939737 IP vm.se.lsoft.com.58679 > bang.swox.se.smtp: S 678305700:678305700(0) win 8192 > 19:45:59.939905 IP bang.swox.se.smtp > vm.se.lsoft.com.58679: S 1749284606:1749284606(0) ack 678305701 win 57344 > 19:45:59.978666 IP vm.se.lsoft.com.58679 > bang.swox.se.smtp: R 678305701:678305701(0) win 0 > 19:46:05.940041 IP vm.se.lsoft.com.58679 > bang.swox.se.smtp: S 678305700:678305700(0) win 8192 > 19:46:05.940205 IP bang.swox.se.smtp > vm.se.lsoft.com.58679: S 2664894402:2664894402(0) ack 678305701 win 57344 > 19:46:05.977251 IP vm.se.lsoft.com.58679 > bang.swox.se.smtp: R 678305701:678305701(0) win 0 > I know I'm late getting to this thread, but I hadn't seen anyone point this out, so it may be of some help or just food for thought. According to the above trace, it basically looks like vm is broken either due to hardware, software or a combination of the both. I know nothing of mainframes or the behavior of their TCP/IP stacks so it was very easy to come to that knee-jerk conclusion. Then I started thinking (always a fruitless endeavor), why would a *BSD based firewall/"IP stack" drop the corresponding SYN-ACK when it was activated? And that thought just fucking bugged me to no end. I could accept some crazy IBM "IP stack" not dealing with *BSD, but this was *BSD box to *BSD box on the return path that dropped the packet. Also, according to the original poster bang.swox.se has no problems communicating with other systems and he has no problems communicating to vm.se.lsoft.com. > But smtp.swox.se is perfectly capable of > accepting TCP connections from lots of machines out there, and the > router leavs the SYNACKs alone except when vm is on the receiving end. > Making tcp connections in the other direction (smtp.swox.se -> vm) > works flawlessly. > Now, I know this may sound a little weird, but that train of thought (I use the term loosely) led me to this question. What if vm never sent the initial SYN? A forged source address perhaps from the internal network. That would make what is shown in the trace above move in clock-step. client (forged) -> SYN ISN host -> SYN ISN (ACK ISN recvd + 1) client (true) -> RST SN ** If the initial packet was forged then the RST from vm makes perfect sense. It would also explain why the Firewall would drop the SYN-ACK as the packet would not correspond to an initiating SYN that the Firewall could reference in it's state tables. *I have never used pf so this assumption may be incorrect. ** After looking through "Stevens TCP/IP Illustrated" I can find no reference to what sequence number a RST packet should have if a SYN-ACK precedes it. I'm unsure whether the RST should ACK the SYN + 1, as a SYN consumes a byte in normal operation, or return the ISN to the sending host. But as sending a RST in response to a SYN-ACK is not normal operation; such ambiguities would likely be left to the programmers discretion. In this case IBM not a stack derived from *BSD. Then, alas, after much trouble and tole; I noticed that the TCP/IP traces refer to different hosts. vm.se.lsoft.com ----> smtp.swox.se then vm.se.lsoft.com ----> bang.swox.se this now opens a whole new box of worms?!?!?