[Discuss] Aktuelle Outdoor-Hardware

[Erich N. Pekarek]

Hallo!

Am 2016-04-08 um 20:54 schrieb Matthias Šubik:
> Hallo Erich,
> diesmal ganz und gar nicht demotivierend, weil ich glaub ich kann hier sogar was ergänzen:
Na, dann versuche ich eben, mit langen Texten die Lesefreudigkeit wieder 
zu senken ;-)
>> On 08.04.2016, at 17:20, Erich N. Pekarek <(spam-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.
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 ;-).
SCNR

Nein, 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.
> ...
>> 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.
> ...
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.
>> (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.
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.

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.
>   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.
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).

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
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : erich.vcf
Dateityp    : text/x-vcard
Dateigröße  : 4 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20160409/9cac1eec/attachment.vcf>