[Spread-users] Retransmission and Connection Problems

[Jeremy McDermond]

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 
> they
> 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 
> the
> 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 225.0.1.1 to 
get pushed through the correct interface and everything started looking 
okay.

> 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 
work correctly.

> The D, C, spread network configuration syntax was designed to deal with
> multihomed machines, so it could help specify the bindings more 
> precisely,
> but if the machines are all on the same network it should not be
> 'necessary'.
>

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 
> up
> 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 
> I'll
> take a look tomorrow and see if I notice anything.
>
> The 'spsend' and 'sprecv' programs that are part of the spread source 
> (but
> not built by default -- run 'make testprog' in a ./configured tree) 
> send
> the same kind of unicast, broadcast, and multicast UDP packets that 
> Spread
> 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 
me.

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!

> Jonathan
>
--
Jeremy C. McDermond                                                     
   mcdermj at peak.org
Lead Engineer
Peak Internet, LLC                                                      
                 (541) 738-4921