[OLSR-users] duplicate IP behaviour

[Andreas Tønnesen]

Sven-Ola,

I agree that it might not be a good thing to terminate upon duplicate
detection as default. Let's rather consider hving this
termination/execution idea available as an explicit option and keep the
currnt behvior as default.

Now regarding autoconfig, I have actually been playing with the idea of
implementing a solution based on dhcp where one or more central boxes act
as DHCP servers while olsrd forwards requests/responses. This would
include a client that auto-detects olsr networks/mode(LQ/RFC) and possibly
other settings as well(?) This will break with the distributed idea of
ad-hoc networks, but I think it would work fine in your standard community
network... well - I'll get working on it one of those 25 hours days ;-)

> Andeas,
>
> please do *not* exit olsrd without further necessity. It's too easy to
> bring
> a complete mesh down simply by configuring an ip twice. The zeroconf
> people
> may consider ipv6 with an address based on the MAC instead.
>
> My two cents: zeroconf/dhcp/rendevezous and others are unsuitable for a
> bigger mesh, because you give away the (small) opportunity for some
> management here. People need to talk to each other - which is hard a total
> anon environment. OK - that's layer 8, not covered by ISO/OSI nor olsrd
> ;-)
>
> LG
> Sven-Ola
>
> "Andreas "Tønnesen"" <(spam-protected)> schrieb im Newsbeitrag
> news:(spam-protected)
>>
>> As long as two nodes share the same _main_ address, then the nodes
>> should
>> just discard the packets originating from eachother. You should see a
>> message like "Not processing message originating from us!"
>> As for messages beeing forwarded via other nodes I'll look that up later
>> (when I get back home).
>> 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
>> 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.
>> But I can't remember having implemented a termination if this occurs...
>> Well - I'll have a look at it later on.
>>
>> - Andreas
>>
>>> Hi,
>>>
>>> When testing what would happen if two OLSR nodes have the same IP, we
>>> found out that both just keep on running, but they loose their peer
>>> connections. This was tested on version 0.4.9 on OpenWRT (Linksys
>>> WRT54G, IPv4).
>>>
>>> I tested this a long time ago and i'm quite sure the result back then
>>> was that the first node detecting a simular IP would just crash with a
>>> clear OLSR error message about what went wrong.
>>>
>>> Has this behaviour been changed recently, or is this a bug that got
>>> into
>>> the software during recent routing-algorithm changes?
>>>
>>> For our un-administered network setup, an OLSR crash that we can detect
>>> would be ideal, so we can just choose another IP and restart OLSR. If
>>> someone knows about another trick to detect duplicate IP numbers, i'm
>>> also very interested.
>>>
>>> Thank you for your help,
>>>
>>> Jaap
>>>
>>> _______________________________________________
>>> olsr-users mailing list
>>> (spam-protected)
>>> https://www.olsr.org/mailman/listinfo/olsr-users
>>>
>>
>>
>>
>> _______________________________________________
>> olsr-users mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-users
>
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users
>