Wackamole failing after cable dis-/reconnect

Hallo,

I have a Spread/Wackamole setup which works at least testing-wise fine 
as long as I fail one machine of the two machine setup by completely 
rebooting it or by killing the Wackamole or Spread daemon.
I the above case(s) the other machine in that litte cluster takes over 
with a very short outage only.

The problem which I encounter is after disconnecting physically the 
network interface's cable on either machine and afterwards reconnecting 
that cable.
Step by step I do the following, assuming initially both machines are 
fine an listening:
1. disconnect NIC cable of machine A (which is 2.4.20 kernel, German 
SUSE 8.2 distro)
2. watch syslog on the other machine B (which is RH 7.1, kernel 
2.4.2-2), wait for Wackamole to complete the arp spoof
3. watch ping -t on a Windows box on the same network. After 
disconnection there is a brief outage of one-two seconds, then the other 
machine jumps in, and ping is receiving good responses again
3. reconnect NIC cable of machine A (where Spread daemon and Wackamole 
have continued running while the cable was off)
4. watch syslog of machine B, Wackamole brings the VIP down
5. watch syslog of machine A, there is no activity, apart from the 
notice that the cacle has been reconnected and a 100Mbit link has been 
established
6. watch ping -t on Windows box, ping receives destination host 
unreachable messages originating from the physical IP of machine B. 
Since machine B has taken down the VIP it was listening to when the 
cable on machine A was reconnected it should not be able to respond to 
ping going to the VIP, which is OK.
7. doing arp -a on the Windows box, I see that the arp cache for the VIP 
has not been updated. One explanation that occurs to me is, that the arp 
spoof and subsequent update of the shared arp cache seem to happen only 
when a VIP comes up, not when its ging down. So in my case, the VIP on 
machine B goes down, without notifying anyone of it. And the VIP on 
machine A, which has been up right through during the physical 
disconnect, does not sense any changes and therefore does not broadcast 
arp information as well.
8. If I purge the VIP from the Windows box arp cache, the ping comes 
right back with good responses.

Well, I hope no one got bored with the lengthy explanation.
I will post the important parts of my conf below.
The Wackamole conf is different from most others I have seen. I want 
(have to) use only one IP Address as VIP for both machines in my little 
cluster, since booth machines have to exposed by that IP address, not at 
the same time (I know this wouldn't work) but intermittendly depending 
on their health state or running condition. The network has no DNS 
available, therefore I have to go with the IP.

Spread (Conf is identical on both machines A and B)
Spread_Segment  192.168.1.255:4803 {
  "192"                   192.168.1.141
  ibm-linux               192.168.1.59
}

Wackamole (identical as well)
# The Spread daemon we are going to connect to.  It should be on the 
local box
Spread = 4803
SpreadRetryInterval = 2s
# The group name
Group = wack1
# Named socket for online control
Control = /var/run/wack.it

# Denote the interface we prefer to have
#prefer eth0:10.3.4.5/8
#prefer { eth0:10.2.3.4/8 eth1:192.168.10.23/24 }

# In most cases, I just don't care.  Let wackamole decide.
Prefer None

# List all the virtual interfaces (ALL of them)
VirtualInterfaces {
        # The following two lines have the same effect
        # en0:192.168.1.2/24
         { eth0:192.168.1.200/24 }

        # This is how you say 2 or more IPs are to be treated as a single
        # "set" or "virtual interface".  If wackamole decides that this
        # machine will manage it, you are ensured to get ALL the ips in the
        # set.
        # { en1:10.0.0.1/8 en0:192.168.35.64/26 }
}

# Collect and broadcast the IPs in our ARP table every so often
Arp-Cache = 1s

# List who we will notify
#       Here the netblock (/24 or /28) can be deceptive.  It is NOT a 
netmask
#       for a single IP.  It is how one will describe that they want to
#       notify ALL IPs in a segment.
Notify {
        # Let's notify our router:
        eth0:192.168.1.1/32
        # Notify out DNS servers
        # en1:10.0.0.10/32
        # en1:10.0.0.11/32
        # 10.0.0.0 -> 10.0.0.255, but only 128 notifications/sec
        # en0:10.0.0.0/24 throttle 128
        # Wackamole shares arp-cache across machines, this says to
        # notify every IP address in the aggregate shared arp-cache.
        arp-cache
}
balance {
        # This field is the maximum number of IP addresses that will move
        # from one wackamole to another during a round of balancing.
        AcquisitionsPerRound = 1
        # Time interval in each balancing round.
        interval = 1s
}
# How long it takes us to mature
mature = 3s


-----

If anyone has got some time:
Can that what I intend to do work at all?
Any hints how I could work aroud my problem?

If you haven't the time, thanks for reading anyway!


--
Mit freundlichen Gruessen / Kind Regards
Toralf Richter

triplesense GmbH
Hanauer Landstraße 186
60314 Frankfurt am Main