Sie wurde aus dem aktuellen Gluon master (2016.1) gebaut und basiert somit auf OpenWrt Chaos-Calmer 15.05. Der Schritt war vor allem notwendig, um die neuen Router Versionen
Wenn Du was automatisiert testen kannst, dann logge dich mal auf einem Router ein und sage „reboot“.
Und schaue, wie oft das geht, bevor er irgendwie nicht mehr sauber hochkommt.
Ich fürchte nämlich, dass es da eine Chance von etwa 1:30 gibt, dass es nicht klappt.
(Mag aber auch meinem Build liegen. Und trifft auch Geräte mit 8MB Flash und 64MB RAM. Also nicht nur die 841er.)
ich hab den freiburger build im bau, die 2016.1 und da „nur“ 3-5 router am laufen zum test … das funktioniert super, auch mit ettlichen reboots …
wenn du willst mach ich den Test … an einem router https://cccfr.de/git/viisauksena/firmware
Würde mir helfen, Vertrauen in den ChaosChalmer aufzubauen. Danke.
(Hintergrund: Wir haben hier letztes Wochenende einen Master-Build auf etwa 40 Router ausgerollt nachdem der Test von rund einer Woche auf 12 Routern „mit direktem Zugriff“ gut aussah. Seitdem haben wir einige Router powercyclen müssen, weil sie aus dem Monitoring verschwanden. Entweder direkt, oder bei einem Konsolen-Reboot nicht wiederkamen.
Symptom war immer gleich: Auf dem link-local ipv6 (eth) waren sie noch erreichbar, aber der Batman etc liefen nicht.
code für server/computer im freifunknetz with ssh-access :
while true; do echo -n " ##### TESTING ####### "; echo -n „reboot all 10 minutes and look router comes up“ ; echo -n " this is $i attempt at $(date) " ; let i+=1; ssh root@fdf0:9bb:7814:a630:eade:27ff:fef9:908 „echo -n ‚alfred‘$(alfred -r 159 |wc -l)’ batman’$(batctl o|wc -l); reboot“; sleep 600; done
deine „50 reboots“ erreichen wir dann in etwa 8-9 Stunden
[quote=„adorfer, post:4, topic:10302“]
aber der Batman etc liefen nicht.
[/quote] das heisst login ginge, was sagte da dmesg dazu - batman wirklich abgesegelt, ganz vereinzelt haben wir router bei denen versagt alfred, aber das für das funktionierende Netz ja bedeutungslos - nur im meshviewer sieht das doof aus.
[quote=„adorfer, post:8, topic:10302“]
Keine Ahnung, ich konnte mich aus Dropbear-Gründen nicht einloggen. Ist halt ein Billig-Client.
[/quote]verstehe den teil nicht - is auch hübsch indifferent.
Der ssh-server des disfunktionalen nodes liess sich noch ansprechen auf der IPv6-Linklocal.
Ping auf IPv6-linklocal ging auch noch.
Einloggen auf dem Knoten konnte ich mich mangels gesetztem Passwort (ohne ssh-key) und wegen gesetzten Passworts (im ssh-key) leider nicht. Das ist dann aber kein Problem des betreffenden Nodes.
also … beide knoten sind 70 mal wieder gekommen, keine probleme dahingehend, allerdings hab ich nen anderes problem gefunden :
alfred -r 159 und alfred -r 158 failen meistens (nicht immer ) beide …
nein, kein Eintrag in dmesg und logread auf dem Knoten … nur alfred lokal faild mit Request failed with 1 nach nem gefühlten timeout - das betrifft aber nur die identifier 159 und 158 … die auch durch unser netz geisternde 119 ist da kein problem(sehr wenige Daten), das bedeutet es scheint was mir der größe, bzw Masse der Paktete zu tun zu haben die zu einem Zeitpunkt x nicht da sind.
Im Moment laufen in unserem Netz auch mehrere Master - wie in der Alfred Doku beschrieben. Im Grunde auf vielen der Supernodes. Bei einer Größe von etwa 300 Knoten und 5-10 Supernodes
Zusätzlich kann ich anbieten time alfred -r 159 ; time alfred -r 159 ; time alfred -r 159 ;
real 0m 13.38s
real 0m 59.99s
real 0m 59.98s
und einmal auf dem 2. Testknoten … das lässt sic beliebig wiederholen.
real 0m 31.42s
real 0m 59.99s
real 0m 59.99s
Das sieht für mich danach aus, das da minütlich „Dinge“ passieren die Alfred an der Stelle crashen lassen … in den minütliche Rhythmus komm ich halt irgendwann rein (daher 1. time x<1m und die anderen sind ziemlich straight 60 sekunden)
@fuzzle have you found the cause of the ‚Request failed with 1‘ message?
I’m having that message in alfred when I want to set new data using ‚alfred -s 64‘
We are using this functionality to share dhcp leases on LibreMesh, but this is failing sometimes with that issue.
i dont know - but i remember that you cant use the first xx bytes … from alfred (see alfred and batman-adv manpages/ doku for that)
and also we found that the bug seem to be in the old batman v14 and in excessive datalosses … so at the end some people suggest to use ONLY one alfred master to minimize the failings , the error comes from too much fragmentet alfred data arriving at different times and corruping your alfred-dataset
so technicaly , reducing the size of alfred data send is also good
(which i think is the main reason for using gzip on alfred data in gluon/freifunk)