Suche im Katalog
Linux Netzwerker-Handbuch

Linux Netzwerker-Handbuch


Tony Bautts, Terry Dawson & Gregor N. Purdy
3. Auflage Juli 2005
ISBN 3-89721-414-8
382 Seiten
Weitere Informationen zur gedruckten Version des Buches finden Sie unter:
www.oreilly.de/catalog/linag3ger/

Zur Übersicht aller OpenBooks


TOC PREV NEXT INDEX

Kapitel 3

Konfiguration der seriellen Hardware

Das Internet wächst mit geradezu unglaublicher Geschwindigkeit. Das liegt wohl hauptsächlich an den vielen Internet-Benutzern, die über einen preiswerten und einfachen Zugang zu DSL-, Kabel- und anderen schnellen Netzwerkverbindungen verfügen und Protokolle wie PPP benutzen, um sich bei einem Netzwerkanbieter einzuwählen und sich die tägliche Dosis E-Mail und News abzuholen.

Dieses Kapitel soll all denjenigen helfen, die ihre Netzwerkverbindung mit Hilfe von Modems realisieren. Wir gehen allerdings nicht näher darauf ein, wie Ihr Modem konfiguriert werden muss, da Sie dazu ausführliche Informationen in vielen der verfügbaren HOWTO-Dokumente im Web finden. Wir behandeln nur die wesentlichen Linux-spezifischen Aspekte, die die Steuerung von Geräten an den seriellen Ports betreffen. Dazu gehören serielle Kommunikationssoftware, die Erzeugung der seriellen Gerätedateien, serielle Hardware sowie die Konfiguration der seriellen Geräte mit den dafür vorgesehenen Befehlen setserial und stty. Viele andere Themenbereiche werden im Serial-HOWTO von David Lawyer behandelt.

Kommunikationssoftware für Modemverbindungen

Für Linux gibt es eine ganze Reihe von Kommunikationsprogrammen. Viele von ihnen sind einfache Terminal-Programme, die es dem Benutzer ermöglichen, sich in einen anderen Computer einzuwählen, so als würde er vor einem ganz gewöhnlichen Terminal sitzen. Das traditionelle Terminal-Programm für Unix-artige Umgebungen ist kermit. Dieses Programm ist allerdings schon fast als antik zu betrachten und würde vielen Benutzern heute möglicherweise einige Schwierigkeiten bei der Bedienung bereiten. Es gibt wesentlich komfortablere Programme, die Telefonnummernverzeichnisse, Skriptsprachen zum automatischen Wählen und Einloggen in andere Systeme und eine Vielzahl von Dateiaustauschprotokollen unterstützen. Eines dieser Programme ist minicom, das einem der beliebtesten DOS-Terminal-Programme nachempfunden ist. Auch an X11-Benutzer wurde gedacht; für sie gibt es beispielsweise das Programm seyon.

Terminal-Programme sind nicht die einzigen verfügbaren Programme zur seriellen Kommunikation. Andere Programme erlauben es Ihnen, eine Verbindung zu einem Host herzustellen und E-Mails in einem einzigen Paket herunterzuladen, damit Sie sie später nach Belieben lesen und beantworten können. Das spart eine Menge Zeit und bietet sich vor allem dann an, wenn Sie eine Netzanbindung haben, die nach Zeit abgerechnet wird. Sie lesen und beantworten die Nachrichten ganz einfach offline. Wenn Sie damit fertig sind, stellen Sie erneut eine Verbindung her und laden Ihre Antworten wieder in einem einzigen Paket hoch.

PPP liegt irgendwo dazwischen, da es sowohl interaktive als auch nicht-interaktive Anwendungen zulässt. Viele benutzen PPP zur Einwahl in ihr Universitätsnetzwerk oder einen anderen Internet Service Provider, um auf das Internet zuzugreifen. PPP (in der Form PPPoE) wird jedoch häufig auch über permanente oder semipermanente Verbindungen wie Kabel- oder DSL-Modems verwendet. Wir werden uns in Kapitel 7 mit PPPoE befassen.

Einführung in serielle Geräte

Der Unix-Kernel stellt Geräte für den Zugriff auf die serielle Hardware bereit. Diese werden üblicherweise als tty-Geräte bezeichnet (sprich: Ti-Ti-Wai).

Das ist eine Abkürzung für Teletype, den wichtigsten Hersteller von Terminals in den Anfangstagen von Unix. Der Begriff wird heute für alle zeichenorientierten Datenterminals benutzt. In diesem Kapitel werden wir ihn ausschließlich verwenden, um uns auf die Linux-Gerätedateien zu beziehen und nicht auf ein physisches Terminal.

Linux unterscheidet drei Klassen von tty-Geräten: serielle Geräte, virtuelle Terminals (die alle durch Drücken der Tastenkombinationen Alt-F1 bis Alt-Fnn an der lokalen Konsole erreichbar sind) und Pseudo-Terminals (ähnlich einer bidirektionalen Pipe, die von Anwendungen wie X11 verwendet wird). Bei Ersteren handelt es sich um tty-Geräte, weil die ursprünglichen zeichenbasierten Terminals über ein serielles Kabel oder eine Telefonleitung und ein Modem an die Unix-Maschine angeschlossen waren. Die beiden anderen zählen ebenfalls zu den tty-Geräten, da sie sich aus Sicht eines Programmierers ähnlich wie diese verhalten.

