Neue Firmware Beta 0.6.9 und Experimental 1.0.0

Technik Gluon
1

Es ist mal wieder soweit, es gibt neue Firmware und diesmal wird sich einiges verändern.

Beta 0.6.9:
Dies Firmware enthält insbesondere Änderungen die wichtig sind um ein reibungsloses Upgrade auf Gluon 2017.1 und damit auf LEDE zu ermöglichen. Ohne dieses Update verlieren die Knoten beim Update auf die nächste Firmware Version 1.0.0 ihre Konfiguration. Es ist also extrem wichtig, dass ihr alle guckt, dass eure Knoten aktualisiert werden. Unabhängig davon werden wir den Fallback aus unserer Umstellung auf von IBSS Mesh auf 802.11s nutzen um zu verhindern das Knoten direkt auf LEDE Updaten. (Zumindest für eine Übergangszeit)

Experimental 1.0.0
Mit dem Update auf Gluon 2017.1 und damit mit der Umstellung auf LEDE werden wir die Versionnummer auf 1.x.x anheben, um diesen Schritt entsprechend zu würdigen. Hier gibt es viele Umstellungen, die dabei helfen sollten das System besser und stabiler zu halten.

Eine weitere, organisatorische Änderung ist, dass ab sofort @NurticVibe für die Firmware verantwortlich ist und daher auch sein Key für die Signatur der Images in diesen Updates enthalten ist.

Beider Versionen werden im laufe des Abends veröffentlicht. Probleme bitte wie immer hier melden.

3 „Gefällt mir“
2

Die Firmware ist ab sofort via Autoupdater verfügbar.

3

Wir debuggen gerade noch Probleme mit dem Manifest File das die Updates verifiziert in der v1.0.0, dort funktionieren daher aktuell keine Autoupdates.

4

Wenn ich es jetzt richtig im großen freifunk-forum mitbekommen habe ist die 0.6.9 dann auch zwingend, vor allem für x86 Offloader um später entsprechend auf LEDE zu switchen - ist das richtig so?!

5

Ja, das Update auf 0.6.9 ist zwingend für alle Geräte mit Firmware kleiner als 0.7.x.

6

Die Signatur der Experimental sollte jetzt auch stimmen.

7

Jetzt ist das Update durchgelaufen. Sieht soweit ganz gut aus.

Das Webinterface ist wieder magenta - ist das Absicht?

8

Nein ist es nicht. Welche Version und wo? Status Seite oder Config Mode?

Hattest du auf dem Knoten vorher einen von @NurticVibe seinen nightly Builds? Die waren/sind Magenta um sie zu erkennen. Evl. ist das dein Browser Cache der da noch alte Daten hält.

9

Status Seite:

http://bensheim-018.nodes.ffrn.de/

War vorher die letzte “normale” experimental drauf, kein nightly build oder sowas.

Browser Cache ist auch unwahrscheinlich:

 root@Bensheim-018:~# grep -r dc0067  /lib/
 /lib/gluon/status-page/www/index.html:  background: #dc0067;
10

Übeltäter gefunden,
In der Status Page ist wohl die Farbe nochmals separat deklariert, ausserhalb des Theme

# ~/gluon/experimental$ grep -srnw dc0067 package/*
     package/gluon-status-page/src/css/main.css:26:  background: #dc0067;

Wird beim nächsten Update gefixt

2 „Gefällt mir“
11

Ich habe einige 842er, die auf experimental 0.7.1-20170415 laufen, langfristig aber auf stable laufen sollen.

Was ist da die Empfehlung? So laufen lassen, und wenn die 1.0 in stable angelangt ist, per autoupdater updaten?

Oder sicherheitshalber ganz neu flashen?

12

Genau das würde ich so machen.

13

Gibt es Feedback zu den Versionen?

14

Die Experimental läuft bei mir seit dem automatischen Rollout super! ;)

15

Die Firmware Version 0.6.9 befindet sich ab sofort im Stable Zweig.

16

Manuelle Installation der 1.0.0 geht auf einem 841.
Aber der Neustart danach ergibt einen XML-Fehler.
Da der Quelltext dann alle Informationen enhält, habe ich den VPN-Key da raus kopiert und in der Knotenverwaltung eingetragen. (Token hatte ich noch, weil der Knoten vorher schon mal registriert war.)
Aber der VPN sei ungültig, sagt die Knotenverwaltung.

17

Kannst du bitte den XML Fehler und den Quelltext kopieren und zur Verfügung stellen?

1 „Gefällt mir“
18

Sorry, hab ich nicht gespeichert. Der Fehler sagt, dass das XML nicht richtig formatiert sei, aber der Quelltext enthält dann alle Informationen. Wird dann in roh-Form unter dem Fehler angezeigt. Wenn ich noch mal so was sehe, dann speichere ich da.

19

Habe auf meinem 842er gerade folgendes im dmesg gesehen (Bensheim-018):

... soweit alles ok
[   39.094874] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1280) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[   39.120025] batman_adv: bat0: Interface activated: mesh-vpn
[   42.986173] random: nonblocking pool is initialized
[51434.084308] 
[51434.084308] do_page_fault(): sending SIGSEGV to dhcpv6.script for invalid read access from 00000000
[51434.093777] epc = 0041efe9 in busybox[400000+4b000]
[51434.098874] ra  = 0041efb1 in busybox[400000+4b000]
[51434.103950] 
[246873.087138] 
[246873.087138] do_page_fault(): sending SIGSEGV to dhcpv6.script for invalid read access from 00000000
[246873.096706] epc = 0041efe9 in busybox[400000+4b000]
[246873.101871] ra  = 0041efb1 in busybox[400000+4b000]
[246873.107035] 
[474616.886748] 
[474616.886748] do_page_fault(): sending SIGSEGV to dhcpv6.script for invalid read access from 00000000
[474616.896275] epc = 0041efe9 in busybox[400000+4b000]
[474616.901475] ra  = 0041efb1 in busybox[400000+4b000]
[474616.906612] 
[603906.185327] 
[603906.185327] do_page_fault(): sending SIGSEGV to dhcpv6.script for invalid read access from 00000000
[603906.194907] epc = 0041efe9 in busybox[400000+4b000]
[603906.200124] ra  = 0041efb1 in busybox[400000+4b000]
[603906.205276]

Bei logread kam leider nix sinnvolles raus.

Hat das schonmal jemand gesehen? Ich habe Telekom mit Dual Stack, und IPv6 für den Uplink auf dem Knoten auch nicht deaktiviert.

20

Ist scheinbar bekannt.

https://bugs.lede-project.org/index.php?do=details&task_id=822

1 „Gefällt mir“