Benutzer:Leo

Wechseln zu: Navigation, Suche
< Benutzer:Leo

Leo's Blog

2018 November 05 21:27:03 CETLeo's Blog

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.


2018 April 10 21:24:20 CESTLeo's Blog

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


2018 March 12 22:53:02 CETLeo's Blog

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


2018 March 05 20:59:23 CETLeo's Blog

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.


2018 February 10 21:40:51 CETLeo's Blog

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:

Posten Person
Vorstandsvorsitzender: Rene Borrmann
Finanzvorstand: Martin Garbe
Schriftführer: Lars Kruse
1. Beisitzer: Ralph Oesker
2. Beisitzer: Friedrich Meincke
3. Beisitzer: Philipp Markwardt
4. Beisitzer: Kai-Uwe Eckhardt

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.


2017 November 21 19:48:09 CETLeo's Blog

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.


2017 October 02 21:29:19 CESTLeo's Blog

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.


2017 August 23 22:50:12 CESTLeo's Blog

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.


2017 August 14 23:03:55 CESTLeo's Blog

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


2017 May 15 22:43:03 CESTLeo's Blog

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.


2017 April 03 22:17:14 CESTLeo's Blog

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 HackRF 03.04.2017.jpg


2017 March 27 22:56:31 CESTLeo's Blog

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.


2017 March 07 19:21:33 CETLeo's Blog

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.


2017 February 13 22:20:39 CETLeo's Blog

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


2017 January 23 22:43:06 CETLeo's Blog

Inhaltsverzeichnis

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.


2017 January 16 23:49:44 CETLeo's Blog

Inhaltsverzeichnis

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


2017 January 06 22:43:52 CETLeo's Blog

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.


2017 January 02 23:03:20 CETLeo's Blog

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


2015 November 14 22:25:14 CETLeo's Blog

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.


2016 December 21 22:45:01 CETLeo's Blog

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.


2016 November 14 21:51:24 CETLeo's Blog

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.


2016 October 17 22:31:14 CESTLeo's Blog

Montagstreffen (17.10.2016)


2016 October 10 20:51:28 CESTLeo's Blog

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.


2016 October 03 21:42:54 CESTLeo's Blog

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.


2016 August 26 23:22:23 CESTLeo's Blog

Inhaltsverzeichnis

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.


2016 July 06 22:05:39 CESTLeo's Blog

Inhaltsverzeichnis

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


2016 May 16 20:42:24 CESTLeo's Blog

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.


2016 February 29 20:14:56 CETLeo's Blog

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


2016 February 22 21:38:26 CETLeo's Blog

Montagstreffen (22.02.2016)

In der Fritz-Reuter-Straße gibt es zwei nette Menschen, welche nun einen neuen AP bei sich installiert haben. Erfreulicherweise ist der AP auch schon in Betrieb.

Mehrere Leute haben ausführlich und kreativ über die Kooperation mit der Stadt am Standort Borwinschule diskutiert. Ein Treffen mit der Stadt steht in den nächsten Tagen an.


2016 February 01 06:52:44 CETLeo's Blog

Inhaltsverzeichnis

IPv6 Treffen (31.01.2016)

Auf dem Treffen wurden einerseits konkrete IPv6 Migrationsprobleme (Fehlen des nameservice-Plugins) als auch die Migration zu OLSRv2 besprochen.

Bisher annoncieren wir drei Dienste (DNS, NTP, Gatewayliste) mit dem OLSRv1 nameservice-Plugin. In OLSRv2 gibt es dieses Plugin derzeit nicht. Wie könnte man das Annoncieren der drei Dienste anders realisieren?

Aufgabe 1: DNS

Vorschlag 1: anycast
  • wir definieren eine magische IP, die DNS-Dienste anbietet
  • alle DNS-Server announcieren diese IP als HNA
  • Nachteile:
    • bei Ausfall eines DNS-Servers (bei gleichzeitig fortbestehender HNA-Announcierung) wird die Namensauflösung für die Umgebung unlösbar gestört
Vorschlag 2: magischer IP-Bereich
  • wir definieren einen IP-Bereich der DNS-Server
  • alle DNS-Server werden von uns per Hand verwaltet und announcieren eine IP aus diesem Bereich via HNA
  • ein Skript auf den APs sammelt regelmäßig die routebaren Adressen aus dem magischen IP-Bereich und konfiguriert damit dnsmasq
  • dnsmasq fragt dann alle DNS-Server gleichzeitig
  • Nachteile:
    • manuelle IP-Vergabe im magischen IP-Bereich an die DNS-Server
    • mehrfache DNS-Anfragen
