Bürgernetz Gera-Greiz e.V.

Stellungnahme des Bürgernetz Gera-Greiz e.V. zum abgelehnten Antrag zur Verwendung von Restmitteln

Hier: Einrichtung eines Gemeinschaftsraumes als „Hackspace“

Nachdem federführend durch den Bürgernetz Gera-Greiz e.V. ein Konzept zur Ausstattung und zum Betrieb des Hackspaces erarbeitet wurde, auf dessen Grundlage der Hackspace tragfähig und nachhaltig betrieben werden kann, kam es innerhalb der Lenkungsgruppe 2017 zu keiner Einigung darüber, dafür Projektmittel aufzuwenden. Durch die Freifunk-Community Gera-Greiz wurden daraufhin in Eigeninitiative Räume gesucht, welche für nachhaltig tragbar gehalten wurden und dem Anspruch einen Hackspace zu betreiben, genügen. Die Renovierung ist nun (Mai 2018) nahezu abgeschlossen. Nach Fertigstellung können die Räumlichkeiten mindestens ein Jahr kostenfrei genutzt werden.

Mit dieser fortgeschrittenen, konzeptionierten und räumlich bereits geplanten Variante des Hackspaces wurde der folgende Antrag in der Lenkungsgruppe eingereicht: https://write.ffggrz.de/p/KonzeptRestmittelverwendung_Hackerspace

In diesem Antrag wurde im Wesentlichen darauf verwiesen, dass der Ersatz des Hackspaces (die Vortragsreihe) nicht dem ursprünglichen Konzeptgedanken des Hackspaces entspricht und der Erfolg (bspw. die gewünschte Breitenwirkung in der Öffentlichkeit) nicht der erhoffte ist. Die Stadt Gera als Antragsteller des Projekts sollte jedoch die entsprechenden Punkte der Bewerbung der Stadt Gera mit dem Projekt “Freifunk-Kommune Gera” beim Konzeptauswahlverfahren für ein Pilotprojekt “Freifunk in Thüringen” und des Antrages der Stadt Gera auf Mittelzuwendung erfüllen. Der Verein Bürgernetz Gera-Greiz e.V. war und ist bereit, als Projektpartner dieses Projektziel zu unterstützen.

Dem Protokoll der Lenkungsgruppensitzung vom 11.4.2018 https://freifunkkommune-gera.de/medien/category/1-protokolle?download=63:2018-04-11-protokoll ist zum Entscheid über die Restmittel zum Betrieb und zur Einrichtung des Hackspaces folgendes zu entnehmen:

• Der informelle Vorschlag des Vereins auf Weitergabe der Fördermittel zur Einrichtung des entstehenden Hackspaces bei Elektro Hauffe wird nach ausgiebiger Diskussion einstimmig abgelehnt.
• Dr. Werner weist auf verschiedene Problemstellungen hin, die eine Weitergabe von Finanzmitteln in einem ungünstigen Licht erscheinen lassen.
  • Der Standort auf einem Betriebsgelände ist nicht „öffentlich“. Die Lage, fernab vom Stadtzentrum, ist nicht leicht erreichbar.
  • Der genannte Betrag (25.000 EUR, Hackspace-Anteil entsprechend des Projektes) ist zu hoch in Anbetracht der fortgeschrittenen Laufzeit des Projektes.
  • Es muss (trotzdem) ein Konzept für den Betrieb des Hackspaces vorgelegt werden.
  • Durch die personelle Verflechtungen des Projektleiters als Stadtmitarbeiter und Schatzmeister des Vereins ist es außerordentlich schwer, dem Verdacht einer Vorteilsnahme zu begegnen. Sowohl die Stadtverwaltung wie auch der Verein machen sich darüber angreifbar.
  • Einer Übertragung sollte explizit durch das TMWWDG und den FD Recht zugestimmt werden.
• Herr Müller und Herr Klein schließen sich dieser Einschätzung an.
• Herr Färber sieht zusätzlich eine Problematik durch das Vermieterpfandrecht in den gemieteten Räumen und in der zeitlichen Einschränkung durch (realistische/realisierbare) Öffnungszeiten. Er regt an, den entstehenden Hackspace als temporäre Einrichtung zu betrachten, aus Projektmitteln auszustatten und mittelfristig ein solches Objekt aus städtischen Mitteln zu finanzieren.
• Die Anwesenden schlagen vor, dass der Verein die Erstellung eines Konzepts zum Betrieb des Hackspaces überdenkt und ggf. zeitnah nachreicht.
• Die Personalentscheidung für ein Mitglied der hiesigen Community hat dieses Problem direkt verursacht und sollte dem TMWWDG (und anderen) als Teilergebnis mitgeteilt werden.

