<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2015-11-07 um 18:17 schrieb Mike B. Kerber:<br>
</div>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">Hallo!
Ich habe mal als test um IP adressen zu sparen folgendes probiert, um
über einen client 0xff node weiter das netz zu verbreiten:</pre>
</blockquote>
<br>
Das ist eine an sich nette Idee, ist aber meiner Ansicht nach nicht
zielführend, weil<br>
a) Du damit auf dem selben Kanal als Master funkst (repeater).
Zweitrouter + anderer Kanal bevorzugt.<br>
b) <a class="moz-txt-link-freetext" href="http://wiki.openwrt.org/doc/recipes/relayclient">http://wiki.openwrt.org/doc/recipes/relayclient</a> - Pseudobridge...
du damit, wenn ich es richtig verstehe letztlich einen Master baust,
der ohne AP Isolation arbeitet, was die Funktionsweise von OLSR
konterkariert.<br>
<br>
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:<br>
<br>
Master mit RFC1918 oder APIPA-Adresse + OLSR Originator IP setzen +
Client mit offizieller Adresse (=originator IP) + OLSR wie immer.<br>
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. <br>
<br>
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<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
a) router 'panel' als 0xff node via client mode verbunden zu einem
master (in dem Fall der brenner)</pre>
</blockquote>
ack.<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
b) auf dem router 'panel' einen zweiten master SSID eingerichtet, gemäß wiki</pre>
</blockquote>
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.<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
c) zwischen den beiden openwrt devices client und master relayd
zwischengeschaltet.</pre>
</blockquote>
OpenWRT Devices? Nicht Interfaces?<br>
Du meinst ja die jeweiligen Schnittstellen von panel, die sich dann
eine IP teilen sollen, oder?<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
d) anderen router 'subclient' genommen und statt auch direkt auf brenner
zu gehen, mit router 'panel' via dessen master verbinden.</pre>
</blockquote>
Logisch.<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
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'</pre>
</blockquote>
Ohne Routingtabelle sage ich dazu nichts...<br>
Was sagt die OLSR-Tabelle am subrouter und panel?<br>
<br>
Panel:<br>
<img src="cid:part1.00090700.00030809@pekarek.at" alt=""><br>
Wir sehen nur ein Interface pro IP. Ob das an olsr selbst oder dem
json-plugin liegt, weiß ich nicht. Markus?<br>
<br>
<br>
Für mich schaut das eher so aus: Für OLSR ist diese Pseudobridge wie
eine Bridge -> erratisch.<br>
Client an Master(Bridge) mit AP Isolation sieht nur den Master und
routet nur zu ihm.<br>
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.<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
Ungut zu debuggen, nicht wahr?<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
Fragen:
1) macht das probleme/ist das unerwünscht?</pre>
</blockquote>
Ergibt es einen Sinn?<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
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</pre>
</blockquote>
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;<br>
<br>
Diese Idee entstammt dem Paper Wirtz, Chants, das ich vor Jahren auf
der Wiki verlinkt hatte.<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
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)</pre>
</blockquote>
Keine Ahnung. Für mich ergibt das mit dem aktuellen OLSRd so keinen
Sinn.<br>
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.<br>
Besser auf Zukunftstechnologien setzen, als das Rad neu zu
erfinden...<br>
<blockquote cite="mid:563E3247.2060602@univie.ac.at" type="cite">
<pre wrap="">
mlg
-mike
--
Wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wien@lists.funkfeuer.at">Wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/wien">https://lists.funkfeuer.at/mailman/listinfo/wien</a></pre>
</blockquote>
<br>
LG<br>
Erich<br>
<br>
</body>
</html>