Vorschlag 3: nameservice-Plugin finden/implementieren
  • für OLSRv2 das Plugin implementieren, analog zu OLSRv1

Aufgabe 2: NTP

Lösung 1: ein DNS-Name
  • ein DNS-Name löst auf mehrere IPs auf (mehrere A/AAAA-Einträge), z.B. ntp.on-i.de
Lösung 2: mehrere DNS-Namen
  • jeder Server hat einen Namen mit Nummerierungsschema: ntp1.on-i.de, ...

Aufgabe 3: Gateway-Auswahl

Vorschlag 1: anycast
  • jeder Gateway announciert eine magische Gateway-IP (als HNA)
  • der Nutzer verbindet sich immer mit dieser IP
  • somit wird der routing-technisch naheliegenste Gateway ausgewählt (Kombination aus Route zum UGW-AP und dessen Verbindung zum UGW-Server)
  • keinerlei Konfigurationsmöglichkeiten oder -notwendigkeiten
  • Nachteile:
    • Gateway announciert IP, ist jedoch kaputt -> keine Chance, automatisch einen alternativen Gateway zu wählen
Vorschlag 2: mehrere IPs via DNS ermitteln
  • via DNS erhalten wir mehrere IPs (Liste von UGW Servern)
  • der konkrete Gateway wird zufällig (z.B. openvpn: round-robin ohne Priorität) gewählt
  • Annahme:
    • alle (oder die meisten) Spender bieten Verbindungen zu _allen_ Gateways an
      • andernfalls werden gelegentlich auch Verbindung über den nicht-nächsten Spender aufgebaut
      • seltener Fall - wohl nicht optimierungswürdig
  • wir benötigen keine Überwachung und Auswahl des optimalen Gateways - dies tut der VPN-Client interaktionsfrei (z.B. openvpn)
  • Nachteile:
    • der UGW-AP (also der Anschluss-Spendende) wird via Routing ermittelt und ist nicht konfigurierbar


Gesamtproblem: OLSRv2 Migration

Da unsere IPv6 Implementierung auf OLSRv2 aufsetzt, müssen wir hier auch Voraussetzungen schaffen. Derzeit ist hier noch vieles unklar.

Nach einer längeren und sehr intensiven Diskussion haben wir viele Ansätze gefunden und auch wieder verworfen. Die vielen möglichen Wege werden wir in einem Wiki (mit graphvis Plugin) dokumentieren, um dort weiter zu diskutieren. Da kommt eine spanndende Aufgabe auf uns zu :)


2016 January 04 22:03:38 CETLeo's Blog

Montagstreffen (04.01.2016)

  • Drei NanoBridges (1x neu, 2x gebraucht) hat Jörg zurückgebracht. Die zurückgebrachten APs 1.229 und 1.228 wurde wieder freigegeben in der Node List. Als offene Aufgabe steht noch das Abbauen von AP1.227 vom Kirchturm Kavelstorf an. Er wird nicht mehr gebraucht und dort soll es demnächst Führungen geben.
  • Es besteht Interesse an einem Neujahrsbrunch. Hierzu wurde eine Umfrage per Email gestartet. Vorgeschlagen wurden die letzten drei Sonntage im Januar. Wir wollen dieses Jahr die Diskussionen ein wenig einschränken, da diese im letzten Jahr dazu führten, dass der Brunch nicht stattfand.
  • Kai Uwe hat ein Bug im openwrt/packages repo gefunden. Seit ein paar Tagen kann das sshfs Packet nicht mehr per sourceforge runtergeladen werden. Die neue Location ist github. Als Workaround kann sshfs in opennet/config/common auskommentiert werden.


2015 December 29 22:52:47 CETLeo's Blog

Firmware- und Technik-Treffen (29.12.2015)

