D-Link DAP-X1860 FF_OFFLINE_xxx

Nachdem die Hardware nun seit drei Monaten hier rum liegt, habe ich heute einen meiner D-Link DAP-X1860 geflashed.
Der Knoten wurde über https://setup.4830.org/ gefunden und eingerichtet, meldet sich dann aber nicht auf der Karte und schreit „FF_OFFLINE_xxx“.

Als IP-Adressen werden mir folgende zugewiesen:
fd10:ca1:1:0:51bc:85d6:7488:f804
fd10:ca1:1:0:c153:9d3e:a5ae:2a2d
fe80::3eb1:554e:b948:d294

Mein Setup ist etwas besonders, ich habe eine Vodafone Station im Bridge Modus, dahinter einen openwrt Router und dahinter dann den Freifunk Knoten.
Mit meinem alten NETGEAR WNDRMACv2 funktioniert Freifunk, wenn auch nur so lala von den Geschwindigkeiten her (etwa 8/8 bei einem 100/10 Anschluss).

Der Netgear läuft auf 1.4.0 der D-Link auf 1.6.0.

Was kann ich tun, damit der D-Link als Freifunk Knoten funktioniert?

Informationen zu batman-adv-Gateways ergibt: nichts

root@33332-Ottilienstr-4-edb8:~# batctl gwl
[B.A.T.M.A.N. adv 2023.1-openwrt-2, MainIF/MAC: primary0/ca:f3:0d:e3:15:73 (bat0/64:29:43:a4:ed:b8 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth

Paßt zu „FF_OFFLINE“, wie auch dieses:

=> keine Verbindung zu unseren Gateways.

Bitte mal brctl show und ps -w | grep tunnel machen …

  OS: 22.03.5, r20134-5f15225c1e          FW: 1.5.0~124                       
  HW: D-Link DAP-X1860 A1                                                 
root@33330-Muensterstr-3-1d80:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-wan		7fff.6a3fc4231458	no		lan
br-client		7fff.bc2228c91d80	no		bat0
							client1
							owe1
							client0
							owe0
							local-port
root@33330-Muensterstr-3-1d80:~# ps -w | grep tunnel
 3095 root      1140 S    /usr/bin/tunneldigger -u bc2228c91d80 -i mesh-vpn -t 1 -b g01m01.4830.org:10001 -b g02m01.4830.org:10001
 3124 nobody    1120 S    /usr/bin/tunneldigger -u bc2228c91d80 -i mesh-vpn -t 1 -b g01m01.4830.org:10001 -b g02m01.4830.org:10001
 3125 nobody    1120 S    /usr/bin/tunneldigger -u bc2228c91d80 -i mesh-vpn -t 1 -b g01m01.4830.org:10001 -b g02m01.4830.org:10001
 4869 root      1312 R    grep tunnel
root@33330-Muensterstr-3-1d80:~# batctl gwl
[B.A.T.M.A.N. adv 2022.0-openwrt-7, MainIF/MAC: primary0/6a:3f:c4:23:14:5b (bat0/bc:22:28:c9:1d:80 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  02:ca:ff:ee:01:10 ( 76) ce:ae:70:b7:74:31 [     mesh0]: 1024.0/1024.0 MBit
* 02:ca:ff:ee:01:04 ( 87) ce:ae:70:b7:74:35 [     mesh1]: 1024.0/1024.0 MBit
root@33330-Muensterstr-3-1d80:~# gluon-wan ping -4 g01m01.4830.org
PING g01m01.4830.org (193.26.120.99): 56 data bytes
64 bytes from 193.26.120.99: seq=0 ttl=53 time=32.982 ms
64 bytes from 193.26.120.99: seq=1 ttl=53 time=22.719 ms
64 bytes from 193.26.120.99: seq=2 ttl=53 time=23.328 ms
64 bytes from 193.26.120.99: seq=3 ttl=53 time=30.714 ms
^C
--- g01m01.4830.org ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 22.719/27.435/32.982 ms
root@33330-Muensterstr-3-1d80:~# logread | grep -i td-
Wed Jul 12 17:01:27 2023 daemon.info td-client: Selected g01m01.4830.org:10001 as the best broker.
Wed Jul 12 17:01:27 2023 daemon.info td-client: [g01m01.4830.org:10001] Tunnel successfully established.
Wed Jul 12 17:01:46 2023 daemon.info td-client: [g01m01.4830.org:10001] Setting MTU to 1364
root@33330-Muensterstr-3-1d80:~# batctl gwl
[B.A.T.M.A.N. adv 2022.0-openwrt-7, MainIF/MAC: primary0/6a:3f:c4:23:14:5b (bat0/bc:22:28:c9:1d:80 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  02:ca:ff:ee:01:04 (237) ce:ae:70:b7:74:35 [     mesh1]: 1024.0/1024.0 MBit
* 02:ca:ff:ee:01:10 (208) ce:ae:70:b7:74:35 [     mesh1]: 1024.0/1024.0 MBit
root@33330-Muensterstr-3-1d80:~# sleep 300 ; logread | grep -i td- ; batctl gwl
[B.A.T.M.A.N. adv 2022.0-openwrt-7, MainIF/MAC: primary0/6a:3f:c4:23:14:5b (bat0/bc:22:28:c9:1d:80 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  02:ca:ff:ee:01:04 (254) 02:ca:ff:ee:01:04 [  mesh-vpn]: 1024.0/1024.0 MBit
* 02:ca:ff:ee:01:10 (224) 02:ca:ff:ee:01:04 [  mesh-vpn]: 1024.0/1024.0 MBit

Zum einen dauert das nach dem Start, bis die VPN-Verbindung aufgebaut wird, zum anderen mit ping mal checken, ob die GWs per FQDN erreichbar sind. (gluon-wan sorgt für Namensauflösung über die WAN-Verbindung.)

g01m01.4830.org und g02m01.4830.org kann ich erreichen, 03-06 nicht

Was mir im logread auffällt, ist das falsche Datum. Dort stet „Jul 6 2023“.

root@33332-Ottilienstr-4-edb8:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-wan		7fff.caf30de31570	no		lan
br-client		7fff.642943a4edb8	no		bat0
							client1
							owe1
							client0
							owe0
							local-port
root@33332-Ottilienstr-4-edb8:~# ps -w | grep tunnel
 3113 root      1384 S    /usr/bin/tunneldigger -f -u 642943a4edb8 -i mesh-vpn -t 1 -b g01m01.4830.org:10001 -b g02m01.4830.org:100
 3121 nobody    1348 S    /usr/bin/tunneldigger -f -u 642943a4edb8 -i mesh-vpn -t 1 -b g01m01.4830.org:10001 -b g02m01.4830.org:100
 3122 nobody    1348 S    /usr/bin/tunneldigger -f -u 642943a4edb8 -i mesh-vpn -t 1 -b g01m01.4830.org:10001 -b g02m01.4830.org:100
20529 root      1376 S    grep tunnel
root@33332-Ottilienstr-4-edb8:~# batctl gwl
[B.A.T.M.A.N. adv 2023.1-openwrt-2, MainIF/MAC: primary0/ca:f3:0d:e3:15:73 (bat0/64:29:43:a4:ed:b8 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
root@33332-Ottilienstr-4-edb8:~# gluon-wan ping -4 g01m01.4830.org
PING g01m01.4830.org (193.26.120.99): 56 data bytes
64 bytes from 193.26.120.99: seq=0 ttl=57 time=21.973 ms
64 bytes from 193.26.120.99: seq=1 ttl=57 time=19.673 ms
64 bytes from 193.26.120.99: seq=2 ttl=57 time=19.932 ms
64 bytes from 193.26.120.99: seq=3 ttl=57 time=22.362 ms
^C
--- g01m01.4830.org ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 19.673/20.985/22.362 ms
root@33332-Ottilienstr-4-edb8:~# logread | grep -i td-
Thu Jul  6 19:18:56 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:18:56 2023 daemon.err tunneldigger[3113]: td-client: [g04m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:18:56 2023 daemon.err tunneldigger[3113]: td-client: [g05m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:18:56 2023 daemon.err tunneldigger[3113]: td-client: [g06m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:18:57 2023 daemon.info td-client: [g01m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.info td-client: [g02m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.info td-client: [g03m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.info td-client: [g04m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.err tunneldigger[3113]: td-client: [g04m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.info td-client: [g05m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.err tunneldigger[3113]: td-client: [g05m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.info td-client: [g06m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:18:57 2023 daemon.err tunneldigger[3113]: td-client: [g06m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:00 2023 daemon.err td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:00 2023 daemon.err td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:00 2023 daemon.err td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:00 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:00 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:00 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:01 2023 daemon.info td-client: [g01m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:01 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:01 2023 daemon.info td-client: [g02m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:01 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:01 2023 daemon.info td-client: [g03m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:01 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:01 2023 daemon.err td-client: [g04m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:01 2023 daemon.err td-client: [g05m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:01 2023 daemon.err td-client: [g06m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:01 2023 daemon.err tunneldigger[3113]: td-client: [g04m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:01 2023 daemon.err tunneldigger[3113]: td-client: [g05m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:01 2023 daemon.err tunneldigger[3113]: td-client: [g06m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:02 2023 daemon.info td-client: [g04m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:02 2023 daemon.err tunneldigger[3113]: td-client: [g04m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:02 2023 daemon.info td-client: [g05m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:02 2023 daemon.err tunneldigger[3113]: td-client: [g05m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:02 2023 daemon.info td-client: [g06m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:02 2023 daemon.err tunneldigger[3113]: td-client: [g06m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:03 2023 daemon.err td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:03 2023 daemon.err td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:03 2023 daemon.err td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:03 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:03 2023 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Thu Jul  6 19:19:03 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:03 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:03 2023 daemon.err tunneldigger[3113]: td-client: No suitable brokers found. Retrying in 5 seconds
Thu Jul  6 19:19:09 2023 daemon.info td-client: Performing broker selection...
Thu Jul  6 19:19:09 2023 daemon.err tunneldigger[3113]: td-client: Performing broker selection...
Thu Jul  6 19:19:12 2023 daemon.err td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err td-client: [g04m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err td-client: [g05m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err td-client: [g06m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err tunneldigger[3113]: td-client: [g04m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err tunneldigger[3113]: td-client: [g05m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:12 2023 daemon.err tunneldigger[3113]: td-client: [g06m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:13 2023 daemon.info td-client: [g01m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.info td-client: [g02m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.info td-client: [g03m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.info td-client: [g04m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.err tunneldigger[3113]: td-client: [g04m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.info td-client: [g05m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.err tunneldigger[3113]: td-client: [g05m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.info td-client: [g06m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:13 2023 daemon.err tunneldigger[3113]: td-client: [g06m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:16 2023 daemon.err td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:16 2023 daemon.err td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:16 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:16 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:17 2023 daemon.info td-client: [g01m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:17 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:17 2023 daemon.info td-client: [g02m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:17 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:17 2023 daemon.err td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:17 2023 daemon.err td-client: [g04m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:17 2023 daemon.err td-client: [g05m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:17 2023 daemon.err td-client: [g06m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:17 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:17 2023 daemon.err tunneldigger[3113]: td-client: [g04m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:17 2023 daemon.err tunneldigger[3113]: td-client: [g05m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:17 2023 daemon.err tunneldigger[3113]: td-client: [g06m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:18 2023 daemon.info td-client: [g03m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:18 2023 daemon.err tunneldigger[3113]: td-client: [g03m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:18 2023 daemon.info td-client: [g04m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:18 2023 daemon.err tunneldigger[3113]: td-client: [g04m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:18 2023 daemon.info td-client: [g05m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:18 2023 daemon.err tunneldigger[3113]: td-client: [g05m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:18 2023 daemon.info td-client: [g06m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:18 2023 daemon.err tunneldigger[3113]: td-client: [g06m01.4830.org:10001] Reinitializing tunnel context.
Thu Jul  6 19:19:20 2023 daemon.err td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:20 2023 daemon.err td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:20 2023 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Thu Jul  6 19:19:20 2023 daemon.err tunneldigger[3113]: td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:20 2023 daemon.err tunneldigger[3113]: td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Thu Jul  6 19:19:20 2023 daemon.err tunneldigger[3113]: td-client: No suitable brokers found. Retrying in 5 seconds
[...]
root@33332-Ottilienstr-4-edb8:~# batctl gwl
[B.A.T.M.A.N. adv 2023.1-openwrt-2, MainIF/MAC: primary0/ca:f3:0d:e3:15:73 (bat0/64:29:43:a4:ed:b8 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth

Habe nun zuerst die /etc/hosts Datei angepasst und es tut.

root@33332-Ottilienstr-4-edb8:~# cat /etc/hosts 
127.0.0.1 localhost

193.26.120.99	g02m01.4830.org g03m01.4830.org g04m01.4830.org g05m01.4830.org g06m01.4830.org
2a06:e881:1706:1:0:c1ff:fe1a:7863   g02m01.4830.org g03m01.4830.org g04m01.4830.org g05m01.4830.org g06m01.4830.org

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Danach habe ich die Änderungen an /etc/hosts wieder auskommentiert und tunneldigger.mesh_vpn.address geändert, das tut nicht.

root@33332-Ottilienstr-4-edb8:~# uci set tunneldigger.mesh_vpn.address='g01m01.4830.org:10001'
root@33332-Ottilienstr-4-edb8:~# uci add_list tunneldigger.mesh_vpn.address='g02m01.4830.org:10001'
root@33332-Ottilienstr-4-edb8:~# uci commit

Also wieder die /etc/hosts Datei angepasst, nun aber mit den richtigen Einträgen für die gw und es tut und das Datum wurde auch korrekt gesetzt.

root@33332-Ottilienstr-4-edb8:~# cat /etc/hosts 
127.0.0.1 localhost
193.26.120.99                           g01m01.4830.org
2a06:e881:1706:1:0:c1ff:fe1a:7863       g01m01.4830.org
193.26.120.227                          g02m01.4830.org
2a06:e881:1707:1:400:c1ff:fe1a:78e3     g02m01.4830.org
193.26.120.125                          g03m01.4830.org
2a06:e881:1702:1:400:c1ff:fe1a:787d     g03m01.4830.org
193.26.120.245                          g04m01.4830.org
2a06:e881:2604:42:400:c1ff:fe1a:78f5    g04m01.4830.org
 
#193.26.120.99	g02m01.4830.org g03m01.4830.org g04m01.4830.org g05m01.4830.org g06m01.4830.org
#2a06:e881:1706:1:0:c1ff:fe1a:7863   g02m01.4830.org g03m01.4830.org g04m01.4830.org g05m01.4830.org g06m01.4830.org

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
root@33332-Ottilienstr-4-edb8:~# logread | grep -i td-
[...]
Tue Mar 19 21:08:57 2024 daemon.err tunneldigger[3037]: td-client: Performing broker selection...
Tue Mar 19 21:08:58 2024 daemon.debug td-client: [g01m01.4830.org:10001] Broker usage: 4356
Tue Mar 19 21:08:58 2024 daemon.info td-client: Selected g01m01.4830.org:10001 as the best broker.
Tue Mar 19 21:08:58 2024 daemon.err tunneldigger[3037]: td-client: [g01m01.4830.org:10001] Broker usage: 4356
Tue Mar 19 21:08:58 2024 daemon.err tunneldigger[3037]: td-client: Selected g01m01.4830.org:10001 as the best broker.
Tue Mar 19 21:08:59 2024 daemon.info td-client: [g01m01.4830.org:10001] Tunnel successfully established.
Tue Mar 19 21:08:59 2024 daemon.err tunneldigger[3037]: td-client: [g01m01.4830.org:10001] Tunnel successfully established.
Tue Mar 19 21:09:05 2024 daemon.info td-client: [g01m01.4830.org:10001] Setting MTU to 1364
Tue Mar 19 21:09:05 2024 daemon.err tunneldigger[3037]: td-client: [g01m01.4830.org:10001] Setting MTU to 1364

Woher soll er ein anderes als das Builddatum als Ausgangspunkt haben ohne Verbindung ins Mesh?

  OS: 23.05-SNAPSHOT, r23481+10-02ed2b    FW: 1.6.0~52                        
  HW: Ubiquiti UniFi AP Pro                                               
root@33332-Schalueckstr-107-11d9:~# logread 
Sun Oct 15 19:36:57 2023 kern.notice kernel: [    0.000000] Linux version 5.15.132 (ffgt@build.container) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23481+9-02ed2b0271) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 Sun Oct 15 17:35:45 2023
Sun Oct 15 19:36:57 2023 kern.info kernel: [    0.000000] printk: bootconsole [early0] enabled
Sun Oct 15 19:36:57 2023 kern.info kernel: [    0.000000] CPU0 revision is: 0001
[…]
root@33332-Schalueckstr-107-11d9:~# uname -a
Linux 33332-Schalueckstr-107-11d9 5.15.132 #0 Sun Oct 15 17:35:45 2023 mips GNU/Linux

Sprich: Zum Bootzeitpunkt wird die Uhrzeit auf den Buildzeitpunkt gesetzt. Kaum ein WLAN-Router hat einen batteriegestützte RTC — genausowenig wie ein Raspberry Pi.

Das ist nicht gut. Was sagt cat /var/gluon/wan-dnsmasq/resolv.conf und paßt das zu ip addr show br-wan?

root@33332-Schalueckstr-107-11d9:~# cat /var/gluon/wan-dnsmasq/resolv.conf
nameserver fe80::eade:27ff:fed6:8676%br-wan
nameserver 2001:678:2c0:1::1
nameserver 192.168.5.31
nameserver 192.168.5.33
nameserver 8.8.8.8
root@33332-Schalueckstr-107-11d9:~# ip addr show br-wan
8: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 66:f8:11:2e:c1:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.180/24 brd 192.168.5.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 2a06:e881:260c:1:64f8:11ff:fe2e:c108/64 scope global dynamic noprefixroute 
       valid_lft 86380sec preferred_lft 14380sec
    inet6 fe80::64f8:11ff:fe2e:c108/64 scope link 
       valid_lft forever preferred_lft forever

IIRC werden nur die ersten 3 NS überhaupt verwendet, aber das ›Wissen‹ ist 20+ Jahre alt und ob das 3x v6 und 3x v4 bedeutet und wie das bei der µlibc ausssieht …

… IMHO ›sicher‹ ist, daß v6-NS nicht funktionieren, da jene über das Mesh laufen (oder gar nicht, die IPv6-WAN-Routingtabelle ist bei mir zumindest leer):

root@33332-Schalueckstr-107-11d9:~# ip route get 2001:678:2c0:1::1
2001:678:2c0:1::1 from :: via fe80::f0be:efff:fe00:110 dev br-client  src 2001:bf7:1310:128:26a4:3cff:feb1:11d9  metric 512
root@33332-Schalueckstr-107-11d9:~# ip -6 rule show
0:	from all lookup local 
1:	from all fwmark 0x1/0x1 lookup 1 
10000:	from 2a06:e881:260c:1:64f8:11ff:fe2e:c108 lookup 1 
20000:	from all to 2a06:e881:260c:1:64f8:11ff:fe2e:c108/64 lookup 1 
32766:	from all lookup main 
4200000012:	from all iif br-client lookup unspec 12
root@33332-Schalueckstr-107-11d9:~# ip -6 route show table 1
root@33332-Schalueckstr-107-11d9:~# 

Hmm …

Ja, wie gesagt, zum Debugging brauche ich diese Info:

root@33332-Ottilienstr-4-edb8:~# cat /var/gluon/wan-dnsmasq/resolv.conf
nameserver fd6c:4282:f889::1
nameserver 192.168.1.1
root@33332-Ottilienstr-4-edb8:~# ip addr show br-wan
8: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether ca:f3:0d:e3:15:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.138/24 brd 192.168.1.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 fd6c:4282:f889:0:c8f3:dff:fee3:1570/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2a02:908:d517:de80:c8f3:dff:fee3:1570/64 scope global dynamic noprefixroute 
       valid_lft 77000sec preferred_lft 33800sec
    inet6 fd6c:4282:f889::b38/128 scope global dynamic noprefixroute 
       valid_lft 41362sec preferred_lft 33801sec
    inet6 2a02:908:d517:de80::b38/128 scope global dynamic noprefixroute 
       valid_lft 41362sec preferred_lft 33801sec
    inet6 fe80::c8f3:dff:fee3:1570/64 scope link 
       valid_lft forever preferred_lft forever

Beim eigenhändigen Stöbern ist mir aufgefallen, dass in logread eine andere resolvconf auftaucht, die auch im uci eingestellt ist.

root@33332-Ottilienstr-4-edb8:~# logread | grep dns
Tue Mar 19 21:09:03 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Tue Mar 19 21:09:03 2024 daemon.info dnsmasq[1]: using nameserver 2001:bf7:1310:128::4#53
Tue Mar 19 21:09:03 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Tue Mar 19 21:09:15 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Tue Mar 19 21:09:15 2024 daemon.info dnsmasq[1]: using nameserver 2001:bf7:1310:128::4#53
Tue Mar 19 21:09:15 2024 daemon.info dnsmasq[1]: using nameserver 2001:bf7:1310:128::a#53
Tue Mar 19 21:09:15 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
root@33332-Ottilienstr-4-edb8:~# uci show | grep resolvfile
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.d/resolv.conf.auto'
root@33332-Ottilienstr-4-edb8:~# cat /tmp/resolv.conf.d/resolv.conf.auto 
# Interface client
nameserver 2001:bf7:1310:128::4
nameserver 2001:bf7:1310:128::a
search 4830.org
# Interface wan
# Interface wan6

Gluon hat zwei Nameserver laufen.

root@33332-Schalueckstr-107-11d9:~# ps -w | grep dnsmasq
 1117 root      2880 S    {dnsmasq} /sbin/ujail -t 5 -n dnsmasq -u -l -r /bin/ubus -r /etc/TZ -r /etc/dnsmasq.conf -r /etc/ethers -
 1136 dnsmasq   2948 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
 2722 root      2992 S    /usr/sbin/dnsmasq -u root -i lo -p 54 -h -k -c 0 -r /var/gluon/wan-dnsmasq/resolv.conf
15251 root      1372 S    grep dnsmasq

Einmal auf localhost:53, der wird in /etc/resolv.conf referenziert und gilt für alles, nutzt die über’s Mesh gelernten NS:

root@33332-Schalueckstr-107-11d9:~# cat  /etc/resolv.conf
search lan
nameserver 127.0.0.1
nameserver ::1

Und einen auf Port 54, der die WAN-Resolver nutzt, siehe Doku.

Änderungen an /etc/hosts sind nicht updatefest; WAN-DNS muß funktionieren …

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

Done. (Hast Du ein Abzeichen für »ersten gemeldeten Eintrag hier ever« bekommen? Falls nicht, fühle Dich entsprechend ausgezeichnet :wink:)

Habe ich nicht bekommen :sob:

Aber zurück zum Thema.
Nach dem Netzumbau passten die manuell eingetragenen IP-Adressen in /etc/hosts natürlich nicht mehr und ich habe das zum Anlass genutzt, um weiterzuprobieren.

Zunächst habe ich mit firstboot den Knoten wieder in einen unkonfigurierten Zustand gebracht.
Wie zu erwarten hat das im gleichen Fehlerbild geendet.
Danach über gluon-enter-setup-mode wieder in den setup-mode gebracht und IPv6 deaktiviert, ebenfalls ohne Besserung. Also wieder aktiviert.

Das Problem ist weiterhin die Namensauflösung von g01m01.4830.org und so weiter.

root@33332-Ottilienstr-4-edb8:~# logread
[...]
Sun May 19 11:41:11 2024 daemon.err tunneldigger[2959]: td-client: [g01m01.4830.org:10001] Hostname resolution timed out.
Sun May 19 11:41:11 2024 daemon.err tunneldigger[2959]: td-client: [g02m01.4830.org:10001] Hostname resolution timed out.
Sun May 19 11:41:11 2024 daemon.err tunneldigger[2959]: td-client: [g03m01.4830.org:10001] Hostname resolution timed out.
Sun May 19 11:41:11 2024 daemon.err tunneldigger[2959]: td-client: [g04m01.4830.org:10001] Hostname resolution timed out.
Sun May 19 11:41:11 2024 daemon.err tunneldigger[2959]: td-client: [g05m01.4830.org:10001] Hostname resolution timed out.
Sun May 19 11:41:11 2024 daemon.err tunneldigger[2959]: td-client: [g06m01.4830.org:10001] Hostname resolution timed out.

[...]

nslookup liefert ein REFUSED

root@33332-Ottilienstr-4-edb8:~# nslookup g01m01.4830.org
Server:		127.0.0.1
Address:	127.0.0.1:53

** server can't find g01m01.4830.org: REFUSED

** server can't find g01m01.4830.org: REFUSED

Über gluon-wan nslookup geht es

root@33332-Ottilienstr-4-edb8:~# gluon-wan nslookup g01m01.4830.org
Server:		127.0.0.1
Address:	127.0.0.1:53

Non-authoritative answer:
g01m01.4830.org	canonical name = ngw-ber01.4830.org
Name:	ngw-ber01.4830.org
Address: 194.113.54.80

Non-authoritative answer:
g01m01.4830.org	canonical name = ngw-ber01.4830.org
Name:	ngw-ber01.4830.org
Address: 2a06:e881:1706:11:0:c2ff:fe71:3650

Nun in /etc/resolv.conf einen anderen Nameserver (lokaler Router) eingetragen und es geht

root@33332-Ottilienstr-4-edb8:~# cat /etc/resolv.conf 
search lan
nameserver 192.168.1.1
nameserver 127.0.0.1
nameserver ::1

Nun die eigentliche Frage: Was hat es mit search lan auf sich? Und könnte es zu einem Problem führen, dass ich .lan als lokale Domain verwende?

Das ist auch faktisch der Weg, über den tunneldigger das Resolving macht, also alles korrekt.

Nein, solange man FQDNs benutzt, greift die Searchlist eh’ nicht:

Und wie gesagt, die /etc/resolv.conf (Symlink auf /tmp/resolv.conf) greift für alle OpenWrt-Prozesse, die DNS-Server des Meshes nutzend — durch einen Eintrag nameserver 127.0.0.1 wird der lokale dnsmasq gefragt, der auf /tmp/resolv.conf.auto zurückgreift.

Gluon-Prozesse, die mit dem WAN hantieren, greifen – mittelkomplex über iptables gelöst – auf einen dnsmasq-Prozeß zu, der auf Port 54 läuft und /var/gluon/wan-dnsmasq/resolv.conf nutzt, bei mir:

 root@33378-test-20240502:~# cat /var/gluon/wan-dnsmasq/resolv.conf 
 nameserver fd00::9a9b:cbff:feb1:1397
 nameserver 2003:ef:9f17:8900:9a9b:cbff:feb1:1397
 nameserver 192.168.177.9
 nameserver 192.168.177.1
 nameserver 8.8.8.8

Es ist diese iptables-Regel, die die Zugriffe auf 127.0.0.1:53 von Prozessen mit der GID 800 auf 127.0.0.1:54 umbiegt:

Chain OUTPUT (policy ACCEPT 1107 packets, 164K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 371K   23M DNAT       udp  --  *      lo      0.0.0.0/0            127.0.0.1            owner GID match 800 udp dpt:53 to::54

gluon-wan sorgt dafür, daß der ausgeführte Prozeß ensprechend gestartet wird:

 root@33378-test-20240502:~# gluon-wan id
 uid=0(root) gid=800(gluon-mesh-vpn)

Gluon ist an manchen Stellen schon recht komplex :wink: Dieser Beiträg könnte auch unter Erklärbar stehen …

Also zusammengefaßt:

  • DNS-Debugging bzgl. WAN geht nur über gluon-wan nslookup ... o. ä.
  • Welche DNS-Resolver im WAN benutzt werden, steht letztlich in /var/gluon/wan-dnsmasq/resolv.conf
  • Mit WAN-Resolvern reden bei Gluon nur Prozesse, die mit der Group-ID 800 laufen; z. B. der tunneldigger-Prozeß
  • »Normales« Debugging führt schnell in die Irre, da dann die Mesh-Resolver genommen werden — die es aber ohne Mesh-Verbindung gar nicht gibt.

Und un zu Deinem Problem:

So, und das darf nicht vorkommen, wenn gleichzeitig dies geht:

Siehe Beitrag davor, tunneldigger läuft in der FW als gid 800, und gid-800-Prozesse nutzen effektiv 127.0.0.1:54 bei der Namenauflösung, genau wie Prozesse, die mit gluon-wan gestartet werden. Wenn gluon-wan nslookup g01m01.4830.org funktioniert, muß das auch beim tunneldigger-Prozeß tun, ich sehe technisch nicht, wie das eine funktioniere sollte und das andere nicht.

Und bitte nicht händisch auf dem Knoten arbeiten, wenn man nicht genau weiß, was man tut :wink: Denn …

… sorgt dafür, daß praktisch DNS-Anfragen alle über 192.168.1.1 laufen:

The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.

Sollten wir z. B. anfangen, split-horizon zu fahren – Anfragen aus dem Mesh bekommen andere Antworten als Anfragen aus dem Internet –, wird ggf. was anderes ins Essen brechen :wink:

habs erstmal wieder rückgängig gemacht und nehme den Knoten nachher mit zu einem anderen Netz, damit ich prüfen kann, ob es am Knoten oder am Netz liegt

1 Like

Auch im Makerspace habe ich das gleiche Verhalten, scheint also irgendwie am Gerät zu liegen.

Ich habe noch einen ungeflashten zu Hause, den ich noch gegenprüfen kann und an dem ich dokumentieren kann, wie ich flashe

PS: Das Zertifikat für setup.4830.org ist am 25.5.2024 abgelaufen.

Interessant …

Yepp, fixed — Hintergründe an anderer Stelle.

Habe nun meinen zweiten Router aus dem Set nach der Anleitung von FF Darmstadt aufgesetzt.
Mit 1.6.0 gibt es das gleiche Fehlerbild, mit 1.6.1. geht es :man_shrugging:

Kann ich noch was an Logs liefern, um das Problem im Nachhinein zu ergründen?

Danke für den Hinweis. Ggf. ist dann in 1.6.0 tatsächlich was vermurkst gewesen — 1.6.0 basierte auf eher experimentellen Versionen von Gluon v2023+ bzw. OpenWrt (um weitere Geräte zu unterstützen), 1.6.1 auf erprobtem Gluon v2022.1.4. Ein testweise auf 1.6.1 gezogener 4300er im virtuellen Niedersachsen tut jedenfalls ebenfalls weiterhin problemlos mit WAN.

Werde mal limitierten v2023er Build machen, dann kann man gucken, ob das da wieder auftaucht …