u-isdn/DOKU

DOKU zum ISDN-Paket. R 7.      // TEXT ohne Tabs //
Basiert auf Linuxkernel 1.2.5.

Dies ist eine Betaversion.

Dieses Programmpaket ist (c) 1994,1995 Matthias Urlichs <urlichs@noris.de>.
Es darf ohne meine Zustimmung _nicht_ weitergegeben werden. Kommerzielle
Verwertung jedweder Art bedarf meiner Zustimmung. Das Anbieten auf
FTP-Servern, in Mailboxen, etc.pp. ist ohne meine Zustimmung nicht
gestattet.

Obige Parameter gelten f<>r diese Betaversion. Die Vollversion wird
unter der GPL bzw. ihrem deutschen <20>quivalent verf<72>gbar sein.


Achtung:
=======

Mit der Version 11 ist das OK am Ende des statischen Teils der AT/L-Ausgabe
weggefallen, weil das zu viele Leute irritiert hat.

Mit der Version 11 hat sich die Installationsprozedur fuer ISDN-Karten
geaendert. Vorher: Config.c editieren, Modul bauen. Jetzt: d_teles.o
laden, dann fuer jede Karte "insmod -o Tel0 teles.o name=$(cardname Tel0)
mem=0xD6000 irq=5" ausfuehren. Daten anpassen! Unterschiedliche Namen
verwenden! Das rc-Skript in tools/ wurde entsprechend angepasst.
16-Bit-Karten: Zusaetzlich "ipl=X" (X=1..3) fuer die erste bis dritte Karte.
Damit sollte es problemlos sein, zwischen verschiedenen Systemen (mit
einigerma<EFBFBD>en identisch konfigurierten Kernels) die Treiber auszutauschen.

Mit der Version f<>r 1.2.0 hat sich die Syntax der cf-Datei leicht ge<67>ndert:

Der :ea-Parameter in der P-Zeile wurde durch den :lr-Parameter ersetzt:
-   verwende ":lr /X" statt ":ea X".
-   h<>nge an die DL-Zeile an die Nummer einen / an und danach ":pr 0 :sp 65
    :pr 63" f<>r 1TR6 oder :sp 8 f<>r Euro-ISDN.
Generell steht nun "/" f<>r EAZs und so; "." steht f<>r Nebenstellennummern.
Bei externen Nummern verwende ich generell ".", aber das ist
Geschmackssache.

Einige Konfigzeilen haben als zus<75>tzlichen Parameter das ISDN-Interface
verpa<EFBFBD>t bekommen.

Die Parameter :pr und :sp stehen nun in der DL-Zeile und nicht mehr in
der P-Zeile.

Die I- und O-Flags werden nun klein geschrieben.

Die Verz<72>gerung beim Auflegen (ML-Zeile) wird nun mit einem Komma an die
Flags angeh<65>ngt anstatt als Extraparameter.


Einen leicht genervten Dank an den einen von ca. 30 Leuten, die den Fehler
in der letzten DOKU-Ausgabe nicht nur bemerkt haben, sondern der sogar auf
die unheimlich neuartige Idee gekommen ist, mir eine entsprechende Mail zu
schreiben. (You know who you are.)  Und zwar nicht eine Mail "Du da pa<70>t
was nicht zusammen, ey boah ey", sondern sogar mit der anscheinend (wenn
ich mir die anderen Mails so ansehe) absolut unn<6E>tigen Info, _was_ nicht
stimmt. Echt goil ey.


Geldmangel
==========

Die Entwicklung so eines Treibers kostet Zeit. Zeit ist Geld.  :-(

Wer sich an den Entwicklungskosten des Treibers beteiligen will:
Konto 2040206135, Hypo-Bank N<>rnberg (BLZ 760 202 14). F<>r den <20>berwiesenen
Betrag kann ich eine Rechnung schreiben, wenn n<>tig inkl. M<>rchen...<2E>h,
Mehrwertsteuer.


Bekannte Fehler
===============

Die Konfigurationsdatei ist manchmal etwas undurchsichtig.
_Ich_ werde das nicht <20>ndern, keine Zeit; wenn jemand ein Frontend
schreiben will -- nur zu!

Das Masterprogramm hat noch Speicherlecks.

Euro-ISDN ist moderat getestet; Geb<65>hrenerfassen w<>hrend der Verbindung
geht noch nicht.

Login <20>ber ISDN macht noch leichte Probleme.

Die Doku liegt nur auf deutsch vor.


Fragen? Probleme? (Gleich am Anfang, damit es keiner <20>bersieht...)
=================

Bitte per Mail, und zwar an isdn-problem@smurf.noris.de.
Wenn ohne Internetanschlu<6C>: Bitte per Fax, an 0911/5980150.
Telefonanrufe von Nichtkunden sehe ich ziemlich ungern, weil sehr
zeitaufwendig.

Vollst<EFBFBD>ndige Konfigdatei und genaues Protokoll dessen, was man gemacht hat,
was im Syslog oder auf der Konsole ausgegeben wurde, etc.pp., mitschicken.

Probleme mit der Doku? DIES IST noch KEINE ENDVERSION. Also bitte selber
nachdenken, in den Sourcen w<>hlen, rausfinden wo es hakt, und mir entweder
genauere Fragen stellen oder einen L<>sungsvorschlag, zB erg<72>nzte Doku,
schicken. Oder mich da<64>r bezahlen, da<64> ich den Kram supporte -- das ist
n<EFBFBD>mlich der eigentliche Grund, weshalb der Treiber nicht schon vor einem
halben Jahr fertig wurde... N<>heres zu meinem Supportangebot f<>r Linux via
Mail -> info@smurf.noris.de.

Bei Systemcrashs und <20>hnlichen Widrigkeiten: Problem reproduzieren;
Konfiguration, genaue Infos was wann wie, Fehlermeldungen in eine Mail
verpacken und mir schicken.


Support
=======

Support gibt es bei mir zu kaufen. N<>here Informationen und Preise -> Mail.

Einen Treiberupdate gibts fuer DM 30 plus Medium. Fuer kommerzielle Kunden
gibts dasselbe fuer DM 250, Erstsupport bis zur erfolgreichen Installation
inbegriffen.

Fuer Privatleute etc. gibts den Support auch kostenlos, in Massen, via Mail
oder via Usenet: de.comp.os.linux.


Systemvoraussetzungen
=====================

Linux. GCC 2.5.8, Libraries 2.6.4, oder neuere.
Passive ISDN-Karte mit Hardware-Doku, oder Teles-8 oder -16 / Creatix.
Support fuer BSC- und AVM A1-Karten ist in Vorbereitung, Source liegt bei,
funktioniert aber noch nicht so ganz (BSC: B-Kan<61>le; beide: Interrupts?) --
wer kann und will, m<>ge sich dransetzen.


Kernelpatches
=============

Die Patches basieren auf dem in der Versionsnummer bezeichneten Kernel.
Fr<EFBFBD>here bzw. sp<73>tere Kernels auf eigene Gefahr bzw. Bastelei. 

Was die einzelnen Patches machen und ob sie ben<65>tigt werden,
steht in den einzelnen Dateien am Anfang.

Der Kernel mu<6D> mit CONFIG_MODVERSION gebaut werden. Alternativ (aber das ist
unsicherer) kann im ISDN-Paket aus config/config.data -DCONFIG_MODVERSION
entfernt werden. Das modutils-1.2.8-Paket wird in jedem Fall ben<65>tigt, um
Parameter an die einzelnen Module zu <20>bergeben.


Grundstruktur
=============

Das Modul "compat" stellt ein paar Funktionen zur Verf<72>gung, wie sie aus 
anderen Unixkernelumgebungen bekannt sind.

"streams" implementiert minimale Streamsunterst<73>tzung. Wegen der
tty-Verwaltung unter Linux gibt es keinen clone-Treiber (die ist nicht
darauf ausgelegt).

Der ISDN-Treiber "isdn_2" ist die Low-Level-Schnittstelle zwischen den
ISDN-Karten und de Steuerprogramm (bin/master). Dieses <20>ffnet /dev/isdnmon,
liest eine Konfigdatei (siehe unten) etc. Der Treiber meldet dem
Steuerprogramm, welche Karten sich bei ihm angemeldet haben.
Es gibt _keine_ Devices f<>r einzelne Karten.

Der Treiber managt das Q.921-Protokoll f<>r die Karten. Alles andere ist
Sache des Steuerprogramms (D-Kanal) bzw. anderer Streams-Module (B-Kan<61>le).

Ein kommunikationswilliges Programm <20>ffnet einen freien ISDN-Port
(/dev/isdn/isdnX, X von 1 bis 99 oder so) und sendet einen Verbindungs-
wunsch an das Steuerprogramm ("atd/subnet/login", <20>ffnen einer Verbindung
zum System "subnet" im Protokollmodus "login"). Das Steuerprogramm schiebt
diesem Kanal nun automatisch die notwendigen B-Kanal-Module unter (X.75,
T.70, V.110, was-auch-immer), baut die Verbindung auf, meldet den Zustand
der Verbindung ("RRING", "CONNECT") und verbindet schlie<69>lich B-Kanal und
Programm.  Es erscheint das login:-Prompt des Systems "subnet".

Umgekehrt wird das Steuerprogframm bei einem ankommenden Anruf selbst einen
freien Port <20>ffnen und das zust<73>ndige Programm auf diesem Port starten.
Dasselbe passiert bei abgehenden Anrufen, die auf das zust<73>ndige Programm
beschr<EFBFBD>nkt sind, zB TCP/IP.

Beispiel:
% cu -l isdn/isdn22
  beliebig, mu<6D> nur frei sein.
AT
 OK
  Der Interpreter im Kontrollprogramm tut so, als w<>re er ein Modem mit
  Hayes-Befehlssatz, und schickt ein OK zur<75>ck.
  Hinweis: Das Ding ist minimal und kann nichtmal ATEx oder ATVx.
ATD/subnet/login
  [ Virtuelles Rappeln einer W<>hlscheibe ]
 RRING
 CONNECT
 login:
  Die Verbindung steht. Viel Spa<70> beim Hacken eines Pa<50>worts. ;-)

BETA-BEMERKUNG: Loginverbindungen sind in der jetztigen Version nicht allzu
gut getestet. Was sehr gut tut, ist TCP/IP; siehe dazu die Beispielkonfi-
guration. Ein Anrufbeantworter existiert ebenfalls (leider noch ohne
DMTF-Erkennung).

Statt eines Sitenamens tut auch ATD und die Nummer; /login ist der Default
f<EFBFBD>r das Protokoll.


Installation
============

Linux:

cd /usr/src
mkdir isdn ; cd isdn
tar xfvz /wo/auch/immer/isdn-xxxx.tar.gz
cd patches
for i in * ; do patch -p0 -d /usr/src/aktueller-kernel < $i ; done
# Kernel installieren und booten.
# (alten Kernel unbedingt zu Backupzwecken erhalten!)
# Danach:

vi config/config.data
vi isdn/cards/dumb/Config.c    # Speicherlage+Interrupts der ISDN-Karten
make.isdn
make load # Einbau der Module in den laufenden Kernel
cd /usr/local/isdn/bin
vi /etc/isdn.conf # ISDN-Nummern, Dienste, etc. eintragen
bin/master /etc/isdn.conf  # geht automatisch in den Hintergrund

S<EFBFBD>mtliche Ger<65>tedateien werden automatisch angelegt.


Testen:
-------

% cu -l isdn/isdn59
AT/L

sollte die konfigurierten TCP-Verbindungen auflisten.
Wenn nicht: Wahrscheinlich stimmt der Kartenname in der D-Zeile nicht.
Generell gilt: Unvollst<73>ndige Konfigurationsdateien werden nicht
angemeckert, sondern ignoriert. (Ja ich wei<65>, das ist unbefriedigend...)


AT-Befehle
==========
Alle Schl<68>sselbuchstaben k<>nnen gro<72> oder klein geschrieben werden.
Das "AT" mu<6D> entweder vollst<73>ndig gro<72> oder vollst<73>ndig klein
geschrieben werden. Zeichen vor dem "AT" werden ignoriert.

AT/Bn
    Schaltet Verbindung <n> von "off" auf "down" um. Siehe AT/L.
AT/K
    Beendet alle laufenden Verbindungen.
    Kann nur vom Superuser ausgef<65>hrt werden.
AT/Kn
    Beendet die Verbindung <n>, beendet das betreffende Programm.
AT/L
    Listet den momentanen Status aller Verbindungen.
<[minor:]id> <Art> <Partner> <Key> <pid> <Modus/Karte> <UnitNow> <UnitAll> <Status>
    <minor>     Nummer der Verbindung, f<>r AT/K o.<2E>.
    <n>         interne Folgenummer der Statusmeldung; Meldungen, die einen
                alten Status ersetzen, bekommen dieselbe Nummer.
    <pid>       PID des Prozesses, der f<>r die Verbindung gestartet wurde.
    <Modus>
        off     Verbindung nicht aktiv, wird bei ankommendem Ruf reaktiviert.
        down    Standby; sobald ein Datenpaket ansteht, wird die Verbindung 
                aufgebaut.
        up      Verbindung steht
        ->down
        ->up    Verbindung wird gerade ab- bzw. aufgebaut.
    <UnitNow>   Einheiten in der aktuellen Verbindung.
    <UnitAll>   Einheiten insgesamt seit Start des Prozesses.
	<Flags>     interner Zustand der Verbindung, komma remote-Nummer,
                strichpunkt lokale-Nummer (jeweils wenn bekannt/vorhanden)
    <Status>    Text; Meldung der Vermittlung (Gro<72>/Kleinschreibung) oder
                      interner Zustand (Gro<72>schreibung).
    Ein Ausrufezeichen an erster Stelle bedeutet, da<64> die Verbindung intern
    nicht mehr bekannt ist, der Zustand aber noch eine Zeitlang angezeigt wird.

    Bis zum n<>chsten AT-Befehl bleibt der Kanal im Monitormodus und meldet
    alle Zustands<64>nderungen automatisch.
AT/I
    Listet den internen Zustand. In der ersten Zeile stehen die erkannten
    ISDN-Karten, die zweite Zeile enth<74>lt den internen Zustand des ISDN-
    Systems. Zum Debuggen.
AT/M foo
    Sendet den Systembefehl "foo" nach unten. Gef<65>hrlich.
    Kann zum Online-Rekonfigurieren von Modulen verwendet werden. Beispiel:
        AT/M pr :mi 2 ::ms :ms timer :tr 30 :tw 30 :ti 10
    w<>rde auf Verbindung 2 den automatischen Verbindungsabbau dazu <20>berreden,
    alle 10 Sekunden nachzusehen, ob in den letzten 30 Sekunden keine Daten
    <20>bertragen wurden, und die Verbindung gegebenenfalls beenden.
AT/Q
    Programmende. Kann nur vom Superuser ausgef<65>hrt werden.
AT/R
    Reload der Konfigdatei. Kann nur vom Superuser ausgef<65>hrt werden.
AT/Xn
    Abbruch der Verbindung <n>. Kann nur vom Superuser ausgef<65>hrt werden.
ATD/sys/proto
    Sucht Nummer und Protokoll in der Konfigdatei, w<>hlt, macht Verbindung auf. 
ATH
    trennt die Verbindung.
<BREAK>
    wechselt vom Online- in den Befehlsmodus, falls erlaubt. Der Interpreter
    antwortet mit OK.
    (zum Verbieten: entsprechenden Konfigurationsbefehl f<>r das PROTO-Modul
     verwenden.)
    "+++" zum Wechseln funktioniert _nicht_.

Diverse andere Befehle sind 100% ungetestet. <BREAK> habe ich seit Ewigkeiten 
nicht mehr ausprobiert.
ATA existiert nicht; stattdessen Konfigdatei <20>ndern.


