Mailing List Archive

Hi!
Try running wackamole in debug mode (-d). May be that will give
some hints of what is actually happening. I've tested on redhat 7.1 in the
past and it works perfectly there.

Aashima

On Thu, 1 Aug 2002, Geoff Campbell wrote:

> Curious one, this.
>
> Set up a pair of servers to run a pair of virtual IP addresses under Wackamole, on a Mandrake 8.1 distribution of Linux, pretty much the simplest Wackamole configuration possible. This all worked perfectly, and I ran a whole suite of tests to confirm it was doing what it should.
>
> Then, for reasons I won't bore you with, the servers had to be reinstalled with RedHat 7.3. Installation went fine, I blew all machines back to the stone-age and reinstalled from scratch, compiled and configured Spread and Wackamole as per the previous installation without problems. However, Wackamole is now sulking.
>
> The two boxes are www1 and www2, with real IP addresses 10.0.0.121 and 122 respectively, and two virtual IP addresses 10.0.0.141 and 142. When I bring www1 up, it comes up as expected with both virtual IP addresses. Bringing www2 up, it then grabs IP address 10.0.0.142, and looking at the ARP cache on a local machine shows the IP addresses on the correct ethernet adapters. However, the eth0:2 entry on www1 hasn't been dropped, as it used to under Mandrake.
>
> More seriously, if I kill www1, either by killing the wackamole process or by chopping the power to the machine, the wackamole process on www2 drops out, too, and all virtual IP addresses disappear.
>
> I'm getting no messages in any of the log files to give me any sort of clue.
>
> Has anyone else seen this, or does anyone have any ideas what might be going on?
>
> Regards,
>
> Geoff Campbell
> Internetworking Ltd.
> +44(0)1267-253747
>
>
>
> _______________________________________________
> wackamole-users mailing list
> wackamole-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users
>

> Hi!
> Try running wackamole in debug mode (-d). May be that will give
> some hints of what is actually happening. I've tested on redhat 7.1 in =
the
> past and it works perfectly there.

Ah, good idea, thanks for the pointer.

I'm not sure what it's trying to tell me, in fact. I've copied the two =
sessions below, minus a lot of repeats of the balance messages in the =
middle, anyone spot anything seriously wrong? Only thing I can see that =
doesn't make sense is that they are both claiming the same real address =
of 16777343, where does this come from? Could it be causing a clash?

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Wackamole_init
Get_conf: using file: /etc/wackamole.conf
vip 10.0.0.141
My real address is 16777343
of 10.0.0.141-142
while reading router ip address is 10.0.0.1
SP_connect: connected with private group(15 bytes): #wackamole#www1

Handle_membership

sending state
Shifting to GATHER

Dequeuing Balance

Handle state
handle state: got state from 16777343
handle state: Finished getting states, maturity is 0.
handle state: shifting back to BOOT

Turn_mature

Handle_mature

Priority_claim called
if_up: eth0:1 10.0.0.141 10.0.0.255 255.255.255.0
Aquire address 10.0.0.141

Claim_unclaimed called
if_up: eth0:2 10.0.0.142 10.0.0.255 255.255.255.0
Aquire address 10.0.0.142
Shifting to RUN in Handle_mature()

Balance called.

Balance called.

Handle_membership

sending state
Shifting to GATHER

Dequeuing Balance

Handle state
handle state: got state from 16777343

Handle state
handle state: got state from 16777343
handle state: Finished getting states, maturity is 1.

Priority_claim called

Claim_unclaimed called
handle state: shifting to RUN

Balance called.
Shifting to RUN in balance

Handle_balance
Finished Handle_balance.

Balance called.
Shifting to RUN in balance

Handle_balance
Finished Handle_balance.
Sig_handler called
SIGTERM Detected!
Clean_up called
if_up: eth0:1 10.0.0.141 10.0.0.255 255.255.255.0
Release address 10.0.0.141
if_up: eth0:2 10.0.0.142 10.0.0.255 255.255.255.0
Release address 10.0.0.142
Wackamole has quit all interfaces
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Wackamole_init
Get_conf: using file: /etc/wackamole.conf
vip 10.0.0.142
My real address is 16777343
of 10.0.0.141-142
while reading router ip address is 10.0.0.1
SP_connect: connected with private group(15 bytes): #wackamole#www2

Handle_membership

sending state
Shifting to GATHER

Dequeuing Balance

Handle state
handle state: got state from 16777343

Handle state

Handle_mature
handle state: got state from 16777343
handle state: Finished getting states, maturity is 1.

Priority_claim called
if_up: eth0:1 10.0.0.142 10.0.0.255 255.255.255.0
Aquire address 10.0.0.142

Claim_unclaimed called
handle state: shifting to RUN

Balance called.

Handle_balance
Finished Handle_balance.

Handle_membership

sending state
Shifting to GATHER

Dequeuing Balance

Handle state
Sig_handler called
SIGSEGV Detected!
Clean_up called
No such interface
Release address 10.0.0.141
if_up: eth0:1 10.0.0.142 10.0.0.255 255.255.255.0
Release address 10.0.0.142
Wackamole has quit all interfaces

> Handle state
> Sig_handler called
> SIGSEGV Detected!

Here is your problem... Wackamole segfaulted.

Can you recompile with debugging and get a core? (or debug it)

Are you running 1.2.0 or the CVS version?

> Clean_up called
> No such interface
> Release address 10.0.0.141
> if_up: eth0:1 10.0.0.142 10.0.0.255 255.255.255.0
> Release address 10.0.0.142
> Wackamole has quit all interfaces


--
Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone: +1 301 776 6376 Fax: +1 410 880 4879
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

> Here is your problem... Wackamole segfaulted.
>=20
> Can you recompile with debugging and get a core? (or debug it)

Do you mean Wackamole, or the kernel? Wackamole already has DEBUG set =
to 1 in alarm.h.

> Are you running 1.2.0 or the CVS version?

v1.2.0 - do you think the CVS version might work better?

Thanks for your help!

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747

Geoff Campbell wrote:

>>Here is your problem... Wackamole segfaulted.
>>
>>Can you recompile with debugging and get a core? (or debug it)
>>
>>
>
>Do you mean Wackamole, or the kernel? Wackamole already has DEBUG set to 1 in alarm.h.
>
wackamoe... you answered it ;-) I was referring to debugging it with GDB.

