[Wien] DNS Einträge ich bin wenigstens in der map!

[Bernd Petrovitsch]

On Die, 2007-12-18 at 23:58 +0100, Markus Gschwendt wrote:
> On Thu, 2007-12-13 at 12:07 +0100, Bernd Petrovitsch wrote:
[...]
> > 1) sollte ohne großartigen technischen Aufwand auskommen können, weil
> > man den Leuten ja sagen wird wollen, wo was falsch ist. Der Zustand wird
> > auch nur temporär sein. Daher das "erkennen und überleben".
> 
> hier geht's eher ums 'erkennen' z.b. dass die ip anderweitig online bzw.

Das ist mbMn (relativ) einfach:
a) eine per definitionem eindeutige und persistente "Node-Id"
   definieren. Kann im Prinzip die MAC-Adresse sein oder der Output von
   `uuidgen` oder `ssh-keygen` oder sonstwas.
   Über die *alle* Anforderungen (was soll gehen was soll nicht gehen)
   an diese Node-Id muß man sich halt klar sein, dann kann man was
   passendes designen.
   Z.B.
   - muß eindeutig sein (na no na net)
   - muß persistent sein (damit es immer dieselbe ist). Z.B. in eine
     File oder NVRAM o.ä. speichern.
   - sollte auf allen verbreiteten/supporteten OSs und Hardwaern erzeugt
     werden können (mir hilft keine HostID, die es nur auf Sun-Hardware
     gibt, oder ein Serial Number Chip, den es auf PCs nicht gibt).
   - soll übersiedelt werden können (damit ich die Hardware meines Nodes
     austauschen kann, wenn z.B. mein LinkSys kaputt ist. Das schließt
     z.B. MAC-Adresse aus. Ja, die kann man nach dem Booten ändern.
     Nein, ich bin kein Fan davon, weil das eine subtile Fehlerquelle
     mehr ist. Chello-Kunden mögen damit vertraut sein, aber sonst?).
   - soll automatisch erzeugt werden können (damit sie der olsrd
     automatisch erzeugen kann, wenn es noch keine gibt)
   - muß eine fixe Größe haben (a la MD5 oder SHA1 Hash o.ä. von
     irgendeinem eindeutigen Input), damit die Implementierung nicht
     unnötig kompliziert ist.
   - sollte so klein wie möglich sein, damit der Overhead nicht unnötig
     steigt.
   Sonst noch was?
b) Das auf (spam-protected) o.ä. diskutieren und "beschließen".
   Hilft ja nichts, wenn man was sozial nicht akzeptiertes
   implementiert.
c) Das im OLSR Protokoll sinnvoll unterbringen.
   Schließlich sollen die anderen Knoten erfahren, welche Message von
   welchem Node mit welcher IP-Adresse ist.
d) Sich überlegen, wie man mit (alten) Nodes ohne Node-Id umgeht.
   Kann man halt nichts checken ...
e) Sich überlegen, wo und wie man die lokale Robustness herbekommt. Was
   weiß ich, keine Routen zum und über Knoten eintragen und/oder
   announcen, die eine doppelte IP-Adresse haben.
   Reicht das?
f) Implementieren, testen, verwenden.

Ich seh' da wenig Notwendigkeit, mit harter Security, Zertifikaten, etc.
reinzugehen.

> vergeben ist. erst durch performance-/routingprobleme draufkommen zu
> müssen ist nicht optimal. zumindest eine warnmeldung beim booten bzw. im

Yup. Ob man das beim Booten schon weiß, ist eine andere Sache. Aber
wenigstens Logmeldungen und robusteres Verhalten (in der eigenen
Umgebung) wär' gut. BTW liest ja u.U. der, der die falsche IP-Adresse
verwendet, ja auch dieselben Logmeldungen.

> webif, dass die ip bereits anderswo online ist wär schön. (wer seinen
> router rebootet schaut meist anschliessend ins webif ob nachbarn
> gefunden wurden)

Naja, ob meine IP-Adresse die richtige oder falsche ist, kann ich am
Gerät nicht trivial unterscheiden.
Aber das wäre ja schon nach "erkennen" und geht in Richtung "beheben".

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services