PPP wird üblicherweise im Kernel implementiert. Der Kernel behandelt das tty-Gerät nicht wie ein gewöhnliches Netzwerkgerät, das Sie wie eine Ethernet-Karte mit Befehlen wie ifconfig manipulieren können. Er sieht sie vielmehr als Stellen an, an die Netzwerkgeräte gebunden werden können. Dazu verändert der Kernel den Verbindungsmodus (line discipline) des tty-Geräts. PPP ist ein Verbindungsmodus, der für tty-Geräte festgelegt werden kann. Der Zweck des Verbindungsmodus besteht darin, dass der serielle Treiber die empfangenen Daten unterschiedlich handhaben soll, je nachdem, welcher Verbindungsmodus gerade aktiviert ist. Im normalen Verbindungsmodus reicht der Treiber einfach jedes empfangene Zeichen weiter. Wenn der Verbindungsmodus PPP ausgewählt ist, liest der Treiber stattdessen einen Datenblock, versieht diesen mit einem besonderen Header, über den die Gegenstelle diesen Block in einem Datenstrom identifizieren kann, und überträgt den neuen Datenblock. Sie müssen sich über die Einzelheiten jetzt keine Gedanken machen; wir beschäftigen uns später mit PPP, und außerdem geschieht das Ganze sowieso automatisch.

Auf serielle Geräte zugreifen

Wie auf alle Geräte in einem Unix-System greifen Sie auch auf serielle Geräte über spezielle Dateien im Verzeichnis /dev zu. Es gibt zwei Arten von Gerätedateien, die mit seriellen Treibern zu tun haben, und für jeden Port gibt es jeweils eine Gerätedatei von jedem Typ. Abhängig von der Datei, über die Sie darauf zugreifen, wird sich das Gerät unterschiedlich verhalten. Wir gehen auf die Unterschiede etwas ausführlicher ein, damit Sie einige besondere Konfigurationsdetails serieller Geräte besser verstehen. In der Praxis werden Sie es allerdings nur mit einer Art von Gerätedateien zu tun bekommen, und in Zukunft könnte eine der beiden Gerätedateien sogar komplett verschwinden.

Die wichtigste der beiden Klassen serieller Geräte hat die Major Number 4. Ihre Gerätedateien haben die Bezeichnung ttyS0, ttyS1 usw. Die zweite Art hat die Major Number 5, ist für Dialout-Anwendungen über die Ports vorgesehen und verwendet die Gerätedateien cua0, cua1 usw. In der Unix-Welt beginnt jede Zählung immer mit null, während Laien dazu tendieren, mit eins zu beginnen. Diese Zählweise verwirrt einige Leute, weil COM1: der Gerätedatei /dev/ttyS0 entspricht, COM2: entsprechend /dev/ttyS1 usw. Jeder, der sich etwas mit PC-Hardware auskennt, weiß, dass die anderen Schnittstellen wie COM3: und höher nie richtig standardisiert wurden.

Die cua- oder »Callout«-Geräte wurden geschaffen, um Konflikte bei seriellen Geräten für Modems zu vermeiden, die sowohl eingehende als auch ausgehende Verbindungen unterstützen müssen. Unglücklicherweise haben sich diese Geräte inzwischen selbst als problematisch erwiesen und werden vermutlich nicht mehr weiterentwickelt. Das Problem ist folgendes:

Linux gestattet es (wie Unix auch), eine (Geräte-)Datei von mehreren Prozessen gleichzeitig öffnen zu lassen. Diese an sich sehr nützliche Sache ist für tty-Geräte allerdings überhaupt nicht sinnvoll, da es passieren kann, dass sich dort mehrere Prozesse gegenseitig in die Quere kommen. Zum Glück hat sich jemand einen Mechanismus ausgedacht, der es einem Prozess ermöglicht, vor dem Öffnen einer Gerätedatei festzustellen, ob diese Datei schon von einem anderen Prozess belegt wurde. Dieser Mechanismus verwendet so genannte Sperrdateien (lock files) und funktioniert so: Will ein Prozess ein tty-Gerät öffnen, prüft er zunächst, ob es eine besondere Datei (die Sperrdatei) gibt, die dem Namen der Gerätedatei ähnelt ist. Existiert eine solche Datei, nimmt der Prozess an, dass das gewünschte Gerät von einem anderen Prozess benutzt wird. Wenn die Datei dagegen nicht existiert, geht der Prozess davon aus, dass das Gerät frei ist, erzeugt dann selbst eine Sperrdatei und reserviert das tty-Gerät für sich. Es gibt noch einen letzten cleveren Trick, damit die Verwaltung von Sperrdateien funktioniert. Die PID des Prozesses, der diese Datei angelegt hat, wird in die Datei selbst geschrieben. Darauf gehen wir gleich näher ein.

Der Sperrdatei-Mechanismus funktioniert perfekt in Systemumgebungen, in denen es ein eindeutiges Verzeichnis für alle Sperrdateien gibt und alle Programme wissen, wo sich dieses Verzeichnis befindet. Bei Linux war das lange Zeit nicht so. Erst seit der offiziellen Einführung des Linux Filesystem Standard (FSSTND) funktioniert der Sperrdatei-Mechanismus für tty-Geräte in Linux störungsfrei. Vorher gab es in manchen Linux-Distributionen phasenweise sogar vier (wenn nicht noch mehr) verschiedene Verzeichnisse für Sperrdateien: /usr/spool/locks/, /var/spool/locks/, /var/lock/ und /usr/lock/. Es ist klar, dass bei einer solchen Konfusion nur Chaos entstehen konnte. Verschiedene Programme öffneten an verschiedenen Stellen gleichzeitig Sperrdateien, die eigentlich zur exklusiven Kontrolle einzelner tty-Geräte gedacht waren. Solche Sperrdateien waren dann natürlich nutzlos.

