Hallo zusammen,
auf dem letzten Treffen kam nochmals die Frage nach einer Offline-SSID
auf. Tarek möchte so eine grundlegende Entscheidung auf der ML diskutieren.
Ich denke wir sollten eine Offline-SSID einführen. Diese muss nicht
direkt vom Online-Status des Routers herrühren, sondern könnte auch
durch ein fehlendes (Batman-)Gateway ausgelöst werden.
Grund: Ohne Gateway Anbindung hat man nicht den erwarteten Zustand.
Befindet man sich beispielsweise in Oldenburg und verbindet sich mit
unserem Netz, erwartet man eine IPv4 und eine Publicv6 aus dem
Oldenburger Bereich zugewiesen zu bekommen und mit jedem anderen im
Freifunk Nordwest Netz und auch mit dem gesamten Internet Daten tauschen
zu können.
Für Nutzer, die auch die ganz grundlegenden lokalen Features nutzen,
sollte es kein Problem sein sowohl Offline- als auch Online-SSID zu
speichern / sich damit zu verbinden.
Wenn wir das nicht tun provozieren wir an reinen Mesh-Routern ohne
Anbindung ein Offline-legen der User. Die Geräte verbinden sich mit
Freifunk, schalten mobile Daten ab und sind offline.
Außerdem kann es auch beim Ausbau unterstützen: Mein Blick in der
Oldenburger Innenstadt geht gerade dahin, wo ich einen Uplink her
bekomme, obwohl ein weiterer Routerstandort auch ohne cool ist. Ich
werde aber keine Router aufbauen, die von vornherein offline sind und
Nutzer beeinträchtigen. Mit Offline-SSID kein Problem und die Geräte
würden sich auf die normale SSID konfigurieren, sobald ein Uplink-Router
in der Nähe ist.
--
Viele Grüße,
Simon
Hi zusamnme,
bitte die Puppet Agents auf nachfolgenden Kisten auslassen:
- OL VM
- srv08
- srv08
Ein Puppet Modul von uns hat hier Fehler und unsere Rheinland Tunnel
bekommen falsche Netmask zugewiesen. Simon und ich sind schon an der
Fehlerbehebung und geben hier Entwarnung sobald es erledigt ist.
Viele Grüße
Stefan
FIY
-------- Forwarded Message --------
Subject: [gluon] [ANNOUNCE] Gluon v2016.2.4
Date: Mon, 13 Mar 2017 15:41:34 +0100
From: Matthias Schiffer <mschiffer(a)universe-factory.net>
To: gluon(a)luebeck.freifunk.net
CC: Freifunk Firmware Entwicklung <firmware-devel(a)freifunk.net>, WLANware <wlanware(a)freifunk.net>
Gluon v2016.2.4 is out, this time we have
- fixed batman-adv (15) being unable to transmit packets of some specific
sizes
- fixed a regression in Gluon v2016.2.3 causing high loads in meshes with
many router advertisements
- switched to a working mirror after the ftp.all.kernel.org
discontinuation
and more.
Find the complete release notes at:
http://gluon.readthedocs.io/en/v2016.2.4/releases/v2016.2.4.html
-- NeoRaider
Ich würde lo(c/k)al.nordwest.freifunk.net sagen
Mit freundlichen Grüßen
Jens Ellerbrock
--------------------
Freifunk Nordwest e.V. Website
Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten)
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------Von: Malte Modler via Dev <dev(a)lists.ffnw.de> Datum: 13.03.17 12:01 (GMT+01:00) An: dev(a)lists.ffnw.de Cc: Malte Modler <mail(a)malte-modler.de> Betreff: Re: [Dev] Offline-SSID
no-uplink.nordwest.freifunk.net
Hallo zusammen,
da nun vermehrt Entwicklungen von mehren Personen beigesteuert und
betrieben werden würde ich gerne die Struktur ein wenig anpassen.
Der master branch ist bereits ein protected branch. Das bedeutet
developer stellen an den master branch einen merge request. Der
voreilt bei der Variante ist das es das Revieren von code wesentlich
angenehmer gestaltet. Über die inline Kommentare kann man dann wunderbar
über Änderungen und Verbesserungen schreiben.
Ich habe gerade die Konfiguration dafür im Projekt angepasst und würde
das so probieren wollen um einen besser geordneten Entwicklungsprozess
zu erzielen und das maintanen zu vereinfachen.
Dazu habe ich alle den Status Developer zu geordnet. Was letztlich dazu
führ das automatisch merge requests gegen den master gestellt werden,
sobald man was puscht in den master puschen möchte. Es sollte sich dadurch
für niemanden was ändern und alle sollten wie vorher auch gewohnt am code
arbeiten können.
Falls jemand ein Problem fest stellt was in der jetzigen Konfiguration
jemanden an der Entwicklung behindert. Gerne hier drauf melden damit wir
schauen können wo genau das Problem besteht und ob evtl. mehrere betroffen
sind.
Schöne Grüße und happy coding zusammen :)
Tarek
Hallo zusammen,
nachdem wir einige Stunden debuggt haben, konnten wir eine Lösung für
das Next Node Problem finden.
Unter node.ffnw ist nun als Client die Statuspage des Routes erreichbar.
Dieser DNS Eintrag läst auf die v6 Adresse (fd74:fdaa:9dc4::127) auf.
Das Problem im Bereich v4 ist, dass 10.18.0.127 außerhalb der Hoods
liegt und deshalb nicht erreichbar ist.
Im nexten Schritt sollten wir die Next Node v4 aus der siteconf
entfernen, denn diese ist nun unnötig.
Viel Spaß :-)
VG
Stefan
Moin
habe gerade das hier produziert:
root@whv-rheinstrasse140-1:~# hoodselector
No VPN connection found
Testing neighboring adhoc networks for batman advanced gw connection.
The following wireless networks have been found:
0 2437 02:CA:FF:EE:BA:BE testing.mesh.ffnw
0 5220 02:CA:FF:EE:BA:BE testing.mesh.ffnw
33 2437 02:00:0A:12:E8:00 testing.mesh.ffnw
39 5220 02:00:0A:12:E8:00 testing.mesh.ffnw
After filtering we will test the following wireless networks:
0 5220 02:CA:FF:EE:BA:BE testing.mesh.ffnw
33 2437 02:00:0A:12:E8:00 testing.mesh.ffnw
39 5220 02:00:0A:12:E8:00 testing.mesh.ffnw
Prepare configuration for testing wireless networks...
VPN stopped.
Testing 02:CA:FF:EE:BA:BE...
command failed: Device or resource busy (-16)
