Hallo! Vorsicht: Antwort in Romanlänge ;-)
Am 2016-04-22 um 19:04 schrieb Mike B. Kerber:
On 2016-04-22 18:06, Matthias Šubik wrote:On 22.04.2016, at 17:59, Mike B. Kerber <[email protected]> wrote: On 2016-04-19 12:00, [email protected] wrote:Date: Mon, 18 Apr 2016 16:06:23 +0200 From: Matthias Šubik <[email protected]>...[...]Das wäre in der Tat super. Ich würde mal vorschlagen bei knoten mit Master-Client layout auf jenen clients die multi SSID können einfach einen AP zu machen, dass man sie scannen kann. ich vermute ich könnte so manchen möglichen partner sehen, wenn der ein SSID ausstrahlen würde. Das wäre es natürlich super, wenn es dazu eine convention gäbe wie noolsr-client.node.funkfeuer.at oder so, damit man weiss das das kein MESH ist und wo zzt kein olsr (aufgrund von technischen details) läuft.Das ist ja machbar, aber warum glaubst Du dass dann dort kein olsrd läuft? Im Standardfall läuft der ja auf allen Interfaces, d.h. wenn ein AP eine zweite SSID ausstrahlt, kann da problemlos auch olsrd laufen.Ja aber dann brauchen alle diese interfaces eine ip, bei ipv4 ist das ein bissi verschwenderisch wenn das nach bedarf geht. Ipv6 olsr kann man aber anmachen gibts ja mehr IPs ;)
Man müsste folgende Konzept einmal im Detail nachbauen: https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf Deren Mobile Adhoc Network im Infrastruktur-Modus, besteht aus: * RONs (ROuter Nodes), die sowohl als Station als auch als AP arbeiten und somit das Mesh bilden, * STANs (Station Nodes), also reine Clients eines AP, zum Beispiel Smartphones.RONs sollen untereinander ein MANET mit Hilfe eines nicht näher bezeichneten Routingprotokolls bilden - das kann auch OLSR sein. Auf den AP-Interfaces der RONs soll je ein DHCP-Server oder DHCP-Relay laufen, um lokale Clients, also STANs zu bedienen. Zudem sollen sie als DNS-Resolver gegenüber den STANs laufen. Nach diesem Konzept sollen RONs die Gateways für die STANs sein, vorzugsweise mit eigenen IP-Assignments. STANs sollen demnach vom komplexen Routing dahinter nichts wissen müssen.
Die Arbeit geht von APs und STAs auf virtuellen Interfaces, beispielsweise durch ath9k implementiert, aus.
Weiters thematisiert sie die Mobilität von sowohl STANs als auch RONs:Um mobilitätsbedingten Routingproblemen (Layer 2 und Layer 3) und Zeitverzögerungen durch ARP im Falle eines Handover eines STANs auf einen anderen RON zu begegnen, lassen Wirtz et. al. jeden RON dasselbe Netzwerk bereitstellen. D.h. die APs strahlen dieselbe SSID aus, sind auf dieselbe IP konfiguriert und nutzen dieselbe (Fake-) MAC-Adresse ("/MAC address of the gateway interface a STAN communicates with./") Die BSSID wird allerdings einzigartig gehalten ("/keep the MAC address of the wireless interface of the RON unique/"). Dies dient der Vermeidung von DUPs (doppelt übermittelte Pakete von benachbarten RONs).
Problematisch ist in diesem Konzept die (Retour-)Route hin zu den STANs.Auf die Mobilität von RONs wird insoweit eingegangen, als sie zwar vorgesehen ist, jedoch wegen Änderungen der Netzwerktopologie davon abgeraten wird, sie großzügig zu nutzen. D.h. RONs würden, wie auch bisher bei uns, einzigartige ESSIDs nutzen.
Wenden wir das Konzept theoretisch auf Knoten bei uns im Netz an und denken das durch:Wenn wir jetzt einen Master-AP auf einem node starten, und der heisst FunkFeuer.at Hotspot, dann erwartet man sich da natürlich DHCP+NATv4.was eben da drauf läuft sollte man erkennen, wenn ich node.funkfeuer sehe erwarte ich keinen hotspot ;)
Dann haben wir:Root-Nodes, die nur als AP fungieren und via Tunnel angebunden sind - auf ihnen läuft ein AP-Interface und OLSR (z.B.: Krypta, Brenner) RONs, die als Station an einem Root-Node angebunden sind und auf demselben Kanal einen AP anbieten - zB etwa ein wo9 an brenner RONs, die als Station an einem anderen RON angebunden sind und auf demselben Kanal einen AP anbieten - zB etwa kr3 an wo9.
STAN: der Laptop von Sven am RON kr3.Nach dem Konzept von Wirtz et. al. würden die Root-Nodes und die RONs je einen DHCP-Server oder ein Relay betreiben. Da unser Netz mit statischen, öffentlichen IPs und Prefixes arbeitet, sollte das kein Problem sein - DHCP mit einem internen Range würde die STANs bedienen. Die anderen RONs haben ja statische IPs, womit es kein Problem gibt. Sofern NAT auf den RONs läuft, müsste es sich auf die internen IP-Ranges (RFC1918), sofern APIPA genutzt wird, auf RFC 3927 beschränken, damit OLSR-Pakete und geroutete Pakete nicht genattet werden.
Wichtig ist, in diesem Konzept, dass die RONs ja eine idente MAC-Adresse und IP verwenden. Damit RONs an RONs über OLSR routen, müssen diese Interfaces auch OLSR sprechen. Dazu müsste eine einzige (offizielle) Adresse mehrfach (per Anycast) angekündigt werden. Habe ich hier einen Denkfehler eingebaut? Wenn nicht, ist OLSR wie immer pro Interface (sonstige Interfacekonfiguration ohne Bridge-Support und mit AP-Isolation) zu konfigurieren. Der Spareffekt ist so ganz ohne Bridging auch gegeben.
Im Ergebnis solle es - organisatorischen Aufwand zur Verhinderung von Missbrauch in der Art, dass RONs mit internen, oder doppelt vergebenen internen IPs einsickern - möglich sein, mit nur einem AP also nur einer ESSID beide Dienste zu betreiben. Ich sehe das aber selbst noch kritisch und würde eine Variante mit Portal Auth bevorzugen.
Man muss sich auch bewusst sein, dass die Mitbenutzung eines Kanals altbekannte Airtime-Probleme insbesondere mit RTS/CTS und CTS-Flooding bewirken kann. Man sollte auch bedenken, dass man sich mit den STANs und mobile STANs etwaige Hidden Station Probleme importiert.
Das Konzept ergibt mangels rechtskonformer Multi-SSID-fähiger Firmware auch nur auf 2.4-GHz Nodes mit OpenWRT Sinn. Auf 5 GHz löst es jedenfalls keine Probleme - insbesondere bei langen RON-RON-Ketten und DFS/TPC würde ein Kanalwechsel mit jeweils auf demselben Kanal operierenden Routerketten einen Kaskadeneffekt mit entsprechenden, womöglich wellenartig auftretenden Performanceproblemen auslösen.
Besteht ein RON allerdings aus "abgesetzen Radios", wie in vorangegangenen Diskussionen besprochen, spricht auch hier nichts dagegen.
Ein Vorteil dieses Setups könnte eine Auto-Config sein, da ein RON vor Erhalt seiner Konfiguration und noch bevor OLSR läuft, bereits am Netz teilnehmen kann. Im Falle eines DHCP-Relays (SPoF?) kann eine im Portal hinterlegte MAC-Adresse auch per DHCP zugewiesen werden.
Bitte um Eure Anmerkungen zu den Überlegungen! Ich habe ziemlich sicher etwas übersehen.
Im Wlan-Frame ist die MAC-Adresse (Layer 2) des pseudo-gebridgten Interfaces nicht vorhanden, es sei denn, man nützt WDS, weil dabei die Mac-Adresse des Senders (Ethernet), bei von dort stammenden Paketen, in den WLAN-Frame als Absender eingebaut wird. WDS muss aber auf beiden Seiten unterstützt werden, damit es wirklich klappt [Access Point (WDS) und Client (WDS)]; darauf hast Du nicht immer Einfluss...Wenn Du zeit hättest, und Multi-SSID testen könntest, wäre super. Ich probier auch mal Multi-SSID+WPA2Enterprise/Free nebeneinander.Auf meinen Knoten läuft eben ein AP parallel zum client. Um ips zu sparen haben ich versucht die interfaces zu bridgen, das geht in openwrt mal nicht direkt, mit relayd wird der Knoten im olsr umgangen aber es geht.
https://wiki.openwrt.org/doc/howto/clientmode#bridgedclientmodeissues
Das ist alles "WIP", nur ohne Progress, weil ich nicht mehr dazu gekommen bin, nachdem ich mich mit dem WRT54G/GL-mit-0xFF-FW-kann-nicht-mit-Atheros-AP-assoziieren-Problem sinnlos aufgehalten habe.Schöner wäre es pro Gerät eine IP zu haben und die interfaces zusammen zu bringen. Es gibt dazu mails im Archiv mit Erich (Siehe Next gen. node).
Bei einem grösseren Knoten mit einem backbine router könnte man die Interfaces jedes geräts auf den backbone router durch bridgen und nur dort läuft dann mit einer OLSRD originator IP ein olsr. die einzelnen
Sie oben.
geräte müssten dann halt über portforwards oder sowas angesprochen werden (zb zum remote configgern).
Nicht zwangsläufig.
In welcher Hinsicht? Beim "abgesetzten Radio" stellt sich die Frage nicht, und Remote Configuration and Information ist in gewisser Weise Basis dieser Netzkultur. Portforwards für sich allein genommen, sind SbO und der vermittelnde Router ist SPoF. Oder?Daraus könnte man sogar einen kleinen sicherheitgewinn erzielen ;)
bG Matthiasmlg -mike [...]
LG Erich
<<attachment: erich.vcf>>
-- Wien mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/wien
