[wlanfhain] Re: OpenWRT, OLSR und NAT

[Juergen Neumann]

-----BEGIN PGP SIGNED MESSAGE-----

Ahoi!

Jens schreibt:

> > > Was allerdings richtig ist ist das wenn das jeder so macht es im OLSR
> > > Netz bald ein ziemliches chaos geben wird. Deswegen würde ich dir
> > > empfehlen einen nicht ganz so häufig verwendeten 192.168.x.x
> > > Netzbereich
> > > zu wählen, d.h. nicht 192.168.1.0  sondern vieleicht
> > > 192.168.23.0 und im
> > > ~ Wiki einzutragen daß du diesen bereich für dein Nezt zu hause
> > > beanspruchst.
> >
> > Das kann auf keinen Fall die Lösung sein. Wenn wir jetzt anfangen,
> > noch 192.168.x.x Netze im WLAN zu routen, dann funktioniert bald
> > garnix mehr!!!
>
> Wenn wir anfangen *beliebig* 192.168.x.x ins olsr-netz zu
> routen, dann
> führt das in der Tat wohl in der Tat wohl in Chaos (obwohl ich nicht
> ganz die Aufregung erstehe, schliesslich können Mehrfach-IP-Vergaben
> genauso übers Wiki eingesehen werden -- sprich es ist nicht
> besser oder
> schlechter als das jetzige vorgehen).

Ich  habe aber bisher ins Wiki keine der von mir verwendeten Privaten
IP-Adressräume geschrieben und die Liste wäre wirklich etwas lang ;-)!
Konflikte sind vorprogrammiert (192.168.1.x) und umkonfigurieren wir
massive Arbeit.

> > Wir sollten uns ganz unbedingt auf das 172.16.x.x Netz
> > beschränken unddas erst mal voll machen. Wenn wir wirklich alle IP's
> > verbraucht haben, geht esmit 1172.17.x.x weiter usw.
> >
> > Für die angesprochene Problematik (über die Bruno und ich auch schon
> > intensiv nachgedacht haben) gibt es unseres Erachtens nach nur die
> > Lösung des Port-Forwardings.
>
> Das wiederum kann aus meiner Sicht nicht die Lösung sein. Wir alle
> ärgern uns über die NAT-Beschränkungen des Internets, und
> jetzt führen
> wir ebensolche »Lösung« in unser Netz ein.

ok.

> Warum die IP-Adressen nicht geographisch verteilen. Kreuzberg kriegt
> 172.17.x.x, Fhain 172.16.x.x usw. Kreuzberg verteilt dann wiederum
> diesen Bereich unter sich, z.B. kriegt die Manteuffel 172.17.1.x und
> mein Haus kriegt 172.17.2.x. usw.  172.17.1bzw2.x würden in Kreuzberg
> über HNA4 sichtbar. Das ist überhaupt kein Problem, bzw. das Problem
> ist genauso groß wie bei der Host-IP-Vergabe auf olsr.freifunk.net --
> alles eine Sache der Absprache, und wenn diese Absprachen in
> Kieze/Bezirke runtergebrochen werden, ist es leichter. Die Fhainer
> müssen dann nur ein 172.17.0.0/16 in der Routingtabelle stehen haben
> für alle Kreuzberger.

Wäre für mich eine Lösung, wenn wir versuchen, es auf etwas weniger
großzügige Adressräume zu beschränken.
U.a verwenden wir die 172.16.99.x, 172.16.9.x beispielsweise bereits privat
- - klar, lässt sich alles ändern, ist aber wie gesagt eine Menge Arbeit.

Darüber hinaus git es noch die Netze, die im AP-Modus angeboten werden.
Auch dafür müssen wir eine Vereinbarung finden.

>    Da kommt dann aus meiner Sicht auch das BerlinBackBone ins
> Spiel. Das
> könnte der Backbone Berlins sein -- sprich er verbindet die einzelnen
> OLSR-Meshwolken der Kieze. Auf dem Backbone könnte dann ein reines
> HNA4-olsr laufen, dass nur die Kieznetze announced, oder wem das zu
> experimentell ist der nehme OSPF (gibt es für OpenWrt)
> (http://lartc.org/howto/lartc.dynamic-routing.html)
>
> Ich möchte folgendes vorschlagen:
> Wir setzen uns am 27.10., Mi 20 Uhr zusammen und besprechen
> genau diese
> Thematik. Bis dahin wird es auch noch auf der Basis des Host-Routings
> funktionieren, und es bleibt Zeit die einzelnen Pro/Contras vorweg
> unter die Lupe zu nehmen.
>
> Der 27. ist auch noch ein bisschen Zeit, so dass es im Terminkalender
> vorgemerkt werden kann.

Guter Vorschlag. Es scheint, dass uns die Realität langsam einholt und wir
nun endlich eine verbindliche Lösung für die IP-Adressen und Routing
brauchen. Wir sollten  m.E. schon OLSR für das Routing nehmen, zumindest
überall dort, wo es für eine Lösung nutzbar ist. Intressant war ja auch die
Mail von cven mit der automatischen IP-Nummern Konfiguration.

LG

JuergeN

PS: Ich rege mich überigens gar nicht auf, ich sehe nur Probleme auf uns zu
kommen, die wir dringend verhindern sollten.


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQEVAwUBQWEcet3z6c5eZCFlAQHDYgf6AgneSXXZbW+vDsbLbxIvNgDKqU9GexND
dvUqnC63/k56x/p795VKM8L9mMDv2/v8cuGsPZPN3OB0liHJKySQyzi13b9vFIjn
++2or4hvnVQE5UX4XLM3lL2AzJO8ivuRGvIeH1FOgaU0Y67l1gjg44BvVfJ6e7Dn
S+lMPzjimF2fTGMG+xuMiy0tCPtHgikyvrwKSzSNSEnWGly8WnL12rtkmJ0Vc0G8
QrgDELCAFLwODj4LSsXoGZSh0c2a0jTZpMubGC8XA7870AvkgXwMI+4RlWrkLrwy
mE/B2yDYWR7XhFEDQXuXpUc3rRoYHcGMMKSF2eq6g9/KY4wuoRUwXw==
=qmXB
-----END PGP SIGNATURE-----

---
[scanned]
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 13.09.2004