Benutzer:Leo

Für weitere News besuche die Seite https://stadtgestalten.org/opennet/

Opennet Montagstreffen (09.11.2020)

Eine Zusammenfassung des Montagtreffens findet ihr unter https://stadtgestalten.org/opennet/opennet-montagstreffen-09112020/

Opennet-Montagstreffen am 26.10.2020

Eine Zusammenfassung des Montagstreffens findet ihr auf dem Stadtgestalten Portal unter https://stadtgestalten.org/opennet/opennet-montagstreffen-am-26102020/

Wir wollen mittelfristig dieses MediaWiki-Blog ablösen und stattdessen die Blog-Funktion von stadtgestalten.org nutzen. Deshalb findet ihr oben nur den Blog-Artikel verlinkt.

Opennet Montagstreffen - Zukunft/Entwicklung von Opennet - (12.10.2020)

Es ist zu beobachten, dass die Menge der aktiven Mitglieder über die Zeit sich immer weiter verringert hat. Dadurch haben wir an vielen Stellen offene Baustelle, siehe hierzu auch https://wiki.opennet-initiative.de/wiki/Benutzer:Leo/Blog:2020_October_13_14:31:37_CEST.

Heute wollen wir mögliche Wege in die Zukunft diskutieren. Prinzipiell müssen wir uns dem Fakt von weniger aktiven Personen anpassen und entsprechend unsere Landschaft und Aufgaben umstellen.

• Ronny hat darauf hingewiesen, dass mehr als 10MBit/s für Enduser teilweise notwendig sind. Konkret geht es um eine Kleingartenanlage. Hier bringen 40-MHz-breite Kanäle einen großen Mehrwert gegenüber den 20-MHz-Kanälen. Wir sollten versuchen mehr 40 MHz zu nutzen, wenn an an den jeweiligen Standorten möglich ist. Bisher hatten wir dies nicht weiter in Betracht gezogen, weil es bei 40-MHz-Kanälen mehr Störung durch Radar gibt, als bei 20-MHz-Kanälen.
• Es wurde auch nochmals über 5 GHz und deren rechtlichen Rahmenbedingungen diskutiert. Auf der crew Mailingliste gab es hierzu auch eine längere Diskussion.
• Der Verein Opennet wird zu sehr als kommerzieller ISP wahrgenommen. Dies ist sehr unbefriedigend für die Aktiven. In der Anfangszeit von Opennet gab es den Gedanken an internet-technisch schlecht erreichbaren Orten Opennet zu bringen. Derzeit gibt es in vielen Gebieten jedoch "schnelles" Internet (z.B. per DSL). Ist an diesen Stellen noch Opennet nötig? In der Diskussion kristallisiert sich heraus, dass ein starkes Bedürfnis vorhanden ist, in einer zukünftigen Ausrichtung des Vereins sich gegen "normale" Internet-ISPs mehr abzugrenzen. Eventuell sollten wir uns wieder mehr auf den Anfangsgedanken konzentrieren und Gebiete ohne DSL & co versorgen. Hier laufen wir auch nicht Gefahr mit einem ISP verglichen zu werden.
• Der Aufwand für die Vorbereitung (Flashen + Konfigurieren) eines APs ist zu hoch. Es gibt zu viele manuelle Schritte. Dies muss grundlegend geändert werden. Eine Idee wäre mehr in Richtung Gluon zu gehen.
• Aufgeworfene Frage: Warum nutzen wir nicht immer die gleiche SSID auch im 5-GHz-Bereich? Kennt jemand den Grund hierfür? Dies wäre sehr charmant für die Firmwarekonfiguration, weil hier keinerlei SSID-Auswahl mehr nötig wäre. Wäre es möglich eine einheitliche SSID für Endnutzer auszustrahlen? Für User wäre das auch von Vorteil, weil bei Störungen mit einem AP automatisch auf andere erreichbare APs gewechselt wird.
• Der Verein konzentriert sich derzeit primär auf das WLAN Netz. In den Anfangszeiten des Vereins war WLAN neu und man konnte neue Personen für WLAN und den Verein begeistern (Bsp. Aktion Antennen Shootout). Um attraktiver für andere Personen zu sein, sollten wir auch Dinge neben dem normalen WLAN machen. Wir suchen neue Anwendungsgebiete hierzu. Ein Beispiel wäre LoraWan. Weitere werden gesucht.
  • Idee (im Anschluss das Meeting entstanden): Sensoren für Luftqualität im Stadtbereich verteilen?
