mit der Version “0.7.4~118_wrz / gluon-gt-ef15c21” habe ich mit einigen Geräten und der manuellen Aktualisierung mit sysupgrade Probleme. Entweder sie kommen danach nicht mehr online (WR841N V.10) oder “hängen sich ab” (gerade aktuell: http://map.4830.org/mueritz/#!v:m;n:e894f6781ac8).
Im letzten Fall reicht Strom aus/an erstmal aus … bis zum nächten mal.
Ein V.10-Gerät ließ sich mit Configmodus und [Weiter] + [Speichern und Neustart] zum Arbeiten bewegen … an die anderen kann ich nachher ran.
Manuell deswegen, weil über ipv6 zurzeit keine “Mirrors” erreichbar sind.
Wo könnte der Wurm drin sein?
Sind das nur v10er, die vorher 0.7.5~29 drauf hatten?
Da es beim Autoupdater klappt und bislang die Meldungen von Problemen mit manuellem Upgrade sich auf die 841 fokussieren, vermute ich, daß es da im RAM knapp wird und der Reboot nicht mehr sauber klappt. Wobei »sysupgrade« ja auch einige Prozesse killt vor dem Flash; aber es läuft ja noch die SSH-Session, als Unterschied zum Autoupdate-Prozeß.
Wichtig ist in erster Linie IMHO, daß beim automatischen Update alles glatt geht. Ich kann »mtr« wieder rauswerfen aus dem Image, sodaß das kleiner wird; anfangs klappte es IIRC ja auch und »mtr« nahm ich nur rein, um IPv6 besser debuggen zu können.
Was v6 angeht muß ich gucken, wer wieder wo die Route verloren hat
der Knoten bei der Feuerwehr sogar mit partiellen Update … neue Teile von 0.7.4~118 und Anzeige von 0.7.5~29
8) … falls das richtig ist --> ff_offline_60e327c79f28
Da’s Euch weniger betrifft (SSID-Change im Kreis GT), bitte mal manuelles Updating stoppen. Backe nacher eine neue FW ohne mtr, dann mit der probieren. Wenn Kuddelmuddel entsteht - was dann wohl Grund für nicht wiederkommende Knoten nach sysupgrade -, ist was massiv karpott
Witzig, meine MR3020 zickten nicht, die sind ähnlich mau ausgestattet wie 841.
Sorry for the hassle; werde nachher eig. v10 probieren.
Neuer Firmwarebuild (experimental: 0.7.5~6) steht bereit, bitte zum manuellen Aktualisieren von 0.7.5~29-841v10-Knoten diesen Build probieren — »mtr« ist nicht mehr mit an Bord, damit das Image insgesamt etwas kleiner/der freie Speicher etwas größer.
EDIT: Okay, also hier hat das mit manuellem »Downgrade« von 0.7.5~29 auf 0.7.5~6 gerade problemlos funktioniert:
Fragt sich halt, wie das Verhältnis normalerweise ist, sprich: hattet Ihr 100% Ausfälle bei manuellem Upgrade eines 841v10 von 0.7.5~29 weg?
Danke, jetzt geht’s wieder ohne Aufregung und Herzflattern … ob der Knoten das Update überlebt hat.
Bei einem von 8 aktualisierten 841v10er-Knoten gab keine Probleme.
Den 9. hatte ich mit Schalter -n selbst ins Nirvana geschickt. Keine Ahnung wo meine Gedanken da waren.
Zu früh gefreut … heute noch ein 841V.10-Gerät mit 0.7.5~6 manuell versenkt.
Strom aus/an brachte leider nix.
Kannst Du das Build größer als 0.7.5~29 setzen? Die aktuelle Nummerierung (0.7.5~6) ist für eine automatischen Aktualisierung zu klein. Ich gehe für das Update auch gerne von stable zeitweise zu experimentell.
Zu früh gefreut … heute noch ein 841V.10-Gerät mit 0.7.5~6 manuell versenkt.
Strom aus/an brachte leider nix.
Hrmpft. Wenn ich nur wüßte, woran’s liegt …
Kannst Du das Build größer als 0.7.5~29 setzen? Die aktuelle Nummerierung (0.7.5~6) ist für eine automatischen Aktualisierung zu klein. Ich gehe für das Update auch gerne von stable zeitweise zu experimentell.
Grobe Richtung kommendes Wochenende ist 0.7.5-0 (-0 ist größer ~xxx) geplant, laß’ die laufenden Knoten auf bis dahin 0.7.5~29, oder brennt was?
Ab 0.7.5~11 sind einige Feature-Backports von Freifunk Celle mit drin, u. a. Uplink per WLAN statt Kabel, außerdem wird man bestimmte »Profile« wählen können (in der Art »gut-ap-ml-ch1« für einen AP auf Kanal 1 mit Mesh-on-LAN in Gütersloh, wo wir normal auf Kanal 9 sind) — damit können größere Standorte sinnvoller konfiguriert werden und das ganze bleibt updatefest.
Technisch machbar wäre es, 0.7.5~6 als 0.7.5~30 neu zu bauen, kost’ ca. 30 Minuten für den geänderten Jenkins-Job und baut ca. 3h — wie groß ist Dein Druck an der Stelle, sprich: lohnt das den Aufwand?
Nein, es ist nicht so dringend.
Ich finde das “ff_offline_xxx”-Feature genial für Bereiche, die lahm angebunden sind, öfters sich abhängen … deswegen wollte ich diese Firmware dort schneller einsetzen. So bekomme ich jetzt von dort schneller Rückmeldung, wenn “Freifunk” mal nicht geht.
Danke für Deinen Einsatz … muss ich mal so ohne Einschränkungen sagen.
Writing from to firmware …
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware…TRX header not found
Error fixing up TRX header
Upgrade completed
Rebooting system…
… was mich nun aber stutzig macht, ist die das automatische Einschalten von Mesh-VPN.
Das war bei diesem Gerät definitiv aus und m.E. auch im Config-Modus nicht [X] gemarkert, da dies kein LAN sehen sollte.
Bug oder Feature?
VPN status
IPv4 not configured
IPv6 not configured
fastd running for 297.971 seconds
There are 6 peers configured, of which 0 are connected:
mesh_vpn_backbone_peer_gw06: not connected
mesh_vpn_backbone_peer_gw04: not connected
mesh_vpn_backbone_peer_gw03: not connected
mesh_vpn_backbone_peer_gw02: not connected
mesh_vpn_backbone_peer_gw01: not connected
mesh_vpn_backbone_peer_gw05: not connected
Das war bei diesem Gerät definitiv aus und m.E. auch im Config-Modus nicht [X] gemarkert, da dies kein LAN sehen sollte.
Bug. Wobei ich nicht wüßte, warum das erst jetzt auftreten sollte. Sicher, daß das nicht schon immer so war? Lies: hast Du v9er-Knoten mit der Einstellung betrieben und da blieb das erhalten?
BTW, ich nutze einen v10 als Testobjekt und hatte mit der aktuellen (also auf dem älteren OpenWRT basierenden) Firmware keinen einzigen Hänger beim manuellen sysupgrade. Nur der erste Flash ging gründlich in die Hose, von 0.7.5~29 auf die 0.7.4-mit-v10 — da habe ich das erste Mal tftp zur wiederbeleben benutzt …
Flashen des 841er mit 0.7.4~68 im Config-Modus ohne Übernahme alter Daten
’Mesh over VPN’ deaktiviert
’autoupdate’ eingeschaltet
VPN status
IPv4 configured
IPv6 not configured
fastd not running
automatisches update nach reboot auf 0.7.4~118 (stable)
VPN status
IPv4 configured
IPv6 not configured
fastd not running
ssh: Umstellung auf experimental
ssh: Aufruf von ‘autoupdater’ —> 0.7.5~72
VPN status
IPv4 configured via br-wan
IPv6 not configured
fastd running for 177.770 seconds
There are 6 peers configured, of which 1 are connected:
mesh_vpn_backbone_peer_gw06: connected for 117.790 seconds
mesh_vpn_backbone_peer_gw04: not connected
mesh_vpn_backbone_peer_gw03: not connected
mesh_vpn_backbone_peer_gw02: not connected
mesh_vpn_backbone_peer_gw01: not connected
mesh_vpn_backbone_peer_gw05: not connected
Yepp. Ich löschte /etc/config/fastd und baute es neu, da durch eine Racecondition zwar die site.conf geändert wurde, aber die fastd-Konfiguration die alte (die aus der site.conf im Image) blieb. Dummerweise wurde Mesh-VPN ja/nein dort gespeichert …
Ich habe das Pferd jetzt vom Kopf her aufgezäumt, die Routinen, die mit site.conf arbeiten, sind nun ›»site-select«-aware‹, heißt, die initiale Racecondition müßte vom Tisch sein. Bringt einige Vereinfachungen mit sich dieser Ansatz, jetzt muß das nur noch bauen … (Der Gluon-Bauprozeß versucht zu verifizieren, ob die site.conf gültiger Lua-Code ist; mit der Routine im Image (gut), leider mit einem abgespeckten Lua auf dem Build-Host (ganz schlecht).)
