[olsr-dev] Changes and some bug fixes to olsrd
Erik Tromp
(spam-protected)
Wed Nov 29 20:00:46 CET 2006
We're using OLSR in a mixed wired/wireless network. And we're
using VLANs, and there is one IP-interface per VLAN. That
adds up....
Sven-Ola, thanks for the link to your patches! I will have a look at
them in a couple of days.
gtrz,
Erik
----- Original Message -----
From: "aaron" <(spam-protected)>
To: "Sven-Ola Tuecke" <(spam-protected)>
Cc: <(spam-protected)>
Sent: Tuesday, November 28, 2006 2:44 PM
Subject: Re: [olsr-dev] Changes and some bug fixes to olsrd
> I believe the 16 interfaces was actually a patch submitted by bernd.
> In Vienna we really already have 17 or 18 interfaces.
> This is on a openvpn tunnel server.
>
> a.
>
> On Tue, Nov 28, 2006 at 09:39:44AM +0100, Sven-Ola Tuecke wrote:
> > Hi Eric,
> >
> > at a first glance, your patches are compat to mine (besides the MAX_IFS
> > change, a very minor oops). Just curious: For what the heck you need more
> > than 16 ifaces? There are only 13 physical channels (b/g) which leaves room
> > for some wired stuff...
> >
> > // Sven-Ola
> >
> > ""Sven-Ola Tuecke"" <(spam-protected)> schrieb im Newsbeitrag
> > news:ekf3k4$qbl$(spam-protected)
> > >Eric,
> > >
> > >one day we need to make a "patch orgy" for 0.5.x ;-) Here are mine:
> > >http://olsrexperiment.de/sven-ola/nylon/packages/olsrd/files/
> > >(to be applied to olsrd-0.4.10 as mentioned in this file:
> > >http://olsrexperiment.de/sven-ola/nylon/packages/olsrd/olsrd_0.4.10.bb ).
> > >That stuff is critical here in berlin - otherwise those up-to-500-routes
> > >will not work on 200Mhz MIPS boxes (>100% CPU). They are also included in
> > >OpenWrt (Whiterussian as well as Kamikaze branch AFAIK). I will check your
> > >patches first. If they are compat to mine, I will put them into the nylon
> > >dir on olsrexperiment.de in the next couple of days.
> > >
> > >P.S. In case you wounder: those files are for building a Nylon (aka
> > >OpenEmbedded for 4G-Meshcubes). Besides that, I use more patches e.g. for
> > >Freifunk Firmware to optimize binary size for the firmware (ref:
> > >http://ff-firmware.cvs.sourceforge.net/ff-firmware/ff-devel/ go to
> > >olsrd-optimize-size.patch)
> > >
> > >Thanks alot anyhow...
> > >// Sven-Ola
> > >
> > >""Erik Tromp"" <(spam-protected)> schrieb im Newsbeitrag
> > >news:(spam-protected)
> > >>Dear Maintainers of the OLSRD code,
> > >>
> > >>I would like to propose a few fixes and enhancements to the current OLSR
> > >>code. The proposed changes are the diff file which can be
> > >>downloaded from http://home.tiscali.nl/levab001/olsrd-0.4.10.diff. The
> > >>diff's are with respect to the current version 0.4.10, as can
> > >>be downloaded at: http://www.olsr.org/releases/0.4/olsrd-0.4.10.tar.gz
> > >>
> > >>Just to be sure you're doing the same as I did, here is the patch
> > >>procedure. Unpack the downloaded .tar.gz file, e.g.
> > >>
> > >> tar -xvzf olsrd-0.4.10.tar.gz
> > >>
> > >>A directory olsrd-0.4.10 will be created. cd to that directory. Copy the
> > >>olsrd-0.4.10.diff file as attached to this mail into that
> > >>directory. Then type:
> > >>
> > >> patch -p 1 < olsrd-0.4.10.diff
> > >>
> > >>You should see a lot of lines starting with "patching file ...". That
> > >>will conclude the patch process.
> > >>
> > >>Below is a list of the changes I propose; some rather trivial, but some
> > >>very 'challenging' ;-) All changes have been tested, but of
> > >>course, there may always be stuff that I missed.
> > >>
> > >>Have fun!
> > >>
> > >>Erik
> > >>
> > >>
> > >>* Added comment about 'Weight' and 'LinkQualityMult' parameters in
> > >> sample .conf files.
> > >>
> > >>
> > >>* httpinfo plugin:
> > >> - make IP-addresses clickable
> > >> - Show ETX value of a HNA route
> > >> - Show number of MID aliases for each MID entry
> > >> - Print LQ information only if LQ enabled
> > >>
> > >>
> > >>* Fix double definition MAX_IFS (16) and MAXIFS (8)
> > >>
> > >>
> > >>* Increased MAX_IFS to 32
> > >>
> > >>
> > >>* Fix copying of old instead of new main IP address in
> > >>chk_if_changed(...) function
> > >>
> > >>
> > >>* Fix link-set -> neighbor-set mismatch that occurs when a neighbor node
> > >>changes its main IP address.
> > >>
> > >>
> > >>* Fixed an inconsistency in the LQ MPR calculation, where a node would be
> > >>selected
> > >> as MPR to a 2-hop neighbor even if the 2-hop neigbor could be reached in
> > >> 1 hop at a lower ETX.
> > >>
> > >> Explanation:
> > >> Suppose we have 4 nodes, A, B, C and D, in the following topology:
> > >>
> > >> 1 1
> > >> A ----- B
> > >> 0.5| \0.5 | 1
> > >> | \ |
> > >> | \ |
> > >> | \ |
> > >> 0.5| 0.5\ | 1
> > >> C ----- D
> > >> 0.5 0.5
> > >>
> > >> The number on each side of the link is the link quality value as
> > >>observed
> > >> by the corresponding node. mpr_coverage is 2.
> > >>
> > >> Currently, the function olsr_calculate_lq_mpr in node A does the
> > >>following
> > >> (follow along in the source code):
> > >>
> > >> // loop through all 2-hop neighbours
> > >> --> the only 2-hop neighbor is D
> > >>
> > >> // check whether this 2-hop neighbour is also a neighbour
> > >> --> Yes, at quality 0.5 * 0.5 = 1/4. This value is stored in 'best'.
> > >>
> > >> // see wether we find a better route via an MPR
> > >> --> Yes, the 2-hop path A-B-D has path_link_quality 1 * 1 = 1
> > >>
> > >> k is set to 0
> > >>
> > >> // look for the best 1-hop neighbour that we haven't
> > >> // yet selected
> > >> --> 'best' is set to -1.0, and the search results in neighbor B,
> > >> 'best' being 1. B is selected as MPR.
> > >>
> > >> k goes to 1
> > >>
> > >> // look for the best 1-hop neighbour that we haven't
> > >> // yet selected
> > >> --> 'best' is set to -1.0, and the search results in neighbor C,
> > >> 'best' being 1/16. C is also selected as MPR, even through the
> > >> path link quality is lower than the quality of the 1-hop link
> > >> A - D, which is 1/4 .
> > >>
> > >> The inconsistency is: if path A - B - D would not be there at all,
> > >> the LQ-MPR calculation would see only A - D as the 1-hop path and
> > >> never even consider C an MPR in the 2-hop path A - C - D. Now we add
> > >> a better 2-hop path A - B - D, and suddenly node C becomes MPR in
> > >> the 2-hop path A - C - D.
> > >>
> > >>
> > >>* Fix a bug in link-quality handling of hello messages inside
> > >> olsr_process_message_neighbors. This bug caused continuous flapping
> > >> of MPR selection in certain situations.
> > >>
> > >> Suppose we have 3 nodes, A, B, C in the following topology:
> > >>
> > >> 1 ------ 1
> > >> 1 1 / \
> > >> A ----- B C
> > >> \ /
> > >> 0.5 ------ 0.5
> > >>
> > >> The number on each side of the link is the link quality value as
> > >>observed
> > >> by the corresponding node.
> > >>
> > >> B sends a LQ hello message indicating that has a neighbor C at LQ=1 and
> > >>NLQ=1,
> > >> and it has neighbor C at LQ=0.5 and NLQ=0.5 .
> > >>
> > >> A receives the LQ hello message by B. Currently, the
> > >>olsr_process_message_neighbors
> > >> function in node A does the following (follow along in the source code):
> > >>
> > >> for(message_neighbors = message->neighbors;
> > >> message_neighbors != NULL;
> > >> message_neighbors = message_neighbors->next)
> > >> --> Let's assume the neighbor message "B has C at LQ=1 and NLQ=1" is
> > >>processed first
> > >>
> > >> if (olsr_cnf->lq_level > 0)
> > >> --> yes, we're doing LQ OLSR
> > >>
> > >> link =
> > >>get_best_link_to_neighbor(&neighbor->neighbor_main_addr);
> > >> --> there is only one link, A - B, link->loss_link_quality = 1 and
> > >> link->neigh_link_quality = 1.
> > >>
> > >> // have we found the one-hop neighbor that sent the
> > >> // HELLO message that we're current processing?
> > >>
> > >> if (walker->neighbor == neighbor)
> > >> --> ok, found 2-hop neighbor C via 1-hop neighbor B
> > >>
> > >> walker->second_hop_link_quality =
> > >> message_neighbors->link_quality *
> > >> message_neighbors->neigh_link_quality;
> > >> --> walker->second_hop_link_quality becomes 1 * 1 = 1.
> > >>
> > >> walker->path_link_quality =
> > >> walker->second_hop_link_quality *
> > >> link->loss_link_quality *
> > >>link->neigh_link_quality;
> > >> --> walker->path_link_quality becomes 1 * 1 * 1 = 1
> > >>
> > >> for(message_neighbors = message->neighbors;
> > >> message_neighbors != NULL;
> > >> message_neighbors = message_neighbors->next)
> > >> --> Now the neighbor message "B has C at LQ=0.5 and NLQ=0.5" is
> > >>processed.
> > >>
> > >> if (olsr_cnf->lq_level > 0)
> > >> --> yes, we're doing LQ OLSR
> > >>
> > >> link =
> > >>get_best_link_to_neighbor(&neighbor->neighbor_main_addr);
> > >> --> there is only one link, A - B, link->loss_link_quality = 1 and
> > >> link->neigh_link_quality = 1.
> > >>
> > >> // have we found the one-hop neighbor that sent the
> > >> // HELLO message that we're current processing?
> > >>
> > >> if (walker->neighbor == neighbor)
> > >> --> ok, found 2-hop neighbor C via 1-hop neighbor B
> > >>
> > >> walker->second_hop_link_quality =
> > >> message_neighbors->link_quality *
> > >> message_neighbors->neigh_link_quality;
> > >> --> walker->second_hop_link_quality becomes 0.5 * 0.5 = 0.25.
> > >>
> > >> walker->path_link_quality =
> > >> walker->second_hop_link_quality *
> > >> link->loss_link_quality *
> > >>link->neigh_link_quality;
> > >> --> walker->path_link_quality becomes 0.25 * 1 * 1 = 0.25
> > >>
> > >>
> > >> So: the better walker->path_link_quality of 1 is now overwritten by the
> > >>worse
> > >> walker->path_link_quality of 0.25 simply because the worst neighbor
> > >>message
> > >> by B was transmitted last. If B would have put its neighbor messages the
> > >>other
> > >> way round into its LQ hello message, the better
> > >>walker->path_link_quality
> > >> would have 'survived' instead.
> > >>
> > >> In other words, depending on the order of neighbor messages in a
> > >>LQ-hello
> > >> message, 2-hop path link qualities may change, even though nothing
> > >>really
> > >> changes in the network.
> > >>
> > >> This is the cause for a lot of 'route/MPR flapping' in the OLSR network,
> > >>which
> > >> we experienced during testing.
> > >>
> > >>
> > >>* Fix duplicate entries of aliases in MID entries.
> > >>
> > >>
> > >>* Remove no longer declared aliases from MID entries.
> > >>
> > >>
> > >>* Moved annoying printing of duplicate tables down to debug level 8.
> > >>
> > >>
> > >>* Fix: when link quality routing is enabled, HNA route calculation should
> > >>be based on
> > >> link quality, not on hopcount.
> > >>
> > >>
> > >>* Prevent two nodes that are advertising the same HNA from processing
> > >>each
> > >> other's HNA ending up in the two nodes routing the same (sub)net to each
> > >> other in deadlock.
> > >> To this end, added functions find_local_hna4_entry(...) and
> > >> find_local_hna6_entry(...)
> > >>
> > >>
> > >>_______________________________________________
> > >>olsr-dev mailing list
> > >>(spam-protected)
> > >>https://www.olsr.org/mailman/listinfo/olsr-dev
> > >
> > >
> > >_______________________________________________
> > >olsr-dev mailing list
> > >(spam-protected)
> > >https://www.olsr.org/mailman/listinfo/olsr-dev
> >
> >
> > _______________________________________________
> > olsr-dev mailing list
> > (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-dev
> >
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>
More information about the Olsr-dev
mailing list