Großes Release 20171211 auf LEDE

Moin Moin Leute,

 

Es ist wieder soweit wir haben eine neue Firmware gebaut. Diesmal handelt es sich um ein großes Rundum-Update.
Für dieses Update gibt es allerdings ein paar Dinge zu beachten. Falls ihr zu irgendwelche Punkten fragen habt: Mail an die Info Adresse.

 

Erster wichtiger Hinweis

Ältere Firmware Versionen sollten vorher auf Version 20170822 [11]  upgraden, um möglichen Problemen vorzubeugen. Router, die den autoupdater an haben, sollten also bereits auf 20170822 sein und updaten somit auch automatisch auf die Version 20171211. Insbesondere gibt es ein Problem in allen Gluonversionen vor 2016.2.7, welches die x86 Systeme betrifft. Diese verlieren ihre Konfiguration, wenn sie auf Gluon 2017.1.x updaten. Ältere Firmwareversionen sollten vorher auf 20170822 [11] upgraden, bevor diese 20171211 installieren. Wer den autoupdater deaktiviert hat, kann mit folgendem Befehl automatich updaten.
autoupdater -f
Der autoupdater sorgt dafür, dass alle Router zunächst mal auf  Version 20170822 (Gluon 2016.2.7) und erst von dort dann weiter auf die 20171211 (Gluon 2017.1.4). Auch wenn später noch Router mit noch älteren Versionen aus dem Schrank geholt werden, updaten die zuerst einmal auf die 20170822.

 

Zweiter wichtiger Hinweis

Für alle, die Setups mit PoE-Passthrough betreiben. Wenn ihr auf Nummer sicher gehen wollt, dass alle eure PoE-Passthrough Geräte das Ausrollen der Firmware heile überstehen, solltet ihr dort, wo PoE-Passthrough aktiviert ist, sicherstellen, dass _nicht_ genau dann vorne in der PoE-Kaskade ein reboot stattfindet, wenn weiter hinten geflasht wird. Mit anderen Worten es sollte genug Zeit nach dem Update der hinteren Router vergangen sein, bevor die vorderen updaten. Die eleganteste Möglichkeit hierzu ist wohl, die Minuten der cronjobs auf den einzelnen Routern entsprechend anzupassen. Hierzu mit vi in der /usr/lib/micron.d/autoupdater die erste Spalte bearbeiten. Danach noch /etc/init.d/micrond reload ausführen. Diese variante ist allerdings nicht update fest und ist somit beim nächsten update nicht mehr exsistent!

 

Alternativ kann man den Autoupdater deaktivieren und das Update zu einem Zeitpunkt händisch ausführen, wenn sicher ist, dass die per PoE-Passthrough betriebenen Geräten das Update bereits installiert haben. Folgender Befehl tut das:

 

Um zu prüfen das PoE-Passthrough aktiv ist. Wenn der zurück gelieferte wert 1 ist, ist es aktiv.

uci get system.gpio_switch_poe_passthrough.value
Dann könnt ihr mit folgendem Befehl den autoupdater ausschalten.

uci set autoupdater.settings.enabled='0'
uci commit autoupdater
Ob und welcher Aufwand sich lohnt muss jede/r selbst entscheiden. Das bricken eines Routers kann mit einer gewissen Warscheinlichkeit passieren, muss aber nicht.

 

Dritter wichtiger Hinweis

Ein potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltest du vor den update auf 20171211 machen! Der Befehl für qemu wäre z.b. folgender:

qemu-img resize $IMAGE 273MB

(mehr …)

geolocator (Software defined GPS)

Hallo zusammen,

Mein Name ist Jan-Tarek Butt. Ich studiere in meinem 4. Semester Informatik an der Hochschule Emden/Leer in Niedersachsen. Einige von euch kennen mich wahrscheinlich schon als langjähriges aktives Mitglied der Freifunk Community und vom letzten Google Summer of Code 2016. Dieses Jahr bin ich wieder einer der Studenten die für Freifunk am Google Summer of Code 2017 teilnehmen dürfen. Im folgenden Beitrag möchte ich eine kleine Einführung in mein diesjährigen Projekt beim Google Summer of Code geben. Wie letztes Jahr habe ich auch dieses Projekt in 3 Teilprojekte zerlegt: web backend, gps-share und LEDE Package (mehr …)