Um einen Ausweg aus diesem Dilemma zu finden, wurden die cua-Geräte eingeführt. Diese Gerätedateien verwendeten keine Sperrdateien mehr, um die Konflikte zwischen Programmen beim Zugriff auf serielle Geräte zu lösen, sondern überließen die Entscheidung über die Freigabe der Geräte dem Kernel. Immer wenn ein ttyS-Gerät bereits geöffnet war, sollte ein Versuch, das zugehörige cua-Gerät zu öffnen, einen Fehler erzeugen, der das öffnende Programm darauf hinwies, dass das Gerät bereits belegt war. Im umgekehrten Fall, wenn also das cua-Gerät bereits geöffnet war und ein Versuch unternommen wurde, das ttyS-Gerät zu öffnen, sollte kein Fehler erzeugt, sondern lediglich die Anfrage blockiert werden, d.h., der öffnende Prozess musste dann so lange warten, bis das cua-Gerät vom anderen Prozess wieder geschlossen wurde. Dieses Verfahren funktioniert ganz gut, wenn man nur ein einzelnes Modem hat, das die meiste Zeit im Dialin-Modus arbeitet, und nur ab und zu ein Dialout über das gleiche Gerät ausführt. In Umgebungen, in denen mehrere Programme gleichzeitig ablaufen, die dasselbe Gerät zum Dialout nutzen wollen, funktioniert die Sache leider nicht. Dazu müssten wieder Sperrdateien verwendet werden und wir wären genauso schlau wie vorher!

Erst mit der Einführung des Linux Filesystem Standard kam das rettende Ufer in Sicht. Er legt fest, dass grundsätzlich Sperrdateien verwendet werden und diese im Verzeichnis /var/lock abgelegt werden. Per Konvention haben die Namen aller Sperrdateien ein besonderes Format. So trägt beispielsweise die Sperrdatei für das ttyS1-Gerät den Namen LCK..ttyS1. Die Sperrdateien für cua-Geräte sollten auch in diesem Verzeichnis gespeichert werden, allerdings wird von der Verwendung dieser Geräte abgeraten.

Die cua-Geräte werden eventuell noch eine Zeit lang unterstützt, um Rückwärtskompatibilität zu gewährleisten, mit der Zeit werden sie jedoch an Bedeutung verlieren. Falls Sie sich nicht sicher sind, verwenden Sie grundsätzlich nur ttyS-Geräte. Stellen Sie außerdem sicher, dass Ihr System auch wirklich den Linux-FSSTND verwendet. Zumindest sollten alle Programme, die serielle Geräte verwenden, ihre Sperrdateien in einem einzigen besonderen Verzeichnis ablegen. Die meisten Programme, die mit tty-Geräten zu tun haben, bieten die Möglichkeit, bei der Übersetzung ihrer Quelldateien das Sperrverzeichnis mit einer speziellen Compiler-Option festzulegen. In manchen Fällen kann man dieses Verzeichnis auch in einer Variable namens LOCKDIR im Makefile oder in einer Konfigurations-Header-Datei angeben. Wenn Sie Ihre Software selbst übersetzen, ist es am besten, wenn Sie sich genau an den FSSTND halten. Bei vorkompilierten Binärpaketen, von denen Sie nicht wissen, wo sie die Sperrdateien ablegen, können Sie das wie folgt herausfinden:

strings binärdatei | grep lock

Stimmt das angezeigte Verzeichnis nicht mit dem Rest Ihres Systems überein, können Sie sich immer noch mit einem Trick behelfen. Versuchen Sie einfach, einen symbolischen Link vom Verzeichnis, das vom Binärprogramm favorisiert wird, zum Standardverzeichnis /var/lock/ anzulegen. Das ist zwar nicht besonders elegant, aber es funktioniert.

Spezialdateien für serielle Geräte

Die Minor Numbers sind für die beiden seriellen Geräteklassen gleich. Wenn Sie an einem der Ports COM1: bis COM4: ein Modem angeschlossen haben, ist seine Minor Number die Nummer des COM-Ports plus 63. Wenn Sie eine andere Art von Hardware verwenden, zum Beispiel eine leistungsfähige Multiport-Karte, kann es passieren, dass sie nicht mit den vorhandenen Standardtreibern funktioniert, sondern spezielle Gerätedateien benötigt. Wie man solche Gerätedateien prinzipiell erzeugt, können Sie im Serial HOWTO nachlesen.

Nehmen wir an, Ihr Modem sei an COM2: angeschlossen. Dann ist seine Minor Number 65, und die Major Number ist 4. Es sollte ein Gerät namens ttyS1 geben, das diese Gerätenummern trägt. Wenn Sie die seriellen ttys im Verzeichnis /dev/ auflisten, finden Sie die Major und Minor Numbers in den Spalten 5 und 6:

$ ls -l /dev/ttyS*

0 crw-rw---- 1 uucp dialout 4, 64 Oct 13 1997 /dev/ttyS0
0 crw-rw---- 1 uucp dialout 4, 65 Jan 26 21:55 /dev/ttyS1
0 crw-rw---- 1 uucp dialout 4, 66 Oct 13 1997 /dev/ttyS2
0 crw-rw---- 1 uucp dialout 4, 67 Oct 13 1997 /dev/ttyS3

Wenn es kein Gerät mit der Major Number 4 und der Minor Number 65 gibt, müssen Sie eins einrichten. Melden Sie sich als Superuser an und geben Sie diese Befehle ein:

