On Thu, Jul 26, 2007 at 07:35:38AM +0200, Matthias Apitz wrote: > Hello Carson, > > Thanks for pointing that out; I did not realized the 'ack' flag and was > only focused on the 'S'; it is now clear why the pkg can not pass the > IPF firewall; > > but it remains a question; I collected all the traffic for the IP > 10.0.1.40 and this is what was captured: > > Why 10.0.1.40 sends out a SYN to the remote side having 'ack' turned on > and having set the destination port to n+1 of the source port of the > established connection? Do you have an idea about?
Where do you see that? Source port is 3232 in the first packet: > 13:30:07.989088 IP xxx.xxx.xxx.xxx.3232 > 10.0.1.40.1720: S > 356680283:356680283(0) win 8192 <mss 1460> And the destination is 3232 it the second packet: > 13:30:07.994005 IP 10.0.1.40.1720 > xxx.xxx.xxx.xxx.3232: S > 85446234:85446234(0) ack 356680284 win 23360 <mss 536> Those match. There's no "+1". As to your question about "ack", that's how TCP works - you respond a SYN with a SYN+ACK. That's the 2nd step of the 3-way handshake - syn, syn+ack, ack. Here's the ack: > 13:30:08.153383 IP xxx.xxx.xxx.xxx.3232 > 10.0.1.40.1720: . ack 1 win 8192 This is a normal TCP handshake. Though the fact that one side has an mss of 536 is very odd. However, it doesn't seem to be causing any problem (other than the inefficiency of such small packets). -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: Digital signature
