1.2.0~31 tunneldigger moag ni

charrr · 4. November 2021 um 20:01

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

wusel · 5. November 2021 um 00:21

Ui, da ist wer mutig

Hmm.

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

Du hast recht

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.

wusel · 5. November 2021 um 05:11

  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!

wusel · 6. November 2021 um 03:56

Auch bei Dir, @charrr?

charrr · 6. November 2021 um 14:27

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.

wusel · 6. November 2021 um 16:10

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