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?
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.)
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
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:~#
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
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
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:
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 bittenichthändisch auf dem Knoten arbeiten, wenn man nicht genau weiß, was man tut 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
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
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
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 …
)
