Übersicht Hardware-/Software für HAMNET

Aus Amateurfunk Wiki

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Peripherie

Einige Beispiele von Sysops (ohne Anspruch auf Vollständigkeit, mit keinem der Anbieter hat die Adacom irgendwelche direkte Beziehungen)

WLAN Router

Ubiquiti

Ubiquiti bietet eine ganze Reihe von Wlan Routern für den Außerbereich d.h. in wetterfestem Gehäuse an.

Prinzipiell wird zwischen B und M Geräten unterschieden und danach auch die Firmware. Alle vorgestellten Router werden über PoE mit Strom versorgt und ermöglichen so einen einfachen Betrieb direkt an der Antenne! Außerdem haben sie eine LED-Anzeige über die die aktuelle Link-Feldstärke angezeigt wird.

Die Router sind für 2.4 oder 5 Ghz erhältlich und haben unterschiedliche Ausgangsleistungen (bis zu 1W).

Firmware ist als Opensource SDK oder bereits fertig erhältlich. Die SDK erlaubt es das erfahrene Programmierer eigene Funktionen hinzufügen (Vorsicht! Das Image darf nicht zu groß werden, das make-Skript prüft die Größe nicht und das Image überflash dann die Konfig-Partition). Im Netz findet man Firmware-Versionen mit integriertem Olsr Router. Wenn etwas beim Flashen schief gegangen ist. Kann man mit dem kleinen Taster (drücken beim Einschalten) und einem TFTP Client eine neue Firmware aufspielen.

Nähere Informationen Siehe Hamnet Wiki Sachsen

Gitterantennen mit integrierter Bullet

Gitterantenne (hoher Gewinn) mit Bullet

Mikrotik

...

WLAN-Karten