Wir haben uns wieder in gemütlicher Runde getroffen und viele Dinge besprochen/diskutiert/umgesetzt:

  • Firmwareentwicklung
    • Ermittlung von Traceroutes von User-APs zu den User Gateway Servern werden zukünftig nur stündlich aktualisiert. Hier gab es Probleme, weil ein kompletter Durchlauf bis zu 10min dauern kann und deshalb außerhalb der normalen Taktung ablaufen muss.
  • Firmware-Builds
    • Der urspüngliche Build Server minato hat noch mysteriöse Probleme. Deshalb wird derzeit ruri als Ersatz genutzt.
    • Download von Firmware Builds auf ruri ermöglicht (http://ruri.on)
  • Infrastruktur Konfiguration:
    • Fehleranfällige Alias-Konfiguration auf dem AP im Vereinsraum umgebaut. Jetzt sind separate Interfaces auch separaten Netze. Damit sollte es keine weiteren Probleme mit dem AP geben.

Es gab eine längere Diskussion über die Zukunft der Firmwareentwicklung. Speziell wurde diskutiert was unsere Firmware und die Gluon-Firmware unterscheidet (abgesehen von den Routing-Protokollen). Da unsere Firmware mittlerweile sehr umfangreich geworden ist, wurden über zukünftige Änderungen, vor allem Vereinfachungen, diskutiert. Diese Vereinfachungen sollen die Wartbarkeit der Firmware in der Zukunft verbessern. Diskutiert wurden:

  • Möglichkeit Gluon als Grundlage zu nutzen. Hierfür müsste OLSR/OpenVPN in Gluon integriert werden. Die Machbarkeit wird Lars prüfen.
  • Umstellung auf OLSRv2 und damit das Entfallen der manuellen UGW-Auswahl. Diese würde ein paar Aspekte der Konfiguration auf UGW-APs und bei der Tunnel-Konfiguration erleichtern.
  • Einführung eines leichtgewichtigen Tunnels zwischen UGW und UGW Server (z.B. ein GRE-Tunnel oder ähnliches). Dieser Tunnel dient lediglich dazu, den UGW Server ins Mesh anzubinden und über seine interne IP erreichbar zu machen. Alle APs (inkl. UGW) können weiterhin VPN Tunnel zu UGWs (interne IP nutzen) aufbauen. Mit dieser Herangehensweise ist ein UGW minimal anders als alle anderen APs. Hier würde keine Portweiterleitung zum UGW Server mehr benötigt werden.
    • Dieser Gedanke ist nicht mit der jetzigen Netzstruktur erstrebenswert, sondern erst wenn wir mit OSLRv2 hoffentlich ein Routing im Netz verwenden, das auch auf Auslastungen/Bandbreiten reagieren kann.


2015 September 20 22:29:35 CESTLeo's Blog

Inhaltsverzeichnis

IPv6-Treffen (20.09.2015)

Wir haben heute zu dritt (Mathias, Martin und Lars) Matthias im Opennet-Raum Gesellschaft geleistet.

Berliner Dinge

  • die Menschen in Berlin haben ihre Umstellung von olsr v1 auf olsr v2 folgendermaßen umgesetzt:
    • IPv6-Verkehr wird via olsr v2 geroutet
    • IPv4-Verkehr bleibt erstmal bei olsr v1 (wird wohl später umgestellt)
  • Desweiteren wird teilweise 802.11s als Mesh Standard genutzt. Dieser Mesh Standard benötigt keine Master/Client Beziehungen im 5GHz Bereich. Dies wäre sehr anstrebenswert für uns, weil dies auch dem ursprünglichen Gedanken eines Mesh Netzes entspricht.
  • Uns scheint eine parallele Infrastruktur (IPv4, IPv6) sehr sinnvoll. Somit können wir möglichst schnell IPv4 ablösen ohne das parallele IPv6 zu beeinflussen.
  • Bei der IPv6 Infrastruktur muss geprüft werden, ob OpenVPN sinnvoll ist.
  • IPv6 Einführung im gesamten Opennet besteht aus
    • Routingprotokoll: Sollten wir OLSRv2 nutzen?
    • Adressverteilung: Wie werden Prefixe verteilt? Über welchen Mechanismus werden IP Adressen reserviert? Wieviel Intelligenz muss auf dem Server oder den APs sein?
    • Schützen des Datenverkehrs: Wie kann der Verkehr zwischen Endnutzer und dem Gateway, welches Verkehr ins Internet leitet, geschützt werden?

Gedanken zur Adressverteilung

  • eventuell lösen wir uns von der IP-Verteilung via OpenVPN (derzeit für alle Internetnutzenden). Generell basiert die IPv6 Adressvergabe auf Multicast. Dies ist in die derzeitige OpenVPN Konfiguration schwer integrierbar. Siehe auch Emailverkehr auf der crew-Mailingliste.
  • Generell sollten wir möglich fertige Tools nutzen und nur an Stellen eingereifen, an denen dies auch vorgesehen wird.
  • Um Informationen im Netz zu annoncieren (z.B. Präfix für Stateless-Auto-Configuration) kann wahrscheinlich das OONF Packet Socket Plugin (http://www.olsr.org/mediawiki/index.php/OONF_Packet_Socket_Plugin) für OLSRv2 genutzt werden.
  • Für zustandsbehaftete Adressbereiche scheint DHCPv6 das richtige zu sein. Hier gibt es an allen Stellen auch fertige implementierungen. Problem: Wie Multicast per OLSR verschicken?
    • DHCPv6 soll auch per Unicast ansprechbar sein, laut RFC: "Once the client has determined the address of a server, it may under some circumstances send messages directly to the server using unicast." http://networksorcery.com/enp/rfc/rfc3315.txt
    • Nutzung von UNICAST Option im DHCPv6 Paket. Damit sollte der Server per Unicast antworten.
    • Aus Server-Seite (ISC dhcpdv6, wide-dhcpv6) und Client-Seite (odhcp) testen.
    • Eine Liste der DHCP Server könnte wiederum per OONF Packet Socket Plugin verbreitet werden.

IP-Bereiche

  • bisher diskustieren wir über zwei bzw. drei Bereiche:
    • permanentes IP-Präfix für jeden Nutzer-AP (kann aus dem Internet heraus angesprochen werden)
    • fluktuierendes IP-Präfix füe jeden Nutzer-AP (reduziert personifizierbare Datenspuren im Internet bei ausgehendem Verkehr)
    • (optional) dauerhaft unveränderliches Präfix für jeden Router aus dem ULA-Bereich


2015 August 31 21:13:51 CESTLeo's Blog

Montagstreffen (31.08.2015)

  • Christian berichtete über den aktuellen Stand der Uni-Kooperation.
  • Martin erzählt ein wenig über die schöne "neue" Welt von IPv6 und was alles zum Schutz der Privatsphäre (gegen Tracken von IPs) gemacht werden kann bzw. für Opennet geplant ist.
  • ... und irgendwas war da noch...
  • Techniktreffen/Firmwaretreffen wäre auch wieder schön. Terminplanung wird per Email rumgehen.


2014 October 10 07:27:25 CESTLeo's Blog

Inhaltsverzeichnis

Techniktreffen (09.10.2014)

Wir haben wieder ein gemütliches und produktives Treffen in der Frieda veranstaltet.


Flash-Schreibzyklen reduzieren

Aktuell wird durch das "on_vpngateway_check"-Skript minütlich die Datei /etc/config/on-openvpn überschrieben. Dies führt nach ca. einem Jahr zu etwa 100k Schreibzyklen - dies entspricht grob der erwarteten Lebensdauer eines Flash-Speichers.

Das Skript schreibt folgende Informationen:

  • das Alter (in Minuten) des letzten VPN-Verbindungstests (Wiederholung im 20-Minuten-Takt)
  • die Entfernung des Gateways (olsrd: ETX-Wert)
  • der Status "blacklisted"
  • das Flag "nutzbar" oder "kaputt"

angestrebtes Ziel heute

  • Alter, Entfernung und Status nur noch in einer Datei im tmpfs speichern (eigenes Format)

erreichtes Ziel heute

Zitat von Lars: "Ist noch nicht getestet aber läuft"


Captive Portal Lösung

Unsere bisherige Lösung wifidog wird nicht weiter von Entwicklern gepflegt. Wir suchen nun ein Lösung, welche schlank ist und unsere Anforderungen erfüllt.

Unsere Anforderungen

benötigte Captive Portal (CP) Funktionen:

  • in regelmäßigen Abständen oder Neubesuch Startseite anzeigen
  •  ?? MAC Adresse sperren
  •  ?? Traffic beschränken

OpenWRT Integration:

  • Es sollte ein bestehendes OpenWRT package geben.
  • Idealerweise ist das package bereits im neuen OpenWRT Package Repository (https://github.com/openwrt/packages). Wenn es nicht darin ist, sollte es so klein/schlank sein, dass es von uns selbst gepflegt werden kann.

Mögliche Lösungen

http://wiki.openwrt.org/doc/howto/wireless.overview#captive.portal.software.available.in.the.openwrt.repository Bewertungskriterien für Lösungen:

  • Erfüllt es unsere obigen CP Anforderungen?
  • Wie einfach ist die Integration in OpenWRT? Von welchen andere Paketen hängt es ab? Sind diese auch im neuen OpenWRT package repo drin?
  • Wie ist die reale oder gefühlte Zukunfsfähigkeit der Lösung?

Lösung 1: nodogsplash

https://github.com/nodogsplash/nodogsplash

  • Scheint sehr minimalistische Lösung zu sein.
  • Abhängigkeiten von anderen Paketen sind auch minimal im Vergleich zu anderen.
  • Auf Github sind pull requests willkommen. Also evtl. zukunftsfähig.

Was wurde heute geschafft (Aktueller Stand)

  • Paket wurde testweise auf AP2.30 installiert
  • Weiterleitung auf Wikiseite wurde konfiguriert
  • Ticket mit Konfigurationsdateien erstellt (https://dev.on-i.de/ticket/65)

Weitere Plan:

  • Paket in Firmware einbauen und testen und damit wifidog hoffentlich ersetzen

Lösung 2: ...

Wird angeschaut, wenn Lösung 1 nicht geht :)


DNS / Service Announcements

Wir haben über mehrere Stunden versucht DNS Announcements über das OLSRD Nameservice Plugin durchzuführen. Letztendlich stellte sich heraus, dass das Nameservice Plugin die "service" Nachrichten parst und validiert. Dies ist aber nur im Quelltext dokumentiert und leider nicht in einer Readme-Datei oder anderen prominenten Stellen.

Ein String nach Format "dns://192.168.10.4:53|udp|dns" ist beispielsweise gültig, solange dies von dem Rechner 192.168.10.4 gesendet wird. Als Präfix ist auch ein Protocol mit "://" nötig.

Weiterer Plan:

  • Auf APs diese DNS Announcements parsen und in die resolv.conf eintragen. Dies in Bash implementieren :(


Internetfreigabe-Knopf

Wir haben intensiv über die VPN Funktion der UGWs geredet. Dabei wurde herausgearbeitet, dass der Internetfreigabeknopf etwas irreführend ist, weil der Nutzer seine Leitung bereits mit anderen hinter ihm liegenden Teilnehmern teilt, sobald er UGW Zertifikate einspielt. Der Knopf aktiviert lediglich die Portweiterleitung und das UGW Announcement.

Der Knopf ist eine gute Idee. Aber mit diesem Knopf sollte auch das Aufbauen des UGW-VPNs verbunden werden. Sodass beim Drücken auf den Knopf drei Dinge passieren sollten:

  • UGW VPN aufbauen
  • Portweiterleitung aktivieren
  • UGW Announcement aktivieren


Zusammenfassung dieses Abends

Es war ein sehr lustiger Abend mit lustigen Leuten. Gefühlt hat Lars sehr viel geschafft. Alle anderen haben sich mit komplexen und schwer durchschaubaren Dingen beschäftigt und letztendlich nur kleine aber wichtige Dinge geschafft :). Alle freuen sich auf das stable Release, welches Lars in naher Zukunft prophezeit. :)


2013 November 04 21:24:18 CETLeo's Blog

Inhaltsverzeichnis

Montagstreffen (04.11.2013)

Bank

  • Wir benötigen folgende Unterlagen:
    • "Satzung" - liegt im Wiki
    • "Protokoll / Mitgliederbeschluss über die aktuelle Satzung" - Liegt bei Jörg
  • "unbeglaubigter Vereinsregisterauszug (nicht älter als zwei Jahre)" - liegt bei Jörg
  • Und dann brauche ich noch eine Liste mit "handelnden Personen".
    • "gesetzlicher Vertreter" - Jörg
  • "Bevollmächtigte" - Christian und Rene

Da benötigte Unterlagen derzeit bei Jörg liegen, warten wir bis er zurück kommt. Das ist voraussichtlich Ende November.

Dann können wir das Konto eröffnen. Dabei sollten wir gleich 2 Karten mitbestellen. Beide können über TAN-Generator genutzt werden. Von allen beteiligten Personen (Jörg, Christian, Rene) wird eine Legitimation dann gebraucht (PostIDENT).

Petri

  • Christian ruft ihn morgen an.

Öffentliche Mitgliederliste

  • Wohnort von Leuten ist durch die Klarnamen-Mitgliederliste ermittelbar.
  • Die Frage stellt sich nach dem Sinn dieser Liste. Wird eine öffentlichen Mitgliederseite benötigt? Welche Vorteile sollte es dabei geben? Es gibt aber Datenschutzprobleme für Personen in dieser Liste. Die bisherige Lösung der Pseudonyme ist eine Möglichkeit, jedoch wird diese Lösung nicht an die Mitglieder kommuniziert. Dies führte dazu, dass Mitglieder sich in dieser Liste öffentlich mit der Adresse wiedergefunden haben. Da keinem Anwesenden ein zwingender Grund zur öffentlichen Pflege dieser Liste einfällt, steht die ausschließlich "geschlossene" Pflege der Liste zur Diskussion.
  • Es gab eine einstimmte Abstimmung der Anwendenden (9 Personen) *gegen* die öffentlichen Pflege der Liste.
  • Es werden jetzt Möglichkeiten gesucht, diese Wikiseite zu löschen/sperren, sodass auch die History nicht zugreifbar ist.

Sonstiges

  • Firmware-Entwicklung
  • "iw survey dump"-Effekte
  • Robert hat ein paar Interessenten in Gehlsdorf


2013 October 28 20:58:50 CETLeo's Blog

Inhaltsverzeichnis

Montagstreffen (28.10.2013)

Bank

  • Wer würde sich die Arbeit machen und bei der Bankumstellung mithelfen?
  • Laut Dt. Bank: Wir benötigen komplett neue Einzugsermächtigung für jeden. Dt Bank hat aber selbst noch nicht auf SEPA umgestellt.
  • Wir müssen an jeden Nutzer eine Mail schicken. Da kommen wir nicht drum herum. Dann können wir eigentlich auch die Bank wechseln.
  • Besser wäre zu andere Bank zu wechseln, welche SEPA anbietet. So haben wir dieses Problem vom Tisch.
  • TODO: Bankkonto bei SKAT Bank anlegen als Verein. Muss man da vor Ort sein. Martin mach mal.
  • Jörg hat Eintragung von Opennet ins Vereinsregister.

Frieda Raum

Jörg hat auf Raumanforderungen für Frieda23 geantwortet. Wir müssen schauen, ob alle Anforderungen erfüllt werden können. Dies könnte z.B. mit der Anzahl der Sicherungskreise sein.

Mau

  • Eine provisorische Lösung hat doch nicht funktioniert.
  • Avila Board wurde gewechselt durch M5. Aber Kopplung fehlt noch.

Firmware

Es wäre schön eine aktuelle Firmwareversion zu haben. Martin möchte Pakete für IPv6 in die Firmware integrieren und benötigt dazu eine aktuelle Firmware.


2013 September 30 21:30:36 CESTLeo's Blog

Inhaltsverzeichnis

Montagstreffen (30.9.2013)

SEPA

  • Es wird geplant eine Erfassung aller AP-Nummern/Zertifikate. Sodass im Anschluss jeder Nutzer ein Zertifikat hat und nicht-zahlende Nutzer später gesperrt werden können.
  • Es muss eine einheitliche Liste mit aktuellen Lastschriften erfasst werden. (Daten aus Bank-Webseite rausziehen)
  • SEPA Brief an alle per Email verschicken. Wenn Nutzer nicht reagieren, dann per Post anschreiben.
  • Bank wechseln? Jetzt wäre die richtige Zeit. Gibt es ein kostenloses Konto irgendwo für Vereine? Bei der jetzige Bank kostenpflichtig 120,-€ im Jahr. Lastenschriften sollten idealerweise kostenlos sein. Kritik: höhe der Bankbeiträge.

Krankenhaus

  • Status (ganz gut)
  • Test, ob Wagenplatz angebunden werden kann
  • Mittwoch wird Besichtigung gemacht

Frieda Treffen

  • Der zuletzt besprochene Stand, innerhalb von Opennet, wurde auf dem Frieda-Treffen kommuniziert.


Meine Werkzeuge
Namensräume

Varianten
Ansichten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge