Benutzer:Leo: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(Notizen zu Opennet Firmwares)
 
Zeile 31: Zeile 31:
 
* gluon Firmware selbst bauen. Kann man da Babel "einfach" aktivieren?
 
* gluon Firmware selbst bauen. Kann man da Babel "einfach" aktivieren?
 
*
 
*
 +
 +
== Opennet Projektideen ==
 +
=== Karte mit historischen Verbindungsdaten ===
 +
Eine Lösung ist die OLSR Daten täglich wegzuschreiben (in Textdateien). Ich glaube das macht Kai-Uwe so. Daher kann er diese historischen Fragen immer beantworten.
 +
 +
Eine ideale Lösung würde die auf der Karte angezeigten Daten einmal täglich archivieren und in einem "Archiv" zur Verfügung stellen über die letzen x Monate.
 +
Das klingt nach einem interessanten Projekt für Javascript Interessierte. Wer hat Lust?
 +
Fragen wären:
 +
- Von wo läd die Karte die Verbindungsdaten (OLSR)?
 +
- Wie können wir diese Daten archivieren?
 +
- Wie können wir einen historischen Datensatz in die Karstenansicht einspielen?
 +
 +
Wer Lust hat sich hier zu engagieren, ist sehr willkommen. Die oben dargestellten Fragen, können wir gern auf einem virtuellen Montagstreffen (oder Mailingliste) durchsprechen.
 +
 +
Auf jeden Fall würde uns diese Funktion viel Arbeit abnehmen und die Supportmöglichkeiten verbessern. Alle Nutzer würden hiervon profitieren.
 +
  
 
==on_map==
 
==on_map==

Aktuelle Version vom 13. November 2020, 20:52 Uhr

Inhaltsverzeichnis

[Bearbeiten] Notizen zu Opennet Firmwares


Beispiel für Inbetriebnahme von Layer3 Firmware:

Fragen:

  • Wo ist Quellecode für L3FirmwareFranken? Basiert diese auf Gluon?
  • Ist Firmware von
  • Wird dies langfristig in Gluon eingehen?

Todo:

  • mit christiand@jabber.community über Layer3 Firmware jabbern
  • Adrian Schmutzler deswegen auch angesprochen
  • gluon Firmware selbst bauen. Kann man da Babel "einfach" aktivieren?

[Bearbeiten] Opennet Projektideen

[Bearbeiten] Karte mit historischen Verbindungsdaten

Eine Lösung ist die OLSR Daten täglich wegzuschreiben (in Textdateien). Ich glaube das macht Kai-Uwe so. Daher kann er diese historischen Fragen immer beantworten.

Eine ideale Lösung würde die auf der Karte angezeigten Daten einmal täglich archivieren und in einem "Archiv" zur Verfügung stellen über die letzen x Monate. Das klingt nach einem interessanten Projekt für Javascript Interessierte. Wer hat Lust? Fragen wären: - Von wo läd die Karte die Verbindungsdaten (OLSR)? - Wie können wir diese Daten archivieren? - Wie können wir einen historischen Datensatz in die Karstenansicht einspielen?

Wer Lust hat sich hier zu engagieren, ist sehr willkommen. Die oben dargestellten Fragen, können wir gern auf einem virtuellen Montagstreffen (oder Mailingliste) durchsprechen.

Auf jeden Fall würde uns diese Funktion viel Arbeit abnehmen und die Supportmöglichkeiten verbessern. Alle Nutzer würden hiervon profitieren.


[Bearbeiten] on_map

TODO

  • Marker auf Karte zeigen können mit Link generieren
  • AP Punkte verschiebbar machen und neue Koordinaten anzeigen
  • Areas markieren mit Klickfähigkeit und Zoom in
  • add https://wiki.openstreetmap.org/wiki/ProxySimplePHP because slow tiles loading from osm servers
  • change to Leaflet ? Do evaluation

[Bearbeiten] IPv6 für Opennet konfigurieren

[Bearbeiten] gai - Server

/etc/network/interfaces

set ipv6 ULA on loopback

iface lo inet6 static
       address fd32:d8d3:87da:0:5054:00ff:fea0:3100
       netmask 64

set ipv6 ULA ending with ::53 for DNS server. Server acts as DNS server. Address will be used for anycast. This solves the problem of getting to know the DNS server in the network. Some kind of first workaround.

auto lo:1
iface lo:1 inet6 static
       address fd32:d8d3:87da::53
       netmask 64


[Bearbeiten] Test ansible roles in vagrant environment

[Bearbeiten] IPSec im Opennet

folgende Installations-Anleitung zeigt, was konfiguriert werden muss, damit IPSec (als Alternative zu OpenVPN) im Opennet genutzt werden kann:

[Bearbeiten] Merker für mich

mesh knoten
mesh-service-bridge
inet-gw , mesh-hub

[Bearbeiten] eth0-bug-loco-xw

[Bearbeiten] Sandbox

[Bearbeiten] 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.
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge