[olsr-dev] OLSR MainAddr(0.0.0.0)

Thomas Lopatic (spam-protected)
Mon Apr 11 12:00:39 CEST 2005


Hi everyone,

I have attached a patch for lq_packet.c that is tailored to the Berlin 
OLSR network and that filters out and reports to stderr

(a) incoming IPv4 LQ HELLOs that are sent by a neighbour that reports 
that its main address is 0.0.0.0

and

(b) entries in incoming IPv4 LQ TCs that report a link to a neighbour 
that has a main address of 0.0.0.0

I'll nevertheless investigate this and will try to find the conditions 
under which an LQ HELLO message with its originator set to 0.0.0.0 is 
transmitted. This seems to be the root of the problem.

The filter patch uses fprintf(stderr, ...), so it is independent of the 
debug level. It would be interesting to install this patch on the node 
next to the Windows node that has caused the problem and capture stderr 
output in a file. If the debug level is set to 0, then there should 
hardly be any output, so the file will remain pretty small. It would 
then be interesting to see whether there are any error messages in the 
file that complain about the Windows node sending an LQ HELLO that 
reports 0.0.0.0 as its main address, which would support my above theory 
about the root of the problem.

It would also be interesting to install the patch on one of the two-hop 
neighbours of the Windows node. Erm, what I mean is the following:

Windows node --- node A --- node B

In the Freifunk configuration (we have TC redundancy set to 2), node A 
will announce its link to the Windows node via a LQ TC message. As both 
nodes, A and B, are patched, node B should never get a TC message with a 
0.0.0.0 entry, as patched node A filters out neighbours with a main 
address of 0.0.0.0. If there nevertheless is an entry on node B that 
complains about an LQ TC message that contains 0.0.0.0 as a neighbour 
main address, then the patch on node A has not solved the problem! In 
this case my theory about the root of the problem is falsified.

So, in a nutshell:

* Let's patch the node next to the Windows node. Let's call this node 
"node A".

* Let's also patch one of the nodes next to node A. Let's call this node 
"node B".

* Redirect stderr to a file on nodes A and B.

* If node A complains in the stderr capture file about a neighbour that 
reports 0.0.0.0 as its main address in a LQ HELLO, then the theory is 
correct.

* If node B complains in the stderr capture file about a LQ TC that 
reports a link to a neighbour with a main address of 0.0.0.0 but node A 
does not complain at all, then the theory is wrong.

Thanks for reporting the problem and for assisting in its resolution!

-Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: filter.diff
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20050411/1efd06db/attachment.ksh>


More information about the Olsr-dev mailing list