On Mon, May 03, 2010 at 02:42:00PM -0400, Sam Tran wrote: > Hi Lars, > > Here is the content of the single state file for the LDAPS TCP connection: > > [...@info-ldap-015 ~]# cat /tmp/tickle/192.168.8.171 > 192.168.8.171:636 192.168.240.178:32913 > > I tried to run the tickle_tcp manually: > > [...@info-ldap-015 ~]# cat /tmp/tickle/192.168.8.171 | > /usr/lib64/heartbeat/tickle_tcp -n 3 > > It did send three packets to the LDAP slave. But it didn't break the > existing TCP connection between the VIP and the slave.
It is not supposed to do that. By sending an invalid ACK, it is supposed to tickle the TCP stack of the client into sending a valid ack to the now failed over IP, which then is supposed to trigger a valid RST from the new server, because it does not know anything about that connection. As long as the endpoint is still there, the tcp session is supposed to be robust against such "attacks". The point of this "attack" is that the endpoint _changed_, and thus the tcp session is no longer valid, even though the client has not noticed that yet. The trick is to talk the client into sending _anything_ at all, so a suitable RST can be send to cause the client to notice, and reconnect. > I have attached > the output of the packet capture in text format. > > Thanks, > Sam > No. Time Source Destination Protocol Info > 1 0.000000 192.168.8.171 192.168.240.178 TCP > [TCP Window Update] ldaps > 32913 [ACK] Seq=1 Ack=1 Win=1234 Len=0 Right. So tickle acks are send out. All is well ;-) If some firewall in between filters out the tickle acks as invalid packets, well, the client is not tricked into sending anything, and thus needs to notice all by itself. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
