[OLSR-users] duplicate IP behaviour

[Bernd Petrovitsch]

On Sun, 2006-02-12 at 20:59 +0100, Kosta Welke wrote:
> Andreas Tønnesen wrote:
> > I agree that the best solution might be that olsrd exits when encountering
> > a IP duplicate.. but I'm not 100% sure(perhaps this should be yet another

AFAIK behaviour on IP duplicates is at best "undefined". So best is to
avoid it (and fix up your IP assignments scheme. If the scheme
allows/produces duplicated IPs, please bugfix it or throw it away).
Apart from the below situation, where the net actually identifes
duplicated IPs, what happens if the duplicated IPs are not detected?
This may not happen today with current implementation of olsrd (since 
one node knows "always" the whole net) AFAICS but in the future?

> > configurable option). But multiple nodes using the same main address will
> > have a very bad impact on the network. So I guess what I'm saying is that
> > we should enforce some sort of DAD which tries to make the network kind of
> > "self healing" bu terminating the conflicting clients.
> 
> What about olsrd just invoking a script when it detects an IP duplicate?
> (Or should be "olsrd stops, invokes script, restarts?", I think this is 

Uuugh - killing a routing daemon is seen by the whole network (not only
with OLSR/olsrd, also with RIP/OSPF/...).

> unnecessary, but you're the olsr guru)
> 
> I am using IP zeroconf and olsr (in a small research envrionment) and if 
>   could olsr detect IP address conflicts, that would be great (ARP 
> doesnt really help in an olsr'd net). For me, invoking a script that 
> rolls the dice for just another IP address would seem like a good solution.

Yes, for such zeroconf (and similar) networks this *is* a solution.
And es Svan pointed out, there is no general solution since we are
messing here with IP-address-administration systems and policies.
Invoking script/programm - read: fork()/exec()/handle SIGCLD[0] (with a
definedlist of parameters and possibly with some interpretation of it's
return value) is the most olsrd can or should do. And there the admin
can do whatever he wants (write a log emtry, send an email, `kill
getppid`, ...).

	Bernd

[0]: One may think about using system(3) here and it *may be*
     considered secure (enopuh) - depending on th actual implementation.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services