Raspberry Pi 2 - Keine Verbindung / Fehlersuche

xmas · 21. Oktober 2017 um 19:38

Hallo zusammen,

um meinen ersten Freifunk-Node aufzusetzen habe ich einen Raspberry Pi 2 mit diesem Image bestückt. Der Config-Mode ist wie erwartet via LAN-Verbindung unter 192.168.1.1 zu erreichen. Meshing ist aktiviert, aber momentan ist der AP allein auf weiter Flur.

Nach dem obligatorischen reboot kann ich keine WLAN-Verbindung zur SSID ‚Freifunk‘ aufbauen. Es wird keine IP-Adresse vergeben.

Auf der Pi-Konsole (welche über HDMI ausgegeben wird) kann ich IP-Adressen im Internet pingen. Traceroute funktioniert auch, allerdings werden keine DNS-Namen aufgelöst.

Meine Hardware:

Pi2 mit USB-WLANn-Adapter (idVendor=0bda, idProduct=8176, rtl8192cu, AP-fähig)
LAN/Internet durch Fritz Box 7490

Wie kann ich prüfen, ob eine (VPN)Verbindung zum Supernode aufgebaut wurde? Bzw. wo fange ich am besten mit der Fehlersuche an?

–
Chrissi

Brother_Lal · 21. Oktober 2017 um 20:00

Moin moin,

VPN-Verbindung schaue ich meist auf der FF-Karte nach: https://map.freifunk-duesseldorf.de

Da stehen ein paar supernodes mit sehr kurzer Uptime, wars vll ein kurzer VPN-Hickup?

Ansonsten hat der PI manchmal etwas Eigenheiten mit dem WLAN - ifconfig zeigt ein wlan0/mesh0 device das den USB-Stick repräsentiert? Nehme ich einfach mal an, wenn du sagst, die SSID Freifunk wird ausgestrahlt

Was sagt denn „iw phy0 info“ ? Hier besonders auf die Interface combinations achten, ob das Gerät Mesh und AccessPoint gleichzeitig kann. Wenn beides an ist, kann es sein das eines von beiden streikt.

Wenn VPN da ist, und mit dem WLAN alles ok ist, dann ist die Software-„Verkabelung“ falsch.

Edit: Im Nachhinein - da keine DNS-Auflösung, kann wohl Tunneldigger keine VPN-Verbindung aufbauen, da keine IPs in der site-conf sind.
EditEdit: Es könnte auch ne Eigenheit des DNS von gluon sein(Nur der tunneldaemon kann DNS ausserhalb des VPNs, wenn ich mich korrekt erinner)… Hab leider grad keinen Knoten zum Testen da.

Fritzbox hat keinen Kinderschutzmodus oder Gästezugang auf Port4? Portsperren?

xmas · 21. Oktober 2017 um 20:58

Die Ausgabe von ifconfig ist durch die vielen Interfaces so umfangreich, dass nicht mehr alles auf eine Bildschirmseite passt. Bin gerade dabei, putty einzurichten, so dass ich die Daten copy/pasten kann.

ifconfig | grep HW
bat0 Link encap:Ethernet HWaddr B8:…
br-client Link encap:Ethernet HWaddr B8:…
br-wan Link encap:Ethernet HWaddr 4E:…
client0 Link encap:Ethernet HWaddr 48:…
eth0 Link encap:Ethernet HWaddr B8:…
local-node Link encap:Ethernet HWaddr 16:…
local-port Link encap:Ethernet HWaddr B8:…
primary0 Link encap:Ethernet HWaddr 4E:…

mesh0 fehlt beim obigen Befehl, aber erstaunlicherweise:

ifconfig mesh0 | grep HW
mesh0 Link encap:Ethernet HWaddr 4E:…

wlan0 gibts nicht, wenn der configuration.wizard durchlaufen wurde. Das scheint sich hinter client0 zu verstecken, da 48:… die MAC des USB Sticks ist.

Auszug aus ‚iw list‘ bzw. ‚iw phy0 info‘:

iw phy0 info
…
Supported interface modes:

IBBS

managed

AP

AP/VLAN

monitor

mesh point

P2P-client

P2P-Go

Ich kann noch weitere WiFi-Sticks testen, aber das dauert, da neue Sicks zwar automatisch erkannt werden, die Freifunk/Gluon-Konfiguration aber nicht automatisch auf den neuen Stick umgestellt wird. Das einzige, was zuverlässig funktioniert ist, das image neu zu flashen und von 0 zu starten.

Portsperren auf der Fritzbox sind alle deaktiviert. Firewall, Gästezugang, Kinderschutz sind aus. Ich hab alle 4 Ports durchprobiert und ein Switch (D-Link DGS-1008P) zwischen Box und Pi macht auch keinen Unterschied. Internet-Ping geht, DNS nicht. Alle anderen Rechner und Handys im privaten LAN/WLAN funktionieren problemlos.

Brother_Lal · 22. Oktober 2017 um 12:47

Ich würde mal im Konfigmodus das Wifi mesh ausschalten, und auch nachschauen, ob mesh-on-lan deaktiviert ist.
Die Sache mit dem DNS sollte so korrekt sein, nur der VPN-Daemon hat tatsächlich zugriff auf das WAN-DNS.

client0 und mesh0 sollten dann die wifi-interfaces sein, die sollten auch in /etc/config/wireless stehen.

Bei dem wifi modes: da sollte etwas mit „valid interface combinations“ stehen, dann sieht man nämlich, ob mesh+Ap erlaubt sind. Es kann nämlich sein, das der Stick jeweils das eine kann, gleichzeitig kann ers aber nicht.

Wenn es das alles nicht war, dann kann ich dir leider auch nicht weiterhelfen - tunneldigger als vpn hatte ich noch nie im einsatz.
Da muss ein Düsseldorfer ran

adorfer · 22. Oktober 2017 um 15:03

ich vermute, dass ein RPI nicht die ideale Platform ist für „mein erster Node“.
Vorschlagsmäßig würde ich erstmal mit einer stabilen (ausgetesteten) Platform starten, bei der auch Leute helfen können.
Nicht dass das mit dem Raspi nicht funktionieren würde, aber es ist so exotisch, dass hier schlicht die meisten Leute -ohne Logs und andere Infos- im Nebel stochern.
(Ich versuche es daher gar nicht, da ich spontan imemrnoch ein halbes Dutzend Möglichkeiten sehe, was da konkret schief läuft.)

Mein Vorschlag, besorge Dir -gern auch leihweise- einen alten TP-Link WR841, 1043er, 940er or whatever…
Und wenn der läuft, dann kannst Du auf der Shell konkret vergleichen, was schief läuft.

xmas · 22. Oktober 2017 um 15:20

Es scheint am WiFi-Stick zu liegen. Bei deaktiviertem meshing wird erst garkeine ‚Freifunk‘ SSID angezeigt, zu der man sich verbinden könnte. client0 und mesh0 sind auch nicht auffindbar mit ifconfig. In der /etc/config/wireless steht auch nichts:

cat /etc/config/wireless

config wifi-device ‚radio0‘
option type ‚mac80211‘
option channel ‚11‘
option hwmode ‚11g‘
option path ‚platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0‘
option htmode ‚HT20‘
option disabled ‚1‘

config wifi-iface ‚default_radio0‘
option device ‚radio0‘
option network ‚lan‘
option mode ‚ap‘
option ssid ‚LEDE‘
option encryption ‚none‘

Hier die vollständigen Angaben des Sticks:

~# iw phy0 info

Wiphy phy0
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
RTS threshold: 2347
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 1:
Capabilities: 0x186e
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT Max RX data rate: 150 Mbps
HT TX/RX MCS rate indexes supported: 0-7, 32
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
interface combinations are not supported
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing

Meine anderen Sticks (LogiLink WL0079, TP-Link ???, Lancom) werden zwar vom Betriebssystem erkannt und die Treiber werden automatisch geladen. Aber gluon scheint damit noch weniger anfangen zu können, als mit dem aktuellen Stick (LB-Link BL-WN151?).

Schade, dann kann ich wohl meinen existierenden Elektroschrott nicht recyclen und es muss neuer angeschafft werden.
Welcher Router ist momentan zu empfehlen (verfügbar und unter 50€), um eine 100Mbit-Leitung auszureizen? Wünschenswert, aber optional wäre ein kompakter Formfaktor (wie der Raspberry Pi) und geringer Stromverbrauch, da ich das Gerät im Erfolgsfall gerne draußen in eine kleine, wasserdichte Box mit Solarbetrieb in eine Baumkrone hängen würde.

MPW · 22. Oktober 2017 um 15:23

Hallo,

ausreizen nicht ganz, aber ein 1043er macht schon mal 60 Mbits, wenn die Gateways das hergeben, also L2TP/Tunneldigger statt Fastd verwendet wird und auch genug Bandbreite abgerufen werden kann. Der ist für knapp 50 Euro verfügbar. Mehr braucht man im Gäste-WLAN in der Regel auch nicht.

Hast du VPN auf dem Pi aktiviert und ihn über Kabel mit deinem DSL-Router verbunden? Kommst du über die WAN-IP (im DSL-Router nachschlagen) auf das Gerät?

Viele Grüße
Matthias

xmas · 22. Oktober 2017 um 15:36

Wenn die WAN-IP die externe IP meiner Fritz-Box ist, dann nein. Das würde evtl. funktionieren, wenn ich den Pi als ‚Exposed Host‘ eintrage. ->> to be tested.

Die LAN-Schnittstelle des Pi kriegt von der FritzBox per DHCP die 192.168.188.20 zugewiesen. Darüber kann ich mich aus dem lokalen Netz mit Putty auf dem Pi einloggen.

