![]() |
Linux für Amateurfunk
|
Packet-Radio ist ein Verfahren, Daten über Funk zu übertragen. Linux unterstützt als einziges Betriebssystem Packet-Radio bereits im Kernel.
Auch für die Leute, die das Kernel AX.25 nicht benutzen wollen (warum eigentlich nicht?) gibt es massig Unterstützung.
Inzwischen gibt es eine ganze Reihe von Programmen für das Kernel AX.25. Tatsächlich bilden Mailboxen unter Linux inzwischen das Rückgrat des deutschen Mailbox-Netzes, denn die wichtigsten Mailboxsysteme sind portiert:
Anwender dürften sich mehr dafür interessieren, daß es inzwischen auch Programme gibt, die komfortable AX.25-Verbindungen erlauben, ähnlich wie SP unter DOS oder WinGT unter Windows.
Für mich in diesem Bereich die "Killerapplikation": LinKT von Jochen Sarrazin DG6VJ. Ein Packet Radio Terminalprogramm für das X Window System und KDE, durchdacht, ohne überflüssige Spielereien aber mit genau den Features, die ich bei anderen Programmen unter Windows vermisse. Unverzichtbar für jeden "Packeteer"!
Die ax25-tools und ax25-apps enthalten:
Informationen zum Kernel AX.25 gibt es in den Linux-Kernel Sourcen (Verzeichnis Documentation/networking/), bei den ax25-tools und aus dem AX25-HOWTO von Terry Dawson.
Zum Beispiel:
Mehr Informationen gibt es im Verzeichneis der Amateurfunk-Applikationen für Linux.
Das Kernel AX.25 ist DAMA-fähig. In den 2.1.x-Kernels ist der Code recht massiv umstrukturiert worden. Der DAMA-Slave muß jetzt bei der Kernel-Konfiguration aktiviert werden, sonst wird er nicht mitkompiliert. Das Kernel-AX.25 erkennt bei kompiliertem DAMA-Slave auch nur dann selbständig, ob es sich um eine CSMA oder eine DAMA- Verbindung handelt, wenn er mit
echo "2" >/proc/sys/net/ax25/{device}/protocol
auch eingeschaltet wurde. Mit
echo 3600 </proc/net/ax25/{device}/dama_slave_timeoutkann der DAMA-Timeout eingestellt werden (hier auf 360 Sekunden).
Ein Problem bleibt jedoch noch, angeschlossene TNCs werden mit einem KISS-Kommando in den Vollduplex-Mode geschaltet. Zwar werten z8530drv und der 6pack-Treiber dieses Kommando aus, andere Treiber aber möglicherweise nicht. An einer Erweiterung der Kommunikation zwischen Kernel-AX.25 und Treiber wird gearbeitet.
Mit diesem Treiber können Einsteckkarten für Packet-Radio genutzt werden, die einen oder mehrere Z8530 chip(s) einsetzen. Eine solche SCC-Karte ist ein Mittelding zwischen TNC und "Simpel-MODEM". Im Gegensatz zum TNC fehlt der Mikrocontroller, dafür beschränken sich die Anpassungen für höhere Baudraten auf den Austausch des MODEMs und die Systemlast ist erheblich geringer als bei Verwendung der Ansteck-MODEMs (BayCom ser12 und par96). Der große Vorteil der SCC-Karten liegt in ihrer Multiport-Fähigkeit. Ein einzelner Z8530 kann schon zwei Funkkanäle bedienen, die meisten Karten setzen zwei oder mehr Chips ein. Ich meine, für Multiport-Betrieb gibt es nichts preisgünstigeres als eine (selbstgefädelte?) SCC-Karte.
Der aktuelle Z8530-Treiber (z8530drv-3.0) im Linux-Kernel ist ein reiner AX.25-Device Treiber, frühere Versionen emulierten noch einen TNC im KISS-Modus. Der Treiber ist geeignet für alle Z8530-Karten, bei denen sich die Control- und Datenports direkt ansprechen lassen und die keine besondere Interrupt-Behandlung brauchen. Getestete Karten sind:
Die PE1PET-Karte, ein OptoSCC-Nachbau, macht offenbar Probleme, vermutlich aufgrund eines unglücklichen Hardware-Designs. Das Problem scheint der verwendete Bustreiber zu sein, dessen Timing sich nicht mit jedem Z8530 verträgt. Diese Karte kann ich daher leider nicht empfehlen. Probleme können auch auftreten, wenn der Takt, mit dem die Z8530-Chips betrieben werden, Rundungsfehler bei der Berechnung der Teilerquotienten erzeugt. Viele Karten halten leider auch nicht die Timing-Spezifikationen ein. Leider halten sich auch einige Hersteller (SGS zum Beispiel) des Chips selbst nicht daran.
Die aktuelle Version des Treibers ist 3.0 und ist Teil des Linux-Kernels seit Kernel Version 2.2, zum Betrieb sind noch einige Utilities nötig:
Für alte Linux-Kernel (2.0.x) gibt es ein Update des Treibers, der auf jeden Fall eingesetzt werden sollte (erheblich geringere Systemlast, kleinere Fehler beseitigt):
(Sollte das File auf UCSD.EDU nicht im angegebenen Verzeichnis sein, versuche es mit ftp://ftp.ucsd.edu/hamradio/packet/tcpip/incoming/).
Die deutsche Dokumentation hängt leider hinterher, die englische Dokumentation ist aber halbwegs aktuell.
Dieser Treiber ist bereits Teil der Linux Kernels seit 2.0.32. Ich habe ihn geschrieben, um diese Funktion aus dem eigentlichen Kernel AX.25 auszulagern und damit eine Übertragung von in AX.25-Frames gekapselten IP-Datagrammen auch über Ethernet möglich ist. Auch Rxecho funktioniert jetzt. Ein paar Erweiterungen sind auch dazugekommen. Der Treiber kann beliebige Ethernet-Adressen als Ziel einsetzen und akzeptiert auf Wunsch nur Frames von einer bestimmten Ethernet-Karte. Die Konfiguration ist simpel: mit jedem neuen Ethernet-Device wird gleichzeitig ein neues Device angelegt (bpq#). Aktiviert wird das neue Interface durch
ifconfig bpq0 dl0xx.ampr.org hw ax25 dl0xxx
Normalerweise ist damit der Treiber konfiguriert: Er akzeptiert alle Ethernet AX.25 Frames und schickt eigene Frames an die Ethernet-Broadcastadresse FF:FF:FF:FF:FF:FF.
Mit
bpqparms bpq0 -a 00:80:AD:1A:F7:E6
hört der Treiber nur auf Frames von 00:80:AD:1A:F7:E6,
bpqparms bpq0 -d 00:80:AD:1B:05:26
führt dazu, daß Frames an die Adresse 00:80:AD:1B:05:26 verschickt werden. "axparms -d broadcast" setzt die Zieladresse wieder auf die Broadcast-Adresse FF:FF:FF:FF:FF:FF. Beide Optionen können natürlich gleichzeitig verwendet werden:
bpqparms bpq1 -a 00:80:AD:1B:05:26 -d 00:80:AD:1A:F7:E6
Dieses Kommando setzt das BPQ-Interface 1, also das zur zweiten Ethernetkarte gehörende Interface, auf Zieladresse 00:80:AD:1A:F7:E6 und akzeptiert nur Frames von 00:80:AD:1B:05:26. Achtung, bpq1 ist nicht unbedingt identisch mit eth1, die BPQ-Devices werden in der Reihenfolge angelegt, in der die Ethernet-Devices initialisiert werden. Die Zuordnung erhält man mit:
cat /proc/net/bpqether
Das Programm "bpqparms" ist Teil der AX.25-Utilities (ax25-tools-*.tar.gz).
Übrigens: "BPQether" steht für "G8BPQ Ethernet Encapsulation" für AX.25-Frames, ein Verfahren, das G8BPQ für seinen BPQNODE, einer NET/ROM-Implementierung für DOS, definiert hat.
Der AX.25 Route Daemon (ax25rtd) dient dazu, durch "Mitlesen" der AX.25-Frames auf einem Port die AX.25-Digipeaterpfade und ARP-Einträge zu lernen, nachdem dieses Feature aus dem Kernel AX.25 entfernt wurde. Er ist in den AX.25-Utilities enthalten und dort (etwas knapp) beschrieben. Inzwischen habe ich die weitere Entwicklung des Programms an Klaus Kudielka OE1KIB abgegeben.
Auch dieses Programm ist in den AX.25-Utilities enthalten. Es wird in ax25d.conf eingetragen und dient dazu, ein Shell-Login für AX.25-User bereitzustellen, ähnlich dem Verhalten von WAMPES. Im Unterschied zu WAMPES trägt Axspawn allerdings ein "unmögliches" Paßwort ("+") in /etc/passwd ein, so daß andere User nicht einfach mit "su" die Identität wechseln können. Das hat allerdings zur Folge, daß ein Login mit Telnet erst nach Setzen eines "richtigen" Paßwortes möglich ist. Ein anderes Problem ist, daß unterschiedliche Versionen von /bin/login unterschiedliche Ansichten über die Parameter haben, so daß es bei installiertem Shadow-Login zu Problemen kommt.
HINWEIS: Wie auch immer man es anfaßt: Das Unix-Paßwortsystem ist ein Sicherheitsrisiko, wenn die Übertragungsstrecke für jedermann mitlesbar ist. Man kann übrigens SSH dazu bringen, nicht zu verschlüsseln, so daß mit Hilfe der RSA-Authentisierung ein Login ohne Paßwörter möglich ist. Das ganze wird dann aber sowieso wieder durch User-Logins beim FTP zunichte gemacht, wo weiterhin Paßwörter unverschlüsselt übertragen werden.
Tux, the Linux penguin, created by Larry Lewing.