[Olsr-users] Problems with OLSR

[Sven-Ola Tuecke]

Hi,

I miss the "ip a" in your debug output. Nevertheless, there may be these 
problems:

* You use RFC mode (means: not using LQ extensions). In RFC mode, olsrd may 
interoperate with other OLSR implementations. Are there others daemons out 
there still maintained? I'm unsure. We've experienced the same routing flap 
behaviour while fiddeling with the olsrd implementation a couple of years 
ago. Since Thomas included LinkQualityLevel 2, nobody uses this mode to my 
knowledge.

* Wifi config shows a possiblity, that 2 nodes may see each other via 2 
links using different wifi cards. This automatically triggers a bug in 
olsrd-0.4.10 IMO - bug exists even in RFC mode AFIAK. A simple matter of 
"what card to use". The sequence of incoming TCs will decide, which state is 
evaluated (Sym or not sym). Try
http://download-master.berlin.freifunk.net/sven-ola/nylon/packages/olsrd/files/0.5.1-110-olsrd-double-wlancard-neigh-hack.patch

* You use madwifi. Madwifi sucks. At least with IBSS. At least with MIPSEL. 
Stops sending whenever it likes (depends on weather IMO). You may need to 
verfiy the link layer e.g. with arping. And it's possible to re-init sending 
with "while true; do iwlist athX scan;sleep 5;done" (which in turn may oops 
on 5 Ghz - depends on your madwifi hal + patchset + iwpriv trick).

My two cents & have fun,
// Sven-Ola

""Gian Maria Giani"" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
The whole network contain 10 nodes in fixed positions, in outdoor 
environment, using olsrd v.0.4.10. Each node has about 3 neighbours, and the 
maximum distance between nodes is 3 hops. The problem we experienced is that 
routes are not stable.

This seems related to the fact that some neighbours are listed as 
non-symmetric (they appear as symmetric for some moments, then appear as 
asymmetric, then again as symmetric). The percentage of lost packets over 
these asymmetric links, however, is 0% in both directions. In the past weeks 
we have made several tries (modifying the validity and emission time of 
Hello and Tc messages, using link quality and hysteresis, etc), but the 
routes are still unstable using these modifications.

We have then decided to make further tests with a subset of this network, 
with only three nodes. The situation in this case is better, but routes are 
still *not* stable even in this small network. We observed the routes for 
about 20 seconds each time. With a total number of 68 observations, routes 
have been changed 10 times, which means 14.7% of the times. When we ran ping 
among nodes the percentage of lost packets is 0%, but the round trip time 
varies from 1 ms to 45 ms.

Attached to this message you can find the output of commands iptable, ip and 
iwconfig on the three nodes, as well as the contents of the olsrd.conf file. 
A few small notes: we have copied the *current* contents of the olsrd.conf 
file but, as mentioned previously, we have already tried different 
configurations, including LQ. The network nodes are Linux boxes using a 
small Linux image derived from OpenWrt, where only a few packages are 
installed and sometimes with limited options (in particular, this is 
relevant for the ip package, as you can see in the attached text files).

In this phase of our work, we would like to find measures for improving link 
stability, e.g. by using directional antenna, higher antenna gain, better 
interference protection, etc, but staying with olsrd 0.4.10. Do you have any 
hits on how to achieve high link stability, including both hardware and 
software measures? What is the main reason for the above described link 
instability problem?

Thanks a lot in advance.




-- 
Olsr-users mailing list
(spam-protected)
http://lists.olsr.org/mailman/listinfo/olsr-users