[Berlin-wireless] freifunk olsrd versus selfcompiled versus openwrt olsrd

[Sven-Ola Tücke]

Moins & Hey,

es wird wie immer keine einfachen Antworten ala "Installier http://asdf.exe" geben. Sorry
fuer diese lange und evnt. etwas konfuse Mail...

Da waere naemlich zunaechst die Frage, welches lq_plugin? Per Default ist etx_fpm 
aktiv, waehrend die Firmware etx_ff verwendet. Das ist der neue Parameter 
LinkQualityAlgorithm in der olsrd.conf:

etx_fpm: Messung der Link-Quali anhand verlorener Hello-Nachrichten
etx_float: dasselbe wie etx_fpm, aber mit floats berechnet
etx_ff: Messung der Link-Quali anhand verlorerer OLSR-Pakete

Alle drei plugins sind Neuimplemteriungen - wobei das etx_ff das bisherige Verhalten bis 
olsr-0.5.5 am besten wiedergibt. etx_fpm/float koennte mal noetig werden, wenn das 
staendige Fluten mit TC's nicht mehr noetig ist und uns damit die groszen Pakete zur 
Messung einfach fehlen. Das ist _jetzt_ aber nicht der Fall.

Der Lq_mult wird allerdings in den Plugins berechnet. Das frueher moegliche 
LQ_Mult=2.0 (das war'n Bug, wurde aber benutzt) geht uebrigens auch nicht 
mehr, das'n typisches Refactoring-Opfer.

Das ifup/ifdown zum Absturz fuehrt ist auch nicht ganz neu. Es gibt ja einen Cronjob,
der das einfach neu starten. Nach meiner Meinungs sind das die olsrd-internen 
Datenstrukturen, die werden nicht aufgeraeumt / geloescht, insbesondere wenn das 
IFace mit der Main-IP 'runterfaellt (und damit der laufende olsrd eine neue Main-IP 
verwenden muss). Ich hatte das vor 'ner Weile eigentlich gefixed, damit wenigstens 
nicht alle Nachbarn ebenfalls abgehen siehe  http://gredler.at/hg/olsrd-0.5.6/rev/7b7b2f8a0a77

Dass Topoinfo nicht ordentlich ueber die MPR-Kette weitergereicht wird, das ist mir 
allerdings neu. @ulf: bitte gucken, ob die MPR-Ketten auch ueber alle Interfaces 
beidseitig richtig ermittelt wurden? MPR's gibts doch noch oder!?

Weiters bin ich mir nicht sicher, ob + welche meiner diversen Patches in der aktuellen 
Version drin sind. Ist dieser hier enthalten? Lt. Repository ja 
-> http://gredler.at/hg/olsrd-0.5.6/rev/aac621d9803e

Hintergrund: Es gab/gibt es einen Bug, der verhindert die Paket-Aggregation 
hereinkommender Messages. An sich laeuft das so:

a) es kommen Datenpakete 'rein
b) daraus werden Messages gelesen + in olsrd eingespeist
c) die Messages werden gesammelt
d) und als Paket wieder 'rausgesendet

Punkt d) wird getriggert, wenn eine bestimmte Zeit um ist (1-2 Sek, mit 
"Random"-Jitter), oder wenn die MTU erreicht ist. Der Jitter verhindert bei 
miesen Links (...auf denen nur kleine Pakete uebertragen werden koennen), 
dass ein Node gar keine Infos erhaelt.

Genau das war kaputt (heisst: keine Paketaggregation, sondern immer 
gleich Minipakete senden). Mit der Folge, dass auch miese Links gute 
Werte bekamen bzw. miese so gut wie ununterscheidbar von guten Links 
waren. Im Uebrigen auch der Grund, warum ich etx_fpm nicht verwende: 
Hellos werden naemlich sofort gesendet (Buffer flush). Ausserdem verlaengere 
ich gerne die angedachten fuer 5-Node-Netzwerke gedachten Defaults, 
wie z.B. das hier

