Date: Sat, 24 Mar 2007 07:40:50 -0400 From: Richard <rleippe@bellsouth.net> To: freebsd-questions@freebsd.org Subject: Re: TCP conection problems IBM VM -> FreeBSD Message-ID: <1174736450.52355.113.camel@darkstar> In-Reply-To: <86odmlhzn8.fsf@king.swox.se> References: <868xdqnnzd.fsf@king.swox.se> <E2D691F7-FF70-4D6E-95D7-357B5815C419@mac.com> <86odmlhzn8.fsf@king.swox.se>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <mss 1420,wscale 0,nop,nop,nop,timestamp 2317060084 0> > 19:45:56.940154 IP bang.swox.se.smtp > vm.se.lsoft.com.58679: S 3183232720:3183232720(0) ack 678305701 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 24588210 2317060084> > 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 <mss 1420,wscale 0,nop,nop,nop,timestamp 2317247594 0> > 19:45:59.939905 IP bang.swox.se.smtp > vm.se.lsoft.com.58679: S 1749284606:1749284606(0) ack 678305701 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 24588510 2317247594> > 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 <mss 1420,wscale 0,nop,nop,nop,timestamp 2317622600 0> > 19:46:05.940205 IP bang.swox.se.smtp > vm.se.lsoft.com.58679: S 2664894402:2664894402(0) ack 678305701 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 24589110 2317622600> > 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?!?!?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1174736450.52355.113.camel>