[Wien] Frage bzgl relayd

Sa Nov 7 23:43:01 CET 2015

Hallo!

Am 2015-11-07 um 18:17 schrieb Mike B. Kerber:
> Hallo!
>
> Ich habe mal als test um IP adressen zu sparen folgendes probiert, um
> über einen client 0xff node weiter das netz zu verbreiten:

Das ist eine an sich nette Idee, ist aber meiner Ansicht nach nicht 
zielführend, weil
a) Du damit auf dem selben Kanal als Master funkst (repeater). 
Zweitrouter + anderer Kanal bevorzugt.
b) http://wiki.openwrt.org/doc/recipes/relayclient - Pseudobridge... du 
damit, wenn ich es richtig verstehe letztlich einen Master baust, der 
ohne AP Isolation arbeitet, was die Funktionsweise von OLSR konterkariert.

Möglich, dass das Folgende -aus meiner Müdigkeit entspringende- völliger 
Blödsinn ist, und vielleicht übersehe ich etwas an Deinem Konzept, aber 
das könnten wir ohne relayd billiger und effektiver haben - man 
korrigiere mich diesfalls bitte:

Master mit RFC1918 oder APIPA-Adresse + OLSR Originator IP setzen + 
Client mit offizieller Adresse (=originator IP) + OLSR wie immer.
Die private Adresse würde dann meines Wissens nicht mittels TC 
weitergegeben, sondern nur der Originator. In der lokalen Routingtabelle 
könnte es anders aussehen. Clients ohne OLSR könnten den Master mehr 
oder weniger mitbenutzen, solange in der Firewall Vorsorge getroffen 
wird, dass offizielle IPs nicht genattet werden. Autoconfig müsste zudem 
dann klappen. Auf einem daran hängenden Client+OLSR, dessen IP eine 
offizielle ist, die als Orginator fungiert, würde die Routingtabelle 
ebenso aussehen, etc.

Hat jemand sowas in einem Testnetz bereits versucht? Am laufenden Netz 
würde ich das nicht testen wollen. Schon gar nicht in der Nähe vom Brenner
> a) router 'panel' als 0xff node via client mode verbunden zu einem
> master (in dem Fall der brenner)
ack.
> b) auf dem router 'panel' einen zweiten master SSID eingerichtet, gemäß wiki
Dieses Konzept hat ebenso wie ein Repeater und auch Adhoc-Mode 
Performance-Einbußen, skaliert aber etwas besser. Grundsätzlich: Ack, 
besser ist immer ein zweiter Router auf einem anderem Kanal.
> c) zwischen den beiden openwrt devices client und master relayd
> zwischengeschaltet.
OpenWRT Devices? Nicht Interfaces?
Du meinst ja die jeweiligen Schnittstellen von panel, die sich dann eine 
IP teilen sollen, oder?
> d) anderen router 'subclient' genommen und statt auch direkt auf brenner
> zu gehen, mit router 'panel' via dessen master verbinden.
Logisch.
>
> das ganze klappt recht gut, nur wird der router 'panel' vom 'subclient'
> ignoriert. dh der 'subclient' olsr sieht gleich den brenner ABER der
> pfad geht brav über 'panel'
Ohne Routingtabelle sage ich dazu nichts...
Was sagt die OLSR-Tabelle am subrouter und panel?

Panel:

Wir sehen nur ein Interface pro IP. Ob das an olsr selbst oder dem 
json-plugin liegt, weiß ich nicht. Markus?

Für mich schaut das eher so aus: Für OLSR ist diese Pseudobridge wie 
eine Bridge -> erratisch.
Client an Master(Bridge) mit AP Isolation sieht nur den Master und 
routet nur zu ihm.
Client an Master(Bridge) mit AP Isolation und Pseudobridge routet über 
ihn zu den Nachbarn am anderen Interface oder halt anders, je nachdem 
was gerade besser aussieht.
> tracepath portal.funkfeuer.at
>   1?: [LOCALHOST]                                         pmtu 1280
>   1:  panel.brambie.wien.funkfeuer.at                      48.557ms
>   1:  panel.brambiE.wien.funkfeuer.at                      15.894ms
>   2:  westm.brenner.wien.funkfeuer.at                     133.572ms
>   3:  brenner-link.tunnel.wien.funkfeuer.at                54.311ms
>   4:  subway.funkfeuer.at                                  44.214ms
>
> sonst geht alles. Sieht halt komisch aus weil man so die echte topologie
> nicht sieht.
Ungut zu debuggen, nicht wahr?
>
> Fragen:
> 1) macht das probleme/ist das unerwünscht?
Ergibt es einen Sinn?
> 2)  kann man das ohne relay machen, mit statischen routen? (ich denke
> mal nicht ohne eine weiter 0xff ip zu verwenden damit man iptables
> targets hat)un
Siehe oben. Die private IP des Masters könnte übrigens netzweit stets 
dieselbe sein - so bliebe die Route beim Wechsel auf einen anderen 
Router mit derselben ESSID (wie am Brenner und OZW üblich, später 
eventuell Mesh-weit) zumindest in einer Richtung stets unverändert. (Nur 
die ARP-Adresse ändert sich, nicht der Routingeintrag selbst). Solange 
keine Bridge im Spiel ist, was bei OLSR unnötig ist, gibt es kein 
Problem auf der Kollisionsdomäne;

Diese Idee entstammt dem Paper Wirtz, Chants, das ich vor Jahren auf der 
Wiki verlinkt hatte.
> 3) kann man im relayd was drehen (hat wer eine ahnung mit dem teil? -
> ich hab den source noch nicht angeschaut, in der openwrt config geht
> nicht viel zum drehen)
Keine Ahnung. Für mich ergibt das mit dem aktuellen OLSRd so keinen Sinn.
Eher würde ich eine Lösung auf Basis eines IPv6-Transport-Meshs mit 
tayga oder sonst mit IPv4-Inseln (getunnelt, verkapselt) favorisieren - 
das wir Dual-Stack-OLSR mit einer Mangelware (IPv4) fahren, kommt mir 
eher unlogisch vor.
Besser auf Zukunftstechnologien setzen, als das Rad neu zu erfinden...
>
> mlg
> -mike
>
>
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien

LG
Erich

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20151107/ccbad4c8/attachment.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : dfjeeicj.png
Dateityp    : image/png
Dateigröße  : 11132 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.funkfeuer.at/pipermail/wien/attachments/20151107/ccbad4c8/attachment.png>