Die bisherigen Anstrengungen, getroffenen Absprachen und vorgenommenen Investitionen der Vereinsmitglieder werden nicht zurückgenommen oder geändert, da die bisherige Initiative vom Verein Bürgernetz Gera-Greiz e.V. ausging und es seitens der Stadt bislang keine Vereinsunterstützung gab.

Der jetzige Hackspace kann durch den Stadtbus (Linie 16, stündlich 2 Busse, Haltestelle Salzstraße) angefahren werden, liegt direkt am Elsterradweg und kann auch mit dem Auto (Parkplätze sind vorhanden) in wenigen Minuten erreicht werden. Nun, ein dreiviertel Jahr vor Projektende, den Verein aufzufordern die bisherigen Planungen, die auf Nachhaltigkeit und Planbarkeit ausgelegt sind, umzuwerfen ist absolut unpassend.

Der Betrag des Antrages (27.135€ im schriftlich eingereichten Antrag) bezieht sich auf die Ursprungswerte der Bewerbung und des Antrages auf Mittelzuwendung und fasst Kosten für Ausstattung und Miete als Sachkosten zusammen. Die Mittel sind damit im Projekt eingeplant und können problemlos innerhalb des Projektmittelvolumens und der Restmittel verwendet werden.

Das Konzept des Hackspaces wurde in der Lenkungsgruppe eingereicht, nachdem es durch den Verein fertig gestellt wurde. Über die Erarbeitung wurde in der Lenkungsgruppe informiert. Außer dem Verein hat niemand, trotz Bitten der Vereinsmitglieder in der Lenkungsgruppe, an der Konzeption mitgearbeitet.

Dass die Mitarbeit des Vereins im Projekt jetzt dafür sorgen soll, dass ein Teil des bewilligten Konzepts nicht umgesetzt werden kann, ist sehr schwer nachvollziehbar. Die bisherigen Zuarbeiten des Vereins (Konfiguration von Backbonehardware, Konzepterstellung und -unterstützung, Hackspace-Engagement) sind im Konzept (sinngemäß) als Mitwirkung des Vereins aufgeführt. Die dafür geplante Vereinsunterstützung, in Form eines Hackspaces, jetzt wegen einer möglichen Vorteilsnahme abzulehnen, stellt einen Schlag ins Gesicht der ehrenamtlichen Freiwilligen dar, zumal der Hackspace auch für Wartungszwecke des Backbonenetzes angedacht wurde.

Herr Drobny als Projektleiter setzt lediglich Lenkungsgruppenentscheidungen um. Er selbst entscheidet über die Mittelverwendung nicht. Wenn er aus der Vergabe von Mitteln an den Verein entsprechend des Zuwendungsbescheides noch herausgenommen wird, was organisatorisch machbar wäre, gibt es faktisch keine Verflechtungen, da die Annahme der Gelder auf Vereinsseite durch den Vorstandsvorsitzenden (Herrn Klein) bzw. dessen Stellvertreter (Herrn ten Venne) zu verantworten ist und die Position des Schatzmeisters (Herr Drobny) erst betrifft, wenn das Geld beim Verein eingegangen ist.

Der Verein Bürgernetz Gera-Greiz e.V. wird keine Überarbeitung des derzeit alleinig initiierten Konzeptes vornehmen. Vielmehr erwarten wir eine fundierte Ausarbeitung, wie sich der Zuwendungsempfänger (Stadt Gera) die Umsetzung eines Hackspaces gemäß der Bewerbung der Stadt Gera mit dem Projekt “Freifunk-Kommune Gera” beim Konzeptauswahlverfahren für ein Pilotprojekt “Freifunk in Thüringen” und des Antrages der Stadt Gera auf Mittelzuwendung zum jetzigen Zeitpunkt vorstellt, bei dem der Verein Bürgernetz Gera-Greiz e.V. als Projektpartner einbezogen ist, um die Nachhaltigkeit des Projekts zu unterstützen.

