[Berlin-wireless] Backbone-Links im managed Mode, ACK für OLSR-Pakete nur vom AP

[Marco Tidow]

On Mon, Aug.14. 01:57 +0200, Joerg Albert wrote:
> Marco Tidow wrote:
> >Hm, denke, die Frage ist, ob client broadcast-packets wegen der (ggfs. mehrfachen)
> >Wiederholung seitens des AP dann auch auf client-Seite mehrfach durch die Kette
> >wlan-firmware - Treiber - IP-stack "nach oben" durchgereicht werden, oder ob
> > (z.B. durch eine Art sequence-counter-field im 802.11-frame) mehrfach empfangene
> >packets verworfen werden, was ich für wahrscheinlicher halte.
> >
> Warum "(ggf. mehrfache) Wiederholung seitens des AP"? Der AP sendet ein 
> empfangenes Broadcast-Paket genau einmal wieder aus. Alle anderen STA 
> empfangen nur diesen Broadcast.

"ggfs. mehrfache", weil clients broadcasts nicht ACK´en, einem Verlust durch
Kollision anders also wohl zu begegnen ist, ist aber pure Vermutung.

> >Kann man per tcpdump mehrfach _identische_ UDP-698 packets auf den
> >clients sehen, also nicht auf dem prism0 (MAC-layer) sondern auf dem ethX-
> >interface(!) - auf das der olrsd bindet?
> >
> Weiß ich nicht, kann man effektiv wohl nur mit einem Programm (crc über 
> die Pakete rechnen) herausfinden.

Na ja, "tcpdump -nex -i eth1 -s 0 udp port 698 > logfile" auf einem client
starten, ein so 20 bis 30 Sekunden dauerndes log mitschneiden und dann drin
stöbern, sollte es dafür auch tun.

> BTW, der Trick scheint hier in Wse gut zu funktionieren. Auf der 
> Master-Seite habe ich im olsrd.conf die IP-Adresse des Peer als 
> BC-Adresse eingetragen. Die angezeigten ETX sind besser, so daß die 
> Routen stabiler stehen. Warum sie immer noch wackeln, ist ein anderes 
> Problem.

Hm.  Habe allerdings auch die Beobachtung, daß ein link "besser" wird,
sobald unicast-traffic drüber läuft (gilt insbesondere für ad-hoc); warum
das so ist: ?  Ein bißchen eigene Theorie:

im "alles automatisch"-Modus kann
die Kombi Karten-firmware/Treiber nur eine begrenzte Zahl links/Nachbarn
individuell "verwalten", z.B. optimale bit-Rate, Sende-Energie zur Gegen-
station.  Grade in Szenarien, wo neben einigen nahen nodes auch entferntere
erreicht werden sollen, versagen die Automatiken.  Wird ein connect durch
uni-cast "erzwungen" (so a la: es _gibt_ da eine node mit der IP soundso,
also machen wir mal ARP&Co, keine Antwort bei - mit den nahen Nachbarn gut
funktionierenden - hohen bit-Raten --> also selbige runterschalten, und
schwups, kommen die Packete an...), verbessert sich auch der Transfer von
broadcast-packets, ergo zeigt der olsrd anschließend bessere LQ zu der
entfernten node.

Selbiges stammt natürlich aus dem Umgang mit broadcom-routern, sollte sich
aber auch auf andere Spezies übertragen lassen.  SOHO-orientierte hardware
wird für kurze Funkstrecken und eine dem privaten Umfeld entsprechend kleine
Anzahl nodes (clients) konzipiert.  Die zur Bequemlichkeit des Anwenders ver-
abreichten Automatismen (bit-Rate, tx-power) können nicht auf alle Anwendungs-
fälle hin optimieren, also typischerweise: alle nodes nah beieinander, so
schnell wie´s eben geht.  Reicht die Funkabdeckung dann nicht, sollen die
Anwender eben mehr AP´s oder repeater(würg) kaufen...

Deshalb stelle ich auf Knoten mit Fernlink-Funktion die bit-Raten (rate + mrate)
auf worst-case-best-working, eben fest ein, i.d.R. so 2Mbit.
Auch, weil ich Automatiken, die blackbox-mäßig arbeiten, nicht mag...

Leider ist das Meßverfahren des olsrd viel zu langsam und "zu weit weg" von
wirklich elementaren, individuellen (Treiber-internen) link-Informationen, um 
eine Rückkopplung seinerseits auf bit-Raten etc. liefern zu können.  Darin 
sehe ich die Hauptschwäche unseres Netzes.  Um das routing zu stabilisieren, 
nehme ich dann lieber niedrige bit-Raten in Kauf - vorerst ;-) 

Gruß, marco


_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin