Jetzt haben wir genau so einen Fall, ich versuche gerade den Nodebesitzer dazu zu bekommen Infos von dem Betroffenen Node zu schicken.
Wie man sieht das Node ist „offline“ aber es besteht vom Nachbarn angeblich noch Verbindung.
Hab wohl gerade auch so einen Fall.
Wie kann ich beim Debuggen helfen? Hab auf die gezeigten Knoten Zugriff via SSH. Der betroffene Knoten ist allerdings nicht erreichbar.
Wenn Du auf den Nachbar-Meshknoten kommst, dann geht’s evtl über die Linklocal-Adresses auf dem Mesh-Interface, also „ssh root@fe80…%mesh0“ (oder wie immer das interface dort heisst).
gleiches gibt für die vpn-Tunnel, auch dort gibt es auf den „inneren Interfaces“ fe80-adressen… Problem ist nur, wenn man diese nicht kennt, weil sie natürlich pro interface verschieden sind/sein können. Dann muss man erstmal broadcast-Pings a la „ping6 ff02::1%mesh0“ (als beispiel) absetzen muss, um zu schauen, wer da so überhaupt auf dem Interface hängt.
Und ja, das kann mühsam werden, wenn man zunächst erstmal einen haufen Nanobeams, Toughswitches und anderes Zeug findet die auf den BAT-Strecken „helfen“.
Da bekomme ich zumindest ne Verbindung via SSH. Er will aber ein Passwort. Bin mir gerade aber ziemlich sicher, dass ich dort nen Key hinterlegt habe 
Probiers mal ssh mit -o ProxyJump=funktionierender Node
Und dann bitte batctl o; batctl n; batctl gwl; iwinfo; dmesg; logread
Oben auf dem Node habe ich wohl doch keinen Key hinterlegt :-/
Das Problem ist gerade aber noch einmal an einer anderen Stelle aufgetaucht:
Hier habe ich aber leider keine Verbindung via SSH bekommen. Wenn das Problem da noch einmal auftritt, dann stecke ich mich mal mit Kabel dran. Der Knoten steht im Nachbarhaus.
Kurze Zeit später war der Knoten wieder ok:
Vllt kann man hier ja schon etwas erkennen?
Logread:
Tue Aug 13 21:20:26 2019 daemon.info hostapd: client0: STA b0:eb:57:80:76:73 IEEE 802.11: disassociated
Tue Aug 13 21:20:27 2019 daemon.info hostapd: client0: STA b0:eb:57:80:76:73 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Aug 13 21:26:22 2019 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 2c:0e:3d:67:cc:0e
Tue Aug 13 21:26:22 2019 daemon.info hostapd: client0: STA 2c:0e:3d:67:cc:0e IEEE 802.11: disassociated due to inactivity
Tue Aug 13 21:26:23 2019 daemon.info hostapd: client0: STA 2c:0e:3d:67:cc:0e IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Aug 13 21:35:02 2019 daemon.info hostapd: client0: STA 44:91:60:42:e9:e5 IEEE 802.11: authenticated
Tue Aug 13 21:35:02 2019 daemon.info hostapd: client0: STA 44:91:60:42:e9:e5 IEEE 802.11: associated (aid 1)
Tue Aug 13 21:35:02 2019 daemon.notice hostapd: client0: AP-STA-CONNECTED 44:91:60:42:e9:e5
Tue Aug 13 21:40:29 2019 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 44:91:60:42:e9:e5
Tue Aug 13 21:40:29 2019 daemon.info hostapd: client0: STA 44:91:60:42:e9:e5 IEEE 802.11: disassociated due to inactivity
Tue Aug 13 21:40:30 2019 daemon.info hostapd: client0: STA 44:91:60:42:e9:e5 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Aug 13 21:57:00 2019 daemon.info hostapd: client0: STA 34:e2:fd:90:58:22 IEEE 802.11: authenticated
Tue Aug 13 21:57:00 2019 daemon.info hostapd: client0: STA 34:e2:fd:90:58:22 IEEE 802.11: associated (aid 3)
Tue Aug 13 21:57:00 2019 daemon.notice hostapd: client0: AP-STA-CONNECTED 34:e2:fd:90:58:22
Wed Aug 14 00:15:21 2019 daemon.notice netifd: client (1214): cat: write error: Broken pipe
Wed Aug 14 00:15:34 2019 daemon.notice netifd: client (1214): cat: write error: Broken pipe
Wed Aug 14 00:28:53 2019 daemon.notice netifd: client (1214): cat: write error: Broken pipe
Wed Aug 14 01:17:19 2019 daemon.warn dnsmasq[689]: no servers found in /tmp/resolv.conf.auto, will retry
Wed Aug 14 01:18:50 2019 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 34:e2:fd:90:58:22
Wed Aug 14 01:18:50 2019 daemon.info hostapd: client0: STA 34:e2:fd:90:58:22 IEEE 802.11: disassociated due to inactivity
Wed Aug 14 01:18:51 2019 daemon.info hostapd: client0: STA 34:e2:fd:90:58:22 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Aug 14 07:33:36 2019 daemon.info dnsmasq[689]: reading /tmp/resolv.conf.auto
Wed Aug 14 07:33:36 2019 daemon.info dnsmasq[689]: using local addresses only for domain lan
Wed Aug 14 07:33:36 2019 daemon.info dnsmasq[689]: using nameserver 2a03:2260:3018:100::3#53
Wed Aug 14 07:33:44 2019 daemon.info dnsmasq[689]: reading /tmp/resolv.conf.auto
Wed Aug 14 07:33:44 2019 daemon.info dnsmasq[689]: using local addresses only for domain lan
Wed Aug 14 07:33:44 2019 daemon.info dnsmasq[689]: using nameserver 2a03:2260:3018:100::3#53
Wed Aug 14 07:33:44 2019 daemon.info dnsmasq[689]: using nameserver 2a03:2260:3018:100::2#53
Wed Aug 14 07:34:01 2019 daemon.info dnsmasq[689]: reading /tmp/resolv.conf.auto
Wed Aug 14 07:34:01 2019 daemon.info dnsmasq[689]: using local addresses only for domain lan
Wed Aug 14 07:34:01 2019 daemon.info dnsmasq[689]: using nameserver 2a03:2260:3018:100::3#53
Wed Aug 14 07:34:01 2019 daemon.info dnsmasq[689]: using nameserver 2a03:2260:3018:100::2#53
Wed Aug 14 07:34:01 2019 daemon.info dnsmasq[689]: using nameserver 2a03:2260:3018::2#53
Wed Aug 14 07:34:15 2019 daemon.notice netifd: client (1214): cat: write error: Broken pipe
dmesg
[ 27.765748] IPv6: ADDRCONF(NETDEV_UP): mesh0: link is not ready
[ 27.977589] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
[ 29.226390] batman_adv: bat0: Adding interface: mesh0
[ 29.231863] batman_adv: bat0: Interface activated: mesh0
[ 31.091255] batman_adv: bat0: IGMP Querier appeared
[ 31.096468] batman_adv: bat0: MLD Querier appeared
[708577.489944] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0ddaGenau dieselbe Meldung haben wir auch meistens bevor ein Mesh zusammenbricht. Was im Moment meinen Verdacht unterstützt, dass es kein BATMAN_V Problem ist sondern eher ein Treiberproblem.
Ich habe auch herausgefunden, dass scheinbar auf vielen ath9k Geräten obwohl der Treiber Throughput Values unterstützen sollte nichts zurück kommt. Und deswegen überall 1Mbit/s als Throughput weitergegeben wird.
Ihr debugt aber nicht gerade zufällig den ATH9-Blackout, oder?
Was tut das Gerät, wenn man in der Situation „iw 20 $DEV station dump“ aufruft? (sinnvollerweise mit & aufrufen 
)
Friert das ein, also no return? (Siehe auch logik vom IW-freeze-reboot: https://github.com/eulenfunk/packages/blob/v2018.1.x/gluon-quickfix/files/lib/gluon/quickfix/quickfix.sh )
Wir haben jetzt folgenden Patch in unserer Firmware, der scheint so ziemlich die Probleme zu reparieren.