Völlig falsch in meinen Augen. Bevor bei uns der erste Knoten Online ging mit unserer SSID, stand das Gateway. Erst dann wurde die Firmware gebaut und auf den ersten Knoten geflasht und dieser in Betrieb genommen. Falls wir uns mal irgendwann dazu genötigt sehen zu einem Freifunk Nord Bla Bla zu migrieren, können wir sagen, hier ist nen Netz mit derzeit 85 Knoten und 2 GWs. Die GWs müssen angebunden werden für die Exits.
1 „Gefällt mir“
Spricht etwas dagegen dieser Liste auch direkt sagen wir 50% zusätzliche Einträge hinzuzufügen um in Zukunft ohne Firmware Update neue Supernodes aktivieren zu können.
Auch zur Implementierung von Hot Standby Systemen fände ich das wünschenswert.
3 „Gefällt mir“
Da spricht nichts gegen, in Wuppertal haben wir nur 3 von 10 Servern in Betrieb. Die 7 nicht funktionierenden Einträge werden einfach übersprungen.
In Frankfurt/Main haben wir 3 aktive Server, der Rest ist „spare“
http://wiki.freifunk.net/Frankfurt-ip-Konzept
(p.s. Der Christof dokumentiert das ganz hervorragend.)
1 „Gefällt mir“
Schon geschehen, wir haben jetzt insgesamt 13 supernodes in der config wovon bis jetzt nur 4 aktiv sind. Der rest kommt am WE, siehe:
https://github.com/ffrl/sites-ffrl/blob/v2014.4/site-rheinufer/site.conf
3 „Gefällt mir“
Super Sache, ich hatte nur nach dem ausrollen der 2014.4-stable-1 enttäuscht festgestellt, dass keine weiteren Supernodes in der Config aufgetaucht sind.
Ich hab 8 Beiträge in ein vorhandenes Thema verschoben: Sammelthread: Störungsmeldungen und Netzprobleme in Gelsenkirchen
Vielleicht sollten wir einfach auf nächste Woche warten bis die Feuer gelöscht sind. Ich denke, das Einbinden von neuen Personen kann man einfach nicht so gut machen, wenn es akut an allen Enden brennt.
Soweit ich weiß läuft auch die Umstellung der einzelnen Domänen auf den Backbone im Hintergrund. Problem dabei ist nach meiner Vermutung, dass es viel Arbeit ist, es aber keinen Sinn macht, da jemanden anzulernen (schließlich macht man das nur einmal…)
Trotzdem sollte man zügig die neuen Interessenten schnell integrieren, bevor das Feuerlöschen ein Dauerzustand wird. Bis jetzt habe ich da aber durchaus noch Verständnis. Wenn in einem Monat die Admins aus Aachen allerdings immer noch nicht mitarbeiten können, dann schließe ich mich nämlich meinen Vorrednern an, dann läuft definitiv was schief mit der Nachwuchsarbeit.
1 „Gefällt mir“
Das stimmt so schlicht nicht. Wobei die Definition von „wir“ sicher zu kären wäre.
Das nutzt uns allen aber eh nix und da rumzuplöppern kostet unötig Zeit und Kraft die wir sinnvoller verwenden können.
Ich würde mir folgendes wünschen, sobald die Probleme abgefedert sind:
- Das Wachstum und den Ausbau „vorausschauender“ betreiben
- Allg. zugängliche Informationen wie z. B. Performance Stats (die gibt es bestimmt, wie es alles gibt nur wenige wissen wo). So können Communitys von denen der Verein nicht mal was weiß, sich selber schon ein Bild machen
- Wissen verallgemeinern, aktuell halten, zugänglicher machen (korreliert mit dem Satz drüber)
Einfach bessere Kommunikation und aktuelle Wissensquellen an EINER zentralen (Verteil)Stelle. Hilfe dazu einfordern und anfragen.
Das gilt nicht nur für die Technik. Selbst so Dinge „wir sind im RIPE“ findet sich nicht mal als News-Schnipsel auf der Website des e. V. Wir haben dafür keine Quelle gefunden, außer dem RIPE Eintrag beim RIPE dort.
Beispiel: wir es Montag eine Info geben zu:
Was klemmte
Was wurde gemacht
Wie sieht es jetzt aus
Was ist noch von wem bis wann zu tun
Was sind die Konsequenzen
…
Lasst uns die aktuellen Engpässe lösen und überlegen wie wir damit in Zukunft proaktiv (Bingo!) umgehen wollen. Ich wäre dabei, wenn sich da was produktives abzeichnet bzw. würde dazu beitragen. Viele andere sicher auch.
Viele Grüße, Fx
4 „Gefällt mir“
Habt ihr schon was gemacht?
Es ist gerade Stoßzeit, aber das Netz ist wieder erstaunlich flott. 
2 „Gefällt mir“
Wow, das ist bei 530 Nodes mit 876 Clients echt erstaunlich.
Vermutlich ist heute die Last besser ausbalanciert als in den vergangenen Tagen.
1 „Gefällt mir“
Nicht ganz so toll wie bei @yayachiken, aber gegenüber gestern Abend mit etwa 100 kbit/s deutlich besser!
Die Node ist heute auch mit 2 Supernodes verbunden:
There are 4 peers configured, of which 2 are connected:
mesh_vpn_backbone_peer_rheinufer0: connected for 5330.039 seconds
mesh_vpn_backbone_peer_rheinufer1: not connected
mesh_vpn_backbone_peer_rheinufer3: not connected
mesh_vpn_backbone_peer_rheinufer2: connected for 5328.291 seconds
Gestern war das eine Zitterpartie zwischen 0 und einer Verbindung.
Name links vpn
Supernode: rheinufer0 0 1 152
Supernode: rheinufer1 0 1 200
Supernode: rheinufer2 0 3 151
Supernode: rheinufer3 0 1 187
@nomaster Wo liegen denn derzeit die Limits?
Ist das mit den unvollständigen Links untereinander Absicht?
1 „Gefällt mir“
Müssen wir uns Sorgen machen? 
Supernode: rheinufer3 0 1 251
Supernode: rheinufer2 0 2 199
Supernode: rheinufer1 0 0 0
Supernode: rheinufer0 0 1 201
Gibt es Neues zu den angekündigten Arbeiten?
Aktueller Stand bei mir über Freifunk:
Vorhin ging gar nichts. Ich kann natürlich nicht ausschließen, dass das Problem bei mir liegt.
Deshalb schicke ich mal den Status des Routers mit:
Model: Ubiquiti Nanostation M
Firmware release: 2014.4-stable-1
22:57:35 up 2:01, load average: 0.13, 0.39, 0.56
6: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 68:72:51:12:1f:61 brd ff:ff:ff:ff:ff:ff
inet6 2a02:f98:0:28:6a72:51ff:fe12:1f61/64 scope global dynamic
valid_lft 86380sec preferred_lft 3580sec
inet6 fda0:747e:ab29:cafe:6a72:51ff:fe12:1f61/64 scope global dynamic
valid_lft 86400sec preferred_lft 3600sec
inet6 fe80::6a72:51ff:fe12:1f61/64 scope link
valid_lft forever preferred_lft forever
total used free shared buffers
Mem: 28860 26256 2604 0 2152
-/+ buffers: 24104 4756
Swap: 0 0 0
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2304 2304 0 100% /rom
/dev/mtdblock5 4288 300 3988 7% /overlay
Neighbourswlan0Joined IBSS 32:ca:ff:ee:ba:be (on wlan0)
SSID: wifimesh-rheinufer
freq: 2422
Station 6a:75:52:0a:2d:67 (on wlan0)
inactive time: 40 ms
rx bytes: 51259145
rx packets: 424407
tx bytes: 1200
tx packets: 36
tx retries: 280
tx failed: 25
signal: -78 [-81, -81] dBm
signal avg: -77 [-81, -80] dBm
tx bitrate: 104.0 MBit/s MCS 13
rx bitrate: 6.5 MBit/s MCS 0
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
VPN statusfastd running for 7232.741 seconds
There are 4 peers configured, of which 2 are connected:
mesh_vpn_backbone_peer_rheinufer0: not connected
mesh_vpn_backbone_peer_rheinufer1: connected for 7169.949 seconds
mesh_vpn_backbone_peer_rheinufer3: connected for 7172.725 seconds
mesh_vpn_backbone_peer_rheinufer2: not connected
Kann ich teilweise bestätigen. Speedtest zeigt zwar 1,32 MBit/s down 2,54 MBit/s up (an einer Gigabitleitung), aber Web-Browsing ist nicht sehr gut möglich (Seitenaufbau ~30 Sekunden). Warum, kann ich nicht sagen.
Gibt es einen einfachen Schalter der sagt:
„Internet weiterhin freigeben, aber ohne VPN?“
Soweit ich weiß absichtlich nicht. In diesem Fall wäre es nämlich zu einfach, den versehentlich umzulegen, sei es durch Anwenderfehler oder aktuen Routeralzheimer oder auch Programmfehler.
Wer das möchte, der kann das tun. Auf der Kommandozeile. Und sich die Befehle dazu selbst zusammensuchen. (Und bei der Suche vielleicht nochmal ins Nachdenken kommen.)
Ich werde niemanden dazu anstiften.
Hi
wie sieht es denn bei fastd mit sowas wie AES-NI aus?
Ich hab das bisher nur für luks verwendet, aber ich glaub hab schon gut was gebracht. Keine Ahnung was fastd für n Crypto macht, aber so n bisschen hardwarebeschleunigung kann nie schaden.