<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hallo zusammen,<br>
<br>
liege ich da mit meiner Vermutung richtig, dass Knoten in
unterschiedlichen Domains nicht airborne miteinander meshen? Z.B.:<br>
<br>
<table class="attributes">
<tbody>
<tr>
<th>Node ID</th>
<td>647002b4059d</td>
</tr>
<tr>
<th>Firmware</th>
<td>1.10.0~rc1 / gluon-v2020.2.2</td>
</tr>
<tr>
<th>Domain</th>
<td>Saarpfalz-Kreis</td>
</tr>
</tbody>
</table>
<br>
mit<br>
<br>
<table class="attributes">
<tbody>
<tr>
<th>Node ID</th>
<td>14cc209ce688</td>
</tr>
<tr>
<th>Firmware</th>
<td>1.10.0~rc1 / gluon-v2020.2.2</td>
</tr>
<tr>
<th>Domain</th>
<td>Sonstige</td>
</tr>
</tbody>
</table>
<br>
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.<br>
<br>
Viele Grüße,<br>
<br>
Christoph Ackermann<br>
<br>
<br>
<div class="moz-cite-prefix">Am 18.12.20 um 11:38 schrieb Ralf Jung
via freifunk-public:<br>
</div>
<blockquote type="cite"
cite="mid:5332ca52-1b16-74d1-fc24-bef1a674dfeb@ralfj.de">
<br>
Hallo allerseits,
<br>
<br>
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.
<br>
<br>
Im Vergleich zur letzten stable-Version ergeben sich die folgenden
Änderungen:
<br>
- Neue Hardware-Unterstützung: TP-Link CPE210 3.20.
<br>
- Integration der Infrastruktur für die automatische Umstellung
der Knoten
<br>
auf andere Domains.
<br>
<br>
Mehr zum zweiten Punkt:
<br>
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.
<br>
<br>
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.]
<br>
Ob für einen Knoten ein Wechsel geplant ist, kannst du per SSH
herausfinden:
<br>
uci get ffda.director.target
<br>
uci get ffda.director.switch_after
<br>
<br>
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.
<br>
<br>
Vielen Dank an alle Tester! Wenn dir mit dieser Beta-Version
irgendwas auffällt, gib bitte Bescheid.
<br>
<br>
Viele Grüße,
<br>
Ralf
<br>
</blockquote>
<br>
</body>
</html>