Moin
es wäre super wenn einfach alle die es noch nicht getan haben die 0.8.2
signieren würden!
Es sind zwar 4 Gültige Signaturen vorhanden, allerdings updaten sich die
Router < 0.8 nicht, da diesen zum Beispiel meine Signatur auf Firmware <
0.8 noch nicht bekannt ist. Dadurch stellt der Autoupdater fest, dass
noch nicht genügend gültige Signaturen vorhanden sind und updatet nicht.
Daher bitte Signieren Danke ! (Das ist ja auch schnell gemacht)
Gruß
Johannes
Hi,
Johannes hat sich mit dem CI System von Gitlab beschäftigt und ein paar
Scripte gebastelt, die bei jedem Commit in das siteconf Repo automatisch eine
neue Firmware bauen, signieren und unter folgender URL hochladen:
http://firmware.nordwest.freifunk.net/nightly/<SITECONF-BRANCHNAME>
Ich habe das ganze noch ein wenig überarbeitet und jetzt scharf geschaltet.
Die relevanten Dateien zur Konfiguration liegen im siteconf Repo unter:
* .gitlab-ci.yml
* build/
Dokumentation:
* http://doc.gitlab.com/ce/ci/yaml/README.html
* Doku im Wiki ist TODO
Aktuell ist das Feature für die folgenden Branches aktiviert:
* master
* citest
Jeder der häufig Änderungen an der Firmware testen muss oder neue Dinge
entwickelt, kann bei Bedarf einen eigenen Branch im siteconf Repo anlegen und
das automatische Bauen der Firmware für den Branch aktivieren indem er den
Namen des Branches in seinem Branch im .gitlab-ci.yml Script in den jeweiligen
Abschnitten von "only" hinzufügt.
Wenn man dann noch die "modules"-Datei auf einen eigenen packages Branch
anpasst und einen eigenen Update-Channel in der Siteconf hinzufügt kann man
sich damit eine richtig schöne Testumgebung mit automatischem Deployment auf
Testroutern realisieren.
Builds angucken:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds
Viel Spaß damit und viele Grüße
Clemens
P.S. Da das Artifacts-Feature von Gitlab erst in einer der kommenden Versionen
auto removing von Artifacts unterstützen wird, wird die Firmware aktuell nur
für den wr841n/d deployed um den Speicherbedarf für Artifacts im Gitlab in
Grenzen zu halten.
Moin,
ich weiß nun warum sich alte Router die noch 0.6x oder so haben nicht
updaten, sie kennen die neuen Signaturen nicht.
Wie lösen wir das nun am besten?
Könnten noch leute die in der 0.6 Firmware die keys hatten bitte noch
die 0.8.2 signieren dass sich die noch hängengebliebenden Router
updaten, danke !
Gruß
Johannes
root@oldenburg-stuwo-pferdemarkt16-1:~# autoupdater
Connecting to autoupdate.ffnw ([2a03:4000:6:8025::1]:80)
- 100% |*******************************| 22144
0:00:00 ETA
Not enough valid signatures!
No usable mirror found.
Hi,
ich bin in der misslichen Lage, dass ich ein Paket auf dem Router
nachinstallieren muss (Firmware ist auf Stand aktueller master). Das Blöde:
der Router denkt er sei per IPv6 angebunden und löst demzufolge jede Adresse
für die ein AAAA Record existiert auf den AAAA record auf obwohl ich natürlich
nur per IPv4 angebunden bin.
Ich hatte kurz die Idee IPv6 per sysctl einfach zu disablen, aber dann läuft
auch link local nicht mehr. Was kann ich tun?
Viele Grüße
Clemens
Hi,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
* Firmware-Version: 0.8.2
* Gluon-Version: 2016.1.3
* Download: http://firmware.nordwest.freifunk.net/0.8.2/
Folgende Änderungen gab es:
* vpn-Server wurden von srvxx zu vpnyy geändert
vg
bjo
--
xmpp bjo(a)schafweide.org
Moin,
zusammen mit Stefan habe ich eine Lösung entwickelt, mit der wir im Meshviewer schnell sehen können welche Router in welcher Hood ist.
Dieses wird durch den siteCode in der site.conf gesteuert.
Die site.conf ist auch auf dem Router abgesichert und wird von respondd ausgelesen.
respondd sammelt die Daten zusammen und sendete sie an Alfred bzw im neuen Setup an den Nachfolger.
Demnach müsste die site.conf bei setzten eine Hood durch den Hoodselector angepasst werden. Ich habe dieses auch schon erfolgreich testen können.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/feature/SiteC…
Was haltet ihr davon? Meinungen?
Gruß
Johannes
Hi,
ich habe mir nach dem letzten Arbeitstreffen den hoodselector nochmals
angeschaut und durch gespielt.
https://pad.ffnw.de/p/hoods-testcases
(Ab den Punkt Hoodselector evaluirungsphase)
Wir haben in dem Pad vor ein paar Wochen test-cases eruiert. Es
fehlt im Grunde ein testcase wo Clemens und ich, länger drüber
diskutiert haben und uns letztlich dafür entschieden hatten diesen Fall
erst mal auszuschließen.
Aktuell ist es so, das der hoodselector, wenn er keine geo Position hat,
nach benachbarten BSSIDs von Mesh Routern scannt und anschließend die
dazu gehörige hood aus dem hoodfile holt. Wenn keine hood zu der
gescannten BSSID existiert beendet sich der hoodselector und bleibt
weiterhin in der hood die beim Durchlauf zuvor gesetzt wurde.
Wenn wir jetzt einen Mesh-Router haben und einen VPN-Router die
miteinander meshen und es wird z.B. eine neue Firmware mit neuen hoods
verteilt, kann folgendes Problem auftreten. Der VPN-Router updatet
vor dem MeshRouter und wechselt in eine andere neue Hood. Der
Mesh-Router wäre somit offline und würde kein Firmware Image bekommen.
Nun kommt ein Lösungsvorschlag den ich in einer früheren Version des
Hoodselectors schon einmal implementiert hatte.
Wenn der Hoodselector keine geo Position hat, scannt er nach
benachbarten BSSIDs von Mesh Routern um anschließend die dazu gehörige
hood aus dem hoodfile zu holt. Wenn keine hood zu der gescannten BSSID
existiert setzt der Router die gescannte BSSID mit der default Hood.
Anschließend beendet sich der hoodselector.
Problem hierbei ist das zwei Hoods über Layer2 verbunden werden könnten.
Was ein wahrscheinlichen Ausfall beider betroffenen Hoods zur folge hätte.
Mein vorchlag hier wäre also wenn eine gescannte BSSID gesetzt wird,
wird fastd abgeschaltet. Somit kann der Router nur Meshen.
Im nächsten Durchlauf würde der hoodselector dann versuchen eine
geoposition zu beziehen. Ist das nicht erfolgreich so würde der Router
prüfen ob Batman-adv GWs in Reichweite sind. Ist das der Fall beendet
sich der hoodselechtor. Ist es nicht der Fall. So würde der Router
wieder in den scann Vorgang gehen. Solange bis er Batman-adv GWs findet
oder es keine anderen BSSIDs die unterschiedlich zu eigenen sind gibt.
Kann der Hoodselector eine Geoposition ermitteln, so setzt der
Hoodselector wieder die andere Hood und BSSID, die er über die
Geoposition bezogen hatte. Die Folge wäre eine Trennung zum Restlichen
Netz.
Auch hier hatte ich schon eine mögliche Lösung implementiert. Das wenn
der Router eine Hood via Position hat, der Hoodselector prüfen soll ob
er Batman-adv GWs sieht. Wenn ja soll er die hood ganz normal setzen.
Wenn der hoodselector keine GWs findet soll die o.g. scannroutine einsetzen.
package repo:
git diff edbba3be529c0d31c0f529cbaebca6e9edff01cc
58234d27a07fa72f59c7add49da2d02cae0483bc
An dieser stell bin ich mir noch nicht ganz sicher denn es würde wenn
ich mich logisch nicht irre eine loop entstehen das. Der Router eine
bssid des nachbar Routers setzen würde mit abgeschalteten fastd. Im
nächsten Durchlauf hätte der Router ja eine batman-adv GWs und würde
somit wieder eine bestehende hood aus seinen hoodfile entnehmen. Dieses
Phänomen würde somit immer wieder wechselnd eintreten. Eine Elegante
Lösung ist mit noch nicht eingefallen. Evtl. hat jemand von euch eine
mögliche Lösung die ich noch nicht gesehen hab.
Schönen Gruß
Tarek
Hi,
@Johannes:
Ich habe gerade den commit 8c373f9987036f0fd5e024254a0539ceb3109618
rückgängig gemacht da dieser ein falschen File Format Besitz. Die Datei
wurde wohl in dos Format abgespeichert. dos nutzt die Endung CRLF
anstatt nur LF für endlines. Magst du den commit noch mal korrigieren ?
vg
Tarek
