L2TP/Tunneldigger Serverdoku-Thread


#9

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?)


#10
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


#11

Das ist bei meiner Installation der Stand:

Dort geht halt bisher nur ipv4

l2tpgw-doku.pdf (84,9 KB)


#12

Wer ist das? Ist das der Plasterouter oder Dein Server?

Poste doch mal das batctl if und brctl show “vom anderen” bitte.


#13

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        eth1

#14

Hmm. Ich kann wirklich nur jedem raten, sich auf gepflegte geskriptete Installationen zu stützen, sei es https://github.com/ffnord/ffnord-puppet-gateway (Puppet) oder https://github.com/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, …


#15

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 :slight_smile: PS das ganze habe ich unter debian9 getestet


#16

Da ich gerade den Kontext nicht habe: Die “offizielle Doku” ist die hier oben aus dem Thread oder die der Tunneldigger-Maintainer?


#17

Beide. Sowohl die von wlanslovenija als auch diese hier sind anders. Wieso die von wlanslovenija nicht geupdated wurde ist mir jedoch unbekannt


#18

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.)


#19

Naja es ist bei denen ja nen GSoC projekt :slight_smile: also sollte das noch passsieren bald.


#20

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 :slight_smile:


#21

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ß


#22

@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.


#23

Wobei der running unten wieder korrekt ist :slight_smile:


#24

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


#25

@mtrnord
Oh das habe ich auch nicht gesehen :smile:
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.


#26

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


#27

kommt wenn ich zeit habe aber ich glaube denen ist das bewusst der change ist nicht so alt :slight_smile:


#28

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.