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