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