TCP conection problems IBM VM -> FreeBSD

[Richard]

> 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?!?!?