recompile wackamole with -g in the CFLAGS. and run (as root) gdb
wackamole. on both machines. repeat your error.
One should say "prgram exited normally" and the other should be stuck in
a stack trace. The one stuck in a stack trace is the one you want. If
you aren't familiar with debugging C code, then you want to still
recompile with -g, but don't run them under gdb... Just run the like normal.

When the one machine segfaults, it should leave a core, email me the
program "wackamole" and the "core".

>
>
>>Are you running 1.2.0 or the CVS version?
>>
>>
>
>v1.2.0 - do you think the CVS version might work better?
>
>
I am not sure what could segfault in 1.2.0 and it disturbs me... The CVS
version embraces 99% of the 1.2.0 code as its base. And the CVS version
is also trickier to debug as it is multithreaded.

--
Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone: +1 301 776 6376 Fax: +1 410 880 4879
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

> wackamoe... you answered it ;-) I was referring to debugging it with =
GDB.
>=20
> recompile wackamole with -g in the CFLAGS. and run (as root) gdb=20
> wackamole. on both machines. repeat your error.

Ah, gotcha.

Except it doesn't want to play. When I try and run wackamole under gdb, =
it displays the opening screen, and then says "Program exited with code =
01". I've set the arguments to "-c /etc/wackamole.conf", and I've tried =
playing with the fork options under gdb, to no avail. Running the same =
command ("wackamole -c /etc/wackamole.conf") outside of gdb works fine.

I can attach to a running copy of Wackamole by giving gdb the process ID =
of an already running copy, and it attaches and loads the symbols from =
various libraries, eventually reporting:

0x420e187e in select () from /lib/i686/libc.so.6

Any ideas?

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747

Geoff Campbell wrote:

>>wackamoe... you answered it ;-) I was referring to debugging it with GDB.
>>
>>recompile wackamole with -g in the CFLAGS. and run (as root) gdb
>>wackamole. on both machines. repeat your error.
>>
>>
>
>Ah, gotcha.
>
>Except it doesn't want to play. When I try and run wackamole under gdb, it displays the opening screen, and then says "Program exited with code 01". I've set the arguments to "-c /etc/wackamole.conf", and I've tried playing with the fork options under gdb, to no avail. Running the same command ("wackamole -c /etc/wackamole.conf") outside of gdb works fine.
>
>I can attach to a running copy of Wackamole by giving gdb the process ID of an already running copy, and it attaches and loads the symbols from various libraries, eventually reporting:
>
>0x420e187e in select () from /lib/i686/libc.so.6
>
That isn't uplifting.... From there you can type 'bt full' to get a
full backtrace. That would help a bit.

>Any ideas?
>
>
Run it with -d or -D (don't remember which)... It will run it is
debugging more and not daemonize.

--
Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone: +1 301 776 6376 Fax: +1 410 880 4879
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

> Run it with -d or -D (don't remember which)... It will run it is=20
> debugging more and not daemonize.

Oh, of course - sorry, been a long day.

OK, below is the result of the "bt full" after the SIGSEGV:

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747


Handle_membership

sending state
Shifting to GATHER

Dequeuing Balance

Handle state

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 6222)]
0x0804af09 in Handle_state () at wackamole.c:617
617 for ( j =3D 0; j < Num_pseudo; j++)
(gdb) bt full
#0 0x0804af09 in Handle_state () at wackamole.c:617
num_bytes =3D 40
curr_num_prefer_ptr =3D (int *) 0x805ae84
i =3D 96350
j =3D 0
k =3D 134522199
#1 0x0804e3ba in E_handle_events ()
No symbol table info available.
#2 0x0804a508 in main (argc=3D4, argv=3D0xbffffb34) at wackamole.c:304
argc =3D 4
argv =3D (char **) 0x0
ret =3D 0
fd =3D 4
signalaction =3D {__sigaction_handler =3D {
sa_handler =3D 0x804c5dc <Sig_handler>,
sa_sigaction =3D 0x804c5dc <Sig_handler>}, sa_mask =3D {__val =3D {
0 <repeats 32 times>}}, sa_flags =3D 0,
sa_restorer =3D 0x4202bd50 <__cxa_atexit>}
#3 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
No symbol table info available.
(gdb)

> OK, below is the result of the "bt full" after the SIGSEGV:

Further investigation seems to give an invalid pointer in =
*curr_prefer_address, which points to 0x80b9000, which is out of bounds, =
FWIW.

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747

Okay... that logic isn't used in CVS and there is a little more robust
bounds checking in place after receives. So, upgrade to the CVS
version. It is much more feature-full anyway ;-)


On Friday, August 2, 2002, at 02:08 , Geoff Campbell wrote:

>> OK, below is the result of the "bt full" after the SIGSEGV:
>
> Further investigation seems to give an invalid pointer in
> *curr_prefer_address, which points to 0x80b9000, which is out of
> bounds, FWIW.
>
> Regards,
>
> Geoff Campbell
> Internetworking Ltd.
> +44(0)1267-253747
>
>
>
> _______________________________________________
> wackamole-users mailing list
> wackamole-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users
>
>
--
Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone: +1 301 776 6376 Fax: +1 410 880 4879
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

> Okay... that logic isn't used in CVS and there is a little more robust =

> bounds checking in place after receives. So, upgrade to the CVS=20
> version. It is much more feature-full anyway ;-)

Good news, thanks - will upgrade shortly, and let you know.

Thanks for your help!

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747

> Good news, thanks - will upgrade shortly, and let you know.

Well, two steps forward, and two backwards, really. Got the CVS version =
compiled and running with little pain, but the two nodes don't seem to =
be seeing one another. Spread is running OK, but when I start Wackamole =
on either node, it grabs both IP addresses even if it is already running =
on the other node.

