[freifunk-public] Neue Beta-Firmware 1.10.0~rc1

[Ralf Jung]

Hallo Christoph,

ja, das ist richtig und wichtig. Der ganze Grund, warum wir Domänen einführen, 
ist dass unser Mesh zu groß ist und wir es in mehrere getrennte Meshes (genannt 
"Domänen") aufteilen wollen.

Die Knoten sollten auch per Mesh-on-LAN/WAN nicht miteinander meshen, wenn sie 
in verschiedenen Domänen sind. Wenn sie es doch tun, haben wir ein Problem, weil 
dieser eine Link dann die beides eigentlich getrennten Domänen zu einem Mesh 
macht.^^

Viele Grüße,
Ralf

On 25.12.20 13:04, Christoph Ackermann via freifunk-public wrote:
> Hallo zusammen,
> 
> liege ich da mit meiner Vermutung richtig, dass Knoten in unterschiedlichen 
> Domains nicht airborne miteinander meshen? Z.B.:
> 
> Node ID 	647002b4059d
> Firmware 	1.10.0~rc1 / gluon-v2020.2.2
> Domain 	Saarpfalz-Kreis
> 
> 
> mit
> 
> Node ID 	14cc209ce688
> Firmware 	1.10.0~rc1 / gluon-v2020.2.2
> Domain 	Sonstige
> 
> 
> obwohl beide aktuell 1m auseinander liegen. Der Zweite war eine Zeit lang aus 
> und hat wohl die Zuordnung zur Saarpfalz Domäne (noch) nicht mitbekommen. 
> Testweise ist der auch noch per Ethernet angebunden.
> 
> Viele Grüße,
> 
> Christoph Ackermann
> 
> 
> Am 18.12.20 um 11:38 schrieb Ralf Jung via freifunk-public:
>>
>> Hallo allerseits,
>>
>> wir rollen jetzt im Beta-Kanal des Autoupdaters die neue Firmware 1.10.0~rc1 
>> aus. Diese ist quasi dieselbe wie die letzte experimental-Firmware, bis auf 
>> ein Gluon-Update auf Version v2020.2.2.
>>
>> Im Vergleich zur letzten stable-Version ergeben sich die folgenden Änderungen:
>> - Neue Hardware-Unterstützung:  TP-Link CPE210 3.20.
>> - Integration der Infrastruktur für die automatische Umstellung der Knoten
>>   auf andere Domains.
>>
>> Mehr zum zweiten Punkt:
>> Wir haben eine angepasste Version des Darmstädter "Domain Director" eingebaut, 
>> mit dem wir die vorhandenen Knoten automatisch auf unsere neuen Domains 
>> verteilen und so die Größe des Mesh-Netzwerks reduzieren wollen. Wir werden 
>> dabei aufpassen, dass lokale Mesh-Wolken geschlossen in dieselbe Domain 
>> migrieren. Wer darauf nicht vertrauen mag, kann den Director in den 
>> erweiterten Einstellungen im Konfig-Modus deaktivieren; in diesem Fall würden 
>> wir gerne mit dir zusammenarbeitet, um deinen Knoten und das Mesh, in dem er 
>> hängt, unbeschadet in die richtige Domain zu bekommen.
>>
>> Technisch läuft das so, dass wir auf dem mgmt-Server eine kleine Datenbank 
>> haben, wo für jeden Knoten anhand der angegebenen Geokoordinaten bzw den 
>> benachbarten Mesh-Knoten eine Ziel-Domain eingestellt ist. Die Knoten fragen 
>> regelmäßig (alle drei Stunden) beim Server nach, was denn ihre Ziel-Domain 
>> ist, und wenn diese von der gesetzten Domain abweicht wird ein Wechsel 
>> geplant. Der Zeitpunkt des Wechsels wird dabei vom Server festgelegt. So 
>> können wir z.B. den Wechsel für 1.1.2021 ankündigen; es würde dann also 
>> reichen, wenn ein Knoten in den nächsten 2 Wochen irgendwann mal für mehr als 
>> drei Stunden online ist, damit er weiß, wann und wohin der Wechsel 
>> stattfindet. [Das ist nur ein Beispiel, bisher ist noch kein Datum gesetzt.]
>> Ob für einen Knoten ein Wechsel geplant ist, kannst du per SSH herausfinden:
>> uci get ffda.director.target
>> uci get ffda.director.switch_after
>>
>> Die Tests bisher sind sehr erfolgreich verlaufen, bis auf eine Konstellation 
>> mit lokalen Anpassungen an der Konfiguration. Wir werden daher versuche, 
>> Knoten mit deaktiviertem Autoupdater nicht automatisch zu migrieren. Die 
>> Details dazu, und wie wir verhindern dass so nur ein Teil eines Meshes 
>> migriert wird, sind noch nicht fertig ausgearbeitet -- aber da diese Logik 
>> serverseitig arbeitet, können wir sie recht einfach anpassen.
>>
>> Vielen Dank an alle Tester! Wenn dir mit dieser Beta-Version irgendwas 
>> auffällt, gib bitte Bescheid.
>>
>> Viele Grüße,
>> Ralf
> 
>