U-ISDN compiliert ohne Probleme, wenn man sich an die Spielregeln hält,
die auch in der DOKU beschrieben sind: erst make.isdn
als User aufrufen, danach nochmal als root. Sonst macht
er gewisse Dinge nicht, wie make depend etc.
In dem U-ISDN-Paket ist eine Beispielkonfiguration.
Konfigurationsdetails für Spezialfälle sind jeweils auch in der DOKU beschrieben.
Zusätzlich auf ftp.gmd.de .
Wenn beim Laden der Module die Meldung erscheint
the symbols from kernel 1.2.13 don't match 1.2.13
dann stimmt ziemlich wahrscheinlich die Ladereihenfolge
der Module nicht. Man muß sich auf jeden Fall streng an
die Reihenfolge in
/lib/modules/modules.isdn.all halten und darf
diese in der Datei auch nicht verändern, wenn man
einzelne Module herausnimmt, die man nicht braucht.
Beim Übersetzen des Pakets gibt es zumindest bis isdn-11 noch einen kleinen Fehler: modules.isdn.all wird vor Anlegen nicht gelöscht. Steigt man also von einer früheren Version um oder übersetzt alles noch einmal, steht das ganze Zeuch möglicherweise mehrfach in der Datei.
Meine ISDN-Karte reagiert nur auf die erste MSN, nicht auf die
anderen. Die MSN sind: 519556, 519557, 519558. Meine DL-Zeile lautet:
> DL Tel? +49=XXX-519556/ :pr 0 :sp 8 :pr 63
Was ist da los?
Man darf hier nicht die ganze Nummer eintragen, sondern nur den
gemeinsamen Teil aller MSN, also 51955/ (bei 1TR6: Nummer ohne
EAZ). In die P-Zeile des gewünschten Dienstes gehört unter :lr der
Rest der jeweiligen MSN (1TR6: die EAZ), also z.B. /6 für Login,
/7 für TCP etc.
Hat man drei völlig verschiedene MSNs, dann werden entsprechend viele DL-Zeilen eingetragen, wobei nur die erste Zeile Protokolle beinhaltet. Siehe DOKU.
Das bedeutet, daß auf dem D-Kanal etwas passiert, für das sich der
master nicht zuständig fühlt, beispielsweise ein Analoganruf auf
einem anderen Kanal. Kann man getrost ignorieren.
/dev/isdn/isdnxx-Devices? Die baut der master beim Hochfahren selber, nachdem er eine freie Major-Number gefunden hat.
Wie kann ich sicherstellen, das bei einer spaeteren Aufruestung auch
alle weiteren B-Kanaele unter einer Rufnummer zu erreichen sind (um die
Gesamtkapazitaet zu erhoehen und die Chance auf eine freie Leitung zu
steigern)?
Die Nummern haben mit den B-Kanälen eines S0-Anschlusses überhaupt nichts zu tun. Es kann passieren, daß zwei Leute auf zwei B-Kanälen über dieselbe Nummer gleichzeitig hereinkommen. Die Vermittlung sucht sich bei einem Anruf auf eine Deiner Nummern einen freien Kanal aus.
Ob es möglich ist, bei der Verwendung mehrerer S0-Anschlüsse die Telekom zu bewegen, alle unter einem gemeinsamen Satz MSN zu schalten, weiß ich nicht, ich kann es mir auch kaum vorstellen. Die Alternative wäre ein Anlagenanschluß unter Euro-ISDN, aber das kann U-ISDN (noch) nicht.
Am übersichtlichsten steuert folgende Zeile den
syslog:
kern.debug,local7.debug /var/log/isdnlog
Dann stehen alle für ISDN relevanten Informationen in
/var/log/isdnlog. Es empfiehlt sich, den
biglog-Patch aus patches einzuspielen, um den
syslog-Puffer zu vergrößern. Da aber der
syslogd jede Zeile mit einem Aufruf von
fsync() auf die Platte schreibt, kann das bei hoher
Last dazu führen, daß einzelne Log-Zeilen verloren
gehen. Sinnvollerweise übersetzt man auch noch den
syslogd neu und wirft die Zeile mit sync()
raus. Folgender Patch hilft beispielsweise beim
sysklogd-1.2:
--- syslogd.c.bak Wed Aug 16 08:42:11 1995
+++ syslogd.c Wed Aug 16 08:42:11 1995
@@ -773,7 +773,8 @@
(void) sprintf(line, "vmunix: ");
lp = line + strlen(line);
for (p = msg; *p != '\0'; ) {
- flags = SYNC_FILE | ADDDATE; /* fsync file after write */
+/* flags = SYNC_FILE | ADDDATE;*/ /* fsync file after write */
+ flags = ADDDATE; /* don't fsync file after write */
pri = DEFSPRI;
if (*p == '<') {
pri = 0;
In isdn/config/config.data gibt es eine Sektion, die da lautet:
#### =()<DEBUGGING @<DEBUGGING>@>()=
DEBUGGING DO
#### =()<CONF_DEBUG @<CONF_DEBUG>@>()=
CONF_MOD2 0x00
## 0x00, 0x33
#### =()<CONF_DEBUG @<CONF_DEBUG>@>()=
CONF_DEBUG 0x5006
## 0x5006, 0xf3df
Wenn man unter CONF_DEBUG eine Null einträgt, ist Stille. Ein
geeigneter Patch ist
isdn-shutup-diff
. Die gezeigten Werte (0x00 bzw. 0x5006) stellen
bereits einen Kompromiß zwischen Rauschen und nützlichem Logging dar.
Nein. Derzeit noch nicht. Matthias arbeitet aber daran.
>Habe die System conline und softwks so eingetragen, dasz nicht
>rausgewaehlt werden kann. Jetzt bekomme ich aber laufend folgende
>Meldungen:
>
>*85:5 softwks tcp * 23214 down/* 0 0 :is:dP:oc^:ou:dD:oc:si ERR FIND
>*85:5 softwks tcp * 23214 >up/* 0 0 :is:dP:oc^:ou:dD:oc:si -
>*85:5 softwks tcp * 23214 off/* 0 0 :is:dP:oc^:ou:dD:oc:si ERR FIND
Nein, ist korrekt. Das Teil will halt dorthin rauswählen (Paket steht an), kann bzw. darf aber nicht, weil keine Nummer zum Rauswählen gefunden, Interface wird für einige Zeit runtergenommen, um die Pakete wegzuwerfen.
Matthias schreibt:
ML ... frame x75 vanj str_if
Der x75 ist wichtig, denn ohne gesicherte Verbindung kann vanj Probleme machen.
Versucht man, die ganze Palette Urlichs-Module mit
rmmod wieder loszuwerden, streiken einige mit der
Meldung, sie seien noch sehr beschäftigt. Der Grund für
das Nichtfunktionieren: die Kernelfunktion
unregister_netdev() zum Löschen von
Netzwerk-Devices ist fehlerhaft, und Matthias
verzichtet zur Zeit darauf. Ab Kernelversion
1.3.irgendwas soll das wieder gehen. Im Moment hilft
nur ein Reboot.
Matthias schrieb hierzu am Fri, 29 Dec 1995:
>> Was machen denn Internet-Provider, die viele ISDN-Anschluesse bereitstellen
>> wollen. Kaufen die fuer jeden Anschlu_ eine ISDN-Karte oder benutzen
>> die gar kein Linux?
>
Nee, sie kaufen eine Binteckarte. Funktioniert. Kostet leider auch nicht
gerade wenig Geld. (Für mich nicht _so_ viel, aber ich hab auch den Treiber
geschrieben. ;-)
>Ist sowas in Planung?
>
Ihr wißt genau, was passieren muß, damit ich eine Karte unterstütze. (Bei
S2M kommt noch die Finanzierung des S2M für zwei Monate oder so dazu. ;-)
Nämlich: Hersteller wegen Leihkarte und Hard/Firmwaredoku nerven.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter