1.2.0~31 tunneldigger moag ni

OS: 18.06-SNAPSHOT, r8067+28-6d94a6e FW: 1.2.0~31
HW: Ubiquiti UniFi-AC-MESH

im 5 min. Takt:

Thu Nov 4 18:50:01 2021 user.notice tunneldiger-watchdog: Daemon not running, restarted tunneldigger. Thu Nov 4 18:50:03 2021 kern.info kernel: [10242.780265] IPv6: ADDRCONF(NETDEV_UP): tmp.mesh1: link is not ready

von Hand gestartet lässt sich Tunneldigger zu einer Verbindung überreden:

root@17258-Gutshof:~# tunneldigger -u 788a20706785 -i mesh-vpn -b l2tp-ber01.4830.org:10006

ergibt:

Thu Nov  4 20:40:01 2021 daemon.info td-client: Performing broker selection...
Thu Nov  4 20:40:02 2021 daemon.debug td-client: Broker usage of l2tp-ber01.4830.org:10006: 0
Thu Nov  4 20:40:02 2021 daemon.info td-client: Selected l2tp-ber01.4830.org:10006 as the best broker.
Thu Nov  4 20:40:03 2021 kern.info kernel: [16842.875617] IPv6: ADDRCONF(NETDEV_UP): tmp.mesh1: link is not ready
Thu Nov  4 20:40:03 2021 daemon.info td-client: Tunnel successfully established.
Thu Nov  4 20:40:03 2021 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Thu Nov  4 20:40:03 2021 daemon.notice netifd: Network device 'mesh-vpn' link is up
Thu Nov  4 20:40:03 2021 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Thu Nov  4 20:40:03 2021 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Thu Nov  4 20:40:03 2021 daemon.notice netifd: Interface 'mesh_vpn' is now up
Thu Nov  4 20:40:04 2021 kern.info kernel: [16843.939115] batman_adv: bat0: Adding interface: mesh-vpn
Thu Nov  4 20:40:04 2021 kern.info kernel: [16843.944613] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1364) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Thu Nov  4 20:40:04 2021 kern.info kernel: [16843.969700] batman_adv: bat0: Interface activated: mesh-vpn
Thu Nov  4 20:40:04 2021 user.notice firewall: Reloading firewall due to ifup of mesh_vpn (mesh-vpn)
Thu Nov  4 20:40:08 2021 daemon.info dnsmasq[1066]: reading /tmp/resolv.conf.auto
Thu Nov  4 20:40:08 2021 daemon.info dnsmasq[1066]: using local addresses only for domain lan
Thu Nov  4 20:40:08 2021 daemon.info dnsmasq[1066]: using nameserver 2001:bf7:170:64::4#53
Thu Nov  4 20:40:08 2021 user.notice firewall: Reloading firewall due to ifupdate of client (br-client)
Thu Nov  4 20:40:10 2021 daemon.info td-client: Setting MTU to 1364
Thu Nov  4 20:40:16 2021 daemon.info dnsmasq[1066]: reading /tmp/resolv.conf.auto
Thu Nov  4 20:40:16 2021 daemon.info dnsmasq[1066]: using local addresses only for domain lan
Thu Nov  4 20:40:16 2021 daemon.info dnsmasq[1066]: using nameserver 2001:bf7:170:64::4#53
Thu Nov  4 20:40:16 2021 daemon.info dnsmasq[1066]: using nameserver 2001:bf7:170:64::a#53

bin gerade etwas planlos, wo ich nach Ursachen suchen könnte

Ui, da ist wer mutig :wink:

Hmm.

  OS: 18.06-SNAPSHOT, r8067+28-6d94a6e    FW: 1.2.0~30                        
  HW: NETGEAR WNDRMACv2

Du hast recht :frowning:

root@33332-Schalueckstr-107-8e8b:~# (logread -f | grep -v bird6) &
root@33332-Schalueckstr-107-8e8b:~# /etc/init.d/tunneldigger restart
Stopping tunneldigger for interface mesh-vpn
start-stop-daemon: warning: killing process 30990: No such process
  tunneldigger stopped
Not starting tunneldigger - missing uuid
Starting tunneldigger on mesh-vpn
root@33332-Schalueckstr-107-8e8b:~# ps w | grep -i pyth
31132 root      1200 S    grep -i pyth
root@33332-Schalueckstr-107-8e8b:~# ps w | grep -i tun
31134 root      1200 S    grep -i tun
root@33332-Schalueckstr-107-8e8b:~# /etc/init.d/tunneldigger stop
Stopping tunneldigger for interface mesh-vpn
start-stop-daemon: warning: killing process 31058: No such process
  tunneldigger stopped
root@33332-Schalueckstr-107-8e8b:~# /etc/init.d/tunneldigger start
Not starting tunneldigger - missing uuid
Starting tunneldigger on mesh-vpn
root@33332-Schalueckstr-107-8e8b:~# logger foo
Fri Nov  5 00:36:52 2021 user.notice root: foo
root@33332-Schalueckstr-107-8e8b:~# batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-13, MainIF/MAC: primary0/56:92:c9:3e:87:63 (bat0/74:44:01:74:8e:8b BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  02:ca:ff:ee:01:09 (210) 66:f8:11:2e:c1:09 [     mesh1]: 1024.0/1024.0 MBit
  02:ca:ff:ee:01:02 (198) 66:f8:11:2e:c1:09 [     mesh1]: 1024.0/1024.0 MBit
* 02:ca:ff:ee:01:04 (224) 66:f8:11:2e:c1:09 [     mesh1]: 1024.0/1024.0 MBit
  02:ca:ff:ee:01:10 (198) 66:f8:11:2e:c1:09 [     mesh1]: 1024.0/1024.0 MBit