• Eine Beobachtung der letzten Jahre ist, dass das Montagstreffen größtenteils aus Nutzerbetreuung bestand. Es war zu beobachten, dass einzelne Personen für wenige Jahre (1-3y) Lust auf Nutzerbetreuung hatten, aber danach dies eher als Belastung wahrgenommen wurde. Leider haben diese technisch versierten Personen dann das Montagstreffen gemieden und somit fehlte das soziale und kreative Miteinander zwischen technisch versierten Personen.
• Einstieg in technische Themen wird von einigen Mitgliedern eher als Problem/hohe Hürde gesehen. Wie kann man technisch gewillte Personen besser identifizieren und fördern?
• Als Vergleich zu den Entwicklungen der Freifunkvereine wurde der Amateurfunk genannt. Ketzerisch dargestellt, haben die Funkamateure seit langem ein Nachwuchsproblem und deshalb sind die Amateurfunkvereine meist im Altersdurchschnitt eher über 50 bzw. 60. Diese Entwicklung wollen wir nicht auch vollziehen. Aber was müssen wir dafür tun?
• Die Sichtbarkeit nach außen sollte verbessert werden, wenn wir mehr aktive Mitglieder werben wollen. Der Hackspace macht bspw. Veranstaltungen für die Öffentlichkeit. Damals hat dies der Opennet Verein auch gemacht. Dies ist derzeit jedoch eingeschlafen.
• Als Gedankenexperiment wurde die Frage gestellt, was passieren würde, wenn der Verein auf 50 Personen schrumpft und wir uns dem Hackspace anschließen. Was würde sich ändern? Würde es dadurch weniger Aktive geben? Hätten die Aktiven mehr Spaß und Zeit zum Ausprobieren?
• Können wir uns viele verschiedene Webdienste noch leisten selbst zu betreiben? Haben wir die menschlichen Ressourcen dazu? Derzeit sieht es nicht so aus (siehe auch https://wiki.opennet-initiative.de/wiki/Benutzer:Leo/Blog:2020_October_13_14:31:37_CEST) Wir sollten in Zukunft mehr darauf achten, bestehende Dienste zu nutzen. Wenn man die Entwicklung der aktiven Mitglieder betrachtet, müssen wir uns dem anpassen und entsprechend unsere Softwaresysteme daraus ausrichten. Also eher Dienste auslagern bzw. von naheliegenden Vereinen (z.B. Hackspace, Freifunk) nutzen und nicht alles selber hosten.
• Die eigene Firmwareentwicklung können wir in der bestehenden Art und Weise (direkt OpenWRT anpassen) auch nicht weiter betreiben. Wir haben zu wenig Personal, welches sich aktiv in die Firmwareentwicklung einbringt. Daher ist hier die Frage auf welche Systeme/Firmwares von anderen wir zurückgreifen können und dies nur noch anpassen. Hier ist Gluon ein lohnenswerter Kandidat. Die Gluon Firmware wird aktiv weiter entwickelt. Viele unserer Aufgaben sind in Gluon auch implementiert. Für Gluon gibt es derzeit auch eine Babel-Entwicklung, damit Layer3 Netze unterstützt werden (https://l3-freifunk.readthedocs.io/de/latest/) . Dies schauen wir uns derzeit aktiv an. Im Idealfall können wir Gluon anpassen, um somit von deren Entwicklung zu profitieren. Dies ist mehr oder weniger der einzig gangbare Weg, da es zu wenig Firmware-Leute bei uns gibt.
• Monitoring: Es gibt den Wunsch nach "aktivem" Monitoring (d. h. mit Alarmierung). Man möchte informiert werden, wenn bestimmte Zustände sich unerwünscht geändert haben (z. B. Benachrichtigung per E-Mail wenn bestimmter Backbone-Link über längere Zeit ausfällt). Zufällig setzt Oyla gerade ein Icinga2 auf. Er wird zu einem späteren Zeitpunkt berichten.

Diskussionsgrundlage - Opennet - Aktueller Stand, Probleme, Zukunft (11.10.2020)

Wir wollen eine Diskussion über den aktuellen Zustand und die Zukunft des Verein anregen. Hierfür ist es notwendig, sich über den aktuellen Zustand im klaren zu werden.

Im Folgenden haben wir versucht eine kleine Bestandsaufnahme einiger Themen im Opennet Verein zu machen. Diese Liste ist nicht vollständig. Sie ist lediglich als später Diskussionsleitfaden zu sehen.

Allgemeine Themen

Thema: Ausrichtung des Vereins

• Ziel: Förderung freier und offener Kommunikationsinfrastrukturen
• oft jedoch als ISP wahrgenommen
• durch Mitgliedsbeiträge sind die Einnahmen gesichert
• neue Themengebiete ermöglichen? z.B. LoraWan?
• Motivation von aktiven Personen beruht auf:
  • soziale Aspekte (Personen im Verein)
  • Arbeiten mit interessanter Technik/Geräte
  • interessante Tätigkeiten (z.B. Dachinstallationen)
  • starke Motivation in 2015 beim Thema "Unterkünfte von Schutzsuchenenden"

Thema: Neue (aktive) Mitglieder

• Sehr wenige neue aktive Mitglieder
• Einstieg erleichtern?
• Kontakt mit Vereinsmitgliedern
• Sichtbarkeit nach außen

Technische Themen

Thema: Firmware

Probleme:

• das Einrichten eines APs dauert sehr lange
• das Einrichten ist fehleranfällig weil es viele manuelle Schritte gibt
• unsere Firmware ist ein Unikat und damit ist Einarbeitung sehr schwer und sie ist schlecht gepflegt
• geringe Internetbandbreite für den Nutzer /ggf. Integration von WireGuard?

Positiv:

• wir haben volle Kontrolle über Features (Software/Hardware)
• Design mit User-Zertifikaten erlaubt maximale Sicherheit (und Schutz der Privatsphäre) auf dem Transportweg
• Durch Layer3 Routing hatten wir nie die Probleme, welche andere Vereine mit Layer2 Netzwerk hatten

Thema: Web-Dienste

Wiki:

• aus historischen Gründen ist das Wiki stark indivualisiert derzeit (durch selbst entwickelte Plugins)
• MediaWiki ist veraltet (derzeit Version 1.20.6 (von 2015))
• Mathias hatte angefangen es zu updaten aber auf Grund von vielen Besonderheiten (Plugins) und fehlender Unterstützung ging es hier nicht weiter

Build Umgebung:

• git: läuft problemlos und hat keine Probleme
• trac: aktuell ist v0.12.5 installiert (aus 2012) - ist veraltet
• bitten: ist auch auf dem Stand von 2012

API:

• läuft relativ problemlos
• ist komplett Eigenentwicklung

Karte:

• Wir haben eine alte und eine neue Karte. Die neue Karte wurde im Zuge der neuen API Version eingeführt.
• Die Migration auf die neue Karte wurde leider nie vollendet.
• Kritik an neuer und alter Karte???

Email:

• Mailverteiler funktioniert problemlos
• Email allgemein funktioniert

Monitoring:

• Wir haben Monitoring. Das ist schon mal gut.
• einfaches System zum Aktivieren (durch Installation von Modul)
• derzeit werden nur Graphen erstellt. Kein (automatisiertes) Reagieren auf Ereignisse möglich/implementiert.

Thema: Weitere Dienste

• Zertifikatsverwaltung: läuft stabil und ist gut automatisiert
• Mitgliederverwaltung: läuft stabil und ist relativ gut automatisiert
• Finanzverwaltung: läuft stabil

Thema: Server

• wir betreiben eigene Server für diverse Dienste. Dies ist gut so.
• Server sind i.d.R. gut gepflegt / geupdated. Es gibt wenige Ausnahmen.
• Viel automatisiert per ansible.
• hog: DEV + DNS sollte man trennen

Thema: Antennenstandorte

• Wir habe sehr gute Standorte auf den Dächern der Stadt (nicht nur Rostock).
• Kooperation mit der Stadt HRO und Uni. Dadurch u.a. Möglichkeit der Nutzung von LWL Strecken.

Opennet Techniktreffen (04.05.2020)

Wir haben uns heute in einem Online-Meeting zusammengefunden um über technische Dinge für Opennet zu sprechen. Als Plattform haben wir meet.in-berlin.de (Jitsi Meet) genutzt, welches dankenswerterweise von Individual Network Berlin e.V. betrieben wird. Besprochen wurden folgende Themen:

• Auf der Z10 müssen defekte Access Points ausgetauscht werden. Es wird diskutiert, wie dies am Besten geschieht.
• Kai-Uwe hatte per Email eine Ubiquiti NanoStation AC (als Master) als Austauschgerät vorgeschlagen, um Erfahrung mit dem Gerät zu sammeln
• Martin würde gern eine MikroTik RouterBoard mANTBox 15s nutzen
• beide Geräte von oben haben nur Halterungen, um an vertikalen Masten montiert zu werden
• für einen horizontalen Masten benötigen wir "90 Grad Adapter". Möglich wäre bspw. mit einer Mastverlängerung von Meconet. Martin wird dies bestellen und testen.
• Till hat über Erfahrungen mit der Polarisation von Access Points berichtet
• Die DFS Problematik wurde auch angesprochen. Da dort eine hohe Dichte an WLAN Geräten zu finden ist, stören sich diese gegenseitig und es werden DFS Impulse erkannt, welche real aber kein Radar sein können. Über mögliche Lösungen und Weiterentwicklungen wurden diskutiert.
• Till hat vorgerechnet, welche Entfernung erreicht werden kann, wenn eine NanoStation M5 mit Standardkonfiguration genutzt wird.
• Wir hatten mehrere Teilnehmer mit IPv6 Anschluss. Ein Teilnehmer mit O2 Anschluss hatte von gelegentlichen Verbindungsprobleme über den Tag berichtet. Wir stellten uns die Frage, ob sich zwei Teilnehmer per IPv6 gegenseitig per Ping erreichen können. Als Ergebnis konnte von einem Telekom Anschluss das Endgerät des O2 Anschlusses erfolgreich per Ping erreichen. Umgekehrt (von O2 zu Telekom) kam die ICMP Fehlermeldung "administratively prohibited". Anscheinend setzen unterschiedliche Provider oder Router-Herstellung das Erlauben/Blocken von Pings aus dem Internet unterschiedlich um.
• Jedem Nutzer ist empfohlen seine IPv6 Einstellungen insbesondere am Endgerät zu prüfen und dort passend zu konfigurieren. Bei IPv6 gibt es stets den Ansatz, dass die Router primär für die Weiterleitung von Paketen verantwortlich sind und Maßnahmen zur Sicherheit auf den Endgeräten vorgenommen werden sollten.

Nächstes Treffen ist für kommenden Montag Abend geplant.

Techniktreffen (09.02.2020)

Allgemeines

• eventuell neuer UGW Server in Hamburg. Es besteht wahrscheinlich auch die Möglichkeit dann BGP zu nutzen.
• neuer Schlüsselzugang für Rene
• Aufräumen: Wir hatten bisher noch ein WebDAV Ordner für den Vorstand. Die Daten sind bereits im letzten Jahr ins git übergegangen. Somit wurde jetzt der WebDAV Ordner entsorgt.
• CA: die aktuellen Sub-CA-Zertifikate sind nur noch bis 2023 gültig - wir sollten beginnen uns darauf vorzubereiten

Routing-Protokoll

• die Intensität der olsr-Entwicklung (olsr1 und olsr2) ist aktuell eher gering
• olsr1 ist aktuell end-of-life (der aktuelle Maintainer hat angekündigt, keine weitere Pflege zu betreiben)
• olsr2 wird nur mit wenig Intensität weiterentwickelt (drei Commits im letzten Halbjahr; davor gab es deutlich mehr Aktivität)
• babel könnte vielleicht eine langfristige Alternative sein - vorerst hoffen wir aber auf neuen Schwung im olsr-Ökosystem

Firmware

• alle aktuellen Geräte sollten mittlerweile durch unsere unstable Firmware unterstützt werden. Lediglich bei 32MB Geräte gibt es Probleme. Hier muss eine alte Firmware genutzt werden.
• es gibt keine "größeren" bekannten Bugs
• die Firmware basiert dann auf OpenWrt 19.07.1 (erschienen am 31. Januar 2020)

IPv6

• wir haben das Problem der Adressverteilung für APs mit Internetzugang diskutiert
• bisher war unser Verständnisproblem, dass die DHCPv6-PD lediglich Subnetze verteilt, jedoch anschließend nicht weiß, welcher AP welches Subnetz erhalten hat
• somit konnten wir uns nicht vorstellen, wie Antwortpakete von gai aus ihren Weg zu einem Internet-Nutzer hinter einem AP finden sollten
• Lösung: NDP-Proxy
  • der AP würde dann auch auf Neighbour Solicitation Anfragen positiv antworten, für die er nicht direkt, sondern für die ein Client in seinem LAN verantwortlich ist
  • dies löst unser DHCPv6-PD-Problem
  • Voraussetzungen:
    • • Layer3-Netzwerk zwischen AP und gai (z.B. ein tap-Netzwerk mit OpenVPN, oder tinc oder wireguard mit einem tap-Tunnel (GRETAP))
      • Martin wird dies ausprobieren (wahrscheinlich mit einem weiteren OpenVPN-Interface via tap basierend auf den Nutzer-Schlüsseln)

Ein beispielhafter Netzaufbau ist folgender:

Montagstreffen (28.11.2019)

Wir haben eine Teststrecke mit Ubnt loco ac Geräten zwischen Z10 und AE22 (Abstand ca 1 km). Unsere Firmware ist auf beiden Geräten installiert und entspricht dem OpenWRT 19.07 branch. Leider stellt sich heraus, dass es hier noch Bugs im WLAN Treiber (ath10k-qca988x-ct) gibt. Sobald das wlan0 Interface die Verbindung zur Gegenstelle verliert, weil bspw. Radar Event aufgetreten sind, werden von der Gegenseite keine Pakete mehr empfangen. Wir wollen hier ath10k-firmware-qca9888-ct-htt testen und hoffen, dass dieser Bug dort nicht auftritt.

Allgemein macht sich etwas Unmut breit, weil wir bei den 802.11ac Geräten nur noch closed source Wifi Treiber haben. Wenn man hier Zeit und Energie in das Verbessern des Treibers steckt (durch Eröffnen eines Tickets bei einer Drittfirma), dann profitiert nicht mehr Nachhaltig die Allgemeinheit davon. Wir vermissen an dieser Stelle Open Hardware und vor allem eine offene Firmware für 802.11ac WLAN Chips.

Weil die Tests mit der loco-ac ernüchternd waren, werden wir eine parallele Teststellung mit Ubnt NS M5 ac aufbauen. Eine haben wir heute bereits eingerichtet. Johannes wird diese auf der AE22 montieren. Martin wird eine andere auf der Z10 montieren.

Philipp hat heute sein vertieftes Wissen über Layer1 an den Mann gebracht. Es wurde diskutiert von wo aus noch Empfang zur Heiligen-Geist-Kirche möglich sein sollten und wie hoch der Durchsatz sein könnte.

Ausblick: Nächste Woche treffen wir uns, um den Umbau Bauamt zu planen. Wir freuen uns schon jetzt auf diese gemütliche Runde.

Montagstreffen (05.08.2019)

Eine neue potenzielle Nutzerin (Magarethenstr.) hat uns besucht. Sie bringt bereits Erfahrung im FOSS Bereich mit. Daher war die Einarbeitung sehr zügig.

Wir haben gelernt wie man per CLI unter Linux eine Sprachausgabe generieren kann (z.B. mittels 'espeak -vde "hallo"). Dies hat uns sehr viel Freude bereitet :)

Wir haben eine Ubnt loco AC mit unserer Opennet Firmware bestück (jedenfalls fast). Dabei ist aufgefallen, dass die alten schwarzen PoE Netzteile nicht genutzt werden können. Ansonsten bleibt die Ethernet Datendose des APs kommunikationslos. Das ist sehr schade weil wir viele von diesen Netzteilen rumzuliegen haben. [Nachtrag: Funkioniert doch, erfordert aber bei manchen Laptops zusätzliche Einstellungen und wurde nur mit zwei Netzteilen getestet, die einen Reset-Knopf aufweisen. Kai-Uwe]

Montagstreffen (24.06.2019)

• Wir haben über Vorbereitungen für die Hansesail gesprochen. Die APs sind vom letzten Jahr noch montiert. Lediglich die Stromversorgung muss erneuert werden, weil jemand das alte Kabel durchgeschnitten hat. Axel wird hier ein geeignetes Kabel beschaffen. Somit kann die kommende Hansesail auch wieder mit Opennet WLAN stattfinden. Wir müssen noch prüfen, ob das Monitoring Modul auf allen APs aktiviert ist. Somit können wir einfach sehen, wie viel Traffic generiert wurde.
• Per Telefon bekamen wir einen Hilferuf von AP3.7. Martin hat mit dem Nutzer über das Telefon den AP resettet und neu konfiguriert. Und das Beste daran ist, dass es am Ende wieder funktioniert hat.

Techniktreffen (11.05.2019)

Heute waren Tobias, Henning, Lars, Martin und Mathias in der Frieda23 anzutreffen.

60 GHz WLAN Test

Wir haben einen Reichweitentest mit zwei MikroTik RouterBoard Geräten durchgeführt. Bei ca. 250 m Sichtverbindung kamen wir an die Grenze einer zuverlässigen Verbindung. Danach brach die Verbindung immer abrupt ab. Bei 250 m konnten wir noch ca. 90 MBit/s mit iperf messen. Bis 200 m war eine Verbindung mit 900 Mbit/s möglich.

Für den mobilen Knoten konnten wir uns dank eines tragbaren Akkus mit 12 V Ausgang auf der Headgehalbinsel in Rostock frei bewegen.

Server Boot-Analyse

Derzeit können wir unsere Hardware Server nicht neu starten bzw. keine Kernel Aktualisierung durchführen , da etwas in der Kombination von UEFI und grub mit RAID und GPT falsche Konfigurationsdateien erzeugt. Wir haben dies im Detail weiter angeschaut. Es gibt bald einen Bug-Report bei Debian dazu.

Dabei konnten wir mit der IPMI-Schnittstelle via eingebundener virtueller Datenträger alles (inkl. Recovery mittels Debian-Image) aus der Ferne tun. Wir können nun also unbesorgt auch die anderen Virtualisierungsserver (aqua und tamago) mit ein wenig Vorbereitung aus der Ferne rebooten.

Firmware-Upgrade von ryoko

Die Firmware-Aktualisierung auf Basis der DELL Patches des Virtualisierungsservers ryoko schlug leider fehl. Der "Dell Lifecycle Controller" mochte die erkannten Aktualisierung nicht herunterladen. Die referenzierten Dateien lt. Repository Datei lagen nicht an der dort verzeichneten Stellen. Wir haben den Datenverkehr mitgeschnitten. Die Patches der Hardware konnten wir daher zunächst nicht durchführen.

Anschließend haben wir die offiziellen Intel Patches sowie Kernel Updates über Debian erfolgreich eingespielt. Die Performance des Servers ist nun wieder in einem guten Zustand. Entsprechend konnten die VM Ressourcen des Monitoring Servers howmei wieder auf die ursprünglichen Werte zurück gestellt werden.

IPv6 und DNS

Inzwischen ist es möglich, die IPv6 Adressen der Access Points aufzulösen:

dig AAAA 1.23.aps.on
dig -x fd32:d8d3:87da:0:e894:f6ff:fe3f:69de

Dies funktioniert (aufgrund der privaten Domain und des privaten IP-Bereichs) natürlich nur über die Opennet Namensserver.

Die notwendigen Daten (konkret: die Main-IPv6-Adresse) werden seit kurzem von der API eingesammelt. Über einen API-Abruf lassen sich somit fortan Zonen-Dateien erzeugen, die wir in unsere Nameserver einbinden.

Da auf unserem primären Nameserver (heartofgold) leider derzeit noch ein altes Debian-System läuft (der Umstieg ist fast erledigt), steht die Automatisierung (also die nächtliche Aktualisierung) noch aus.

Somit können wir bald die statische Liste für die IPv6 und AP-Zuordnung aus der Firmware entfernen. Technologisch sind wir im Bereich der IPv6-Adressen also nun beim Übergang von statischen Listen zu DNS-Abfragen.

on-dataservice vs. NetJSON

Für die Inventarisierung werden derzeit mit OLSRv1 oder dem HTTP Abruf die on-dataservices Daten der APs eingesammelt. Es stand die Frage im Raum, ob wir diese Eigenentwicklung auf einen Standardmechanismen ändern wollen/können. Hierzu wurde sich NetJSON angeschaut. NetJSON scheint für Konfigurationsmanagement gut verwendbar zu sein. Hier gibt es auch Tools. Für unseren konkreten Fall gibt es jedoch nur wenig Mehrwert. Es gibt bei uns bereits eine JSON Datei, welche als Nachfolge von on-dataservice über OLSRv1 (Nameservice Plugin mit SQLite DB) existiert. Das Format zu ändern und auf einen Standard zu wechseln, hat nur wenig Mehrwert derzeit.

Montagstreffen (06.05.2019)

Tobias benötigt ein User VPN Zertifikat. Vor Ort hat er sich dies erarbeitet und wird den CSR bald senden.

Oyla hat Spaß mit dem HackRF. Ja, er hat auch Radio damit gehört. Er will damit spannende Forschungsdinge machen.

Martin hat eine Varia Liegerung gebracht. Unter anderem waren dabei eine Nanostation AC und eine NanoBeam AC Gen2.

Es Stand die Aussage im Raum, dass mit der Original-Firmware nur gleiche UBNT AirMAX Geräte verbunden werden können aber keine anderen Standard-WLAN Geräte. Diese Vermutung hat sich bestätigt. Die Geräte machen kein Standard-WLAN sondern erlauben nur Verbindungen zur anderen AirMAX Geräten. Daraufhin wurde das Gerät befreit von seinen Zwängen und mit OpenWrt geflasht. Dies lief problemlos. Man kann mit dem AP nun eine 802.11ac Wifi Verbindung aufbauen.

Als nächstes wird die NanoBeam befreit und dann folgt ein Durchsatztest mit 802.11ac. Wir sind gespannt.

Montagstreffen (08.04.2019)

Das heutige Treffen war sehr gut besucht. Folgende Dinge wurden gemacht/diskutiert:

1. Sichtung der Varia Bestellung.
2. Einem Besucher wurde mit seinem AP geholfen
3. Diskussion über den Einsatz unfreier Software/Hardware im Opennet

zu 1.) In der Bestellung fehlen die zwei Switche. Dies ist merkwürdig, weil alles "sofort lieferbar" tituliert wurde. Mit einer vorherigen Lieferung hatten wir schon ähnliche Probleme. Das wird hoffentlich nicht der Normalfall bei Varia.

zu 2.) Ein Besucher hatte Probleme mit seinem AP und wir haben geholfen den AP zu flashen und erneut zu konfigurieren.

zu 3.) Es gab auf der Crew-Mailingliste eine Diskussion über die Nutzung unfreier Software und Hardware im Verein. Es ging hauptsächlich um die zukünftige Ausrichtung des Vereins. Wie sehr sollen unfreie Software und Hardware genutzt werden. Konkrete Beispiele sind:

