Was gibt’s denn neues?
MTU-size? Neue Server? Oder auch „echte“ bugfixes oder gar enhancements?
Es wurde in jedem Fall etwas an der Datenübertragung nach Netmon geschraubt. Seit dem Update sind die VPN Verbindungen nicht mehr unter „Sichtbare Nachbarn“ was unteranderem auswirkungen auf die Graphen „Originators“ und „Quality“ hat.
Leider scheinen auch Custom Interfaces(2 Ports für Mesh + 2 Ports für Clients) nicht mehr korrekt Übertragen zu werden.(Habe einen Router zu dem 2 weitere korrekte Verbindung über br-wan anzeigen er selber sie nicht in der Liste hat.)
Wenn ichs korrekt gesehen habe wurde zudem das VPN Limit auf 1 gesenkt.
Korrigiert mich wenn ich falsch liege 
1 „Gefällt mir“
Ich hab einfach mal die Mail von der ML hier rein kopiert.
Das Release 0.5.5.3 beinhaltet folgende Änderungen:
-
Das Paket gluon-ath9k-workaround ist nicht mehr auf den Routern [0].
-
nodewatcher: Es werden alle mesh-VPN originators raus gefiltert. Das
erspart ca. 90% an traffic [1]. -
Es gibt wieder einen testing branch für den Autoupdater. Der dient
zur Vorbereitung für das batman-adv update [2].
WICHTIG! Der testing brach ist ausschließlich nur für die Entwicklung
gedacht d.h. alle die nicht an der Firmware Entwicklung beteiligt sind
sollten auf stable bleiben! -
Neues Paket names „opkgconfig“: Die default Repositories in
/etc/opkg.conf werden durch ein lokales Repo via ULA im Freifunk Netz
ersetzt [3]. -
Der configurator ist um eine Funktion erweitert worden die dafür
sorgt das die GEO Koordinaten aus der Netmon Datenbank direkt auf den
Router gespeichert werden [4].
Hinzu kommt noch die Änderung der peering Limits die von 2 auf 1 gesetzt worden sind.
Gruß
Jan-Tarek Butt
[0]
[1]
https://git.nordwest.freifunk.net/ffnw/packages/commit/8c0967fdc602a45d8307d395d02da80833cf5069
[2]
https://git.nordwest.freifunk.net/ffnw/siteconf/commit/4f325bbe976e3c0762e587c529f9c9ada4968624
[3]
https://git.nordwest.freifunk.net/ffnw/packages/commit/7ac6c1b6318cec185ec047e5fc4ceae7b0bd7dbb
[4]
https://git.nordwest.freifunk.net/ffnw/packages/commit/6cb1e1d1fbd0c291acbdaecce58b2ca4a3b0a2e5
Dienste auf die alle Router regelmäßig zugreifen auf ULAs zu setzen hat sich in der Vergangenheit sowohl im Ruhrgebiet und ein paar Wochen später im Rheinufer als wirklich katastrophal erwiesen.
Sobald das Netz einmal instabil wird und Router vermehrt booten kann das zu kaskadierenden Paketstürmen führen.
Mich würde interessieren wie gut das läuft. Bisher sehen die Tunnel sehr stabil aus, sodass wir (andere domänen) uns eventuell durch die 2-Tunnel-Redundanz unnötig Ressourcen wegnehmen?
Zumal die 2 Tunnel nach meinem derzeitigen Gefühl nicht in allen Szenarien helfen.
Wenn nämlich ein Supernode „halb tot“ ist, d.h. den Fastd-Connect noch hält, das Routing dahinter (zu dhcp, zu den anderen Servern) ab weg ist, dann hockt da ein Router evtl. bis St. Nimmerlein (bis zum nächsten Boot falls Internet ohne Zwangstrennung) mit einem disfunktionalen Meshnetz (kein Gateway, kein dhcp) da.
Die 2-Tunnel-Redudanz war in unserem Netz IMHO mehr oder weniger sinnlos.
Im Falle eines Ausfalls muss batman erstmal merken, dass der Gateway weg ist, und auf den anderen umstellen. Die per DHCP an die Clients vergebene IP muss aber auch noch erneuert werden, was nach max. 15 Minuten der Fall wäre. In der Zeit kann auch fastd direkt eine neue Verbindung aufbauen, wenn ein Gateway abgeschmiert ist.
1 „Gefällt mir“
kann ich über Netmon noch, in welcher Form auch immer, sehen ob der fastd Tunnel steht ? Die Anzeige ist ja unter „Verbindungsqualität zu Nachbarn“ verschwunden, ich fand das immer ganz nützlich.
Seit dem Update werden nicht alle Mesh-LAN Verbindungen korrekt Angezeigt. Konkretes Beispiel:
Links zu sehen Nanostation1 bei welcher Mesh-WAN zum VPN Offloader und Mesh-LAN zu Nanostation2 korrekt angezeigt werden.
Links der Offloader WDR3600 mit separatem VLAN fuer Mesh-LAN. Hier war vor dem Update die Verbindung zu der Nanostation1 und einem Test Router zu sehen auf Interface eth0.3.
Woran liegt es dass bei der Nanostation das Interface angezeigt wird bei dem WDR aber nicht?
Muss ich das irgendwo eintragen dass es wieder korrekt angezeigt wird?
Das könnte daran liegen, dass einige Router die physikalischen Interfaces „eth0“/„eth1“ numerieren, anderen als „eth0.1“/„eth0.2“ und irgendein script das nicht berücksichtigt. (Vorsicht: Spekulation)
Wobei ich höre, dass die Interface-Benennung bei OpenWRT-ChaosCalmer sowieso komplett neu gemacht werden wird. Könnte also noch etwas unlustig werden für einige Gluon-Module.
Ich habe gesehen, dass es jetzt eine
„Firmware: 0.5.5.4“ auf meinen Routern gibt.
Weiss jemand, was es da neues gibt?
Die ersten Vorbereitungen für das BATMAN Update. Es sind u.a neue gluon Packages hinzugekommen. Changelog ist im GIT zu finden.
Zu 0.5.5.4 folgt heute Abend noch ein Artikel, aber hier die Änderungen:
-
Das Paket ffnw-fastdreg ist nicht mehr auf den Routern, da es durch
eine Infrastruktur Umstellung obsolet geworden ist -
mesh_vpn wird per default auf true gesetzt
-
nodewatcher: originator filter Code optimiert. Direkte VPN Router
sind wieder in der originator List erkennbar -
Das good_signatures_level wurde von 2 auf 3 inkrementiert. Es müssen
also ab jetzt mindesten 3 Entwickler das Manifest signieren bevor eine
neue Firmware ausgerollt wird -
Das Paket ffnw-autoupdater-mod ist nun auf den Routern enthalten. Es
dient dazu den autoupdater so zu patchen das dieser für das
bevorstehende B.A.D.M.A.N-adv update optimiert ist, da die neue
B.A.D.M.A.N-adv Version inkompatibel zu alten ist -
Es sind zwei neue Signaturen hinzugefügt
-
Die VPN Gateways VPN04 und VPN05 sind nicht mehr in der neuen
Firmware Version verfügbar. Das dient zu Vorbereitung auf das neue
B.A.D.M.A.N-adv update
1 „Gefällt mir“
Batman-Upgrade könnte spannend werden, wie man da sicherstellt, dass Nodes „ohne MeshVPN“ als erste updaten.
Oder wird es einen Modul geben in denen Nodes in „gateway-lose“ Wolken regelmäßig (täglich?) nach einem anderen Freifunk-AP schauen, sich dort als Client einbauchen und schauen, ob sie damit zu einem Update-Server kommen.
Genau, die MESH Router updaten als ersten und danach die VPN Router.
Auf die Gefahr von Wortklauberei hin: Die Wifi-Mesh-Router updaten vor den VPN-Mesh-Routern.
Das wird dann wie bewerkstelligt? Die Unterscheidung trifft der jeweilige Node selbst?
Oder wird das zentral gesteuert?
D.h. der VPN-Mesh-Router „BatmanADVv14“ weigert sich so lange upzudaten wie er noch Wifimesh-Nodes an sich hängen hängen sieht?
Über das Autoupdater Module wird das auf dem jeweiligen Router geregelt.
Bevor der Mesh Router das Update nicht hat, darf def VPN Router sich es nicht ziehen.
Konsequenz daraus. In der Zeit bis der VPN Router das Update nicht hat kann der Mesh Router nicht online sein. Dafür wurde im Autoupdaterdie Zeitspanne in der nach Updates gesucht wird verkleinert
Meine Frage bezog sich darauf, welche Bedingung da abgefragt wird.
jemand anders hat das gebaut. Es wird geprueft ob eine VPN verbindung besteht, wenn ja wird die Waittime(zwischen erkennen und updaten) hoeher angesetzt als bei Routern ohne VPN.
Dementsprechend jeder Router entscheidet fuer sich.