Sollte es zu keinem tragfähigen Vorschlag kommen, werden wir in der Lenkungsgruppe keiner Mittelumwidmung zustimmen und werden beantragen, dass die Summe für den Hackspace des Antrages der Stadt Gera auf Mittelzuwendung Punkt 3.3 Einrichtung eines Gemeinschaftsraumes als „Hackspace“ an den Fördermittelgeber zurückgezahlt wird.

Details

Geschrieben von: Mario

Kategorie: Aktuelles

Veröffentlicht: 20. November 2021

Zuletzt aktualisiert: 02. Mai 2018

CC BY-SA 2.5 by Arpad Horvath

Nach unserem letzten Update der stabilen Version läuft diese nun schon einige Zeit auf fast allen Routern der Community Gera-Greiz. Bis auf wenige Router ohne Auto-Update gibt es keine Beta- oder experimentelle Version mehr. Das liegt im Wesentlichen daran, daß alle 3 Firmware-Zweige (stable, beta, experimental) Beim Einführung der stabilen Version einen identischen Stand hatten.

Das soll sich jetzt ändern. Wir bereiten einige interessante neue bzw. geänderte Funktionen vor, die wir mit den im Downloadbereich seit heute bereitstehenden Beta- und experimental Firmwares testen möchten. (Wem das Folgende zu technisch ist: macht nichts, einfach unsere getestete stabile Firmware weiter nutzen)

Bei der Beta-Version gibt es von uns nur 2 Änderungen:

1. Die Basis bildet die GLUON-Version 2016.1.4. Die Änderungen seit der für unsere Stable genutzte Version 2016.1.2 sind hier beschrieben. Im Wesentlichen gibt es die Unterstützung einiger neuer Routermodelle und etliche Bugfixes.
2. Die Gateway Selection Class der Router wird auf 45 erhöht. Davon erhoffen wir uns, daß der Datenverkehr eines Routers verstärkt über das Gateway geleitet wird, mit welchem dieser verbunden ist. Bisher schicken sehr viele Router ihren Traffic gerade zu einem der anderen Gateways, was zu einem hohen Datenaustausch zwischen den Gateways führt. Gibt es mit der Beta-Version keine Probleme, werden wir deswegen sehr schnell auch eine neue stabile Version mit dieser Änderung nachschieben.

Bei der neuen experimentellen Version wurde wesentlich mehr geändert:

• Die Gateway Selection Class wurde ebenfalls erhöht.
• Basis ist die aktuelle Entwickler-Version von GLUON mit dem Stand vom 1. Mai
• OPKG-Mirror: Router ohne eigene Internetverbindung (Mesh-only) haben keine IPv4-Adresse. Da die offiziellen OpenWRT-Repositories nur per IPv4 erreichbar sind, kann man deswegen keine Pakete einfach nachinstallieren. Das ist nun durch das Einfügen eines IPv6-Repositories möglich.
• Mesh-Protokoll IEEE802.11s: In der stabilen Firmware ist die Unterstützung für das neue Mesh-Protokoll 802.11s bereits enthalten, aber deaktiviert. Das ist für die experimentelle Firmware umgekehrt: 802.11s ist per default aktiv, das "alte" Ad-Hoc-Mesh deaktiviert. damit können in der Grundeinstellung Router mit der experimentellen Firmware keine Verbindung mehr zu Routern mit der stabilen Firmware aufnehmen! Deswegen sollten alle Router der Testumgebung (nur dafür ist die experimentelle Firmware gedacht)  auf das gleiche Mesh-Protokoll gestellt werden.
  802.11s wird es ermöglichen, wesentlich mehr Router verschiedenster Hersteller mit eine Freifunk-Firmware auszustatten. Da besonders kleinere Router bei der Ativierung beider Mesh-Protokolle Probleme bekommen, werden wir bei der späteren Einführung in der stabilen Firmware die entsprechenden Meshverbindungen bereits vorher umstellen.
• L2TP: Die experimentelle Firmware unterstützt neben dem bisherigen FastD nun die Kombination TunnelDigger/L2TP zum Aufbau eines Tunnels zu den Gateways. L2TP ist im Vergleich zu FastD wesentlich ressourcenschonender, was sowohl auf dem Router als auch auf den Gateways die Auslastung verringert und so die Geschwindigkeit erhöht. Allerdings verschlüsselt L2TP den datenverkeht zwischen Router und Gateway nicht mehr. Das sollte aber kein großes Problem darstellen: vom Client (Notebook, Tablet, Smartphone...) zum Router und vom Gateway ins Internet wird sowieso nicht verschlüsselt. Zur Bewahrung der Privatsphäre sollte man also selbst verschlüsseln (https...).
  Derzeit unterstützt lediglich Gateway2 eine verbindung mit L2TP. Auf den anderen Gateways wird die Aktivierung in Kürze ebenfalls erfolgen.