• Sollen wir im größeren Umfang 802.11ac Geräte einsetzen, welche nicht mit OpenWrt bzw. unserer Firmware kompatibel sind?
• Sollen wir im größeren Umfang Funktechnik einsetzen, welche ein abgewandeltes WLAN nutzen und somit nicht mehr 802.11 standardkonform sind?
• Sollen wir im größeren Umfang proprietäre AP Management Software für unfreie APs einsetzen?

Während der Diskussion gab es unterschiedliche Positionen von "meine Hauptmotivation an Opennet ist Nutzung freier Software/Hardware" bis "es sollte auch unfreie Software/Hardware genutzt werden, wenn wir dadurch einen besseren Durchsatz/Wartbarkeit/Monitoring erzielen können". Allgemein waren sich alle Personen einig, dass freie Soft-/Hardware wichtig ist und wenn verfügbar auch genutzt werden sollte.

Die Diskussion heute im nicht-repräsentativen Kreis ergab, dass

• ein Bedarf an Vergleichbarkeit aktueller 802.11ac Geräten (inkl. unfreier Software/Hardware) mit unserer derzeitigen freien Hardware/Software besteht
• unsere Infrastruktur noch viel Optimierungspotenzial hat, sodass auch schon jetzt mit bestehender Technik besserer Datendurchsatz erreicht werden könnte (z.B. HT40)
• proprietäre AP Management Software vermieden werden sollte, wegen Vendor LockIn