Running in debug mode doesn't show up anything obvious. Could be I'm =
not understanding the new config file properly. I've attached the =
config file I'm using below, anyone see anything wrong with it? The =
only changes I make for the two machines are the Spread=3D line and the =
Prefer line, otherwise they are the same on the two nodes.

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747
=20
# The Spread daemon we are going to connect to. It should be on the =
local box
Spread =3D 4803@www1
SpreadRetryInterval =3D 5
# The group name
Group =3D www
# Named socket for online control
Control =3D /var/tmp/wack.it
# Denote the interface we prefer to have
prefer eth0:10.0.0.141/24
# List all the virtual interfaces (ALL of them)
VirtualInterfaces {
eth0:10.0.0.141/24
eth0:10.0.0.142/24
}
# Collect and broadcast the IPs in our ARP table every so often
Arp-Cache =3D 90s
Notify {
eth0:10.0.0.1/32
eth0:10.0.0.0/24 throttle 128
arp-cache
}
balance {
AcquisitionsPerRound =3D all
interval =3D 4s
}
mature =3D 5s

On Mon, Aug 05, 2002 at 08:28:57AM +0100, Geoff Campbell wrote:
> # The Spread daemon we are going to connect to. It should be on the local box
> Spread = 4803@www1

It's been recommended to drop the @www1 and just use 4803, for reasons of
using domain sockets instead.

> SpreadRetryInterval = 5
> # The group name
> Group = www
> # Named socket for online control
> Control = /var/tmp/wack.it
> # Denote the interface we prefer to have
> prefer eth0:10.0.0.141/24

You can comment out the prefer statement, unless you really want the machine
to have this IP. Otherwise, wackamole will handle the IP negotiation.

> # List all the virtual interfaces (ALL of them)
> VirtualInterfaces {
> eth0:10.0.0.141/24
> eth0:10.0.0.142/24

Any IP address that is added on an interface is usually going to be an alias
with a netmask of 255.255.255.255 (at least on freebsd) so it would be
recommended to use a /32 netmask vs. the /24 you have listed.

> }
> # Collect and broadcast the IPs in our ARP table every so often
> Arp-Cache = 90s
> Notify {
> eth0:10.0.0.1/32
> eth0:10.0.0.0/24 throttle 128
> arp-cache

These look fine if 10.0.0.1 is your router/gateway and 10.0.0.0/24 is your
only network of machines that go through 10.0.0.1 or would want to reach
your 10.0.0.{141,142}

Cheers,

-.mag
> }
> balance {
> AcquisitionsPerRound = all
> interval = 4s
> }
> mature = 5s

Mark,

Thanks for your pointers, I will have a play this evening and let you =
know how I get on.

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747
=20

> -----Original Message-----
> From: wackamole-users-admin@lists.backhand.org
> [mailto:wackamole-users-admin@lists.backhand.org]On Behalf Of Mark A.
> Garcia
> Sent: 05 August 2002 20:03
> To: wackamole-users@lists.backhand.org
> Subject: Re: [Wackamole-users] Wackamole dropping out
>=20
>=20
> On Mon, Aug 05, 2002 at 08:28:57AM +0100, Geoff Campbell wrote:
> > # The Spread daemon we are going to connect to. It should be=20
> on the local box
> > Spread =3D 4803@www1
>=20
> It's been recommended to drop the @www1 and just use 4803, for reasons =
of
> using domain sockets instead.
>=20
> > SpreadRetryInterval =3D 5
> > # The group name
> > Group =3D www
> > # Named socket for online control
> > Control =3D /var/tmp/wack.it
> > # Denote the interface we prefer to have
> > prefer eth0:10.0.0.141/24
>=20
> You can comment out the prefer statement, unless you really want=20
> the machine
> to have this IP. Otherwise, wackamole will handle the IP negotiation.
>=20
> > # List all the virtual interfaces (ALL of them)
> > VirtualInterfaces {
> > eth0:10.0.0.141/24
> > eth0:10.0.0.142/24
>=20
> Any IP address that is added on an interface is usually going to=20
> be an alias
> with a netmask of 255.255.255.255 (at least on freebsd) so it would be
> recommended to use a /32 netmask vs. the /24 you have listed.
>=20
> > }
> > # Collect and broadcast the IPs in our ARP table every so often
> > Arp-Cache =3D 90s
> > Notify {
> > eth0:10.0.0.1/32
> > eth0:10.0.0.0/24 throttle 128
> > arp-cache
>=20
> These look fine if 10.0.0.1 is your router/gateway and 10.0.0.0/24 is =
your
> only network of machines that go through 10.0.0.1 or would want to =
reach
> your 10.0.0.{141,142}
>=20
> Cheers,
>=20
> -.mag
> > }
> > balance {
> > AcquisitionsPerRound =3D all
> > interval =3D 4s
> > }
> > mature =3D 5s
>=20
> _______________________________________________
> wackamole-users mailing list
> wackamole-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users
>=20

> Thanks for your pointers, I will have a play this evening and let=20
> you know how I get on.

Well, I implemented the changes to the wackamole.conf file, but I still =
can't get it running. =20

The first machine to come up sets up both virtual IP addresses as =
expected. The second one then either doesn't grab an IP address, or =
grabs one briefly then hands it back to the first machine. Killing the =
wackamole process on the first machine then makes the second one drop =
out - I've run it under gdb, the output is attached below.

Both machines are running RedHat 7.3, with the v2.4.18-3 kernel, btw. =
Is anyone successfully running wackamole on this release? Can someone =
with the current CVS release running successfully post their =
wackamole.conf so I can compare it to mine, please?

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747
=20

