[HamNet_V] HAMnet im Osten tut sich was
Bjørn Kagelmacher
DL7RAY at t-online.de
Mo Aug 27 16:19:39 CEST 2012
Hallo HamNet_V - ML,
zunächst möchte ich Dirk, DG0KF & SysOp DB0HGW, DB0OVP recht herzlich in
der Mailinglist für HAMNET im Distrikt V begrüßen.. Er plant an seinem
Standort eine HAMNET-Backbone - Infrastruktur aufzubauen und wand sich
mit seinem Anliegen an mich, um den aktuellen Status zu HAMNET in
unserem Distrikt zu erfragen.. Damit alle Listen-Mitglieder die
vorangegangene Diskussion zwischen Dirk und mir verfolgen können und
auch eigene Kommentare abgeben können, habe ich mir erlaubt das Gespräch
in die Mailinglist zu verlagern.. Es ist sehr zu begrüßen, daß wohl nun
endlich mit der Umsetzung zur Errichtung einer
HAMNET-Backbone-Infrastruktur in unserem Distrikt begonnen wird, nachdem
ich vor Jahren beim ANIR (hier war es Thomas, DL9SAU, vom
AMPR-IP-Koordinatorenteam, welcher uns die bis heute gültige ASN mit den
entsprechenden IP-Blöcken zuwies) ein Subnet für unseren Distrikt
beantragte und die Planungen für den Netzausbau vornahm..
Wenn HAMNET jetzt also auch im Nordosten Deutschlands starten soll,
müssen die nächsten Schritte wohl überlegt sein.. Damit später kein
bunter Mix an unterschiedlicher Hardware- und Softwarekonfiguration
entsteht, sollten wir uns auf einige Standards einigen, welche in
unserem Distrikt Gültigkeit haben, aber uns gleichzeitig auch an die
Vorgaben halten, die vom ANIR gefordert werden.. Mit diesen von uns
festgelegten Standard wird uns eine gewisse Einheitlichkeit garantiert,
was besonders hilfreich ist, da sonst ein Durcheinander an verschiedenen
Hardware-Plattformen existieren würde und man sich in neue Hardware erst
hineindenken müßte.. Wenn wir uns auf zwei oder maximal drei
Herstellerfirmen von WLAN-Plattformen einigen, wüßte jeder OM um die
Besonderheiten dieser Hardware und etwas mit den Begriffen "NanoBridge",
"Loco", "RB" etc. anzufangen..
Deshalb schlage ich vor in unserem Distrikt für die Verwendung im
HAMNET-Backbone nur Hardware der Hersteller
* Mikrotik
* Ubiquiti
* Gateworks
zu verwenden, wobei jede der Plattform spezifische Besonderheiten hat,
welche jeder HAMNET-SysOp kennen sollte.. Hardware von Mikrotik zum
Beispiel stellt kleine Einplatinen-Computer her, welche meistens mehrere
mini-PCI - Erweiterungsslots und eine oder mehrere Ethernetbuchsen
aufweisen.. In die mini-PCI - Slots werden dann die WLAN-Karten
gesteckt.. Mit sog. Pigtails (engl. für Schweineschwanz, Ringelschwanz
bei Schweinen), einem Koaxkabel, wird die WLAN-Karte mit einer N-Buchse,
welche im Gehäuse befestigt wird, in welchem auch das Mikrotik-Board
verbaut ist, verbunden.. Diese Hardware-Konfiguration erlaubt die
Installation eigens ausgewählter Antennen wie z.B. Planar-, Spiegel-,
Sektor- oder Rundstrahlantennen oder den Bau ganz eigener
Antennengebilde.. Weil der Amateurfunkdienst ja ein experimenteller
Funkdienst ist, kann man hier recht gut mit Frequenzen, Sendeleistungen
und Antennen experimentieren.. Mikrotik findet vielfach im Süden
Deutschlands Verwendung..
Aber auch Hardware von Ubiquiti hat einige Vorzüge.. Damals stellte die
amerikanische Firma genau wie heute noch Mikrotik entsprechende Boards
für den WLAN-Einsatz her, die unter dem Namen NanoStation (NS) und
NanoStation Pro (NS Pro) vertrieben wurden.. Heute ist Ubiquiti zu
kompakter Hardware in MIMO-Technik übergegangen.. So ist das Board und
die Antenne in einem Gehäuse integriert.. Es gibt verschiedene
Ausführungen.. Die Bullet zum Beispiel ist im Grunde nur ein Stück
Plastikrohr, daß es in sich hat.. Am einen Ende des Rohrs ist eine
Ethernet-Buchse verbaut, während sich auf der anderen eine N-Buchse
befindet.. Zwischen diesen beiden Buchsen ist im Rohr der eigentliche
Accesspoint verbaut.. Das Bullet wird meist in Verbindung mit
Rundstrahlantennen benutzt, aber auch auch Gitterantennen.. Die
Installation ist einfach.. Bullet auf die HF-Einspeisung der
Rundstrahlantenne oder des Erregerelements der Grid schrauben und
Ethernetkabel in die Ethernetbuchse am anderen Ende des Stücks Rohrs
stecken.. Fertig!!
Ähnlich funktioniert das mit der Bridge.. Sie besteht aus einem Spiegel,
einer Aufnahme für den Accesspoint (AP) und dem AP selbst, welcher
wiederum aus Board und Antenne in einem Gehäuse integriert besteht..
Auch hier ist die Installation sehr einfach.. Aufnahme mit Schrauben im
Spiegel befestigen, AP in die Aufnahme stecken und Spiegel am Mast
befestigen.. Die Bridge ist darauf ausgelegt, zwei WLAN-Standorte
miteinander zu verbinden und hohe, weil in MIMO-Technik aufgebaut,
Datenraten zu übertragen..
Die Loco ist ein sehr kleiner AP zur Mast-Montage.. Sie eignet sich zur
Installation bei HAMNET-Nutzern, welche im HAMNET surfen möchten.. Auch
hier ist Board und Antenne in einem Gehäuse untergebracht.. Die Loco
gibt es für 13cm (Loco M2) und 6cm (Loco M5)..
Praktisch bei Ubiquiti ist die in den Geräten eingebaute grobe
Feldstärkeanzeige, die während des Bootens den Status den AP anzeigt..
Die Signalstärke, bei welcher Feldstärke bestimmte LEDs eingeschaltet
werden, läßt sich beliebig einstellen, genauso welcher Status über die
LEDs angezeigt werden soll.. Sehr Vorteilhaft bei Ubiquiti-Geräten ist
auch die Kürze der Antennenzuleitung zur Antenne, da meistens schon im
Gerät integriert.. Damit entfällt das handtieren mit zusätzlichen
Antennen und Leitungsverluste werden minimiert.. Im freien Funknet
(Freifunk) der Opennet-Initiative e.V. in Rostock wird seit einigen
Jahren im Rahmen der Umrüstung auf Ubiquiti vielfach auf diese Hardware
zurückgegriffen.. Fast der gesamte Backbone ist mit Ubiquiti NanoBridges
aufgebaut und auch viele der "Kunden" im Opennet verwenden Ubiquiti Loco
für den Zugriff auf dieses MAN..
Aber Hardware von Ubiquiti hat neben all diesen Vorzügen auch einen
Nachteil: Im Sinne des Amateurfunks mit WLAN-Experimentieren ist dann
nicht mehr viel, da alles auf Plug&Play getrimmt ist - aufbauen und
loslegen..
Für SysOp's, die einen großen Knotenpunkt aufbauen möchten und auf sehr
leistungsfähige Hardware zurückgereifen müssen, wäre Hardware von
Gateworks interessant.. Praktisch ist die Anzahl von gleich vier
mini-PCI - Steckplätzen auf einem Board bei Avila.. So könnte man mit
nur einem AP Backbone-Verbindungen in alle vier Himmelsrichtungen
aufbauen oder einen Usereinstieg mit vier Sektorantennen realisieren..
Und da schnelle Hardware zum Einsatz kommt, ließen sich auch einige
Server-Prozesse auf einem solchen Board betreiben.. Gegenüber der
Hardware der anderen beiden genannten Hersteller ist Hardware von
Gateworks allerdings sehr teuer..
Bei den WLAN-Karten sollten wir ausschließlich die "Wistron DCMA-82"
verwenden.. Sie genügt allen für unsere Zwecke erforderlichen Maßgaben
und sollte als DIE Standard-WLAN-Karte für HAMNET auch in unserem
Distrikt eingesetzt werden..
Welche Hardware Ihr für Euren Standort verwenden wollt, hängt also davon
ab, welchen Zweck die Installation erfüllen soll.. Der SysOp hat da
volle Entscheidungsfreiheit, nur sollte man bedenken, daß wenn andere
Plattformen verwendet werden und es tritt ein Problem auf man ziemlich
alleine da steht und sich um eine Lösung bemüht.. Sicher schadet es aber
nicht, sich mit dem SysOp des Nachbar-Standortes abzustimmen oder an die
ML zu schreiben..
Auch bei der Software gelten einige Vorgaben, welche wir einhalten
sollten.. Diese Vorgaben wurden einmal vom ANIR festgelegt, andere lege
ich als ARIR für unseren Distrikt fest, damit nicht nur
Backbone-Verbindungen zwischen den HAMNET-Standorten aufgebaut werden
können, sondern auch die Integration unseres HAMNET in das bereits
bestehende HAMNET problemlos möglich ist.. Da diese Punkte besonders
wichtig sind, führe ich diese zunächst in einer kurzen Übersichtsliste
auf und erläutere diese mit mehr oder weniger kurzen Kommentaren in
darunterliegenden Absätzen..
Hier die Liste mit den Standards:
* Einhaltung der Koordinatoren-Hierarchie
* Routingprotokoll: OSPF (für distriktsinterne Backbone-Verbindungen)
eBGP (für Backbone-Verbindungen zum
Nachbar-Distrikt)
* einen BGP-Konzentrator und einen DNS-Server
* Tunnel ins HAMNET
* strikte Trennung zwischen Backbone und User/Service
* keine Multipoint-BB-Verbindungen
* Passwort für SysOp und ARIR
* IPv6-Support
* Backbone-Verbindungen auf 3 GHz und/oder 5GHz
* ESSID und DNS
Nun die Punkte im Einzelnen:
* Einhaltung der Koordinatoren-Hierarchie
In Hinblick auf die spätere Entwicklung bzw. Endausbaus des HAMNET
sollten unbedingt die Hierarchien bei den Ansprechpartner eingehalten
werden.. Daran sollte sich schon heute gehalten werden.. Sicher wird es
Thomas, DL9SAU, als Mitglied im AMPR-IP-Koordinatoren-Team (ANIR),
zuständig für HAMNET im Osten Deutschlands, nicht gefallen, wenn er
täglich hunderte von eMail-Anfragen bezüglich HAMNET erhält, welche
zumeist belanglose Dinge enthalten, weil ein OM keine HAMNET-Verbindung
zum lokalen HAMNET-Standort aufbauen kann.. Zumal kann Thomas von der
Ferne sowieso wenig ausrichten, weil er weder die Situationen noch die
Ansprechpartner kennt.. Damit eMail-Postfächer nicht gefloodet werden,
bitte ich alle hier mitlesenden OM's sich an die Hierarchien zu halten..
Dabei kontaktieren OM's, die im HAMNET surfen, bei Problemen zunächst
den SysOp des Standortes, bei welchem sich die HAMNET-Nutzer sich
einloggen.. Oftmals kann der SysOp da schon weiterhelfen, indem
gemeinsam eine Lösung erarbeitet wird.. Oder andere Nutzer helfen bei
einem Problem aus, was ja durchaus der Fall sein kann, wenn der SysOp
z.B. durch QRL u.ä. nicht sofort erreichbar ist.. HamSpirit - wir sind
alle Funkamateure und helfen uns gegenseitig..
Es kann aber auch schonmal vorkommen, daß der SysOp des jeweiligen
Standortes selbst ein Problem hat (z.B. Routingfehler im Backbone, oder
Zuteilung von IP-Adressen etc.) oder bei einem Problem mit einem Nutzer
überfragt ist.. Dann kann der ARIR des jeweiligen Distriktes (in unserem
Distrikt DL7RAY) sicher aushelfen.. Auch wenn es um Netzplanung, neue
Standards oder HAMNET-Treffen geht, kurz um, wenn es um allgemeine
Dinge, welche im gesamten HAMNET des Distriktes Gültigkeit haben, bin
ich der richtige Ansprechpartner.. Wenn ein Nutzer einen HAMNET-Dienst
betreiben möchte (z.B. WebCam, WX-Station, http-Server etc.), sollte er
diesen Wunsch seinem SysOp melden.. Der SysOp weiß, daß für die ständige
Erreichbarkeit eine feste IP-Adresse erforderlich ist und fragt beim
ARIR nach einer zu vergebenden IP-Adresse.. Der ARIR trägt die zu
vergebene IP in eine Liste ein (Registration) und teilt die zugeteilte
IP dem anfragen SysOp weiter, welcher diese an den Nutzer weiter reicht..
Ideen und Wünsche von Nutzern und SysOps aus unserem Distrikt, welche
ich auch nicht beantworten kann, leite ich an DL9SAU weiter.. So bekommt
Thomas nur die wirklich wichtigen Anfragen, über welche er ggf. mit den
anderen ANIR abstimmen muß (z.B. wenn das Thema IPv6 wieder aufgegriffen
wird).. Zusätzlich ließt er aber auch in dieser Liste mit.. Fragen, die
ich zu Thomas weiterleiten muß wären zum Beispiel jene, die mit der
Vergabe neuer Subnetze einhergehen, Tunnel von unserem Distrikt zum
Ost-Hub oder bei Fragen, bei denen ich selbst überfragt bin..
Außerdem kann jeder OM in diese Liste schreiben, der nach einer Lösung
für sein Problem bei HAMNET sucht.. So stelle ich mir reibungslose
Kommunikation vor, ohne dabei die Postfächer wichtiger OM's mit "Spam"
'zuzumüllen'..
* Routingprotokoll:
Für das Routing im Backbone des Distriktes V wird OSPF eingesetzt..
Damit wird Distriktsintern nur ein Routingprotokoll eingesetzt, was in
Hinblick auf die spätere Backbone-Infrastruktur in unserem Distrikt
flexibel und leistungsfähig genug ist, die verschiedenen
HAMNET-Standorte zu verwalten, ohne daß uns die ganze Sache mit HAMNET
über den Kopf wächst.. Bei den sog. Border-Gateways kommt ein
zusätzliches Routingprotokoll zum Einsatz.. Bordergateways sind
HAMNET-Standorte an unseren Distriktsgrenzen, welche eine
Backbone-Verbindung zum Nachbardistrikt haben.. Über diese
Backbone-Verbindung zum Nachbardistrikt wird eBGP (external
BorderGatewayProtocol) eingesetzt, um Routinginformationen zum
Nachbardistrikt austauschen zu können.. Für unseren Fall wären dies die
Standorte DB0NBB <-> DB0ZEH und DB0KUE <-> DB0MAR, aber auch Tunnel..
* BGP-Konzentrator und DNS-Server
Sehr Vorteilhaft wäre die Einrichtung eines BGP-Kenzentrator und
DNS-Servers am Standort von DB0HST in Stralsund, da sich dieser
potentielle HAMNET-Standort auf dem Campus-Gelände der Fachhochschule
Stralsund befindet und damit ein möglicher Zugang zum DFN bereitsteht..
* Tunnel ins HAMNET
Da per WLAN noch keine Verbindung zum bereits bestehenden HAMNET
aufgebaut werden kann, sind wir für die Dauer, in der unser Distrikt
noch nicht am HAMNET angebunden ist, auf einen Tunnel angewiesen..
Dieser Tunnel sollte von dem HAMNET-Standort, der am Dichtesten zu einem
HAMNET-Standort des Nachbar-Distriktes steht, eingerichtet werden.. So
könnte man DB0NBB per Tunnel an den Ost-Hub anschließen und einen
Backbone-Link zu DB0HGW und DB0OVP bauen, womit die erste HAMNET-Insel
in unserem Distrikt am HAMNET angeschlossen wäre.. Trotzdem sollte eine
Devise oberste Priorität haben: "So wenig Tunnel wie möglich, so viel
wie nötig".. Damit behält man den Überblick über die aktiven Tunnel,
ohne Gefahr zu laufen, daß Tunnel kreuz und quer durch das gesamte
Bundesgebiet verlaufen.. Zudem soll das HAMNET auch dann noch sicher
funktionieren, wenn alle anderen Kommunikationsmittel ihren Dienst
versagen; also auch selbst dann, wenn das Internet weg bricht.. Das
HAMNET soll autark funktionieren, ohne irgendwelche Tunnellösungen..
* strikte Trennung zwischen Backbone und User/Service
Für das Backbone-Netz und für die Verwendung als User/Service gibt es
getrennte IP-Adressen.. Diese beiden Netze sollen auch weiterhin
getrennt bleiben.. Es gilt der Grundsatz, daß alle Hosts, die
unmittelbar im HAMNET-Backbone hängen, auch IP-Adressen speziell für den
Backbone erhalten.. Alle anderen Dienste (z.B. Webserver, WebCam,
Fonie-Relais, PR, APRS, WX etc.) und Nutzer (OM's, die im HAMNET
surfen), erhalten einen kleinen IP-Pool (DHCP-Server der
HAMNET-Standorte für User-Login) oder jeweils eine IP-Adresse für einen
Host, der von außen zugänglich sein muß.. Wenn DB0HGW / DB0OVP
eingerichtet ist, kann man sich diesen als Vorbild nehmen und nach
diesem Beispiel auch die anderen HAMNET-Standorte einrichten..
* keine Multipoint-BB-Verbindungen
Wir sollten es vermeiden im Backbone Multipoint-Verbindungen
herzustellen, da sonst der Datendurchsatz durch ständige automatische
Änderung des Routings leiden würde.. Multipoint-Verbindungen sind
Verbindungen, welche von einem HAMNET-Standort zu mehreren
HAMNET-Standorten führen.. Stattdessen sollten wir für jeden
Backbone-Link genau eine Gegenstelle haben, mit der sich dieser BB-AP
verbindet.. Auf den HAMNET-Usereinstiegen sind Multipoint-Verbindungen
erwünscht.. Aber wenn die Datenrate auf dem Usereinstieg stockt, muß an
diesem HAMNET-Standort möglicherweise ein zweiter Usereinstieg
eingerichtet werden..
* Passwort für SysOp und ARIR
Damit niemand unbefugt an der Konfiguration der einzelnen HAMNET-Devices
herumspielt, sollten alle Geräte mit einem Passwort versehen werden..
Befugt sind die SysOps des jeweiligen HAMNET-Standortes und der ARIR..
Warum soll der ARIR auch autorisiert sein Änderungen an der
Konfiguration vornehmen zu dürfen?! Weil der ARIR den Überblick über das
gesamte HAMNET des Distriktes hat und so schneller Rückschlüsse auf
Fehlkonfigurationen ziehen kann.. So kann er bei Meldung eines Problems
direkt eingreifen und schnell zur Lösung beitragen.. Der jeweilige SysOp
erhält eine eMail über die vom ARIR gemachten Einstellungen, sodaß der
SysOp informiert ist und es dadurch vermieden wird, alte Einstellungen
zurückzuschreiben.. Ich schlage vor, für den Login des SysOps ganz
normal den root-Account (root:root) zu verwenden und für den Login des
ARIR einen neuen User 'arir' in der Gruppe 'root' mit root-Rechten
anzulegen (arir:root).. Damit kann der SysOp auch nachvollziehen, wenn
sich der ARIR eingeloggt hat und welche Eingaben gemacht worden sind..
* IPv6-Support
Im Distrikt V sollte jeder HAMNET-AP das Internet-Protokoll Version 6
unterstützen.. Ich denke, daß IPv6 im HAMNET irgendwann enorm wichtig
werden wird und da möchten wir schon jetzt vorbereitet sein.. Zwar wird
im HAMNET überwiegend noch mit dem alten Internet-Protokoll (IPv4)
gearbeitet, aber für Experimente im HAMNET läßt sich IPv6 durchaus
anwenden.. Zur Zeit ist aber imo IPv6 im HAMNET noch nicht im Einsatz..
@DL9SAU: Thomas, weißt Du, ob Brian für 44.0.0.0/8 bereits ein
IPv6-Subnet beantragt hat (z.B.: fd2c::/16)?!
* Backbone-Verbindungen auf 3 GHz und/oder 5GHz
Vorzugweise sollten Backbone-Verbindungen auf den höheren Bändern
abgewickelt werden.. Hier ist das Störaufkommen nicht so hoch wie bei
2.4GHz, wo viele WLAN-Geräte von Nutzern senden..
* ESSID und DNS
Auch wir sollten die vom ANIR vorgeschlagene Struktur bei der
Namensvergabe verwenden.. Hier ein Beispiel:
link-hgw-nbb.db0hgw.as64642.de.ampr.org
Dabei liegt folgende Struktur zugrunde:
.ampr.org = DOMAINNAME für das internationale AMPRNET (44.0.0.0/8)
.de = COUNTRY im AMPRNET (ermöglicht echte Delegation im
Internet!)
.as64642 = ZONENAME eines AS (Unterscheidung der verschiedenen
AS-Zonen) Unser Distrikt hat die ASN 64642
.db0hgw = CALLSIGN vom jeweiligen STANDORT innerhalb des AS
link-hgw-nbb = HOSTNAME für ein Gerät, einen Dienst, Router, eine
IP-Steckdose etc.
Auch wir sollten diese Struktur beibehalten.. Hier werde ich später mehr
Zeilen schreiben, aber ich denke das Prinzip ist klar..
Wenn wir uns an all diese Regeln halten, sollte einem funktionierenden
HAMNET eigentlich nichts mehr im Wege stehen.. HAMNET ist das, was ein
jeder SysOp daraus macht.. Je besser die Konfiguration, desto besser
wird man im HAMNET auch surfen können und desto störungsfreier ist der
spätere Betrieb, wenn auch die einzelnen Repeaterstandorte vernetzt sein
werden.. Darum laßt uns gemeinsam alle anpacken und uns ein schönes
Backbone-Netz nach dem Muster auf www.hamnet-dl.de/ aufbauen..
73 de Bjørn, DL7RAY & SysOp DB0HRO & ARIR Distrikt V
Am 26.08.2012 23:04, schrieb Dirk:
> Hallo Bjørn,
>
> Vielen Dank, für Deine ausführlichen Informationen. Das war eine Menge
> Stoff zum lesen.
>
> Zu einigen Punkten die du angesprochen hast.
>
> Die Karte des geplanten Netzes hatte ich auch im Internet gefunden.
> Für die Verbindung HGW <->HST sehe ich auch keine Probleme, laut
> Streckenprofil sollte es
> gehen. Berechnung sieht i.O. aus. Bei der Strecke NBB <-> HGW sieht es
> schon anders
> aus. Das Streckenprofil sagt es geht nicht. Vor NBB ist laut Profil
> ein Berg wo wir nicht drüber
> kommen. In Natura habe ich diesen Berg allerdings noch nicht gefunden.
> Ohne Berg ist die
> Berechnung noch i.O. aber nur mit hohem Antennengewinn. Da ist auf
> jeden Fall noch Klärungs-
> bedarf.
Ich habe die Höhen der Antennen über Grund neu festgesetzt.. So befindet
sich die Höhe der Antenne über Grund bei DB0HGW bei 75 Metern.. Diese
Höhe habe ich aus dem Internet für die Bakenantenne entnommen.. Auf
welche Höhe sich die HAMNET-Antenne befinden wird, weiß ich nicht.. Die
Höhe der HAMNET-Antenne bei DB0NBB habe mit 8o Metern bei DB0NBB
willkürlich gewählt.. Hier fehlt mir eine genaue Antennen- bzw.
Plattformhöhe.. Wenn etwas mehr als die Hälfte der Ausdehnung des
Fresnelzone verfügbar ist, sollte eine Verbindung mit guten Antennen
möglich sein.. Gerade für den Backbone-Link zwischen DB0HGW und DB0NBB
sollten Antennen mit gutem Gewinn zum Einsatz kommen.. Hier mal ein
Vorschlag, aus welchen Komponenten ein BB-Node bestehen könnte:
/ Anzahl | Bezeichnung | Produktname | Preis | URL zum Produkt
// -------|---------------|---------------------------|-----------|---------------------------------------------------------------------------------------------------------
// 1x | Routergehäuse | PC Engines Outdoor Gehäuse| 48,58 EUR | http://www.mikrotik-shop.de/Gehaeuse/Outdoor/PC-Engines-Outdoor-Gehaeuse-1x-N-Typ-1x-Ethernet::267.html
// 1x | Montageplatte | für MikroTik-Routerboard | 17,50 EUR | http://www.mikrotik-shop.de/Gehaeuse/Outdoor/Montageplatte-MikroTik::271.html
// 1x | Routerboard | MikroTik RB411AH | 71,36 EUR | http://www.mikrotik-shop.de/Mainboards/MikroTik-RouterBOARD-411AH-L4-1-x-LAN-1-x-miniPCI::234.html
// 1x | WLAN-Iface | Wistron DCMA-82 | 38,00 EUR | http://www.mikrotik-shop.de/Interfaces/Wistron-DCMA82::276.html
// 1x | Pigtail | HDF-100, MMCX -> Type-N | 7,50 EUR | http://www.mikrotik-shop.de/Antennenkabel/Pigtails/18cm-Pigtail-MMCX-auf-N-Buchse::300.html
// 25 cm | Koaxkabel | Ecoflex 15 Plus / Meter | 10,95 EUR | http://www.conrad.de/ce/de/product/604980/KOAXIALKABEL-SCHWARZ-ECOFLEX-15-PLUS
// 2x | HF-Steckverb. | Type-N Stecker | 9,90 EUR | http://www.mega-kom.de/eshop/product_info.php?products_id=12098
// 1x | Antenne | PARABOLA XP 36 dBi, 5 GHz | 96,60 EUR | http://www.atel-electronics.eu/produkt.php?hash=05225&dispLang=EN
// ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
// 310,29 EUR/
>
> Bei den Admin - Rechten für die eingesetzte Geräte sehe ich keine
> Probleme. Im PR-Netz war es
> zumindest bei DB0HGW ähnlich. Da hatten auch mehrere OM´s die
> Möglichkeit Systemparameter
> anzupassen.
So sollte das auch im HAMNET sein, wobei man genau überlegen sollte, wer
root-Rechte bekommt, denn mit diesen erhält man ALLE Rechte zur
Konfiguration des jeweiligen Device..
>
> An dem Block Bild der geplanten Stationen bin ich dran.
Sehr schön.. So bekommt man gleich einen optischen Eindruck über den
Aufbau.. Das Programm "dia" kann ich Dir für solche Dinge sehr empfehlen..
>
> Es ist aber auch nicht kompliziert was wir hier vorhaben.
>
> DB0HGW : Standort Greifswalder DOM dort laufen alle HF-Verbindungen
> Links / Einstiege,
> D-Star Repeater (beantragt), APRS , (geplant
> Anbindung Echolink, Klubstation, Usereinstieg)
>
> DB0OVP: Standort: Gahlkow (bei mir zu Hause) dort laufen DX-Cluster,
> Internet-Verbindungen
>
> DB0HGW und DB0OVP sind mit einem HF-Link verbunden. Bis jetzt lief der
> Link im 23cm -Band
> mit der zur Zeit beantragten Lizenzverlängerung habe ich eine Frequenz
> im 6cm Band mit HamNet-
> Parametern beantragt.
> Ein Linktest auf der Strecke (12km) mit grob ausgerichteten Nano
> Bridge´s, hat gute Ergebnisse gebracht.
Das würde mich auch schwer wundern, wenn es mit NB über eine Distanz von
~1o km nicht funktionieren sollte.. ;-)
> Da wären wir beim nächsten Punkt.
>
> Der VPN-Tunnel zum HamNet. Aus Erfahrung der letzten Jahre werde ich
> das DX-Cluster auch weiter
> direkt am Internet betreiben bzw. mich nicht mehr nur auf HF-Links
> verlassen. Es sollten natürlich vorrangig
> die HF-Links genutzt werden, wie es die PR-Technik auch schon gemacht
> hat. Aber als Backup sollte ein
> VPN-Tunnel verfügbar sein. Dieser könnte dann auch von DB0OVP ausgehen.
Tunnel sollten sparsam verwendet werden.. Begründung siehe oben..
>
> Beim Routing Protokoll sollten wir das nehmen was für uns zukünftig
> besser ist. Ich denke da hast du mehr
> Erfahrung.
>
> Bleibt noch die Frage der zu verwendeten Hardware.
> Ich habe gelesen das im Süden größtenteils die Routerboards von
> Mikrotik eingesetzt werden bzw. die
> Nano Station/Bridge von ubnt. Gibt es dort bei uns schon Erfahrungen
> oder Absprachen?
Absprachen gibt es bisher zwar noch nicht, aber wir sollten auf die o.a.
Hardware zurückgreifen.. Erfahrungen habe ich schon mit allen dreien
Plattformen und einigen weiteren gemacht.. Wie es bei den anderen hier
mitlesenden OM's aussieht kann ich leider nicht sagen.. Aber vielleicht
kann man für die Wintermonate mal wieder ein HAMNET-Kompetenz-Treffen
machen..
>
> Auf den Mailverteiler habe ich mich eingetragen.
Das habe ich gelesen.. Das ist aber schon eine kleine Weile her.. :-D
>
> vy 73
>
> Dirk, DG0KF
>
>
> Am 17.08.2012 01:55, schrieb Bjørn Kagelmacher:
>> Hallo Dirk,
>> es freut mich, daß es nun wohl erstmals mit HAMNET in unserem Distrikt
>> vorangehen wird.. Schön, wenn es klappt ein lauffähiges HAMNET vorweisen
>> zu können..
>>
>> Seit dem Treffen vor 2 Jahren ist leider noch nichts bezüglich der
>> Realisierung eines HAMNET im Distrikt V passiert.. Es fehlt wie so oft
>> !!ein Anfang!!, wo andere SysOps und OM's sehen, daß HAMNET nun auch in
>> unserem Distrikt startet und
>> sich mit ihrer WLAN-Technik an ein bereits bestehendes HAMNET verbinden
>> (assoziieren) und an Know-How anknüpfen können.. Dieses Treffen sollte
>> allen teilnehmenden OM's Mut machen, ein HAMNET aufzubauen und auch Wege
>> aufzeigen, wie eine Lösung aussehen könnte..
>>
>> Zwischenzeitlich hatte ich einige Anfragen bezüglich des
>> Aufbaufortschritts des HAMNET in unserem Distrikt erhalten, welcher die
>> Dokumentation auf www.hamnet-dl.de/ zur Grundlage hatte.. Leider wurde
>> die Zeichnung so interpretiert,
>> als würde das HAMNET bereits fertig aufgebaut bestehen und ich wurde
>> gefragt wie man daran teilnehmen kann.. So mußte ich den interessierten
>> OM's erklären, daß es sich bei dieser Zeichnung nur um einen Entwurf
>> handelt, wie das Backbone-Netz später einmal aussehen soll.. Dies ist
>> auch daran zu erkennen, daß keiner der Standorte eine vollständige
>> IP-Adresse hat.. Diese wird bei der Aktivierung des Standortes vom ARIR
>> vergeben.. Außerdem hatte der Ortsverband Greifswald die Idee ihre
>> Clubräume via DB0MAR (Timmendorfer Strand) an das HAMNET anzubinden..
>> Dazu sollte eine Ubiquiti NS auf dem Fernmeldemast des OV installiert
>> werden, was allerdings wieder etwas eingeschlafen ist.. Schön, wenn in
>> Grevesmühlen ein HAMNET-Client in Betrieb geht; aber eigentlich geht es
>> mir als ARIR des Distriktes V vorrangig um den Aufbau einer
>> HAMNET-Backbone-Infrastruktur.. Mit DB0HGW bzw. DB0OVP wären die ersten
>> automatischen Funkstellen in unserem Distrikt mit HAMNET-Unterstützung
>> in Betrieb..
>>
>> Warum das so lange mit dem Aufbau eines HAMNET in unserem Distrikt auf
>> sich warten läßt, kann ich mir nur so erklären, daß die für den
>> jeweiligen Standort zuständigen SysOps die Anschaffungskosten, oder die
>> für sie noch recht neue Technik fürchten, oder aber keinen Bedarf bzw.
>> Nutzen im HAMNET sehen.. Das ist sehr schade, weil von den meisten OM's
>> das ungeheure Potential nicht erkannt wird, welches im HAMNET steckt..
>> Deshalb ist es umso wichtiger zu zeigen: "Hey!! Guckt mal her.. Wir
>> haben HAMNET bereits in Betrieb.. Wollt ihr nicht auch mitmachen?!"..
>> Laß uns beginnen!!
>>
>>
>>
>>
>> Es ist sehr wichtig, schon von Anfang an gewisse Standards in unserem
>> Subnet festzulegen.. Dies dient dazu ein einheitliches Netz zu schaffen,
>> mit dem sich jeder OM verbinden kann, ohne zusätzliche Barrieren zu
>> schaffen.. So sollte jeder, der sich mit HAMNET beschäftigt, die
>> hierarchische Struktur bei der IP-Adressvergabe und bei Anfragen
>> kennen.. User (OM's), welche Probleme mit ihrem Einstieg oder der
>> Konfiguration haben, melden sich beim regionalen SysOp des Digipeaters,
>> bei dem sich der jeweilige User ins HAMNET einloggen möchte.. Dann wird
>> gemeinsam eine Lösung erarbeitet.. Wenn SysOps mit ihrem Wissen nicht
>> mehr weiter kommen, IP-Adressen benötigt werden, Routingfehler auftreten
>> etc., wenden sich die SysOps an den jeweiligen ARIR ([A]MPRNet
>> [R]egional [I]P [R]egistry) des jeweiligen Distriktes.. (Im Fall
>> Distrikt V bin ich der ARIR)
>> Der ARIR verwaltet also die vom ANIR ([A]MPRNet [N]ational [I]P
>> [R]egistry) zugeteilten Subnetze.. Der ANIR ist im Fall Deutschland ein
>> Team bestehend aus drei Koordinatoren, welche Deutschland in drei
>> Verwaltungszonen unter sich aufgeteilt
>> haben.. So ist Egbert Zimmermann DD9QP für den Bereich Nordwest, Jann
>> Traschewski DG8NGN für den Bereich Süd und Thomas Osterried DL9SAU für
>> den Bereich Ost zuständig.. In diesen Bereichen stehen auch die
>> HAMNET-Switches, an denen für die jeweiligen Bereiche auch die Tunnel
>> für HAMNET-Insellösungen enden.. Wenn wir im Distrikt V ein neues Subnet
>> zugeteilt bekommen oder sich die ASN ändert, geht diese Info von DL9SAU
>> direkt zu mir und ich mache diese Info dann im Distrikt bekannt..
>> Umgekehrt wende ich mich bei Fragen und Ideen, welche nicht nur den
>> Distrikt V betreffen, sondern u.U. auch bundesweit Gültigkeit haben
>> (z.B. IPv6) und bei Weiterleitungen von Anfragen von SysOps unseren
>> Distriktes an den ANIR direkt an Thomas DL9SAU..
>>
>> Ein weiterer Punkt der Standardisierung in unserem Distrikt betrifft die
>> Administration der HAMNET-Standorte.. So sollte es selbstverständlich
>> sein, daß sowohl der zuständige SysOp als auch der ARIR Zugriff auf die
>> Geräte der HAMNET-BB-Standorte haben.. Man kann das so wie im
>> Freifunknetz "Opennet-Initiative e.V." in Rostock lösen, daß die AP ein
>> einheitliches root-Passwort besitzen, was so bisher problemlos
>> funktioniert, weil die Administratoren des Netzes bei Problemen schnell
>> eingreifen können oder zwecks Dokumentation schnell die Konfiguration
>> einsehen können.. Diese Lösung schätze ich schon seit Jahren, weil das
>> lästige hantieren mit Passwortlisten entfällt.. Für unser HAMNET und
>> weil wir Funkamateure alle Rufzeichen haben favorisiere ich einen
>> anderen Ansatz.. Ein root-Account für jedes Device für den zuständigen
>> SysOp und ein User-Account mit Root-Rechten in der Gruppe root für den
>> ARIR (z.B. arir:root).. So kann ich, wenn im späteren Netz irgendetwas
>> nicht stimmt die Konfiguration prüfen und ggf. ändern mit eMail an den
>> jeweiligen SysOp, wo beschrieben wird, welche Änderungen vorgenommen
>> wurden.. Außerdem hat der Login mit einem User-Konto den Vorteil, daß
>> der SysOp einsehen kann, wer und wann sich Jemand eingeloggt hat und
>> welche Eingaben gemacht worden sind.. Ich denke, wir sollten uns auf den
>> letztgenannten Vorschlag einigen..
>>
>> Ein weiterer Standard ist, daß das Routingprotokoll OSPF für das interne
>> Routing im HAMNET-Backbone (Distrikt V) eingesetzt wird.. Ich habe zwar
>> auch über den Einsatz von iBGP nachgedacht, doch ist OSPF gerade bei
>> größeren Netzen skalierbarer.. Bei kleinen Netzen fällt es kaum ins
>> Gewicht, ob man für das Routing iBGP einsetzt, aber sind erst mal
>> (gerade im Endstadium des Ausbaus) viele Knoten zu verwalten, werden die
>> Vorzüge von OSPF erkennbar.. Und wir haben einen Vorteil: Wir müssen
>> dann nicht mehr Umstellen, weil wir bereits OSPF einsetzen.. Nur die
>> Border-Gateways, also die HAMNET-Standorte an unseren Distriktsgrenzen
>> müssen neben OSPF zusätzlich eBGP unterstützen, um Routinginformationen
>> mit den Nachbardistrikten austauschen zu können.. Als Routingdaemon
>> sollten wir uns auf bird oder quagga (vormals zebra) einigen, wobei bird
>> bevorzugt verwendet werden sollte (Empfehlung).. bird ist einfacher zu
>> administrieren.. quagga ist sehr komplex..
>>
>> Außerdem sollte jeder Standort mit der Unterstützung für IPv6
>> ausgerüstet sein.. Dies ist keine Vorgabe vom ANIR, aber eine Empfehlung
>> von mir als ARIR.. Da das IPv6-Protokoll eh kommen wird und es sicher
>> auch viele Funkamateure gibt, die mit dem neuen Internetprotokoll
>> experimentieren möchten, sollte es auf JEDEM Device eingerichtet sein..
>>
>> Weil der Distrikt V keine Anbindung an das HAMNET hat, müssen wir an die
>> oben bereits angesprochene Tunnel-Lösung (VPN) zurückgreifen.. Wir (ANIR
>> und ARIR) sehen es nicht gerne, wenn kreuz und quer Tunnel eingerichtet
>> werden, da man so schnell den Überblick verliert und das Verwalten
>> erschwert.. Deshalb lautet die Devise: So wenig Tunnel wie möglich, so
>> viel wie nötig.. Ein Tunnel, im Ausnahmefall zwei Tunnel, sollten
>> genügen..
>> Es würde Sinn machen eine Bridge (HAMNET-Backbone) zwischen DB0HGW und
>> DB0NBB einzurichten und diesen Tunnel bei DB0NBB einzurichten, weil
>> DB0NBB im späteren Endausbau des HAMNET ein zentraler Knotenpunkt sein
>> wird.. Dieser Tunnel hat dann so lange Bestand, so lange noch keine
>> Verbindung zu DB0ZEH besteht.. Ein großes Problem sehe ich im Aufbau der
>> Backbone-Linkstrecke zwischen DB0HGW und DB0NBB aufgrund der großen zu
>> überbrückenden Distanz dieser beiden Digipeaterstandorte (s. Links
>> Distrikt V / Main-Backbone / DB0HGW-DB0NBB).. Hier können nur Antennen
>> mit großem Gewinn oder ein zusätzlicher Hop Abhilfe schaffen..
>> Vielleicht sollte man zuvor auch einmal eine Versuchslinkstrecke
>> testen.. Über den Link in Richtung DB0HST mache ich mir keine Sorgen..
>> In DB0HST könnte ein BGP-Concentrator stehen, da dort an der
>> Fachhochschule eine Verbindung ins DFN besteht..
>>
>> Der Verbindung der einzelnen HAMNET-Standorte sollte über den Backbone
>> im 5cm-Band auf den für den HAMNET-Backbone ausgewiesenen
>> Amateurfunkfrequenzen abgewickelt werden.. Die Unterverteilung zu den
>> Usern sollte vorzugsweise im 13cm-Band auf den für HAMNET-User/Service
>> ausgewiesenen Amateurfunkfrequenzen stattfinden (kann aber auch 5cm
>> sein)..
>>
>> Vom ANIR habe ich die AS-Nummer 64642 mit der Domain DISTRIKT-V-642-AS
>> zugewiesen bekommen.. Darin enthalten sind zwei IPv4-Blöcke
>> (44.224.44.0/24 für den Backbone und 44.225.88.0/22 für
>> User/Service-Netz).. Der IPv6-Prefix fc2c:fc82::/32 wurde nicht vom ANIR
>> zugeteilt, sondern entstammt meines geistigen Einfallsreichtum.. ;-)
>> Wenn die Zeit gekommen ist, dann gerne mehr zu IPv6.. Daraus habe ich
>> die IPv4-Blöcke so aufgeteilt, wie sie seit einigen Jahren auf
>> www.hamnet-dl.de/ veröffentlicht sind.. Gedanken mache ich mir, ob wir
>> die Transfernetze wirklich brauchen.. Aber das wird die Zeit zeigen..
>> Wichtig ist, daß Backbone-Netz und User/Service-Netz stets getrennt
>> bleiben und die Geräte entsprechende IP-Adressen bekommen, wofür sie
>> auch gedacht sind.. So erhält jeder AP im Backbone eine von mir
>> zugeteilte IP-Adresse.. Möchtest Du für Deinen Standort zwei
>> Linkstrecken betreiben DB0HGW<->DB0HST und DB0HGW<->DB0NBB wirst Du zwei
>> Backbone-IP-Adressen benötigen.. Alle anderen Geräte (Server, Webcam,
>> Repeater (D-STAR), Digipeater (APRS) und sonstige Dienste, welche mit
>> einer festen IP-Adresse erreichbar
>> sein müssen) erhalten eine IP-Adresse aus dem User/Service-Netz-Pool des
>> jeweiligen Standortes.. Dies gilt auch für User-Stationen, welche z.B.
>> eine vom HAMNET aus erreichbare Wetterstation oder WebCam von zuhause
>> aus betreiben.. User, welche sich nur mit dem HAMNET Verbinden, um im
>> HAMNET zu surfen, erhalten per DHCP eine IP-Adresse aus dem DHCP-Pool
>> (User/Service) des jeweiligen HAMNET-Standortes..
>>
>> Die vom ANIR für unseren Distrikt zugeteilten IP-Blöcke sind fest.. Ich
>> kann aber nicht sagen, ob sich hinsichtlich der Aufteilung der
>> IP-Adressen noch etwas ändern wird, zumal das HAMNET ja noch wächst..
>> Deshalb sind Änderungen jederzeit
>> vorbehalten, doch muß der ARIR das ganze managen; dafür ist er ja da!!
>>
>> Wünschenswert wäre ein Blockbild der HAMNET-Installation, um sich eine
>> genaue Vorstellung von der Konfiguration machen zu können.. Am
>> einfachsten geht das mit dem Programm DIA, welches unter Linux verfügbar
>> ist (eine Windows-Version gibt es imo auch).. Diese Skizze könnte man
>> dann ins HAMNET-Wiki hochladen.. So ist es für mich einfacher die
>> Standorte zu koordinieren und Netzlisten zu erstellen und auf einem
>> aktuellen Stand zu halten, um sie an den ANIR weiterreichen zu können..
>>
>> Die IP-Adressen der jeweiligen Standorte trage ich dann in die Listen
>> ein, sobald der jeweilige Standort aktiv wird.. Diese IP-Adressen
>> bleiben dann auch so zugeteilt, bis sie vom SysOp zurückgegeben werden..
>> Trotzdem sparsam mit den IPv4-Adressen umgehen.. Bei IPv6 ist es dann
>> trivial..
>>
>> Ach so, eine Sache noch, bevor sie mir wieder entfällt.. :-) DB0HGW
>> hängt dann im späteren Main-Backbone.. Dies bedeutet daß dort der
>> Haupt-Traffic fließen wird und deshalb die Hardware entsprechend
>> Leistungsfähig (schnelle Plattform und hohe Datenraten) sein muß und
>> stabil laufen sollte.. Dies trifft zwar eigentlich auf alle AP im
>> Backbone zu, aber im besonderen Maße auf den Main-Backbone.. Dieser
>> Main-Backbone ist auf der Karte rot eingefärbt.. Der redundante Backbone
>> ist für den Fall wichtig, falls mal ein HAMNET-Standort oder ein
>> Backbone-AP ausfällt; vielleicht ja der Backbone-AP bei DB0HGW für den
>> Link DB0HGW<->DB0HST?! ;-) Dann wäre von DB0NBB so kein durchkommen
>> mehr zu DB0HRO, wäre da nicht noch der redundante Backup-Backbone via
>> DO0MAL.. Der BackUp-Backbone ist auf der Karte blau eingefärbt.. Für den
>> Einstieg ins HAMNET durch die User kann auch günstige Hardware verbaut
>> werden.. Hier fließen für gewöhnlich nicht so viele Daten wie auf dem
>> Backbone, auf dem die Daten der einzelnen HAMNET-Standort gebündelt
>> übertragen werden..
>>
>> Ich hoffe ich habe mich einigermaßen Verständlich ausgedrückt, weil ja
>> doch einige Fachbegriffe auftauchen.. Trotzdem bemühte ich mich die
>> Anzahl an Fachausdrücken auf ein gesundes Maß zu reduzieren.. Aber
>> Fachausdrücke und gängige Abkürzungen vereinfachen die Verständlichkeit;
>> wenn man sie denn versteht.. Deswegen bitte ich um Re, wenn noch Fragen
>> offen geblieben sein sollten..
>>
>> Es freut mich, daß es nun mit HAMNET auch hier endlich losgeht und sich
>> einige OM's zusammengefunden haben einen Anfang zu machen.. Den
>> Grundstein dafür hatte ich schon vor Jahren mit der Beantragung des
>> Netzes und einigen Wochen der Netzplanung gemacht.. Ich hoffe, daß meine
>> Vorbereitungen gut durchdacht sind, um so schnell ein funktionierendes
>> und stabiles HAMNET aufbauen zu können.. Diese Ideen, die ich damals
>> hatte, habe ich gleich ins Wiki eingepflegt, welches mein Scratchboard
>> und Dokuablage zugleich war.. Nachdem ich die Netzplanung abgeschlossen
>> habe, mußte das ganze dann durch den Aufbau der HAMNET-Standorte nur
>> noch mit Leben gefüllt werden.. Nun ist es wohl soweit.. Eigentlich ist
>> es ja ganz einfach.. SysOps der HAMNET-Standorte schauen auf den Plan,
>> wohin Linkstrecken benötigt werden und versuchen zunächst testweise eine
>> Verbindung zum Nachbarn aufzubauen.. Wenn das klappt kommen die
>> Feinheiten (IP-Adresse vergeben lassen und Konfiguration anpassen).. So
>> war eigentlich der Plan von mir, daß SysOps eng mit der Wiki und dem
>> ARIR zusammenzuarbeiten..
>>
>> BTW: Es ist sehr von Vorteil, wenn sich die am HAMNET interessierten
>> OM's in die ML Distrikt V eintragen bzw. diese Liste abonieren.. So
>> werden Fragen schnell beantwortet und man bleibt über News auf den
>> Laufenden..
>>
>> http://www.amateurfunk-wiki.de/index.php/Links_Distrikt_V_Mecklenburg-Vorpommern
>>
>> http://www.amateurfunk-wiki.de/index.php/IP-Koordination_Distrikt_V_Mecklenburg-Vorpommern
>>
>> http://www.amateurfunk-wiki.de/index.php/DB0HGW
>> http://de.ampr.org/mailman/listinfo/hamnet_v/
>>
>>
>>
>> 73 de Bjørn, DL7RAY& SysOp DB0HRO& ARIR Distrikt V
>>
>>
>>
>>
>> Am 16.08.2012 19:37, schrieb Dirk:
>>> Hallo Bjørn,
>>>
>>> Ich bin der Sysop von DB0HGW und DB0OVP ( Greifswald).
>>> Du hattest mal vor knapp 2 Jahren eine Rundmail an die Sysop´s
>>> bezüglich HAMnet im Distrikt V geschrieben. Ich war damals QRL -
>>> bedingt sehr beschäftigt.
>>> Was ist aus dem Projekt geworden? Im Internet habe ich über die HAMnet
>>> - Entwicklung im Distrikt V nicht viel gefunden.
>>>
>>> Wir wollen im Greifswalder Raum jetzt auch am HAMnet bauen. Als erste
>>> Anwendungen sind D-Star und APRS in der Planung. Wie ist die sonstige
>>> Situation in MV?
>>>
>>> 73 Dirk
>>> DG0KF
>>>
>>>
>>>
>>>
>>>
>>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://de.ampr.org/pipermail/hamnet_v/attachments/20120827/8314a7b8/attachment-0001.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 262 bytes
Beschreibung: OpenPGP digital signature
URL : <http://de.ampr.org/pipermail/hamnet_v/attachments/20120827/8314a7b8/attachment-0001.pgp>
Mehr Informationen über die Mailingliste HamNet_V