Die Personen vor Ort fragen sich, wie groß der Vorteil von unfreier Hardware/Software in unserem realen Anwendungsfall ist. Im nächsten Schritt sollte diese Frage beantwortet werden.

Opennet Treffen Bau-Planung (17.03.2019)

Es hat sich eine bunte Mischung von Mitglieder (ca. 15 Personen) in der Frieda getroffen um primär über Bauvorhaben dieses Jahres zu sprechen. Neben den Bauvorhaben wurden auch allgemeine Dinge kurz diskutiert.

Im Folgenden sind Stichpunkte dieses Treffens zu finden. Allgemein kann man dieses Treffen als Auftaktveranstaltung eines hoffentlich sehr produktiven Frühlings/Sommers sehen.

Allgemein

• Standortpatenschaften und Dokumentation
  • Menschen die einen Blick auf einen Standort haben und sich als Ansprechpartner fühlen
  • Diese Menschen wissen zumindestens den konkreten Ansprechpartner
• Was wird wo angebunden? Backbone planen :)
• Dokumentation (z.B. Wer strahlt welche SSID aus?)
• AirOS auf allen Geräten durch Opennet Firmware ersetzen, um eine bessere Stabilität zu erreichen
• Ein konkretes technisches Gerät möchte befreit werden
  • Ein Atari wird als Gegenleistung angeboten
• Schnelles Eingreifen bei Notsituationen (Es droht etwas zu fallen) klären
• Versicherungsschutz prüfen
• Wie ist der Zustand von Standorten die bereits offline sind?
  • Vorschlag: Alle zwei Jahre physisch besichtigen und Probleme aufnahmen (z.B. Hängen alle APs richtig oder sind evtl. abgebrochen durch Windlast)
• Welche Geräte können wir denn aktuell überhaupt nutzen?
• Stabilität
  • Phänomene melden!
  • Welche Bugs in welcher Firmware? Es gibt eine Ticketliste (http://dev.opennet-initiative.de/ ). Dies ist aber ein sehr technischer Weg, die DEV und Admin Liste dev@, admin@ ist der einfache Weg

Standorte

• Ziolkowskistraße 10 (Z10)
  • Der bestehende Stromkasten ist zu kleine. Er muss vergrößert werden oder ein zusätzlicher installiert.
  • Zustand der Geräte? Anbindung?
• HG Kirche
  • Dokumetation im Wiki gucken
• Petrikirche
  • Wir haben das Projekt länger anlaufen lassen, irgendwann waren wir drauf und viel Energie rein gesteckt
  • Es hängt dort eine Kamera, aber die wird nicht genutzt, Kommunikation ist merkwürdig
    • Anmerkung Mathias M.: Die Kamera wird verwendet, ist eingebunden und aktiv. Bei Fragen melden sich sich die Ansprechpartner (Gemeinschaftsprojekt: Kirche, Webmenschen, Kameramenschen, Opennetmenschen)
• Bauamt
  • Komplettsanierung nötig.
• AE22
  • Bestandsaufnahme
  • Was ist Funk? Was Glasfaser?
• Philotower
  • Derzeit gibt es dort temporäre Installation weil ein Mast lose ist.
  • Sollzustand unbekannt
• Kraftwerk
• Warnemünde
  • Wer ist hier Ansprechpartner?
    • Anmerkung Mathias M.: Jörg P. und ich
• Kavelsdorf
• MAU
  • Klettern ist hier die größte Herausforderung
  • Eher weniger aufwändig
• Ulmenstraße
• Bunker
• Südstadtklinik
• & Schwerin :)

TODO

• Geräte bestellen
• Halterungen prüfen und neue, stabile kaufen
• Liste von Standorten erstellen (Henning)
• Immer 2 Paten pro Standort finden
  • Z10: Christoph+Martin+...
  • Bauamt: Tobias+oyla+...
  • AE22: Thomas + Christian +
  • ...
• Philotower
  • Reinhard erfragt den Zugang zu einem Wochenende bei der Uni
  • Schrank umziehen, Halterungen Prüfen, Geräte prüfen, Doku, XM durch XW Geräte ersetzen, neue Halterungen
  • POE Switche kaufen
  • Martin unterstützt im Einkauf
• Z10
  • Der Verteilerkasten ist zu klein
  • Martin kümmert sich und stößt Christoph an, damit es voran geht
  • Halterungen müssen erneuert werden
  • Tough Switchport kaputt, dadurch machte ein PoE Passthrough
  • XM Geräte austauschen
  • Sicherung besthender APs
• HG Kirchen
  • AC Gerät soll hinzukommen
  • Chrstian ist iniitiator und schreibt eine Mail für einen konkreten Termin
  • Christian und Reinhard treffen sich mit dem neuen Pastor Krämer
• Bauamt
• Petrikirche
  • Christian schreibt eine Mail an die Crew mit den Informationen dazu
• AE22
  • Christian und Kai-Uwe schreiben eine Mail an die Crew Liste
  • Im letzten Jahr gab es Vorbereitungen, nun muss dies fortgeführt werden
• Bauamt
  • Oyla kümmert sich
  • Ein neuer Kasten

Neuer Termin am 21. Juli 15:30.

Montagstreffen (04.02.2019)

Wir haben über die letzte Mitgliederversammlung gesprochen. Generell haben sich viele gefreut, dass die Remote-Teilnahme sehr gut funktioniert hat. Allgemein haben wir folgende Fragestellungen resultierend aus der Versammlung diskutiert:

• Wie kann man Mitglieder motivieren sich aktiv in den Verein einzubringen?
• Wie können/wollen wir den Verein weiter öffnen?
• Sollte man neuen Personen den Einstieg in den Verein noch weiter vereinfachen, um die Anzahl der Mitglieder zu erhöhen?
• Wie entwickelt sich das Verhältnis von Aktiven zu Passiven, wenn man die Einstiegshürgen verringert?
• Kann man auf der Jahresversammlung einen "besseren" Feedback-Kanal für Remote-User realisieren. Einige Remote-Teilnehmer fühlten ihr Feedback nicht genug in die reale Sitzung wieder gespiegelt.

IPv6 Technik-Treffen (26.01.2019)

Wir trafen uns in gemütlicher Runde. Als erstes wurden die bisher zusammengetragenen Informationen unter IPv6 gesichtet. Danach gab es die Diskussion, in wie weit Multicast Forwarding für uns sinnvoll wäre. Nach diesem Exkurs ging es nochmals zurück zum Anfang und zum großen Ziel:

Frage:

