[Olsr-users] Problems with OLSR
Thu Sep 20 13:05:18 CEST 2007
I miss the "ip a" in your debug output. Nevertheless, there may be these
* 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
* 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
* 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,
""Gian Maria Giani"" <(spam-protected)> schrieb im Newsbeitrag
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
Thanks a lot in advance.
Olsr-users mailing list
More information about the Olsr-users