Einschub: Was ist dieser Streams-Kram eigentlich?
========  Was ist auf dem B-Kanal los, da<64> man sowas braucht?

Nimm an, du willst TCP/IP-Pakete verschicken. Du packst also jedes dieser
Pakete in einen Datenblock und schickst sie auf die Reise ... halt, so einfach
geht das nicht. Normalerweise wird auf dem B-Kanal sowas wie eine gesicherte
Verbindung gefahren. (Man kann sich streiten, ob das bei IP-Paketen, die
eigentlich sowieso beliebig verlorengehen d<>rfen, Sinn macht.) Au<41>erdem k<>nnen
manche ISDN-Implementierungen nur ziemlich kleine Pakete verarbeiten; um
zu vermeiden, da<64> die IP-Pakete fragmentiert werden (Overhead: ca. 20 Bytes
pro Fragment) oder von der Gegenseite weggeschmissen werden (Overhead:
unendlich ;-) , mu<6D> man sie so kennzeichnen, da<64> die Gegenseite sie direkt
wieder zusammensetzen kann (Overhead: 2 Bytes; braucht aber besagte gesicherte 
Verbindung, um vern<72>nftig zu funktionieren). BTX beispielsweise arbeitet
so. Au<41>erdem ist ISDN bytesynchrton, d.h. irgendjemand mu<6D> kennzeichnen, wo
ein Datenpaket aufh<66>rt und wo/wann das n<>chste anf<6E>ngt. Daf<61>r gibt es, wie
<EFBFBD>blich, mehrere Methoden...

Streams sind nun eine M<>glichkeit, mehrere speziell geschriebene Module
auf einem ebenfalls speziell geschriebenen Treiber so zu stapeln, da<64> jedes
Modul eine Einzelaufgabe dieser Arbeit erledigt. Im Idealfall sind die
einzelnen Module recht klein und damit debugbar, lassen sich vielseitig
zusammenst<EFBFBD>pseln, etc.pp. In der Praxis ist die Sache nat<61>rlich nicht ganz
so einfach; insbesondere ist der Overhead, die Pakete von einem Modul zum
n<EFBFBD>chsten zu schaufeln, nicht zu vernachl<68>ssigen. Er ist aber tolerierbar,
vor allem wenn man auf die ganzen <20>berfl<66>ssigen "Features" (von manchen
Menschen als "Bugs" oder "Designfehler" bezeichnet...) verzichtet, die
USL und Co. in Sys5 Release 4 dazuerfunden haben.

Die einzelnen Module m<>ssen parametrisiert werden. Im Normalfall spricht
man sich mit der Gegenseite vorher ab, ob beispielsweise X.75 verwendet
wird und in welchem Modus. Alternativ, und wenn man die Normen auswendig
wei<EFBFBD>, schaltet man ein Monitor-Modul zuunterst auf den Datenstrom, l<><6C>t
sich von der Gegenseite anrufen, beobachtet genau was da passiert, und
richtet die Konfiguration entsprechend ein. (Das klingt nicht nur
kompliziert, das ist es auch. Au<41>erdem gibt es ein paar Details, die sich
nicht ohne weiteres beobachten lassen.) Zum Gl<47>ck haben sich ein paar
"normale" Betriebsarten herauskristallisiert, an die sich die meisten
Systeme halten.


Noch ein Einschub: TCP-IP-Routing
=================================

So ein TCP/IP-Draht <20>ber ISDN mag ja ganz nett sein, aber irgendwie m<>ssen
andere wissen, wie sie vom lokalen Netz zum IP-Rechner zur Gegenstelle
k<EFBFBD>nnen. Und umgekehrt.

Das ganze Thema ist zu kompliziert, um es hier abzuhandeln. Man lese ein
gutes Buch <20>ber den Kram, zB Stevens. 

Wichtige Spezialf<6C>lle:
- Das Gro<72>e Internet ist auf der anderen Seite der ISDN-Leitung.
  slipto mit -d starten und auf den ganzen anderen Rechnern im lokalen Netz 
  eine Defaultroute zum ISDN-Rechner eintragen. ACHTUNG! ALLE LOKALEN
  RECHNER BRAUCHEN OFFIZIELL ZUGETEILTE IP-NUMMERN. Das Weiterleiten von
  Nummernbereichen nach RFC 1597 mu<6D> unterbunden werden (wenn diese lokal
  verwendet werden: unbedingt IP-Firewall in den Kernel einbauen und
  rausfiltern); andere unzul<75>ssige Netznummern m<>ssen durch einen zweiten
  Gatewayrechner mit zwei Ethernetkarten o.<2E>. abgeschottet werden.

- Ein System, das eigentlich Teil des lokalen Netzes w<>re, sitzt am anderen
  Ende der Leitung. Am einfachsten ist hier Proxy-ARP; der ben<65>tigte Befehl
  beim Booten lautet "arp -s IP_der_entfernten_Kiste Ether_des_ISDN_-
  _Rechners pub". Die Ethernetadresse spuckt "ifconfig eth0" aus.

  diplogin (f<>r IP <20>ber serielle Leitung) kann den arp-Eintrag automatisch
  setzen. Wenn jemand entsprechende Patches f<>r slipto macht -> her zu mir.

- Ein Netz mit stupidem ISDN-Router, der ein Transfernetz sehen will, ist
  auf der anderen Seite. Einfachste Methode: Vom lokalen Netzbereich wird
  ein 4-Adressen-Bereich abgezwackt und als Transfernetz mi<6D>braucht. Sei
  die lokale Adresse 129.130.131.x, so wird zum Beispiel der Bereich x =
  [224..227] verwendet (die beiden untersten Bits des unteren Endes des
  Adressbereichs, hier 224, m<>ssen(!!!) 00 sein). Die n<>chste Adresse
  (hier: 225) wird die lokale Adresse (entweder als lokale Adresse im
  slipto, oder via dummy-Interface: "ifconfig dummy0 129.130.131.225; route
  add -host 129.130.131.225 dev lo" -- in der Konfigdatei wird in diesem
  Fall die normale Ethernetadresse des Rechners als lokale Adresse
  verwendet). Danach (hier; .226) kommt die entfernte Adresse (eintragen
  via Proxy-ARP).

  Auf der Gegenstelle wird dann das Transfernetz mit einer Netmask von
  255.255.255.252 konfiguriert, die ..225 wird dort die entfernte
  Adresse und die Defaultroute an der Gegenstelle zeigt darauf.
  (Au<41>erdem mu<6D> manchmal eine Route f<>r das Netz, hier 129.130.131.0,
  eingetragen werden, die auf die Gegenseite, hier .225, zeigt.)

  Diese Methode verschwendet 75% des Adressbereichs (die Nummern .224,
  .225 und .227 werden im Internet nie in Erscheinung treten) und einer der
  Rechner auf der Gegenseite verwendet dummerweise eine Nummer aus dem
  lokalen Netz, f<>r die ein funktionierender Nameserver-Eintrag gepflegt
  werden mu<6D>, hat aber den Vorteil, da<64> sie funktioniert.

  Es f<>llt au<61>erdem auf, da<64> die lokale Adresse und Konfiguration des
  ISDN-Links nichts mit dem zu tun haben mu<6D>, was die Gegenseite von uns
  denkt. Das ist auch total egal -- im Gegensatz zu PPP werden die Adressen
  nicht mit der Gegenstelle abgeglichen. Das einzige, auf das es ankommt,
  ist, da<64> die jeweils lokalen Adressen auch als lokal angesehen werden und
  _nicht_ irgendwie wieder zur Gegenseite geroutet werden. Pingpongpakete
  haben auf einer ISDN-Leitung nichts verloren! (Und auch nirgends anders.)

  Es f<>llt au<61>erdem auf, da<64> ich nichts von routed und <20>hnlichen Programmen
  gesagt habe. Das ist Absicht. Konfiguriert eure Routen lieber statisch,
  das ist ges<65>nder...


Die Konfigurationsdatei
=======================

Die Datei besteht aus verschiedenen Zeilentypen, die frei gemischt werden
k<EFBFBD>nnen. Der erste auf ein Problem passende Eintrag wird verwendet; auf eine
passende Zeile folgende solche werden bei manchen Zeilentypen ebenfalls 
ausgewertet.
Strings in spitzen Klammern sind Platzhalter. Ein Doppelpunkt mit zwei
folgenden Buchstaben ist ein Parameter, dem eine vom Parameter abh<62>ngige
Anzahl Werte folgen kann.

Alle Zeilentypen:

<Key> ist jeweils ein beliebiger String. Alle f<>r eine Verbindung verwendeten
      Zeilen in der Konfigdatei m<>ssen zueinander passende Keys haben, d.h.
      mindestens ein Zeichen mu<6D> in allen Keys <20>bereinstimmen. "*" pa<70>t zu
      allen anderen Zeichen.
<Mod> sind einzelne Buchstaben, der der betreffenden Zeile eine Sonder-
      behandlung verpassen.
<Parameter...> ist eine Folge von einem oder mehr Parameter-Wert-Angaben.
               (Manche Parameter haben keine Wertangabe.)
      Merke: Zeilen ohne Parameter sind im allgemeinen nicht sinnvoll
      und f<>hren (momentan noch) zu Fehlverhalten des Treibers.


P-Zeile ("Protokoll")
-------

Form:
P <Art> <Partner> <Key> <Karte> <Mod> <Parameter...>

Beispiel:
P login * * R   :sv 0700 :nr .2 :lr /2

Parameter:
:Ft Bei Festverbindungen angeben. (Erzwingt das Laden des
    "Verbindungs"handlers.)
:dI Eine Verbinung dieses Typs soll persistent sein, d.h. zwischen zwei
    Verbindungen wird das handhabende Programm nicht unterbrochen.
    Ein "reconn"-Streamsmodul stellt sicher, da<64> das Programm davon nichts
    mitbekommt, au<61>er wenn der Wiederaufbau der Verbindung nicht klappt.
:cd Karte. Welche ISDN-Leitung verwendet werden soll. (Wichtig f<>r SPVs.)
    Bei Festverbindungen wird dieser Parameter nicht ben<65>tigt.
:bc Zu verwendender B-Kanal, 1 oder 2. Nur f<>r Festverbindungen
    interessant; im normalen ISDN managt die Vermittlung B-Kan<61>le f<>r uns.
:nj Kann der Ruf nicht angenommen werden, wird BUSY statt CallRejected
    gesendet.
:xi Wenn ankommende und abgehende Anrufe kollidieren, soll der an-
    kommende abgewiesen werden. (Default: Der abgehende Ruf wird
    abgebrochen.) (Nicht allzu gut getestet.)
:yi Bei einem ankommeden Ruf wird automatisch ein abgehender gestartet und
    der ankommende wird abgewiesen. (Ungetestet.)
:il Die CL-Zeile wird ignoriert.
:fX Ankommende Anrufe, die (zB wegen besetzt) abgewiesen werden, werden
    "schnell" abgelehnt. (Andere Ger<65>te am Bus k<>nnen nicht abheben.)
:fr Abgehende Anrufe, die nicht durchkommen, werden "sofort" und "oft"
    wiederholt.

    Logischerweise darf :xi oder :yi nicht auf beiden Seiten angegeben
    sein..!

Spezifisch f<>r 1TR6:
:sv Dienstkennung; zwei Bytes in Hex. Telefon ist 0101 und 0102; DF<44> ist
    07xx (xx ist <20>blicherweise 00).
:pv Semipermanente Verbindung bei abgehenden Rufen.
    Ankommend werden SPVs automatisch unterst<73>tzt.

Spezifisch f<>r Euro-ISDN:
:vB Bearer Capability. Hexstring, evtl. mit Maske.
:vL Lower Layer Compatibility. Hexstring, evtl. mit Maske.
:vU Upper Layer Compatibility. Hexstring, evtl. mit Maske.
    Was diese Dinger bedeuten, steht in der Norm Q.931, zu holen bei 
    info.itu.ch via Gopher oder FTP. Die wichtigsten Bedeutungen stehen am
    Ende dieser Anleitung.

Spezifisch f<>r die Bearbeitung von Telefonnummern:
:nr Entfernte Telefonnummer. Siehe unten unter Telefonnummernverarbeitung.
:lr Lokal angew<65>hlte Telefonnummer, bzw. deren variabler Teil.
:om Die folgenden Nummernteile sind zum Rausw<73>hlen bestimmt, d.h. eindeutig.
:im Die folgenden Nummernteile sind zum Einw<6E>hlen bestimmt, d.h. Muster.
:bm Die Nummernteile werden sowohl ankommend als auch abgehend verwendet
    (Default).

    Hierbei gilt: Angegeben werden nur die Nummernteile, die nicht in den
    D- bzw. DL-Zeilen stehen. Das System destilliert aus den verschiedenen
    Angaben lokale und 

Mod:
R Die Zeile wird prim<69>r f<>r einen Verbindungsaufbau verwendet.
M Die Zeile wird nur dann analysiert, wenn eine <20>ber ihr gefundene P-Zeile
  "pa<70>t".
X Wenn diese Zeile (oder eine dar<61>berliegende) "pa<70>t", wird das Scannen
  nach weiteren passenden Angaben hier abgebrochen.
i f<>r ankommende Verbindungen
o f<>r abgehende Verbindungen
f f<>r Festverbindungen
d f<>r W<>hlverbindungen
p f<>r Verbindungsaufbau nach Bedarf

Der Suchalgorithmus findet zun<75>chst eine zur Verbindung passende R-Zeile
und h<>ngt an deren Parameterliste dann alle ebenfalls passenden M-Zeilen
an (dabei werden bereits angegebene Werte beibehalten, die spezifischen
Eintr<EFBFBD>ge also nach oben!), bis er auf eine X-Zeile trifft. 


ML-Zeile ("Modulliste")
--------

Form:
ML <Art> <Partner> <Key> <Karte> <Mod> <Modus> <Module...>

Beispiel:
ML login * * * - frame x75 t70

Hiermit wird angegeben, wie die Karte eingestellt und welche Streams-Module
f<EFBFBD>r einen B-Kanal verwendet werden m<>ssen, um zwischen diesem und einer
Anwendung zu vermitteln. Die Beschreibung der verf<72>gbaren Module folgt
weiter unten; der Modus wird <20>ber "CM"-Zeilen (auch unten) in eine Zahl
<EFBFBD>bersetzt, die der Kartentreiber verstehen mu<6D>.

Konzeptuell sind diese Module gestapelt; "unten" ist die Karte, "oben" das
Anwendungsprogramm. Zwischen diesem und dem letzten Modul in der obigen
Liste wird stets ein Spezialmodul namens "proto" eingeschoben, das die
Meldungen zum Verbindungsaufbau etc. so verarbeitet, da<64> die Anwendung
davon nichts mitbekommt."proto" darf nie in einer ML - Zeile erscheinen.

Mod:
i f<>r ankommende Verbindungen
o f<>r abgehende Verbindungen
f f<>r Festverbindungen
d f<>r W<>hlverbindungen
p f<>r Verbindungsaufbau nach Bedarf
,#  Verz<72>gerung bei Verbindungsende, in Sekunden, f<>r sauberes
    Herunterfahren des B-Kanalprotokolls.

Die Modulliste ist nach dem Start eines Programms festgelegt und wird durch
AT/R nicht veraendert.


MP-Zeile ("Modulparameter")
--------

Form:
MP <Art> <Partner> <Key> <Karte> <Mod> <Modul> <Parameter...>

Beispiel:
MP login * * * - proto :bk 0 :sg 0
MP login * * * - x75 :cm 3