• Was wollen wir und wie wollen wir es machen?

Antwort:

• Wir wollen IPv6 im Opennet einführen.
• Wir wollen dies konstant in kleinen Schritten machen, sodass auch zeitnahe Resultate sichtbar sind. (Dies ist eine Änderung in der Herangehensweise zum letzten Mal im letzten Jahr.)

Was ist der nächste Schritt? Aktuell wird der Opennet Nutzer-VPN-Tunnel per IPv4 aufgebaut. Wir wollen dies jetzt auf IPv6 (ULA-Adressen) ändern.

• damit wird sämtlicher Traffic (IPv4+IPv6) zwischen User-AP und UGW-Server im IPv6 Tunnel transportiert
• damit wird automatisch olsrv2 genutzt, anstatt olsrv1

Manuelles hinzufügen und aktiveren eines Gateway (hier: gai):

 vpn_status add_gw fd32:d8d3:87da::245
 on-function verify_vpn_connection gw_openvpn_fd32_d8d3_87da__245_1600_udp
 on-function find_and_select_best_gateway true

Offene Aufgaben

• Filterung von eingegebenen IPv6-Adressen auf kanonisches Format (Nullen und Doppelpunkte minimieren) - sonst klappt die Suche in der OLSR2-Routen-Liste nicht; siehe "shorten_ipv6_address"
• Ausgabe der Entfernung in vpn_status und im Web-Interface mit mehr Kommastellen falls kleiner Null

Zukunftsschritte

• 1) OLSRD2 auf mindestens einem der UGW-Server aktivieren
• 2) DNS-Eintrag für diesen Dienst erstellen (z.B. "gw.services.on" mit der IPv6-ULA-Adresse des einen UGW; später kommen weitere hinzu)
• 3) Firmware: falls on-olsr2 auf einem Router aktiv ist, dann sollen die Ergebnisse eines DNS-Queries (z.B. "gw.services.on") automatisch in die Liste der verfügbaren Gateway-Server aufgenommen werden
  • aufgrund unserer Berechnung der "distance" (konkret: "1 / path_cost" aus OLSR2) sind die OLSR2-Hosts dabei immer ganz oben in der Liste
  • dies erlaubt ohne Aufwand die parallele Nutzung von VPN-Tunneln via IPv6-Verbindungen, da die Infrastruktur der bisherigen Gateway-Liste wiederverwendet wird (Test auf Erreichbarkeit, VPN-Funktionsfähigkeit, usw.)
  • problematisch ist dies nur für Nutzer, deren IPv6-Wege deutlich länger als ihre IPv4-Wege sind, falls der aktuelle lokale UGW kein olsr2 unterstützt:
    • fließt der Verkehr über einen längeren Weg
    • lenkt den Verkehr somit über seinen Mesh-Tunnel - also zusätzliche Verschlüsselung durch das UGW (was seinen Durchsatz verringert)

Montagstreffen (17.12.2018)

Unser Server erina wurde vom Hoster (webtropia/myLoc) am 13.12. deaktiviert. Dies war ein unschönes Erlebnis. Nach einem Telefonat mit dem Support (heute erst, weil am Wochenenede keine telefonischer Support angebote) wurde der Server erstmal wieder aktiviert. Wir bringen Nachweise, dass wir überwiesen haben und die Gegenseite prüft.

Das Vorgehen von webtropia/myLoc finde ich schon sehr sportlich. Hier die Ereignisse in zeitlicher Einordnung:

• 1.12. Sa - Rechnungseingang
• 3.12. Mo - Wir haben bezahlt
• 7.12. Fr - Erste Mahnung mit Fristsetzung auf 10.12.
• 10.12. Mo - Zweite Mahnung mit Fristsetzung auf 13.12.
• 13.12. Do - Server Deaktivierung
• 17.12. Mo - Telefonat mit Support; Server erstmal wieder aktiviert; Wir haben Zahlungsbeleg als Beweis geschickt
• 21.12 Fr - ...zu prüfen...

Wir hoffen, dass unser Server auch noch nach Freitag online ist. Ich bin gespannt. Wir werden berichten...

Montagstreffen (05.11.2018)

• Arbeitsgruppe "Rettet den Philo-Turm" trifft sich. Es müssen AccessPoints und Halterungen repariert werden. Der aktuelle Forschritt wird im Wiki dokumentiert: https://wiki.opennet-initiative.de/wiki/PhiloTurm#Probleme_der_Installation_.281.11.2018.29 . Thorsten holt den Schlüssel vom Dispatcher, sagt dem Hausmeister Bescheid und versucht möglichst viel zu reparieren.
• Es gibt ein potenzielles Mitglied in der Neubramowstraße. Hier suchen wir jedoch noch andere Mitglieder in der gleichen Straße, welche Opennet weiterverteilen können.
• Wir haben versucht eine neue Ubnt Nanostation M XW mit unserer Firmware zu flashen. Merkwürdigerweise schlägt das TFTP flashen mit "Firmware check failed" fehl. Das muss noch weiter untersucht werden.

Montagstreffen (09.04.2018)

• Martin und Bernd erzählen von ihrer teilweise erfolgreichen Z10 Besichtigung. Es gab zwei defekte APs. Beim AP2.175 war die Halterung abgebrochen. Wir vermuten, dass die Windlast zu groß war und durch die zusätzlichen Abschirmbleche der Druck zu groß wurde. Wir hier die Halterung durch eine neue ersetzt. Der zweite defekte AP1.136 scheint mechanisch noch zu funktionieren, aber rein Datentechnik ist er defekt. Man kommt an das Gerät nicht mehr ran.

• Es wurde ein Ersatzgerät für den AP1.136 konfiguriert (NanoBridge). Dies wird voraussichtlich am Wochenende verbaut.

• Martin und Christian versuchten den korrekten Mechanismus des Fallschutzes zu ergründen. Martin fand die Bedienungsanleitung. https://www.skylotec.com/eu_de/arg-30-g-0030.html

• Kraftwerk: Christian bereitete die NanoBeam für Kraftwerk --> Ressort Hotel vor.

• Thilo und Christian kümmerten sich um Thilos Geräte.

• Es wurden gebrauchte Geräte von ehemaligen Mitgliedern vorbeigebracht. Config ist gelöscht und Geräte liegen im Schrank zur weiteren Nutzung.

Montagstreffen (12.03.2018)

• Heute haben wir wieder festgestellt, dass eine Karte mit ausgestrahlten SSIDs sehr hilfreich wäre. Die wäre nötig, damit beim Montagstreffen den Personen gesagt werden kann, mit welcher SSID sie sich zuhause verbinden sollen.
• Wir konnten Personen aus dem Patriotischer Weg, aus der Friesenstraße und der Ulmenstraße helfen.
• Das Blocken von Netflix (bzw. geblockt werden) wurde auch wieder diskutiert.
• Firmware 0.5.4 Probleme: Kai-Uwe berichtet über seine Beobachtungen mit Verbindungsproblemen, welche nur mit Opennet Firmware 0.5.4 auftreten aber nicht mit 0.5.3. Was hier die Ursache ist, gilt es herauszufinden. Heute traten sie im Vereinsraum aber nicht auf und die gleiche Hardware konnte sich mit mesh und aenderbar verbinden. Beacons dieses Zustandes wurden zur Analyse gesammelt (auf Kanal 48 wurden gemessen: aenderbar -61 dBm, mesh -61 dBm, frieda_nord -81 und MCRWLAN -66).

Montagstreffen (05.02.2018)

• Wir haben einen Bug in der Infrastruktur des Vereinsraum korrigiert. Jetzt funktioniert DHCP + Internet wieder im kabelgebundenen Netz. Vorher ging war nur OLSR dort verfügbar. Ursache für das Problem war ein Kabel ohne Rastnasenhebel, welches nur halb in der Buchse steckte. Das Kabel wurde in einer etwas größeren Kabel ersetzt. Jetzt funktioniert wieder alles.
• Unterlagen für die Vorstandsummeldung wurden vorbereitet und liegen zur Unterschrift im Vereinsraum.

Opennet Jahresversammlung 2018

Am 2. Feb. fand die jährliche Mitgliederversammlung (Protokoll) statt. Die Sitzung begann mit einem Rückblick auf 2017. Erwähnt wurden:

• Bauprojekte
• Radar / Wifi / Firmware
• Tools zur Vereinsverwaltung
• Mitgliederentwicklung

Der alte Vorstand wurde auf der Sitzung entlastet und ein Neuer wurde gewählt. Der neue Vorstand besteht aus:

Am Ende gab es eine Aussicht auf anstehende Projekte, wie z.B.:

• AE22 Kabelerneuerung
• Neuinstallation Borwinschule beenden
• Feeedbacksystem für Ausfall oder Auffälligkeiten im Netz aufbauen
• Hansesail erneut unterstützen
• Vorschlag für Teilnahme an Ehrenamtbörse

Die Sitzung endete um 22:05.

Montagstreffen (20.11.2017)