# mknod -m 666 /dev/ttyS1 c 4 65
# chown uucp.dialout /dev/ttyS1

In den verschiedenen Linux-Distributionen werden die Eigentumsrechte an den seriellen Geräten leicht unterschiedlich gehandhabt. Manchmal ist root als Eigentümer vorgesehen, manchmal gehören sie einem anderen Benutzer. Die meisten Distributionen haben eine Gruppe, die speziell für Dialout-Geräte gedacht ist. Alle Benutzer, denen es erlaubt ist, diese Geräte zu verwenden, werden in diese Gruppe eingetragen.

Manche Leute empfehlen, einen symbolischen Link namens /dev/modem einzurichten, der auf Ihr Modem zeigt, damit eher ungeübte Benutzer sich nicht den ein wenig sperrigen Namen ttyS1 merken müssen. Sie können dann allerdings nicht in einem Programm modem und in einem anderen den echten Gerätenamen verwenden, da sonst die Sperrdateien unterschiedliche Namen bekommen und der Sperrmechanismus nicht mehr funktioniert.

Serielle Hardware

RS-232 ist der derzeit am weitesten verbreitete Standard für serielle Geräte in der PC-Welt. Er verwendet eine Reihe von Schaltkreisen zur Übertragung der einzelnen Bits und zur Synchronisation. Weitere Leitungen können dafür benutzt werden, um das Anliegen eines Trägersignals zu signalisieren (bei Modems), sowie für den Handshake. Linux unterstützt eine breite Palette an seriellen Karten, die nach dem Standard RS-232 funktionieren.

Obwohl der Hardware-Handshake vom Standard nicht vorgeschrieben wird, ist er doch sehr nützlich. Er erlaubt jeder der beiden Stationen, der jeweils anderen mitzuteilen, ob weitere Daten empfangen werden können oder ob die Gegenstelle eine Pause einlegen sollte, bis der Empfänger die vorliegenden Daten verarbeitet hat. Die hierfür verwendeten Steuerleitungen heißen Clear to Send (CTS) bzw. Request to Send (RTS), woraus sich auch der umgangssprachliche Name RTS/CTS für den Hardware-Handshake ableitet.

Die andere Art von Handshake, die Ihnen vermutlich geläufig sein wird, ist XON/XOFF. Dabei werden zwei besondere Zeichen, normalerweise Strg-S bzw. Strg-Q, dazu verwendet, um der Gegenstelle mitzuteilen, dass sie ihre Datenübertragung beenden bzw. fortsetzen soll. Während diese Methode sehr einfach zu implementieren und für einfache Terminals recht nützlich ist, erweist sie sich für die Übertragung binärer Daten als sehr problematisch, da die beiden Sonderzeichen bei der Übertragung nicht als gewöhnliche Bytes aufgefasst, sondern immer als Steuerzeichen interpretiert werden. Außerdem ist es langsamer als der saubere und schnelle Hardware-Handshake, weshalb Letzterer gegenüber XON/XOFF immer den Vorzug bekommen sollte.

Im ursprünglichen IBM-PC wurde die RS-232-Schnittstelle durch einen UART-Chip vom Typ 8250 angesteuert. Seit den Zeiten der 486er-Prozessoren verwendeten die PCs zumeist einen 16450, der etwas schneller als der 8250 war. Fast alle Pentium-Maschinen wurden mit einer noch moderneren Variante, dem 16550, ausgestattet. Einige Marken (besonders interne Modems mit Rockwell-Chips) verwenden dagegen völlig andere Chips, die aber das Verhalten der 16550er emulieren und daher fast genauso behandelt werden können. All diese Chips werden von Linux in dessen Standard-Serial-Port-Treiber unterstützt.1

Gegenüber dem 8250er und dem 16450er stellt der 16550er eine deutliche Verbesserung dar, da er über einen 16 Byte großen FIFO-Puffer verfügt. Beim 16550 handelt es sich eigentlich um eine ganze Familie von UART-Geräten. Dazu gehören unter anderem der 16650, 16550A und 16550AFN (später als PC16550DN bezeichnet). Die Unterschiede zwischen diesen Chips liegen darin, ob die eingesetzten FIFOs tatsächlich funktionieren. Unter den genannten Chips ist der 16550AFN die sicherste Variante. Es gab auch einmal einen NS16550; dessen FIFO hat aber nie wirklich funktioniert.

Die UARTs 8250 und 16450 besaßen nur einen einfachen 1-Byte-Puffer. Ein 16450 löste daher für jedes zu übertragende Zeichen eine Unterbrechung (Interrupt) aus. Jeder Interrupt benötigt eine gewisse Zeit, in der er verarbeitet wird. Diese kurze Verzögerung begrenzt die maximale zuverlässige Datenübertragungsrate des 16450 auf einem ISA-Bus-Rechner auf ungefähr 9.600 bps.

In der voreingestellten Konfiguration überprüft der Kernel die Standardports COM1: bis COM4:. Der Kernel ist auch in der Lage, die UARTs an den Standardports automatisch zu erkennen. Wird dabei ein 16550 entdeckt, macht Linux vom erweiterten FIFO-Puffer Gebrauch.

Hilfsmittel zur Konfiguration

Nun befassen wir uns mit den beiden nützlichsten Konfigurationshilfsmitteln für serielle Geräte: setserial und stty.

Der Befehl setserial