Meinst Du mit VPN aktivieren die Checkbox im Wizard? Wenn das an ist, dann tauchen auch client0 und mesh0 auf. ‚Bandbreite begrenzen‘ an/aus macht keinen Unterschied. Es funktioniert in keinem Fall. Leider bin ich momentan auf den Wizard bzw. den Config-Mode angewiesen. Wie die Einstellungen anchträglich über die Konsole modifiziert werden könnnen, muss ich mir erst noch anlesen.

MPW · 22. Oktober 2017 um 16:25

Nein, das ist eine IP bei dir im lokalen Netz. Irgendwas mit 192.168.x.y.

Das meinte ich.

Zeig mal

logread

und

uci show|grep vpn

Grüße
Matthias

adorfer · 22. Oktober 2017 um 16:56

uci show|grep tunnel

und

ps|grep tunnel

xmas · 30. Oktober 2017 um 18:38

Hi, sorry für die späte Rückmeldung.

Hier das logread. Um zumindest etwas Übersicht zu behalten, habe ich das ca. erste Drittel des logs rausgenommen. Alles, was ansatzweise mit Netzwerk/gluon zu tun hat sollte aber noch da stehen.
Das erwähnte DNS-Problem ist konsistent mit den Fehlermeldungen ‚daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.‘
Der Versuch, per wicd eine Verbindung zur Freifunk SSID herzustellen, bricht ab mit der Fehlermeldung : „Verbindung fehlgeschlagen: IP-Adress kann nicht bezogen werden.“

