Das Funktioniert hier Technisch. Wie es mit den Reboots aussieht wird sich zeigen.
Jo. Ich wäre dann auch fertig damit. Seien wir mal gespannt. Das
ebtables -A FORWARD --logical-in $brname -j DROP
ist also die Variante, wie man ein split-horizon oder point-2-multipoint umsetzt. F*** hab ich das lange gesucht und nicht gefunden…
2 „Gefällt mir“
Ich habe jetzt ein paar mal den Tunneldigger beendet bei ca 60 Tunneln… Normal hatten wir da immer schon den reboot/kernel panic
Sieht also ganz gut aus
2 „Gefällt mir“
Mein Problem: das lief über Wochen super. Die Crahes kamen dann plötzlich … Ich bin aber zuversichtlich: im batman sollte das jetzt ja nicht mehr sterben, denn aus dem Teil vom Code ist das Paket dann ja schon raus und flitzt irgendwo in der Bridge rum …
1 „Gefällt mir“
Es geht hauptsächlich darum das Batman wohl nicht gut mit vielen Interfaces umgehen kann.
Irgendwo im Batman Code spielt dann was verrückt wenn die Interfaces plötzlich verschwinden.
Dem wird ja dadurch entgegen gewirkt das die Bridge nicht andauernd entfernt oder hinzugefügt wird.
Auf den Supernodes in Düsseldorf haben wir die Bridge als normales Interface in der Debian Config hinzugefügt, Tunneldigger entfernt also nur die Interfaces aus der Bridge wenn wir diesen neu starten. Die Bridge selbst bleibt im Bat0 Interface vorhanden.
Edit mit Beispiel:
# Tunneldigger VPN Interface
auto tunneldigger
iface tunneldigger inet manual
## Bring up interface
pre-up brctl addbr $IFACE
pre-up ip link set address 0A:BE:EF:25:00:01 dev $IFACE
pre-up ip link set dev $IFACE mtu 1364
pre-up ip link set $IFACE promisc on
up ip link set dev $IFACE up
post-up ebtables -A FORWARD --logical-in $IFACE -j DROP
post-up batctl if add $IFACE
# Shutdown interface
pre-down batctl if del $IFACE
pre-down ebtables -D FORWARD --logical-in $IFACE -j DROP
down ip link set dev $IFACE down
post-down brctl delbr $IFACE
3 „Gefällt mir“
Es gibt ein paar Bugfixes für Tunneldigger welche ich bereits für 2015.1.2 backported habe.
Außerdem gibt es nun das Paket „gluon-tunneldigger-watchdog“, dies ist ein cronjob welcher prüft ob Tunneldigger läuft und ggf. neu startet. Dies ist nur der Fall wenn Tunneldigger aktiviert ist.
Dies muss einfach nur in die site.mk eingefügt werden.
Hier ein Beispiel modules config für Gluon 2015.1.2
Für die Entwicklerversion einfach wie gewohnt den master branch verwenden.
# This file allows specifying additional repositories to use
# when building gluon.
#
# In most cases, it is not required so don't add it.
## GLUON_SITE_FEEDS
# for each feed name given, add the corresponding PACKAGES_* lines
# documented below
GLUON_SITE_FEEDS='ffrl_packages'
## PACKAGES_$feedname_REPO
# the git repository from where to clone the package feed
PACKAGES_FFRL_PACKAGES_REPO=https://github.com/ffrl/ffrl-packages.git
## PACKAGES_$feedname_COMMIT
# the version/commit of the git repository to clone
PACKAGES_FFRL_PACKAGES_COMMIT=646c8155fb4753294a548676917003c522ffb674
## PACKAGES_$feedname_BRANCH
# the branch to check out
PACKAGES_FFRL_PACKAGES_BRANCH=backports_2015.1.2
Gruß
Cyrus
1 „Gefällt mir“
@stefan - so scheint es zu gehen, oder? Dann versuch ich am Wochenende mal wieder alles zu schwenken. Ich nehme dazu die Pakete von @CyrusFox.
1 „Gefällt mir“
Ja läuft bei uns einwandfrei.
Blöde Frage: wie trenne ich vom Server her am sinnigsten einen Knoten??
Vermutlich wie bei fastd: gar nicht.
Router blacklisten und Server neu starten, damit alle anderen sich erneut verbinden.
(Wobei mir die Serverseite nach wie vor etwas unklar ist. Die Dokumentationslage im Wiki ist nicht so toll. Eventuell ist es einfach noch nicht ausgereift wie fastd.)
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
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“