Der Kernel gibt sich alle Mühe, selbst herauszufinden, wie Ihre serielle Hardware für einen reibungslosen Betrieb konfiguriert werden muss. Das ist wegen der Vielzahl unterschiedlicher Konfigurationen serieller Geräte aber ein schwieriges Unterfangen. Wo die Probleme liegen, hatten wir bereits bei den internen Modems kurz besprochen. Sie verwenden zwar einen UART mit 16-Byte-Puffer, der Gerätetreiber im Kernel meint aber, er hätte es nur mit einem 16450 zu tun. Wenn er nicht ausdrücklich darüber informiert wird, dass es sich um einen 16550 handelt, wird der Kernel vom erweiterten Puffer keinen Gebrauch machen. Ein anderes Beispiel sind die einfachen 4-Port-Karten, die IRQ-Sharing unterstützen, d.h., alle seriellen Geräte können sich einen Interrupt teilen. In diesem Fall muss der Kernel ausdrücklich darüber informiert werden, welcher Interrupt genutzt werden soll und dass Interrupts mehrfach genutzt werden können.

Mit dem Befehl setserial können serielle Treiber zur Laufzeit des Systems konfiguriert werden. Normalerweise wird er während des Bootens von einem Skript namens rc.serial aus gestartet. In einigen Distributionen kann der Name des Skripts auch anders lauten. Dieses Skript ist dafür verantwortlich, den seriellen Gerätetreiber so zu initialisieren, dass er mit allen angeschlossenen seriellen Geräten zurechtkommt, die nicht dem üblichen Standard entsprechen.

Die allgemeine Syntax für den Befehl setserial lautet

setserial gerät [parameter]

wobei gerät ein serielles Gerät ist, etwa ttyS0.

Der Befehl setserial weist viele Parameter auf. Die gebräuchlichsten sind in Tabelle 3-1 beschrieben. Informationen zu den anderen Parametern finden Sie in der Manpage von setserial.

Tabelle 3-1
setserial-Kommandozeilenparameter 
Parameter
Beschreibung
port portnummer
Gibt die I/O-Portadresse des seriellen Geräts an. Portnummern müssen in hexadezimaler Schreibweise angegeben werden, z.B. 0x2f8.
irq num
Gibt die Nummer des Interrupts an, den das serielle Gerät verwendet.
uart uart-typ
Gibt den UART-Typ des seriellen Geräts an. Gebräuchliche Werte sind 16450, 16550 usw. Ein Wert von none schaltet dieses serielle Gerät ab.
fourport
Die Angabe dieses Parameters teilt dem seriellen Kernel-Treiber mit, dass sich dieser Port an einer AST-Fourport-Karte befindet.
spd_hi
Programmiert den UART auf eine Geschwindigkeit von 57,6 Kbps, wenn ein Prozess 38,4 Kbps verlangt.
spd_vhi
Programmiert den UART auf eine Geschwindigkeit von 115 Kbps, wenn ein Prozess 38,4 Kbps verlangt.
spd_normal
Programmiert den UART auf die Standardgeschwindigkeit von 38,4 Kbps, wenn eine Anfrage vorliegt. Dieser Parameter bewirkt die Umkehrung des Effekts von spd_hi oder spd_vhi, das auf dem angegebenen seriellen Gerät vollzogen wird.
auto_irq
Dieser Parameter veranlasst den Kernel, den IRQ des angegebenen Geräts automatisch zu ermitteln. Dieser Versuch kann auch fehlschlagen, weshalb es sich hierbei eher darum handelt, dass der Kernel den IRQ errät. Falls Sie den IRQ des Geräts kennen, sollten Sie stattdessen den Parameter irq verwenden.
autoconfig
Dieser Parameter muss immer in Verbindung mit dem port-Parameter angegeben werden. Ist dieser Parameter vorhanden, veranlasst setserial den Kernel, automatisch den UART-Typ an der angegebenen Portadresse zu ermitteln. Ist auch auto_irq angegeben, versucht der Kernel außerdem, automatisch den IRQ herauszufinden.
skip_test
Dieser Parameter veranlasst den Kernel, auf den UART-Typ-Test während der automatischen Konfiguration zu verzichten. Das ist insbesondere dann notwendig, wenn der UART vom Kernel nicht korrekt erkannt wird.

Eine typische und einfache rc-Datei zum Konfigurieren Ihrer seriellen Ports beim Booten könnte etwa so aussehen wie in Beispiel 3-1. Bei den meisten Linux-Distributionen wird ein solches Beispiel etwas ausführlicher gestaltet sein.

Beispiel 3-1
rc.serial-Datei mit setserial-Befehlen 
# /etc/rc.serial - Konfigurationsskript für die serielle Leitung.
#
# Konfiguration der seriellen Geräte
/sbin/setserial /dev/ttyS0 auto_irq skip_test autoconfig
/sbin/setserial /dev/ttyS1 auto_irq skip_test autoconfig
/sbin/setserial /dev/ttyS2 auto_irq skip_test autoconfig
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
#
# Anzeige der Konfiguration der seriellen Geräte
/sbin/setserial -bg /dev/ttyS*

Das Argument -bg /dev/ttyS* im letzten Befehl gibt eine hübsch formatierte Zusammenfassung der Hardware-Konfiguration aller aktiven seriellen Geräte aus. Diese Ausgabe sieht etwa wie Beispiel 3-2 aus.

Beispiel 3-2
Ausgabe des Befehls setserial -bg /dev/ttyS 
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A

Der Befehl stty