http://ff-firmware.cvs.sourceforge.net/viewvc/*checkout*/ff-firmware/ff-devel/131-olsrd-tweak-ffetx.patch

P.S. Des weiteren rechnet FPM ab olsrd-0.5.6 mit 10Bit-Nachkomma. Das 
sind zwar nur 2 Bit weniger als olsrd-0.5.5, aber ich persoenlich saehe es lieber 
wenn es z.B 14 Bit waeren und die entsprechenden Zahlenueberlaeufe 
(FPM_INT_MAX, FPM_INT_MIN) anders aufgefangen wuerden. Ich denke aber, 
die generelle Rechengenauigkeit spielt fuer die aktuellen Bugs keine Rolle.

P.P.S: Irgendwer noelte irgendwat von "wo ist der Patchset".

Der ist wie immer hier, nnn-olsrd*.patch unter:
  http://ff-firmware.cvs.sourceforge.net/viewvc/ff-firmware/ff-devel/
makefile dann dieses:
  http://ff-firmware.cvs.sourceforge.net/viewvc/*checkout*/ff-firmware/ff-devel/freifunk-olsrd.mk 
Also sind die Patches dann hier 'draufzuwerfen:
  http://gredler.at/hg/olsrd/rev/7b7b2f8a0a77

HTH,
// Sven-Ola

Am Samstag 11 Oktober 2008 23:27:58 schrieb Patrick Grimm:
> Tach
> Das Problem hab ich auch.
> Wir sollten uns auf eine Version einiegen. Im BBB sieht es nicht
> besser aus.
> Wo finde ich die patche für den olsrd in der aktuellen Firmware?
> Was ist mit lqmult default 0.5 z.b. Passiert? Das scheint nicht mehr
> zu gehen.
> Wir würden dann im pberg alle knoten auf die gleiche Version updaten
> wenn klar ist welche.
>
> Gruß
>               Patrick
>
> Am 10.10.2008 um 12:56 schrieb "ulf kypke" <u.kypke at gmail.com>:
> > hi folks,
> > ich möchte nicht zu viel salz in die wunde streuen, aber es gibt
> > ernsthafte probleme / inkompatibilitaeten zwischen dem freifunk
> > firmware olsrd, dem openwrt kamikaze olsrd und einem frisch von
> > olsr.org kompiliertem.
> > dies zeigt sich besonders zwischen version 0.5.5.pre  und 0.5.6
> > routing information werden bei systemen mit multi-interfaces nicht
> > vollstaendig an die nachbarn weitergereicht, erstes zeichen hierfuer
> > sind die recht grossen empfangenen olsr pakete und nur sehr kleine
> > gesendeten olsr pakete. zudem wird die topologie nur bis zu einen hop
> > hinter einen link local in der routing table eingetragen, bei einem
> > "olsr relais" also einem sytem auf dem an min. zwei schnittstellen
> > olsr gesprochen wird sind das jeweils die andere lokale schnittstelle.
> > so sieht ein nachbar per wlan seinen link local teilnehmer und dessen
> > zweites interface in der routing table aber nicht die restliche wolke
> > die an dem zweiten interface erreichbar waere.
> > und speziell bei der aktuellen openwrt kamikaze olsr version stuerzt
> > der olsr ab, wenn ihm z.b. durch einen wackeligen link das client wlan
> > interface im master client weggenommen wird. ich habe nun zwei
> > linkstrecken bei denen diese probleme auftauchen, eines ist das hdl
> > zum tacheles, bzw. alxhh hat das selbe problem vom hld zum frauenhofer
> > focus und bei der linkstrecke zwischen cbase und tresor / koepi.
> > ueberall kommt ein mischsetup mit freifunk firmware unf kamikaze,
> > sowohl also auch x86 mit selbst kompiliertem olsr von olsr.org zum
> > einsatz.
> > wer hat lust zu debuggen ;)
> > gruss ulf
> > _______________________________________________
> > Berlin mailing list
> > Berlin at berlin.freifunk.net
> > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin