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.
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?!
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.
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.
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.
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.