~# logread
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0xf00
Mon Jul 10 18:22:14 2017 kern.notice kernel: [ 0.000000] Linux version 4.4.89 (jenkins@whiteforest) (gcc version 5.4.0 (LEDE GCC 5.4.0 r3435+30-65eec8bd5f) ) #0 SMP Mon Jul 10 16:16:23 2017
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1
[…]
Mon Jul 10 18:22:14 2017 user.info kernel: [ 6.197576] kmodloader: loading kernel modules from /etc/modules.d/*
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.244056] l2tp_core: L2TP core driver, V2.0
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.256889] l2tp_netlink: L2TP netlink interface
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.272827] l2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.288273] l2tp_ip: L2TP IP encapsulation support (L2TPv3)
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.302436] l2tp_ip6: L2TP IP encapsulation support for IPv6 (L2TPv3)
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.323932] ip6_tables: (C) 2000-2006 Netfilter Core Team
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.346904] Loading modules backported from Linux version wt-2017-01-31-0-ge882dff19e7f
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.363620] Backport generated by backports.git backports-20160324-13-g24da7d3c
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.401398] batman_adv: B.A.T.M.A.N. advanced 2017.2 (compatibility version 15) loaded
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.424804] hidraw: raw HID events driver (C) Jiri Kosina
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.451906] u32 classifier
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.462280] input device check on
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.473486] Actions configured
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.485779] Mirror/redirect action on
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.537584] usbcore: registered new interface driver asix
Mon Jul 10 18:22:14 2017 kern.notice kernel: [ 6.553119] Bridge firewalling registered
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.566139] usbcore: registered new interface driver dm9601
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.588841] Ebtables v2.0 registered
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.602199] ip_tables: (C) 2000-2006 Netfilter Core Team
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.659191] nf_conntrack version 0.5.0 (14871 buckets, 59484 max)
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.796318] usbcore: registered new interface driver r8152
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.810273] usbcore: registered new interface driver rtl8150
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.842676] input: HID 04f3:0110 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04F3:0110.0001/input/input0
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.862054] hid-generic 0003:04F3:0110.0001: input,hidraw0: USB HID v1.10 Keyboard [HID 04f3:0110] on usb-3f980000.usb-1.3/input0
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.903001] input: HID 04f3:0110 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1/0003:04F3:0110.0002/input/input1
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.922604] hid-generic 0003:04F3:0110.0002: input,hidraw1: USB HID v1.10 Mouse [HID 04f3:0110] on usb-3f980000.usb-1.3/input1
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.941785] usbcore: registered new interface driver usbhid
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.954890] usbhid: USB HID core driver
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 6.979659] xt_time: kernel timezone is -0000
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 7.008208] rtl8192cu: Chip version 0x10
Mon Jul 10 18:22:14 2017 kern.notice kernel: [ 7.075976] random: nonblocking pool is initialized
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 7.104608] rtl8192cu: Board Type 0
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 7.115694] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 7.128962] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
Mon Jul 10 18:22:14 2017 kern.debug kernel: [ 7.143507] ieee80211 phy0: Selected rate control algorithm ‚rtl_rc‘
Mon Jul 10 18:22:14 2017 kern.info kernel: [ 7.146164] usbcore: registered new interface driver rtl8192cu
Mon Jul 10 18:22:14 2017 user.info kernel: [ 7.161600] kmodloader: done loading kernel modules from /etc/modules.d/*
Mon Jul 10 18:22:14 2017 daemon.notice haveged: haveged starting up
Mon Jul 10 18:22:15 2017 daemon.info haveged: haveged: ver: 1.9.1; arch: generic; vend: ; build: (gcc 5.4.0 CV); collect: 128K
Mon Jul 10 18:22:15 2017 daemon.info haveged: haveged: cpu: (); data: 32K (P); inst: 32K (P); idx: 16/40; sz: 32428/78796
Mon Jul 10 18:22:15 2017 daemon.info haveged: haveged: fills: 0, generated: 0
Mon Jul 10 18:22:16 2017 user.notice : Added device handler type: tunnel
Mon Jul 10 18:22:16 2017 user.notice : Added device handler type: Network device
Mon Jul 10 18:22:16 2017 user.notice : Added device handler type: bridge
Mon Jul 10 18:22:16 2017 user.notice : Added device handler type: veth
Mon Jul 10 18:22:16 2017 user.notice : Added device handler type: macvlan
Mon Jul 10 18:22:16 2017 user.notice : Added device handler type: 8021ad
Mon Jul 10 18:22:16 2017 user.notice : Added device handler type: 8021q
Mon Jul 10 18:22:16 2017 authpriv.info dropbear[540]: Not backgrounding
Mon Jul 10 18:22:17 2017 daemon.warn netifd: You have delegated IPv6-prefixes but haven’t assigned them to any interface. Did you forget to set option ip6assign on your lan-interfaces?
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.574746] smsc95xx 1-1.1:1.0 eth0: hardware isn’t capable of remote wakeup
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.593497] device eth0 entered promiscuous mode
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.611186] br-wan: port 1(eth0) entered forwarding state
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.624174] br-wan: port 1(eth0) entered forwarding state
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚wan‘ is enabled
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚wan6‘ is enabled
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚mesh_wan‘ is enabled
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚local_node‘ is enabled
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚local_node‘ is setting up now
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚local_node‘ is now up
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚gluon_bat0‘ is setting up now
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.648609] IPv6: ADDRCONF(NETDEV_UP): local-node: link is not ready
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚loopback‘ is enabled
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚loopback‘ is setting up now
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚loopback‘ is now up
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚client‘ is enabled
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.681651] IPv6: ADDRCONF(NETDEV_UP): br-client: link is not ready
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.704512] IPv6: ADDRCONF(NETDEV_CHANGE): local-node: link becomes ready
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.721430] device local-port entered promiscuous mode
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.735393] br-client: port 1(local-port) entered forwarding state
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.750361] br-client: port 1(local-port) entered forwarding state
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.765437] IPv6: ADDRCONF(NETDEV_CHANGE): br-client: link becomes ready
Mon Jul 10 18:22:17 2017 daemon.notice netifd: bridge ‚br-wan‘ link is up
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚wan‘ has link connectivity
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚wan‘ is setting up now
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚wan6‘ has link connectivity
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚wan6‘ is setting up now
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚mesh_wan‘ has link connectivity
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Network device ‚eth0‘ link is up
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Network device ‚local-port‘ link is up
Mon Jul 10 18:22:17 2017 daemon.notice netifd: veth ‚local-node‘ link is up
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚local_node‘ has link connectivity
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Network device ‚lo‘ link is up
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚loopback‘ has link connectivity
Mon Jul 10 18:22:17 2017 daemon.notice netifd: bridge ‚br-client‘ link is up
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚client‘ has link connectivity
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚client‘ is setting up now
Mon Jul 10 18:22:17 2017 user.notice sysctl: net.ipv6.conf.local-node.forwarding = 0
Mon Jul 10 18:22:17 2017 user.notice firewall: Reloading firewall due to ifup of local_node (local-node)
Mon Jul 10 18:22:17 2017 daemon.info respondd[732]: unable to read providers from ‚/usr/lib/respondd‘, ignoring
Mon Jul 10 18:22:17 2017 user.notice sysctl: net.ipv6.conf.br-client.forwarding = 0
Mon Jul 10 18:22:17 2017 daemon.notice netifd: wan (740): udhcpc: started, v1.25.1
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.977033] batman_adv: bat0: Adding interface: primary0
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 10.990515] batman_adv: bat0: Interface activated: primary0
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 11.008592] 8021q: adding VLAN 0 to HW filter on device bat0
Mon Jul 10 18:22:17 2017 daemon.notice netifd: Interface ‚bat0‘ is enabled
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 11.043629] device bat0 entered promiscuous mode
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 11.057205] br-client: port 2(bat0) entered forwarding state
Mon Jul 10 18:22:17 2017 kern.info kernel: [ 11.071249] br-client: port 2(bat0) entered forwarding state
Mon Jul 10 18:22:18 2017 daemon.err odhcp6c[717]: Failed to send DHCPV6 message to ff02::1:2 (Address not available)
Mon Jul 10 18:22:18 2017 kern.info kernel: [ 11.207224] batman_adv: bat0: Changing gw mode from: off to: client
Mon Jul 10 18:22:18 2017 kern.info kernel: [ 11.232694] batman_adv: bat0: hop_penalty: Changing from: 30 to: 15
Mon Jul 10 18:22:18 2017 kern.info kernel: [ 11.247140] batman_adv: bat0: orig_interval: Changing from: 1000 to: 5000
Mon Jul 10 18:22:18 2017 daemon.notice netifd: Network device ‚bat0‘ link is up
Mon Jul 10 18:22:18 2017 daemon.notice netifd: Interface ‚bat0‘ has link connectivity
Mon Jul 10 18:22:18 2017 daemon.notice netifd: Interface ‚bat0‘ is setting up now
Mon Jul 10 18:22:18 2017 daemon.notice netifd: Interface ‚bat0‘ is now up
Mon Jul 10 18:22:18 2017 kern.info kernel: [ 11.331735] batman_adv: bat0: Interface deactivated: primary0
Mon Jul 10 18:22:18 2017 kern.info kernel: [ 11.359957] IPv6: ADDRCONF(NETDEV_UP): primary0: link is not ready
Mon Jul 10 18:22:18 2017 kern.info kernel: [ 11.378890] batman_adv: bat0: Interface activated: primary0
Mon Jul 10 18:22:18 2017 daemon.notice netifd: Interface ‚gluon_bat0‘ is now up
Mon Jul 10 18:22:18 2017 daemon.notice netifd: Network device ‚primary0‘ link is up
Mon Jul 10 18:22:18 2017 daemon.notice netifd: wan (740): udhcpc: sending discover
Mon Jul 10 18:22:18 2017 daemon.notice procd: /etc/rc.d/S60gluon-wan-dnsmasq: Segmentation fault
Mon Jul 10 18:22:18 2017 daemon.notice procd: /etc/rc.d/S90tunneldigger: Starting tunneldigger on mesh-vpn
Mon Jul 10 18:22:18 2017 daemon.info td-client: Performing broker selection…
Mon Jul 10 18:22:18 2017 daemon.err odhcp6c[717]: Failed to send DHCPV6 message to ff02::1:2 (Address not available)
Mon Jul 10 18:22:18 2017 daemon.err odhcp6c[723]: Failed to send DHCPV6 message to ff02::1:2 (Address not available)
Mon Jul 10 18:22:18 2017 daemon.notice procd: /etc/rc.d/S99alfred: /etc/rc.d/S99alfred: waiting 30 secs for br-client address…
Mon Jul 10 18:22:19 2017 kern.info kernel: [ 12.185877] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Mon Jul 10 18:22:19 2017 daemon.notice netifd: radio0 (646): command failed: Not supported (-95)
Mon Jul 10 18:22:19 2017 kern.info kernel: [ 12.622276] br-wan: port 1(eth0) entered forwarding state
Mon Jul 10 18:22:19 2017 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Mon Jul 10 18:22:19 2017 kern.info kernel: [ 12.690197] rtl8192cu: MAC auto ON okay!
Mon Jul 10 18:22:19 2017 kern.info kernel: [ 12.742278] br-client: port 1(local-port) entered forwarding state
Mon Jul 10 18:22:19 2017 kern.info kernel: [ 12.768190] rtl8192cu: Tx queue select: 0x05
Mon Jul 10 18:22:19 2017 daemon.notice procd: /etc/rc.d/S99alfred: /etc/rc.d/S99alfred: starting alfred
Mon Jul 10 18:22:19 2017 daemon.notice procd: /etc/rc.d/S99alfred: /etc/rc.d/S99alfred: starting batadv-vis
Mon Jul 10 18:22:19 2017 daemon.info procd: - init complete -
Mon Jul 10 18:22:19 2017 kern.info kernel: [ 13.062298] br-client: port 2(bat0) entered forwarding state
Mon Jul 10 18:22:21 2017 daemon.notice netifd: wan (740): udhcpc: sending discover
Mon Jul 10 18:22:21 2017 daemon.notice netifd: wan (740): udhcpc: sending select for 192.168.188.20
Mon Jul 10 18:22:21 2017 daemon.notice netifd: wan (740): udhcpc: lease of 192.168.188.20 obtained, lease time 864000
Mon Jul 10 18:22:21 2017 daemon.info dnsmasq[1086]: started, version 2.78 cachesize 150
Mon Jul 10 18:22:21 2017 daemon.info dnsmasq[1086]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Mon Jul 10 18:22:21 2017 daemon.info dnsmasq[1086]: using local addresses only for domain lan
Mon Jul 10 18:22:21 2017 daemon.notice netifd: Interface ‚wan‘ is now up
Mon Jul 10 18:22:21 2017 daemon.warn dnsmasq[1086]: no servers found in /tmp/resolv.conf.auto, will retry
Mon Jul 10 18:22:21 2017 daemon.info dnsmasq[1086]: read /etc/hosts - 4 addresses
Mon Jul 10 18:22:21 2017 daemon.info dnsmasq[1086]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
Mon Jul 10 18:22:21 2017 kern.info kernel: [ 14.654585] IPv6: ADDRCONF(NETDEV_UP): client0: link is not ready
Mon Jul 10 18:22:21 2017 daemon.notice hostapd: client0: interface state UNINITIALIZED->COUNTRY_UPDATE
Mon Jul 10 18:22:21 2017 kern.info kernel: [ 14.677521] device client0 entered promiscuous mode
Mon Jul 10 18:22:21 2017 daemon.err hostapd: Using interface client0 with hwaddr 48:02:2a:cd:58:a7 and ssid „Freifunk“
Mon Jul 10 18:22:21 2017 kern.info kernel: [ 14.710309] IPv6: ADDRCONF(NETDEV_CHANGE): client0: link becomes ready
Mon Jul 10 18:22:21 2017 kern.info kernel: [ 14.726198] br-client: port 3(client0) entered forwarding state
Mon Jul 10 18:22:21 2017 kern.info kernel: [ 14.741062] br-client: port 3(client0) entered forwarding state
Mon Jul 10 18:22:21 2017 daemon.notice hostapd: client0: interface state COUNTRY_UPDATE->ENABLED
Mon Jul 10 18:22:21 2017 daemon.notice hostapd: client0: AP-ENABLED
Mon Jul 10 18:22:21 2017 user.notice firewall: Reloading firewall due to ifup of wan (br-wan)
Mon Jul 10 18:22:21 2017 daemon.notice netifd: Network device ‚client0‘ link is up
Mon Jul 10 18:22:21 2017 daemon.err odhcp6c[717]: Failed to send DHCPV6 message to ff02::1:2 (Operation not permitted)
Mon Jul 10 18:22:23 2017 daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.
Mon Jul 10 18:22:23 2017 daemon.err td-client: Failed to resolve hostname ‚vpn02.freifunk-duesseldorf.de‘.
Mon Jul 10 18:22:23 2017 kern.info kernel: [ 16.732323] br-client: port 3(client0) entered forwarding state
Mon Jul 10 18:22:23 2017 daemon.info dnsmasq[1086]: exiting on receipt of SIGTERM
Mon Jul 10 18:22:23 2017 daemon.info dnsmasq[1221]: started, version 2.78 cachesize 150
Mon Jul 10 18:22:23 2017 daemon.info dnsmasq[1221]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Mon Jul 10 18:22:23 2017 daemon.info dnsmasq[1221]: using local addresses only for domain lan
Mon Jul 10 18:22:23 2017 daemon.warn dnsmasq[1221]: no servers found in /tmp/resolv.conf.auto, will retry
Mon Jul 10 18:22:23 2017 daemon.info dnsmasq[1221]: read /etc/hosts - 4 addresses
Mon Jul 10 18:22:23 2017 daemon.info dnsmasq[1221]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
Mon Jul 10 18:22:32 2017 daemon.notice netifd: Interface ‚client‘ is now up
Mon Jul 10 18:22:32 2017 daemon.notice netifd: Interface ‚wan6‘ is now up
Mon Jul 10 18:22:32 2017 user.notice firewall: Reloading firewall due to ifup of client (br-client)
Mon Jul 10 18:22:32 2017 daemon.info respondd[1273]: unable to read providers from ‚/usr/lib/respondd‘, ignoring
Mon Jul 10 18:22:32 2017 user.notice firewall: Reloading firewall due to ifup of wan6 (br-wan)
Mon Jul 10 18:22:34 2017 daemon.info td-client: Reinitializing tunnel context.
Mon Jul 10 18:22:34 2017 daemon.info td-client: Reinitializing tunnel context.
Mon Jul 10 18:22:39 2017 daemon.info td-client: Selected vpn01.freifunk-duesseldorf.de:10050 as the best broker.
Mon Jul 10 18:22:39 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:22:42 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:22:45 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:22:48 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:22:51 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:22:54 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:22:57 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:00 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:03 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:06 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:09 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:10 2017 daemon.err td-client: Connection with broker not established after 30 seconds, restarting broker selection…
Mon Jul 10 18:23:10 2017 daemon.info td-client: Performing broker selection…
Mon Jul 10 18:23:15 2017 daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.
Mon Jul 10 18:23:15 2017 daemon.err td-client: Failed to resolve hostname ‚vpn02.freifunk-duesseldorf.de‘.
Mon Jul 10 18:23:26 2017 daemon.info td-client: Reinitializing tunnel context.
Mon Jul 10 18:23:26 2017 daemon.info td-client: Reinitializing tunnel context.
Mon Jul 10 18:23:31 2017 daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.
Mon Jul 10 18:23:31 2017 daemon.info td-client: Selected vpn01.freifunk-duesseldorf.de:10050 as the best broker.
Mon Jul 10 18:23:31 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:34 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:37 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:40 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:43 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:46 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:49 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:52 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:55 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:23:58 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:01 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:02 2017 daemon.err td-client: Connection with broker not established after 30 seconds, restarting broker selection…
Mon Jul 10 18:24:02 2017 daemon.info td-client: Performing broker selection…
Mon Jul 10 18:24:07 2017 daemon.err td-client: Failed to resolve hostname ‚vpn02.freifunk-duesseldorf.de‘.
Mon Jul 10 18:24:07 2017 daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.
Mon Jul 10 18:24:07 2017 authpriv.info dropbear[1440]: Child connection from 192.168.188.28:55395
Mon Jul 10 18:24:18 2017 daemon.info td-client: Reinitializing tunnel context.
Mon Jul 10 18:24:18 2017 daemon.info td-client: Reinitializing tunnel context.
Mon Jul 10 18:24:22 2017 authpriv.warn dropbear[1440]: Login attempt for nonexistent user from 192.168.188.28:55395
Mon Jul 10 18:24:23 2017 daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.
Mon Jul 10 18:24:23 2017 daemon.info td-client: Selected vpn01.freifunk-duesseldorf.de:10050 as the best broker.
Mon Jul 10 18:24:23 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:25 2017 authpriv.warn dropbear[1440]: Login attempt for nonexistent user from 192.168.188.28:55395
Mon Jul 10 18:24:26 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:28 2017 authpriv.info dropbear[1440]: Exit before auth: Disconnect received
Mon Jul 10 18:24:29 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:32 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:35 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:38 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:41 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:44 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:47 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:49 2017 authpriv.info dropbear[1445]: Child connection from 192.168.188.28:55397
Mon Jul 10 18:24:50 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:53 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:24:54 2017 daemon.err td-client: Connection with broker not established after 30 seconds, restarting broker selection…
Mon Jul 10 18:24:54 2017 daemon.info td-client: Performing broker selection…
Mon Jul 10 18:24:59 2017 daemon.err td-client: Failed to resolve hostname ‚vpn02.freifunk-duesseldorf.de‘.
Mon Jul 10 18:24:59 2017 daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.
Mon Jul 10 18:25:01 2017 daemon.warn td-client: Got termination signal, shutting down tunnel…
Mon Jul 10 18:25:06 2017 authpriv.warn dropbear[1445]: Bad password attempt for ‚root‘ from 192.168.188.28:55397
Mon Jul 10 18:25:08 2017 user.notice tunneldiger-watchdog: No neighbours on mesh-vpn interface, restarted tunneldigger.
Mon Jul 10 18:25:08 2017 daemon.info td-client: Performing broker selection…
Mon Jul 10 18:25:13 2017 daemon.err td-client: Failed to resolve hostname ‚vpn02.freifunk-duesseldorf.de‘.
Mon Jul 10 18:25:13 2017 daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.
Mon Jul 10 18:25:18 2017 authpriv.notice dropbear[1445]: Password auth succeeded for ‚root‘ from 192.168.188.28:55397
Mon Jul 10 18:25:24 2017 daemon.info td-client: Reinitializing tunnel context.
Mon Jul 10 18:25:24 2017 daemon.info td-client: Reinitializing tunnel context.
Mon Jul 10 18:25:29 2017 daemon.err td-client: Failed to resolve hostname ‚vpn01.freifunk-duesseldorf.de‘.
Mon Jul 10 18:25:29 2017 daemon.info td-client: Selected vpn01.freifunk-duesseldorf.de:10050 as the best broker.
Mon Jul 10 18:25:29 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:25:32 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:25:35 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:25:38 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:25:41 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:25:44 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!
Mon Jul 10 18:25:47 2017 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!

uci show|grep vpn bzw. uci show|grep tunnel:

~# uci show | grep vpn
firewall.mesh_vpn_dns=include
firewall.mesh_vpn_dns.family=‚ipv4‘
firewall.mesh_vpn_dns.type=‚restore‘
firewall.mesh_vpn_dns.path=‚/lib/gluon/mesh-vpn/iptables.rules‘
network.mesh_vpn=interface
network.mesh_vpn.ifname=‚mesh-vpn‘
network.mesh_vpn.transitive=‚1‘
network.mesh_vpn.mtu=‚1364‘
network.mesh_vpn.macaddr=‚4e:15:7e:87:46:ff‘
network.mesh_vpn.fixed_mtu=‚1‘
network.mesh_vpn.proto=‚gluon_mesh‘
simple-tc.mesh_vpn=interface
simple-tc.mesh_vpn.enabled=‚0‘
simple-tc.mesh_vpn.ifname=‚mesh-vpn‘
simple-tc.mesh_vpn.limit_ingress=‚3000‘
simple-tc.mesh_vpn.limit_egress=‚200‘
tunneldigger.mesh_vpn=broker
tunneldigger.mesh_vpn.uuid=‚b827eb9225f0‘
tunneldigger.mesh_vpn.address=‚vpn01.freifunk-duesseldorf.de:10050‘ ‚vpn02.freifunk-duesseldorf.de:10050‘
tunneldigger.mesh_vpn.group=‚gluon-mesh-vpn‘
tunneldigger.mesh_vpn.broker_selection=‚usage‘
tunneldigger.mesh_vpn.bind_interface=‚br-wan‘
tunneldigger.mesh_vpn.interface=‚mesh-vpn‘
tunneldigger.mesh_vpn.enabled=‚1‘

und ps | grep tunnel

~# ps | grep tunnel
2076 root 812 S /usr/bin/tunneldigger -u b827eb9225f0 -i mesh-vpn -t 1 -b vpn01.freifunk-duesseldorf.de:10050 -b vpn02.freifunk-duesseldorf.de:10050 -I br-wan -a
2078 nobody 784 S /usr/bin/tunneldigger -u b827eb9225f0 -i mesh-vpn -t 1 -b vpn01.freifunk-duesseldorf.de:10050 -b vpn02.freifunk-duesseldorf.de:10050 -I br-wan -a
2079 nobody 784 S /usr/bin/tunneldigger -u b827eb9225f0 -i mesh-vpn -t 1 -b vpn01.freifunk-duesseldorf.de:10050 -b vpn02.freifunk-duesseldorf.de:10050 -I br-wan -a
2141 root 1024 R grep tunnel

eth0 / br-client / bat0 MAC: B8:…
wifi / br-wan MAC: 4E:

adorfer · 30. Oktober 2017 um 20:09

Paste mal den Output von

  ps | grep dnsmasq

Wenn da nur einer ist, wenn da keine zwei sind, vor allemkeiner mit „wan-dnsmasq/resolv.conf“ versuche das mal manuell.

/usr/sbin/dnsmasq -x /var/run/gluon-wan-dnsmasq.pid -u root -i lo -p 54 -h -r /var/gluon/wan-dnsmasq/resolv.conf

Wenn das sich nicht starten lässt, dann ist es eventuell dieses Problem: package:gluon-wan-dnsmasq secondary dnsmasq (the one on port 54) is not starting automatically on rpi · Issue #1245 · freifunk-gluon/gluon · GitHub

Ein Hotfix wäre vermutlich, die FQDNs der Server durch IPv4 zu ersetzen:

schau mal, wie der schlüssel genau heisst,

uci show |grep tunneldigger|grepp address

sollte etwa soetwas sein:

tunneldigger.@broker[0].address='vpn02.freifunk-duesseldorf.de:10050' 'vpn02.freifunk-duesseldorf.de:10050'

dann entsprechend (es kann vorn in der Schreibweise des „broker[0]“ auch abweichen, habe keinen Knoten von dort hier.)

uci delete tunneldigger.@broker[0].address
uci add_list tunneldigger.@broker[0].address=185.46.137.154:10050
uci add_list tunneldigger.@broker[0].address=185.46.137.155:10050

Beim nächsten Autoupdater hast Du dann natürlich ein Problem, da die Settings überschreiben werden.

Alternativ könntest Du auch die IPv4 in die hosts-datei einschreiben und zusätzlich über ein script in der /etc/rc.local sicherstellen, dass das beim Autoudpate wieder hergestellt wird.
Setzt aber immer voraus, dass sich beim DNS dort nie etwas ändert. Daher bitte mit Vorsicht.

xmas · 31. Oktober 2017 um 11:14

~# ps | grep dnsmasq
10260 dnsmasq 864 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg02411c
10440 root 1024 S grep dnsmasq

nach dnsmasq -x …

~# ps | grep dnsmasq
10260 dnsmasq 864 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg02411c -k -x /var/ru
10841 root 864 S /usr/sbin/dnsmasq -x /var/run/gluon-wan-dnsmasq.pid -u root -i lo
10986 root 1024 S grep dnsmasq

Urea, es funktioniert! Und mit 18/16 Mbit/s bei einem verbundenen Client sogar recht gut. Ich lass es erst mal so laufen und schaue, ob es auch stabil ist.

uci show |grep tunneldigger|grep address

tunneldigger.mesh_vpn.address=‚vpn01.freifunk-duesseldorf.de:10050‘ ‚vpn02.freifunk-duesseldorf.de:10050‘

Vielen Dank für die Hilfe soweit!

Nochmal zum Verständnis für den Laien hier: der dnsmasq-Befehl hat jetzt ipv4 erzwungen, weil ipv6 nicht funktioniert? Wo genau hakt es in der ursprünglichen Konfiguration?

adorfer · 31. Oktober 2017 um 11:54

Das Startscript für den dnsmasq „auf wan-seite“ failed beim Start.
Wenn Du die l2tp-server von fqdn auf IPv4 umstellst, dann braucht es keinen dns für die Namensauflösung mehr.

(Und ja, der Bug ist bekannt und im Gluon „Upstream“ auch gefixt. Und nein, es ist nicht nur ddorf betroffen. Andere hatten das auch.Da RPI aber so exotisch ist hat’s ein wenig gebraucht, bis es aufgefallen ist oder überhaupt reported wurde.)

MPW · 31. Oktober 2017 um 13:31

Freut mich, dass es klappt.

Für alle die mitlesen, den Fehler, den @adorfer auch schon richtig diagnostiziert hat, sieht man hier an diesen Zeilen: