gestern hat sich mal wieder ein Knoten abgehängt und ist heute ohne Eingriff wieder im Netz zurück. So ist das Logfile nicht durch ein Reboot verloren gegangen. Der “uplink” war die ganze Zeit online und konnte den angehängten Knoten auch sehen: http://map.4830.org/mueritz/#!v:m;n:30b5c22264ce
root@17194-Tressow-9824:~# logread
[...]
Tue Jun 28 15:57:48 2016 kern.err kernel: [490773.410000] ath: phy0: Failed to stop TX DMA, queues=0x002!
Tue Jun 28 15:57:56 2016 kern.err kernel: [490781.190000] ath: phy0: Failed to stop TX DMA, queues=0x002!
Tue Jun 28 15:57:57 2016 kern.err kernel: [490782.320000] ath: phy0: Failed to stop TX DMA, queues=0x002!
Tue Jun 28 15:57:58 2016 kern.err kernel: [490783.240000] ath: phy0: Failed to stop TX DMA, queues=0x002!
Tue Jun 28 15:58:02 2016 kern.err kernel: [490787.240000] ath: phy0: Failed to stop TX DMA, queues=0x002!
Tue Jun 28 15:58:24 2016 daemon.info hostapd: client0: STA cc:3a:61:97:91:33 IEEE 802.11: disassociated due to inactivity
Tue Jun 28 15:58:25 2016 daemon.info hostapd: client0: STA cc:3a:61:97:91:33 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Jun 28 16:02:01 2016 user.notice gluon-offline-ssid: TQ is 0, SSID is mueritz.freifunk.net, change to FF_OFFLINE_60e327c79824
Tue Jun 28 16:05:44 2016 daemon.info dnsmasq[1292]: reading /tmp/resolv.conf.auto
Tue Jun 28 16:05:44 2016 daemon.info dnsmasq[1292]: using local addresses only for domain lan
Tue Jun 28 16:05:44 2016 daemon.info dnsmasq[1292]: using nameserver fd39:e4e3:eee1::5#53
Tue Jun 28 16:13:13 2016 daemon.warn dnsmasq[1292]: no servers found in /tmp/resolv.conf.auto, will retry
Tue Jun 28 22:11:57 2016 daemon.info dnsmasq[1292]: reading /tmp/resolv.conf.auto
Tue Jun 28 22:11:57 2016 daemon.info dnsmasq[1292]: using local addresses only for domain lan
Tue Jun 28 22:11:57 2016 daemon.info dnsmasq[1292]: using nameserver fd39:e4e3:eee1::6#53
Tue Jun 28 22:12:03 2016 daemon.info dnsmasq[1292]: reading /tmp/resolv.conf.auto
Tue Jun 28 22:12:03 2016 daemon.info dnsmasq[1292]: using local addresses only for domain lan
Tue Jun 28 22:12:03 2016 daemon.info dnsmasq[1292]: using nameserver fd39:e4e3:eee1::6#53
Tue Jun 28 22:12:03 2016 daemon.info dnsmasq[1292]: using nameserver fd39:e4e3:eee1::5#53
Tue Jun 28 22:13:00 2016 user.notice gluon-offline-ssid: TQ is 68, SSID is FF_OFFLINE_60e327c79824, change to mueritz.freifunk.net
Örks. Das ist ein Bug, der eigentlich längst gefixt sein sollte. Es gibt von einer anderen Community ein Modul, was bei Auftreten dieser Situation den Knoten rebootet. Ich guck’ mal, damit eine neue experimental fertig zu machen, evtl. erklärt das verschiedene (Teil-) Ausfälle auch bei uns im Kreis GT.
… hier funktionierte es auf dem Knoten, der die Verbindung „verloren“ hatte. Die Gegenstelle hat den selben Aufruf zur gleichen Zeit (+/- Zeitdifferenz der Geräte) - das Protokoll dazu ist schon übergelaufen …
Vielleicht passt der „Workaround“ in /lib/gluon/ssid-changer/ssid-changer.sh
Wenn Verbindung wech … dann „schaun wir mal“ uns um. Ob das protokolliert werden soll oder im Nirvana landet, ist später für stable interessant.
Leider ist das der einzige Standort, an dem ich das bis jetzt nachvollziehen konnte.
Wed Jul 6 17:47:38 2016 kern.err kernel: [45268.360000] ath: phy0: Failed to stop TX DMA, queues=0x002!
Wed Jul 6 17:48:03 2016 kern.err kernel: [45293.750000] ath: phy0: Failed to stop TX DMA, queues=0x00a!
Wed Jul 6 17:53:00 2016 user.notice gluon-offline-ssid: TQ is 0, SSID is mueritz.freifunk.net, change to FF_OFFLINE_e894f660e6ae
Wed Jul 6 17:53:55 2016 daemon.info dnsmasq[1379]: reading /tmp/resolv.conf.auto
Wed Jul 6 17:53:55 2016 daemon.info dnsmasq[1379]: using local addresses only for domain lan
Wed Jul 6 17:53:55 2016 daemon.info dnsmasq[1379]: using nameserver fd39:e4e3:eee1::5#53
Wed Jul 6 17:57:36 2016 daemon.warn dnsmasq[1379]: no servers found in /tmp/resolv.conf.auto, will retry
Wed Jul 6 18:00:01 2016 cron.info crond[963]: crond: USER root pid 21813 cmd /usr/sbin/iw dev mesh0 scan | grep -i SSID > /tmp/SSID_scan.txt
Wed Jul 6 18:00:07 2016 daemon.info dnsmasq[1379]: reading /tmp/resolv.conf.auto
Wed Jul 6 18:00:07 2016 daemon.info dnsmasq[1379]: using local addresses only for domain lan
Wed Jul 6 18:00:07 2016 daemon.info dnsmasq[1379]: using nameserver fd39:e4e3:eee1::6#53
Wed Jul 6 18:00:07 2016 daemon.info dnsmasq[1379]: using nameserver fd39:e4e3:eee1::5#53
Wed Jul 6 18:00:39 2016 daemon.info dnsmasq[1379]: reading /tmp/resolv.conf.auto
Wed Jul 6 18:00:39 2016 daemon.info dnsmasq[1379]: using local addresses only for domain lan
Wed Jul 6 18:00:39 2016 daemon.info dnsmasq[1379]: using nameserver fd39:e4e3:eee1::6#53
Wed Jul 6 18:00:39 2016 daemon.info dnsmasq[1379]: using nameserver fd39:e4e3:eee1::5#53
Wed Jul 6 18:03:00 2016 user.notice gluon-offline-ssid: TQ is 89, SSID is FF_OFFLINE_e894f660e6ae, change to mueritz.freifunk.net
heute hatten bei drei hartnäckigen Fällen auch die Uplinks (2x 1043ND / 1x 841N) die Schuld … dort war mesh0 weg.
Thu Jul 7 15:45:01 2016 cron.info crond[994]: crond: USER root pid 29742 cmd /usr/sbin/iw dev mesh0 scan | grep SSID > /tmp/scan_SSID.txt
Thu Jul 7 15:45:02 2016 kern.info kernel: [14556.560000] IPv6: ADDRCONF(NETDEV_UP): mesh0: link is not ready
Nun habe ich dort noch in /etc/crontabs/root folgende Zeile eingebaut:
*/6 * * * * if [ $(ifconfig | grep ^mesh0 | wc -l) -eq 0 ]; then sleep 30; if [ $(ifconfig | grep ^mesh0 | wc -l) -eq 0 ]; then reboot; fi; fi
Gruß
Matthias
PS: Vielleicht hat das ja auch nix zu sagen … aber aufgefallen ist mir, dass die Meldung “Failed to stop TX DMA”’, wenn sie überhaupt auftaucht, bei 841-v9-Geräten häufiger auftritt als bei 841-v10- und 1043-v2-Geräten.