Posted bitte mal den output auf Deinem supernode von
batctl if
und
brctl show
Vermutlich fehlt irgendwas a la
batctl add if tunneldigger
(oder war es „if add“?) in dem batup-script des fastd. (warum hast Du kein bat0 oder ähnliches im Batman? Wo geht es denn weiter bei Dir?)
root@v22017011140543301:~# batctl if
tunneldigger: active
root@v22017011140543301:~# brctl show
bridge name bridge id STP enabled interfaces
br-ffnl 8000.c2ab15e286df no bat0
tunneldigger 8000.0abeef250001 no
Das „tunneldigger“-Interface muss wohl auf auf bat0 zeigen oder?
Das „br-ffnl“ ist dann wohl ein überbeilbsel von der FastD Konfiguration?
Probiere ich gleich nach dem Mittagessen mal aus.
Grüße und Danke
Wer ist das? Ist das der Plasterouter oder Dein Server?
Poste doch mal das batctl if und brctl show „vom anderen“ bitte.
Moin,
das ist der Server:
root@v22017011140543301:~# batctl if
tunneldigger: active
root@v22017011140543301:~# brctl show
bridge name bridge id STP enabled interfaces
tunneldigger 8000.0abeef250001 no l2tp1061
Und das ist mein Test-Plaste-Router:
root@ffein98ded091ec3c:~# batctl if
ibss0: active
mesh-vpn: active
primary0: active
root@ffein98ded091ec3c:~# brctl show
bridge name bridge id STP enabled interfaces
br-client 7fff.98ded091ec3c no eth0
client0
bat0
br-wan 7fff.dad1fba113d8 no eth1Hmm. Ich kann wirklich nur jedem raten, sich auf gepflegte geskriptete Installationen zu stützen, sei es GitHub - ffnord/ffnord-puppet-gateway: Deploy and manage your Freifunk community gateway, mostly compatible with Gluon. (Puppet) oder GitHub - FreiFunkMuenster/Ansible-Freifunk-Gateway (Ansible) oder … Anders als beim cut&waste aus Webseiten kann man da nichts vergessen, und der Vorgang wird bei gleicher Eingabe das gleiche Ergebnis (oder einen Fehler) erzeugen. Ob man Salt, Ansible, Puppet, … nimmt, ist am Ende des Tages egal, wichtig ist, daß man bei einem Tool bleibt und dies konsequent für seine Server einsetzt. Denn nach dem 1. folgt das 2. Gateway (und damit ggf. die Notwendigkeit zur Vernetzung jenseits des Meshs), ab dem 37., voll vermaschten, Gateway möchte man die Ebenen (Mesh/Routing) vielleicht doch trennen, …
Moin da oben auf eine alte Version bezogen wird hier mal wie man die neuste version der ursprünglichen ersteller nutzt.Das ganze habe ich allerdings nur trocken und nicht im Wirkbetrieb getestet also ist das ganze experimentell!
Zudem handelt dies nur vom installieren und nicht Server einrichten oder routing sowie config, dadieses gleich bleibt
Zuerst mal die nötigen Pakete intallieren, dazu unter debian den folgenden command nehmen:
sudo apt-get install iproute bridge-utils libnetfilter-conntrack3 python-dev libevent-dev ebtables python-virtualenv libffi-dev libnfnetlink-dev libnetfilter-conntrack-dev
Anschließend erstellt ihr die nötigen Ordner, klont die source und erstellt das Virtual ENV für python. Dazu diese commands nehmen (Ps ab jetzt in der selben shell bleiben):
# Tunneldigger Ordner erstellen
mkdir -p /srv/tunneldigger
cd /srv/tunneldigger
# Python virtualenv erstellen
virtualenv env_tunneldigger
#tunneldigger clonen
cd /srv/tunneldigger
git clone https://github.com/wlanslovenija/tunneldigger.git
#virtual env aktivieren
source env_tunneldigger/bin/activate
Als nächstes installieren wir Tunneldigger. Dieser Teil ist anders als in der offiziellen Doku.
# In den richtigen ordner bewegen
cd /srv/tunneldigger/tunneldigger/broker
# Installiere tunneldigger in das virtuelle ENV
python setup.py install --prefix=/srv/tunneldigger/env_tunneldigger/
Nun noch eine Änderung in der start-broker.sh. Die legen wir wie oben schon genannt in /srv/tunneldigger/start-broker.sh an und die sieht so aus:
#!/bin/bash
WDIR=/srv/tunneldigger
VIRTUALENV_DIR=/srv/tunneldigger/env_tunneldigger
cd $WDIR
source $VIRTUALENV_DIR/bin/activate
$VIRTUALENV_DIR/bin/python -m tunneldigger_broker.main l2tp_broker.cfg
Ich hoffe ich habe keine Pfade zu dollProblematisiert und bei Fragen anpingen 
PS das ganze habe ich unter debian9 getestet
Da ich gerade den Kontext nicht habe: Die „offizielle Doku“ ist die hier oben aus dem Thread oder die der Tunneldigger-Maintainer?
Beide. Sowohl die von wlanslovenija als auch diese hier sind anders. Wieso die von wlanslovenija nicht geupdated wurde ist mir jedoch unbekannt
Mein großer Traum wäre ja noch immer ein Tunneldigger, der auch über IPv6 connectiert, damit man sich bei DSLite-Anschlüssen den Umwege über das CGN spart. (und ich weiss, dass es am wlanslovenija liegt.)
Naja es ist bei denen ja nen GSoC projekt also sollte das noch passsieren bald.
Ach PS falls jemand sich wundert woher ich die Installations anweisungen habe: Ich habe in deren openwrt paketen geguckt die haben ein broker openwrt paket
Ich weiß ja nicht wo Du guckst, aber die Doku ist aktuell.
https://tunneldigger.readthedocs.io/en/latest/index.html
Btw. Der aktuelle „Rewrite“ vom Tunneldigger performed extrem schlecht.
Sehr hohe CPU Load.
Gruß
@Comacho dein link sagt in der anleitung sagt pip install -r tunneldigger/broker/requirements.txt das ist allerdings nicht mehr korrekt mit dem aktuellsten master. die requirements.txt existiert nicht.
Wobei der running unten wieder korrekt ist
hi
gibt es dazu eine Lösung? Bisher war die Lösung eine alte Tunneldiggerversion zu verwenden. Problem dabei die läuft nicht unter Debian 9 weil wegen irgendein Kernelmodul (netconntrack oder so ähnlich, sry habs grad nicht ganz aufm Schirm) Speicherfehler um sich wirft und nicht startet.
mfg
Christian
@mtrnord
Oh das habe ich auch nicht gesehen 
Aber warum bist Du dann nicht so nett, und schickst ein PR, sodass
die Doku für alle wieder korrekt ist ?
@ChrisD
Nicht das ich wüsste, das mit Debian 9 ist mir auch neu.
Bei uns läuft der alte seit Ubuntu 14.04 ohne mukken,
aktuell auf Ubuntu 16.04 und mir ist kein vorteil gegenüber dem neuen bekannt.
Da Debian grundsätzlich ältere Pakete verwendet als Ubuntu,
fände ich das jetzt schon etwas komisch, das es nicht noch mehr aufgefallen ist.
Wenn du mal eine Fehlermeldung hast wo der Broker aussteigt,
könnte man mal schauen wodran es liegt.
ich hab leider grad kein System wo er aktuell läuft, habs eben aus Backlogs aus einen Channel gezogen:
root@:/home/# /srv/tunneldigger/env_tunneldigger/bin/python /srv/tunneldigger/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/tunneldigger/broker/ficht-broker.cfg
Speicherzugriffsfehler
und aus dmesg;
root@:/home/#[287591.857996] python[24138]: segfault at ffffffffa019a590 ip 00007ff9a861c753 sp 00007fff00a934a8 error 7 in libnetfilter_conntrack.so.3.6.0[7ff9a8614000+1c000]
[287691.691838] python[24448]: segfault at 194af590 ip 00007f26018e6753 sp 00007fff885276f8 error 6 in libnetfilter_conntrack.so.3.6.0[7f26018de000+1c000]
Konnten Kollegen auf weiteren Debian 9 Server nachvollziehen, scheint daher erstmal kein Einzelfall zu sein.
mfg
Christian
kommt wenn ich zeit habe aber ich glaube denen ist das bewusst der change ist nicht so alt 
Ich glaube nicht. Auf deren Mailingliste wird nämlich ein anderes GSOC-Projekt (eine Art Monitor-System) fleißig dokumentiert. Bzgl. V6 habe ich noch nichts gelesen. Ich glaube, es ist niemand gefunden worden, der das übernimmt.