[fyi] wifi hängt sich auf - emergency script

Technik Gluon
1

wer ärger mit hängenden Knoten hat, dessen Wifi sich abschiesst, hab hier gerade ein emergency script dazu laufen, der ein oder andere findet das vielleicht ganz brauchbar
(prüft gegen batman gateway die gesehen werden - fastd)

bezogen auf Gluon Issue889 - Lede Bug - gluonv2016.2-master
und bestimmt noch weitere Fehler mit ATH9k mac80211 / ibss0 sta

$ cat emergency.sh

#!/bin/sh

# set some sysctl
# see kernel.org/doc/Documentation/sysctl/vm.txt
sysctl -w vm.panic_on_oom=0 # deact reboot on oom
sysctl -w kernel.panic=80 # 80s after panic reboot
sysctl -w vm.overcommit_memory=2 # calc if enough mem is avail mmaloc
echo 100 > /proc/sys/vm/overcommit_ratio # max % useable mem
echo 0 > /proc/sys/vm/user_reserve_kbytes # only root need reserve
echo 128 > /proc/sys/vm/lowmem_reserve_ratio

# raise prob. of proc to kill
# echo 10 > /proc/$(cat /var/run/fastd.mesh_vpn.pid)/oom_adj # deprecated
echo 700 > /proc/$(pgrep fastd)/oom_score_adj # fastd
echo 900 > /proc/$(pgrep ntp)/oom_score_adj # ntp
echo 950 > /proc/$(pgrep /usr/sbin/batadv-vis)/oom_score_adj # batvis

# if we see bat GW just exit
netz=$(batctl gwl -H|grep -v "gateways in range"|wc -l)
if [ $netz -ne 0 ] ; then
        echo "$0 found GW in network, exiting"|logger
        echo 0 > /tmp/emergency
        exit 0
fi

# see ath9k for stopped
# cat /sys/kernel/debug/ieee80211/phy0/ath9k/queues

# simple counter 
touch /tmp/emergency
counter=$(cat /tmp/emergency)
if [ -z $counter ] ; then counter=0 ; fi
if [ $counter -lt 10 ]
        then
                let counter+=1
                echo $counter > /tmp/emergency
                if [ $counter -eq 3 ]; then echo "$0 - 3 min offline - try wifi"|logger; wifi ; fi
                if [ $counter -eq 5 ]; then echo "$0 - 5 min offline - try restart fastd"|logger; /etc/init.d/fastd restart ; fi
                if [ $counter -eq 7 ]; then echo "$0 - 5 min offline - try restart network"|logger; /etc/init.d/network restart ; fi
        else reboot
fi
echo $counter

edit: kleine Fehler ausgemerzt, mit overcommit ist ggf. ein autoupdate auf den 32mb geräten nicht möglich!

2 „Gefällt mir“
2

wichtig zu erwähnen wäre das sich dieses script mit so v14-zu-v15 update skripten beissen wird, die arbeiten in der regel auch so dass Knoten die länger kein batman gw haben - ein spezielles Script ausführen … das würde nie passieren, oder mittendrin failen wenn dieses script nach 10 min. einen reboot ausführt.
das gilt es nur zu beachten wenn man das hier längerfristig einbauen wollte.

3

Ja schön, haben wir das Rad also nochmal neu erfunden.

Die schon mehrmals besprochenen Packages für Linkcheck und IP6-detachment kommen nicht von ungefähr.
(und haben sich bewährt)

@fuzzle ob sich das jetzt mit dem irreführend benannten Script beisst: Mag sein, sollte es aber eigentlich maximal einmal beim erstmaligen Wegbrechen des Mesches der Nachbarn. Danach ist dann „Insellage“ und die Resets greifen nicht mehr.

4

@adorfer … einer von uns beiden hat jetzt die skripte nicht genau angesehen, nach dem ersten drüberfliegen machen die von dir vorgeschlagenen zwar etwas ähnliches – aber lange nicht aus dem gleichen Grund, und die Lösungsstrategie ist auch anders - wenngleich beide als ulitma ratio einen reboot enforcen.

edit jedenfalls machen deine auch bei fastd funktionierenden Uplink Knoten einen check ob deren ibss0 noch tut - das mach ich (bisher) nicht, da das auch sekundär scheint. Ich vermute dsa ich das über die Karte gut herusfinden würde.

5

Reboots on oom habe ich nicht mit drin.
Ich gehe schlicht davon aus, dass wenn das auftritt, dann auch das Script es noch schafft, die aus dem oom folgenden Effekte zu erkennen und neu zu starten.
Das Prüfen der AT9K-Queues ist natürlich fixer als wenn man nur schaut, ob einem die Neighbors abhanden gekommen sind und „so ruhig“ auf dem Wlan geworden ist.

6

das Problem das es zu lösen galt - scheint gelöst