Stable branch check for those who don't know: in the olsrd CVS are two parts of development. The HEAD where the actual development takes place and a stble branch "olsr_04".

I diff'ed them (and found some - IMHO - minor stuff in the process).
The only differences are roughly:
- the initial libnet stuff (which is markes #ifdef LIBNET anyways)
- putting config variables togehter into the olsr_cnf variable (and
killing src/defs.c where the separate variabls where defined).
- there is a "FriendlyNameToMiniIndex" function (and some code aropund it) in the
Win32 port.
Since I have no experince, I wait for comments from Thomas Lopatic.

All other differences are IMHO not bug/error relevant.

So IMHO the olsr_04 branch should be bug-fix-like up-to-date.  ¶ 2:32 PM 0 comments

  slides for the funkfeuer convention The slides for the funkfeuer convention are online now. (german, sorry. English version coming) -- aaron  ¶ 8:35 AM 0 comments

  Silent hard limit removed FunkFeuer/Vienna ran yesterday into the problem that adding a 17^th interface makes "olsrd" bail out right after startup. It turns out that there was a statically sized array for the number if interfaces defined but never checked. So the 17^th wrote a pointer somewhere beyond the array. So this was actually a bug fix.

The fixes are committed into HEAD with http://www.olsr.org/pipermail/olsr-cvs/2006-November/000199.html and following.

Backporting the bug fix today to the "olsrd_04" stable branch required also the backporting of more stuff - there was another similarily statically sized array ("fwdtimer" for the curious). The patched version runs now for more than 1.5 hours on my home node - so it seems to work so far.

Apparently there were more statically size arrays in earlier versions - so this change seem to go into the corrct direction.

Alas, I probably broke the Windows port - see in the above commit message for more details. I should get the toolchain to work on windows.  ¶ 1:12 PM 0 comments

  First fixes OK, first small fixes:

• - http://www.olsr.org/pipermail/olsr-cvs/2006-November/000178.html adds a convenient target similar to other ones.
• - http://www.olsr.org/pipermail/olsr-cvs/2006-November/000180.html resulted from a review of all socket(2) and accept(2) calls to avoid leaking file descriptors.
  
• - http://www.olsr.org/pipermail/olsr-cvs/2006-November/000190.html and the following fix wrong usage.
  It helps to compile such stuff on AMD64 though top get warnings.

  ¶ 3:29 PM 0 comments

  new/old ideas by otti

otti from funkfeuer Graz made a nice list of things (sorry, german) he would like to see in a new OLSR version. Some ideas were already included in our plans (notably: correcting the ETX metric calculation. We also thought about zoning but dismissed that idea for Vienna since our IP adresses are scattered all around the network

The section "Erkennen von Nachbarn" (neighbor discovery) is and was already implemented (poll interval) but adding some dynamic auto tuning capabilities would be niece. I.e. I can imagine that a olsr node "senses" that he is moving (accelerometer) and accordingly decrease the polling interval. Hm.. new idea!

"Treffen der Routing Entscheidung" (routing decision):

yes, that basically sounds like the new BATMAN protocol by freifunk Berlin.

"Supporting Anycasts" sounds like a nice new idea. But on the other hand... I never encountered a anycast server in the wild out there. Sad but true. Would be a really nice thing to have. But then... you would also need better IPv6 support.

  ¶ 4:46 PM 0 comments