• Wir haben ein neues Mitglied gewonnen. Aus diesem Anlass haben wir uns intensiver mit unser Satzung und den Ordnungen beschäftigt. Es kamen u.a. folgende Fragen zur Vereinssatzung auf:
  • §3 Abs. 2: "Ist eine sinnvolle Aufstellung am Wohnort des Mitglieds unmöglich oder von diesem nicht gewünscht, bestimmt das Kuratorium den Aufstellungsort. "
    • Wofür war dieser Absatz früher gedacht? Wer ist dieses Kuratorium?
  • §7 Abs. 3a) "Verabschiedung der Leistungsordnung, der Finanzordnung, der Beitragsordnung und der Technikordnung "
    • Was genau sollte diese Technikordnung sein? Wofür was das gedacht?
• Beim Ausfüllen des neuen Online-Mitgliedantrags (http://mitgliedsantrag.on-i.de ) sind kleine Optimierungsmöglichkeiten aufgefallen.

Montagstreffen (02.10.2017)

Für den Standort Borwinschule haben wir heute die konkreten Anforderungen (https://wiki.opennet-initiative.de/wiki/Projekt_HRO/Standorte) weiter entwickelt. Die Stadt kann somit auf diese Anforderungen eingehen bzw. umsetzen. Aus dieser Anforderung soll später ein generelles Template für andere Standorte der Stadt entstehen.

Desweiteren hat Ragnar uns dankenswerterweise seine Nanostation M5 geschenkt, weil es aus Rostock wegziehen wird.

Montagstreffen (21.08.2017)

• Kai-Uwe hat "angefangen" AP1.236 (Radar AP) per TFTP mit neuester Firmware zu flashen. Problem: Der AP schickt per Ethernet OLSR Pakete ist aber noch nicht erreichbar.
• Wir hatten mehrere Leute zu Besuch:
  • Jule und Norbert haben eine Nanostation eingerichtet und mitgenommen
  • Thilo (Philo Turm) hat seit Freitag Probleme
  • Eine Person aus Sievershagen würde gern bei Opennet mitmachen. Derzeit ist er per Provider Arche angebunden weil es kein DSL in diesem Stadtteil gibt.

Montagstreffen (14.08.2017)

• Kai-Uwe konnte den zerflashten Test-AP wieder reaktivieren
  • jetzt mit 0.5.4-2122 geflasht
  • sysupgrade auf 0.5.4-2136 endet in fehlendem Link
  • es war nötig per ethtool die autonegation abzuschalten
• Es waren drei Opennet-interessierten Menschen zu Besuch
  • einem auch Technik-interessierter Menschen wurde beim Flashen und Konfigurieren geholfen
  • einem Weiteren konnten wir die Fritzbox als AP konfigurieren
  • einer dritten Person haben wir einen AP zum Testen am Mühlendamm mitgegeben

Montagstreffen (15.05.2017)

• Wir hatten heute zwei Besucherinen aus der Borwinstr. und Gellertstraße. Ein Gerät für die Gellertstr. wurde final übergeben. In der Borwinstr. müssen noch Informationen eingeholt werden. Eventuell hat einer der Nachbarn sogar jetzt schon Opennet.
• Teile der Radarsplittergruppe waren auf dem Dach und haben Radarimpulse mittels HackRF aus Warnemünde eingefangen und haben davon Aufnahmen angefertigt (10GB für 10min). Nun müssen damit interessante Dinge gemacht werden. Weiterhin soll eine weitere Messungen auf der Z10 durchgeführt werden, weil dort das Radarproblem gehäuft auftritt.

Montagstreffen (03.04.2017)

• Auf der Z10 werden bei ein paar Geräte sehr viele Radar-Events erkannt. Wir wollen dies untersuchen. Da auch ein PoE Switch als Störquelle in Frage kommt, werden wir hier einen Ersatzswitch kaufen und austauschen.
• Die Radarsplittergruppe macht jetzt Hack-RF und analysiert spannende existierende Funksignale.

Montagstreffen (27.03.2017)

• Eine Person aus der Gellertstraße hat die Nanostation zurück gebracht. Leider konnte sie zum jetzigen Zeitpunkt keinerlei Opennet WLAN Netze empfangen.
• Im Verlauf des Abends konnte wir Lothar "überzeugen" wieder einen AP in der Gellertstraße zu platzieren, sodass der Person von oben geholfen werden kann. Wir müssen hier noch zwei Geräte vorbereiten. TODO für das nächste Treffen.
• Lothar hat es geschafft den Drucker mittels Android anzusprechen. Dies haben wir im Wiki dokumentiert.
• Der Entwickler des aktuellen DFS Erkennungsalgorithmus (Zefir Kurtisi) hat sich erfreulicherweise bei uns wegen unserer DFS Untersuchungen gemeldet. Wir sind optimistisch, dass sich dies positiv auf unsere DFS Untersuchungen auswirken wird.
• Der Hack-RF ist angekommen und wurde Sekunden später in Betrieb genommen. Ein erster Radio-FM Empfangstest des lokalen Radiosenders Lohro (www.lohro.de) war erfolreich. Das Gerät wird der "Radarsplittergruppe" bei seinen DFS Untersuchungen sehr behilflich sein.
• Es wurde über Tools der Mitgliederverwaltung gesprochen. Wir wollen die Mitgliederdatenbank mittels MoinMoin realisieren. Als weitere Verbesserung der Mitgliederverwaltung wird es bald ein Onlineformular für neue Mitglieder geben.

Montagstreffen (07.03.2017)

Rostock KTV

Eine Person aus der Gellertstr. (http://www.openstreetmap.org/way/4859481#map=19/54.08951/12.11112) war zu Besuch. Sie möchte gern bei Opennet mitmachen. Derzeit ist noch nicht klar, ob Sie in der Straße auch Opennet empfangen kann. Dies wird Sie jetzt erstmal mit einer M5 testen.

iPerf Test

Philipp und Martin haben iperf Tests gemacht. Die Ursprungsfrage ist: Warum scheint die Anbindung des Hackspace so "langsam". Tests zeigen, dass wir nicht über 10MBit/s hinaus kommen. Nach weiterer Analyse konnten wir den virtuellen UGW in der Frieda als "Ursache" ermitteln. Obwohl alle Leitungen noch potenzial haben (WLAN + Inet Uplink + Server Anbindung) und die CPU auf virt. UGW AP und UGW Server nicht ausgelastet ist, scheint der UGW nicht über 10MBit/s zu kommen. Hier müssen weitere Untersuchen stattfinden.

Montagstreffen (13.02.2017)

• Philipp berichtet wie er in einer nächtlichen Aktion den Bunker-AP neu geflasht und konfiguriert hat.
• Im Vereinsraum kam kein "Internet" aus den Wanddosen. Wir konnten es fixen. Ein Kabel im AP1.50 steckte nur lose drin (Rastnase abgebrochen).
• Es wurde über das Visualisieren des Opennet philosophiert, um Inseln zu sehen und "Single Point of Failure" zu identifizieren. Dabei haben wir uns intensiv die OLSR Routing Daten eines AP angeschaut.
• Die Netflix Problematik (https://help.netflix.com/de/node/277) wurde angesprochen. Anschließend wurde ausführlich erklärt, warum IPv6 hier eine Lösung bringt. Der Weg ist somit klar, er muss nur beschritten werden :) .

Montagstreffen (23.01.2017)

Firmware Migration auf LEDE

• Heute haben wir den lede_migration Branch mit unserem master Branch vereint. Ab heute werden die automatischen Builds auf Grundlage von LEDE gebaut. Damit ist der Wechsel nach LEDE getan.

Jahresversammlung 2017

• Wir suchen derzeit noch Opennet Mitglieder für die Jahresversammlung. Wer Zeit hat, möge sich bitte unter Jahresversammlung 2017 anmelden.
• Es wurde auch über wahrscheinliche Änderungen im Vorstand diskutiert. Nach derzeitigem Stand werden viele bisherige Vorstandsmitglieder keine weitere Amtszeit anstreben.

Vorstand

• Teile des Vorstands haben Kassenbuch und Mitgliederverwaltung gepflegt.

Montagstreffen (16.01.2017)

Opennet Firmware auf x86

• wir haben uns über den alternativen Betrieb unserer Firmware auf den verschiedenen x86 Plattformen unterhalten (KVM/QEMU, VMware, APU Bords, Futuru)

Sendeleistung von Access Points regulieren

• Wir haben über das Konfigurieren der Sendeleistung von APs diskutiert. Es wurde beobachtet, dass die eingestellte Sendeleistung von der realen Leistung abwich. Hier gibt es auch unterschiedliches Verhalten von OpenWrt und AirOS. Dies muss noch weiter untersucht werden.

Radar Messungen

• Wir haben über unsere Beobachtungen zur Radarerkennung auf diversen Geräten gesprochen. Die Frage ist, an welchen Orten zu welchen Zeiten Radar erkannt wird. Aktuell machen wir Messungen hierzu, um ein Gefühl für die Anzahl an unterschiedlichen Orten zu bekommen.
• Unsere Produktivität hat sich in Firmware Patches widergespiegelt. Unter anderem wird unsere Firmware in Zukunft den Kanal 128 (Wetterradar Warnemünde) unter allen Umständen meiden (chanlist in hostapd).
• Insbesondere haben den Abend über Abschnitte des ETSI Standards und die Verweise aus der Allgemeinverfügung der BNetzA auf diese untersucht und versucht schrittweise die derzeitigen Test- und Realkriterien zu finden sowie zu verstehen.

DNS für IPv6

• auch an dieser Stelle geht es voran, wir haben nun ein angepasstes do_dnsupdate.sh für die Busybox Shell und die Vorbereitungen für dynamische DNS Einträge der Loopback-Adressen unserer IPv6 fähigen Access Point Landlandschaft
• wir haben uns daneben noch über das OLSRv2 Routing mit Global und ULA Adressen verständigt sowie die "Single NIC" Anbindung an die Server

Techniktreffen (06.01.2017)

Neue stabile Firmware veröffentlicht (0.5.3)

• Wir haben den aktuellen Stand der Firmware als stable markiert.
• Für die nächste Version müssen wir uns bspw. Probleme bei der UGW Funktion auf CPEs anschauen. Hier verliert das WAN Interface seine IP, sobald ein VPN Tunnel aufgebaut wird.

IPv6

• Wir haben uns darauf geeinigt, dass wir im Kleinen anfangen. Wir werden erstmal Basisfunktionen implementieren und dann weitere Funktionen darauf aufbauen.
• Durch die geänderte Vorgehensweise ist z.B. der IP-Plan erstmal nicht von Bedeutung.
• Aufgabe: Addressvergabe - hier DHCPv6-PD per DHCP-Relay testen.

Montagstreffen (02.01.2017)

Heute haben wir uns vor allem mit der Untersuchung von WLAN Problemen beschäftigt.

Wifi-hang-TX-stop Problem:

• Wir haben derzeit einen Bug in ath9k, welcher das Wifi Interface alle Verbindungen verlieren lässt und keine neuen mehr zulässt. Der TX Counter stagniert in einem solchen Fall.
• Wir haben hier ein Workaround Skript, welches diese Situation erkennt und das Kommando 'wifi' aufruft und somit das Wifi Interface neu startet. Leider scheint es nach einiger Zeit auf einigen APs dann zu einem nicht-funktionierenden Wifi Interface zu führen. Das Interface ist down und kann nicht mehr in den Zustand 'up' gebracht werden.
• Nach einer Untersuchung sind wir beim Start von 'ubus call network reload' im 'wifi' Skript gelandet. Dieses Kommando scheint das Interface nicht mehr richtig zu initialisieren. Ein Test zeigt, dass 'ubus call network restart' das Interface wiederbelebt. Hier werden jedoch alle Interfaces neugestartet.
• Heute geändert: LogBuffer auf 1024 erhöht. Verbose-Level von hostapd von 2 (informational) auf 1 (debug) gesenkt.
• TODO: Warten bis der Fehler wieder auftritt und Meldungen im Syslog zu dem Zeitpunkt des Problemeintritts suchen.

'dropped due to inactivity' Bug:

• bei Renes AP gibt es auch ab und zu Wifi Probleme, welche von Logmeldungen der Art "deauthenticated due to inactivity" begleitet werden.
• Zum Sammeln von Informationen beim nächsten Fehlerfall Daten aus /sys/kernel/debug/ieee80211/phy0/ath9k/ sammeln. Hier z.B. 'ani' und 'queue'.
• Evtl. hat es etwas mit Advanced Noice Immunity zu tun. Das sieht man dann aber in den gesammelten Daten (s. oben).

IPv6 Treffen (14.11.2015)

Beim heutigen IPv6 "Treffen" wurde eine Übersicht der aktuell diskutierten Themen zusammengestellt. Ab jetzt werden unter IPv6 alle Ideen mit den zugehörigen Diskussionsergebnissen festgehalten. Auch verworfene Ideen sollen dort mit einer Begründung festgehalten werden. Ziel ist es, uns und auch anderen bei diesem doch recht komplexen Thema gesammelte Informationen mit Diskussionspunkten und Resultaten zur Verfügung zu stellen.

Auf der Seite sind viele Punkte mit dem Wort Vorschlag markiert. Hintergrund ist, dass viele Punkte noch nicht endgültig diskutiert wurden. Die Vorschläge sind ein Weg viele Punkte umzusetzen. Diese müssen aber noch weiterhin geprüft werden.

Technik/Radar Treffen zur DFS Problematik (21.12.2016)

Die Experimente und Erkenntnisse der letzten Zeit sind nun relativ ausführlich auf der Seite OpenWrt_DFS/Experiment#Technischer_Hintergrund festgehalten. Wir würden gern mit anderen Freifunk Vereinen und Gruppen hierzu ins Gespräch kommen um diese Thematik weiter voranzutreiben und die aktuell unbefriedigende Situation zu verbessern.

Wenn ihr euch für das Thema interessiert und darüber reden wollt, dann schreibt eine E-Mail an dev<ät>opennet-initiative<punkt>de.

Montagstreffen (14.11.2016)

• Ein neuer potenzieller Nutzer (Markus) wurde für das Opennet gewonnen. Der AP wurde gemeinsam eingerichtet und übergeben.
• Bernd hat das Schrankschloss "repariert". Es ist jetzt besser als vorher.
• Wir haben den AP1.187 auf der Z10 remote stromlos gemacht und neugestartet. Der AP legt zum zweiten Mal ein merkwürdiges Verhalten an den Tag. Er ist plötzlich per OLSR nicht mehr erreichbar. Das Gerät läuft aber noch. Nur auf ping antwortet er nicht. Vereinzelt werden noch Pakete vom AP gesendet. Wir beachten das.

Montagstreffen (17.10.2016)

• Heute war es wieder eine größere Runde. Wir hatten u.a. zwei Funkamateure zu Besuch. Hier ergab sich die Gelegenheit für Opennet Mitglieder, welche auch Funkamateure sind, gemeinsam Informationen auszutauschen und Pläne zu schmieden. Es gab einen spannenden Spontanvortrag zu HAMNET im District V von Björn.
• Es kam die Idee auf, von Schwerin nach Rostock mit Hilfe der Funkamateure einen Link zu bauen. Leider ist MV aber doch nicht so flach, wie man immer denkt (siehe Höhenprofil unter http://ham.remote-area.net/linktool/index?F=58&RZ0=db0mvp&RZ1=db0hro&P0B=53.634747&P0L=11.39261&P1B=54.1395&P1L=12.047&H0=45&H1=65&RZ0a=db0mvp&RZ1a=db0hro&Senden=HAMNETDB).
• Einem neuen Mitglied wurde seine Nanostation HP eingerichtet. Jetzt wird erstmal der Empfang getestet.

Montagstreffen (10.10.2016)

Wir haben den Abend in kleiner Runde verbracht und über Geschichte und Philosophie, begleitet von Beethovens Sinfonie Nr. 9, diskutiert. Unter anderem wurde angesprochen, warum der 3.10. (und keiner anderer) der Tag der Deutschen Einheit geworden ist.

Montagstreffen (03.10.2016)

• Philipp hat einem Menschen am Kabutzenhof mit seinem AP geholfen
• Wir haben Informatinen über DAB+ ausgetauscht und diskutiert.
• IPv6 Todos:
  • beantragen von (mind.) /48 Adressbereich
  • Registrierungsmechanismus für IPv6 APs implementieren. Auch Anzeige im Wiki (per API registrieren) umsetzen.
  • nameservice-Plugin Alternative suchen (Martin will das Thema überregional diskutieren. Eventuell kann man hier mit anderen Freifunkvereinen kooperieren.

Opennet Techniktreffen (26.08.2016)

SIP Telefon im Vereinsraum

Das SIP Telefon im Vereinsraum war offline. Eine Fehleranalyse ergab, dass es DHCP Probleme gab. Nach einem Sichten der Verkabelung und logischen Netze, stellt sich AP1.23 als Problem heraus. Hier wurde als Maßnahme DHCP auf dem Mesh-Interface deaktiviert. Der AP hat eine etwas komplexere Konfiguration und einige Besonderheiten, welche Fehleranalysen sehr in die Länge zieht. Hier sollten wir den AP sowie die Switchanbindung zum Hausnetz mit seinen Funktionen vereinfachen. Doku ist auf der AP Wiki Seite. Weitere Details folgen.

Sipgate API

Im Rahmen des Telefonausfalls, gab es die Idee ein Monitoring einzurichten. Ziel ist, bei einem Nichterreichen des Telefons benachrichtigt zu werden. Sipgate bietet drei APIs an. Die Restful-API scheint sehr passend und einfach zu sein. Dort gibt es auch ein "GET /devices" (https://api.sipgate.com/doc/#!/devices/getDevices). Hier bekommt man alle angemeldeten Geräte zurück. Leider wird mit jedem GET nicht nur der Status der Geräte zurückgegeben sondern auch die Zugangsdaten samt Passwort. Dies hat uns überrascht und ist von uns nicht gewollt. Bisher konnten wir keinerlei Weg finden den Status eines Gerätes abzufragen, ohne dass Passwörter immer mitgesendet werden.

Neue stabile Opennet Firmware v0.5.3

Wir arbeiten an der Fertigstellung der nächsten stabilen Firmware. Es wurden noch kleinere Änderungen gemacht. Diese müssen noch getestet werden. Danach steht dem Release nichts mehr im Weg. Sehr erfreuliche Anpassungen haben sich noch ergeben:

• Fehler bei on-monitoring ist identifiziert
• Pakete werden zukünftig nach einem Firmwareupdate automatisch wieder installiert
• in Sachen Analyse der Radar-Erkennung gibt es Fortschritte
• OLSRv2 kommt weiter voran

LEDE

Wir haben eine Prozedur gefunden, um mit unserer Build-Umgebung von OpenWrt auf LEDE zu wechseln. Sobald wir die stabile Opennet Firmware veröffentlcht haben beginnen wir mit dem Umstieg auf LEDE. Dann kommt eine spannende Zeit auf uns zu. Unklar bleibt vor allem, wann es ein stabiles Release geben wird. In Anbetracht der Tatsachen, dass der LEDE trunk ohne Fehler heute kompiliert sind wir ganz zuversichtlich.

Opennet Techniktreffen (06.07.2016)

Durch den Wechsel von OLSRv1 nach OLSRv2 feht uns die Funktionalität des nameservice Plugins (http://www.olsr.org/mediawiki/index.php/Olsrd#Plugins). Bisher wurde von uns das Plugin genutzt, um die Liste der DNS Server und der UGW-Server im Netz zu verbreiten.

Derzeit wird nach einer Alternative gesucht. Im Folgenden werden mögliche Wege aufgezeigt.

Portieren des alten nameservice Plugins auf OLSRv2

Das Portieren des Plugins auf OLSRv2 wurde auf der olsrd Mailingliste diskutiert (https://lists.olsr.org/pipermail/olsr-users/2016-July/006922.html). Es stellt sich heraus, dass dies nicht der optimale Weg ist. Schon die Art und Weise, wie das nameservice-Plugin damals implementiert wurde, scheint von einigen Personen kritisch gesehen zu werden. Der Vorschlag auf der Mailingliste ist, einen Mechanismus ähnlich HNCP (https://tools.ietf.org/html/rfc7788) zu nutzen. Somit ist eine klare Trennung zwischen dem Routingprotokoll und anderen Diensten (hier das Verbreiten von anderweitigen Daten im Netz) gegeben.

Was spricht *für* eine enge Verknüpfnug von nameservice Plugin und OLSRv2 Daemon:

• bestehenden MPR Flooding nutzen
• Nutzung vieler Funktionen des OONF Frameworks (Config Parsing, ....)
• Kein zusätzliches Binary

Was spricht dagegen:

• Dokumentation von OONF ist minimal und dadurch der Weg zur Implementierung an vielen Stellen unklar
• Der Hauptentwickler rät davon ab, das nameservice Plugin an das OLSRv2 Plugin anzuknüpfen

Was wäre theoretisch zu tun, um dies umzusetzen:

• Zusätzlichen Nachrichtentyp definieren (nameservice-Nachricht)
• Eigenes Plugin erstellen mit Kommunikation zum OONF-OLSRv2-Plugin
  • Empfangen: wenn Nachricht vom Typ "nameservice-Nachricht" ankommt:
    • enthaltene Service-Definitionen zu lokaler Service-Datenbank hinzufügen (falls sie noch nicht bekannt war)
      • externes Programm der ONI-Firmware über Änderung der Service-Liste informierten
    • falls Service-Definition schon bekannt war, Aging-Timer zurücksetzen
  • Senden: regelmäßig Service-Definitionen des eigenen APs per MPR-Flooding verteilen
  • periodisch Aging-Zähler der "gelernten" Services dekrementieren, bei Ablauf eines Zähler entsprechenden Eintrag aus lokaler Datenbank löschen und ggf. externes Programm der ONI-Firmware über Änderung der Service-Liste informierten
• Eigene Services (des APs) werden in de OLSRd-Konfigurationsdatei spezifiziert

Home Networking Control Protocol (HNCP)

HNCP (RFC7788) ist ein Protokol/Mechanismus, welcher das automatische Konfigurieren von Geräten im Heimnetzwerk ermöglicht. Es basiert auf DNCP (RFC7787). DNCP ist ein Protokol zum Verteilen und Synchronisieren von Stati im Netz. Es nutzt TLV Strukturen für die Daten und den Trickle Algorithmus sowie Hash Bäume zum Verteilen der Daten im Netz.

Vorteile:

• Es gibt Implementationen dafür: shncp und hnetd

Nachteile:

• Wir benötigen nur einen sehr kleinen Teil von HNCP (Flooding von TLVs).
• HNCP/DNCP macht eigentlich zu viel, denn jeder Knoten merkt sich den Status jedes anderen Knotens im Netz. Das benötigen wir nicht.

Was wäre theoretisch zu tun, um dies umzusetzen:

• Ein Reduzieren und Anpassen von shncpd wäre möglich. Aufgrund seines minimalistischen Umfangs sollte der Zeitaufwand her geringer sein als bei hnetd.

Eigenen Daemon für's Verteilen der Service-Informationen schreiben

Vorteil:

• Wir sind unabhängig vom fremden Codebases, guter Dokumentation bzw. der Unterstützung durch die jeweiligen Entwickler
• Das Programm kann sehr schlank sein

Nachteil:

• Höherer Programmieraufwand
• "Insellösung" (das wäre allerdings ein OLSRv2-Plugin oder ein Hack von shncp/hnetd im Grunde auch)
• wenn wir effizientes Flooding a la MPR wollen, entsteht hoher Implementierungsaufwand, da quasi das halbe OLSR nachgebaut werden müsste

Montagstreffen (16.05.2016)

Störerhaftung

Wir haben uns über die Lockerung der Störerhaftung und deren mögliche Konsequenzen unterhalten. Wir sind sehr gespannt wie der zugehörige Gesetzestext aussehen wird. Derzeit sind wir verhalten optimistisch.

Für Opennet wird sich nicht viel ändern. Wir verfolgen primär das Ziel freie und offene Kommunikationsinfrastrukturen zu fördern. Eventuell wird es durch die Änderung der Störerhaftung mehr offene Hotspots geben. Dies sehen wir sehr positiv. Lesenswert ist hier übrigens der Kommentar von Digitale Gesellschaft e.V. https://digitalegesellschaft.de/2016/05/wlan-koalition-halbe-strecke/ . Neben der Haftungsfreistellung stellen die Unterlassungsansprüche auch noch einen wichtigen Punkt dar. Eine allgemeine Besserung der Hotspot Versorgung wird es nur geben, wenn die Haftungsfreistellung und die Unterlassungsansprüche neu geregelt werden.

Gerätedefekt

Eine Nutzer benötigt einen neuen AP, weil das alte Gerät sich von der Halterung gelocket hat und kopfüber hing. Das Wasser tat sein übriges. Da der Nutzer nur noch einige Monate in Rostock ist, wird Philipp ihm ein Leihgerät geben.

IPv6 / OLSRv2 Techniktreffen (28.02.2016)

Wir haben uns darauf geeinigt, dass wir IPv6 und OLSRv2 gleichzeitig in Abhängigkeit einführen. Damit würden wir IPv4 mit OLSRv1 und IPv6 mit OLSRv2 betreiben. Idealer wäre es OLSRv1 abzulösen, jedoch ist ein Migration der IPv4 Adressen von OLSRv1 zu OLSRv2 sehr komplex und anfällig für Routingsschleifen (siehe dazu auch https://systemausfall.org/wikis/spontanplanung/OLSR1-OLSR2-Migration).

Folgendes haben wir für IPv6 festgelegt:

• Für die Testphase (bis finale IPv6 Adressbereich vorhanden ist) nehmen wir
  • das 2001:67c:1400:2431::/64 für Mesh Geräte.
  • Für Clientnetze können folgende Bereiche genutzt werden: 2001:67c:1400:243X::/64 (wobei X=2..6)
• neuer Knoten generiert sich selbst eine IP (EUI64)
• er meldet sich bei einer zentralen Vergabestellen. Diese Vergabestelle muss neu entworfen werden.
• Vergabestelle registriert DNS Name
  • z.B. streng monoton wachsende Nummer
  • nach manueller Interaktion eventuell sprachfähiger Name
• Knoten erfragt evtl. Client Netz(e) (/64) bei Vergabestelle

• IPv6/OLSRv2 soll per zusätzlicher Pakete auf bestehender aktueller Firmware installierbar gemacht werden

Demnächst zu diskutieren:

• PI Adressen beantragen
• Diskussion über zukünftige VPN-Tunnel-Implementierungen