• Im Konfigurations-Modus vergißt der Router nun nicht mehr die vorgenommenen Einstellungen, wenn zum Experten-Modus und zurück gewechselt wird.

Um uns bei den Tests zu unterstützen, können die neuen Firmware-Versionen entweder über den Konfigurations-Modus oder per SSH installiert werden. Beachtet werden muß aber, daß durchaus Probleme auftreten können. Eine Garantie für die ordnungsgemäße Funktion können wir generell nicht übernehmen. Das gilt insbesondere für die experimentelle Version. Auf schlecht erreichbare Router z.B. sollte also nur die stabile Firmware installiert werden. Auch sollte jeder, der eine Beta- oder experimentelle Firmware installiert, zumindest zu einem Recovery per TFTP in der Lage sein. Wenn Probleme auftreten, helfen wir aber natürlich z.B. im Forum oder bei einem Treffen weiter.

Update 10.5.2016: Nachden mit der Beta-Version keine Probleme aufgetreten sind, gibts die nun seit heute als stabile Version. Mit aktiviertem Autoupdater wird das Update in den nächsten Stunden erfolgen.

Details

Geschrieben von: Jörg

Kategorie: Aktuelles

Veröffentlicht: 20. November 2021

Zuletzt aktualisiert: 02. Mai 2016

Hier mal eine kurze Einführung, wie man das Mesh über WLAN zu bestimmten Knoten unterbinden kann.

Das ist zum Beispiel dann sinnvoll, wenn man die betreffenden Knoten über Kabel miteinander meshen läßt und so keine Airtime für das zusätzliche WiFi-Mesh verschwenden möchte. Außerdem lassen sich damit instabile Links ausblenden, deren Aufrechterhaltung unter Umständen nur unnötig Ressourcen benötigen würde. Die Mesh-Funktion ansich bleibt hierbei erhalten, so daß zum Beispiel der Nachbar einen Knoten aufstellen und dieser dann meshen kann. Außerdem gibt es schlicht keinen Grund, 2 Knoten die per Kabel miteinander meshen, zusätzlich über WiFi miteinander meshen zu lassen, das wäre Ressourcenverschwendung.

Zum jetzigen Zeitpunkt ist es leider noch nicht möglich, die notwendige Änderung dauerhaft, also reboot- und updatefest in die Konfiguration der Knoten zu übernehmen, das wird sich hoffentlich mal ändern. Die notwendigen Befehle werden auf der ssh-Konsole ausgeführt.

Um einen Mesh-Link zu deaktivieren, muß man bei beiden beteiligten Knoten die MAC-Adresse des mesh-Interface des jeweils anderen Knotens sperren. Zunächst muß also diese MAC-Adresse ermittelt werden, dies macht man zum Beispiel mit dem Befehl:

ifconfig mesh0 | grep HWaddr

Die MAC-Adresse erscheint dann hinter HWaddr in der Form XX:XX:XX:XX:XX:XX. Hat man einen Dualband-Router, muß man entsprechend das richtige Interface (mesh0, mesh1) abrufen, die haben nämlich unterschiedliche MAC-Adressen!

Nun haben wir die MAC-Adresse, welche wir am anderen Knoten sperren müssen. Dies bewerkstelligt man mit dem Befehl:

iw dev mesh0 station set xx:xx:xx:xx:xx:xx plink_action block

An Stelle der XX muß natürlich die entsprechende MAC-Adresse angegeben werden.

Die Anweisung ist sofort aktiv, es sind keine weiteren Schritte notwendig, also auch kein commit und kein wifi oder sonstiges. Damit der Link zuverlässig deaktiviert wird, muß man nun noch analog den zweiten beteiligten Knoten anpassen.

Die Anpassung bleibt in dieser Form jedoch nur bis zum nächsten Neustart bestehen.

VG

Sven

Details

Geschrieben von: Sven

Kategorie: Aktuelles

Veröffentlicht: 20. November 2021

Zuletzt aktualisiert: 10. März 2017

