So I am seeing some interesting behavior of TCP during a MySQL connect over the network. The following packets capture shows the packet flow: asa1# sh capture debug-in 8 packets captured 1: 21:49:13.461554 8.25.42.100.32929 > 74.81.76.195.3306: S 4107544000:4107544000(0) win 65535 <mss 1380,nop,wscale 3,sackOK,timestamp 2065216038 0> 2: 21:49:13.462073 74.81.76.195.3306 > 8.25.42.100.32929: S 2601320299:2601320299(0) ack 4107544001 win 5792 <mss 1460,sackOK,timestamp 2581054349 2065216038,nop,wscale 7> 3: 21:49:13.462210 74.81.76.195.3306 > 8.25.42.100.32929: P 2601320300:2601320363(63) ack 4107544001 win 46 <nop,nop,timestamp 2581054349 2065216038> 4: 21:49:13.519061 8.25.42.100.32929 > 74.81.76.195.3306: . ack 2601320300 win 8208 <nop,nop,timestamp 2065216096 2581054349> 5: 21:49:14.135384 8.25.42.100.32929 > 74.81.76.195.3306: P 4107544001:4107544003(2) ack 2601320300 win 8208 <nop,nop,timestamp 2065216712 2581054349> 6: 21:49:14.135521 74.81.76.195.3306 > 8.25.42.100.32929: . ack 4107544003 win 46 <nop,nop,timestamp 2581055023 2065216712> 7: 21:49:16.461981 74.81.76.195.3306 > 8.25.42.100.32929: P 2601320300:2601320363(63) ack 4107544003 win 46 <nop,nop,timestamp 2581057349 2065216712> 8: 21:49:16.618147 8.25.42.100.32929 > 74.81.76.195.3306: . ack 2601320363 win 8208 <nop,nop,timestamp 2065219195 2581057349> 8 packets shown Packet "1" is Syn from MySQL client to Server Packet "2" is Syn/Ack from Server Packet "3" is a TCP Push! ??? HERE IS WHERE I AM CONFUSED Packet "4" is the Ack from the client completing the 3-way hand shake. My firewall is dropping packet "3" as it is not happy there is a push going on before it sees the completed handshake. Anybody run across this? Is the a MySQL option for a faster connection? Finally the firewall is a Cisco ASA and the "TCP Normalization" feature is dropping the packet. Specifically is the "tcp-3whs-failed" rule that is being offended. I cannot seem to figure out a way to turn this off? Thanks for the help. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward?
On Thu, Apr 28, 2011 at 11:40 PM, Joe Renwick <joe@gonetforward.com> wrote:
3: 21:49:13.462210 74.81.76.195.3306 > 8.25.42.100.32929: P 2601320300:2601320363(63) ack 4107544001 win 46 <nop,nop,timestamp 2581054349 2065216038>
Packet "1" is Syn from MySQL client to Server Packet "2" is Syn/Ack from Server Packet "3" is a TCP Push! ??? HERE IS WHERE I AM CONFUSED Packet "4" is the Ack from the client completing the 3-way hand shake.
My firewall is dropping packet "3" as it is not happy there is a push going on before it sees the completed handshake. Anybody run across this? Is the a MySQL option for a faster connection?
A) That push appears to be the first data packet containing MySQL's connection banner. B) This would be an OS TCP implementation issue. MySQL has a socket as of when the syn/ack is queued. It has no control over when the OS decides it can begin to transmit the data MySQL writes to that socket. I'm guessing the OS is trying to optimize TCP performance by skipping the syn-received state and going straight to established. I'm not sure whether or not the RFCs allow that.
Specifically is the "tcp-3whs-failed" rule that is being offended. I cannot seem to figure out a way to turn this off?
If you figure it out, I'd be interested to learn what you found. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Apr 28, 2011 at 8:40 PM, Joe Renwick <joe@gonetforward.com> wrote:
Packet "1" is Syn from MySQL client to Server Packet "2" is Syn/Ack from Server Packet "3" is a TCP Push! ??? HERE IS WHERE I AM CONFUSED
The "Push" is a red herring here. Push is an historic flag that is (almost) always ignored now days, but for historic reasons almost every TCP packet has it set. So packet 3 isn't really a "Push" packet, but it IS a data packet : 3: 21:49:13.462210 74.81.76.195.3306 > 8.25.42.100.32929: P 2601320300:2601320363(63) ack 4107544001 win 46 <nop,nop,timestamp 2581054349 2065216038> 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. Whilst that's definitely strange, it's probably legal. It's definitely legal to include data in the SYN-ACK packet itself (and even, I think, in the initial SYN packet!) although I've never seen anything that implements that. 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. My firewall is dropping packet "3" as it is not happy there is a push going
on before it sees the completed handshake.
Not at all surprising. Most firewalls will drop anything that's even slightly unexpected, and this would certainly fit into that category - even if it's legal. Scott.
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.
participants (4)
-
Joe Renwick -
Rob Austein -
Scott Howard -
William Herrin