== Vorwort ==

Der Artikel "Next Generation Nodes" erörtert Konzepte für die Funkfeuer-Mesh-Nodes von Morgen.
Er dient zur Sammlung von Ideen, aus denen ein zukunftssicheres und performantes Netz hervorgehen soll.

''Next Generation Nodes'' sind dadurch charakterisiert, dass sie:
* sparsam im Umgang mit IPv4-Adressen sind.
* als IPv4/IPv6 relay fungieren oder
* dual-stack unterstützen.
* OLSRv2 oder andere Routingprotokolle nützen.
* anstelle des Adhoc-Mode einen kombinierten AP/Station-Mode verwenden, wie er von [http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf Wirtz, Chants et al., "Establishing Mobile Ad-Hoc Networks in 802.11 Infrastructure Mode"] beschrieben wird.
* optional als Hotspot funktionieren können.
* optional auto-provisioning beherrschen.
* optional auto-updating beherrschen, um Nodes immer im gewählten branch, z.B. "HEAD", "current", "bugfix only" zu betreiben.

== Spezifikationen ==
=== Hardware ===
Jeder Router, der in der Lage ist, gleichzeitig an mehreren Netzen teilzunehmen, sei es durch
* Bereitstellung dedizierter Schnittstellen oder
* Unterstützung von virtuellen Drahtlosschnittstellen (VAP) in der Kombination: mindestens ein Access Point und mindestens eine Station.

=== Software ===
Als Betriebssystem kann -wie bisher- OpenWRT verwendet werden, aber theoretisch auch jede andere Distribution, die
* OLSRv2 zur Verfügung stellt.
* Routinen bereitstellt, um einerseits die Funktionalität
** eines Access Points (AP), andererseits
** einer Station (STA) bereitzustellen.

Eine beispielhafte Softwareausstattung umfasst:
# OpenWRT
## Kernel: kmod-ipv6, kmod-ipip, kmod-gre; kmod-iptables etc.
# OLSRv2 ''[https://ietf.org/doc/draft-ietf-manet-olsrv2/?include_text=1]''
# WLAN-bezogen:
## hostapd/wpad (nach Möglichkeit mit Unterstützung für WPA/WPA2)
## Unterstützung für Radius/WPA(2) Enterprise, 802.1X (im Falle des Aufbaus eines zentralen Hotspot-Portals)
# Tayga ''[http://www.litech.org/tayga/]'', ''[http://de.wikipedia.org/wiki/NAT64]'', ''[http://wiki.openwrt.org/doc/howto/ipv6]''
# DNS64 ''[http://de.wikipedia.org/wiki/DNS64#DNS64]''

=== IPv6 ===
Hard- und Software soll in der Lage sein, IPv6 sinnvoll einzusetzen.
Durch Tayga [s.o.] können IPv4 fähige Knoten angebunden werden.
* Bitte ergänzen, wie konkret das aussehen kann
* Wie funktioniert das Zusammenspiel: OLSR,OLSR-NG in dieser Situation; HNA-Ankündigung? Tunnel? Separate OLSR-Inseln?

Für erste Testläufe genügen link-lokale IPv6 Subnetze.
In weiterer Folge wird es erforderlich sein, für die Verwendung von NAT64 geeignete Mappings im vorläufigen IPv6-Vergabekonzept zu definieren und allenfalls ein Präfix (/96) hierfür entweder im 0xFF-Präfix 2a02:60:/29 zu definieren und die einzelnen 1:1 Mappings über HNA anzukündigen oder dies site-lokal innerhalb der zugewiesenen Adressblöcke vorzunehmen oder beides zusammen - je nach Funktionalitätserfordernissen.