Mit dieser Zeile k<>nnen Module parametrisiert werden, um ihre interne
Arbeitsweise so einzustellen, da<64> sie korrekt mit der Gegenseite zusammen-
arbeiten. Die m<>glichen Parameter sind unter den einzelnen Modulen, unten, 
beschrieben.

Mod:
i f<>r ankommende Verbindungen
o f<>r abgehende Verbindungen
f f<>r Festverbindungen
d f<>r W<>hlverbindungen
p f<>r Verbindungsaufbau nach Bedarf
u f<>r Parameter, die nur beim Programmstart gesetzt werden (x75-Kram zB)
a f<>r Parameter, die bei Neueinlesen der Konfigdaten gesetzt werden


D-Zeile ("Dial")
-------

Form:
D <Art> <Partner> <Key> <Karte> <Mod> <Nr>

Beispiel:
D * subnet * * - +49=721-961252.
D * Any-D * * I +49=*
D * Any * * I +*
D tcp xlink * Tel2 L

Angabe der Telefonnummer, unter der eine Gegenstelle erreichbar ist bzw.
mit der sie sich bei ankommenden Rufen meldet. Festverbindungen haben 
nat<EFBFBD>rlich keine Nummer. 

Mod:
i f<>r ankommende Verbindungen
o f<>r abgehende Verbindungen
f f<>r Festverbindungen (der zu verwendende B-Kanal steht in der P-Zeile)
d f<>r W<>hlverbindungen
p f<>r Verbindungsaufbau nach Bedarf


DL-Zeile ("Dial Local")
--------

Form:
DL <Karte> <Nummer> <Protokolle>

Beispiel:
DL Tel? +49=911-995962. :pr 0 :sp 65 :pr 63

Eigene Telefonnummer. Im Beispiel sind alle Karten, auf die "Tel?"
pa<EFBFBD>t, an einer ISDN-Leitung mit dieser Nummer angeschlossen.

Diese Zeile wird verwendet, um die k<>rzestm<74>gliche Rufnummer f<>r
abgehende Verbindungen zu finden und um die verwendeten Protokolle zu
spezifizieren.

Beispiel 1TR6:
DL Tel0 +49=911-23456. :pr 0 :sp 65 :pr 63

Beispiel Euro-ISDN:
DL Tel0 +49=911-34567. :pr 0 :sp 8 :pr 63

Beispiel Festverbindung:
DL Tel2 - :pr 64

Beispiel intelligente Karte mit CAPI:
DL Bin0 +49=911-45678. :pr 65

Bedeutung der Spezialzeichen in der Nummer: Siehe "DP" unten.

Protokolle und Flags in der DL-Zeile:
--------------------

Die Reihenfolge ist wichtig.

:pp        Punkt-zu-Punkt-Verbindung, feste TEI (0x00). :kl ebenfalls
           angeben!
:mp        Verbindung am Bus, variabler TEI-Identifier. Bei manchen 1TR6-
           Vermittlungen und Nebenstellenanlagen sinnvoll.
:mf        Verbindung am Bus, fester TEI-Identifier. Default.
:mt        Verbindung am Bus, feste TEI(0x12). In Spezialf<6C>llen notwendig.

