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
 |
| 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:
- 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.
- 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
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
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
|
| CC BY-SA 2.5 by Arpad Horvath |
Basierend auf GLUON v2016.2.6 steht ab sofort die neue stabile Firmware 0.8.18 für die Community Gera-Greiz zur Verfügung. Bei Knoten mit aktiviertem Autoupdater erfolgt die Verteilung automatisch in den kommenden 2 Wochen. Seit der vorangegangenen stabilen Version 0.8.16 hat sich nicht allzu viel geändert:
- Unterstützung für TP-Link TL-WR841N/ND v12
- Behebung kleinerer Fehler und eines für uns unbedeutenden Sicherheitsloches
- Behebung eines Fehlers bei Upgrades von x86-basierenden Knoten
Der letzte Punkt ist wichtig für alle, die Knoten auf PC-Hardware (Intel/AMD) betreiben. Wird beim Upgrade auf eine der nächsten Firmware-Versionen diese Version 0.8.18 ausgelassen, geht die gesamte Konfiguration des Knotens verloren. Er würde sich also nicht mehr mit Gateways und anderen Knoten verbinden und müßte vor Ort neu konfiguriert werden.
Die Version 0.8.18 wird voraussichtlich die letzte sein, welche auf dem nicht mehr gepflegten OpenWRT aufbaut. Die nächste Version läuft dann mit GLUON v2017.x unter dem aktuellen, modernisiertem LEDE. Wahrscheinlich werden wir dabei auch den Schritt von Fastd zu TunnelDigger/L2TP vornehmen. Beides sind VPN-Protokolle, welche für nicht (nur) per Mesh angebundene Knoten über unsere Gateways die Verbindung zum restlichen Netz unserer Community aufnehmen. TunnelDigger/L2TP ist im Vergleich zu Fastd ressourcenschonender und schneller, so daß auch weniger leistungsstarke Knoten die volle Kapazität des Internet-Anschlusses ausschöpfen können.
Auf Grund dieser recht wesentlichen Änderungen sind vor diesem Update noch umfangreiche Tests geplant. Unsere derzeitige experimentelle Firmware basiert bereits auf GLUON v2017.1 und LEDE und verwendet nur noch TunnelDigger/L2TP. Diese läuft auf ca. 25 Knoten bisher recht gut. Als nächsten Schritt werden wir beim kommenden Techniktreffen auf dieser Basis eine neue Beta-Version erstellen. Damit können wir auf allen Beta-Knoten testen, ob beim Wechsel auf die neue Firmware Probleme auftreten. Für eine breitere Testbasis wünschen wir uns, daß sich noch mehr Knotenbetreiber an den Betatests beteiligen. Auch Nutzer der aktuellen experimentellen Firmware sollten nach Möglichkeit nochmal den Schritt von der derzeitigen stabilen auf die folgende Beta-Firmware durchspielen. Wie das genau geschehen kann, erklären wir, sobald die neue Beta-Firmware zur Verfügung steht.
- Details
- Geschrieben von: Jörg
- Kategorie: Aktuelles
<name>space
geschlossen seit 31.05.2023 23:36 Uhr