2016.1 Firmware im Test

Eine neue Firmware für Radevormwald wurde als Beta veröffentlicht und ist hier zu finden:
http://firmware.freifunk-radevormwald.de/

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

CPE210/220/510/520 v1.1
TL-WA901N/ND v1
TL-WR710N v2
TL-WR801N/ND v1, v2
TL-WR841N/ND v10
TL-WR940N v1, v2, v3
TL-WR941ND v6
TL-WR1043N/ND v3

von TP-Link zu unterstützen. Seit einer Woche wird bereits eine größere Wolke damit erfolgreich betrieben. Rückmeldungen gerne hier im Thema.

1 Like

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
http://www.openfreiburg.de/freifunk/2016-expfuzzle/

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.

Ähnliches hat @jannic von einem Router berichtet.

Vielleicht sollte ihr das als issue zu Github tragen.

da würde ich doch an serverstelle mal 10 Router mit "while true ; do dmesg -c ; sleep 5; done & logread -f " wobei wenn batman failesd is auch schluss mit verbindung (in der regel)
ich setz mal 2 router auf reboot alle 10 minuten , damit die zeit haben sich im meshviewer zu melden : openfreiburg.de - Diese Website steht zum Verkauf! - Informationen zum Thema openfreiburg. und openfreiburg.de - Diese Website steht zum Verkauf! - Informationen zum Thema openfreiburg.
hier ist welche das sind, damit du die selber monitoren kannst.

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

1 Like

[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.

Keine Ahnung, ich konnte mich aus Dropbear-Gründen nicht einloggen. Ist halt ein Billig-Client.

[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 …

2 Likes

Vielen Dank dafür!

Wie äußert sich das? „kommt nix an am alfred-master“ oder auch auch „gibt lokal eine Fehlermeldung“?

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)

https://www.open-mesh.org/projects/alfred/wiki/Alfred_architecture

@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.

Thanks!

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)