At Thu, 28 Apr 2011 21:33:08 -0700, Scott Howard wrote: ...
The "(63)" means the packet has 63 bytes of data in it. So if there's something strange happening here, it's that the server is sending a data packet before it gets the 3rd packet in the 3-way handshake. ... In this case, the data isn't in the SYN-ACK itself but in a packet following it. I'm not sure if that's legal or not, but I can't see why it wouldn't be.
It's legal. The third packet carries the client's ACK of the server's SYN, so the connection reaches state ESTABLISHED at that point. You don't see this pattern often because it's difficult to produce with the TCP APIs as they evolved on most operating systems, but that's an implementation artifact, not a protocol restriction. Since this is not a common pattern, it could easily be confusing the firewall that the original poster mentioned. Bug report time (reference page 68 of RFC 793), but in the meantime the original poster presumably needs a workaround.