Der Name stty bedeutet wahrscheinlich »set tty« (Setze tty), der Befehl stty kann aber auch dazu benutzt werden, um die Konfiguration eines Terminals anzuzeigen. Verglichen mit setserial, bietet der Befehl stty vielleicht eine noch verwirrendere Anzahl an Konfigurationsmöglichkeiten. Die wichtigsten davon werden wir gleich besprechen, die anderen können Sie in der Manpage zu stty nachlesen.

Der stty-Befehl wird meist dazu verwendet, um Terminal-Parameter zu konfigurieren, etwa ob Zeichen zurückgesandt (echo) werden sollen oder welche Taste ein Abbruchsignal erzeugen soll. Wir hatten bereits früher erwähnt, dass serielle Geräte tty-Geräte sind und der stty-Befehl daher auch für sie geeignet ist.

Eine der wichtigsten Anwendungen von stty für serielle Geräte ist die Aktivierung des Hardware-Handshakes auf dem Gerät. Wir haben uns bereits mit Hardware-Handshakes befasst. In der Standardkonfiguration für serielle Geräte sind Hardware-Handshakes deaktiviert. Diese Einstellung ermöglicht das Arbeiten mit dreiadrigen seriellen Kabeln; sie unterstützen die für Hardware-Handshakes notwendigen Signale nicht. Wären Hardware-Handshakes standardmäßig aktiviert, dann könnten über das Kabel keine Zeichen übertragen werden.

Überraschenderweise gibt es Programme zur seriellen Kommunikation, die Hardware-Handshakes nicht aktivieren. Falls Ihr Modem Hardware-Handshakes unterstützt, sollten Sie Ihr Modem so konfigurieren, dass es sie auch benutzt (die entsprechenden Befehle finden Sie im Handbuch Ihres Modems), und auch das serielle Gerät dementsprechend einstellen. Der Befehl stty kennt ein crtscts-Flag, das Hardware-Handshakes auf einem Gerät aktiviert; Sie werden dieses Flag benutzen müssen. Am besten wird der Befehl wahrscheinlich aus der Datei rc.serial (oder einem Äquivalent) heraus beim Booten aufgerufen. Dazu verwenden Sie Befehle wie in Beispiel 3-3.

Beispiel 3-3
stty-Befehle in der Datei rc.serial 
#
stty crtscts < /dev/ttyS0
stty crtscts < /dev/ttyS1
stty crtscts < /dev/ttyS2
stty crtscts < /dev/ttyS3
#

Der stty-Befehl arbeitet standardmäßig immer mit dem aktuellen Terminal. Durch die Eingabeumleitung (<) kann man aber jedes tty-Gerät mit stty manipulieren. Es kommt häufig vor, dass man vergisst, wann man < oder > anzuwenden hat. Moderne Varianten des stty-Befehls haben in dieser Hinsicht eine viel übersichtlichere Syntax. Um das zu zeigen, formulieren wir unser Konfigurationsbeispiel etwas um. Das Ergebnis sehen Sie in Beispiel 3-4.

Beispiel 3-4
stty-Befehle mit moderner Syntax in der Datei rc.serial  
#
stty crtscts -F /dev/ttyS0
stty crtscts -F /dev/ttyS1
stty crtscts -F /dev/ttyS2
stty crtscts -F /dev/ttyS3
#

Wir erwähnten bereits, dass stty auch dazu verwendet werden kann, um die aktuelle Terminal-Konfiguration eines tty-Geräts anzuzeigen. Um sich alle aktiven Einstellungen eines tty-Geräts anzusehen, gehen Sie folgendermaßen vor:

$ stty -a -F /dev/ttyS1

Die Ausgabe dieses Befehls, die Sie in Beispiel 3-5 sehen, liefert Ihnen den Zustand aller Flags für dieses Gerät. Steht vor einem Flag ein Minuszeichen, wie etwa bei -crtscts, dann ist dieses Flag deaktiviert.

  
Beispiel 3-5
Ausgabe des Befehls stty -a  
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

Eine Beschreibung der wichtigsten Flags finden Sie in Tabelle 3-2. Ohne Minuszeichen wird ein Flag in einer stty-Anweisung immer aktiviert, mit Minuszeichen deaktiviert. Um z. B. den Hardware-Handshake am Gerät ttyS0 abzuschalten, geben Sie Folgendes ein:

$ stty -crtscts -F /dev/ttyS0
Tabelle 3-2
Die wichtigsten stty-Flags zur Konfiguration serieller Geräte 
Flags
Beschreibung
N
Setzt die Übertragungsgeschwindigkeit auf N Bits pro Sekunde.
crtsdts
Aktiviert/deaktiviert Hardware-Handshakes.
ixon
Aktiviert/deaktiviert XON/XOFF.
clocal
Aktiviert/deaktiviert Modem-Steuersignale wie DTR/DTS und DCD. Das ist erforderlich, falls Sie ein dreiadriges serielles Kabel verwenden, da es diese Signale nicht übermittelt.
cs5 cs6 cs7 cs8
Setzt die Anzahl der Datenbits auf 5, 6, 7 bzw. 8.
parodd
Aktiviert ungerade Parität. Durch Deaktivieren dieses Flags wird gerade Parität aktiviert.
parenb
Aktiviert einen Paritätstest. Wenn dieses Flag negiert ist, wird keine Parität verwendet.
cstopb
Aktiviert die Benutzung von zwei Stoppbits pro Zeichen. Bei negiertem Flag wird nur ein Stoppbit pro Zeichen benutzt.
echo
Aktiviert/deaktiviert die Rücksendung des empfangenen Zeichens (»Echo«) zum Sender.

