[Berlin-wireless] FF-DHCP und 2 Router

[Alexander Morlang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuel Munz schrieb:
> Fabian Schonack wrote:
>> Hier gestalltet sich folgendes Szenario:
> 
>> Es gibt den Hauptrouter A mit DHCP (zB IP x.x.x.1 - x.x.x.6) einen Router B 
>> ohne DHCP.  Beide selbe (B)SSID. Nun kommt der unbedarft User und moechte 
>> sich mit dem freifunk verbinden. Mit Glueck bekommt er am anfang vom Router A 
>> eine IP zugewiesen. Kurz darauf dreht der Wind er verliert die Verbindung zu 
>> A und verbindet sich nun lieber zu B. Bekommt natuerlich keine IP und bekommt 
>> schlechte Laune..."instabiles Freifunk etc".
> 
> Der Client verbindet doch nicht zu einem einzelnen Router sondern im
> adhoc zur Mesh Wolke. Die DHCP-Requests kommen demnach bei allen Routern
> in Funkreichweite an, und wer DHCP anbietet antwortet dem Client. Von
> daher denke ich das Problem mit dem Client ist was anderes, schlechte
> Funkverbindung zum Router mit DHCP evtl.?
> 

das problem ist, das der client keine informationen darüber hat, mit
welcher signalstärke die antworten der verschiedenen dhcpserver
angekommen sind, so das er, wenn er einfach den ersten, nicht den
besten nimmt.

so hatten wir schonmal darüber nachgedacht, das mit heftigstem gefrickel
zu lösen, getan hat es letztendlich dann doch niemnd.

gedanke:
jeder client bekommt nicht nur eine eigene ipadresse, er bekommt auch
ein eigenes defaultgateway. Diese adresse wohnt dann auf dem
node(master), der die adresse vergeben hat als alias interface.
dieser announced die ipadresse des clients auch per hna.

der homenode erzählt seinen nachbarn, der er nen clienten hat.
er und seine nachbarn fangen an, ihn per layer-2 zu pingen, um eine
metrik zu bilden.

Ändern sich die metriken, so das einer der nachbar eine bessere
verbindung zu dem client hat, muss eine roamingevent folgen:

hna announcement auf den new master aktivieren.
defaultgateway ipadresse als alias auf das interface des neuen master legen

old master muss alias und hna löschen.

new master muss mit gratious arp den client über seine neue mac adresse
aufklären.

erste offenlichtliche probleme:
dynamisches hna an- und abkündigen.
nicht jeder spielt bei gratious arp mit.
hnapropagation ist recht langsam, es ist unklar, wie lange der client in
der roamingphase disconnected ist.
vieles mehr, was mir grad nicht auffällt.

diese ideen sind mal in stark verrauchter atmosphäre entstanden und ich
hab versucht, sie direkt nach dem wachwerden aufzuschreiben.

wenn da irgendwas dran ist und wer das diskutieren will, möge er es
bitte auf eine wikiseite kopieren, so das wir das während der diskussion
 updaten will.



> Grüße
> soma

gruss, Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkIPmkACgkQhx2RbV7T5aGe+QCfUxgKhY/6C5N2+DisndHApkbr
f58AmgNETw8lweYRe6zb7GVdRaBnCRxY
=tu+b
-----END PGP SIGNATURE-----