[Discuss] alternatives NAT Package fuer die freifunkfirmware

Henning Rogge (spam-protected)
Mi Feb 4 19:43:52 CET 2009


On Mittwoch 04 Februar 2009 09:00:54 you wrote:
> Schon, aber worauf ich hinaus wollte ist dass man das RFC auch so
> lesen könnte: Die nicht-funk interfaces nehmen ja nicht am MANET
> teil (weil am Kabel gibt's ja keine mobility) also gelten die
> Einschränkungen des RFC nicht, obwohl das interface natürlich
> trotzdem vom olsrd verwaltet wird.
Wir fahren Hellos/TCs über die Kabel, also sind es OLSR-Interfaces.

> Das RFC hat Interoperabilität als Ziel, aber nachdem die Kabel ja
> sowieso fix sind, würd' es schon auch Sinn machen Kabelinterfaces
> als "matter of local policy" ohne Beschränkungen stehen zu lassen.
Nunja, gut ist die Sache immer noch nicht... aber sie wäre vielleicht 
praktikabel während wir auf IPv6 warten...

> Aber das ist natürlich uninteressante Haarspalterei, ich wollt nur
> anmerken, dass das RFC (vermutlich bewusst) sehr abstrakt und
> allgemein geschrieben ist und es bei der Implementation eigentlich
> so viel wie möglich offen lässt. - Ist zumindest mein Eindruck
> nach dem Vortrag vom Thomas Clausen.
In diesem Punkt ist der RFC recht direkt. Das was ich zitiert habe ist eine 
der "Definitionen" bevor die Erklärung von OLSR anfängt.

> Ja, mit so einem Setup hätte man dann sozusagen link local IPv4 Adressen
> erfunden - eigentlich müsste man in diesem Fall die privaten Interface
> IPs nicht einmal mit MID Messages announcen, aber das ist dann wirklich
> nicht mehr RFC konform ... ;)
Jein, je nach Metrik kann es unterschiede machen über welche Interfaces das 
Paket rausgeht, daher ist es sinnvoll das die global irgendwie adressierbar 
sind.

> > > Kennst du da irgendein Gegenbeispiel an das ich nicht gedacht habe?
> >
> > Wie schon in einer anderen Mail erwähnt habe verbaut uns das einige
> > Sachen in Hinsicht der Linkmetriken die ich momentan teste.
>
> Hm, das klingt interessant. Allerdings hab' ich dieses Mail anscheinend
> nicht gekriegt ... Link ins Archiv?
Ich schreibe momentan an einer "Linklayer-Database", mit der wir Werte wie 
Signalstärke und Bandbreite den Nachbarn zuordnen können und dann passende LQ-
Plugins schreiben können.

Die Zuordnung MAC/IP sollte dafür eindeutig sein.
Zum Glück braucht man für ausgewiesene Ethernet-Devices keinen LQ-
Algorithmus... die sind entweder an oder aus.

> > > a) $lieblingswebsite vergisst mich, wenn sich meine IP ändert
> >
> > Wieso sollte sich deine IP ändern wenn du öffentliche IPs hast ?
>
> Weil, wenn es in der Route nicht explizit überschrieben wird, dann
> wird die Interface-IP als src IP verwendet.
>
> > > b) Übersichtlichkeit, wenn DNS wieder nicht erreichbar ist und ich
> > >   debuggen muss - die IP vom Tunnelserver kenn' ich auswendig, aber
> > >   wenn der 40 IPs hat, dann werd' ich mir die nicht alle merken.
> >
> > Du braucht die Main-IP des Tunnelservers, mehr sollte dich erstmal
> > nicht interessieren.
>
> Na aber solang mir traceroute, ping -R, etc Interface-IPs ausspucken,
> seh ich die Main-IP halt einfach gar nicht. Eben Linuxrouting nicht
>OLSR Routing, das hier am Werk ist.
Ach so meinst du das.

> > Andererseits könnte man bei wichtigen Servern vielleicht ein
> > modifiziertes Nameservice-Plugin einsetzen was alle Interfaces in der
> > Form
> >
> > vpn0.<name der OLSR Node>
> > eth0.<name der OLSR Node>
> >
> > jeweils in die DNS-Tabelle einfügt.
> >
> > Wäre beim Debuggen eines solchen Servers bestimmt nützlich.
>
> Hm, das Nameservice-Plugin verwenden wir gar nicht (zurecht, es ist
> IMHO eine mühsame Krücke), aber in solchen Fällen würd's natürlich
> ein bisschen helfen.
Ja, ein besseres System für nen verteilten DNS wäre auch nicht übel.
Lust eines zu schreiben ? ;)

> Ja, die meisten anderen Probleme, die wir oben diskutiert haben, werden
> sich mit IPv6 auch lösen (link local Adressen, etc).
>
> Das Problem ist halt auch, dass sich hier in Wien eine Menge Leute
> gegen das "eine öffentliche IP pro Standort" gestellt haben.
Kannst du mir erklären wie die Argumente waren ?

> > Solltest du auf den Wechsel der Main-IP anspielen (wenn das 1.
> > Interface des OLSR down geht), das kann im TIP einfach dadurch gelöst
> > werden das du deine Router-ID (und nichts anderes ist die Main-IP)
> > einfach im Config-File angibst.
>
> Nein, ich hab' das hier gemeint:
> http://lists.olsr.org/pipermail/olsr-dev/2008-December/002729.html
Siehe meine Antwort auf diese Mail (ist die 3. Mail des Threads)... die Mail 
war wenn ich das richtig im Kopf habe der Auftakt für eine ganze Reihe von 
Stresstests, Bugfixes und Rewrites im Routing-System.

Solche Hacks sind klasse dazu Fehler im Code zu verdeutlichen und klar zu 
machen in welche Richtung die Lösung gehen muss... wobei oft dadurch erst klar 
wird das man hier die Spitze des Eisbergs sieht. ;)

Henning

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20090204/c9afcc1f/attachment.sig>


Mehr Informationen über die Mailingliste Discuss