Das nächste Beispiel kombiniert einige dieser Flags und setzt das ttyS0-Gerät auf 19.200 bps, 8 Datenbits, keine Parität, Hardware-Handshake und deaktiviertes Echo:

$ stty 19200 cs8 -parenb crtscts -echo -F /dev/ttyS0

Serielle Geräte und die Eingabeaufforderung login:

Früher war es üblich, dass eine Unix-Installation aus einem einzigen Server mit vielen zeichenbasierten, »dummen« Terminals oder Dialup-Modems bestand. Solche Konstellationen wählt man heutzutage allerdings kaum noch. Dass diese »dummen« Terminals mittlerweile zu Spottpreisen erhältlich sind, macht die Sache gerade für solche Leute interessant, die sich ein Unix-System in der genannten Konstellation zusammenstellen wollen. Konfigurationen von Dialup-Modems sind heute nicht weniger verbreitet, allerdings werden sie heutzutage eher zum Einloggen in PPP-Systeme verwendet (siehe Kapitel 6) als für einfache Logins. Nichtsdestotrotz kann man in beiden Konfigurationen ein einfaches getty-Programm verwenden.

Das Wort getty setzt sich vermutlich aus »get tty« zusammen. Ein getty-Programm öffnet ein serielles Gerät, führt an ihm (und am eventuell vorhandenen Modem) eine passende Konfiguration durch und wartet schließlich, bis eine Verbindung zustande kommt. Eine aktive Verbindung am seriellen Gerät wird normalerweise am DCD-Pin (Data Carrier Detect) erkannt. Unmittelbar nach dem Verbindungsaufbau gibt das getty-Programm eine login:-Eingabeaufforderung aus, ruft das Login-Programm des Systems auf und übergibt ihm die Kontrolle. Unter Linux ist für jedes virtuelle Terminal (z. B. /dev/tty1) ein eigener getty-Prozess zuständig.

Es gibt eine ganze Reihe unterschiedlicher Implementierungen von getty. Jede hat gegenüber einer anderen gewisse Vorzüge. Der getty-Befehl, den wir hier näher betrachten, wird mgetty genannt. Er ist relativ populär, da er gerade für Modems eine ganze Menge von Eigenschaften enthält, z. B. Unterstützung von automatischen Faxprogrammen und Voice-Modems. Wir konzentrieren uns hier nur darauf, wie man mgetty für gewöhnliche Datenabrufe konfiguriert. Die Betrachtung weiterer Details überlassen wir gerne Ihrem Forscherdrang.

Konfiguration des mgetty-Dämons

Der mgetty-Dämon ist in nahezu allen Linux-Distributionen in vorkonfigurierter Form enthalten. Er unterscheidet sich von den meisten anderen getty-Implementierungen dahin gehend, dass er speziell für Modems mit dem AT-Befehlssatz (Hayes-kompatible Modems) gedacht ist.

Er unterstützt zwar auch direkte Terminal-Verbindungen, eignet sich aber am besten für Dialup-Anwendungen. Er verwendet zur Erkennung eines eingehenden Anrufs nicht die DCD-Leitung, sondern achtet auf die RING-Nachricht moderner Modems, die bei eingehenden Anrufen ausgelöst wird, sofern sie nicht auf automatische Anrufbeantwortung eingestellt sind.

Das ausführbare Programm heißt /usr/sbin/mgetty, seine Hauptkonfigurationsdatei ist /etc/mgetty/mgetty.config. Es gibt noch eine Reihe weiterer Programme und Konfigurationsdateien für die anderen Funktionen von mgetty.

Um mgetty automatisch zu starten, braucht man in den meisten Installationen für die Konfiguration nur einige Änderungen in der Datei /etc/mgetty/mgetty.config vorzunehmen und einige passende Einträge in der Datei /etc/inittab hinzuzufügen.

Beispiel 3-6 zeigt eine sehr einfache mgetty-Konfigurationsdatei. In diesem Beispiel werden zwei serielle Geräte konfiguriert. Das erste, /dev/ttyS0, unterstützt ein Hayes-kompatibles Modem mit 38.400 bps; das zweite, /dev/ttyS1, ein direkt angeschlossenes VT100-Terminal mit 19.200 bps.

Beispiel 3-6
Beispiel für eine /etc/mgetty/mgetty.config-Datei 
#
# mgetty-Konfigurationsdatei
#
# das ist eine Beispiel-Konfigurationsdatei, siehe mgetty.info für Details
#
# Kommentarzeilen beginnen mit einem "#", leere Zeilen werden ignoriert
#
# ----- global section -----
#
# In diesem Abschnitt legen Sie die globalen Vorgaben fest, portweise Festlegungen
# folgen unten
#
# Zugriff auf das/die Modem(s) mit 38400 bps
speed 38400
#
# setzt den globalen Debug-Level auf "4" (Vorgabe aus policy.h)
debug 4
#
# ----- port specific section -----
#
# Hier können Sie Dinge einsetzen, die nur für eine Leitung gültig sind, nicht
# für die anderen
#
#
# Hayes-Modem, angeschlossen an ttyS0: nicht faxen, weniger Protokollierung
#
port ttyS0
debug 3
data-only y
#
# direkte Verbindung eines VT100-Terminals, das keine DTR-Ausfälle mag
#
port ttyS1
direct y
speed 19200
toggle-dtr n
#

