On Mar 22, 2007, at 12:00 PM, Torbjorn Granlund wrote:
  The second line should have been smtp.swox.se.smtp SYN+ACK'ing the
  ISN of 27523124.  vm is sending a RST to that because the sequence
#'s don't match. It's also odd that the set of options being listed don't correspond at all...if you run the tcpdump for several minutes,
  can you track down other SYN requests which do correspond?

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>

Notice the ACK from vm.se.lsoft.com is off by one, but the timestamp option corresponds. Looks to be a bug with the vm machine, the bang machine is behaving properly per the TCP requirements.

Hmm, I wonder if something in between is fragmenting the initial traffic and causing vm to get confused? Try setting the interface MTUs down to 1024 or 512 and see whether that makes any difference...

  Sometimes this kind of re-writing can happen if natd or PF is
  attempting to translate the packets, perhaps when they shouldn't if
  both sides of your router box are using routable IPs....

I don't run natd at all, and to get the output above from tcpdump I
had disabled pf with pfctl -d.  With pf running, it silently drops the
2nd packet.  Could that too be related to ISN's?

Yes, pf tracks connection state and will drop subsequent traffic which does match an legit connection or a new (permitted) connection open attempt.

The outside of the fbsd 6.2 router has two addresses, one routable and
one not routable.  This is due to the default setup my ISP is
providing: Their is a little net between their router
and my fbsd 6.2 router.

OK. That shouldn't matter then, if you're just doing straight routing via this /30, rather than re-writing the packets.


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to