[Olsr-dev] Detecting IP address collision between nodes

Henning Rogge (spam-protected)
Mon Sep 7 11:09:49 CEST 2009

Am Sat September 5 2009 22:42:33 schrieb Mitar:
> Hi!
> In our network we would like to extend our monitoring software with a
> possibility of detecting IP address collision between nodes. Does OLSR
> supports already something like this?
No. At the moment we assume that all communicating OLSR nodes have unique IPs 
(both interface and originator-IP).

> As we researched OLSR does not detect this and merge nodes together
> into one node.
Sometimes you might even get some kind of fluctiations in the network because 
of conflicting TC information.

> This is understandable as it uses IP address to
> identify nodes so it cannot distinguish between them. Only nodes which
> are in a collision can detect this. In code there is a check if
> message comes from same IP address:
> ipequal((union olsr_ip_addr *)&m->v4.originator, &olsr_cnf->main_addr)
> But as I understand such message can come back to a node also in a
> normal OLSR operation when other nodes broadcast its message, can't
> it?
Exactly. Most OLSR messages are flooded through the network, so it's a NORMAL 
thing that you get a copy of your own message (most times from your 1-hop 

> So my idea is that each node would check TC messages and if it would
> see that there are TC messages which are with its IP address but which
> node has not send (like TC message that there is a peer this node does
> not know nothing about) it would know that there is some IP address
> collision going on.
Not easy to do. You might have lost the link inside the TC a moment ago 
because of an interface going down. The best way to detect a collision might 
be the message sequence number. If you have two nodes, one of them should 
receive messages with a "future" number.

> When this situation would be detected by the node (one or the other or
> both) it would have to report it to the monitoring node. Because
> routing does not work reliably for this node TCP is probably not
> possible. Even UDP could get lost on a way to the monitoring node. So
> an idea was to add a special flag to TC messages this node is sending
> around (and all other nodes distribute all over the network) which
> would say that a node which has send this message has detected an IP
> address collision. So all other nodes would know that something is
> happening and also the monitoring node could then get this
> information.
I think there are three different cases we should discuss.

1.) collision between two originator-IPs

this is the worst case. The originator-IP is the "identity" of the OLSR node. 
In most OLSR nets these numbers are preconfigured, so it's not easy to get a 
new one. We would need some way to "prove" which nodes own a originator-IP.

2.) collision between an originator-IP and an interface-IP

Olsrd already contains an experimental patch that allows to keep the 
interface-IPs hidden for nodes far away, only the originator-IP will be known 
(and routed) by the net. If we use this patch, the node with the conflicting 
interface-IP should just change it. Without this patch it's much more 
difficult, especially if the interfaces get public IPs too (see Vienna 
funkfeuer net).

3.) collision between two interface-IPs

With the patch mentioned above the sollution is easy, one (or both) interfaces 
need a new interface IP. Without it, it's difficult.

> What do you think? Any improvements to the idea? It is too
> complicated? It is too simple? Does something already exists? How
> would one implement this? Is it possible to implement it as a plugin?
> Would it be possible to add it to the official version if we make a
> patch?
A plugin/patch would be a nice way to help an user to debug problems, even if 
we have no way to solve the problem. There are some special situations where 
we could temporarly solve the problem by blocking a link (to prevent damage to 
the net), but most of them require the 'don't flood interface IP' patch.

I have planned to add a Logger-RSSfeed to the plugins of the development tree, 
so the user can keep an eye on the his OLSRd router. This would be a possible 
way to tell the user "hey, you have a problem with our interface IP x" too.

Henning Rogge

Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090907/78c60a99/attachment.sig>

More information about the Olsr-dev mailing list