:ud XX     Verz<72>gerung zwischen dem Verbindungsaufbau (D-Kanal) und dem
           eigentlichen Datenaustausch (B-Kanal). Zehntelsekunden; max.
           2 Sekunden; Default 1/4 Sekunde. Mit :ud 0 geht der Verbindungs-
           aufbau entweder etwas schneller, oder das erste Paket wird
           verschluckt, oder die Vermittlung kommt durcheinander und die
           Verbindung ist tot.  :-(

:pr 0      Normaler ISDN-D-Kanal, angeschlossen am Netz oder an einer
           Telefonanlage. Darf nur zusammen mit TEI-Handler (:pr 63)
		   verwendet werden.
  :kl      Level-2-Verbindung zur Vermittlung nicht trennen. Bei Punkt-
           zu-Punkt-Verbindungen und bei entsprechend konfigurierten
           ISDN-Anschl<68>ssen ("Dauer-irgendwas") notwendig.
  :cl      Level-2-Verbindung zur Vermittlung trennen. Default.

  :sp 8    DSS1, Euro-ISDN.
  :sp 65   1TR6, deutscher Standard.

  :ai      Ankommenden Anruf mit dem ISDN-<2D>quivalent von "RINGING"
           beantworten, dann pr<70>fen ob der Anruf angenommen werden kann. 
           Notwendig bei langsamen Rechnern.
  :ad      Ankommende Anrufe erst pr<70>fen, dann annehmen (oder auch nicht).
           Default.
:pr 63     TEI-Handler (Transport Endpoint Identifier).
  :ti      TEI sofort zuordnen lassen. Notwendig bei langsamen / sehr
           besch<63>ftigten Rechnern und bei manchen Telefonanlagen.
  :td      TEI beim ersten Verbindungsaufbau zuordnen lassen. Default.
:pr 64     Festverbindung: kein D-Kanal.
:pr 65     Intelligente Karte mit CAPI 1.x-Schnittstelle.
           (Noch nicht!)


DP-Zeile ("Dial Prefix")
--------

Form: 
DP <Karte> <Pr<50>fixe-Dialout> <Pr<50>fixe-Dialin>

Beispiel:
DP Tel? +00=0- +00=0-

Definition von Nummernpr<70>fixen, um Vermittlungsbereiche erreichen zu k<>nnen.

Das erste Pr<50>fix ist f<>r abgehende, das zweite (das weggelassen werden kann)
f<EFBFBD>r ankommende Verbindungen; 1TR6-Nebenstellenanlagen wollen beim W<>hlen
typischerweise eine vorgestellte Null o.<2E>. sehen, die aber bei ankommenden
Gespr<EFBFBD>chen nicht mit angezeigt wird.

Die Zeichen sind immer "+" f<>r internationale Verbindungen, "=" f<>r 
nationale Verbindungen, "-" f<>r Ortsverbindungen, "." oder "/" f<>r
Verbindungen innerhalb einer Nebenstellenanlage oder EAZs/MSNs etc. Der
Unterschied ist, da<64> Nummern einer Nebenstellenanlage direkt angerufen
werden k<>nnen, w<>hrend ich f<>r eine Verbindung zu einer anderen MSN die
Teilnehmernummer mitw<74>hlen mu<6D>.

Beispiel: Eine Konfiguration
D ... -1234/[456]
DL... -23456
DP... -
MP... :nr /5
w<EFBFBD>rde die Nummer 12345 w<>hlen.


R-Zeile ("Run")
-------

Form:
R <Art> <Partner> <Key> <Karte> <Benutzer> <Mod> <Programm> <Argumentliste...>

Beispiel:
R login * * * root IDUST /bin/login

Hiermit wird ein Programm (plus Parameter) angegeben, das bei ankommenden
oder abgehenden Gespr<70>chen aufgerufen wird. Ein Dialout zu einem System
mit "R"-Zeile ist also direkt nicht m<>glich, da der Datenaustausch zum
betreffenden Programm geht.

Eine R-Zeile wird ignoriert, sobald das betreffende Programm einen Fehler
gemeldet hat (Exitstatus != 0) oder bei der Verbindungssteuerung ein Fehler
aufgetreten ist. 

Im Environment dieses Programms werden folgende Variablen abgelegt:
SITE      <Partner>
PROTOCOL  <Art>
CLASS     <Key>
PHONE     Telefonnummer der Gegenstelle, so wie sie ankam bzw. gew<65>hlt wurde
DIRECTION "IN" oder "OUT"
DEVICE    im Normalfall: /dev/ttyiXX

Mod:
.n Die Antwort wird um n Sekunden verz<72>gert, beispielsweise um einen Anruf-
   beantworter nicht sofort abheben zu lassen.
,n Wenn eine automatische Verbindung nicht hergestellt werden konnte, wird
   nach n Sekunden der Verbindungsaufbau wieder erlaubt. (Noch nicht 
   implementiert)
$ Die Befehlszeile wird nicht direkt ausgef<65>hrt, sondern der Shell <20>bergeben.
E Beim Auftreten eines Fehlers wird dieses Programm deaktiviert.
D /dev/ttyiXX wird angelegt und nach Programmende gel<65>scht.
F Das Programm wird sofort gestartet, und die Verbindung wird aufgebaut.
  Interessant insbesondere bei Festverbindungen und SPVs.
L nur der angegebene Benutzer kann die Verbindung aktivieren.
Q strace(1) wird automatisch auf den neuen Proze<7A> losgelassen.
R kein Dialout via ATD m<>glich.
S stderr des Programms liegt auf ISDN (sonst: stderr des Treiberprogramms)
T Verbindung im Terminalmodus (ankommend, also zB beim Start von /bin/login).
U ein Eintrag in /etc/utmp wird angelegt (wichtig zB f<>r login).
B Die Verbindung wird beim Hochfahren des Managers automatisch aufgebaut.
i f<>r ankommende Verbindungen
o f<>r abgehende Verbindungen
f f<>r Festverbindungen. "B" wird hier normalerweise ebenfalls angegeben.
d f<>r W<>hlverbindungen
p f<>r Verbindungsaufbau nach Bedarf ("reconn"-Modul nicht vergessen!);
  wird beim Programmstart automatisch mitgestartet. Die eigentliche
  ISDN-Verbindung wird hierdurch _nicht_ aufgebaut, daf<61>r ist "B" gedacht.


CM-Zeile ("Card Mode")
--------

Form:
CM <Karte> <Zahl> <Modus>

Beispiel:
CM Tel? 2 transalaw
CM Tel? 3 transv110
CM Tel? 4 trans
CM Tel? 10 frame
CM Tel? 14 frame16

Assoziiert einen Modus einer Karte mit einem Schl<68>sselwort in der "ML"-Zeile.
Die Nummern sind im Kartentreiber fest eingebaut.
Momentan gibt es folgende Modi:

trans       volltransparente Verbindung. Es wird st<73>ndig ein synchroner 
            64-kBit-Datenstrom <20>bertragen. Wenn nichts gesendet wird,
            werden 1-Bits <20>bertragen. (Der Zustand "wenn nichts empfangen
            wird" kann nicht vorkommen!)
transalaw   wie oben, aber statt Einsen wird 0xAA gesendet ("Ruhepegel" bei
            A-Law-Sprachkodierung). Das Senden von Rauschen, wie auf
            gemultiplexten Satellitenleitungen, habe ich mir erspart...
transv110   wie oben, aber statt Einsen werden leere V.110-Frames (38.4 kBaud)
            gesendet.
frame       Standardmodus f<>r Daten<65>bertragung; die Karte interpretiert den
            B-Kanal als HDLC-Datenstrom, inkl. 0-Bit-Einschieben nach 5
            1-Bits, Pr<50>fsumme, etc.
frame16     16-bit breite Daten<65>bertragung auf entsprechenden
            Festverbindungen. Funktioniert nur auf dem ersten B-Kanal
            (der Modus greift sich einfach beide Kan<61>le) und (unter anderem
            wegen m<>glichen Laufzeitunterschieden) nicht bei zwei
            W<>hlverbindungen zur gleichen Zielstation.
/* die folgenden Modi sind noch nicht implementiert, bzw. nicht getestet */
frame0      Wie 'frame', aber zus<75>tzlich wird 1-Bit-Einschieben nach 7 0-Bits
            aktiviert. F<>r Leitungen in manche Ecken der USA, die keine
            Nulloktetts auf der Leitung zulassen (weil sie keinen externen
            Takt verwenden).
framehi     wie 'frame', nur werden nur die oberen 7 Bits verwendet.
framelo     ... oder die unteren Bits. Sinnvoll dann, wenn jemand den Daten-
            strom auf eine 56-kBaud-Leitung umsetzt.


CL-Zeile ("Card Limit")
--------

Form: CL <Karte> <Zahl> <Modus>

Beispiel>
CM Tel? 2 
Begrenzt die Zahl der verwendbaren B-Kan<61>le einer Karte.
Ueber das Limit hinausgehende Anrufe werden mit BUSY abgelehnt, es sei denn
in der entsprechenden P-Zeile steht der entsprechende Parameter.


LF-Zeile ("Load File")
--------

Form: LF <Karte> <Segmentgr<67><72>e> <Dateiname>

L<EFBFBD>dt die Datei auf die (aktive) Karte. Mehrere LF-Zeilen k<>nnen angegeben
werden.


RP-Zeile ("Run Program")
--------
Noch nicht implementiert.


Module und deren Konfiguration
==============================

:XX <Wertbereich> <Default> Funktion eines Parameters mit Wertangabe
:YY                         Dito, ohne Wertangabe


A-Law-Coder "alaw"
-----------
Wandelt einen A-Law-Datenstrom in einen 8-Bit-Datenstrom. Dabei werden nur
die Bytes umkodiert, die Daten aber nicht auf 12 Bit aufgeblasen. Gibt nach
oben Bytes _mit_ Vorzeichen weiter.
Zus<EFBFBD>tzlich k<>nnen f<>r beide Richtungen Schwellwerte definiert werden, 
unterhalb derer keine Uebertragung zugelassen wird, um in Gespr<70>chspausen
die Rechnerlast zu senken.

:ro 0-127    Ansprechschwelle beim Empfang. Null schaltet permanent auf
             "Durchgang".
:rx 0-127    Abschaltschwelle. T<>ne werden blockiert, wenn mehr als ..:
:rc 1-32767  aufeinanderfolgende Samples unterhalb der :rx-Schwelle liegen.
:xo :xx :xc  wie :ro :rx :rc, aber f<>r den Sendeteil.


Befehlsinterpreter "proto"
------------------
Sitzt immer automatisch zuoberst auf dem durch den ISDN-Treiber
definierten Stream. Interpretiert im Befehlsmodus die eingetippten Zeichen
und schickt sie zeilenweise an das Managementprogramm.
Im Online-Modus wird keine Spezialzeichenfolge wie etwa "+++" gesondert
interpretiert; stattdessen wird ein _BREAK_ zum Zur<75>ckschalten verwendet.

:cr 0-255  0x13  ASCII Carriage return
:lf 0-255  0x10  ASCII line feed
:bs 0-255  0x08  ASCII Backspace
:cc 0-255  0x03  Zeile l<>schen (Abbruch, ^C)
:ca 0-2    2     0: kein Hangup
                 1: Hangup bei NO CARRIER
                 2: Hangup bei CONNECT...NO CARRIER
:bk 0-1    1     BREAK bewirkt R<>ckkehr in den Befehlsmodus.
:sg 0-1    0     wenn 1, sende SIGUSR1 beim Aufbau der Verbindung und
                 SIGUSR2 beim Abbau der Verbindung

Die folgenden Codes werden normalerweise vom L4-Treiberprogramm gesendet:
:on      schaltet auf Daten<65>bertragung
:of      schaltet auf Befehlsmodus


Streams->IP-Wandler (str_if)
-------------------
Implementiert ein TCP/IP-Modul. Daten werden nicht in Richtung Anwender-
programm, sondern in das TCP/IP-Networking des Kernels umgeleitet.

:mt 120-4096  512     MTU des Treibers.

ioctl(x,SIOCGETU,int) ioctl-Aufruf zur Uebertragung der Unit-Nummer ("strX",
0 <= X <= 15) an ein Anwenderprogramm. Das Programm kann damit die IP-
Adressen auf beiden Seiten des Links konfigurieren. Ein einfaches
Treiberprogramm, "slipto", dem lokale und entfernte IP-Adresse <20>bergeben
werden, ist im Verzeichnis str_if.


Cisco-HDLC-Modul "fakeh"
----------------
Verwendet das Cisco-eigene "HDLC"-Protokoll. Auf der Gegenseite mu<6D>
(noch... hat jemand Doku zu den Tieren?) "no keepalives" konfiguriert
werden. 


Zeitbegrenzer "timer"
-------------
Bricht die Verbindung ab, wenn eine bestimmte Zeit lang keine Daten
<EFBFBD>bertragen wurden.
Alle Zeitangaben sind in Sekunden.

:ti 60  Abstand zwischen den m<>glichen Abbruchpunkten (zB Geb<65>hrenzeittakt)
:to 55  Zeit zwischen Verbindungsaufbau und erster Messung
:tw  0  wenn zum Me<4D>zeitpunkt soviele Sekunden nichts gesendet wurde,
        wird die Verbindung abgebrochen
:tr  0  dto., gelesen; eine der beiden Bedingungen reicht aus.
:tI     die Verbindung wird unterbrochen. Dazu mu<6D> <20>ber dem timer-Modul
        ein reconn-Modul sitzen und die Verbindung mu<6D> mit ":dI" markiert
        sein. (Ja ich wei<65>, das sollte das Programm selber managen...
        kommt alles noch.)
:tD     die Verbindung wird beendet.
:li     unterbrochen wird nur bei ankommenden Verbindungen.
:lo     dto, bei abgehenden Verbindungen
:lb     dto, beide Verbindungsarten (Default).

Vorsicht: Es macht absolut keinen Sinn, den Timer unterhalb von
<EFBFBD>bertragungssichernden Modulen wie x.75 oder gar Datenstrom-Modulen wie
v110 anzuordnen.

Der Timeout sollte mindestens dreimal so gro<72> sein wie die Zeit, die
typischerweise zum Verbindungsaufbau ben<65>tigt wird, weil es sonst
scheu<EFBFBD>liche Interaktionen mit den TCP-Retryalgorithmen gebenb kann.


T.70 "t70"
----
Implementiert das T-70-Minimalprotokoll -- spaltet abgehende Dateneinheiten
auf, wenn sie zu gro<72> sind, und fa<66>t ankommende zusammen, wenn das ent-
sprechende Bit im T70-Header gesetzt ist.

:mt  1-4096 1024 Maximale Datenblockgr<67><72>e.


V.110 "v110"
-----
Implementiert V.110 im 38400-Baud-Modus. Ungetestete Experimentierversion.
Warnung: Exzessive Kernelbelastung durch Bitschieberei etc. F<>r ernsthafte
Anwendungen braucht es einen entsprechenden Wandler in Hardware auf der Karte.
In der jetztigen Version ungetestet.


Van-Jacobsen-Kompression "vanj"
------------------------
Komprimiert TCP-IP-Header.
Sollte nur auf einer gesicherten Verbindung verwendet werden.
:ac               Aktiv komprimieren. (Default bei abgehenden Verbindungen.)
:pa               Komprimieren nur, nachdem ein komprimiertes Paket ankam.
                  (Default bei ankommenden Verbindungen.)


X.75 "x75"
----
Implementiert Ebene 2 des X75-Protokolls. Das Framing (Pr<50>fsumme, 1-Stopfen,
Interframezeichen etc.) wird von der Hardware auf der Karte erledigt.

:nk  1-7 (127) 1 Parameter "k" -- Anzahl der maximal ausstehenden
                 Datenbl<62>cke. (Die L<>nge dieser Bl<42>cke wird nicht
                 begrenzt -- siehe T70-Modul)
:wd              2-Byte-Befehlsw<73>rter: SABME, max(k) 127.
:nw              1-Byte-Befehlsw<73>rter: SABM, max(k) 7.
:n1  1-100    3  Parameter "N1" -- Anzahl der Wiederholungen von Poll-Frames,
                 bis ein Fehler angenommen wird.
:t1  1-100   10  Parameter "t1" -- Timeout f<>r unbest<73>tigte Daten- und
                 Poll-Frames in Zehntelsekunden.
:t3 1-1000  100  Parameter "t3" -- Timer f<>r Test, ob die Verbindung noch
                 aktiv ist. In Zehntelsekunden, mu<6D> > 2*t1 sein.
:ad 0-255 0-255  (dieser Parameter braucht zwei Wertangaben!)
        1     3  Adre<72>bytes f<>r Befehls- und Meldungsframes. Sollten
                 das niederwertige Bit gesetzt haben und verschieden sein.
                 Wegen Abw<62>rtskompatibilit<69>t mit dummen Implementierungen
                 werden "falsche" Einstellungen akzeptiert.
:po              Pollmodus -- l<>st beim Empfang einer RNR-Meldung sofort
                 einen RR/RNR-Befehl aus. F<>r Kompatibilit<69>t mit dummen
                 Gegenstellen, die vergessen, sich mit RR bereit zu melden,
                 nachdem sie RNR gesendet hatten.
:np              schaltet den Pollmodus ab (Default).
:cm 012348  1    wann die X75-"Verbindung" aufgebaut wird
            0    gar nicht -- es wird angenommen, die Verbindung existiert.
                 Zur Kompatibilit<69>t mit dummen Gegenstellen, die sich
                 auf die Steuerung im D-Kanal verlassen.
            1    Baldm<64>glichst (abgehend)
            2    Baldm<64>glichst (ankommend)
            3    Baldm<64>glichst (an- und abgehend)
            4    wenn der erste Datenblock zur <20>bertragung ansteht.
            8    gar nicht -- es werden UI-Frames verwendet.

pr_on
-----
Spezialmodul, um die "Verbindung hergestellt"-Kennung auf einem Stream
abzusenden, der nicht <20>ber ISDN arbeitet. Wird zB vom slipto-Programm
verwendet.


Verzeichnisstruktur der Sourcen
===================

alaw/       Streamsmodul f<>r alaw-Coder.
bin/        fertige Programme (Symlinks)
cards/      Treiber f<>r Karten.
 dumb/        .. f<>r dumme Karten (mit Siemens-Chipsatz).
config/     Konfigurationsteil.
fakeh/      Cisco-HDLC-Modul.
final/      Installationsteil; final/Makefile wird als letztes aufgerufen
include/    Includedateien (was sonst...)
ip_mon/     TCP/IP-Monitorprogramm nebst Streamstreiber/Modul.
                   Noch nicht verwendbar.
isdn_2/     Schicht-2-Treiber f<>r ISDN (D-Kanalsteuerung, B-Kanal-Routing).
isdn_3/     Schicht-3-Treiber (1TR6 etc.).
isdn_4/     Steuerprogramm (besagter wilder Hack).
ksupport/   Supportkram f<>r den Kernel, diverse Streamsmodule,
            Supportcode f<>r die ISDN-Protokollhandler.
reconnect/  Streamsmodul zum dynamischen Wiederaufbau einer Verbindung.
strslip/    Streamsmodul f<>r SLIP-Framing.
str_if/     Streamsmodul f<>r Anbindung an TCP/IP.
support/    Supportkram f<>r Anwendungsprogramme.
t70/        Streamsmodul f<>r T-70.
timer/      Streamsmodul zum Trennen einer Verbindung (Timeout).
v110/       Streamsmodul f<>r V.110. Momentan ungetestet.
van_j/      Streamsmodul f<>r VanJ-TCP/IP-Headerkompression. Funktioniert
            momentan nur auf gesicherten Verbindungen 100%ig.
x75/        Streamsmodul f<>r X.75-Handling.


Programme und -Optionen
=======================


isdn_4/master alias bin/isdn
----------------------------

Steuerprogramm f<>r den gesamten ISDN-Kram.

-d      Debugging; verhindert da<64> das Programm sich selber in den
        Hintergrund setzt.
-f dev  Steuerdevice anstelle von /dev/isdnmon.
-I      Debugbefehle werden von stdin gelesen.
-t      Testflag. Nicht verwenden.
-l      setzt ein strlog-Modul auf die Steuerverbindung. Debugging.
-L      setzt ein qinfo-Modul auf die Steuerverbindung. Debugging.
-w      setzt ein strlog-Modul auf die programminterne Verbindung zwischen
        dem eigentlichen Programm und dem ISDN-Level-3-Code. Debugging.
-x file Datei mit (internen) Steuerbefehlen, die nach dem vollst<73>ndigen Start
        des ISDN-Krams ausgef<65>hrt wird. Ungetestet.
file... Steuerdateien.


monitor
-------

Protokolliert die vom ip_mon-Modul gemeldeten IP-Daten.
-a      numerische Angabe der lokalen IP-Adressen.
-b      numerische Angabe der entfernten IP-Adressen.
-c      numerische Angabe der IP-Protokolle.
-l      Debugging; setzt strlog-Modul ein.

Monitor kann auch zum Blockieren von IP-Paketen verwendet werden; ungetestet.


slipto
------

Kontrollprogramm f<>r den TCP/IP-Kram. Macht bei Verwendung mit ISDN _kein_
"slip"; wenn jemand (zB ein Amiga mit KA9Q) auf SLIP besteht, mu<6D> das
"slip"-Modul via ML-Zeile explizit eingesetzt werden.

-d       eine "Default"-Route zur Gegenseite wird eingerichtet.
-m mtu   setzt die MTU auf den angegebenen Wert. (Die MRU ist auf 4000 Bytes
         begrenzt.)
-R ip    die IP-Nummer "ip" wird zur Gegenseite geroutet. (route -host)
-r ip    Das IP-Netz "ip" wird zur Gegenseite geroutet. (route -net)
-r ip:nm Das IP-Netz "ip" wird mit der Netmask "nm" zur Gegenseite geroutet.

Die folgenden Optionen werden _nicht_ im ISDN-Betrieb verwendet, sondern im
Standalonebetrieb mit anderen Streams-Treibern. Im ISDN-Betrieb m<>ssen
stattdessen die entsprechenden Module auf der ML-Konfigurationszeile
eingetragen werden.

-L       protokolliert den Dialog zum Modem.
-l       Debugging: setzt qinfo-Modul ein.
-ll       zus<75>tzlich count-Modul.
-lll       zus<75>tzlich strlog-Modul.
-M       setzt IP-Monitor-Modul ein.
-S       Betrieb auf synchroner Leitung: verwende kein "slip"-Modul.
-E       Autoenable; wenn slipto auf einer bestehenden Verbindung gestartet
         wird.
-o       schickt ATA zur Leitung und wartet auf CONNECT.
-p dev   <20>ffnet Device "dev". (Man verwende "/dev/tty" f<>r stdin/out.)
-v       verwende Van-Jacobsen-Headerkompression.
-f       verwende Cisco-HDLC-Header.

Die folgenden Parameter m<>ssen immer angegeben werden:

ip_loc   lokale IP-Nummer.
         Kann auch auf anderen Interfaces (Ethernet) verwendet werden!
ip_rem   IP-Nummer der Gegenstelle.
         Die beiden Nummern muessen nicht im gleichen Netz sein!

Hackers Corner
==============

Debuggingoptionen:
Das Masterprogramm schickt Debugkram nach stdout. Umleiten nach /dev/null
wenn's st<73>rt.

In isdn/cards/dumb/Config.c stehen ein paar DEBUG_*-Flags.

In isdn/config/config.data finden sich die Konstanten CONF_DEBUG und
CONF_MOD2, die das Verhalten von isdn_2/isdn_2.c kontrollieren.

Hinweis: Wenn alles funktioniert, kann man die Debuggerei getrost
abschalten. Allerdings ist dann die Fehlersuche so gut wie unm<6E>glich...


Module
======

strlog
------

protokolliert absolut alles mit, was <20>ber dieses Modul an Daten l<>uft.

"xstrlog" macht dasselbe wie "strlog", nur werden DATA-Pakete (also die
eigentlichen <20>bertragenen Informationen) nicht mitgeschrieben.


qinfo
-----

Gibt alle N Sekunden eine Meldung <20>ber den aktuellen Zustand des
Datenstroms vom ISDN-Modul zum Anwendungsprogramm aus. N<>tzlich, wenn
man sehen will, wo die Daten h<>ngenbleiben.
:tm      Zeit zwischen Meldungen, in Sekunden.


count
-----

Z<EFBFBD>hlt mit, wieviele Datenpakete durchlaufen und wie lang diese sind.


Systemmeldungen
===============
Diese werden zwischen dem "proto"-Modul und dem ISDN-Treiber ausgetauscht
und informieren diese und die dazwischenliegenden Module vom Zustand einer
Verbindung.
"->L2" und "->Cmd" deuten an, dass die Meldung in Richtung ISDN-Treiber oder
"proto"-Modul gesendet werden.

in   die Verbindung wird ankommend sein (->Cmd)
ou   die Verbindung wird abgehend sein (->Cmd)
os X Reserviert zus<75>tzlichen Pufferplatz am Anfang von Datenbl<62>cken.
     (Separat f<>r beide Richtungen, wird automatisch initiiert.)
     Module inkrementieren X, um die Zahl der Bytes, die sie selbst maximal
     als Header vor die Daten stellen, und reservieren eine entsprechende
     Anzahl beim Anfordern eines neuen Datenblocks.
     "os" signalisiert au<61>erdem, da<64> der Aufbau des Modulstacks abge-
     schlossen ist. Module k<>nnen sich also nach der Weitergabe dieser
     Meldung untereinander unterhalten, wenn n<>tig.
li   B-Kanal ankommend geschaltet, zB W<>hlton beim Telefon (->Cmd)
hl   B-Kanal-Durchschaltung akzeptiert (->L2)
co   B-Kanal bidirektional geschaltet (->Cmd)
hc   Verbindung hergestellt (->L2)

wi   Befehl zur Herstellung einer Unterbrechung (->Cmd)
is   Verbindung unterbrechen (->L2)
is   Verbindung ist unterbrochen (->Cmd)
hi   R<>ckmeldung: Verbindung unterbrochen(->L2)
wd   Befehl zum "sauberen" Abbau der Verbindung(->Cmd)
di   Verbindung abbauen (->L2)
di   Verbindung ist abgebaut (->Cmd)
hd   R<>ckmeldung: Verbindung ist getrennt, evtl wird NO CARRIER gemeldet.

Wer beobachten will, wie genau diese Meldungen transpoortiert werden,
verwende ein xstrlog-Modul.


Euro-ISDN: Bearer Capability und andere Feinheiten
=========

Die Informationselemente sind in mehrere Bl<42>cke aufgeteilt. Jeder Block
wird dadurch begrenzt, da<64> das h<>chstwertige Bit auf 1 steht. Die
weggelassenen Bytes haben Defaultwerte. Ich f<>hre hier die wichtigsten
Codierungen auf; der Rest steht in der Q.931. 

1  1AABBBBB      AA       Codierungsstandard
                 00       CCITT
                 BBBBB    Datenformat
                 00000    Sprache
                 01000    digitale Daten
                 10000    Audio, 3.1 kHz
2  1AABBBBB      AA       Modus
                 00       Standard
                 BBBBB    <20>bertragungsgeschwindigkeit
                 10000    64 kBit
3  x01AAAAA      AAAAA    Schicht-1-Protokoll
                 00001    V.110
                 00011    A-law Audio 
                 01000    V.120
                 01001    X.31 mit HDLC-Flags.

Hinter einem Hexstring kann ein weiterer String angegeben werden, der als
Maske dient, welche Bits bei ankommenden Rufen beachtet werden. Die h<>chst-
wertigen Bits haben dieselbe Bedeutung wie oben und k<>nnen zum Abk<62>rzen
verwendet werden. Siehe support/vectcmp.c.

Beispiel:
:vB 9090A3 EFFFFF   -- Sprache oder 3.1kHz Audio, f<>r den Anrufbeantworter
:vB 8890            -- (alle Bits signifikant) entspricht :sv 0700, f<>r
                       Datenverbindungen aus dem 1TR6-Raum

[ Falls jemand anders den Rest der relevanten Teile der Q.931 abtippen
  will, nur zu... ]

Ansonsten: Sich von der Gegenstelle anrufen zu lassen und die betreffenden
Daten einfach einzutragen ist wohl die einfachste Methode.