[Spread-users] Retransmission and Connection Problems
mcdermj at peak.org
Fri Oct 3 18:58:23 EDT 2003
On Thursday, October 2, 2003, at 10:35 PM, Jonathan Stanton wrote:
> This is only a quick reply now as it's 1:30am and I'm really crashing.
I know how that goes...
> I have seen a number of issues with multi-homed machines. Sometimes
> work just fine, sometimes they can work if configured (either Spread
> configuration, or networking) and sometimes they seem to have problems
> because of OS issues (usually Linux -- hopefully FreeBSD doesn't have
> same problems).
I don't know if this is the same as Linux, but it seems that the
multicast packets go out the interface with the default route, unless
otherwise specified. This is probably the "correct' behavior as far as
the OS is concerned. , and I feel pretty boneheaded for not
realizing/checking this before. I configured a router for 184.108.40.206 to
get pushed through the correct interface and everything started looking
> My experience has been that multicast with multihomed machines can be
> tricky because often only one interface is assigned to route multicast
> packets and so if it isn't the right one (meaning the one the Spread
> configuration is using) then nothing works.
> Broadcast usually works in these cases though, as the bcast address is
> network address specific so it gets routed out the right interface.
It appears that possibly there's some sort of broadcast limiting or
other weirdness on our network that seems to be making broadcast not
> The D, C, spread network configuration syntax was designed to deal with
> multihomed machines, so it could help specify the bindings more
> but if the machines are all on the same network it should not be
I did this just in case, it wasn't that hairy a change to make.
> I'd run 'netstat -tan' and 'netstat -rn' while the spread daemons are
> and check the interfaces they are bound to and listening on, and the
> routing table and make sure it all matches up. If you can post them
> take a look tomorrow and see if I notice anything.
> The 'spsend' and 'sprecv' programs that are part of the spread source
> not built by default -- run 'make testprog' in a ./configured tree)
> the same kind of unicast, broadcast, and multicast UDP packets that
> itself does and can verify whether the networking is working without
> running all of Spread.
The spsend and sprecv programs are great, and invaluable. They helped
me find my problems with
1) firewall rulesets
2) multicast routing
in pretty quick order. Thank you very much for pointing these out to
The apache daemons seem to be connecting correctly now, and shoving log
records into the log receivers, and spuser seems to work great. For
some reason spmonitor is failing to execute. It gets through its
banner, and up to the point at which it relenquishes permissions, and
then exits. It seems to be exiting with a return code of 1, and I
can't find anywhere in the monitor code where it would do this.
> Hope this helps some,
Thank you immensely, this helped very much!
Jeremy C. McDermond
mcdermj at peak.org
Peak Internet, LLC
More information about the Spread-users