"Wistron DCMA82" (etwas dicker, daher max. 2 pro 433er-Board --> eine R5H-Karte koennte dazwischen passen (nicht zu empfehlen --> lieber 1x RB411AH + 1x Wistron DCMA82 ).

Antennen

Siehe auch Antennen

Antenne Bemerkung
Panel Sieht aus wie ein Quadratisches Brett
Vorteile: Abmessung klein, unauffällig, kleine Windlast, leicht montierbar
Gewinn: 2.4Ghz bis 20dBi (35 Euro) 350 x 400x 35 mm
5Ghz bis 23dBi (56 Euro)
Gitter Gitterförmiger Parabolausschnitt
Vorteile: Hoher Gewinn schon bei 2.4Ghz, Windlast und Montierbarkeit mittel
Nachteile: Vereisung im Winter (Gewicht, Funktionsverlust)
Gewinn: 2.4Ghz bis 24dBi (48 Euro) Abmessungen: 600 x 900 mm

5Ghz bis 27dBi (53 Euro) Abmessungen: 400 x 600 mm

Parabolspiegel Parabolform
Vorteile: Sehr hoher Gewinn, blendet Störungen aus (Wlan QRM aus der Stadt...)
Nachteile: Windlast und Montierbarkeit schwierig

Moglichst nur in Gitterform verwenden ->wesentlich geringere Windlast!
Vereisung im Winter! (Last...)

Gewinn: 2.4Ghz bis 24dBi Voll

Abmessungen: 648 mm Durchmesser

5Ghz bis 35dBi (186 Euro) Gitter
Abmessungen: 850mm Durchmesser

Anbieter

Weiterführende Gedanken

Die im Wiki beschriebenen Netzpläne haben allgemeine Gültigkeit und sind nicht an die Hardware von Mikrotik oder RouterOS gebunden. Darum ist es sinnvoll, Vergleiche mit anderen Komponenten und anderer Software durchzuführen.

Auf den Komponenten von Mikrotik ist bereits das firmeneigene RouterOS mit der an die Hardware gebundene Softwarelizenz vorinstalliert. Die Softwarelizenz sollte den Level 4 haben. Damit können alle unsere Anforderungen erfüllt werden. Eine höhere Lizenz ist unnötig. Weitere Informationen zu den Lizenzen gibt es bei Mikrotik (http://wiki.mikrotik.com/wiki/Category:License). Leider kann auf dem RouterOS keine Software von Drittherstellern installiert werden. Mikrotiks Firmenphilosophie ist es, das nur von ihnen getestete stabile Software auf ihren Produkten laufen darf und verhindert daher den Zugang auf die darunter laufende Linuxplattform. Es gibt Bedenken, dass Software von Drittanbietern das Gesamtsystem instabil machen würde und Mikrotik dafür verantwortlich gemacht werden würde.

Die Thematik mit der eingeschränkten Frequenzauswahl ist seit der RouterOSVersion 4.3 offiziell erledigt (http://wiki.mikrotik.com/wiki/Manual:Interface/Wireless#Advanced_settings). Es können nun alle Frequenzen der WLAN-Karte unabhängig von Zusatzlizenzen (Superchannel) genutzt werden.

Für die beschriebenen Standard HAMNET-Installationen stellt die Tatsache der geschlossenen Plattform kein Problem dar. Bisher ist mir auch kein Hack bekannt, der bei einem laufenden RouterOS Zugriff auf eine Linuxshell bietet. Möchte man trotzdem die ganze Freiheit einer Linuxinstallation nutzen, dann kann ein Linux wie OpenWRT auf der Mikrotikhardware installiert werden.

Im Gegensatz zu Mikrotik wirbt Ubiquiti (http://www.ubnt.com) mit seiner „Open Source“-Philosophie und dem Betriebsystem AirOS. Leider ist kein Softwarepaket für das BGP-Routing in der Standardfirmware enthalten. Flemming Frandsen stellt mit seinem AirOS+ aber einen Patch mit einer Anleitung zum Compilieren eines eigenen Firmwareimages mit den BGP-fähigen Softwareroutern Quagga und BIRD bereit (http://dren.dk/airos-plus.html). Die Konfiguration von Quagga oder BIRD ist allerdings nicht in grafischer Form z.B. über ein Webinterface verfügbar, sondern muss über Textdateien erledigt werden. AirOS bietet wie RouterOS alle verfügbaren WLAN-Kanäle und reduzierte Bandbreite (half/quarter) an.

OpenWRT ist eine Linuxdistribution für „embedded devices“. Wie bei einer normalen Linuxdistribution arbeitet es mit einem Paketmanagementsystem. Ziel ist es, ein Grundsystem für möglichst viele Plattformen und möglichst viel Speicherplatz für zusätzliche Pakete zu bieten. Derzeit ist die Version Kamikaze 8.09.2 stabil, aber seit dem 4.3.2010 steht bereits die Version Backfire 10.03 als Beta in den Startlöchern.

Uns Funkamateure interessiert primär die Unterstützung der einzelnen Funkmodule in Bezug auf reduzierte Bandbreite, freier Frequenzwahl und optimiertes Timing für längere Linkstrecken. Leider sind diese Punkte auch heute noch ein großes Problem. Hintergründe zum Thema sind von Steve Lampereur, KB9MWR, gut zusammengefasst worden (http://www.qsl.net/kb9mwr/projects/wireless/modify.html). Mit dem neuen Framework „mac80211“ (http://linuxwireless.org/en/developers/Documentation/mac80211) für Linux ist zwar eine gute Entwicklungsumgebung für quelloffene Wireless Treiber entstanden, aber unsere Anforderungen werden bisher noch nicht offiziell unterstützt. D.h. man kommt nicht um eigene Modifikationen der Treiber herum, wenn man außerhalb des ISM-Bandes mit reduzierter Bandbreite senden möchte.

OpenWRT kann sowohl auf den Mikrotik-Komponenten (Architektur: Mipsel) als auch auf den Ubiquiti-Komponenten (Architektur: Mips) laufen. Spezielle Softwarepakete für AX.25 wurden auf DB0FHN bereits zur Verfügung gestellt (http://db0fhn.efi.fh-nuernberg.de/doku.php#openwrt). Der Softwarestand ist allerdings nicht mehr der aktuellste. Mit den Softwareentwicklern des BIRD internet routing daemon (http://bird.network.cz) versuchen wir derzeit, das Paket „bird“ in den offiziellen OpenWRT Zweig einfließen zu lassen. Setzt man OpenWRT auf einem Mikrotik-Board ein, könnte man den seriellen Port zum Beispiel zum Anschluss eines RMNCs oder APRS-TNC nutzen. Daten serieller Schnittstellen können nach RFC2217 auch über ein Netzwerk übertragen werden. Hierfür gibt es das Paket ser2net.

Für die verbreitete Architektur x86 gibt es Komponenten von ALIX (http://www.pcengines.ch/alix.htm). Für diese Plattform steht bereits ein fertiges OpenWRT-Image mit modifizierten WLAN-Treibern von HB9XAR zur Verfügung (http://hamnet.tuxworld.ch/download). Da über den Compact-Flash Steckplatz eine Menge Speicher zur Verfügung steht, kann statt OpenWRT z.B. auch ein abgespecktes Debian/Linux (Voyage Linux) zum Einsatz kommen. Die x86-Architektur kann beim Entwickeln von Software eine Menge Nerven sparen, da das umständliche Crosscompilieren entfällt. Soll am Standort ein Low-Power-PC für z.B. D-Star, Asterisk/app_rpt oder svxlink betrieben werden, da der Stromhaushalt extrem knapp ist, kann man über die Integration des HAMNET-Links in den Rechner nachdenken. Letztens ist mir erst ein neues Mainboard mit Intel Atom CPU durch seine komplette Fernadministrierbarkeit (Console Redirection, Virtual Media) positiv aufgefallen (http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y).

Mit einer offenen Linuxplattform hat man unter Beachtung der CPU-Belastung die Möglichkeit z.B. auch einen AX.25-Knoten wie Xnet laufen zu lassen. Meist hat man jedoch sowieso einen PC am Standort und kann die benötigten Dienste dort implementieren. Meine Empfehlung ist es, das HAMNET autark aufzubauen, um Ausfallzeiten zu minimieren. Wer die Möglichkeit hat, kann Dienste hardwareseitig separieren.

Persönliche Werkzeuge