Monitoring and quality assurance of open wifi networks out of client view (final evaluation)

Hi together,

now the time has come to explain the full Google Summer of Code Project. In both blog posts before I explained the work packages and structure of the Project [0][1]. In the first post I declare the three main subjects. Here is a short overview to remind of the project structure:

sub-projects,

Mainline project

and seminars.

The sub-projects are background work for community projects.

The mainline Google Summer of Code project is to develop a new firmware for routers, based on LEDE [2]. The third point are seminars for enlightment of technical aspects of the Freifunk Community. (mehr …)

Monitoring and quality assurance of open wifi networks out of client view (midterm evaluation)

Hey everyone,
Now we are on the midterm evaluation. I would like to tell you what I have done so far and what will come next. In the first post [0] I explained the work packages. In this post I will come back to the work packages  and show you what I have done for each package.
The first sub-project was the hoodselector. At the beginning of the work period I did some bugfixing for the hoodselector so that we where able to deploy the hoodselector in our live environment. The hoodselector creates decentralized, semi automated ISO OSI layer 2 network segmentations. You can find a detailed discription here [0]. Retrospective I can say that the deploymend of the hoodsystem went without any major problems opposed to my first expectations. Currently we have 4 hoods active. Around Oldenburg(Oldb), Ibbenbüren, Osnabrück and Friesland. More hoods will follow in future. Open Issues can be find here [1].
The second sub-project was to create a propper workaround for building images with the continuous-integration (CI) system of Gitlab using make on multiple cores.
The Freifunk Nordwest firmware now has automatically built testing images that are not only build on a single core but can be built on multiple cores. And the architecture targets are also autogenerated out of the sourcecode. This makes it possible to generate images dynamically for all
targets also including new targets that may come in the future. I implemented a small algorithm that manages the thread counter of make commands. I
use the number of CPUs out of /proc/cpuinfo * 2 this means for each logic core will follow two threads. In example our runner02.ffnw.de server has 8 cores so the CI build process will automatically build with 16 Threads [2]. Here is an example of a passed buildprocess with our CI builder[3]. Actually it is not possible to build images with a high verbose output, because the CI logfiles will get to big. That makes it impossible to use the webfrontend for analyzing the buildprocesses. I opened an issues for this and discussed the problem with the gitlab developers [4].
The CI builder is very helpful for the developing process of the monitoring drone.
Following I would like to report about our first hacking seminar.
The first hacking seminar was on 28.05.2016. We started with two presentations. One about Wireless Geo Location and the second one about the Hoodselector. We recorded the presentation with our new recording equipment [7] bought using some of the money for the mentoring organisation and uploaded the recordings to youtube [5].
The first presentation was about geolocating with wireles technologies.
Based on the Nordwest Freifunk geolocator [6]

The second presentation was about the function of the Hoodselector


After this two presentations we had a smal disscussion about the presentation topics and than we started o
ur hacking session where the developers started coding on their projects.
Now all sub-Projects are finnisched and I will continue with the Monitoring Drone Project after I finish my Study exams. Also the date of next hacking seminar is set for 9th of Juli 2016. Again we will have two presentations. One on Gitlab CI and one about how to use our new Puppet Git repositories including the submodule feature. The presentations will be recorded and after the presentation we will have a coding session like last time.
Timeline:
23. May: Community Bonding (3 weeks)
test and deploy hoodselector  <- Done
16. May 6:00 PM: GSoC Mumble  <- Done
Refine the roadmap  <- Done
23. May – 20. June: Work period 1 (4 weeks) <- Done
28. May 2:00 PM: hacker-session  <- Done
  1. Presentation about the hoodselector <- Done
  2. Presentation about the openwifi.su project[4] and the geolocator <- Done
13. June 6:00 PM: GSoC Mumble  <- Done
Midtermevaluation
Tarek & Clemens exams!!!
20. June – 15. August: Work period 2 (8 weeks)
9. July 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. Presentation about puppet deployment system
13. June 6:00 PM: GSoC Mumble
25. June 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. Presentation about puppet deployment system
18. July 6:00 PM: GSoC Mumble
30. July 2:00 PM: hacker-session
  1. actual unknown
  2. actual unknown
15. August 6:00 PM: GSoC Mumble
Finalevaluation