Problem Tunneldigger

die anzahl der möglichen gateways scheint tunneldigger wieder aus dem konzept zu bringen.

(scheinbar gleiches problem wie 1.2.0~31 tunneldigger moag ni)

root@17258-Gutshof:/etc/config# /etc/init.d/tunneldigger restart
Stopping tunneldigger for interface mesh-vpn
start-stop-daemon: warning: killing process 5890: No such process
  tunneldigger stopped
Not starting tunneldigger - missing uuid

nach manuellem rauslöschen von einigen gateways aus der /etc/config/tunneldigger funktioniert der verbindungsaufbau wieder

DANKE! Ich habe das heute vormittag auf einer Test-4040 gsehen, daß TD nicht wollte, hatte aber keine Zeit mehr — Urlaub, Ankunft bis 19:00, 7 Stunden Fahrt minimum …

Und das beantwortet auch meine nächtlche Frage an mich selbst, »wieso eigentlich nur diese Auswahl?« Fsck, das Thema hatte ich echt nicht mehr auf der Pfanne. Sorry for that.

Ich habe mir gerade 9ln.netgln.net«, »gluon.net«) gesichtert, mit »l2tp-dus02.4830.org:10001» ⇒ »ld2.9ln.net:10001« wird aus …

wusel@luggage:~$ echo "/sbin/start-stop-daemon -S -q -b -m -c root:gluon-mesh-vpn -p /var/run/tunneldigger.mesh-vpn.pid -x /usr/bin/tunneldigger -- -u 744401748e8b -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10001 -b l2tp-ber02.4830.org:10001 -b l2tp-dus01.4830.org:10001 -b l2tp-dus02.4830.org:10001 -b l2tp-dus03.4830.org:10001 -b l2tp-dus04.4830.org:10001 -b l2tp-fra01.4830.org:10001 -b l2tp-fra02.4830.org:10001 -b l2tp-ham01.4830.org:10001 -b l2tp-ham02.4830.org:10001 -b l2tp-ham03.4830.org:10001 -b l2tp-ham04.4830.org:10001 -I br-wan -a"|wc 
      1      45     519

eine kürzere Kommandozeile:

wusel@luggage:~$ echo "/sbin/start-stop-daemon -S -q -b -m -c root:gluon-mesh-vpn -p /var/run/tunneldigger.mesh-vpn.pid -x /usr/bin/tunneldigger -- -u 744401748e8b -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10001 -b l2tp-ber02.4830.org:10001 -b l2tp-dus01.4830.org:10001 -b l2tp-dus02.4830.org:10001 -b l2tp-dus03.4830.org:10001 -b l2tp-dus04.4830.org:10001 -b l2tp-fra01.4830.org:10001 -b l2tp-fra02.4830.org:10001 -b l2tp-ham01.4830.org:10001 -b l2tp-ham02.4830.org:10001 -b l2tp-ham03.4830.org:10001 -b l2tp-ham04.4830.org:10001 -I br-wan -a"|sed -e 's/l2tp-/l/g' -e 's/dus0/d/g' -e 's/ber0/g/g' -e 's/fra0/f/g' -e 's/ham0/h/g' -e 's/4830.org/9ln.net/g' |wc
      1      45     423

Need to ponder 'bout this.

FTR, nächster Build läuft.

Kann bitte jemand es mal mit 1.2.0~55 ausprobieren? Bin im Urlaub nicht mit meinem üblicherweise verfügbaren Hardwarezoo ausgestattet :slight_smile:

~55 sieht gut aus. Router hier vor Ort ( 17258-Gutshof) hat sich heute/gestern Nacht das Update gezogen und läuft mit der Version ohne Probleme.

Bei einem Router im Feldberger Netz (17258-HDG-Offloader) wunder ich mich allerdings noch, was da das Problem ist. Der läuft mit 1.2.0~33 + deaktiviertem Autoupdate und ist auch zum gleichen Zeitpunkt wie die Kisten mit aktiviertem Autoupdate → rawhide ausm Netz verschwunden. Diese uuid fungiert wahrscheinlich als eine Art Schlüssel für den Tunnel oder? Vermutung: Router versucht aufgrund alter Config Verbindung auf Port 10001 aufzubauen und dazu passt die uuid jetzt nicht mehr. < wohl doch nicht. UUID wird ja offensichtlich anhand der NodeID erzeugt.

Danke für die Rückmeldung.

10001 ist Mesh 01, Stadt GT. Feldberger Knoten sollten über 10006 kommunizieren.

Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.