Ach wo. Der Tunneldigger hat einen Control-Channel. Da wird man schon irgendwie ein ERROR_REASON_SHUTDOWN zur Gegenseite schicken können. Ist da niemand da draußen, der das schneller raus finden kann als ich?
Moin,
das kommt ja auf das Ziel an. Soll der Router reconnecten, dann sollte es reichen die Session/ das Interface weg zu haun.
Soll der Router nicht neu connecten würde ich das Interface nur aus batman rausnehmen. Dann connected der nicht laufend neu, ist aber trotzdem „offline“. Dazu ne iptables Regel, damit der nach einem Neustart auch draussen bleibt, wenn gewünscht.
Gruß
Chrisno
Für mich klingt das nach einer freundlichen Einladung.
4 „Gefällt mir“
Wenn ich eine Bridge für Tunneldigger erstelle kann ich „no_rebroadcast“ nicht mehr benutzen, oder?
Ja das ist richtig, das funktioniert nur bei individuellen Interfaces.
1 „Gefällt mir“
OK, danke für die Auskunft 
Weißt du zufällig ob Batman 2013.4 auch Probleme mit vielen Interfaces/Änderungen macht oder ob das nur ein Problem mit den neueren Versionen ist?
Unsere (alte) Statistik-VM hat 4 vCores, die Interfaces sind eher statisch (die Kiste hat halt batman_adv geladen, weil da lokal alfred/batadv-vis laufen sollen und die Kartenbackends befüllen). Wir nutzen 2013.4.0. Es ist die einzige VM bei uns, die sich häufiger (so alle 2 Monate?) mal ins Gehackte legt. Zu selten für Ursachenforschung, zumal bei Legacy-Release, aber batman_adv taucht im Crash-Log auf der virtuellen Console i. d. R. auf. Kurzum: wirst Du wohl austesten müssen, ich denke aber, die Bugs sind nicht erst seit v15 drin …
Ich habe die Probleme ab ca 150 Interfaces im Batman auch bei 2013.4.
Mit dem Patch batman-adv: Fix use-after-free/double-free of tt_req_node · freifunk-gluon/batman-adv-legacy@ffcd5f2 · GitHub
soll sich die Situation scheinbar bessern. Gibt es auch für v15.
1 „Gefällt mir“
Was ist denn der richtige Ort, um Bugs im Tunneldigger (aus dem FFRL-Repo) zu berichten? GitHub-Issues sind geschlossen für dieses Repo. Die Links in der README füren zum wlan-si, und die Unterschiede sind inzwischen doch ziemlich groß.
Wir haben den Effekt, dass die GWs völlig verkehrte usage-Information berichten. Ich habe da schon etwas debugged, das schreibe ich gerne ausführlich auf, sobald ich weiß, was dafür der richtige Platz ist.
1 „Gefällt mir“
Hab die Issues in Github wieder aktiviert, warum auch immer die aus waren 
1 „Gefällt mir“
Hehe, diesmal war ich schneller, habe gleich den Patch geschrieben und als PR submitted 
Habt ihr das Problem lösen können? Wenn ja, wie?
Ist bei uns exakt das gleiche Problem, dass das Tunneldigger-VPN bei Factory-Image-Installationen per Default deaktiviert ist. Trotz enabled = true.
Bei einem sysupgrade funktioniert es, da wird das migrate-vpn-Script wohl seine Arbeit tun.
1 „Gefällt mir“
Negativ, ist hier auch noch „Baustelle“.
Kann man dabei irgendwie unterstützen/tracen/sonstwastun ?
Müsste ein
uci set tunneldigger.@broker[0].enabled=‚1‘
per Script ausgeführt beim Firstboot den Tunnel nicht einschalten? Ok, ist keine wirkliche Lösung, aber als Workaround könnte das vielleicht helfen.
Einen (ähnlichen) Workaround in den Update-Scripten werde ich auch durchführen, wenn das Main-Respository bis zu meinem nächsten Build-Lauf noch nichts entsprechendes geändert ist.
@CyrusFox Ich nehme an, das dass eines der (hier in ffdus) nicht verwendeten luci-configmodule aus ddorf das fixen würde, ich habe das nur noch nicht im Detail angeschaut.
Einem Kollegen hier im Saarland ist aufgefallen, dass bei den site.conf, die man hier so herumfliegen sieht – und auch in unserer eigenen – im tunneldigger-Block das enabled = true fehlt, das man beim fastd immer stehen hatte. Ist das vielleicht der Grund für das Problem beim Factory-Flashen? (Ich habe unsere Factory-FW noch nicht mit Tunneldigger ausprobiert, weiß also nichtmal, ob das Problem bei uns überhaupt auftritt). Wir haben jetzt enabled = true drin und werden das nächste Woche mal testen, ob die Factory-FW funktioniert.
Ansonsten haben jetzt hier ein gutes Dutzend User wagemutig die Tunneldigger-Firmware installiert, und die sind alle sehr zufrieden. Latenzen sind auf weniger als 30% gesunken im Vergleich zu fastd, während der Durchsatz deutlich gestiegen ist und erst bei ca. 30 MBit/s an eine Grenze zu kommen scheint. Klasse Sache, Danke an alle Beteiligten
Was mir noch aufgefallen ist: tunneldigger ist mit Abstand der RAM-fressendste Prozess in der Firmware. „top“ zeigt in meiner VM fast 5 MB „VSZ“ an. Nun ist mir auch klar, dass RAM-Messungen extrem schwierig sind, aber der Trend ist doch ziemlich eindeutig (auf Platz zwei folgt haveged mit 1.3 MB VSZ). Das ist wohl immer noch weniger, als fastd früher gebraucht hat, aber trotzdem fragt man such, was tunneldigger da eigentlich tut… der macht doch nur ein bisschen Parameteraushandlung mit vier Brokern (von denen aktuell nur 2 laufen).
Das Problem hab ich nun gelöst, Lua ist irgendwie seltsam was Conditional Clauses angeht
Ich habe jeweils einen Release für 2015.1.2 sowie 2016.1.X gepusht.
Gluon 2016.1.X
Der Tag ist zwar v2016.1.4 aber der Release ist mit allen v2016.1.X Versionen kompatibel.
Gluon 2015.1.2
Gruß
Cyrus
2 „Gefällt mir“
Das bedeutet Repo aktualisieren und neu bauen reicht?
1 „Gefällt mir“
Ja richtig Aber nicht vergessen in der Modules Config auf den neuen Commit zu verweisen