[olsr-dev] Changes and some bug fixes to olsrd
aaron
(spam-protected)
Tue Nov 28 14:44:01 CET 2006
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
>
More information about the Olsr-dev
mailing list