Neue Firmware Experimental 1.1.0

Technik Gluon
1

Experimental 1.1.0

Diese Firmware enthält das finale Release der Gluon Version 2017.1.2.
Ausserdem wird hiermit die MTU von vormalig 1280 Bytes auf 1312 Bytes angehoben. Der Grund kann hier nachgelesen werden.

Dies erfordert dass nach und nach alle Gateways umgestellt werden.

Die Firmware wird voraussichtlich am 12.09.2017 per Autoupdate sowie auf unserer Firmwareseite verfügbar sein.

Wer sich zutraut die Firmware im aktuellen Zustand, mit nur einem verfügbaren Gateway, zu testen kann das Update über folgenden Befehl per SSH durchführen.

autoupdater http://fw.ffrn.de/experimental.110/sysupgrade
1 „Gefällt mir“
2

Hat bei mir irgendwie nicht funktioniert:

root@Bensheim-002:~# autoupdater http://fw.ffrn.de/experimental.110/sysupgrade
Downloading 'http://fw.ffrn.de/experimental.110/sysupgrade/experimental.manifest'
Connecting to 2a01:4f8:10a:f225::6:80
Writing to stdout
-                    100% |*******************************| 65012   0:00:00 ETA
Download completed (65012 bytes)
New version available.
Stopping cron...
Stopping haveged...
Stopping micrond...
Stopping sysntpd...
Stopping gluon-radvd...
Stopping uhttpd...                                                                                                
Stopping sse-multiplexd...                                                                                        
Stopping alfred...                                                                                                                                                                                                                    
sed: /etc/crontabs/root: No such file or directory                                                                                                                                                                                    
Command failed: Not found                                                                                                                                                                                                             
Stopping gluon-respondd...                                                                                                                                                                                                            
vm.drop_caches = 3                                                                                                                                                                                                                    
Downloading 'http://fw.ffrn.de/experimental.110/sysupgrade/gluon-ffrn-1.1.0-20170829-tp-link-tl-wr842n-nd-v3-sysupgrade.bin'                                                                                                          
Connecting to 2a01:4f8:10a:f225::6:80                                                                                                                                                                                                 
Writing to '/tmp/lua_cLCBIh'                                                                                                                                                                                                          
/tmp/lua_cLCBIh      100% |*******************************|  4416k  0:00:00 ETA                                                                                                                                                       
Download completed (4521988 bytes)                                                                                                                                                                                                    
Stopping network...                                                                                                                                                                                                                   
packet_write_wait: Connection to 2a01:4f8:171:fcff:ee08:6bff:fe56:b784 port 22: Broken pipe

Anschließend lief aber wieder die alte Firmware:

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

Habe ich was falsch gemacht?

Soll ich es einfach nochmal versuchen?

[EDIT]: Habe es einfach nochmal gemacht, identischer Konsole-Output, aber jetzt ist die 1.1.0 drauf. Keine Ahnung, was da passiert ist.

3

Das kann, je nach aktueller Firmware Version häufiger oder seltener, auftreten. Einfach nochmals probieren hilft in der Regel.

4

Firmware läuft auf meinem Offloader und 842er aktuell ohne Probleme.

1 „Gefällt mir“
5

Danke für die bisherigen Tests. Um den Kreis zu erweitern werde ich die Firmware morgen, am 12.09., schon per Autoupdater ausrollen.

6

Irgendwas läuft bei mir nicht rund mit der Firmware. Manchmal kann ich meine Knoten anpingen, manchmal nicht. Manchmal komme ich per SSH drauf, dann wieder nicht. Manchmal wenn ich eingeloggt bin, hängt die SSH-Session, und nach Minuten geht es weiter.

Sieht für mich nach den klassischen Symptomen eines MTU Problems aus…

Beide Knoten verhalten sich ähnliche:
bensheim-002-offloader.nodes.ffrn.de
bensheim-002.nodes.ffrn.de

Hier mal ein paar Pings:
https://paste.ffrn.de/?e759ff22610dbbec#imSZhBaIHocvdhq0htfBqiT0lnsWw1CGOvWPNPIg4Pg=

Wurden direkt intereinander ausgeführt, mal Packet Loss, mal normale Antworten, mal Address Unreachable.

7

Wer mehr über den Grund der 1312er MTU lesen will: https://github.com/freifunk-gluon/gluon/pull/1210

1 „Gefällt mir“
8

Updates sind bei mir automatisch und problemlos gelaufen. Bin gespannt ob es jetzt insgesammt auch besser mit der Stabilität ist.

9

Bisher (2 Tage) ist keiner meiner Knoten hängen geblieben … das ist erfreulich. Es gab einmal einen Knoten, der für ein paar Stunden keine Verbindung hatte, der hat sich aber wieder gefunden. Ein kleiner hat einmal neu gestartet. Das ist aber nicht so ungewöhnlich.

Also bisher bin ich sehr zufrieden. So gut lief es seit längerem bei mir nicht. Teilweise musste ich mehrmals am Tag Stecker ziehen.

10

Das Knoten hängen oder abstürzen hatte ich jetzt eigenlich auch nicht, aber irgendwie habe ich immer wieder total schlechte Surf-Performance. Einen Fehler hat @NurticVibe neulich schon gefixt, aber ich habe das Gefühl, da ist noch mehr kaputt.

Eben konnte ich praktisch nicht im Freifunk Netz arbeiten, DNS-Anfragen an 10.142.53.4 haben teilweise 15 Sekunden gedauert. Ich habe das mal mit Wireshark mitgeloggt. Ich konnte das auf der Konsole auch eine Zeit lang reproduzieren, aber jetzt scheint wieder alles ok zu sein.

