Neue Firmware stable-3.0.2 im Testbetrieb

Basis: Gluon v2018.2
der Branch basiert jetzt wieder auf

  • openwrt und bringt ein
  • Linux-Kernel 4.9.146

Patches

  • Support für CPE210V3
  • GL-MIFI (minimal-image bauen, zusätzliche Kernel-Module und Pakete mit opkg manuell nachinstallieren vom Update-Server)

Testbetrieb in der Domain Lohmar:

Version 3.0.1 mit gluon-mesh-batman-adv: use getifaddrs #1616 und opkg repo-urls openwrt

respondd liefert jetzt die korrekten IPs ohne Doubletten

Danke für dein Feedback imzum Issue.

Ich warte noch darauf, dass der Build komplett durch ist - für die betroffenen Nodes mit IP-doppel in der Liste brauche ich ar71xx-tiny images - danach weiss ich erst, ob der umgestellte respondd den Fehler dort auch abstellt, wo er aufgetreten ist.

@hexa :

vorher:

nachher:

In der Domain Lohmar ca. 10% der Nodes beim Autoupdate von lede basierter 2.10.0 (gluon v2018.1.x) auf openwrt basierter 3.0.0 ‚verloren‘. Das Backup von der config wurde nicht zurückgespielt, sondern die betroffenen Router stehen mit der neuen Firmware im Wartungsmodus mit default config der Community.
Bei manuellem Upgrade per ssh mit wget und sysupgrade gab es dagegen keine Probleme.

Habe heute unser Netz von 200 Knoten von 2017.1.8 auf 2018.2 gebracht. Keine Verluste.

3 „Gefällt mir“

auf welcher Gluon version basierte das genau?
Bitte den exakten Commit-Hash nennen oder verlinken.

@rotanid : bei Soziale Netze stable-2.10.0 / gluon-v2018.1-1-g098ca81d
Da ich alle Domains hintereinander weg baue, betrifft das auch die FW der Lohmar nodes mit config-Alzheimer.

1 „Gefällt mir“

This was a known-issue until v2018.1.1 (#1496) and was fixed only after v2018.1-10-g0cb98882.

  • Configuration loss on upgrade under certain circumstances (#1496)The issue can only occur when upgrading from 2018.1 and there are multiple mirror entries in site.conf (specifically, an early failure for one of the mirrors, e.g. during DNS resolution, followed by a successful upgrade from a different mirror triggers the issue). This is a regression in Gluon 2018.1.

Your configuration loss is therefore a result of the previously installed firmware, not the one after the upgrade.

3 „Gefällt mir“

Das ist eine wichtige Nachricht. Es lag also wohl nicht an Gluon v2018.2, sondern an der älteren Version gluon-v2018.1-1-g098ca81d, von welcher aus aktualisiert wurde.

EDIT:
Gemeint ist eine ältere Version als Gluon v2018.1-10-g0cb98882, und das aber nur in Kombination mit mehreren Mirror-Update-Pathes.

OT:
Hier in Frankfurt haben wir erstmalig ein Upgrade ohne Verluste durchgeführt. Dieses Upgrade wurde von Gluon v2018.1.3 auf Gluon v2018.2 realisiert. Sonst hatten wir immer so ca. 1-2% temporäre Verluste.

Erklärt vielleicht auch warum wir hier in Leverkusen auch keine Verluste hatten. Wir kamen direkt von 2017.1.8. Eine Version auf Basis von 2018.1 gab es bei uns nie.

1 „Gefällt mir“

openwrt hat wohl mit 200 reduce size patch das blocking von Mesh-Verbindungen über rsk-paket blockmesh unmöglich gemacht - auf iw-full umgestellt in stable-3.0.2

mit iw-full wieder volles feature-set:
root@firmwaretest_openwrt_cpe210v3:~# iw --help | grep ‚station set‘
dev station set mesh_power_mode <active|light|deep>
dev station set vlan
dev station set plink_action <open|block>


TP-Link CPE210 v3.0 und rssileds laufen.

gestern in Troisdorf zur Versorgung einer Unterkunft einen CPE210 v3.0 aus reiner Notwehr als Ersatzrouter verbaut - mal schauen, ob der stabiler läuft als sein v1.1-Vorgänger.

Über die Richtfunkstrecke wird der zweite Teil einer Einrichtung versorgt .