[root@www2 etc]# gdb wackamole
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you =
are
welcome to change it and/or distribute copies of it under certain =
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for =
details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
(gdb) set args -d
(gdb) run
Starting program: /usr/local/bin/wackamole -d
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 1024 (LWP 18168)]
(no debugging symbols found)...
/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D\
| The Wackamole Program. =
|
| Copyright (c) 2000-2001 The Johns Hopkins University =
|
| All rights reserved. =
|
| =
|
| Wackamole is developed at the Center for Networking and Distributed =
Systems, |
| The Johns Hopkins University. =
|
| =
|
| The Wackamole package is licensed under the CNDS Open Source License =
|
| You may only use this software in compliance with the License. =
|
| A copy of the license can be found at =
|
| http://www.backhand.org/wackamole/license =
|
| =
|
| This product uses the Spread toolkit, developed by Spread Concepts =
LLC. |
| For more information about Spread see http://www.spread.org =
|
| =
|
| This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF =
|
| ANY KIND, either express or implied. =
|
| =
|
| Creators: =
|
| Yair Amir yairamir@cnds.jhu.edu =
|
| Ryan Caudy wyvern@cnds.jhu.edu =
|
| Aashima Munjal munjal@jhu.edu =
|
| Theo Schlossnagle jesus@cnds.jhu.edu =
|
| =
|
| For a full list of contributors, see Readme.txt in the distribution. =
|
| =
|
| WWW: www.backhand.org www.cnds.jhu.edu =
|
| Contact: wackamole@backhand.org =
|
| =
|
| Version 1.3.0 Released 2002-Jan-20 =
|
| =
|
\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D/
connecting to 4803
Clean_up called
No such interface
No such interface
SP_connect: connected with private group(15 bytes): #wack18168#www2
Sending 0 local arp entries
Sending 0 local arp entries
wackamole: wackamole.c:668: Send_state_message: Assertion `ret =3D=3D =
My.num_allocated' failed.
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGABRT, Aborted.
[Switching to Thread 1024 (LWP 18168)]
0x42029241 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0 0x42029241 in kill () from /lib/i686/libc.so.6
#1 0x40048c4b in raise () from /lib/i686/libpthread.so.0
#2 0x4202a7d2 in abort () from /lib/i686/libc.so.6
#3 0x42022ddb in __assert_fail () from /lib/i686/libc.so.6
#4 0x0804bed9 in main ()
#5 0x0804b7fe in main ()
#6 0x0804b2db in main ()
#7 0x08051572 in E_handle_events ()
#8 0x0804b24f in main ()
#9 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)

Geoff Campbell wrote:
>>Thanks for your pointers, I will have a play this evening and let
>>you know how I get on.
>
>
> Well, I implemented the changes to the wackamole.conf file, but I still can't get it running.
>
> The first machine to come up sets up both virtual IP addresses as expected. The second one then either doesn't grab an IP address, or grabs one briefly then hands it back to the first machine. Killing the wackamole process on the first machine then makes the second one drop out - I've run it under gdb, the output is attached below.
>
> Both machines are running RedHat 7.3, with the v2.4.18-3 kernel, btw. Is anyone successfully running wackamole on this release? Can someone with the current CVS release running successfully post their wackamole.conf so I can compare it to mine, please?
>
> Regards,
>
> Geoff Campbell
> Internetworking Ltd.
> +44(0)1267-253747

Hi,

I'm a little out of touch with the latest wackamole releases, but I've
been trying to think about what could be causing your problems. Could
you send an email with your latest wackamole.conf, spread.conf, and
output from ifconfig for each machine?

Cheers,
Ryan Caudy

> I'm a little out of touch with the latest wackamole releases, but I've =

> been trying to think about what could be causing your problems. Could =

> you send an email with your latest wackamole.conf, spread.conf, and=20
> output from ifconfig for each machine?

Certainly - see below. All three are identical for both machines, I did =
try changing the wackamole.conf Spread=3D line to explicitly reference =
the machine's IP addresses, and also to 4803@127.0.0.1, but neither made =
any difference.

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747


[root@www1 etc]# cat wackamole.conf
# The Spread daemon we are going to connect to. It should be on the =
local box
Spread =3D 4803
SpreadRetryInterval =3D 5
# The group name
Group =3D wack1
# Named socket for online control
Control =3D /var/tmp/wack.it
# In most cases, I just don't care. Let wackamole decide.
#Prefer None
# List all the virtual interfaces (ALL of them)
VirtualInterfaces {
{ eth0:10.0.0.141/32 }
{ eth0:10.0.0.142/32 }
}
Arp-Cache =3D 90s
Notify {
eth0:10.0.0.1/32
eth0:10.0.0.0/24 throttle 128
arp-cache
}
balance {
AcquisitionsPerRound =3D all
interval =3D 4s
}
mature =3D 5s



[root@www1 etc]# cat spread.conf
Spread_Segment 10.0.0.255:4803 {

www1 10.0.0.121
www2 10.0.0.122
}
# Spread options
#------------------------------------------------------------------------=
---
#------------------------------------------------------------------------=
---
#DebugFlags =3D { PRINT EXIT }
EventLogFile =3D /var/log/spread.log
#EventTimeStamp =3D "[%a %d %b %Y %H:%M:%S]"
#DangerousMonitor =3D false
#RequiredAuthMethods =3D " "
#AllowedAuthMethods =3D "NULL"
#AccessControlPolicy =3D "PERMIT"



[root@www1 etc]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:E0:18:66:E2:10
inet addr:10.0.0.121 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3015333 errors:0 dropped:0 overruns:0 frame:0
TX packets:1077030 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:148087988 (141.2 Mb) TX bytes:84160285 (80.2 Mb)
Interrupt:11 Base address:0x7000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:533 errors:0 dropped:0 overruns:0 frame:0
TX packets:533 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:43990 (42.9 Kb) TX bytes:43990 (42.9 Kb)



[root@www2 etc]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:E0:18:6D:FE:11
inet addr:10.0.0.122 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:525142 errors:0 dropped:0 overruns:0 frame:0
TX packets:254245 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:726891149 (693.2 Mb) TX bytes:22840495 (21.7 Mb)
Interrupt:11 Base address:0x7000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:292 errors:0 dropped:0 overruns:0 frame:0
TX packets:292 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:19952 (19.4 Kb) TX bytes:19952 (19.4 Kb)

Does anyone have any ideas on this at all?

I've been having a poke around the code today, but I can't see anything =
wrong. Seems to me that the first machine to come up allocates both IP =
addresses correctly, then when Wackamole is started on the second =
machine it grabs an IP address, which is correctly dropped from the =
first machine, but then it's immediately dropped on the second machine, =
too. I can't work out what is triggering the event that causes this =
spurious dropping of the IP address.

Finally, when Wackamole is stopped on the first machine, the second one =
drops out with the message "wackamole: wackamole.c:668: =
Send_state_message: Assertion 'ret =3D=3D My.num_allocated' failed."

Running the CVS Wackamole (v1.3.0 from January) on RedHat 7.3 on two =
identical Intel boxes, with kernel v2.4.18-3. Is anyone else out there =
successfully running Wackamole on this sort of setup? I have happily =
run the release v1.2.0 Wackamole on these machines on Mandrake v8.1 with =
a v2.4.8-26 kernel, unfortunately this setup doesn't work with the =
software we're trying to implement on it.

I'm happy to look at any wild guesses anyone has now, as I'm drawing a =
complete blank on this one.

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747
=20

> -----Original Message-----
> From: wackamole-users-admin@lists.backhand.org
> [mailto:wackamole-users-admin@lists.backhand.org]On Behalf Of Geoff
> Campbell
> Sent: 07 August 2002 07:53
> To: wackamole-users@lists.backhand.org
> Subject: RE: [Wackamole-users] Wackamole dropping out
>=20
>=20
> > I'm a little out of touch with the latest wackamole releases, but =
I've=20
> > been trying to think about what could be causing your problems. =
Could=20
> > you send an email with your latest wackamole.conf, spread.conf, and=20
> > output from ifconfig for each machine?
>=20
> Certainly - see below. All three are identical for both=20
> machines, I did try changing the wackamole.conf Spread=3D line to=20
> explicitly reference the machine's IP addresses, and also to=20
> 4803@127.0.0.1, but neither made any difference.
>=20
> Regards,
>=20
> Geoff Campbell
> Internetworking Ltd.
> +44(0)1267-253747
>=20
>=20
> [root@www1 etc]# cat wackamole.conf
> # The Spread daemon we are going to connect to. It should be on=20
> the local box
> Spread =3D 4803
> SpreadRetryInterval =3D 5
> # The group name
> Group =3D wack1
> # Named socket for online control
> Control =3D /var/tmp/wack.it
> # In most cases, I just don't care. Let wackamole decide.
> #Prefer None
> # List all the virtual interfaces (ALL of them)
> VirtualInterfaces {
> { eth0:10.0.0.141/32 }
> { eth0:10.0.0.142/32 }
> }
> Arp-Cache =3D 90s
> Notify {
> eth0:10.0.0.1/32
> eth0:10.0.0.0/24 throttle 128
> arp-cache
> }
> balance {
> AcquisitionsPerRound =3D all
> interval =3D 4s
> }
> mature =3D 5s
>=20
>=20
>=20
> [root@www1 etc]# cat spread.conf
> Spread_Segment 10.0.0.255:4803 {
>=20
> www1 10.0.0.121
> www2 10.0.0.122
> }
> # Spread options
> #-----------------------------------------------------------------
> ----------
> #-----------------------------------------------------------------
> ----------
> #DebugFlags =3D { PRINT EXIT }
> EventLogFile =3D /var/log/spread.log
> #EventTimeStamp =3D "[%a %d %b %Y %H:%M:%S]"
> #DangerousMonitor =3D false
> #RequiredAuthMethods =3D " "
> #AllowedAuthMethods =3D "NULL"
> #AccessControlPolicy =3D "PERMIT"
>=20
>=20
>=20
> [root@www1 etc]# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:E0:18:66:E2:10
> inet addr:10.0.0.121 Bcast:10.0.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:3015333 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1077030 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:148087988 (141.2 Mb) TX bytes:84160285 (80.2 Mb)
> Interrupt:11 Base address:0x7000
>=20
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:533 errors:0 dropped:0 overruns:0 frame:0
> TX packets:533 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:43990 (42.9 Kb) TX bytes:43990 (42.9 Kb)
>=20
>=20
>=20
> [root@www2 etc]# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:E0:18:6D:FE:11
> inet addr:10.0.0.122 Bcast:10.0.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:525142 errors:0 dropped:0 overruns:0 frame:0
> TX packets:254245 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:726891149 (693.2 Mb) TX bytes:22840495 (21.7 Mb)
> Interrupt:11 Base address:0x7000
>=20
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:292 errors:0 dropped:0 overruns:0 frame:0
> TX packets:292 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:19952 (19.4 Kb) TX bytes:19952 (19.4 Kb)
>=20
>=20
>=20
> _______________________________________________
> wackamole-users mailing list
> wackamole-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users
>=20

I just encountered a weird bug/feature in linux that may be affecting
you. It seems that if you drop the _first listed_ virtual interface on
a given subnet, linux will drop all of your other routes on that network
as well.

In freebsd the docs specifically require virt. interfaces to be added as
/32s. I haven't tried that solution on Linux yet, as I've moved with
other work aorunds (using a fixed place holder adress in that address
sapce for that network).

Geoff Campbell wrote:

>Does anyone have any ideas on this at all?
>
>I've been having a poke around the code today, but I can't see anything wrong. Seems to me that the first machine to come up allocates both IP addresses correctly, then when Wackamole is started on the second machine it grabs an IP address, which is correctly dropped from the first machine, but then it's immediately dropped on the second machine, too. I can't work out what is triggering the event that causes this spurious dropping of the IP address.
>
>Finally, when Wackamole is stopped on the first machine, the second one drops out with the message "wackamole: wackamole.c:668: Send_state_message: Assertion 'ret == My.num_allocated' failed."
>
>Running the CVS Wackamole (v1.3.0 from January) on RedHat 7.3 on two identical Intel boxes, with kernel v2.4.18-3. Is anyone else out there successfully running Wackamole on this sort of setup? I have happily run the release v1.2.0 Wackamole on these machines on Mandrake v8.1 with a v2.4.8-26 kernel, unfortunately this setup doesn't work with the software we're trying to implement on it.
>
>I'm happy to look at any wild guesses anyone has now, as I'm drawing a complete blank on this one.
>
>Regards,
>
>Geoff Campbell
>Internetworking Ltd.
>+44(0)1267-253747
>
>
>>-----Original Message-----
>>From: wackamole-users-admin@lists.backhand.org
>>[mailto:wackamole-users-admin@lists.backhand.org]On Behalf Of Geoff
>>Campbell
>>Sent: 07 August 2002 07:53
>>To: wackamole-users@lists.backhand.org
>>Subject: RE: [Wackamole-users] Wackamole dropping out
>>
>>
>>>I'm a little out of touch with the latest wackamole releases, but I've
>>>been trying to think about what could be causing your problems. Could
>>>you send an email with your latest wackamole.conf, spread.conf, and
>>>output from ifconfig for each machine?
>>>
>>Certainly - see below. All three are identical for both
>>machines, I did try changing the wackamole.conf Spread= line to
>>explicitly reference the machine's IP addresses, and also to
>>4803@127.0.0.1, but neither made any difference.
>>
>>Regards,
>>
>>Geoff Campbell
>>Internetworking Ltd.
>>+44(0)1267-253747
>>
>>
>>[root@www1 etc]# cat wackamole.conf
>># The Spread daemon we are going to connect to. It should be on
>>the local box
>>Spread = 4803
>>SpreadRetryInterval = 5
>># The group name
>>Group = wack1
>># Named socket for online control
>>Control = /var/tmp/wack.it
>># In most cases, I just don't care. Let wackamole decide.
>>#Prefer None
>># List all the virtual interfaces (ALL of them)
>>VirtualInterfaces {
>> { eth0:10.0.0.141/32 }
>> { eth0:10.0.0.142/32 }
>>}
>>Arp-Cache = 90s
>>Notify {
>> eth0:10.0.0.1/32
>> eth0:10.0.0.0/24 throttle 128
>> arp-cache
>>}
>>balance {
>> AcquisitionsPerRound = all
>> interval = 4s
>>}
>>mature = 5s
>>
>>
>>
>>[root@www1 etc]# cat spread.conf
>>Spread_Segment 10.0.0.255:4803 {
>>
>> www1 10.0.0.121
>> www2 10.0.0.122
>>}
>># Spread options
>>#-----------------------------------------------------------------
>>----------
>>#-----------------------------------------------------------------
>>----------
>>#DebugFlags = { PRINT EXIT }
>>EventLogFile = /var/log/spread.log
>>#EventTimeStamp = "[%a %d %b %Y %H:%M:%S]"
>>#DangerousMonitor = false
>>#RequiredAuthMethods = " "
>>#AllowedAuthMethods = "NULL"
>>#AccessControlPolicy = "PERMIT"
>>
>>
>>
>>[root@www1 etc]# ifconfig
>>eth0 Link encap:Ethernet HWaddr 00:E0:18:66:E2:10
>> inet addr:10.0.0.121 Bcast:10.0.0.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:3015333 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:1077030 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:100
>> RX bytes:148087988 (141.2 Mb) TX bytes:84160285 (80.2 Mb)
>> Interrupt:11 Base address:0x7000
>>
>>lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>> RX packets:533 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:533 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:43990 (42.9 Kb) TX bytes:43990 (42.9 Kb)
>>
>>
>>
>>[root@www2 etc]# ifconfig
>>eth0 Link encap:Ethernet HWaddr 00:E0:18:6D:FE:11
>> inet addr:10.0.0.122 Bcast:10.0.0.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:525142 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:254245 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:100
>> RX bytes:726891149 (693.2 Mb) TX bytes:22840495 (21.7 Mb)
>> Interrupt:11 Base address:0x7000
>>
>>lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>> RX packets:292 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:292 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:19952 (19.4 Kb) TX bytes:19952 (19.4 Kb)
>>
>>
>>
>>_______________________________________________
>>wackamole-users mailing list
>>wackamole-users@lists.backhand.org
>>http://lists.backhand.org/mailman/listinfo/wackamole-users
>>
>
>
>_______________________________________________
>wackamole-users mailing list
>wackamole-users@lists.backhand.org
>http://lists.backhand.org/mailman/listinfo/wackamole-users
>

On Thu, Aug 15, 2002 at 03:50:38PM +0100, Geoff Campbell wrote:
> Does anyone have any ideas on this at all?
>
> I've been having a poke around the code today, but I can't see anything wrong. Seems to me that the first machine to come up allocates both IP addresses correctly, then when Wackamole is started on the second machine it grabs an IP address, which is correctly dropped from the first machine, but then it's immediately dropped on the second machine, too. I can't work out what is triggering the event that causes this spurious dropping of the IP address.
>
> Finally, when Wackamole is stopped on the first machine, the second one drops out with the message "wackamole: wackamole.c:668: Send_state_message: Assertion 'ret == My.num_allocated' failed."
>
> Running the CVS Wackamole (v1.3.0 from January) on RedHat 7.3 on two identical Intel boxes, with kernel v2.4.18-3. Is anyone else out there successfully running Wackamole on this sort of setup? I have happily run the release v1.2.0 Wackamole on these machines on Mandrake v8.1 with a v2.4.8-26 kernel, unfortunately this setup doesn't work with the software we're trying to implement on it.

Geoff, I am following this thread, especially with Theo referencing to
download the latest CVS version. But I see you mentioned the latest cvs
from January. Have you tried the latest cvs version from July
'200207111620.tar.gz' ?

-.mag

>
> I'm happy to look at any wild guesses anyone has now, as I'm drawing a complete blank on this one.
>
> Regards,
>
> Geoff Campbell
> Internetworking Ltd.
> +44(0)1267-253747
>
>
> > -----Original Message-----
> > From: wackamole-users-admin@lists.backhand.org
> > [mailto:wackamole-users-admin@lists.backhand.org]On Behalf Of Geoff
> > Campbell
> > Sent: 07 August 2002 07:53
> > To: wackamole-users@lists.backhand.org
> > Subject: RE: [Wackamole-users] Wackamole dropping out
> >
> >
> > > I'm a little out of touch with the latest wackamole releases, but I've
> > > been trying to think about what could be causing your problems. Could
> > > you send an email with your latest wackamole.conf, spread.conf, and
> > > output from ifconfig for each machine?
> >
> > Certainly - see below. All three are identical for both
> > machines, I did try changing the wackamole.conf Spread= line to
> > explicitly reference the machine's IP addresses, and also to
> > 4803@127.0.0.1, but neither made any difference.
> >
> > Regards,
> >
> > Geoff Campbell
> > Internetworking Ltd.
> > +44(0)1267-253747
> >
> >
> > [root@www1 etc]# cat wackamole.conf
> > # The Spread daemon we are going to connect to. It should be on
> > the local box
> > Spread = 4803
> > SpreadRetryInterval = 5
> > # The group name
> > Group = wack1
> > # Named socket for online control
> > Control = /var/tmp/wack.it
> > # In most cases, I just don't care. Let wackamole decide.
> > #Prefer None
> > # List all the virtual interfaces (ALL of them)
> > VirtualInterfaces {
> > { eth0:10.0.0.141/32 }
> > { eth0:10.0.0.142/32 }
> > }
> > Arp-Cache = 90s
> > Notify {
> > eth0:10.0.0.1/32
> > eth0:10.0.0.0/24 throttle 128
> > arp-cache
> > }
> > balance {
> > AcquisitionsPerRound = all
> > interval = 4s
> > }
> > mature = 5s
> >
> >
> >
> > [root@www1 etc]# cat spread.conf
> > Spread_Segment 10.0.0.255:4803 {
> >
> > www1 10.0.0.121
> > www2 10.0.0.122
> > }
> > # Spread options
> > #-----------------------------------------------------------------
> > ----------
> > #-----------------------------------------------------------------
> > ----------
> > #DebugFlags = { PRINT EXIT }
> > EventLogFile = /var/log/spread.log
> > #EventTimeStamp = "[%a %d %b %Y %H:%M:%S]"
> > #DangerousMonitor = false
> > #RequiredAuthMethods = " "
> > #AllowedAuthMethods = "NULL"
> > #AccessControlPolicy = "PERMIT"
> >
> >
> >
> > [root@www1 etc]# ifconfig
> > eth0 Link encap:Ethernet HWaddr 00:E0:18:66:E2:10
> > inet addr:10.0.0.121 Bcast:10.0.0.255 Mask:255.255.255.0
> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > RX packets:3015333 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:1077030 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:100
> > RX bytes:148087988 (141.2 Mb) TX bytes:84160285 (80.2 Mb)
> > Interrupt:11 Base address:0x7000
> >
> > lo Link encap:Local Loopback
> > inet addr:127.0.0.1 Mask:255.0.0.0
> > UP LOOPBACK RUNNING MTU:16436 Metric:1
> > RX packets:533 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:533 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:0
> > RX bytes:43990 (42.9 Kb) TX bytes:43990 (42.9 Kb)
> >
> >
> >
> > [root@www2 etc]# ifconfig
> > eth0 Link encap:Ethernet HWaddr 00:E0:18:6D:FE:11
> > inet addr:10.0.0.122 Bcast:10.0.0.255 Mask:255.255.255.0
> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > RX packets:525142 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:254245 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:100
> > RX bytes:726891149 (693.2 Mb) TX bytes:22840495 (21.7 Mb)
> > Interrupt:11 Base address:0x7000
> >
> > lo Link encap:Local Loopback
> > inet addr:127.0.0.1 Mask:255.0.0.0
> > UP LOOPBACK RUNNING MTU:16436 Metric:1
> > RX packets:292 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:292 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:0
> > RX bytes:19952 (19.4 Kb) TX bytes:19952 (19.4 Kb)
> >
> >
> >
> > _______________________________________________
> > wackamole-users mailing list
> > wackamole-users@lists.backhand.org
> > http://lists.backhand.org/mailman/listinfo/wackamole-users
> >
>
>
> _______________________________________________
> wackamole-users mailing list
> wackamole-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users

There was a problem with the auto-rolled cvs tarballs I believe. you
should actually do a checkout to be sure.

On Thursday, August 15, 2002, at 02:29 PM, Mark A. Garcia wrote:

> On Thu, Aug 15, 2002 at 03:50:38PM +0100, Geoff Campbell wrote:
>> Does anyone have any ideas on this at all?
>>
>> I've been having a poke around the code today, but I can't see
>> anything wrong. Seems to me that the first machine to come up
>> allocates both IP addresses correctly, then when Wackamole is started
>> on the second machine it grabs an IP address, which is correctly
>> dropped from the first machine, but then it's immediately dropped on
>> the second machine, too. I can't work out what is triggering the
>> event that causes this spurious dropping of the IP address.
>>
>> Finally, when Wackamole is stopped on the first machine, the second
>> one drops out with the message "wackamole: wackamole.c:668:
>> Send_state_message: Assertion 'ret == My.num_allocated' failed."
>>
>> Running the CVS Wackamole (v1.3.0 from January) on RedHat 7.3 on two
>> identical Intel boxes, with kernel v2.4.18-3. Is anyone else out
>> there successfully running Wackamole on this sort of setup? I have
>> happily run the release v1.2.0 Wackamole on these machines on Mandrake
>> v8.1 with a v2.4.8-26 kernel, unfortunately this setup doesn't work
>> with the software we're trying to implement on it.
>
> Geoff, I am following this thread, especially with Theo referencing to
> download the latest CVS version. But I see you mentioned the latest cvs
> from January. Have you tried the latest cvs version from July
> '200207111620.tar.gz' ?
>
> -.mag
>
>>
>> I'm happy to look at any wild guesses anyone has now, as I'm drawing a
>> complete blank on this one.
>>
>> Regards,
>>
>> Geoff Campbell
>> Internetworking Ltd.
>> +44(0)1267-253747
>>
>>
>>> -----Original Message-----
>>> From: wackamole-users-admin@lists.backhand.org
>>> [mailto:wackamole-users-admin@lists.backhand.org]On Behalf Of Geoff
>>> Campbell
>>> Sent: 07 August 2002 07:53
>>> To: wackamole-users@lists.backhand.org
>>> Subject: RE: [Wackamole-users] Wackamole dropping out
>>>
>>>
>>>> I'm a little out of touch with the latest wackamole releases, but
>>>> I've
>>>> been trying to think about what could be causing your problems.
>>>> Could
>>>> you send an email with your latest wackamole.conf, spread.conf, and
>>>> output from ifconfig for each machine?
>>>
>>> Certainly - see below. All three are identical for both
>>> machines, I did try changing the wackamole.conf Spread= line to
>>> explicitly reference the machine's IP addresses, and also to
>>> 4803@127.0.0.1, but neither made any difference.
>>>
>>> Regards,
>>>
>>> Geoff Campbell
>>> Internetworking Ltd.
>>> +44(0)1267-253747
>>>
>>>
>>> [root@www1 etc]# cat wackamole.conf
>>> # The Spread daemon we are going to connect to. It should be on
>>> the local box
>>> Spread = 4803
>>> SpreadRetryInterval = 5
>>> # The group name
>>> Group = wack1
>>> # Named socket for online control
>>> Control = /var/tmp/wack.it
>>> # In most cases, I just don't care. Let wackamole decide.
>>> #Prefer None
>>> # List all the virtual interfaces (ALL of them)
>>> VirtualInterfaces {
>>> { eth0:10.0.0.141/32 }
>>> { eth0:10.0.0.142/32 }
>>> }
>>> Arp-Cache = 90s
>>> Notify {
>>> eth0:10.0.0.1/32
>>> eth0:10.0.0.0/24 throttle 128
>>> arp-cache
>>> }
>>> balance {
>>> AcquisitionsPerRound = all
>>> interval = 4s
>>> }
>>> mature = 5s
>>>
>>>
>>>
>>> [root@www1 etc]# cat spread.conf
>>> Spread_Segment 10.0.0.255:4803 {
>>>
>>> www1 10.0.0.121
>>> www2 10.0.0.122
>>> }
>>> # Spread options
>>> #-----------------------------------------------------------------
>>> ----------
>>> #-----------------------------------------------------------------
>>> ----------
>>> #DebugFlags = { PRINT EXIT }
>>> EventLogFile = /var/log/spread.log
>>> #EventTimeStamp = "[%a %d %b %Y %H:%M:%S]"
>>> #DangerousMonitor = false
>>> #RequiredAuthMethods = " "
>>> #AllowedAuthMethods = "NULL"
>>> #AccessControlPolicy = "PERMIT"
>>>
>>>
>>>
>>> [root@www1 etc]# ifconfig
>>> eth0 Link encap:Ethernet HWaddr 00:E0:18:66:E2:10
>>> inet addr:10.0.0.121 Bcast:10.0.0.255 Mask:255.255.255.0
>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>> RX packets:3015333 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:1077030 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:100
>>> RX bytes:148087988 (141.2 Mb) TX bytes:84160285 (80.2 Mb)
>>> Interrupt:11 Base address:0x7000
>>>
>>> lo Link encap:Local Loopback
>>> inet addr:127.0.0.1 Mask:255.0.0.0
>>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>>> RX packets:533 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:533 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:0
>>> RX bytes:43990 (42.9 Kb) TX bytes:43990 (42.9 Kb)
>>>
>>>
>>>
>>> [root@www2 etc]# ifconfig
>>> eth0 Link encap:Ethernet HWaddr 00:E0:18:6D:FE:11
>>> inet addr:10.0.0.122 Bcast:10.0.0.255 Mask:255.255.255.0
>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>> RX packets:525142 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:254245 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:100
>>> RX bytes:726891149 (693.2 Mb) TX bytes:22840495 (21.7 Mb)
>>> Interrupt:11 Base address:0x7000
>>>
>>> lo Link encap:Local Loopback
>>> inet addr:127.0.0.1 Mask:255.0.0.0
>>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>>> RX packets:292 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:292 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:0
>>> RX bytes:19952 (19.4 Kb) TX bytes:19952 (19.4 Kb)
>>>
>>>
>>>
>>> _______________________________________________
>>> wackamole-users mailing list
>>> wackamole-users@lists.backhand.org
>>> http://lists.backhand.org/mailman/listinfo/wackamole-users
>>>
>>
>>
>> _______________________________________________
>> wackamole-users mailing list
>> wackamole-users@lists.backhand.org
>> http://lists.backhand.org/mailman/listinfo/wackamole-users
>
> _______________________________________________
> wackamole-users mailing list
> wackamole-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users
>
>
// George Schlossnagle
// Principal Consultant
// OmniTI, Inc http://www.omniti.com
// (c) 240.460.5234 (e) george@omniti.com
// 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0

> Geoff, I am following this thread, especially with Theo referencing to
> download the latest CVS version. But I see you mentioned the latest =
cvs
> from January. Have you tried the latest cvs version from July
> '200207111620.tar.gz' ?

Mark, George, thanks for your responses. I may be being a little dense =
here, how do I get hold of the July version you reference? If I run a =
"cvs checkout" from the command line, I get the January version, there =
doesn't seem to be a way to persuade the command line version to give me =
a list of other modules available, and the viewcvs browsable link from =
the Wackamole home page appears to be broken?

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747

> I just encountered a weird bug/feature in linux that may be affecting=20
> you. It seems that if you drop the _first listed_ virtual interface =
on=20
> a given subnet, linux will drop all of your other routes on that =
network=20
> as well. =20
>=20
> In freebsd the docs specifically require virt. interfaces to be added =
as=20
> /32s. I haven't tried that solution on Linux yet, as I've moved with=20
> other work aorunds (using a fixed place holder adress in that address=20
> sapce for that network).

Thanks for that one, too - not the problem in this case, as I've tried =
the /32 version of the addresses, and am using them at the moment. Will =
certainly file that one for future reference, though.

Regards,

Geoff Campbell
Internetworking Ltd.
+44(0)1267-253747

On Fri, Aug 16, 2002 at 10:10:43AM +0100, Geoff Campbell wrote:
> > Geoff, I am following this thread, especially with Theo referencing to
> > download the latest CVS version. But I see you mentioned the latest cvs
> > from January. Have you tried the latest cvs version from July
> > '200207111620.tar.gz' ?
>
> Mark, George, thanks for your responses. I may be being a little dense here, how do I get hold of the July version you reference? If I run a "cvs checkout" from the command line, I get the January version, there doesn't seem to be a way to persuade the command line version to give me a list of other modules available, and the viewcvs browsable link from the Wackamole home page appears to be broken?

You should be able to get it via the following:

cvs -d :pserver:anonymous@commedia.cnds.jhu.edu:/storage/cvs \
checkout wackamole

That will get you the latest commited version.

Then you can keep updates fresh in your checked out copy by cd'ing to it,
and doing 'cvs update'

Cheers,
-.mag

>
> Regards,
>
> Geoff Campbell
> Internetworking Ltd.
> +44(0)1267-253747
>
>
>
> _______________________________________________
> wackamole-users mailing list
> wackamole-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users