fe80::1 vermeiden

So Nov 18 21:56:16 CET 2018

Hallo zusammen,

wir haben gelegentlich Probleme, wenn ein Gerät in einer Hood die Adresse fe80::1 benutzt, weil dann die Mesh-Knoten unter dieser Adresse das Gateway nicht mehr erreichen können. Das kann dann mehr oder minder eklig werden.

In Retrospektive war es wohl nicht so klug, hier ausgerechnet diese Adresse zu wählen.

Wir haben heute hierzu zwei Ideen entwickelt:

Idee 1: Man könnte die Adresse ändern:

- Man denkt sich eine andere Adresse aus, z.B. fe80::fff:1

- Alle V2-Gateways hängen die Adresse ZUSÄTZLICH mit nodad an ihre Interfaces, so wie jetzt die fe80::1

- Wenn von allen GWs diesbezüglich Rückmeldung erfolgt ist, tauscht man per Patch die Adresse in der Firmware aus

Ab dem darauf folgenden Release wird dann die Zahl der Router, die fe80::1 verwenden, immer kleiner. Das Problem ist zwar nie ganz weg, aber die Wahrscheinlichkeit des Auftretens wird zunehmend reduziert.

Das System wird nicht geändert. Den Gatewaybetreibern tut die Sache überhaupt nicht weh, es klebt halt eine Adresse mehr dran. Die Änderung ist einfach und schnell.

Man muss zwar ALLE GW-Betreiber erreichen, das sollte sich bei V2 aber noch relativ realistisch erreichen lassen. Im allerschlimmsten Fall (jemand hat es vergessen zu machen) muss jemand nachträglich noch den einen Befehl ergänzen.

Die größte Frage hier wäre die Wahl der IPv6 Adresse: Ich persönlich tendiere zu einer einfachen Adresse (fe80::fff:1), die aber eben nicht erste, zweite oder letzte Adresse im Adressraum ist.

Man könnte natürlich auch etwas mit random generieren, allerdings halte ich das für übertrieben. Dadurch schaffen wir nur wieder Raum für Übertragungsfehler (und ähnliches), während die Kollisionswahrscheinlichkeit zwar reduziert wird, aber nur geringfügig.

Zudem muss darauf geachtet werden, dass man keine Adresse zufällig generiert, die aus einer MAC-Adresse entstehen kann. (Wäre alles aber natürlich machbar)

Idee 2: Man gibt dem KeyXchange eine fd43-Adresse:

Anstelle einer anderen fe80::-Adresse könnte man auch den KeyXchange ins Netz bringen und dann dessen fd43-Adresse anstatt der fe80 hinterlegen (geht das wirklich so einfach?).

Die Router erhalten nach wie vor ihr initiales Hoodfile von der üblichen Quelle (wXsta, Network), aber das „zweite“ dann nicht mehr vom Gateway, sondern vom KeyXchange.

Vorteile:

- Die Gateways kopieren ohnehin nur das Hoodfile, es muss aber identisch zum KeyXchange sein; diese Fehlerquelle fällt weg

- Wir sparen uns den ganzen Umweg über die Gateways und fragen direkt bei der Quelle an; den ganzen Spaß mit dem Hoodfile auf dem Gateway samt Download werden wir komplett los

Nachteile:

- Größere „Umstellung“ mit mehr möglichen Randfällen (verglichen mit Idee 1; insgesamt immer noch überschaubar)

- Macht ein GW das ULA-Routing nicht/falsch, geht was kaputt

- Ist am Router die fd43-Adresse nicht richtig konfiguriert (machen wir per configurehood-Skript), dann kein Hoodfile mehr (eigtl. ist das aber ein Vorteil, weil dann konfiguriert sich das Gerät dadurch neu und repariert sich).

In beiden Fällen geht es mir darum, die fe80::1 loszuwerden, ohne das ganze System um- oder neu zu bauen! Bitte also jetzt nicht noch drei andere Vorschläge, wie man noch mal alles umbauen kann.

Ich stelle mir das als relativ gering-invasiven Eingriff vor, der ja zudem immer noch mit der alten Lösung koexistieren muss (und mit den genannten Lösungen auch einfach kann.)

Bitte um Feedback bzw. ggf. alternative Vorschläge zur Wahl der fe80-Adresse. Zustimmung für bestimmte Varianten ist natürlich auch gerne gesehen.

Beste Grüße

Adrian
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20181118/15f67a7d/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20181118/15f67a7d/attachment.sig>