[collectd] Multicast

[Florian Forster]

--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Jeff,

On Fri, Oct 07, 2005 at 06:45:02AM -0400, Jeff Haney wrote:
> I would appreciate any help anyone could give me getting the multicast=20
> option to work.  It's not working and I'm not getting any feedback from t=
he=20
> daemon as to why.

I'll try ;) Thanks for mailing, I saw that I use `perror' (which outputs
to STDERR) even though I close STDERR at startup.. The next version will
fix this.. This _might_ explain why you don't get an error..

> The server is generating it's own stats in /var/lib/collectd,=20

If started with `-s' collectd shouldn't write any RRDs other than the
ones it gets via multicast. So if there is for example a
/var/lib/collectd/memory.rrd then there's something wrong. If you
started server and client on the same host, then all RRDs should be
under /var/lib/collectd/<hostname>/

<hostname> is the `reverse lookup' of the sending IP..

Could you post the complete list of arguments you have given? Also,
please note the `-c', `-l' and `-s' are exclusive! If you want
statistics of the `server' box as well you need to start a second
process using `-c' (or `-l', though I'd recommend the former).

> the client is not, presumably because it is in "send" mode however the=20
> server is not receiving anything.

Yep, that's correct behavior.

> Doing an "ip route add 224.0.0.0/4 dev eth0" and pinging 224.0.0.1
> gets a response from quite a few servers on the network so multicast
> appears to be working.

Adding the route shouldn't be neccessary, actually.. It probably doesn't
hurt though..

> Doing "ip route add 239.0.0.0/4 dev eth0" gives me a error, not sure
> why,

That's expected (if not correct) behavior: When giving a subnet-mask
(`/4') all but the significant bits (the first four) should be set to
zero. Therefore `224.0.0.0/4' includes `239.192.74.66' (it's the entire
IPv4 multicast net).

> and I get no response when trying to ping  239.192.74.66.

The server should answer here.. This is evidence that the problem is
something with the server..

> Also tried creating a subdirectory under /var/lib/collectd on the
> server machine with the hostname of the client machine (tried fully
> qualified and not qualified) but that didn't have any affect.

Collectd automatically creates these subdirectories as needed, so you
only need to check if the permissions are okay. But if it can create
RRDs the permissions should be okay..

That's what I'd do to get some more information:
1) Fire up `tcpdump' on both boxed like this (change `eth0' to whatever
   interface you have on the network-side):
   tcpdump -i eth0 -nv udp port 25826

   If you see a few lines every 10 seconds (see below) the client is
   sending. Depending on your network equipment you may see them on the
   server side although the server has not joined the multicast group..

   If you do not see any packets coming by I'll send you a pre-release
   version which reports to syslog instead of STDERR, maybe this clears
   things up a bit..

2) If you see the packages, check if the server is listening on the
   address/port using netstat (probably as root):

   alice:~# netstat -lnp | grep collectd
   udp 0 0 0.0.0.0:25826 0.0.0.0:* 8297/collectd=20

   If there is a listening socket, and you saw packets on the server,
   there's a real problem..

   If there is no listening socket we'll try the syslog-patches version,
   too..

Please let me know what you found out. I'm about to pack a
bugfix-release and would like to have this problem fixed (even if it's
`only' a documentation-problem..)

Regards,
-octo
--=20
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDRqSmjvke9ZFSPD0RArT0AKCLXkjsCB34WsfWVk/H5A/T1HtmOACfSceQ
sbrdBiGo9TBMLOjB3eLw7OI=
=jqD+
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--