Am 29.07.17 fand im Herzen von Gera die 3. Aprestour statt. Gemeinsam mit dem Veranstalter haben wir hierbei Freifunk für diesen Tag aufgebaut. Hierzu standen uns 7 Knoten zur Verfügung. Zwei Knoten befanden sich an der Videowand und zwei Nanostation am Zugangspunkt zum Internet mit einer Bandbreite von 25 MBit, welcher von einen Bürger dankenswerterweise zur Verfügung gestellt wurde. Somit konnte die Veranstaltung abgesichert werden. Ein weiterer Knoten befand sich an unseren Freifunk Infostand.
Zu Spitzenzeiten waren 145 Clients im Freifunk Netz eingeloggt.
Ich möchte mich hiermit bei dem Veranstalter Lucas Schädlich für die gute Zusammenarbeit bedanken. Weiterhin sage ich ein großes Dankeschön an alle Freifunker, welche aktiv diese Veranstaltung abgesichert haben. Wir konnten hierdurch unserer Können abermals unter Beweis stellen.

Details

Geschrieben von: Lutz

Kategorie: Aktuelles

Veröffentlicht: 20. November 2021

Zuletzt aktualisiert: 01. August 2017

CC BY-SA 2.5 by Arpad Horvath

Basierend auf dem gerade erschienenen GLUON v2016.2 erstellen wir derzeit eine neue Beta-Version der Router-Firmware für unsere Community Gera-Greiz, die Version 0.8.9-beta1. Diese sollte ab heute (22.9.2016) abend zum Download und fürs Autoupdate zur Verfügung stehen. Sollten damit keine Probleme auftreten, wird kurzfristig eine statile Version nachgeschoben, welche dann auf dieser Beta-Version basiert.

Seit der aktuellen stabilen Version 0.8.8 gibt es folgende Neuerungen:

• Unterstützung für viele neue Routermodelle, vor allem solche mit ath10k WLAN Chipsatz, hinzugefügt. Z.B. auch:
  • GL-AR150
  • Archer C5 v1, Archer C7 v2
  • TL-WR842N/ND v3
  • UniFi AP AC Lite und Pro
  • RaspberryPi 1 und 2
• Die Modellnamen vieler Ubiquiti-Router werden jetzt eindeutig erkannt. Damit wird z.B. eine Loco jetzt als Loco angezeigt und nicht mehr als Bullet.
• Aktivierung des Parameters "mesh_no_rebroadcast" für Mesh-on-WAN/LAN Interfaces. Das soll einiges an Traffic einsparen.
• neue UCI-Option "gluon-core.@wireless[0].preserve_channels": Wird diese auf "1" gesetzt, werden manuell geänderte Kanäle euf einem Router bei einem Update nicht mehr überschrieben
• In den Advaced Settings des Config-Modes kann nun für Nanostations und CPE 210/510 PoE Passthrough konfiguriert werden
• Das Feld zur Angabe der Höhe im Config-Mode kann ausgeblendet werden. Das haben wir in unserer Firmware auch getan.
• Die Angabe eines Kontaktes im Config-Mode kann jetzt verlangt werden. Auch das ist in unserer Firmware jetzt aktiviert.
• Der Knotenname kann jetzt beliebige Sonderzeichen enthalten.
• Beim 2,4GHz-WLAN können jetzt die unterstützten Raten gesetzt werden. Das ist bei uns nun so eingeschränkt, daß 802.11b-Clients nicht mehr unterstützt werden. Dafür sollte die Performance steigen.
• Die Stabilität der WLAN-Treiber soll entscheidend verbessert worden sein.
• Ab sofort verzichten wir auf das automatische Eintragen von SSH-Schlüsseln unserer Admins auf den Routern. Dies hatte es zwar ermöglicht, in den verschiedensten Notfällen schnell eingreifen zu können. Wer dies nicht wünschte, konnte den Schlüssel z.B. im Config-Mode löschen. Leider wurde der Schlüssel bei jedem Update automatisch wieder eingetragen. Das ist verständlicherweise für alle, die eine Zugriffsmöglichkeit auf ihre Router explizit nicht wünschen, nicht akzeptabel. Deswegen wird nun generell kein Schlüssel mehr gesetzt. Wer dennoch nicht auf die sehr sinnvolle Möglichkeit des Supports durch unsere Admins verzichten möchte, muß deren SSH-Schlüssel nun während der Konfiguration von Hand selbst eintragen.

Details

Geschrieben von: Jörg

Kategorie: Aktuelles

Veröffentlicht: 20. November 2021

Zuletzt aktualisiert: 22. September 2016