Anfang 2016 hatten wir beim Freifunk Stuttgart eine erhöhte Reboot-Rate von schwächeren Nodes, insbesondere den WR841. Als Ursache hatte sich eine zu hohe RA-Dichte herausgestellt, da die Verarbeitung von RA auf den Nodes sehr ressourcenintensiv ist (zumindest war).
Deshalb habe ich mir die Situation bei Euch im FFRN-Netz angesehen an einem Testnode mit der Experimental Firmware 1.1.2, der gerade so mit dem FFRN verbunden ist:
root@ffrn-Roland-Test:~# batctl gwl
[B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/6a:8b:f5:18:ee:0b (bat0/08:00:27:6c:bc:4a BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth
3a:59:70:e3:da:9e (235) ce:45:72:c2:ba:98 [ mesh-vpn]: 900.0/900.0 MBit
ae:65:a5:33:3a:78 (240) ce:45:72:c2:ba:98 [ mesh-vpn]: 900.0/900.0 MBit
f2:13:57:2a:db:1d (232) ce:45:72:c2:ba:98 [ mesh-vpn]: 900.0/900.0 MBit
ba:72:2d:0c:d8:64 (231) ce:45:72:c2:ba:98 [ mesh-vpn]: 900.0/900.0 MBit
7e:99:9f:1d:bc:a5 (231) ce:45:72:c2:ba:98 [ mesh-vpn]: 900.0/900.0 MBit
- ea:4e:50:02:e4:dc (255) ce:45:72:c2:ba:98 [ mesh-vpn]: 900.0/900.0 MBit
root@ffrn-Roland-Test:~#
Da werden alle 3 Sekunden folgende RA im FFRN-Netz verschickt:
fe80::5054:ff:fe3c:b702 ff02::1 ICMPv6 134 Router Advertisement from 52:54:00:66:66:66
Wir haben damals bei uns die Konfiguration vom radvd auf den Gateways angepasst, konkret den Parameter “MinDelayBetweenRAs” erhöht. Hierbei gilt es einen Kompromiss zu finden zwischen durchschnittlicher Wartezeit eines Clients auf ein RA und Systemlast. Persönlich würde ich nicht unter “MinDelayBetweenRAs 5;” gehen.
Vielleicht könnt ihr damit die Nodes soweit entlasten, dass sie mit der neuen Firmware klar kommen, ohne überdurchschnittlich zu rebooten.