[Edit] Problem ist wieder da, aber scheinbar kein Fehler in der Firmware, daher habe ich einen neuen Thread aufgemacht: DNS Problem 10.142.53.4

11

Also das WIFI-Problem besteht weiter …
Ich bin immer noch nicht dazu gekommen die Seriellen Adapter anzulöten … muss ich endlich machen.

Ich hab zum Test den Offloader weggemacht und einen meiner 1043 direkt als Uplink angeschlossen. Das Ergebnis ist das gleiche:

Der Knoten hängt im Netz und ist über seine IPV6 erreichbar. Er macht auch Mesh-LAN für einen anderen Knoten, der weiter erreichbar ist. Aber das WLAN und WLAN-Mesh reagiert dann nicht mehr.

Ein einfaches “wifi” auf der Konsole behebt das Problem. Sekunden danach mesht er wieder und ist auch bereit Clients anzunehmen.

Nach dem Upgrade auf die 1.1.0 hat es zwei, fast drei Tage funktioniert. Jetzt hängt er sich wieder 1-2 Mal am Tag ab.

12

Ich habe ein Mesh-Netz aus 3 Knoten (841N) daheim, nur einer davon ist ein Uplink. Es lief alles stabil, bis ich einen der Knoten auf experimental geflashed habe. Seit dem steigt der Uplink regelmäßig aus und muss neu gestartet werden, obwohl die Last als Clients gering ist. Da der Stable-Knoten und nicht der Experimental aussteigt, ist das eher ein Problem von Stable und in meinen Augen unkritisch. Durch den Autoupdater sollten alle Knoten es Meshs auch zeitnah die 1.1.0 bekommen und das Problem sollte nicht gravierend sein. Wollte es trotzdem mal berichten und davor warnen aktuell »gemischte« Meshs zu bauen. Und die WR841N einzusetzen! ;)

13

Habe gestern die beiden anderen Knoten auch auf Experimental aktualisiert, stürzt immer noch ab. Die Warnung bezüglich gemischter Meshs dürfte daher hinfällig sein. Ich werde morgen mal eine Serielle Schnittstelle an den Uplink basteln und schauen, was da passiert

14

Wie heißen die Knoten?

Auch ich habe manchmal seltsame Phänomene, die ich aber selten gut zuordnen kann. Die 841er sind ja benkanntermaßen instabil, und da ich teilweise Wired-Mesh benutze, bin ich vielleicht auch davon betroffen:

(Achtung: der zitierte 842N V2 hat auch nur 32MB RAM - nicht mit den aktuelleren 842 verwechseln!)

15

Der Knoten Am-Neckardamm-002 ist der crashende Uplink.

16

Der mit Uplink hat eine deutlich höhere Speicherauslastung… Hast Du IPv4 und IPv6 am Uplink? Ggf. mal IPv6 deaktivieren? Als “Mini-Offloader” setze ich die 841er mittlerweile gar nicht mehr ein, nur als “Endgeräte” (also entweder isolierter Knoten mit eigenem Uplink oder als Knoten, der per Mesh on LAN/WAN versorgt wird).

Uplink + Mesh on LAN + Client LAN/WLAN ist vielleicht einfach zu viel :-(

Der Autoupdater braucht dann auch noch regelmäßig Speicher - vielleicht den erstmal deaktivieren.

17

Nein, kein IPv6 aktuell. Ich plane eh den Uplink durch eine VM zu ersetzen, dauert aber noch etwas

18

Ich habe mittlerweile vier 841’er auf die neue Firmware 1.1.0-20170829 aktualisiert.

Hierzu habe ich einfach folgendes ausgeführt:

uci set autoupdater.settings.branch=experimental
autoupdater -f

(Den Trick, nicht uci commit autoupdater zu schreiben, damit die Knoten nach dem reboot nur automatische Updates zur nächsten Stable tun werden, habe ich natürlich erst beim letzten Knoten herausgefunden ; )

Die Hardware-Revisionen der 841er sind v7, v10 und v11.

Bei einem hat der Reboot sehr lange gedauert (ich hatte schon gedacht, ich muss den Power Cycle durchführen, vor dem mich @Cheatha gewarnt hat), aber sie kamen alle wieder aus eigener Kraft hoch.

Alle meine manuellen Sonder-Konfigurationen (hierzu folgt ein anderer Thread) sind auch erhalten geblieben, bis auf den Funkkanal. @NurticVibe ist es Absicht oder ein Bug, dass ein geänderter Funkkanal auf ‘6’ zurückgestellt wird?

Ansonsten kann ich nur das Feedback geben, dass IPv6-Verbindungen signifikant besser laufen als vorher – es scheint, dass die VPN-MTU-Änderungen greifen. Allerdings hat es hierfür gereicht, den (VM-)Offloader zu aktualisieren, die Nicht-Selbst-VPN-Verbindungs-Herstellenden-Clients konnten die Pakete auch mit der alten Firmware problemlos weiterleiten bzw. zustellen.

Nochmal einen großen Dank für das sehr virtualisierungs-freundliche amd64 image, welches wunderbar mit der VirtIO-Netzwerkkarte klarkommt.

19

Preserve Channels gesetzt und auch das commit nicht vergessen?

  • WLAN Kanal Änderungen können jetzt mit uci set gluon-core.@wireless[0].preserve_channels=1; uci commit über Updates hinaus festgelegt werden

Bzw:

20

@tobox Danke! Den habe ich tatsächlich überlesen. Werde nach dem nächsten Update berichten, ob er greift.