=== OLSRv2 ===
Bei OLSRv2 ''[https://ietf.org/doc/draft-ietf-manet-olsrv2/?include_text=1]'' handelt es sich um einen Entwurf (Draft/Proposed Standard) der The Internet Engineering Task Force (IETF) ''[http://www.ietf.org/]'' und Weiterentwicklung von OLSR ''[http://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol]'' bei folgende Eckpunkte verfolgt werden:
* Die Linkmetrik wird auch durch andere Faktoren als nur den Hopcount bestimmt.
* Wenn Informationen über den Linkstatus vorhanden sind, kann OLSRv2 diese mit einbeziehen.
* Topologiereduktion: Nur Knoten, die als Multipoint Relays (MPRs) fungieren müssen Information zum Linkstatus abgeben.
* Topologiereduktion und Reduktion des Floodings: MPRs führen zwei Typen von Nachbarn ein: Flooding MPRs und Routing MPRs.
...

==== OLSRv2 ''APIPA''/''Auto-IP'' Plugin ====
Henning Rogge (Institut für Kommunikation Informationsverarbeitung und Ergonomie/Fraunhofer) hat ein Plugin für die automatische Vergabe linklokaler Adressen via OLSRv2 geschrieben, dessen Funktiolität sich wie folgt darstellt:
* es vergibt IPv4-linklokale Adressen nur wenn das Interface noch keine IPv4 Adresse hat (und löscht sie wieder wenn der User eine zusätzliche
IPv4 vergibt).
* IPv4-linklokale Adressen werden zufällig gewählt, allerdings wird im ersten Versuch die IPv4 Adresse aus einem Hash der IPv6-linklokalen Adresse errechnet.
* Die Vergabe der IPv4-linklokalen Adressen wird um ein paar Sekunden(aktuell 10) verzögert, damit man Zeit hat die IPv6-linklokalen Adressen der Nachbarn zu lernen.
* Kollisionsdetektion sowohl mit den IPv4-Adressen der Nachbarn als auch mit deren Hash der IPv6-linklokalen Adressen (blockiere nicht die erste Wahl deines Nachbarn!)

Andere Quellen:
Implementierung von olsr.org ''[http://olsr.org/?q=node/63]''
OLSR-NG == OLSR 0.5.x+ ''[http://wiki.funkfeuer.at/index.php/OLSR-NG]''

=== AP/Sta statt Adhoc ===
Im oben zitierten Aufsatz von Wirtz et. al. wird empfohlen, eine gemischte Umgebung aufzusetzen, die mehr den Fähigkeiten, der auf dem Markt erhältlichen Geräten entspricht. Der Adhoc-Mode wird bei diesen oft nicht oder nur rudimentär unterstützt, und Kompatibilitätsprobleme zwischen verschiedenen Chipsätzen stehen dabei immer noch an der Tagesordnung [Anm: Beobachtungen in der 0xFF-Community beim Mischbetrieb von Broadcomm und Atheros]. Details über den Adhoc-Mode, seine Synchroniserungsmechanismen und Probleme können in Matthew S. Gast, "802.11 Wireless Networks - The Definitive Guide²" nachgelesen werden.
Messungen von Wirtz haben ergeben, dass der kombinierte AP/Sta-Modus durchwegs performanter sein kann als Adhoc-Netzwerke und zudem wurde festgestellt, dass diese Modi für mehr Endgeräte zur Verfügung stehen, während der Adhoc-Mode eher vernachlässigt wird.
Wirtz unterscheidet zwischen RONs (ROuting Nodes), die beides Modi betreiben, und STANs (Station Nodes), die nur als Client fungieren.
In unserem Fall sind vermutlich IRONs [Anm: eigene Wortschöpfung] (Intermediate ROuting Ndes) erforderlich, die mit dedizierter Hardware zusätzlich ein Adhoc-Mode-Interface zur Verfügung stellen. Dedizierte Hardware wird deshalb erforderlich sein, das der gleichzeitige Betrieb von Adhoc-Netzen mit einem der anderen Modi erfahrungsgemäß [Anm: in der 0xFF-Community] Performanceeinbussen [Erg: mutmaßlich] jenseits der 20%, die Wirtz beschreibt, mit sich bringt, dies allerdings abhängig von der Umgebung.
Wirtz problematisiert bei seinem Konzept das Thema Handover. Damit Stations von einer Übergabe an einen anderen RON auf Layer 2 möglichst wenig mitbekommen, wird auf allen RONs eine einheitliche ESSID, MAC [Anm: laut Originaltext, richtiger wäre hier "BSSID" oder "MAC-Adresse und BSSID"] und IP-Adresse (wegen Layer 3) benutzt, während auf den STANs keine derartigen Änderungen vorgesehen sind.
Als Problem wird das Routing zwischen den RONs in Bezug auf die STANs im Falle eines Handovers gesehen, wobei ein dynamisches Layer2- oder Layer3- Routing-Protokoll - wie auch bisher - dieses Problem wohl recht rasch korrigiert.
STANs entsprechen der mobilen Infrastruktur, während RONs eher als statische Punkte gesehen werden.
Ein weiteres Problem stellt nach Wirtz unter Umständen die Skalierbarkeit der RON/STAN-Kombination dar. Dieses Problem stellt sich de facto wohl auch bei Adhoc-Netzen, ist aber durch Beschränkungen im AP-Mode wohl besser beherrschbar - ein Ansatz wäre die Fähigkeit RSSI-Thresholds oder die Anzahl der verbundenen Stationen zu limitieren, was im Adhoc-Mode so nicht funktioniert; bei gegenwärtigen Ath9k-Treibern führen derartige Limits, die über "iw" gesetzt werden, allerdings zu Fehlermeldungen - hier wird noch weiter nachzuforschen sein.

Abgebildet auf unser bestehendes Netz: RONs sind Backbone/Freebone-Nodes und ein Teil der etablierten restlichen Nodes, während STANs in der Regel Mobilgeräte (Handies, Laptops, etc) sind.
Im Zusammenspiel mit IPv6 ist davon auszugehen, dass die größeren Datenmengen (alleine die Header sind länger) über den AP-Mode effizientier übertragen werden können. Unter anderem könnte sogar Frame Aggregation ''[http://en.wikipedia.org/wiki/Frame_aggregation]'' benutzt werden, um die Performance zu steigern, was im Adhoc-Mode keinesfalls empfehlenswert erscheint. Die Richtigkeit dieser Vermutung ist allerdings noch zu belegen.

Zusammenfassung:
Bei richtiger Planung könnten die Vorteile von Access Points und Adhoc-Netzwerken zusammengefasst werden, ohne eine unüberschaubare Zahl neuer Probleme zu schaffen. Erhöhte Performanz und Verfügbarkeit stehen im Vordergrund und werden beim Umstieg auf IPv6 unumgänglich sein.
Durch die Umstellung würde die Zahl der für solch ein Netz geeigneter Geräte zunehmen und auch ältere Hardware, hier jedoch mit Einschränkungen wiederverwendbar sein, wobei typische Probleme (z.B. mit Ratenkontrollalgorithmen im Adhoc-Mode und bei starkem Noise) umgangen würden. Das Netz wäre wie beim Adhoc-Mode unproblematisch erweiterbar, jedoch kann ein Nodebetreiber im Gegensatz zum Adhoc-Mode wesentlich besser auf Störungen einer Station (Hidden Node Problem) reagieren (z.B. durch Verweigerung der Assoziierung auf MAC-Ebene).
Es ist zu erwarten, dass mit einer einzigen Referenz-Konfiguration ein breites Spektrum an Einsatzszenarien abgedeckt werden kann, ohne wie in der Vergangenheit Unterscheidungen hinsichtlich des Betriebsmodus zu treffen.

== Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node ==
* Ein OpenWRT-kompatibler Router mit mindestens 8 MB Flash und 32 MB Ram wird vorbereitet.
* Die Paketliste für ein Image umfasst zumindest die folgenden Installationspakete:
''collectd-mod-cpu collectd-mod-conntrack collectd-mod-iptables collectd-mod-memory collectd-mod-network collectd-mod-olsrd collectd-mod-cpu collectd-mod-conntrack collectd-mod-iptables collectd-mod-memory collectd-mod-network collectd-mod-olsrd curl kmod-gre kmod-sit ip iperf iputils-tracepath iputils-tracepath6 iw iwinfo luci luci-app-commands luci-app-ddns luci-app-diag-core luci-app-firewall luci-app-olsr luci-app-qos luci-app-statistics luci-base luci-i18n-base-de luci-i18n-commands-de luci-i18n-ddns-de luci-i18n-diag-core-de luci-i18n-firewall-de luci-i18n-freifunk-de luci-mod-admin-full luci-mod-freifunk luci-proto-ipv6 luci-ssl luci-theme-bootstrap snmpd olsrd olsrd-mod-arprefresh olsrd-mod-jsoninfo olsrd-mod-nameservice olsrd-mod-txtinfo olsrd-mod-watchdog opkg qos-scripts socat swconfig tayga tc tcpdump wireless-tools -wpad-mini wpad wpa-supplicant zlib''
* Es wird ein AP-Client(Station) eingerichtet: ESSID: [(linkpartner)|wien].funkfeuer.at eingerichtet. Für das daraus entstandene Interface wird eine OLSR-Schnittstelle mit der zugewiesenen öffentlichen IPv4-Adresse angelegt. Optional wird die dem Knoten gemäß [http://www.ipv6.wien.funkfeuer.at/ IPv6-Konzept] eine Adresse aus einem dem Knoten inhärenten IPv6-Hostnet (/64) vorzugsweise eingetragen. Vorzugsweise das zweite verfügbare /64, sodass im Bereich des ersten verfügbaren /64 NAT64 oder ähnliches passieren kann. Dieses Konzept betrachtet abweichend vom damaligen Konzept das Hostnet 20a2:60:100[xx]:[yy]00::/64 als für solche Zwecke reserviert.
* Es wird ein AP (Master) eingerichtet: ESSID [(eigenerknotenname]|wien)].funkfeuer.at. Bridging wird deaktiviert. Als IP-Adresse kommt bei jedem (sic!) derartigen Master die private IPv4-Adresse 172.16.16.16/32 zum Einsatz. Als IPv6-Adresse kann eine offizielle IP oder eine noch zu definierende öffentliche IP aus dem 0xFF-Subnetz gewählt werden, mit der eine Anycast-ähnliche Funktion nachgebildet wird. Alternativ kommt eine Link-lokale Adresse zum Einsatz. In diesem Punkt sind noch Forschungen erforderlich. In OLSR wird auch hierfür je ein eigenes Interface angelegt.
* OLSR erhält die Originator-IPv4, die dem IPv4-Client-Interface (0xFF-Jargon "Device-IP") zugewiesen wurde. Damit ist gewährleistet, dass der Knoten nach Außen nur unter dieser Adresse angekündigt wird.

Vorteile des Konzepts:
* Die Routen im Uplink bleiben aus Sicht des Clients stets unverändert, lediglich das Routing in die andere Richtung muss angepasst werden.
* Es wird der Adhoc-Mode bestmöglich nachgebaut.
* Es kann eine Wien-weite ESSID eingeführt werden. (siehe auch Nachteile)

Nachteile des Konzepts:
* Mögliche PMTU-Probleme, noch zu erforschen.
* Master und Client sind stets auf demselben Kanal. Ändert der primäre Master in einer Kette den Kanal, so wechseln auch die anderen den Kanal.
* Bei einer Wien-weiten ESSID würde der Client meist den Master mit dem höchsten empfangbaren Signalpegel wählen. Es entstünden durch die Wahl unterschiedlicher Kanäle Netzwerk-Fragmente, was bei Flächendeckung kein großes Problem darstellt. Als Workaround kann ein Client an die BSSID (MAC-Adresse) eines spezifischen Linkpartners gebunden werden. Kanalwechsel sind so immer noch möglich. Eventuell bringt die automatische Kanalwahl am Kopf einer Kette Vorteile.
* Abweichende RTS-Thresholds, die bei Clients exponierter Hosts geringer sein sollten als am Master, sind so nur bedingt möglich, RTS-Thresholds (in OpenWRT) stets für das phy gelten, nicht für das jeweilige if.

Next Generation Nodes

2015-11-08T11:39:07Z

Erichn: /* Vorwort */

Erichn: /* AP/Sta statt Adhoc */

== Vorwort ==

Auf dieser Seite wird versucht, ein Konzept für "Next Generation Nodes" zu erstellen.
Dieser Text stellt keine Empfehlung dar, sondern soll Überlegungen zur künftigen Entwicklung bündeln, mit deren Hilfe ein performantes Netz der nächsten Generation gestaltet werden könnte.

Next Generation Nodes sind dadurch charakterisiert, dass sie:
* Routing nur mit IPv6 betreiben.
* 6to4 NAT/4to6 NAT aus Kompatibilitätsgründen bereitstellen und mit nur einer individuellen IPv4-Adresse das Auslangen finden.
* [[OLSR-NG]] anstelle von OLSR verwenden.
* anstelle des Adhoc-Mode einen kombinierten AP/Station-Mode verwenden, wie er von Wirtz und anderen ''[http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf]'', "Establishing Mobile Ad-Hoc Networks in 802.11 Infrastructure Mode" beschrieben wird.

== Spezifikationen ==
=== Hardware ===
Jeder Router, der in der Lage ist, gleichzeitig an mehreren Netzen teilzunehmen, sei es durch
* Bereitstellung dedizierter Schnittstellen oder
* Unterstützung von virtuellen Drahtlosschnittstellen (VAP) in der Kombination: mindestens ein Access Point und mindestens eine Station.

=== Software ===
Als Betriebssystem kann -wie bisher- OpenWRT verwendet werden, aber theoretisch auch jede andere Distribution, die
* OLSR-NG zur Verfügung stellt.
* Routinen bereitstellt, um einerseits die Funktionalität
** eines Access Points (AP), andererseits
** einer Station (STA) bereitzustellen.

Eine beispielhafte Softwareausstattung umfasst:
# OpenWRT
## Kernel: kmod-ipv6, kmod-ipip, kmod-gre; kmod-iptables etc.
# OLSR-NG ''[http://wiki.funkfeuer.at/index.php/OLSR-NG]''
# WLAN-bezogen:
## hostapd/wpad (nach Möglichkeit mit Unterstützung für WPA/WPA2)
## Unterstützung für Radius/WPA(2) Enterprise, 802.1X (im Falle des Aufbaus eines zentralen Hotspot-Portals)
# Tayga ''[http://www.litech.org/tayga/]'', ''[http://de.wikipedia.org/wiki/NAT64]'', ''[http://wiki.openwrt.org/doc/howto/ipv6]''
# DNS64 ''[http://de.wikipedia.org/wiki/DNS64#DNS64]''

=== IPv6 ===
Hard- und Software soll in der Lage sein, IPv6 sinnvoll einzusetzen.
Durch Tayga [s.o.] können IPv4 fähige Knoten angebunden werden.
* Bitte ergänzen, wie konkret das aussehen kann
* Wie funktioniert das Zusammenspiel: OLSR,OLSR-NG in dieser Situation; HNA-Ankündigung? Tunnel? Separate OLSR-Inseln?

=== OLSR-NG ===
Beschreibung bitte hier einfügen:
Quellen:
[http://wiki.funkfeuer.at/index.php/OLSR-NG]
[http://www.olsr.org/?q=taxonomy/term/10]

=== AP/Sta statt Adhoc ===
Im oben zitierten Aufsatz von Wirtz et. al. wird empfohlen, eine gemischte Umgebung aufzusetzen, die mehr den Fähigkeiten, der auf dem Markt erhältlichen Geräten entspricht. Der Adhoc-Mode wird bei diesen oft nicht oder nur rudimentär unterstützt, und Kompatibilitätsprobleme zwischen verschiedenen Chipsätzen stehen dabei immer noch an der Tagesordnung. Details über den Adhoc-Mode, seine Synchroniserungsmechanismen und Probleme können in Matthew S. Gast, "802.11 Wireless Networks - The Definitive Guide²" nachgelesen werden.
Messungen von Wirtz haben ergeben, dass der kombinierte AP/Sta-Modus durchwegs performanter sein kann, als Adhoc-Netzwerke und zudem für mehr Endgeräte zur Verfügung steht.
Wirtz unterscheidet zwischen RONs (ROting Nodes), die beides Modi betreiben, und STANs (Station Nodes), die nur als Client fungieren.
In unserem Fall sind vermutlich IRONs (Intermediate ROuting Ndes) erforderlich, die mit dedizierter Hardware zusätzlich ein Adhoc-Mode-Interface zur Verfügung stellen. Dedizierte Hardware wird deshalb erforderlich sein, das der gleichzeitige Betrieb von Adhoc-Netzen mit einem der anderen Modi erfahrungsgemäß Performanceeinbussen jenseits der 20%, die Wirtz beschreibt, mit sich bringt, dies allerdings abhängig von der Umgebung.
Wirtz problematisiert bei seinem Konzept das Thema Handover. Damit Stations von einer Übergabe an einen anderen RON auf Layer 2 möglichst wenig mitbekommen, wird auf allen RONs eine einheitliche ESSID, BSSID(der Originaltext spricht von "MAC") und IP-Adresse (wegen Layer 3) benutzt, während auf den STANs keine derartigen Änderungen vorgesehen sind.
Als Problem wird das Routing zwischen den RONs in Bezug auf die STANs im Falle eines Handovers gesehen, wobei ein dynamisches Layer2- oder Layer3- Routing-Protokoll - wie auch bisher - dieses Problem wohl recht rasch korrigiert.
STANs entsprechen der mobilen Infrastruktur, während RONs eher als statische Punkte gesehen werden.
Ein weiteres Problem stellt nach Wirtz unter Umständen die Skalierbarkeit der RON/STAN-Kombination dar. Dieses Problem stellt sich de facto wohl auch bei Adhoc-Netzen, ist aber durch Beschränkungen im AP-Mode wohl besser beherrschbar. (Ein Ansatz wäre die Fähigkeit RSSI-Thresholds oder die Anzahl der verbundenen Stationen zu limitieren, was im Adhoc-Mode so nicht funktioniert. Bei gegenwärtigen Ath9k-Treibern führen derartige Limits, die über "iw" gesetzt werden, allerdings zu Fehlermeldungen - hier wird nachzuforschen sein.)

Abgebildet auf unser bestehendes Netz: RONs sind Backbone/Freebone-Nodes und ein Teil der etablierten restlichen Nodes, während STANs in der Regel Mobilgeräte (Handies, Laptops, etc) sind.
Im Zusammenspiel mit IPv6 ist davon auszugehen, dass die größeren Datenmengen (alleine die Header sind länger) über den AP-Mode effizientier übertragen werden können. Unter anderem könnte sogar Frame Aggregation ''[http://en.wikipedia.org/wiki/Frame_aggregation]'' benutzt werden, um die Performance zu steigern. Dies ist allerdings noch auszutesten.

Zusammenfassung:
Bei richtiger Planung könnten die Vorteile von Access Points und Adhoc-Netzwerken zusammengefasst werden, ohne eine unüberschaubare Zahl neuer Probleme zu schaffen. Erhöhte Performanz und Verfügbarkeit stehen im Vordergrund und werden beim Umstieg auf IPv6 unumgänglich sein.
Durch die Umstellung würde die Zahl der für solch ein Netz geeigneter Geräte zunehmen und auch ältere Hardware, hier jedoch mit Einschränkungen wiederverwendbar sein, wobei typische Probleme (z.B. mit Ratenkontrollalgorithmen im Adhoc-Mode und bei starkem Noise) umgangen würden. Das Netz wäre wie beim Adhoc-Mode unproblematisch erweiterbar, jedoch kann ein Nodebetreiber im Gegensatz zum Adhoc-Mode wesentlich besser auf Störungen einer Station (Hidden Node Problem) reagieren (z.B. durch Verweigerung der Assoziierung auf MAC-Ebene).
Es ist zu erwarten, dass mit einer einzigen Referenz-Konfiguration ein breites Spektrum an Einsatzszenarien abgedeckt werden kann, ohne wie in der Vergangenheit Unterscheidungen hinsichtlich des Betriebsmodus zu treffen.

Next Generation Nodes

2013-11-17T12:37:45Z

Erichn: /* AP/Sta statt Adhoc */

Next Generation Nodes

2013-11-17T12:37:19Z

Erichn: /* OLSR-NG */

Next Generation Nodes

2013-11-17T12:36:09Z

Erichn:

2013-04-21T12:16:22Z

Erichn:

#
# ACHTUNG: Basierend auf diesem Dokument wird momentan an der Map (s.u.) weiter entwickelt
# ein Großteil der Funktionen wurden schon umgesetzt
# (das tunnelmaster-flag funktioniert momentan noch nicht)
#
# Dies ist ein Dokument, das stündlich von der Map (https://map.funkfeuer.at/experimental) abgerufen wird
# und bestimmten Knoten & Links Besonderheiten zuweist (Syntax weiter unten)
#
# Bitte beachte beim Editieren, dass jede Zeile mit einem Leerzeichen zur korrekten Darstellung beginnen muss.
#
# Kommentare:
# # das Kommentar beginnt ab # und gilt für die ganze Zeile
# // das Kommentar beginnt ab // und gilt für die ganze Zeile
# /* das Kommentar gilt nur in diesem Bereich */
#
#
# Syntax:
# (alle case-sensitive)
# Aufgrund des Datenschutzes kann statt des Knotennamens auch die Node-ID angegeben werden (siehe Map)
#
# node NodeName tunnelmaster [ignore NodeA, NodeB, ... NodeN]
# der Knoten namens "NodeName" ist ein Tunnelkonzentrator
# d.h. jeder Knoten mit Verbindung zu diesem Knoten
# wird als Tunnelknoten ausgewählt
# ignore: Alle Knotennamen nach ignore (getrennt durch Beistrich und Leerzeichen)
# werden ignoriert, auch wenn sie Verbindung mit dem Knoten haben
#
# node NodeName 5ghzbackbone // der Knoten namens "NodeName" ist ein wichtiger teil des 5GHz Backbones, wird mit grünem Marker dargestellt
#
#
# link NodeA NodeB ethernet [static] // der Knoten "NodeA" hat zu "NodeB" eine Kabelverbindung, graue Linie
# link NodeA NodeB 5ghz [static] // der Knoten "NodeA" hat zu "NodeB" eine 5GHz (Highspeed) Verbindung, grüne Linie
# link NodeA NodeB tunnel [static] // der Knoten "NodeA" hat zu "NodeB" einen Tunnel, blaue Linie (keine blauen Marker wie bei tunnelmaster)
#
# die Option static bedeutet, dass der Link auch angezeigt wird,
# wenn es keine OLSR Verbindung zwischen den 2 Knoten gibt und sollte normalerweise nicht verwendet werden.
#

node tunnel tunnelmaster ignore krypta, kryptaroof, datacop, nixroof

link krypta kryptaroof ethernet static
link krypta nixroof ethernet static
link kryptaroof nixroof ethernet static

link krypta tunnel ethernet static

node nixroof 5ghzbackbone
link nixroof ho6 5ghz
link nixroof hh10 5ghz
link nixroof arg67 5ghz

node kryptaroof 5ghzbackbone
link kryptaroof garten94 5ghz
link kryptaroof jg7 5ghz
link kryptaroof zelter7 5ghz

node ho6 5ghzbackbone
link ho6 mir 5ghz

node mir 5ghzbackbone
link mir pas77 5ghz

node zelter7 5ghzbackbone
link zelter7 biss 5ghz
link zelter7 OZW 5ghz
link zelter7 bici 5ghz

node hh10 5ghzbackbone
link hh10 gb24 5ghz
link hh10 luxi122home 5ghz
link hh10 ffh 5ghz
link hh10 as5 5ghz
link hh10 NANO5gb 5ghz

node nano5gb 5ghzbackbone
link nano5gb hh10 5ghz

node gb24 5ghzbackbone
link gb24 hfs 5ghz
link gb24 OZW 5ghz

node heunord 5ghzbackbone
link heunord hasi 5ghz
link heunord schenkich 5ghz
link heunord modul 5ghz
link heunord erzherz170 5ghz
link heunord wmg64 5ghz

node garten94 5ghzbackbone
link garten94 nord27 5ghz
link garten94 heusued 5ghz
link garten94 heunord 5ghz

node liechtwicht 5ghzbackbone
link liechtwicht hp4 5ghz
link liechtwicht gtxgoz11 5ghz

node gtxgoz11 5ghzbackbone
link gtxgoz11 modul 5ghz

node hp4 5ghzbackbone
link hp4 gym42 5ghz
link hp4 leo 5ghz //momentan auf beiden seiten unavailable *G

node gym42 5ghzbackbone
link gym42 liechtwicht 5ghz //smartbridges
link gym42 ho6 5ghz

node leo 5ghzbackbone //vmtl. wiedermal stromlos

link pdorf28 peer 5ghz //pdorf28 - peer(manner?)
link pdorf28 eno5gb // pdorf28 <-> eno (bullet5 <-> RB411AH)

node ffh 5ghzbackbone
link ffh OZW 5ghz

link dg38 as5 5ghz
link as5 ruz24 5ghz

node jg7 5ghzbackbone
link jg7 wo9 5ghz

node nbg43 5ghzbackbone
link nbg43 heusued 5ghz //momentan inaktiv da heusued "outoforder"
link nbg43 kryptaroof 5ghz
link nbg43 rei6 5ghz
link nbg43 ma89 5ghz

node rei6 5ghzbackbone
link rei6 hansi5 5ghz
link rei6 modul 5ghz

node modul 5ghzbackbone
link modul kryptaroof 5ghz
link modul nixroof tunnel static //eoip tunnel
# link gallbrunn?

node ble20 5ghzbackbone
link ble20 wo9 5ghz

node ma89 5ghzbackbone
link ma89 ble20 5ghz
link ma89 spenger25 5ghz

node wo9 5ghzbackbone

node arg67 5ghzbackbone
link arg67 wo9 5ghz

node jed99 5ghzbackbone
link jed99 tunnel tunnel static //ovpn tunnel via engerl
#link jed99 bisam 5ghz
link jed99 put24 5ghz

node put24 5ghzbackbone
link put24 geras 5ghz

node leo 5ghzbackbone
link leo hp4 5ghz

# node erzherz170 5ghzbackbone

link sc54test hetzendorf ethernet static
link sc54test OZW 5ghz
link sc54test tunnel tunnel

node biss 5ghzbackbone
link biss zelter7 5ghz

link wpaeC8West as5 5ghz

link hohl28 koelbl15 5ghz
link hohl28 stu7 5ghz

link schafbergalm heunord 5ghz

link frieden modul 5ghz

link akazia OZW 5ghz

link hzd-au hzd-ff 5ghz

MapSpecialConfig

2013-04-21T12:15:00Z

Erichn:

#
# ACHTUNG: Basierend auf diesem Dokument wird momentan an der Map (s.u.) weiter entwickelt
# ein Großteil der Funktionen wurden schon umgesetzt
# (das tunnelmaster-flag funktioniert momentan noch nicht)
#
# Dies ist ein Dokument, das stündlich von der Map (https://map.funkfeuer.at/experimental) abgerufen wird
# und bestimmten Knoten & Links Besonderheiten zuweist (Syntax weiter unten)
#
# Bitte beachte beim Editieren, dass jede Zeile mit einem Leerzeichen zur korrekten Darstellung beginnen muss.
#
# Kommentare:
# # das Kommentar beginnt ab # und gilt für die ganze Zeile
# // das Kommentar beginnt ab // und gilt für die ganze Zeile
# /* das Kommentar gilt nur in diesem Bereich */
#
#
# Syntax:
# (alle case-sensitive)
# Aufgrund des Datenschutzes kann statt des Knotennamens auch die Node-ID angegeben werden (siehe Map)
#
# node NodeName tunnelmaster [ignore NodeA, NodeB, ... NodeN]
# der Knoten namens "NodeName" ist ein Tunnelkonzentrator
# d.h. jeder Knoten mit Verbindung zu diesem Knoten
# wird als Tunnelknoten ausgewählt
# ignore: Alle Knotennamen nach ignore (getrennt durch Beistrich und Leerzeichen)
# werden ignoriert, auch wenn sie Verbindung mit dem Knoten haben
#
# node NodeName 5ghzbackbone // der Knoten namens "NodeName" ist ein wichtiger teil des 5GHz Backbones, wird mit grünem Marker dargestellt
#
#
# link NodeA NodeB ethernet [static] // der Knoten "NodeA" hat zu "NodeB" eine Kabelverbindung, graue Linie
# link NodeA NodeB 5ghz [static] // der Knoten "NodeA" hat zu "NodeB" eine 5GHz (Highspeed) Verbindung, grüne Linie
# link NodeA NodeB tunnel [static] // der Knoten "NodeA" hat zu "NodeB" einen Tunnel, blaue Linie (keine blauen Marker wie bei tunnelmaster)
#
# die Option static bedeutet, dass der Link auch angezeigt wird,
# wenn es keine OLSR Verbindung zwischen den 2 Knoten gibt und sollte normalerweise nicht verwendet werden.
#

node tunnel tunnelmaster ignore krypta, kryptaroof, datacop, nixroof

link krypta kryptaroof ethernet static
link krypta nixroof ethernet static
link kryptaroof nixroof ethernet static

link krypta tunnel ethernet static

node nixroof 5ghzbackbone
link nixroof ho6 5ghz
link nixroof hh10 5ghz
link nixroof arg67 5ghz

node kryptaroof 5ghzbackbone
link kryptaroof garten94 5ghz
link kryptaroof jg7 5ghz
link kryptaroof zelter7 5ghz

node ho6 5ghzbackbone
link ho6 mir 5ghz

node mir 5ghzbackbone
link mir pas77 5ghz

node zelter7 5ghzbackbone
link zelter7 biss 5ghz
link zelter7 OZW 5ghz
link zelter7 bici 5ghz

node hh10 5ghzbackbone
link hh10 gb24 5ghz
link hh10 luxi122home 5ghz
link hh10 ffh 5ghz
link hh10 as5 5ghz
link hh10 NANO5gb 5ghz

node nano5gb 5ghzbackbone
link nano5gb hh10 5ghz

node gb24 5ghzbackbone
link gb24 hfs 5ghz
link gb24 OZW 5ghz

node heunord 5ghzbackbone
link heunord hasi 5ghz
link heunord schenkich 5ghz
link heunord modul 5ghz
link heunord erzherz170 5ghz
link heunord wmg64 5ghz

node garten94 5ghzbackbone
link garten94 nord27 5ghz
link garten94 heusued 5ghz
link garten94 heunord 5ghz

node liechtwicht 5ghzbackbone
link liechtwicht hp4 5ghz
link liechtwicht gtxgoz11 5ghz

node gtxgoz11 5ghzbackbone
link gtxgoz11 modul 5ghz

node hp4 5ghzbackbone
link hp4 gym42 5ghz
link hp4 leo 5ghz //momentan auf beiden seiten unavailable *G

node gym42 5ghzbackbone
link gym42 liechtwicht 5ghz //smartbridges
link gym42 ho6 5ghz

node leo 5ghzbackbone //vmtl. wiedermal stromlos

link pdorf28 peer 5ghz //pdorf28 - peer(manner?)
link pdorf28 eno5gb // pdorf28 <-> eno (bullet5 <-> RB411AH)

node ffh 5ghzbackbone
link ffh OZW 5ghz

link dg38 as5 5ghz
link as5 ruz24 5ghz

node jg7 5ghzbackbone
link jg7 wo9 5ghz

node nbg43 5ghzbackbone
link nbg43 heusued 5ghz //momentan inaktiv da heusued "outoforder"
link nbg43 kryptaroof 5ghz
link nbg43 rei6 5ghz
link nbg43 ma89 5ghz

node rei6 5ghzbackbone
link rei6 hansi5 5ghz
link rei6 modul 5ghz

node modul 5ghzbackbone
link modul kryptaroof 5ghz
link modul nixroof tunnel static //eoip tunnel
# link gallbrunn?

node ble20 5ghzbackbone
link ble20 wo9 5ghz

node ma89 5ghzbackbone
link ma89 ble20 5ghz
link ma89 spenger25 5ghz

node wo9 5ghzbackbone

node arg67 5ghzbackbone
link arg67 wo9 5ghz

node jed99 5ghzbackbone
link jed99 tunnel tunnel static //ovpn tunnel via engerl
#link jed99 bisam 5ghz
link jed99 put24 5ghz

node put24 5ghzbackbone
link put24 geras 5ghz

node leo 5ghzbackbone
link leo hp4 5ghz

# node erzherz170 5ghzbackbone

link sc54test hetzendorf ethernet static
link sc54test OZW 5ghz

node biss 5ghzbackbone
link biss zelter7 5ghz

link wpaeC8West as5 5ghz

link hohl28 koelbl15 5ghz
link hohl28 stu7 5ghz

link schafbergalm heunord 5ghz

link frieden modul 5ghz

link akazia OZW 5ghz

link hzd-au hzd-ff 5ghz