Hallo! Am 2016-04-08 um 20:54 schrieb Matthias Šubik:
Na, dann versuche ich eben, mit langen Texten die Lesefreudigkeit wieder zu senken ;-)Hallo Erich, diesmal ganz und gar nicht demotivierend, weil ich glaub ich kann hier sogar was ergänzen:
Ich sehe schon die Artefakte des 21. Jahrhunderts vor mir: Totems der Communities: gepfählte Kameras, Smartphones und Drucker im Outdoorgehäuse mit OLSR-Mod ;-).On 08.04.2016, at 17:20, Erich N. Pekarek <[email protected]> wrote:…...5. ist der Adhoc-Mode meines Wissens ohnehin nur auf OpenWRT verfügbar,Ad-Hoc findet sich bei einigen Geräten, die auch dezidiert als Client geplant sind. Da die Hersteller hier manchmal ad-hoc von Druckern, Kameras, Smartphones oder Drohnen begegnen, müssen sie das können.
SCNRNein, im Ernst: Smartphones, Tablet und Windows 10 können das. Das Adhoc auf Druckern kann, muss aber nicht, bloß zu Konfigurationszwecken dienen (v.a. Samsung SCX-Serie). Wer einen AP verwendet, wird auch regelmäßig den Drucker derart ins Heimnetz oder Officenetz einbinden.
Man muss sich vergegenwärtigen, dass eine PtP-Verbindung im Medium Luft nicht wirklich PtP ist, sondern der einzelne Kanal ein Shared Medium ist. So gesehen funktioniert beispielsweise die Kollisionserkennung stets auf den Kanal bezogen. Das wäre somit stets ungewollt PtMP. Das Problem ist dabei weniger der Unicast-, sondern der Multicasttraffic - siehe unten....7. Ist der AP-Mode mit Richtantennen die planbarere und effzientere Methode, mit dem Shared Medium umzugehen.Das lasse ich mal dahingestellt, bei einer point-to-point Verbindung ist der Unterschied von akademisch bis riesig, das müsste man mal durchprobieren. ...
Grundsätzlich ist das richtig. RTS/CTS (im Vierwege-Verfahren) funktioniert erst, wenn die konfigurierte Schwelle, also die Größe des zu übertragenden Datenpakets, erreicht oder überschritten ist. AFAIK greift diese Schwelle aber stets nur für Unicast-Traffic. OLSR sendet aber Broadcasts, also Multicasttraffic. Nicht jeder Router kann eine MC/UC-Konversion durchführen (AirOS beispielsweise kann es). An diesem Punkt kommt Adi ins Spiel, der stets und zu Recht fixe Multicastraten für Adhoc verlangt hat: OLSR sendet häufige Multicasts, die unabgesichtert eine erneute Übertragung erfordern. Je nach Rate Control Algorithmus mit verringerten Datenraten. Somit wird weniger Information pro Timeslot übertragen und die TX-Queues können sich füllen. Auf der anderen Seite verringert eine fixe MC-Rate die Reichweite, da andere Adhoc-Geräte nur verlässlich mit dem Linkpartner sprechen können, wenn diese Übertragung bei höherer Datenrate auch unverfälscht empfangen werden kann. An dieser Stelle lautet die Kritik, dass die Router eigentlich die Datenrate selbst je nach Rauschpegel und Signal bestimmen sollten. Leider hatten frühere OpenWRT-Versionen aber genau damit ein Problem: Die TX-Datenraten gingen -vor allem bei Beteiligung von WRTs stets hinunter - mit dem zuvor genannten Problem. Ob das jetzt ein Problem des RCA (Rate Control Algorithmus) oder der Verwendung von CTS-to-self oder RTS/CTS (letztere senden immer mit der niedrigsten Rate nach 802.11 (ohne b/g/n/ac), nämlich 1 Mbit/s, weiß ich nicht. In AirOS würde das Setting "Alternative Data Rate Module" ein ähnliches Verhalten (Regulierung nach Unten statt nach Oben) bewirken. Dieser Modus ist aber nur für problembehaftete Links gedacht. Sinnvoller ist es, die höchstmögliche Datenrate zu benützen, um die TX-Queues möglichst leer zu halten. Eine volle Queue hätte zur Folge, dass Multicast-Traffic ehebaldigst, Unicast-Traffic erst, wenn der Kanal frei ist, gesendet werden kann.(weil Adhoc-Mode ebenso wie Multi-VAP/Client letztlich nur store-n-forward auf ein und demselben Kanal …Wenn ich mich richtig erinnere, haben wir ad-hoc deswegen aufgegeben, weil in point-to-multipoint Szenarios wir immer wieder ein hidden-station-problem haben, und dadurch viele Kollisionen, die im Master-Mode vom Master zumindest beherrscht werden können.
Da bei Erhalt eines CTS-Pakets, so auch bei CTS-to-self (insbesondere bei 802.11b/g-Umgebungen) der Kanal als belegt gilt, kommt es recht bald zu Airtime-Problemen. Stört dann eine Hidden Station dennoch diese Übertragung, kommt es eventuell zum Resend mit (erneut) verringerter Datenrate.
Ein Ausweg daraus wäre gewesen, bei nur einem vorhandenen Linkpartner OLSR auf genau diesen zu limitieren, indem man diesem einen Unicast (=Broadcast an die exakte WLAN-IP des Partners) überträgt. Andere Stationen wären dann zwar im Radio als verbunden angezeigt, aber im OLSR nur in einer Richtung zu sehen (NLQ: ja; LQ: 0). Diese Idee von Markus wurde ausgetestet, brachte aber nur kosmetische Korrekturen beim (vormaligen) Multicasttraffic. Der AP-Mode scheint hier in den meisten Szenarien schlicht stabiler zu laufen.
Dieselbe Problematik existiert auch im AP/Client-Mode-Setup. Der Vorteil gegenüber Adhoc ist aber, dass die Synchronisation der Timeslots nicht dezentral mittels ATIM, sondern vom Master gesteuert mittels DTIM erfolgt. Damit ist schon einmal eines der potentiellen Übersprech-Probleme gelöst. Ein weiterer Vorteil ist, dass man mittels MAC-Filter einzelne Hidden Stations auf demselben Kanal zumindest vom assoziieren abhalten kann - gegen ein CTS von dort, das innerhalb des Empfangsradius auftritt, hilft es aber nicht. Man kann aber auch den Client auf die BSSID (=MAC) des richtigen Linkpartners fixieren, um die korrekte Assoziation zu forcieren. Auch das vermeidet, dass planwidrig ein Client zur Hidden Station wird.
Der Adhoc-Mode hingegen lässt jede Verbindung im derselben BSSID zu, egal, ob diese sinnvoll ist, oder nicht. Da der Modus auch nicht standardisiert ist, sind die Probleme daraus mannigfaltig.
Somit bleibt für die Verwendung von Adhoc nur ein netzpolitisches Argument, nämlich, dass ein "Aussperren" Einzelner nicht möglich ist. Technisch ist die universelle Verbindung mittels Adhoc aus den oben dargelegten Gründen kein Vorteil.
Auf 5GHz wäre es zudem tunlich, mit einer auf die freien Outdoor-Kanäle beschränken Liste und automatischer Kanalwahl zu arbeiten. Dies entspricht der durch DFS und TPC implizierten und für alle Beteiligten verträglichsten Nutzungsart:
Würde ein Radarsignal empfangen oder wäre der Kanal überbelegt, findet ein Wechsel auf einen anderen Kanal statt. Für die meisten Installationen wird dies vorteilhaft sein. Probleme ergeben sich auf größere Distanz, wenn die Fresnel-Zone tw. durch Objekte gestört ist, und die Antenne bauartbedingt auf eine andere Mittenfrequenz hin optimiert ist - dann fällt der relative Antennengewinn auf manchen Kanälen/Frequenzen weniger hoch aus, als spezifiziert wurde.
Im Endeffekt läuft es wieder darauf hinaus, dass man Links auf PtP hin optimieren sollte, u.z. ausschließlich bei absolut freier Sichtlinie - und dazu ist auf PtMP hin entwickelte Adhoc schlicht nicht gedacht.
Der Grundgedanke eines rein auf technischen Kriterien arbeitenden (technokratisch-selbstorganisierten) Netzes ist daher nicht realistisch.
Jein, ein paar Tests wurden schon gemacht: Wenn Probleme aber schon im Indoor-Test auftreten, kann man sich das Rollout sparen. Inzwischen wäre es sinnvoll es erneut zu versuchen, denn Chaos Calmer, wie auch davor Barrier Breaker haben einige schwerwiegende Bugs beseitigt. U.a. DMA-Probleme auf Atheros und ein damit zusammenhängendes Problem, das auf den RCA eingewirkt hat. Zudem hat man die UCI-Konfiguration wegen des ac-Standards verbessert, sodass nun für 2.4 GHz 802.11g der Grundmodus ist, der entweder Legacy-Unterstützung (CTS-to-Self) bietet oder mittels HTxy+/- 802.11n/ac-Unterstützung bietet. für 802.11a/ac ist es ähnlich implementiert, da aber a und g hinsichtlich der Modulationen verwandt sind (nur OFDM statt DSSS) stellt sich die CTS-to-self-Problematik hier nicht (in diesem Ausmaß: mit ac eventuell schon).Da die Umstellung aber auf eine Zeit fällt, als auf 2,4 GHz die hohen Störpegel begonnen haben, wurde ad-hoc auf 5 GHz auch aufgrund der nicht immer vorhandenen Softwareumsetzung nie ausgiebig probiert.
Chaos Calmer ist aber nicht für Geräte konzipiert, die weniger als 4MB Flash und weniger als 16MB (Tendenz: 32MB) RAM haben. Gerade die Komponenten netifd, rpcd und procd beanspruchen auf beispielsweise WRTs einen Gutteil der Ressourcen. Ein Lösungsweg hierfür ist eine geringe Übertaktung, der Einsatz von zram (zram-swapping), sofern es stabil läuft oder die Rückkehr zu rein skript-zentrischer Konfiguration wie in der Vergangenheit unter Verzicht auf die auf dieser Hardware ohnedies entbehrlichen Plug-n-Play-Funktionen und Eventtrigger.
Sollte ich in der Erklärung Fehler gemacht haben, die einer Korrektur bedürfen, möge man bitte darauf hinweisen. Ich hoffe, es ist keine schwerwiegende Fehlannahme enthalten.
Es gibt noch ein paar andere Probleme mit ad-hoc, aber ja, 802.11s wäre sicher auch noch ein Thema auf dem man noch viel ausprobieren könnte.
Sind diese in meinem Text angesprochen, oder meinst Du andere Probleme?Das Interessante an 802.11s ist, dass es ja unterschiedliche Knotentypen mit unterschiedlicher Funktion gibt und, dass es auf Layer 2 arbeitet und, dass man mittels HWMP nicht nur an ein Protokoll gebunden ist. Ein Problem scheint aber die Skalierbarkeit zu sein, wie Harald(?) meinte und in der Wikipedia (ohne Nachweis) angedeutet ist [frei übersetzt von https://en.wikipedia.org/wiki/IEEE_802.11s: "meistens für weniger als 32 Knoten implementiert"].
Siehe auch: http://www.heise.de/ct/artikel/Gemeinsamkeiten-und-Unterschiede-von-WLAN-und-Mesh-Netzen-1899930.html
beste Grüße Matthias
SG Erich
<<attachment: erich.vcf>>
-- Discuss mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/discuss