root@33332-Schalueckstr-107-8e8b:~#

1.2.0 basiert auf Gluon 2019.1 (statt vormals 2018.2); soweit ich das aktuell sehe, startet /etc/init.d/tunneldigger start nicht wegen fehlender UUID. Allerdings:

+ config_get broker_selection mesh_vpn broker_selection
+ eval export -n -- 'broker_selection=${CONFIG_mesh_vpn_broker_selection:-${4}}'
+ export -n -- 'broker_selection='
+ '[' 1 -eq 0 ]
+ local 'broker_opts='
+ '[' '!' -z  ]
+ '[' '!' -z  ]
+ '[' '!' -z  ]
+ '[' '!' -z  ]
+ '[' -z  ]
+ missing uuid
+ echo 'Not starting tunneldigger - missing uuid'
Not starting tunneldigger - missing uuid
+ return
+ option uuid 744401748e8b
+ local 'varname=uuid'
+ shift
+ local 'value=744401748e8b'
+ config_set mesh_vpn uuid 744401748e8b
+ local 'section=mesh_vpn'
+ local 'option=uuid'
+ local 'value=744401748e8b'
+ export -n 'CONFIG_mesh_vpn_uuid=744401748e8b'

Sprich: UUID ist da.

Evtl. bricht das wegen der Länge der Kommandozeile ins Essen?

+ /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

Es wurden weitere – potentielle – Gateways hinzugefügt, auf meinem Knoten kann ich obige Kommandozeile nicht eingeben — »r-wan -a« paßt nicht mehr in den Buffer. Mit verkürzter Zeile kann ich’s starten:

root@33332-Schalueckstr-107-8e8b:~# /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 l
2tp-dus01.4830.org:10001 -b l2tp-dus02.4830.org:10001  -b l2tp-fra01.4830.org:10001 -b l2tp-fra02.4830.org:10001 -b l2tp-ham01.4
830.org:10001 -b l2tp-ham02.4830.org:10001 -b l2tp-ham03.4830.org:10001 -b l2tp-ham04.4830.org:10001 -I br-wan -a
+ /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-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
root@33332-Schalueckstr-107-8e8b:~# ps w | grep -i pyth
+ + grep -i pyth
ps w
 4275 root      1200 S    grep -i pyth
root@33332-Schalueckstr-107-8e8b:~# ps w | grep -i tunn
+ + grep -i tunn
ps w
 3812 root      1040 D    /usr/bin/tunneldigger -u 744401748e8b -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10001 -b l2tp-ber02.4830.or
 3813 nobody    1012 S    /usr/bin/tunneldigger -u 744401748e8b -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10001 -b l2tp-ber02.4830.or
 3814 nobody    1012 S    /usr/bin/tunneldigger -u 744401748e8b -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10001 -b l2tp-ber02.4830.or
 4466 root      1200 S    grep -i tunn
root@33332-Schalueckstr-107-8e8b:~# batctl gwl
+ batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-13, MainIF/MAC: primary0/56:92:c9:3e:87:63 (bat0/74:44:01:74:8e:8b BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  02:ca:ff:ee:01:09 (207) 02:ca:ff:ee:01:10 [  mesh-vpn]: 1024.0/1024.0 MBit
  02:ca:ff:ee:01:02 (207) 02:ca:ff:ee:01:10 [  mesh-vpn]: 1024.0/1024.0 MBit
* 02:ca:ff:ee:01:04 (225) 66:f8:11:2e:c1:09 [     mesh1]: 1024.0/1024.0 MBit
  02:ca:ff:ee:01:10 (238) 02:ca:ff:ee:01:10 [  mesh-vpn]: 1024.0/1024.0 MBit
root@33332-Schalueckstr-107-8e8b:~#

Ich bau’ mal eine ~32 mit weniger Gateways, vielleicht liegt’s ja wirklich daran.

  OS: 18.06-SNAPSHOT, r8067+28-6d94a6e    FW: 1.2.0~32                        
  HW: NETGEAR WNDRMACv2                                                   
root@33332-Schalueckstr-107-8e8b:~# ps w | grep tunn
 2030 root      1044 S    /usr/bin/tunneldigger -u 744401748e8b -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10001 -b l2tp-ber02.4830.or
 2034 nobody    1016 S    /usr/bin/tunneldigger -u 744401748e8b -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10001 -b l2tp-ber02.4830.or
 2035 nobody    1016 S    /usr/bin/tunneldigger -u 744401748e8b -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10001 -b l2tp-ber02.4830.or
 3032 root      1200 S    grep tunn

Scheint zu tun … Danke für den Hinweis, @charrr!

Auch bei Dir, @charrr?

tut! zumindest bei mir zuhause nach manuellem anstoßen des updates (+ ergänzen eines ext. nameservers in der resolv.conf, weil sonst der updateserver nicht gefunden wurde)

in diesem fall eher ‚blöd‘: auf quasi allen knoten, die ich in feldberg eingerichtet hab ist rawhide druff + auf autoupdate und wie es aussieht, wollen/können die sich das update auf ~33 nicht ziehen. werde wohl mal eine kleine stadtrundfahrt machen nächste woche.

Mea culpa; aber ja, das ist da Problem von »rawhide«: das fällt aus dem Compiler ins Firmware-Verzeichnis und sollte nur auf Knoten benutzt werden, auf die man schnellen, direkten Zugriff hat — gerade weil Probleme ggf. erst auf den Geräten auffallen. (Hier war es mir z. B. gar nicht aufgefallen, da der Knoten über einen zweiten online blieb.)

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