Die Konfigurationsdatei unterstützt sowohl globale als auch portspezifische Optionen. In unserem Beispiel verwenden wir eine globale Option, um die Übertragungsgeschwindigkeit auf 38.400 bps einzustellen. Dieser Wert wird an das Gerät ttyS0 »vererbt«. Alle Ports, auf die mgetty angewendet wird, verwenden diese Geschwindigkeit, wenn für sie nicht ausdrücklich eine andere portspezifische Geschwindigkeit angegeben ist - in etwa so, wie wir es bei der Konfiguration von ttyS1 getan haben.

Das Schlüsselwort debug stellt die »Gesprächigkeit« der mgetty-Protokollausgaben ein. Das Schlüsselwort data-only in der ttyS0-Konfiguration veranlasst mgetty, alle Faxmodem-Funktionen zu ignorieren, so dass das Modem sich wie ein gewöhnliches Datenmodem verhält. Das Schlüsselwort direct in der ttyS1-Konfiguration weist mgetty an, das Modem am Port nicht zu initialisieren. Schließlich bewirkt das Schlüsselwort toggle-dtr, dass mgetty keinen Versuch unternimmt, die laufende Verbindung durch Absenken des DTR-Signals (Data Terminal Ready) an der seriellen Schnittstelle abzubrechen; manche Terminals mögen das einfach nicht.

Wenn Sie wollen, können Sie die Datei mgetty.config auch leer lassen und Kommandozeilenparameter verwenden, um die meisten der genannten Konfigurationsoptionen einzustellen. Die dem Programm beiliegende Dokumentation enthält eine vollständige Beschreibung der mgetty-Konfigurationsparameter und -Kommandozeilenargumente. Siehe das folgende Beispiel.

Um diese Konfiguration zu aktivieren, fügen wir zwei Einträge in die Datei /etc/inittab ein. Bei dieser Datei handelt es sich um die Konfigurationsdatei des init-Befehls in Unix System V. Dieser Befehl ist für die Systeminitialisierung verantwortlich und enthält eine ganze Reihe von Anweisungen zum automatischen Start von Programmen während des Boot-Vorgangs bzw. zum Neustart von Programmen, die im laufenden Systembetrieb beendet werden. Das ist ideal für die Aufgaben, die ein getty-Programm ausführen soll.

T0:23:respawn:/sbin/mgetty ttyS0
T1:23:respawn:/sbin/mgetty ttyS1

Jede Zeile der Datei /etc/inittab besteht aus vier Feldern, die durch Doppelpunkte voneinander getrennt sind. Das erste Feld enthält eine eindeutige Kurzbezeichnung und besteht traditionell aus zwei Zeichen, in modernen Systemen aus bis zu vier Zeichen. Das zweite Feld enthält eine Liste von Runleveln, in denen dieser Eintrag aktiv sein soll. Runlevel stellen gewissermaßen verschiedene Maschinenkonfigurationen dar. Sie werden in Form hierarchischer Baumstrukturen aus Startskripten implementiert, die in den Verzeichnissen /etc/rc1.d, /etc/rc2.d usw. abgelegt sind. Diese Funktion ist meist sehr einfach implementiert. Sie sollten Ihre eigenen Einträge nach dem Vorbild der anderen Dateieinträge gestalten und für weitere Informationen auf Ihre Systemdokumentation zurückgreifen. Das dritte Feld beschreibt, wann eine Aktion ausgelöst werden soll. Für die Anwendung von getty sollte in dieses Feld ein respawn eingetragen werden, was dafür sorgt, dass das Programm automatisch neu gestartet wird, sobald es aus irgendeinem Grund endet. Es gibt noch viele andere Optionen, sie sind aber für unsere Zwecke nicht weiter interessant. Das vierte Feld zeigt an, welcher Befehl tatsächlich ausgeführt werden soll. Das ist der Ort, an dem wir den mgetty-Befehl mit den gewünschten Argumenten angeben. In unserem einfachen Beispiel starten wir mgetty immer dann (neu), wenn das System im Runlevel 2 oder 3 arbeitet. Als Argument geben wir nur das serielle Gerät an, das wir benutzen wollen. mgetty geht automatisch vom Verzeichnis /dev/ aus, so dass wir es nicht eingeben müssen.

Das war eine schnelle Einführung in die Anwendung von mgetty und wie man seriellen Geräten Login-Prompts zur Verfügung stellt. Weiterführende Informationen finden Sie im Serial HOWTO.

Nachdem Sie die Konfigurationsdateien bearbeitet haben, müssen Sie dafür sorgen, dass init die geänderte Konfiguration neu einliest, damit die Änderungen wirksam werden. Senden Sie dazu einfach ein Hangup-Signal (HUP) an den init-Prozess. Er hat grundsätzlich eine Prozess-ID von 1, so dass Sie bedenkenlos immer folgenden Befehl ausführen können:

# kill -HUP 1

Fussnoten

1Beachten Sie, dass wir hier nicht von WinModem reden! WinModems haben eine sehr einfache Hardware und nehmen daher den Hauptprozessor Ihres Computers stark in Anspruch. Wenn Sie sich ein Modem kaufen wollen, empfehlen wir Ihnen dringend, auf keinen Fall ein WinModem zu nehmen. Kaufen Sie sich lieber ein »echtes« Modem! Falls es sich dennoch nicht vermeiden lässt, mit einem WinModem zu arbeiten, lassen Sie den Kopf nicht hängen - es gibt Hoffnung! Unter http://linmodems.org finden Sie Treiber, Anweisungen und das LINMODEM HOWTO.

TOC PREV NEXT INDEX


O'Reilly Home | O'Reilly-Partnerbuchhandlungen | Bestellinformationen
Kontakt | Über O'Reilly | Datenschutz

© 2005, O'Reilly Verlag GmbH & Co. KG