wie gestern Abend besprochen hat die 2. Phase des u23-Projekts begonnes. Ziel ist es, sich mit einem ganz konkreten Aspekt des Freifunk-Netzes auseinander zu setzen.
Ergebnisse sind:
Ein Vortrag (etwa 20min) am 27.11.2014 ab 20:00 Uhr im Chaos Computer Club Cologne.
Eine Software, Installation oder Dokumentation die wir bei Freifunk produktiv einsetzen.
Als Themen schlagen wir diese Fragen vor:
Wie kann das Freifunk-Netz mit dem IC-VPN und anderen Darknets verbunden werden?
Wie können bestimmte Angriffe im Freifunk-Netz erkannt und unterbunden werden?
Wie können wir die Qualität des batman-adv Meshes mit collectd visualisieren?
Wie können wir OpenWRT und die Freifunk-Firmware automatisiert testen?
Wie können wir Störungen in Freifunk-Deployments erkennen und größere Installationen planen?
Wie können wir die vorhanden Nodes nutzen, um Informationen oder Anwendungen (z.B. Chat) dezentral anzubieten?
Dabei sind wir auch für Eure Themenvorschläge offen! Zu jedem Projekt gibt’s einen von uns, der Euch betreut.
Solltet Ihr euer Thema entdeckt haben, startet bitte einen Forums-Thread um Eure Arbeit zu koordinieren.
Punkt 3 würde ich rausnehmen. Collectd nutzt so gut wie keiner und außerdem hat Gluon ja alles drin was diese Daten bereitstellt. Kann also direkt von der Maschine so ausgelesen und verarbeitet werden welche die Visualisierung macht Macht die FF-Map ja auch nicht anders, wobei da noch im Backend nur die wichtigsten Daten aufbereitet werden.
Den Punkt 5 verstehe ich hier in der Liste etwas anders als in dem Slide vom Treffen.
Laut dem Slide geht es um WLAN-Skalierung/Debugging, hier hört es sich eher nach dem Skalieren und zentralen Deployen von Installationen an?
Kann jemand kurz erklären, was man sich unter dem Punkt 5 vorzustellen hat?
Sorry - mein Fehler. Ich hab’ versucht den Punkt als Frage zu formulieren - dabei war ich etwas frei im umformulieren. Eigentlich wollte ich es damit einfacher machen :-/. Ich dachte:
WLAN skalieren <=> Größere Installationen planen.
Störungen erkennen <=> Debugging.
Die Idee ist, ein Setup als Beispiel zu nehmen um Störungen zu erkennen (Abweichung: Soll - / Ist Qualität) und dabei auf Setups zu blicken, die größer sind als 2 Geräte (Notebook + FF-Router; d-h. komplettes Haus, Straße, FrOSCon, Hackerspace, etc.).
Hierzu sollte man eine Vorstellung haben, welche „Ist-Qualität“ erreicht werden sollte.
Der Fokus liegt dabei auf WLAN, d.h. es interessiert nicht, wie viele Geräte bspw. batman-adv oder ein Internet-Uplink vertragen kann.
Hefitigeres: Beispiel: Wir planen die FrOSCon
Es steht je ein 2.4Ghz und 5 Ghz Kanal zur Verfügung
Es gibt viele Workshopräume (10 - 50 Teilnehmer), die kaum mit WLAN versorgt sind
Es gibt einen Ausstellungsbereich, indem Passenten das Netz testen.
Dabei gibt es jede Menge fragen, die man beantworten könnte…
Wie viele Geräte braucht man? Wo sollen sie stehen?
Wie kann während der Veranstaltung festestellen, wie gut das Netz funktioniert?
Was sollte ich tun, wenn ich vers. Probleme erkenne? (Zu viele Clients pro Node. Node stören sich?)
Welche Geräte kann ich noch einsetzen, um die Situation zu verbessern? (Sektorantennen, Ethernet-Kabel)
An welchen Geräten sollte man Meshing abschalten?
Wo machen Richtfunkstrecken statt Meshing sinn?
Besseres Beispiel:
Du planst Dein Deployment.
Da ich nicht weiß, wie das aussieht, kann ich dazu nur wenig sagen
Ich hoffe, es wird nun ein wenig klarer.
Gruß, Jan Lühr
Es gibt viele Optionen - das ist wohl eine Aufgabe mit der meisten Freiheiten. Ein Deployment finden wir schon (C4, Möhnesee, u.ä.) Ich kann mir vorstellen:
Ein neues Deployment aufbauen und testen. Die Präsentation wären Fotos + Messergebnisse
Ein vorhandenes Deployment (z.B. C4) testen und mit den Parametern spielen. (Stören sich die Accesspoinsts? Haben wir zu viele oder zu wenig?)
Ein bestimmtes Problem in Freifunk-Deployments (airtime nur knapp, Störungen auf dem Kanal) vorstellen und Tools zum messen zeigen.
Evtl. macht es auch Sinn, auf dem Node Software zu installieren um die airtime + Signal-Noise-Ration zu messen und zu plotten. Wenn Du gerne etwas Coden willst, kannst Du Dir auch übrelegen, Messergebnisse (bspw. aus horst) auf dem Node offen abrufbar hinzustellen.
Z…B eine Art „Node-Radar“, dass zeigt, welche anderen Nodes es in Funkreichweite gibt und wie gut die Verbindung ist…
Man könnte auch mal plotten, wie in der Praxis folgende (jetzt schon gut zentral gut erfassbare) Werte (da schon in diversen Reportings vorhanden) zu einander verhalten bei einem Mesh:
Empfangsfeldstärke (dB)
Linkspeed (Tx/Rx getrennt!)
Schätzungung vom BatmanAdv zum Link (anhand von Packetloss ermittelt)
Meine Vermutung: Man kann mit Airtime und Kanalbelegungen viel herumorakeln, der vom Batman als Berechnung zurgrundgelegte Packetloss ermittelt aus Pings im Adhoc-Mesh ist bereits perfekt, weil es genau das misst, was man hinterher braucht.
Und das auch als Grundlage zur Selbstoptimierung zu nutzen.
@adorfer: Wenn Du nur die batman-adv Link-Quality zu Grunde nimmst, kannst Du wenig darüber sagen, ob die Hop Penalty einen sinnvollen Wert hat.
Airtime kann Dir helfen herauszufinden, wie viel Zeit das Netz bei der Übertragung mit broadcast-Traffic verbringt. Das hilft eine Aussage zur mcast-Rate zu treffen. Hierbei siehst Du, wie viele „Zeit“ im Äther für broadcast-Traffic verbraucht wird.
Über die Qualität im Infrastruktur-Netz weiß batman-adv auch wenig. Hier interessieren bspw. eher Datenraten zu den einzelnen Clients und die Wahrscheinlichkeit eines Retransmitts.
Long story short: Das Thema ist sehr vielfältig. Die batman-adv LQ ist nicht die letzte Antwort.
Ich fände es in jedem Fall toll, wenn mal Feldforschung zu dem Thema betrieben wird und dabei etwas herauskommen würde, was man als Leitfibel für Freifunker herausgeben könnte.
Also „Was kann man am Netz tun, wen xy. Und was wenn z“.
Oder auch „wenn ich eine neue Community plane und vorher schauen kann, wie die Funkbänder derzeit genutzt werden“ (an welchen repräsentativen Orten?) wie treffe ich dann die Wahl für einen Kanal?
Leider glaube ich nicht, dass eine Leitfibel als u23-Projektergebnis realisitisch ist. Dafür ist das Thema zum umfangreich. Realistischer ist, IMHO ein konkretes Beispiel (Deployment, technisches Problem, usw.) aufzugreifen und zu untersuchen…
Die Wahl des Funkkanals bietet wenig / kaum möglichkeit zur Optimierung: Man muss einen Kanal wählen - der passt dann irgendwo nicht - egal was Du wählst.
Interessanter ist imho eher, wie man damit umgehen kann, wenn der Kanal belegt ist oder es Störungen gibt. (Störung lokalisieren, quantifizieren, workarounds (Antennen, 5 Ghz, usw.). Ich siimme Rougu hier ohne Einschränkung zu. Siehe auch: http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/2014-July/002439.html
Macht die FF-Map ja auch nicht anders, wobei da noch im Backend nur die wichtigsten Daten aufbereitet werden.