ATTENTION! The following header is not fully valid yet!
From: dl4mhk@lrz.uni-muenchen.de (Bernhard Hailer)
Newsgroups: de.alt.comm.isdn4linux,de.answers,news.answers
Subject: ISDN4linux-FAQ
Followup-To: de.alt.comm.isdn4linux
Summary: This posting describes what every reader of de.alt.comm.isdn4linux
ought to know about ISDN under Linux using isdn4linux.
It's in German, like the Newsgroup. An English version exists, see
i4l-faq.
Archive-name: de-i4l-faq
Posting-frequency: monthly
Last-modified: 18-Mar-97
URL: http://www.lrz-muenchen.de/~ui161ab/www/isdn/
+49 931 781464 Zyxel U-1496E V.32(bis), V.42(bis), Zyxel 19200
+49 931 781465 Atrie 1914A V.32(bis), V.42(bis), V32terbo
+49 931 781467 Atrie 1914A V.32(bis), V.42(bis), V32terbo
+49 931 781468 Atrie 1914A V.32(bis), V.42(bis), V32terbo
+49 931 79002055 Motorola 3400 V.32(bis), V.42(bis), V.34
+49 931 7840724 ICN X.75 2 B-Kanäle
+49 931 7841020 ICN X.75 2 B-Kanäle
+49 931 7841060 ICN X.75 2 B-Kanäle
+49 931 7841070 ICN X.75 2 B-Kanäle
+49 931 7841080 ICN X.75 2 B-Kanäle
ftp://freja.frontier.dk/linux/isdn4linux/ ftp://ftp.cs.tu-berlin.de/pub/net/isdn/isdn4linux/ ftp://ftp.fokus.gmd.de/.mount2/pub/Linux/isdn/isdn4linux/ ftp://ftp.franken.de/pub/isdn4linux/ ftp://ftp.germany.eu.net/pub/os/Linux/Local.EUnet/ISDN/isdn4linux/ ftp://ftp.kiss.de/pub/linux/isdn4linux/ ftp://ftp.leo.org/pub/comp/os/linux/isdn/isdn4linux/ ftp://ftp.lame.org/mirrors/isdn/ ftp://ftp.mathematik.th-darmstadt.de/pub/linux/mirrors/misc/isdn4linux/ ftp://ftp.nvg.unit.no/pub/linux/isdn/ ftp://ftp.pop.de/pub/local/linux/isdn/ ftp://ftp.rz.fh-hannover.de/pub/linux/local/isdn4linux/ ftp://ftp.rz.hu-berlin.de:/pub/linux/isdn4linux/ ftp://ftp.tu-dresden.de/pub/soft/isdn/isdn4linux/ ftp://ftp.uni-mainz.de/pub/internet/starter-kit/isdn/isdn4linux/ ftp://ftp.uni-wuppertal.de/pub/linux/isdn4linux/ ftp://ftp.xlink.net/pub/mirror.ftp.franken.de/isdn4linux/ ftp://fvkma.tu-graz.ac.at/pub/isdn4linux/ ftp://wildsau.idv.uni-linz.ac.at/pub/isdn4linux/
ISDN-Kernelsubsystem: /usr/src/linux/Documentation/isdn/README
ISDN-Steckkarte: /usr/src/linux/Documentation/isdn/README.<Karte>
Synchrones PPP: /usr/src/linux/Documentation/isdn/README.syncppp
/usr/src/linux/Documentation/isdn/README.syncPPP.FAQ
Voice capability: /usr/src/linux/Documentation/isdn/README.audio
ISDN Utilities: /usr/src/isdn4k-utils-<version>/README(.*)
Des weiteren existieren zu vielen Hilfsprogrammen Man-Pages!
In einer Suse-Distribution könnten u.U. noch folgende Informationen
hilfreich sein:
Synchrones PPP: /usr/doc/faq/faq/PPP-FAQ
Konfiguration Email: /usr/doc/howto/mini/Mail-Queue.gz
index isdn4linux - zeigt, welche Archive vorhanden sind
get isdn4linux <archivname> - holt das File <archivname>
Deutschland
Finnland
Frankreich
Italien
Niederlande
Norwegen
Österreich
Peru
Portugal
Schweden
Schweiz
Spanien
USA
* ITK ix1 micro V2.0 und V2.1
* Cisco 200
* ITK Columbus
* Teles S0-8
* Teles S0-16 und S0-16.2
(baugleich: Dr. Neuhaus Niccy 1016, Creatix 16/S0)
* Teles S0-16.3
* Teles S0-16.3 PNP
* Teles PCMCIA
* Creatix S0 PNP
* AVM A1 (Fritz!)
* ELSA Microlink PCC-16
* ELSA Microlink PCF
* ELSA Microlink PCF/pro (nur ISDN-Teil, nicht der V34 Modem Chip)
* ELSA Quickstep 1000
* ITK ix1-micro Rev.2
Erstes Ziel des HiSax Treibers war es mehr ISDN Karten unter i4l
verfügbar zu machen, dieses Ziel bleibt auch bestehen.
Zweitens soll er möglichst einfach konfiguriert werden können und dem
User keine funktionierende Karte vorgaukeln wenn es Hardware Probleme
gibt (IRQ, Reset Problem Teles). An den Hardwareproblemen selbst (PCI
IRQ, Int 12/15 usw.) kann ich auch nichts ändern, aber der Treiber
wird nicht geladen wenn sowas auftritt.
Drittens und dieser Teil ist erst angefangen, vollstendige
Überarbeitung der Statemaschinen um einen komplett DSS1 bzw. 1TR6
konformen Treiber zu bekommen, der eine Zulassung bestehen würde (das
heißt nicht, das ich ihn zulassen will oder kann).
Desweitern möchte ich,wenn möglich auch die US ISDN Protokolle
unterstützen, damit i4l mal aus Europa rauskommt.
Auch weitere l2/l3 Protokolle sollen rein (V110 ...), Standleitungs-
Unterstützung ..., eine Menge Arbeit, die ich nicht unbedingt allein
machen möchte.
Deshalb an alle die ein wenig von Programmierung und ISDN verstehen
(ich selbst hab im Januar das erste mal was von ISDN gehört und
beruflich auch nichts damit zu tun, d.h alles nebenbei gelernt), wer
Lust hat (was dabei glaube ich immer noch das wichtigste ist) melde
sich für die weitere Entwicklung.
1. Wahl ELSA
ELSA stellt im Gegensatz zu AVM die Spezifikation zur Verfügung.
2. Wahl Creatix PNP
Auch Creatix Mitarbeiter stehen Linux nicht vollkommen negativ
gegenueber ;-). Ist uebrigens eine Creatix Eigenentwicklung und
nicht mit der Teles 16.3 PNP identisch.
56k asynchron : nein
64k synchron : ja
128k synchron : ja (channel bundling - siehe nächste Frage)
* Welcome to Linux at eberhard.moenkeberg.de (LAN, 192.168.99.1).
Under ++49-551-7704103, ISDN NetCalls (HDLC-trans-rawip)
for 192.168.99.1 get accepted. You should come as 192.168.*.*
because sometimes my "default" route is not your way.
/ftp is exported for NFS; try "showmount -e".
You can login as "guest" without password.
FTP as "gast" with password "gast" avoids the restricted shell.
* Under ++49-551-7704102, a 28800 bps modem and a Creatix ISDN
card (HDLC only, not X.75) are listening for Logins.
There's a "gast" at +49 30 67 19 81 01 (X.75, mgetty). There's the
stones-html-page with pics in postscript to test downloading. Who
needs a target to call could use it.
Es gibt den Gast auf der +49 30 67198101 mit X.75, sofern nicht einer
der Tester mein ttyI erhängt hat, und auf der ...103 ein getty mit
HDLC.
Ich bekomme oft Patches - gegen die aktuell offizielle Release des
Quellcodes - bei denen ich Probleme bekomme, sie einzubinden.
Mein lokaler Quellcode hier ist manchmal zwei oder drei Versionen
weiter, wobei ich sie allerdings nicht releasen kann, weil er
unvollständig oder völlig ungeprüft ist etc.
Deshalb habe ich jetzt beschlossen, das CVS-Repository von
isdn4linux öffentlich zugänglich zu machen. Jetzt können Programmierer,
die einen Blick auf den Fortgang der Entwicklung werfen wollen, oder
Leute, die immer den allerneuesten Stand haben wollen, folgendermaßen
auf das CVS-Repository zugreifen:
1.) Man installiere GNU CVS (irgendeine Version >= 1.6 tut's).
2.) Man schreibe ein kleines Shellscript .cvsrsh im Homedir:
#!/bin/sh
exec rsh -l guest $*
3.) Man setze CVS_RSH auf dieses Script (z.B. CVS_RSH=~/.cvsrsh)
4.) Man setze CVS_ROOT auf oldhades.think.de:/i4ldev
(z.B. export CVS_ROOT=oldhades.think.de:/i4ldev)
5.) Man führe aus: "cvs -z9 checkout isdn"
-> Dies läßt einen Verzeichnisbaum im aktuellen Verzeichnis
entstehen. Unterhalb von isdn/ findet man die gleiche
Hierarchie wie im Linux-Source nebst einigen Scripten, um
den Inhalt in den Linux-Quellcodezweig zu kopieren/diffen.
Ähnlicher Zugang ist auch auf das Utility-Paket möglich, mit dem
Kommando:
cvs -z9 checkout isdn4k-utils
ABER VORSICHT! DAS NEUESTE MATERIAL IST MANCHMAL ZIEMLICH INSTABIL ODER
WENIGSTENS NICHT OHNE GUTE PROGRAMMIERKENNTNISSE COMPILIERBAR -
bitte keine Newbie-Fragen zu diesem Thema! Use the source, Luke!
Hinweis:
Natürlich ist der Zugriff Read-Only. Der Zugriff ist auf die
folgenden Kommandos beschränkt:
checkout
diff
export
status
update
Zur Benutzung dieser Befehle sehe sich die Dokumentation zu CVS an.
Leute, die das Entwicklerteam _ständig_ unterstützen wollen
(z.B. neue Treiber schreiben [oder FAQ-Mitarbeit! Die Red.]),
können einen echten Account zum vollständigen Zugriff erhalten.
Man schreibe mir in diesem Falle eine Mail.
In der dosemu.conf genügt z.B. der folgende Eintrag für einen
virtuellen com2-Port, der z.B. unter Telix oder Terminate läuft:
serial { com 2 device /dev/ttyI3 }
Auch der Zugriff über Fossil ist möglich, wenn fossil.com (beim dosemu
dabei) gestartet wird.
Getestet in den folgenden Konfigurationen:
- Kernel 2.0.21, Telestreiber inkl. Karstens patches
- Kernel 2.0.21, HiSax
Es läuft parallel. Und es läuft unter 2.0.X.
Beide ISDN-Pakete laden jedoch das Modul isdn.o, ansonsten ist der
Namensraum verschieden. Abhilfe: Urlichs isdn.o in uisdn.o umbenennen,
entsprechend /lib/modules/modules.isdn (oder wie immer das Ding heißt,
wo die Module drinstehen, und das das Skript ausliest) anpassen.
Freundlicherweise sind auch die Default-Namen der ISDN-devices
verschieden.
AOC-D ist die "Gebühreninformation während der Verbindung".
AOC-D ist die "Gebühreninformation nach der Verbindung". Dieses
Dienstemerkmal ist in Deutschland im "Komfort-Anschluß" enthalten.
CLIR ist ein Angebot des ISDN-Anbieters: man kann fallweise
die Übermittlung der eigenen Rufnummer an den Gesprächspartner
unterdrücken lassen. CLIR muß man beantragen, es ist (in Deutschland)
jedoch kostenlos. Hingegen kostet die fallweise Übermittlung
der Rufnummer Geld.
Auch COLP ist ein Angebot des ISDN-Anbieters. Man muß es beantragen,
aber es kostet (in Deutschland) 10.-- DM pro Monat extra. Wer COLP
beantragt hat, bekommt ein erweitertes Wählprotokoll über die
Leitung, welches man dann z.B. in der Tk-Anlage auswerten kann.
Derzeit wird an einer Möglichkeit gebastelt, das mit Hilfe einer
"verkehrtherum" angeschlossenen zweiten Teleskarte zu umgehen. Man
bekommt dann ganz ohne Gebühren mehr Informationen als mit laufendem
COLP. Das rechnet sich bald...
Die i4l-Entwickler haben sich zu einem Team zusammengeschlossen. Das
Tool "cvs" erlaubt es den Mitgliedern, relativ problemlos Patches
einfließen zu lassen. Der Werdegang des Projektes wird damit
ausgezeichnet dokumentiert, und es ist auch nicht schwierig, eine
ältere Version wieder herzustellen.
Ein sehr verbreitetes Low-Level-Protokoll.
Ein Siemens-Chip, der ähnlich ->ISAC auf vielen passiven ISDN-Karten
sitzt. Er übernimmt den seriellen Bus vom ISAC und demultiplext beim
Empfangen bzw. multiplext (d.h. fügt die Bits an der richtigen Stelle
ein) die B-Kanäle.
Ein Siemens-Chip, der ähnlich ->HSCX auf vielen passiven ISDN-Karten
sitzt. Er ist für "Level 1" zustaendig, sitzt also (beinahe) direkt an
der Leitung. Er kann das D-Kanalprotokoll handhaben und setzt die
S0-Daten auf einen speziellen seriellen Bus (IOM) um. Beim Senden
geht es umgekehrt.
Die lokale Vermittlungsstelle oder bei internen S0 die Anlage weist
jedem Endgerät automatisch oder fest eine TEI zu. Diese dient ganz
einfach zur Addressierung des D-Kanals. TEIs haben folgende Werte:
0- 63 feste TEIs (z.B wird 0 bei Anlagenanschlüssen verwendet)
64-126 automatisch zugewiesen
127 Rundruf an alle (z.B. bei hereinkommendem Anruf)
Eine TK-Anlage dient dazu, verschiedene interne Geräte an das
ISDN-Netz anzuschließen. Meist handelt es sich dabei um analoge
Geräte, die nicht direkt ans ISDN-Netz angeschlossen werden können.
Die TK-Anlage kann jedoch auch einen internen digitalen S0-Bus zur
Verfügung stellen, an dem dann ISDN-Geräte angeschlossen werden können.
Probiere doch mal Port 0x080h, DIP-SW in die nicht dokumentierte
Position!
1. HiSax muß in den Kernel gepatcht werden
(Achtung: den "-pn" Parameter verwenden!)
2. Mit "make menuconfig" (oder "make config") werden folgende Kernel-
Optionen eingestellt:
* ISDN = "M" (als Modul - PNP funktioniert sonst nicht!)
* HiSax = "M" (als Modul - PNP funktioniert sonst nicht!)
* 16.3/PNP support
* EURO support
3. Kernel und Module kompilieren & installieren, depmod. (Reboot!)
4. Die Konfiguration der PNP-Karte auslesen mit:
"pnpdump > /etc/isapnp.conf".
5. Die Konfigurationsdatei "/etc/isapnp.conf" muß von Hand angepaßt
werden. Folgende Werte sind zu setzen:
INT0 - der von der Karte verwendete Interrupt
(Default bei Teles 16.3 PNP: 10)
IO0, IO1 - die von der Karte verwendeten IO-Ports
(Default bei Teles 16.3 PNP: 0x580 bzw. 0x180)
(Achtung: diese Werte müssen 64bit aligned sein! Frühe
Versionen der PNP-Karten schlagen evtl. falsche Werte vor!)
6. Aktivieren der Konfiguration per:
"isapnp /etc/isapnp.conf"
(muß bei jedem Booten gestartet werden)
7. Nun kann das HiSax-Modul gestartet werden mit:
"modprobe hisax io=4,<P>,<INT>,<IO0>,<IO1>"
4 - PNP-Karte
<P> - Protokoll:
2 - für Euro-ISDN (normalerweise)
1 - für 1TR6-ISDN (deutscher Vorgänger von Euro-ISDN)
<INT> - der in /etc/isapnp.conf bei INT0 eingetragene Wert
<IO0> - der in /etc/isapnp.conf bei IO0 eingetragene Wert
<IO1> - der in /etc/isapnp.conf bei IO1 eingetragene Wert
Ich habe bei meinem Rechner 2 Runlevel definiert (3 und 4), 3 läuft
ohne isdn, 4 mit. Wenn ich ISDN mitsamt den dazugehörigen Prozessen
wie ipppd, isdnlog und mgetty stoppen will, gebe ich als root "init 3"
ein, zum Starten dann "init 4". Init sorgt dann dafür, daß über
"/sbin/init.d/i4l start" bzw. "... stop" die notwendigen Dinge
angestoßen werden.
Das ist kein Problem - machen wir schon lange.
- Einfach ein isdn-Interface anlegen
- wichtig dabei: encap isdnX ethernet
Den Rest macht "mars_nwe" (incl. Routing), ein vollständiger
Novell-Netware-Emulator. Den gibt es z.B. auf:
ftp://ftp.gwdg.de/pub/linux/misc/ncpfs/mars_nwe-0.98.pl7.tgz
Das Entladen der Module, wenn sie eine Minute lang nicht mehr
gebraucht wurden, macht der kerneld defaultmäßig. Das ist bei Modulen
wie Gerätetreibern ala Floppy etc. kein Problem; bei Treibern aber,
die irgendwelche Einstellungen über einen längeren Zeitraum behalten
müssen, aber doch. Z.Bsp. sind die Einstellung des Mixers bei einer
Soundkarte oder die Konfiguration von Dialin- und Dialout-Parametern
beim ISDN-Treiber solche.
Das Entladen des ISDN-Treibers zerstört z.B. auch das IP-Interface
ippp0 oder isdn0. Die Einträge in der IP-Layer des Kernels gehen dann
ins Leere. Wenn man mal in die Start-Up-Skripten von i4l reinschaut,
wird man eine ganze Menge Dinge finden, die mit isdnctrl etc.
eingestellt werden; die müßte der kerneld bei jedem erneuten Laden
wieder einstellen lassen. Auch der Status des D-Kanals auf ISDN könnte
zu den Dingen gehören, die durch das Entladen verloren gehen.
Also mein Tip ist, nicht vom kerneld laden und entladen lassen,
sondern beim Systemstart laden und nur entladen, wenn es aus
technischen Gründen nötig ist.
Genau für diesen Zweck gibt es seit geraumer Zeit in dem Modules
Paket eine Erweiterung, die es erlaubt, eine Datenbank mit
Zustandsinformationen über die Treiber zu installieren. Leider wird
dieses Feature bisher kaum oder gar nicht von den Modulen
unterstützt.
Als Alternative bieten sich auch solche Optionen wie der
"post-install" Hook in der "/etc/conf.modules" an. Es ist dann zwar
erforderlich, daß man von Hand die passenden Skripts schreibt, aber
im Prinzip funktioniert das dann genauso gut wie, wenn das Modul eine
automatische Initialisierung über eine Datenbank durchführen würde.
Nachdem auch der Patch vom Eberhard Moenkeberg auf ftp.gwdg.de kein
cisco-hdlc ausdumpen kann, habe ich hier mal einen isdn-patch fuer
tcpdump-3.0.4 gemacht, der das Interface fragt, was fuer eine
Encapsulation es benutzt und sich entsprechend einstellt. Das Teil ist
gegen eine tcpdump-3.0.4-1.tar.gz Distribution, wie sie z.B. auf
ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/tools liegt,
gemacht. Dieser Patch erkennt RAW-IP, ISDN-IP und CISCO-HDLC und kann
die Pakete entspr. dumpen.
Es gibt doch isdn4k-utils-2.0/tcpdump-3.0.3-isdn.diff ! Damit klappts,
sofern man noch selbst Hand anlegt:
In der Datei tcpdump-3.0.3-isdn/libpcap-0.0/pcap-linux.c steht nach
dem Patch irgendwo folgendes:
else if (strncmp("ppp", device, 3) == 0)
Entweder man nennt seine ppp-devices irgendwie pppX statt ipppX, oder
ändert die Zeile z.B. in
else if (strncmp("ippp", device, 4) == 0)
^^^^ ^^
Dann erkennt tcpdump auch sync-ppp. Jedenfalls bei mir.
chgrp isdn /dev/ttyI* /dev/cui*
chmod o-rw /dev/ttyI* /dev/cui*
* Telefon
* Analogmodem (als Fax, Anrufbeantworter und Daten-Modem genutzt)
* Dial-In für X.75 (Modememulation)
* Dial-In mit SyncPPP
- Telefon (Sprache)
- VBOX (Sprache, klar)
- X.75-Login (mgetty /dev/ttyI?)
- IP-Interface für IP-Verbindungen zu anderen Rechnern?
Die erste ist von der Anlage mitgegeben und ungeprüft.
Die zweite ist die von der Telekom vergebene.
Ich hatte hier auch schon solche Anrufe, wo ein Siemens-
Mitabeiter aus München hier anrief und mit einer ellenlangen
Nummer kam, deren Vorwahl 030 (Berlin) war.
Ich rief daraufhin die Telekom an, was das denn solle, und
die wußten auch erst nichts, dann fanden sie wen kompetentes,
der sagte, daß das ginge.
"CLIP no screening". Der Anrufer hat das (kostenpflichtige und nur am
Komfort-Anlagenanschluss(!) verfügbare) Feature, welches ihm die
Übertragung einer beliebigen Caller ID erlaubt.
Die eigentlich benutzten Adressen sind:
isac 980
hscx 180/580
cfg d80
Zur Verwirrung kommt es aufgrund eines Mißverständnisses: Teles
gibt die HSCX0-Adresse als Referenz an, während der alte Teles-Treiber
die cfg-Adresse benötigt. Da die Benutzer dadurch verwirrt waren,
können die beiden Treiber nun beide Adressen handhaben (und die
Benutzer sind dadurch erneut verwirrt ;-))
#define NEW_GET_FREE_PAGES
/* #define NEW_GET_FREE_PAGES */
/* #define NEW_TIMERS */
struct IsdnCard cards[]={
{ (byte *)0xd0000,11,0xd00,NULL } ,
/* 1. Karte */ { (byte *)0xd8000,10,0xe80,NULL } ,
/* 2. Karte */ ...
/* u.s.w. */
};
# load modules
/sbin/modprobe isdn.o
echo "teles0 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles0 teles_id=teles0
io=0xd0000,5,0xd80,2
echo "teles1 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles1 teles_id=teles1
io=0xd2000,9,0xe80,2
echo "teles2 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles2 teles_id=teles2
io=0xd4000,12,0xf80,2
/sbin/lsmod | grep teles > /dev/null
Wenn Du was über Teles's Geschäftspraktiken lesen willst, schau dir
http://www.inx.de/~chris/isdn.htm an.
Bei HiSax wird die Hardware und das IRQ-Verhalten gecheckt, so daß der
Treiber nur dann geladen wird, wenn er Zugriff auf die Register hat und
Interrupts generiert werden. ALSO:
2*Laden erledigt
HSCX version 0 oder F erledigt
BUSY bei minicom u.ä. nur noch :
* REAL BUSY
* keine MSN/EAZ
* Kabel/Leitungs Probleme
Es kann nie schaden, die orginal Kernel-Sources erst mal zu sichern.
Dann ins /usr/src/linux (da sollte sich der aktuelle Source befinden)
gehen. Jetzt der Patch selbst:
zcat HiSax_1.1.patch.gz |patch -p1 >& /tmp/HiSax.log
Das -p1 ist sehr wichtig, da sonst alle files aus neuen directories in
/usr/src/linux landen.
Dann /tmp/HiSax.log nach errors/warnings/rejects durchsuchen, wenn
welche auftreten die entsprechenden files anschauen und gegebenfalls
von Hand korrigieren.
Wer Gnu Patch besitzt, kann auch "... |patch -s -p1 " verwenden. Dann
werden nur die Fehler berichtet. Und wer ein log will, kann auch
"... |patch -s -p1 | tee /tmp/HiSax.log" machen. Damit bekommt man
zusätzlich zur Bildschirmausgabe ein Logfile.
Die Patches werde ich bis zur nächsten Version mit Buchstaben
"numerieren" und auch auf ftp ablegen.
1. Die o.g. Aussage ist nicht ganz korrekt:
if ((channel &1)+1 == B-channel )
2. Ich beschreib den Bug mal anders rum: Wenn gerade B-channel 1 von
einem anderen ISDN Gerät belegt ist und i4l wählt raus bekommt der
logische channel 0 von der VST den B-channel 2 zugewiesen.
---> geht
Das andere ISDN Gerät hängt auf.
Es kommt zusätzlich ein Ruf für i4l rein,natürlich für B-channel 1.
Da aber channel 0 belegt ist und es eine feste Zuordnung
B1->chan 0,2,4...
B2->chan 1,3,5... gibt wird der call nicht angenommen.
(chan 2,3 gibt es bei 2 Karten usw.)
Das ist zwar relativ selten kommt aber vor und wird demnächst gefixed
(wenn mir was Geniales einfällt).
Leerlauf l1 ist down
=> beide LED blinken ca. 1s an 1s aus.
l1 ist aktiviert (auch durch Telefon oder ä.)
=> Wechselblinken 0.5 gelb 0.5 grün
Betrieb
=> 1.5 an 0.5 aus
grün HSCX A aktiv
gelb HSCX B aktiv
Daß die ständig blinken hat die Ursache, das ich so bei der
Entwicklung sofort gesehen habe, daß die Karte hängt.
Thinking Objects Software GmbH
Obere Heerbergstr. 17
97078 Würzburg
Tel: 0931-2877950
Fax: 0931-2877951
email isdn-support@think.de
WWW http://www.think.de/
/sbin/insmod -m /lib/modules/1.2.13/misc/isdn.o >/etc/isdn.map
/sbin/insmod -m /lib/modules/1.2.13/misc/icn.o >/etc/icn.map
/sbin/insmod -m -o icn2 /lib/modules/1.2.13/misc/icn.o >/etc/icn2.map
/sbin/insmod -m /lib/modules/`uname -r`/misc/isdn.o > /etc/isdn.map
#
# ICN-2B, default port und mem (0x320, 0xd0000)
#
/sbin/insmod -m /lib/modules/`uname
-r`/misc/icn.o icn_id=icn0 > /etc/icn.map
#
# ICN-4B hinzufügen auf port 0x328
#
/sbin/icnctrl add 0x328 icn1 icn2
#
# Noch eine ICN-4B auf port 0x300
#
/sbin/icnctrl add 0x300 icn3 icn4
#
# Firmware laden
# ICN-2B: 1TR6
# 1. ICN-4B, beide S0 EDSS1
# 2. ICN-4B, 1. S0: 1TR6, 2. S0: EDSS1
#
/sbin/icnctrl -d icn0
load /etc/loadpg.bin /etc/pc_1t_ca.bin
/sbin/icnctrl -d icn1
load /etc/loadpg.bin /etc/pc_eu_ca.bin /etc/pc_eu_ca.bin
/sbin/icnctrl -d icn3
load /etc/loadpg.bin /etc/pc_1t_ca.bin /etc/pc_eu_ca.bin
Ich verwende folgendes Skript um die Karte zu "starten":
#!/bin/sh
#
# load modules
/sbin/modprobe isdn.o
/sbin/modprobe icn.o icn_id=icn0 icn_id2=icn2
# ^^^^^^^^^^^^
# Wichtig hierbei ist die Angabe von
# icn_id2. Hieran erkennt der Treiber,
# daß eine 4B verwendet werden soll.
#
# download firmload
cd /usr/src/isdn4k-utils-1.3.97/icn
icnctrl load download/loadpg.bin download/pc_1t_ca.bin
download/pc_1t_ca.bin
/sbin/isdnctrl verbose 2
modprobe icn icn_id=line0 icn_id2=line1 icnctrl io 0xd0000 0x340
icnctrl add 0x340 line0 line1
icnctrl load /sw/linux-i386/isdn4kutils-2.0.0/lib/loadpg.bin
/sw/linux-i386/isdn4kutils-2.0.0/lib/pc_1t_ca.bin
/sw/linux-i386/isdn4kutils-2.0.0/lib/pc_1t_ca.bin
Für EDSS1:
DRV1.11EC-Q.931-CAPI-CNS-BETA-15.07.95,BRV2.3
Für 1TR6:
DRV1.01TC-1TR6-CAPI-CNS-BETA-03.05.95,BRV2.3
Auf i4l-Seite Auf ISPA-Seite
====================================================
isdnctrl l2_prot isdn0 hdlc \
isdnctrl l3_prot isdn0 trans > -h0
isdnctrl encap isdn0 rawip /
----------------------------------------------------
isdnctrl l2_prot isdn0 hdlc \
isdnctrl l3_prot isdn0 trans > -h1
isdnctrl encap isdn0 uihdlc /
----------------------------------------------------
isdnctrl l2_prot isdn0 x75i \
isdnctrl l3_prot isdn0 trans > -l0
isdnctrl encap isdn0 rawip /
----------------------------------------------------
isdnctrl l2_prot isdn0 x75i \
isdnctrl l3_prot isdn0 trans > -l1
isdnctrl encap isdn0 uihdlc /
----------------------------------------------------
DFÜ-Netzwerk: ja. Es könnte noch eine andere Möglichkeit mit CINDI,
WISPA u.ä. von Herbert Hahnewinkel (Kosten ca 80 DM pro Lizenz, und
jeder User braucht dann eine) geben, aber das Geld habe ich nicht
ausgegeben.
AVMPort (Capi-Modememulation für Win' 95 verwenden, wichtig: auf der
Win 0.95 "Anmelden am Netzwerk" einschalten.
Systemsteuerung/Software/Diskette CD-ROM Admin/Apptools/Dscript
- Scriptverwaltung für DFÜ-Netzwerke (siehe nach der Installation
Start/Programme/Zubehör)
Damit das Script was empfängt, bei ISDN Echo einschalten. Bei AVMPort
geht das mit E1 im Initstring.
Wenn Du den Mac anrufst, stellt er sich auf das Protokoll (X.75 oder
HDLC) ein. Wenn er Dich anruft, muß er das Protokoll explizit angeben
(z.B. durch Anfügen eines "X" für X.75) an die Rufnummer - sonst ruft
der Mac womöglich mit dem Leonardo-Protokoll an.
isdnctrl l2_prot <interface> hdlc
isdnctrl l3_prot <interface> trans
isdnctrl encap <interface> cisco-h
isdnctrl addif <interface>
Seit Cisco-IOS 11.0.x (x = 7 ist das einzige, was ich kenne) habe ich
keine Probleme mehr mit Cisco <-> HDLC <-> Nicht-Cisco. Das gilt
sowohl für netgw als auch i4l als auch Banzai! an der Gegenstelle,
wobei allerdings die jeweiligen speziellen Cisco-HDLC-Optionen wichtig
sind.
Wir hatten bis gestern hier Probleme mit AVM+W95 und Mini-Port-Treiber
(PPP m. PAP). Der Ascend hat abgenommen und 3-4 sec später aufgelegt.
Im Ascend Log stand nur Call refused, was aber nicht stimmte, da der
Ascend abgehoben hat...
Durch eine neue Firmware auf dem Ascend (4.6C+) statt der 4.6B+p2 ist
das Problem wohl weg.
Da wir davor ein anderes RACK hatten (von ITK) welches dieses Verhalten
beim Kunden nicht zeigte, gehe ich mal davon aus, daß es der
Ascend war. Neue Firmware für den Ascend gibts unter
ftp://ftp.ascend.com/
oder
ftp://ftp.ascend.de/
wobei man hier höllisch aufpassen muß, daß man das richtige Image
nimmt :-)
subscribe [meine mail-alias-adresse] ascend-users-de
subscribe ascend-users-de
Es gibt auch eine weitaus besser besuchte Mailingliste zum Ascend.
Diese ist allerdings in englisch (dafuer schreiben und lesen dort
auch Ascend-Techniker mit).
Anmelden kann man sich unter
majordomo@bungi.com
Im Body dann:
subscribe ascend-users
Kann sein, dass das mit dem Authentication Type so funktioniert, ich
nehme für sowas jedoch als Password "Ascend-CLID".
Ein Eintrag im users-file muß folgendermaßen aufgebaut sein:
69123456 Password="Ascend-CLID"
User-Name = "Username_fuer_Abrechnung"
User-Service = Framed-User
Also als Username die Caller-ID, als Password "Ascend-CLID".
[...] Ich hab hier mehrmals täglich saubere Verbindungen zu einem
EL310, ich polle per ifcico FIDO darüber. Hier mal die Config des
Elink: ati Elink 310 Version 1.36 OK ati4
Baudrate: 115k2,N
SIN unbekannt: Ruf annehmen
Anschaltung: EDSS1
SIN ungleich &B: Ruf annehmen
Betriebsart: X.75
SIN gesendet: neutral
Mehrfachrufnummer: 980031
E1 M1 Q0 V1 X2 &B049 &C1 &D2 &R0 &S1
\A3 \J0 \N3 \Q3 \V1 %A013 %C1 %F1 FCLASS=000
S00=000 S01=000 S02=043 S03=013
S04=010 S05=008 S06=002 S07=040
S08=003 S09=000 S10=007 S11=000
S12=050 S13=01010000B S14=10011010B S15=00001110B
S16=10110011B S17=049 S18=013 S19=003
S20=000 S21=00000100B S22=000 S23=006
S24=120 S25=128 S26=016 S27=002
S28=003 S29=128 S30=000 S31=000
OK
(dasselbe funktioniert natürlich auch per Modem. Nur sieht da die
Initialisierungs-Sequenz natürlich anders aus.)
Ad 1: Man besorge sich diald. Keine Ahnung, wo man das Paket
findet - Archie fragen (diald ist dazu gedacht, eine
Defaultroute auf eine noch garnicht physikalisch be-
stehende SLIP oder CSLIP-Verbindung zu legen; werden
dann Pakete an dieses Pseudo-Interface geschickt, stellt
diald die (C)SLIP-Verbindung her; welche Pakete einen
Verbindungsaufbau auslösen, und wann/wie die Verbindung
wieder abgebaut wird, ist alles konfigurierbar.) Dann
installiere man das Binary und die Config-Files (man
kann die im Paket enthaltenen Muster so übernehmen;
nur, wenn z.B. ein PING einen Verbindungsaufbau bewirken
soll, muß man minimal ändern; ggf. kann man auch Timeouts
anpassen - halt etwas herumprobieren).
Ad 2: Man nehme einen Kernel mit integriertem SLIP/CSLIP oder
SLIP/CSLIP als Module (die natürlich geladen sein müssen)
Ad 3: Isdn4Linux muß natürlich auch installiert sein; wichtig
ist die Modem-Emulation (ttyIx).
Ad 4: Man starte den diald, z.B. mit folgendem Script (heißt bei
mir /etc/rc.d/rc.diald.t-online):
/usr/sbin/diald /dev/ttyI2 -m aslip local 192.168.90.9
remote 192.168.90.1 defaultroute dynamic modem crtscts
lock speed 38400 connect "chat -v -f /etc/diald/t-online"
mtu 1500 dslip-mode local-remote
(sinnvollerweise schreibt man das in eine Zeile :-)
Ad 5: Man erzeuge das Script, das bei mir "etc/diald/t-online"
heißt. Sieht ungefähr so aus:
TIMEOUT 30
ABORT "NO CARRIER"
ABORT ERROR
ABORT "NO DIALTONE"
ABORT BUSY
ABORT "NO ANSWER"
ABORT "NO MSN/EAZ"
"" ATZ
OK AT&B2000&E<MyMSN>&X1
OK ATD01910
CONNECT .
"[?25h" <ZugangsKennung>\c
"[?25h" ""
"[?25h" ""
"[?25h" <passwort>
"[?25h" *53#\c
"[?25h" *190144100#\c
"[?25h" 19\c
"STATUS OK" LIN
"" "OK"
Darin müssen natürlich einige "Platzhalter" ersetzt werden:
<MyMSN> ist die MSN, mit der man in die weite Welt hinauswill.
<Zugangskennung>: Das meist mit "000..." beginnende Zahlenmonster,
welches die Telekom einem genannt hat.
<passwort>: Das Zugangspasswort eben
In obigem Musterscript wird davon ausgegangen, daß Anschluß-
und Mitbenutzernummer dem auf der Login-Seite vorgegebenem
Default entsprechen. Ist das nicht der Fall, muß man halt
die beiden Zeilen vor "[?25h" <passwort> entsprechend anpassen
(gibt man eine Mitbenutzernummer der Art "0003" an, sollte z.B.
die Zeile vor "[?25h" <passwort> lauten:
"[?25h" 0003\c
(denn das Eingabefeld ist nach "0003" voll, es darf kein CR mehr
folgen))
Wenn der diald läuft, sollte man urplötzlich über ein Interface
"sl0" verfügen (ifconfig fragen), und die Defaultroute sollte genau
darauf zeigen (route -n gibt Aufschluß; ohne "-n" würde "route"
versuchen, die Phantasie-IP-Adressen, die man anfangs angegeben hat
(und die später von "echten" überschrieben werden) aufzulösen - muß
ja nicht sein).
Oh, wer nicht nur mit IP-Adressen arbeitet, sondern erfolgreich auch
z.B. "ftp stp.sunsite.edu" probieren will, sollte natürlich in
/etc/resolv.conf einen Nameserver eingetragen haben (der/einer der
Telekom hat die IP-Nummer 194.25.2.129).
So, und nun Ftp, Telnet, Netscape, wasweißich starten. Das war's
Übrigens: Der Diald schreibt Romane ins Syslog. Man kann den gesamten
Login-Vorgang da nachlesen, auch wenn's chaotisch aussieht. Klappt ein
Request nicht, sollte man den diald mit "kill" erwürgen (Routen werden
automatisch gelöscht) und im Syslog nachschauen. Da können Sachen
stehen wie "Zur Zeit keine verbindung möglich" - dann ist das Internet-
Gateway der Telekom down. Oder man stellt fest, daß irgendwas mit dem
Login nicht klappte - Vorsicht: Nach drei Fehl- Logins muß der Zugang
von der Telekom "entsperrt" werden; das kann man per Telefon oder
direkt von BTX aus erbitten (einfach per Terminalprogramm, z.B. seyon
oder minicom, 01910 wählen, langsam per Hand durch den Login-Screen
gehen und die Anweisungen befolgen)
In der geschwätzigen chat-Version gibt es einen kleinen Fehler in
logf(): es wird solange in einen 256 Byte Puffer geschrieben, bis ein
Zeilenumbruch kommt. t-offline sendet aber deutlich mehr Bytes für die
Anmeldeseite ... Also entweder chat ohne -v aufrufen oder den Puffer
vergrößern (am besten mit Füllstandsüberprüfung).
* Kein Handshaking mehr
=> schneller Verbindungsaufbau
* Authorisierung per Caller Id
=> schnell, sicher, ohne Paßwort
* Fixe IP-Adresse
=> eine abgebrochene Verbindung kann nach Wiedereinwahl
fortgesetzt werden
* Höherer Datendurchsatz
* Hohe Stabilität (kleiner Treiber => kaum Bugs)
* Kein Handshaking mehr
=> Konfiguration muß vorher stattfinden (IP-Adressen,...)
=> sinnvoll nur für maximal einen Provider gleichzeitig einsetzbar
* Authorisierung kann nur per Caller Id erfolgen
=> Einwahl nur vom eigenen Anschluß möglich
* Fixe IP-Adresse
=> muß vorher bekannt sein, höherer Verbrauch von IP-Adressen,
keine dynamische Adreßvergabe möglich
tail -f /var/log/messages |
awk '/isdn0 connected/ { system ("ip-up") }
/hangup isdn0/ { system ("ip-down") } '
(Die folgenden Fragen entstammen zumeist der syncPPP-FAQ von Michael Hipp.)
#
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
[...]
# PPPD for asyncPPP over ISDN
i1:45:respawn:/usr/sbin/pppd -detach silent noipdefault /dev/ttyI0
(Die folgenden Fragen entstammen zumeist der syncPPP-FAQ von Michael Hipp.)
/sbin/isdnctrl encap ippp0 syncppp
"isdnctrl pppbind <interface> <Nummer>"
"isdnctrl pppbind ippp5 2"
/sbin/ipppd :$REMOTE noipdefault /dev/ippp0
lcp-restart 1
1. dein LAN ist ein offizielles Class C Netz mit im Internet gültigen
IP adressen.
Der Fall ist am einfachsten zu konfigurieren, du gibst jeder
Netzwerkkarte in dem Netz eine dieser IP adressen und legst eine
Default Route auf deine ISDN Karte, die ins Internet zu deinem
Provider führt.
2. Du möchtest aus deinem LAN heraus nur http ins Internet machen.
In dem fall kannst du dir für dein LAN IP adressen ausdenken,
die einzige offizielle IP Adresse ist die, die der ISDN Karte
zugewiesen wird. auf deinem linux isdn router mußt du einen
Proxy Server installieren, der bei deinen Browsern auch
eingetragen wird. Du brauchst in dem Fall keine Default Routen.
3. Du möchtest dich immer nur aus dem LAN auf deinem Linux ISDN
Router einloggen und VON DORT deine Arbeit im Internet verrichten.
Das ist noch einfacher, denn dann mußt du nicht einmal einen
Proxy Server.
Den drei Möglichkeiten würde ich noch eine vierte hinzufügen. Selber
hab ich es zwar noch nicht ausprobiert (da ich die erwähnte 1.
Möglichkeit bevorzuge und ein Class-C-Subnetz habe, hehe ;) aber ich
weiß von einem Freund, daß er nach einigem Tüfteln am Linux-Kernel
dann tatsächlich das IP-Masquerading hinbekommen hat.
Das funzt irgendwie soähnlich wie ein proxy (wenn man den
ip-versteck-effekt betrachtet). Bietet natürlich kein Caching,
maskeriert aber nach aussen hin alle internen Klau-IPs ;) mit der
einen offiziellen des ISDN-Interface. Frag mich nicht, wie da
irgendein Routing hinhaut, aber es geht...
Wenn ich mich nicht irre, hat mein Freund sogar mit einer dynamischen
IP maskeriert ?!
Die nachfolgende Anleitung wurde von Rainer May
<r_may@khavi.desaster.heide.de> zusammengestellt.
Prompt for development and/or incomplete code/drivers Y
Enable loadable module support Y
Networking support Y
Network firewalls Y
TCP/IP networking Y
IP: forwarding/gatewaying Y
IP: firewalling Y
IP: masquerading Y
PPP (point-to-point) support (wenn PPP zum Provider) Y
SLIP (serial line) support Y
Ethernet (10 or 100Mbit) (oder Arcnet oder ...) Y
ISDN support [1] M
Support synchronous PPP (wenn ipppd benutzt wird) Y
HiSax SiemensChipSet driver support M
(dann den HiSax für die ISDN Karte wählen)
([1] Wer mag, kann die ISDN-Treiber natürlich auch direkt in den
Kernel einbauen, anstatt sie als Module zu verwenden.)
* Das ISDN-Subsystem läuft, d.h., von Linux aus kann eine Verbindung
zum Provider hergestellt werden.
* Das lokale Netzwerk (Ethernet usw.) läuft auch, vorzugsweise unter
Verwendung "freier" IP-Adressen (z.B. 192.168.xx.xx), und der Linux-
Host kann von allen anderen Rechnern im LAN erreicht werden (z.B.
per ping).
* Zugriffe von einem beliebigen Rechner im LAN auf eine nicht-lokale
IP-Adresse sollen den Linux-Router veranlassen, eine Verbindung zum
Provider aufzubauen; und
* Der Linux-Router soll zwar die Rechner im LAN mit dem Provider
verbinden, diesem gegenüber aber verheimlichen, daß nicht der Router
selbst Empfänger/Absender der entsprechenden IP-Pakete ist.
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
Hmm. So wie ich das sehe, passiert da gar nichts. Grund: Die Rechner im
lokalen Netz unterhalten sich ja direkt über die fake-Adressen im
192.168.123.xxx-Netz. Zum Beweis kannst Du Deine Linux-Kiste einfach
abschalten (naja OK, shutdown...), und die lokalen Rechner werden sich
weiter unterhalten können. Also wird da auch nix masqueraded.
Der Hintergrund: Masquerading ist eine FORWARD Rule im Firewall und
wird daher auch nur beim FORWARDEN (wörtlich zu nehmen: WEITERleiten)
verwendet.
Netz-intern wird nichts geforwarded und deshalb auch nichts
masqueraded, solange Du nur eine Netzwerkkarte hast. Bei mehreren
Karten hast Du jedoch recht: Hier sollte man entsprechende Routing-
und auch ipfwadm-Einträge vornehmen.
* Man verwendet synchrones PPP für die Verbindung zum Provider, also
den "ipppd". Dann ist nichts weiter zu tun als dafür zu sorgen, daß
immer die Default-Route des Routers auf das entsprechende ipppx-
Interface weist. Vorsicht: Beim Verbindungsabbau löscht der Kernel
diese Route!
Sie muß also z.B. in der Datei /etc/ppp/ip-down neu gesetzt werden.
Das Risiko bei diesem Verfahren sind Programme auf den LAN-Rechnern,
die mehr oder weniger regelmäßig Nameserver-Requests, Keepalive-
Pakete oder ARP-Broadcastings erzeugen - dann stellt nämlich der
Router jedesmal eine Verbindung zum Provider her. Die Telekom wird's
danken.
Übrigens kann es passieren, daß manche aus dem LAN initiierte
Verbindungen recht lange auf Antwort warten. Ich weiß nicht, ob
Kernel oder ipppd das "auslösende" Paket verschlucken, oder die
Antwort darauf unterschlagen; ich weiß aber, daß es hilft, z.B. bei
Netscape wenige Sekunden nach Anforderung der ersten Seite auf den
"roten Knopf" zu drücken und die Seite nochmals anzufordern.
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP für die Verbindung
zum Provider, kann man das Programm "diald" [4] verwenden. Es bietet
zudem den Vorteil, extrem stark konfigurierbar zu sein; so kann man
z.B. festlegen, daß zwischen 0900 und 1200 grundsätzlich keine
Verbindung aufgebaut wird, daß Nameserver-Anfragen eine Verbindung
zwar nicht aufbauen, aber offenhalten können u.v.m. Wer sich mit
diesen Konfigurationsmöglichkeiten nicht herumschlagen mag, braucht
das indes auch nicht - die Default-Konfiguration kann man ohne
Gefahr für Leib und Geldbörse übernehmen :-)
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cant exec cu: $!\n";
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
Das ist bei allen Karten mit 1 Siemens ISAC so, der hat (und braucht)
nur 1 Empfaenger und 1 Sender.
Theoretisch besteht eine Moeglichkeit, mit nur einem Empfaenger den
kompletten D-Kanal zu belauschen (das macht der ISAC sogar) und zwar
werden die auf der RX Leitung empfangenden D-Bits auf sogenannte Echo
Bits zeitversetzt auf die TX Leitung kopiert, darueber erfolgt die
Access Kontrolle (Kollisionserkennung) des S0 Busses.
Leider gibt es im ISAC im TA Mode keine Moeglichkeit die ECHO Bits aus
einem Register zu lesen.
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- offen ------------
S 5 -- TX- 1b -- offen ------------ Karte
6 -- RX- 2b ---------------/
#!/bin/bash
#ISDNBUTTON: Disconnect ISDN
/sbin/isdnctrl list isdn0 | grep Outgoing | grep -q 0251XYZ &&
/sbin/isdnctrl delphone isdn0 out 0251XYZ
/sbin/isdnctrl hangup isdn0
exit 0
#!/bin/bash
#ISDNBUTTON: Connect ISDN
/sbin/isdnctrl list isdn0 | grep Outgoing | grep -q 0251925020 ||
/sbin/isdnctrl addphone isdn0 out 0251925020
exit 0
GRÜN - mindestens eine ISDN Verbindung ist zur Zeit aktiv. Leider
kann ich nicht überprüfen, womit diese Verbindung aktiv
ist (siehe andere Mail in die Liste). Es muß sich also
nicht unbedingt um eine Netzwerkverbindung handeln und es
werden auch eingehende Verbindungen angezeigt (was ich in
meinem Fall aber auch ganz gut brauchen kann).
GELB - keine aktive ISDN Verbindung wurde entdeckt, aber
mindestens eines der ISDN Interfaces hat eine ausgehende
Telephonnummer fuer Demand-Dialing. Es besteht also die
"Gefahr", dass automatisch eine Verbindung aufgebaut
werden kann.
ROT - Keine der oben genannten Punkte trifft zu. In der Regel
bedeutet das, daß
a) der Kernel gar kein ISDN kennt, oder das ISDN
Subsystem nicht aktiv ist, oder
b) ISDN Auswahlverbindungen deaktiviert sind.
(Die folgenden Antworten entstammen zumeist der Anleitung zu vbox von
Matthias Heßler <hessler@wi-inf.uni-essen.de> und
Bernhard Hailer <dl4mhk@lrz.uni-muenchen.de>; man findet sie unter:
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
- dort "Audio!" anklicken!)
cat xxx>/dev/audio
sox <file>.wav -r 8000 <file>.ul rate
rmdcatheader -u <file.ul> > <file>.msg
cat <file>.ul >> <file>.msg
Zuerst wird - gleich beim Booten - diald "scharf gemacht"
# /etc/rc.d/rc.diald
/usr/sbin/diald /dev/ttyI4 -m ppp
local 192.168.90.9 remote 192.168.90.1
defaultroute dynamic modem crtscts lock connect "chat -v -f
/etc/ppp/chat.provider"
(in einer Zeile!)
Datei /etc/ppp/chat.provider:
TIMEOUT 240 "" AT&E1234 OK ATD047110815 ogin: Puser sword: topsecret
Telefonnummer, Name sowie Paßwort sind natürlich gefälscht :-)
Ich benutze den chargeint, das klappt hervorragend; Gebühren kommen
bei mir während der Verbindung, aber ich glaube, man kann das auch per
Hand justieren. Du mußt mit den beiden in
isdnlog-2.50/contrib/chargeint zum einen die Kernel-Sourcen, zum
anderen die isdn4k-utils-2.0 patchen; dann den isdnlog mit dem Flag
-Dchargeint compilieren (siehe Makefile). Kernel und isdnctrl
natürlich auch neu kompilieren.
Dann den isdnlog mit der option -hx starten, wobei x die Anzahl der
Sekunden ist, die noch zum Gebührenimpuls fehlen. Da legt der chargeint
dann auf. Im start-script für isdn wie gewohnt einen huptimeout
definieren, zusätzlich den chargeint scharf machen:
/sbin/isdnctrl huptimeout ippp0 80 # in sec;
nach Bedarf /sbin/isdnctrl chargeint ippp0
Der chargeint legt immer zwei Sekunden vor dem Ende der
Gebühreneinheit auf. Der isdnlog setzt, wenn er mit -Dchargeint
compiliert wurde, mit "-h" die Dauer der Einheit (i.e. Charge
Interval) abhängig von der Tageszeit und des Datums. Ein zusätzlicher
Parameter für "-h" verkürzt diese Dauer um den angegeben Wert.
Letzteres darf man bei Verwendung des chargeint aber nicht verwenden,
da sonst der chargeint die Verbindung zu früh beendet. Der Fehler
vergrößert sich mit der Anzahl der Gebührentakte. Also: "-h0" angeben,
um das Problem zu vermeiden.
> /sbin/isdnctrl huptimeout ippp0 80 # in sec;
In diesem Anwendungsfall ruhig kürzer, ich habe 5 Sekunden angegeben.
Dann kann ich die letzte Einheit bis auf 7 Sekunden (huptimeout + 2
Sekunden "chargeint-reserve") ausnutzen.
> /sbin/isdnctrl chargeint ippp0
Nicht nötig, wird von isdnlog mit "-h" erledigt.
1. Den Kernel mit "isdnlog-2.50/contrib/chargeint/patch-chargeint-2.04"
patchen, neuen Kernel backen und booten
2. Die isdn4k-utils-2.0 mit
"isdnlog-2.50/contrib/chargeint/patch-chargeint-kutils"
patchen, make clean; make install
3. In der "/etc/isdnlog/isdnlog.conf" bei den gewuenschten Gegnern
das jeweilige Interface in Spalte 4 eintragen, und noch mal
die Korrektheit der Zone-Eintraege pruefen
4. Im "Makefile" von isdnlog "-DCHARGEINT" bei "COPTS" anfuegen,
make clean; make install
5. isdnlog mit der weiteren Option "-h0" starten, fertig!
#
# ISDN Lines
#
I0:56:respawn:/usr/local/sbin/mgetty ttyI0
I1:56:respawn:/usr/local/sbin/mgetty ttyI1
port ttyI0
modem-type data
speed 38400
init-chat "" ATZ OK AT&E0 OK AT&B512 OK
i0:45:respawn:/sbin/mgetty -D -m '"" ATZ OK AT&E0 OK AT&B512 OK'
-s 38400 ttyI0
#/AutoPPP/ - ppp /usr/sbin/pppd auth -chap +pap login kdebug 7 debug
<login-name> * ""
* * ""
MSN Analog Digital
=== ====== =======
1 Voice + ISDN-Anrufbeantworter HDLC-PPP
2 Voice (Mutter) Netz-Interface
3 Modem/Fax X.75
Von Routern mit 1 BRI scheint es jede Menge zu geben, die wenigen mit
mehr sind recht teuer (Cisco 4000 mit vier Anschlüssen etwa DM
15000.--, Ascend Pipeline 400: ?).
ISDN-Router mit 4xBRI gibt es auch noch preiswerter von einem
deutschen Hersteller - siehe http://www.conware.de/
Ein Banzai! könnte auch helfen. Als Hardware tut's jeder beliebige PC
mit (z.B.) teles-Karten, die Software kostet so um die 800-1000 DM.
Ich persönlich mag Banzai!-Router überhaupt nicht wegen Ihrer
schlechten Diagnosemöglichkeiten, insbesondere ist Fernwartung so gut
wie nicht möglich (es sei denn, man hat die SNMP-fähige Version, aber
die kostet dann gleich einiges mehr). Aber wenn sie laufen, laufen sie
stabil und im Unterschied zu Cisco's können sie einen echten Callback.
Von Cisco gibt es als Alternative noch die Cisco 2503 für etwa 5000
DM, die zwar nur einen BRI-Port hat, aber dafür zwei serielle
Schnittstellen, an die man einen TA (je etwa 800 DM) hängen kann.
Schließlich kann man last, not least in den saueren Apfel beißen und
sich mehrere Cisco 1003 antun (ca. 2000DM pro Stück). Falls Geld keine
gar so dringende Rolle spielt, würde ich persönlich die letztere
Variante bevorzugen: Ich mag Cisco's einfach. :-)
Also du solltest dir eben überlegen, WAS dir am wichtigsten ist:
(1) Geld sparen
(2) Zeit sparen
Für (1) gibt es 2 Lösungen:
- Banzai! (heißt jetzt übigens Flux oder Concorde..)
-> http://www.concorde.de/ (von cls: http://www.cls.de/)
-> http://www.flux.de/ (von INS: http://www.ins.de/).
Basiert auf mind. einem 386er und routet eben Ethernet -> ISDN,
tut mit vielen Karten, die Programmierer arbeiten m.w mit Teles.
Nachteil: nicht sauber fern-konfigurierbar, außer du kauft die SNMP
Option dazu, was die Sache aber teurer und entsprechend
unattraktiver macht..
- ISPA + PCROUTE
-> http://www.biochem.mpg.de/~heha/
benötigt auch einen PC (tut auch schon mit einem 286er). Hat deutlich
weniger Optionen wie Banzei, Flux, Concorde etc. ist ebenfalls gar
nicht fernbedienbar, läuft dafür aber bombenstabil.
PCROUTE kostet gar nix, ISPA inzwischen 70.-, ggf. findest du auch
noch die Version 2.41 die auch ohne key unlimited läuft.
Beide Lösungen unterstützen so ziemlich alle ISDN Protokolle (u.a
diverse HDLC Varianten etc..). Unterstützung für SPVs (bald eh
obsolet) und D64S ist zumindest f. Teles-Karten da (kommt auch die
CAPI drauf an, nicht auf die Software). Alte PCs kriegst du ja schon
für <1.000 DM, die Teleskarte kostet nicht die Welt nur die Flux,
Concorde Software wird doch recht teuer wenn man da SNMP dazu kauft
-> du bist dann auch bald bei 2.000.- und dann kann du lieber gleich
'ne cisco1003 kaufen..
(2)
Wenn du nicht basteln willst, nimmst du entweder 4 einnzelne
Cisco1003 Router, die gibts so ab 2300.- und du bist mehr oder weniger
alle Sorgen los (mal von diverse IOS-Bugs abgesehen..). Dummerweise
können CISCO Router kein "richtiges" Callback... Und als Protokoll nur
PPP (wobei es IOS-Versionen gibt, die daß nicht sauber machen!) und
CISCO-HDLC.
Wenn du 4 BRI brauchst -> CISCO 4000, dann solltest du aber gleich
das 8-fach BRI kaufen, kostet nur knapp 2.000 DM weniger. Dann mußt
du aber deutlich mehr als 10.000.- investieren..:-(
Andere Variante: ELSA LANCOM MPR, kostet auch < 2.000 DM, kann
Callback, diverse Protokolle (HDLC, X.75, PPP) und ist recht nett zu
konfigurieren. Auf der Interop wurde ein Shiva ISDN Router mit a/b
Wandler für 1600 DM vorgestellt, damit wärst du bei 4 BRI Ports bei
etwas über 6000 DM...
Dann gibts noch etliche Hersteller die einfach BRI-Router im Programm
haben (Preistendenz unter 2.000 stark fallend..), z.B ASCEND, MIRO
usw.. Wenn du unbedingt 4fach BRI haben willst, gibts eigentlich nur
die Wahl zwischen Cisco und Ascend..
äh.. und weil du nach Ascend gefragt hast, hier habe ich noch ne
Preisliste von ascend gefunden (juli96), der max400 OHNE BRI Port
kostet schon mal 15.750.-, das 4-fach BRI schlägt dann nochmal mit
11.250 DM zu Buche... ich denke damit erübrigt sich ascend..:-(
Falls dir eine PC-Lösung nicht widerstrebt, könntest du noch netGW von
netcs verwenden (http://www.netcs.com). Das ist eine Software
für SCO, AIX, Sun u.a und basiert bei PCs z.B auf den Karten von Diehl
ISDN. netGW dürfte mit weitem Abstand die meisten Protokolle und
Optionen bieten, dafür mußt du dich mit einem PC und den damit
verbundenen Probleme anfreunden. So ein SCO-Lösung mit 4fach ISDN
Karte + Software kostet aber auch so an die 10.000 DM.
Wir haben inzwischen fast alle Banzai! und Co rausgerümpelt, weil sie
auf Dauer schlecht fern-administrierbar sind und eben bei weitem nicht
die Stabilität von Cisco oder anderen Stand-alone Routern haben..
Letztendlich ist es eben eine Entscheidung ob die lieber etwas mehr
Geld ausgeben willst, und dann läuft es auf Anhieb, oder du baust dir
so einen PC Router zusammen und bastelst eben rum... daß muß jeder für
sich selber entscheiden... Wobei Teles einen echt an den Rand der
Verzweiflung treiben kann, da die CAPI Versionen oft massive Probleme
haben und man als 08/15 User an alte CAPI-Versionen nicht ohne
Probleme ran kommt. Der Support bei Teles ist nicht gerade berauschend
(0190-8er Nummer!). Dann kann man ruck-zuck 20-30 DM vertelefonieren
ohne eine Lösung des Problemes erhalten zu haben...
Cisco ist sogar billiger als Linux wenns um PRI geht. Oder schon mal
geguckt was PRI Karten für PC's kosten. ;) Dann brauchte mann auch
noch Treiber dafür etc... Da ist mann schnell deutlich über 20k.
Eine 4000'er mit PRI bekommt man schon für 12-15kDM. Und wenn man
versucht die Sache mit einzelnen S0's zu lösen wird's erst recht
teuer...
Für Dialup bis 4 x BRI (was halt in eine kiste geht) ist Linux
allerdings vom Preis/Leistung her unschlagbar. Auch eine 2'te Kiste
macht noch Sinn.
Dann sollte man sich langsam mal nach einer PRI Lösung umsehen.
Beides läuft bei uns stabil und problemlos.
Da werden die Daten einfach rausgeschickt! Wenn du an einer D64S oder
2MB Leitung das eine Ende abklemmst, sagt dir dein Router, daß die
Leitung selber "up" ist. Du hast - außer mit Ping o.ä. - KEINE
Möglichkeit, zu erkennen, ob die Leitung weg ist oder nicht. (Bei ISPA
z.B drehen sich die out-going "Rädchen"....)
Das Einzige was du von deiner Seite messen kannst, ist der Loop zur
nächsten Vermittlungsstelle. Wenn du statt Bchan1 auf Bchan2 gehst und
Daten rausschickst, müßten die wieder zurückkommen. Das sieht man dann
an der Statistik. Dies setzt voraus, daß die Telekom in der Vstelle den
nicht benutzen Bchan auch so geschaltet hat. Damit haben wir der
Telekom mal nachgewiesen, daß die Leitung selber einen Kabelbruch
hatte...
Was dir allerdings passieren kann, wenn du nicht automatisch davon
ausgehst, daß die Leitung da ist: wenn die Gegenseite noch nicht "up"
ist, fließen keine Daten. Bei ISPA ist die z.B der Fall, weil der mit
der Pseudo-Rufnummer 1tap bzw. 2tap und erst beim ersten Datenpaket
loswählt und das Protokoll hochfährt. Einkommende Pakete werden
schlicht ignoriert, u.a auch wegen der fehlenden Signalisierung....
Nur bei S01 oder S02 Leitungen hat du einen D-Kanal und kannst was zum
Signalisieren nehmen, die meisten mir bekannten Lösungen nutzen aber
diese 16kb ebenfalls zur Datenübertragung und fahren dann 144kb statt
128kb. Also versuch' es einfach mal, indem du die Daten losschickst,
in der Annahme die Leitung ist vorhanden :-) im schlimmsten Fall laden
die Daten im Nirvana...
/sbin/telesctrl HiSax 5 0
# binde Interface an 1. BChannel (,1 fuer 2.)
/sbin/isdnctrl bind HiSax,0
/sbin/isdnctrl eaz isdn0 1
/sbin/isdnctrl addphone isdn0 out 2
/sbin/isdnctrl addphone isdn0 in 3
Organization: Marcus Graf Hard- & Software To: usenet@mail.omikron.de (news), isdn4linux@hub-wue.franken.de Date: Sat, 25 Jan 1997 17:31:11 +0100
Das geht sicher. Haben wir hier so im Einsatz. Funktioniert
auch stabil (Kernel >2.0.26 ist notwendig, da sonst ggf.
Routerkomplettstillstand). Nur, wenn Du den Stecker des Kabels
zum Terminaladapter rausziehst und wieder reinsteckst oder
Dir die Telekom da einen Aussetzer fabriziert, dann mußt
Du auf beiden Seiten einmal (oder zweimal) auflegen lassen,
damit die Leitung wieder steht. Das kann man notfalls mit einem
"ping" und einem "isdnctrl hangup" per cron machen lassen.
Weitere Doku außer der zum Sourcecode kenne ich nicht.
Werde aber gerne bei weiteren Fragen helfen, da man mir
schliesslich auch geholfen hat.
Es gibt dabei mehrere Dinge zu beachten: LEASEDx ist die
innumber auf dem Device; eine outgoing number ist nicht
notwendig, da der Kernel (oder die Firmware, genau weiss
ich das nicht) pseudomäßige, eingehende Rufe generiert,
solange niemand "abgehoben" hat. Bei LEASEDx ist das kleine
"x" durch die Nummer des S0-Interfaces zu ersetzen.
Wir haben in den betreffenden Routern jeweils vier
Interfaces (sie werden mit 0, 1, 2, 3, ... durchgezählt),
weshalb ich auf dem letzten Interface die LEASED-line
betreibe. Das macht Sinn. Denn die anderen drei Interfaces
dienen für 6 B-Kanaele mit dial-up-Leitungen und es wird
vom Kernel bei rausgehenden Rufen immer das erste freie
Interface gesucht und dort rausgewählt. Wenn man dann
die Leased Line auf das Interface 0 legen wuerde, wäre
der zweite B-Kanal der Standleitung ja scheinbar (und
nur scheinbar) noch frei. Der Kernel merkt aufgrund der
aktiven Karte noch nichtmal, daß kein D-Kanal zum Wählen
an dem Interface dran ist und wählt und wählt und wählt.
Zur Vorsicht habe ich aus dem Grunde auch ein weiteres
ISDN-Netzinterface kreiert und exklusiv auf dem scheinbaren
zweiten B-Kanal der Standleitung gebunden, damit bei 6 belegten
Dialout-Lines nicht auch noch auf der Standleitung ein
Waehlversuch gestartet wird.
Noch ein wichtiger Stolperstrick ist, daß bereits der erste
reingehende Ruf, der pseudomäßig generiert wird, vom
ISDN-Netzinterface abgenommen werden muss (sonst klappt
wieder erst der Dritte und dann erst wieder der Fuenfte;
genau weiss ich nicht warum, habe nur so eine Vermutung
daß das an den beiden B-Kanaelen liegt, fuer die abwechselnd
ein Ruf generiert wird; eine D64s hat aber nur einen B-Kanal).
Das sofortige Abnehmen erreicht man wie folgt:
* Modul für die ICN-Karte laden und konfigurieren (firmware
laden, bus-reject, ...) ABER NOCH KEIN "icnctrl -d XXX leased"
* Netzinterfaces des Kernel generieren mit innumber LEASEDx
und allem anderen Schnickschnack (IP-Adresse, ...).
Die Bindung zum entsprechenden S0-Interface nicht vergessen.
* JETZT: icnctrl -d XXX leased
Das Netzinterface muß also schon up sein, wenn "icnctrl -d XXX leased"
abgesetzt wird. Denn mit diesem Befehl wird sofort der erste Ruf
generiert und dann kann er gleich angenommen werden - und schwup
steht die Leitung.
Ja, das geht (zumindest in der Schweiz geht's). Achtung daß man den
richtigen Kanal erwischt ;)
TIMER_BCREAD = Intervall für B-Kanal-Poll (Einheit = jiffies = 20ms)
TIMER_DCREAD = Intervall für D-Kanal-Poll dito
FLAG_RBTIMER (und andere FLAG_...) entsprechende funktion aus dem
Haupt Timer dispatcher aufrufen.
Den BCREAD hab ich wegen der Ping-Zeiten runtergesetzt, (war vorher
auf 3) [Seit 2.0.16 auf 1 - die Red.]
Die Auflösung des timers in Linux ist nur 20ms, so daß
ICN_TIMER_BCREAD=0 nichts bringt. Außerdem ist das Problem eher
kosmetischer Natur. Beide (Sende- und Empfangs-) Routinen leeren
jeweils die Queue, d.h. wenn richtig Traffic gemacht wird, wird bei
jedem Zyklus nicht immer nur ein Fragment übertragen, sondern bis zu
16. Der Karten-Puffer faßt 16 Fragmente. Nur bei ping und Co. wird das
sichtbar. FTP (oder auch Z-Modem über ttyI) kommen mühelos auf
nahezu 8k cps. Außerdem werden bei jedem Zyklus beide Richtungen
bedient, die Rechnung 20ms-receive + 20ms-send stimmt also nicht.
Abgesehen davon 40ms ist ein wirklich guter Wert. Viele ISDN-Router
(auch i4l vor der Reduzierung auf BCREAD=1) haben 60ms und mehr.
Wegen ein paar Klagen vor dem Europäischen Gerichtshof gegen
die Telekom wohl bis Ende 1997. Wurde in den ensprechenden
Newsgroups gepostet und es könnte vielleicht auch was bei
http://www.birch.de zu finden sein (der klagte nämlich).
isdnctrl addif <master-interface>
isdnctrl addslave <master-interface> <slave-interface>
1st: There seems to have been a change in the "BogoCharsPerSecond"
calculations. This now gives values (for me) from 60 ->101.
The values used by the isdn-net code for starting the slaves is
still set to 7000 cps! Needless to say it doesn't see these
values anymore. After setting it to 75, I get the channels
starting again.
2nd: With 1 B-channel, I get 8K /sec (full)
With 2 B-Channels, I get ~14K /sec (~88 % util.)
With 3 B-Channels, I get ~18K /sec (~75 % util.)
With 4 B-Channels, I get ~15K /sec (~50 % util.)
isdnctrl addlink <device>
isdnctrl removelink <device>
...
rcvd [0][proto=0x3d] c0 00 00 00 80 fd 01 01 00 0a
...
sent [0][LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01
...
Ich habe einen Schreibfehler in Kernel 2.0.20 gefunden, der jedoch auch
in neueren Kernels existiert.
Wenn man die folgende Zeile in isdn_ppp.c:
(function isdn_timer_funct())
#if (defined CONFIG_ISDN_PPP ) && (defined ISDN_CONFIG_MPP)
in
#if (defined CONFIG_ISDN_PPP) && (defined CONFIG_ISDN_MPP)
ändert, wird's mit MPP Verbindung eher klappen.
Ohne diese Änderung hängt sich MPP schon beim Verlust eines einzigen
Paketes auf.
1. Als erstes sollte überprüft werden, ob beim Booten alles
funktioniert.
Gibt es ungewöhnliche Fehlermeldungen in /var/log/messages?
Sind nach dem Booten alle Programme aktiv, die gestartet werden
sollten (mit ps überprüfen, bzw. fuser /dev/xxx)?
HiSax wird nicht starten, wenn irgendetwas nicht funktioniert.
Der alte Teles-Treiber dagegen kann durchaus scheinbar fehlerlos
gestartet werden, ohne daß er tatsächlich funktioniert.
Siehe dazu die Fragen unter Troubleshooting|Teles.
2. Als zweites ruft man sich selbst mit dem Telefon an. Die
Telefonnummer sollte in /var/log/messages angezeigt werden (in
einer Message nach dem Muster: "isdn_tty: call from XXX -> YYY
ignored"). Ansonsten wurden die Treiber vielleicht schon beim
Booten nicht korrekt gestartet?
3. Als drittes werden die eigenen Experimente mit der Modememulation
fortgesetzt. Aufgrund der unterschiedlichen Dienstekennung kann man
leider weder das eigene Fax noch das eigene Telefon zum Klingeln
bringen, wir müssen anders vorgehen. Wir öffnen auf zwei
verschiedenen Konsolen "minicom -s" als Root und setze die erste
Konsole in "Serial Port Setup|Serial Device" auf /dev/ttyI0, die
zweite auf /dev/ttyI1. Danach "Exit" anwählen und die
Modememulation jeweils mit "ATZ" und "AT&Exxxxxxx" (xxxxxxx ist die
eigene MSN ohne Vorwahl - das, was bei Schritt 2 in
/var/log/messages als YYY angezeigt wurde) initialisieren.
Jetzt kann's losgehen: auf der ersten Konsole wählt man seine
eigene Telefonnummer mit ATDxxxxxxx an. Auf der zweiten Konsole
sollten nun "CALLER NUMBER: xxxxxxx" und "RING" angezeigt werden.
Nimmt man nun den Anruf auf der zweiten Konsole mit "ATA" an,
sollte auf beiden Konsolen "CONNECT 64000/X.75" angezeigt werden,
danach kann man sich gegenseitig Zeichen auf die jeweils andere
Konsole schreiben (um auch die eigenen Zeichen zu sehen, muß man
das lokale Echo einschalten).
4. Als viertes kann man nun eine bekannte ISDN-Mailbox anwählen. Wer
keine in der Nähe hat, kann sich auch bei Gernot einwählen, siehe
Frage "Gibt es Rechner, die einen Gastzugang bieten, wo ich mein
isdn4linux testen kann?".
Bei Problemen mit der Modememulation siehe
Troubleshooting|Modememulation.
5. Als fünftes kann man sich nun an die Konfiguration der
Netzinterfaces sowie ipppd wagen. Das bereitet Anfängern (und nicht
nur denen) erfahrungsgemäß die meisten Probleme. Wer sich die Sache
etwas erleichtern will, und mit asyncPPP zufrieden ist (zur
Bedeutung von asyncPPP siehe Frage "pppd, ipppd, asyncPPP, syncPPP
- was ist das? Was soll ich einsetzen?"), kann den normalen pppd
über die Modememulation (also /dev/ttyI*) laufen lassen.
ln -s /usr/include/curses.h /usr/include/ncurses.h
Ich habe allerdings keine neuere Distribution gesehen (weder Slackware
noch Debian), die ein vollständiges ncurses packet besitzt.
/usr/include/ncurses.h ist vorhanden - manchmal heist es halt
curses.h, aber das include File panel.h muß man sich trotzdem aus
einem Original ncurses Paket holen.
Bei Debian sollte man halt neben ncurses auch ncurses-dev installiert
haben, wenn man selbst etwas darauf aufsetzendes compilieren will.
bash$ dpkg -S panel.h
ncurses3.0-dev: /usr/include/panel.h
| | | |
| | | |
1 2 3 4
Da ich gerade keinen Patch zur Hand habe, erklär ichs mal so: in
linux/drivers/isdn/teles/callc.c nach CC_ALERTING_REQ suchen und
diese Zeile auskommentieren. Das sollte dann so aussehen:
if (((chanp->chan & 1) + 1) & chanp->para.bchannel) { /* \
chanp->is.l4.l4l3(&chanp->is, CC_ALERTING_REQ, NULL); */
FsmChangeState(fi, ST_IN);
if (chanp->debug & 1)
Das ist die saubere Lösung. Für Datenverbindungen wird kein ALERT
benötigt oder erwartet. Für die Voice Anwendungen ist das Alert nur
dann wichtig, wenn man mehrere "Klingelzeiten" abwarten möchte.
Es gibt [bei HiSax-Versionen<1.2 - die Red.] kein Alerting mehr.
Manche hatten schon das Problem, daß die Telekom die Gebühren-Info nur
für bestimmte Dienste aktiviert haben. Die müssen das offensichtlich
für jede Dienstart (Voice, Daten, G4-Fax,...) getrennt machen.
Ich denke, ich habe den Grund dafür gefunden, warum die Ascotel PBX
Linux abschießt. Es ist kein übergroßer "FACILITY"-Frame, wie ich
früher mal schrieb, sondern ein Frame eines unbekannten Protokolls
(0x44, während EDSS1=0x08 und DIS_N0=0x40, DIS_N1=0x41).
[...]
Jan den Ouden <denouden@groovin.xs4all.nl> hat dafür ja schon einen
Patch gemacht, welcher solche Frames einfach mißachtet. Ja, ich *habe*
diesen Patch ausprobiert... aber entweder habe ich irgendwas
fürchterlich falsch gemacht (z.B. Module nicht richtig geladen?) oder
es gab einen anderen Grund für den Crash. Und wieder weiß ich nicht
mehr weiter :-( Ich habe gerade den 2.0.18 ausprobiert und versucht,
einfach einen Hexdunp der unbekannten Frames zu machen anstatt sie zu
interpretieren - und jetzt stürzt die Maschine nicht mehr ab. Und
genau jetzt habe ich 2.0.20 probiert und sie ist auch nicht
abgestürzt. *Schulterzuck*, Konfusion...
Egal, wenn das wirklich nicht der Grund des Crashes ist, denke ich
immer noch, daß Jan's Patch in den ISDN-Standardtreiber eingebaut
werden sollte. Es ist keine gute Idee, daß Frames, die nicht vom Typ
1TR6 sind, voreinstellungsmäßig als EDSS1-Frames interpretiert werden.
Anmerkung: Der Patch, der hierzu gepostet wurde, hat noch einen bösen
Bug: X.75 geht damit nicht mehr!
1. TK-Anlage ausstecken
2. PC abschalten
3. TK-Anlage einstecken
4. PC anschalten
Cause 64 bedeutet "invalid information element contents" und ist aus
dem 12TR7 Protokoll, das von Anlagen (bei uns Octopus-M) intern
gefahren wird. 12TR7 beinhaltet 1TR6. Mehr weiß ich dazu nicht. Die
Quelle ist ein netter Telekommensch. Dort gibt es "Richtlinien", die
die Protokolle beschreiben.
diff isdnctrl.c.dist isdnctrl.c
240c240
< if (strlen(cfg.slave))
---
> if (cfg.slave && strlen(cfg.slave))
#define HSCX_RBUF_ORDER 1
#define HSCX_RBUF_BPPS 2
#define HSCX_RBUF_MAXPAGES 3
(4096<<HSCX_RBUF_ORDER)/HSCX_RBUF_BPPS
Diese Fehler passieren gerne mit schlechten Sound-Karten bzw.
Sound-Treibern, die die Interrupts zu lange disablen!
Ich hatte den gleichen Fehler, bis ich die korrekte Netmask angab.
insmod -m isdn.o | sort | sed -e 's/ / T /g' |
egrep '.* T [a-z,A-Z,_]+' > /etc/isdn/isdn.map
cat /System.map /etc/isdn/isdn.map > /iSystem.map
Am besten überprüfen, ob der Interrupt korrekt registriert ist. Mit
"cat /proc/interrupts" kann man das testen. Folgender Eintrag weist
auf einen Fehler hin:
11: 0 + teles
Die 11 ist korrekt, solange die Teleskarte auf Interrupt 11
konfiguriert wurde. Die 0 jedoch bedeutet, daß die Teleskarte keine
Interrupts akzeptiert, und damit nicht funktioniert. Das ist der
bekannte "Busy"-Bug, er kann durch das Entladen und Neuladen der ISDN-
Module wieder behoben werden. Der IRQ-Zähler muß nicht unbedingt auf 0
stehen, auch niedrige Werte ungleich 0 weisen auf das selbe Problem
hin. Man kann das relativ einfach testen:
1. cat /proc/interrups, Zählerstand merken
2. Mit dem Telefon den Rechner anrufen.
3. Nochmal cat /proc/interrupts, der Zähler muß sich nun
gravierend vom ersten Wert unterscheiden.
Bei PCI-Boards niemals IRQ 12 benutzen. Der wird manchmal von der
Busmaus benutzt (auch dann, wenn man gar keine hat und für sie den
IRQ nicht aktiviert hat), daher geht der IRQ manchmal verloren, und
man bekommt es mit Fehlern zu tun.
Bei PCI-Boards niemals IRQ 15 benutzen. Der wird manchmal vom IDE 2
benutzt (auch dann, wenn man den gar nicht nutzt und für ihn den
IRQ nicht aktiviert hat), daher geht der IRQ manchmal verloren, und
man bekommt es mit Fehlern zu tun.
Versuch mal statt eines "reboot" (per Kommando) oder "Ctrl-Alt-Del"
einen Reset per Reset-Taster ("Hard-Reset") am PC.
Bei manchen Motherboards (was nicht zwangsweise Schuld des
Motherboards sein muß) werden bei einem "Soft-Reset" die
Karten nicht wieder in ihren Grundzustand versetzt, so daß
manche Treiber dann Probleme haben, die Karten anzusprechen.
l1state 4
l1state 8
l1state 13
ph_command 9
l1state 4
l1state 0
ph_command 0
l1state 7
ph_command 9
Klarer Fall von IRQ-Problemen. Gerade der 11 macht auf manchen Boards
Probleme. Obwohl man denkt, daß manche IRQ's frei sind, werden sie dann
doch vom BIOS irgendwie reserviert.
Gut für einen Schuß sind immer IRQ 5 und IRQ 9. Falls Ihr keine Mäuse
und Modems habt, könnt Ihr es auch mit 4 und 3 probieren. Damit klappts
auch auf obskuren Boards.
#ifndef PROTO_H
#define PROTO_H
#define PROTO_EURO 0x08
#define PROTO_DIS_N0 0x40
#define PROTO_DIS_N1 0x41
#endif
HiSax: Teles 16.3 found,irq:5 isac:a80 cfg:e80
HiSax: hscx A:280 hscx B:680
Teles3: HSCX version A: V2.1 B: V2.1
<date> <time> foo kernel: HSCX B EXIR 10
<date> <time> last message repeated <n> times
Ich hatte schon vor einigen Wochen über meine Probleme, mit einem
EL 310 zu connecten berichtet. Es kam keine Connect-Meldung für den
Daten-Kanal vom ISDN. Das problematische Elink hängt an einem 1TR6
Anschluß und hat identische Settings wie ein anderes Elink an einem
Euro-ISDN Anschluß, mit dem ich nie Probleme hatte. Seit ca. 2
Wochen funktioniert das jetzt plötzlich einwandfrei, ohne daß lokal
oder remote etwas geändert wurde.
Schlußfolgerung: Die Software in den Vermittlungsstellen scheint da
eine Rolle zu spielen....
{ PPP_CCP, ccp_init, ccp_input, ccp_protrej,
ccp_printpkt, ccp_datainput, "CCP" }
Weitere Hinweise finden sich im gleichnamigen Abschnitt im Kapitel "Konfiguration"!
Gerade die ersten Pakete des Protokolls können verloren gehen, wenn
sie sofort nach der Connect-Meldung auf dem B-Kanal rausgefeuert
werden. Ich hatte das Problem bei raw hdlc, daß Pakete verloren
gingen, aber nur wenn man von einer bestimmten Seite aus anrief.
Vielleicht ist es auch ein Problem mit dem verwendeten Kabel...
Wenn da wirklich kein Prozeß mehr drauf läuft, versuch mal:
cu -l /dev/ttyI0 dir
+++
ath0
~.
Vor und nach dem "+++" ist eine Sekunde Pause einzuhalten, sonst wird
es von der Modem-Emulation nicht als Escape-Sequenz erkannt (wie echte
Modems). Achte mal auf Prozesse, die mit "ps -ax" in der zweiten
Spalte einen Eintrag der Art "I0" oder "I1" haben, die haben nämlich
ein ISDN-Terminal als controlling terminal. Eventuell mußt Du diese
mit kill abschießen.
Ich mußte das bei mir folgendermassen einstellen. Sonst bekam ich auch
nur Fehler.
# Prot
protocol-parameter g packet-size 512
protocol-parameter g short-packets y
protocol-parameter g window 7
protocol-parameter g remote-window 7
protocol-parameter v packet-size 512
Damit komme ich bei großen Paketen auf ca 7300 cps
Bei mir pollen auch einige XP-Benutzer, wohl auch ohne Probleme. Ich
habe folgendes gemacht: Zum einen habe ich die Send-Packetsize vom
ttyI? auf 1024 gesetzt ("AT&B1024") und zum setze ich die
Paketgrößen für das g-Protokoll beim UUCP:
protocol-parameter g packet-size 2048
protocol-parameter g remote-packet-size 0
Wie gesagt, damit läuft hier alles prima.
#define DATA_VERSION 1
#define DATA_VERSION 2
daemon.* /var/log/ppp-log
Entferne das Kommentarzeichen aus der folgenden Zeile
in /etc/syslog.conf:
#*.=debug /tmp/debug
Nach Änderung der Datei kannst Du mit "kill -1 <pid vom syslogd>" den
syslogd zum restart bringen.
Der in /tmp/debug erzeugte output ist auch geeignet, um das Aushandeln
von Optionen zwischen den Gegenstellen zu optimieren.
Das hatte ich auch! (S.u.S.E. 4.2 Kernel 2.0.0, isdn4k-utils 3.91 mit
patch). Als ich dann den Kernel neu kompilierte u. ppp als Modul
konfiguriert hatte, konnte ich ipppd starten. Da gibt's wohl
Versionsprobleme.
isdnctrl addif ippp0
isdnctrl encap ippp0 syncppp
... (siehe isdn4linux-Doku für weitere Informationen) ...
Bei 1.2.13 sagt man dem Kernel, daß er *keinen* ppp-support
haben soll, compiliert den Kernel, und macht *anschließend* ein
'make modules', sowie ein 'make modules_install'. Damit wird dann
alles(!), was nicht in den Kernel konfiguriert wurde, aber als module
geladen werden darf, zum Zuladen mittels insmod vorbereitet. 'modprobe
ppp' beim Booten (im geeigneten rc.xxx Skript) lädt dann das ppp-Modul
und alle dafür nötigen Module (slhc etc.).
Voraussetzung für ipppd mit 1.2.13: Installiere ppp-Version 2.2.0c.
Auch in den Kernel-Sources (ppp-2.2.0c.tar.gz). Und Du brauchst dafür
modutils 1.2.8 (modules-1.2.8.tar.gz).
Ich hatte das gleiche Problem auch. Bei mir war es so, daß nach ca.
5 Minuten erst - nachdem mehrere dieser Meldungen in den messages
erschienen - der ipppd meldete: "started". Dann lief's aber!
Naja, ich habe dann mal ein paar test-prints in den ipppd-Source
gestreut und habe dann das Problem einkreisen können:
Der ipppd berechnet bei der Initialisierung eine Zufallszahl (ich weiß
nicht mehr wo), und benutzt dafür gethostid(). Das führt aber wohl zu
einem DNS-Lookup. Daraufhin versucht die Kiste, den in /etc/resolv.conf
angegebenen Nameserver anzusprechen.
Da aber der ipppd noch gar nicht vollständig durchgestartet hat, kann
der Nameserver nicht erreicht werden. Das führt dann zu den Meldungen.
Die Lösung war ganz einfach:
Ich habe in /etc/hosts meinen Rechner nicht nur mit dem Kurznamen (z.B.
isdn) eingetragen, sondern auch noch den kompletten Namen inkl. der in
/etc/resolv.conf angegebenen Domain, also z.B.
x.x.x.x isdn isdn.wer.weiß.wo
Danach war Ruhe und es lief!
Noch etwas früher wird in main() die Funktion setipdefault()
aufgerufen, welche (in options.c) gethostbyname() ausführt.
Dieses führt natürlich auch zu einem DNS-Lookup und verursacht ebenso
die Meldung "isdn_ppp_bind: Can't find usable ippp device"
Es wären also 2 Stellen im Source zu ändern, um einen DNS-Lookup zu
vermeiden.
Einfacher ist es, in /etc/hosts den eigenen Namen einzutragen, ich
hab's mit der IP-Adresse der eingebauten Ethernet-Karte gemacht.
Es gab eine Änderung in patch-2.0.16, die das Problem verursacht haben
könnte. Bis zum offiziellen Fix kann man den inoffiziellen Patch von
ftp://ftp.gwdg.de/pub/misc/isdn/linux/ippp/isdn.diff versuchen.
Der bei meiner Suse-Distribution mitgelieferte ipppd war bei mir
defekt. Das Paket i4l-43b2.tar von ftp://ftp.suse.de/ hat mir
geholfen.
- nur einige wenige "LCP-conf-req SENT"-Meldungen (weniger als zehn)
und dann ein "Term-REF:
-> nachsehen, ob die ISDN-Karte richtig konfiguriert worden ist, denn
es scheint, daß der Rechner nicht wählt (IRQ, IO, Protokoll oder
ähnliches Problem)
- nur wenigstens ein paar "RECV"--Medungen
-> gut: die Karte wählt und die Gegenstelle versucht, zu
kommunizieren.
Vielleicht klappt nur die Authentifizierung nicht. Die ipppd-
Konfiguration nochmals prüfen!
- den Hinweis, daß der ipppd aus irgendwelchen Gründen beendet wird
-> nicht gut... Man checke /var/log/messages und /var/adm/daemon.
Das könnte ein Bug im ipppd sein.
Bitte auf Kernel 2.0.14 downgraden ... In späteren Versionen (seit
2.0.16) gibt es einen kleinen Bug, der den ipppd beendet, wenn keine
Verbindung zustandekommt. (Das sollte eigentlich gut gehen, wenn man
immer Verbindung bekommt.) Ein "quick and dirty hack" ist möglich,
wenn man ein paar Zeilen im ipppd entfernt, aber es ist schon besser,
bei 2.0.14 zu bleiben, bis der Bugfix seinen Weg in die neuen Kernels
gefunden hat.
#!/bin/sh
/sbin/route add default ippp0
#! /bin/sh
case $1 in
on)
/sbin/isdnctrl dial ippp0 # Verbindung herstellen
sleep 5 # warten, bis Leitung offen
/sbin/route add default ippp0 # Route setzen
;;
off)
/sbin/isdnctrl hangup ippp0 # Verbindung abbrechen
/sbin/route del default # und Route wieder löschen
;;
*)
echo -e "\a Usage: 'isdn on' or 'isdn off'"
;;
esac
XXX YYY ZZZ
* * ZZZ
Ich hatte genau das gleiche Problem bzw. die gleiche Meldung.
Verursacht war es bei mir dadurch, daß ich in chap-secrets bzw.
pap-secrets drei Einträge pro Zeile hatte (für client, server,
secret), aber keinen vierten (IP adresses), JEDOCH: nach dem dritten
Eintrag bis zur Position des vierten noch BLANKS standen.
Nach dem Entfernen aller schleppenden BLANKS und/oder TABS lebt
(i)pppd äußerst zufrieden mit meinen auth-files.
Mein PAP Skript war verkrüppelt, da ich ein "#" in meinem Paßwort
hatte! Nachdem ich das Paßwort sauber gequotet hatte (z.B. mit
Anführungszeichen) war das Problem gelöst.
Wir sind ISP hier in Dresden und setzen u.a. Linux für unsere Zugänge
ein (sowohl I4L mit hisax als auch externe Terminaladapter) Wir haben
das Problem vor allem mit Windows-95 und NT-Kunden, die die
"eingebaute" (DFÜ-Netzwerk)-Software benutzen. Dabei ist es völlig
egal, ob sich der Kunde mit async oder sync-PPP einwaehlt. Auch ist
egal, welche Modememulation er auf seiner Seite benutzt. Allen Fällen
ist gemein, daß die Einbindung über Microsoft-DFÜ-Adapter+Microsoft-
PPP erfolgt. (ein Kollege erzählte mir neulich von einem ähnlichen
Problem mit einem Macintosh-Kunden)
Da es bei PPP ziemlich egal ist, wer Server ist und wer Client, frag
mal deinen ISP über welche Technik Du dich einwählst. (mit
Linux-Kunden und Trumpet-Winsock-Nutzern z.B. haben wir >>null<<
Probleme (Ich schließe daraus einen Bug in MS-PPP)
Folgender Workaround hilft bei uns aber in der Regel: (ist kein
Heilmittel, hilft aber die Schmerzen zu lindern...)
* Verringern der Max-MTU auf 576 oder gar (296)
* Verringern des DefaultRcvWindow auf 2144
Auf der Windows-95-Seite sind das zwei Registry-Einträge, auf der
Linux-Seite kannst Du mal "mtu 576" und "mru 576" in den ppp-Optionen
eingeben.
(ffs. http://www.windows95.com/connect/trouble.html)
Also, bei mir haben weder PPP-compressions-options geholfen, noch
mru/mtu auf 296. Was aber gut geholfen hat, war der AT-Befehl:
AT&B512
der die maximal verschickten Pakete auf 512 Bytes begrenzt.
mtu 1024
Gestern habe ich eine feste IP-Adresse bekommen, und seitdem läuft der
automatische Verbindungsaufbau über ipppd phantastisch problemlos.
Ebenfalls über eine normale serielle Schnittstelle mit async. PPP über
V.120 und diald (per ELSA Microlink ISDN/TLpro --- wie auch über
V.34-Modem) funktioniert das Ganze jetzt. Die Ausfallerscheinungen
waren da ja vorher die gleichen.
Resumee: Wer automatisches(!) ppp-Dialing benötigt, benötigt zwingend
eine feste IP-Adresse. Wer seine Verbindung manuell(!) hochzieht und
auch manuell wieder abbaut, kann wunderbar mit dynamischer
Adreßzuweisung leben.
Es wäre sicher an der Zeit, ppp in seiner Funktionalität soweit zu
erweitern, daß es verbindungsinitiierende Pakete nicht nur zurückhält,
sondern auch auf die abgehende IP-Adresse hin überprüft, diese nach
erfolgtem Verbindungsaufbau korrigiert, und das Paket erst dann
abschickt.
Dasselbe ebenfalls für die Pakete, die nach dem initiierenden kommen
bevor die Verbindung schon steht.
Ebenso müßte der diald diese Funktionalität bekommen, wenn der den
Verbindungsauf- und -abbau steuern soll.
IP ist eben vom Konzept nie für dynamische Adressen vorgesehen gewesen,
und stehende Verbindungen wie telnet oder ftp kann man über
Verbindungsabbau und -wiederaufbau (mit neuer IP-Adresse) dann ohnehin
nie mehr recover'n.
1) Keine lokale Name-Server/Name-Server-Cache
2) Lokale Squid Proxy-WWW-Server (und Netscape muss ihn benutzen).
3) positive_dns_ttl auf 1 setzen in /usr/local/squid/etc/squid.conf
damit Squid nicht die IP-Adressen cachet
Jetzt wird die Verbindung immer gestartet mit der DNS-
Anfrage, der immun ist gegen IP-Adresse-Änderungen (weil er
mit UDP und nicht TCP laueft?). Wenn du andere Programme
hast, die IP-Adressen cachen, musst du dir ueberlegen wie
das umgangen werden kann. Normalerweise wird ein Program
die IP-Adresse chachen, wenn es 2 mal zur selben Server
connectet. Das ist natürlich kein Problem, wenn die
beiden Verbindungen so kurz nacheinander erfolgen, daß
die Dial-On-Demand-Verbindung noch die selbe ist.
*** 1.14 1996/06/06 22:08:46
--- isdnctrl.c 1996/09/04 19:13:39
***************
*** 498,504 ****
}
printf("MSN/EAZ-mapping for %s:\n%s\n",argv[2],nstring);
} else {
! iocts.arg = (unsigned long)argv[3];
if ((result=ioctl(fd,IIOCSETMAP,&iocts))<0) {
perror(argv[2]);
exit(-1);
--- 498,506 ----
}
printf("MSN/EAZ-mapping for %s:\n%s\n",argv[2],nstring);
} else {
! char buf[400];
! strncpy(buf, argv[3], sizeof(buf)-1);
! iocts.arg = (unsigned long)buf;
if ((result=ioctl(fd,IIOCSETMAP,&iocts))<0) {
perror(argv[2]);
xosview reagiert, jedenfalls in meiner Version 1.4, auf das ip-
Accounting des Kernels. Also einkonfigurieren, ggf. neuen Kernel
bauen, dann anknipsen mit
ipfwadm -A -a -S your-ip-address-here -D 0.0.0.0/0
ipfwadm -A -a -D your-ip-address-here -S 0.0.0.0/0
Wie's mit variablen IP-Adressen geht, weiß ich nicht, ich habe eine
feste.
Rainer May <r_may@khavi.desaster.heide.de> hat einige Fragen und Antworten zum Thema "i4l und Masquerading" zusammengestellt:
* Ist auf dem LAN-Rechner der Linux-Router als Gateway eingetragen
(manche "Betriebssysteme" muß man komplett resetten, bevor Sie da
eine Änderung mitbekommen)?
* Liegt auf dem Router die Default-Route auf dem "Bereitschafts-
Interface" zum Provider (z.B. auf ippp0 bei synch. PPP, oder auf
sl0 bei diald (auch wenn die "echte" Verbindung nachher per ppp0
geht - diald benutzt ein SLIP-Interface als "Türklingel")?
* Erzwingt der Provider die Verwendung von Proxies? Dann müssen die
IP-Adressen der Provider-Proxies auch in den entsprechenden
Programmen der LAN-Rechner eingetragen sein!
Mir ist dabei aufgefallen, dass nach dem ersten Verbindungsaufbau via
ippp0 das lokale Netzwerk wieder erreichbar ist. Dann steht auch in
ifconfig ippp0 nicht mehr die 0.0.0.0 drin, sondern eine zugewiesene
IP-Adresse aus dem Pool der Gegenstelle, die bei einem neuen
Verbindungsaufbau neu gesetzt wird.
In de.comp.os.linux.networking wurde der Thread bereits diskutiert,
und es kam eine Lösungsmöglichkeit:
Einfach auf ippp0 eine Dummy-IP-Nummer aus dem Pool setzen. Das
lokale Netzwerk hat auch direkt nach dem Booten trotz default route
keine Probleme mehr, und die IP-Nummer in ifconfig ippp0 wird sowieso
überschrieben.
Ist bei den "üblichen Meldungen" auch ein
"(HiSax driver detected)"
dabei?
Falls nein:
- hast du die Version 2.52 auch gestartet - nicht nur compiliert?
- hast du das "telesctrl <DriverID> 1 4" auch nicht vergessen?
- ISDN-Verbindungen funzen ansonsten schon?
Falls ja: Melde dich mal bei mir (isdnlog@Kool.f.EUnet.de) mit
den entsprechenden Log-Files (mit "isdnlog -v7" erstellt).
Mein Problem mit isdnlog 2.50 und dem "wrong structure error" lag nur
darin, daß ich keine führende 0 bei den Aliases angegeben habe.
Beispiel:
017201234567 Handy 1 -
Bei mir sah es vorher so aus:
*17201234567 Handy 1 -
Damit scheint alles behoben zu sein.
Bei mir schmierte isdnlog immer ab, weil im /etc/services isdnlog
nicht eingetragen war.
#!/bin/sh
/usr/local/bin/play anruf.au 2>/dev/null
(Die folgende Frage/Antwort schickte uns Andreas Kool <akool@Kool.f.EUnet.de>
- direkt beim Start von isdnlog oder isdnrep:
Hier haben sich die beiden Programme beim Einlesen der "isdnlog.conf"
vertüddelt.
Abhilfen:
- nie Blank's in der Alias-Spalte verwenden!
(z.b.: "Meine MSN")
- nie "#" in der Alias-Spalte verwenden!
(z.b.: "MSN#3")
- nie "\" in der Alias-Spalte verwenden!
(z.b.: "MSN\#3") (Danke, Holger Wirtz <chick@midips.snafu.de>)
- nie "*" als Eintrag in der Flags-Spalte angeben!
(Danke, Werner Wiethege <ww@slarti.frankfurt.netsurf.de>)
- auch die "START=" Zeile benötigt als Angabe, wann gestartet
werden soll, also z.b.
START=IOH=auplay hangup.au
und nicht
START=auplay hangup.au
(Danke, Dirk Staneker <zxmjy04@student.uni-tuebingen.de>)
- beim Einsatz der "-S" Option zum Starten von externen Programmen.
Hierbei hat sich isdnlog leider im Code für den X11-Client "xisdn"
verlaufen, und fing zum einen an, in sich selbst zu loopen, zum
anderen hinterließ er gerne Zombies - dies wurde durch isdnlog-2.50
korrigiert.
Ich hatte neulich den gleichen Effekt, was bei mir nur daran lag, daß
ich aus Versehen zwei mal isdnlog gestartet hatte.
Isdnlog habe ich inzwischen gepatcht. Das Problem ist der strftime()-
Aufruf in Zeile 264 in isdnlog.c. Dort muß das "%e" durch ein "%d"
ersetzt werden, dann geht wieder alles.
(Die folgenden Antworten entstammen zumeist der Anleitung zu vbox von
Matthias Heßler <hessler@wi-inf.uni-essen.de> und
Bernhard Hailer <dl4mhk@lrz.uni-muenchen.de>; man findet sie unter:
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
- dort "Audio!" anklicken!)
/sbin/route del default
/sbin/isdnctrl system off
/sbin/ifconfig ippp0 down
/sbin/isdnctrl system on
/sbin/ifconfig ippp0 up
/sbin/route add $GATE-IP dev ippp0
/sbin/route add default ippp0
Leider gibts meines Wissens nach für tcpdump noch keinen patch für sync
ppp encapsulation. Wenn du ipppd benutzt bleibt Dir deshalb nur die
Möglichkeit, konsequent einen daemon nach dem anderen abzuschalten und
sehen ob Ruhe im Karton ist. Insbesondere named, sendmail aber auch
smbd (Samba) sind Kandidaten, die gerne Verbindungen aufbauen.
Ich habs auch nur durch Killen verdächtiger Prozesse rausgefunden.
Genaueres zum Suchen der Prozesse und wie man sie still bekommt gibts
unter:
http://www.fzi.de/sim/people/trautw/i4l/index.html
Probier mal rauszufinden, welche Anfrage das auslöst, und zwar mit
"isdnctrl verbose 3". dann sollte in der kernel-message-queue (siehst
Du wenn Du "dmesg" tippst) ein Eintrag a'la:
OPEN: 141.76.60.54 -> 193.171.67.253 TCP, port: 1686 -> 540
aufscheinen. das obige beispiel heisst, dass unser rechner auf port 540
post abholen will (uucp over tcp/ip over isdn).
Ein kleiner Tip noch. Es gibt viele Daemons auf der Linux-Seite, die
Broadcast auf allen Interfaces versenden. Das führt auch häufig zum
Autodial.
Da kann man die broadcast-Adresse auf das dummy0-Interface umlenken.
Ist zwar nicht sauber, aber tut.
Wenn beim Wintel der Nameserver des Providers eingetragen ist, und
Sinnlos3.11/95 gestartet wird, muß (warum weiß nur Bill Gates) er
sich unbedingt mit dem Nameserver unterhalten.
Warum stellst du nicht einfach das Windows-Setting im Netzwerksetup:
"Use DNS for Windows Names Resolution" (oder ähnlich)
auf No?
Dann müßte Ruhe sein, zumindest bei mir ist es so.
nmdb -S -B 192.168.99.255 -I 192.168.99.99
Leider hat uns die Realität überholt - soweit ich gehört habe,
baut Netscape z.B. jetzt in der Version 4.02 tatsächlich eine
Verbindung auf...
Wenn man die keep-alive-Packets nicht beantwortet, beendet die Cisco
das routing! Das passiert in der Regel nach dem 4. oder 5. keep-alive-
Packet, das der eigene Router nicht beantwortet.
Die beste Lösung ist es, dem Provider mitzuteilen, daß man keine
keep-alive-Pakete haben will (no keepalive in der Cisco-Konfiguration).
Gerade zwischen zwei Cisco-Routern und gemieteten Leitungen gibt es
keinen Grund, keep-alive zu verwenden.
LCP-Messages werden als Verkehr betrachtet und halten die Leitung
offen. Es gab da einen kleinen Patch gegen Linux-2.0.21 mit
dem patch-chargeint-2.04 für isdnlog-2.50-Benutzung. Mit diesem Patch
werden *alle* syncPPP-LCP-Daten bei der Berechnung des Hangup-Timers
ignoriert, so daß der Hangup auch dann funktioniert, wenn der Provider
alle paar Sekunden LCP-Echo-Requests sendet.
Warnung: Der Code funktioniert bei *mir* (mit meinem Provider), ich
weiß aber nicht, ob er auch bei *euch* geht! Einfach mal versuchen!
Nach einigen Experimenten kam ich zu einer Lösung auf der Cisco
(IOS 11.0.7), das "snapshot routing" genannt wird. Ich konfigurierte
"snapshot server" auf dem BRI-Interface. Das bedeutet es wird nur dann
Routing Updates verschicken, wenn es diese auch durch dieses Interface
empfängt.
im Modul isdn_net.c (Zeile 1720) gibt es den Kommentar "/* if this
interface is dialing, it does it probably on a different device, so
free this device */" und es wird die Funktion isdn_free_channel
aufgerufen.
[...]
Das ganze sieht jetzt folgendermaßen aus:
#ifdef CONFIG_ISDN_PPP
if (p->local.p_encap == ISDN_NET_ENCAP_SYNCPPP)
ippp_table[lp->ppp_minor]->state = IPPP_OPEN;
#endif
> ... ich habe den Code mal durchsucht und tatsaechlich
> eine moegliche Fehlerquelle bei reinkommenden Anrufen
> ausgemacht. Trifft das auf dein Szenario zu?
> Wenn ja, mal die Zeile: (isdn_net.c, etwa Zeile 1730)
> p->local.pppbind = -1;
> in der Funktion isdn_net_find_icall() rauswerfen.
Ich habe die Zeile rausgeschiessen und siehe da es geht.
Ein Cisco wählt unter Umständen so heftig, daß kein ipppd eine Chance
hat, einen Callback zu starten.
Ciscos sind so programmiert (definitive Aussage eines Cisco-
Entwicklers):
Wenn ein Cisco ein Paket empfängt, das über ein "dial on demand"
ISDN-Interface herausgeroutet werden soll, auf dem noch keine
Telephonverbindung besteht, und wenn gleichzeitig ein D-Kanal zum
Herausrufen frei ist, dann wird sofort herausgerufen.
Wenn also (so ist die Situation bei Delta Internet ein halbes Jahr
gewesen) ein Cisco auf der anderen Seite steht, der locker 8 D-Kanäle
zur Verfügung hat und wenn jemand einen simplen "ping <RemoteIP>"
startet, dann benutzt der Cisco (im schlimmsten) Fall alle seine 8
D-Kanäle, um das Gegenüber anzurufen. Sicher kann er nicht ein und
dieselbe Telephonnummer mit zwei D-Kanälen gleichzeitig anrufen (gäbe
ja sofort besetzt). So dumm programmiert ist er auch nicht, aber er
macht den nächsten D-Kanal schon zum Herauswählen (Blockwahl)
startklar, bevor der Ruf auf dem vorherigen D-Kanal als gescheitert
betrachtet wird.
So ein Cisco funktioniert also wie ein Maschinengewehr bezüglich des
Herausrufens. Und kein Linux bekommt für einen Callback einen freien
D-Kanal, wenn es der Cisco nicht will.
Das Dumme ist: Ein Cisco erwartet, selbst wenn er auf "callback client"
konfiguriert ist (Linux ruft zurück), immer, daß wenigstens einmal
abgehoben wird, dann im Einvernehmen wieder aufgelegt wird und danach
der Rückruf geschieht. Denn bei Verwendung von PPP muß immer, bevor ein
Rückruf passieren darf, einmal der Username und das Paßwort
ausgetauscht werden, um sicher zu gehen, daß derjenige, der den
Callback wünscht, überhaupt dazu autorisiert ist. [...]
Selber habe ich das Callback über PPP mit zwei CISCOs oft genug
probiert. Versuche mit der Kombination CISCO <-> Linux sind jedoch,
nach meiner Erkenntnis, zum Scheitern verurteilt.
Denn ein CISCO handelt den Callback-Request stets über PPP aus.
Dafuer muss also die Seite, die die Aufforderung zum Rückrufen
bekommt erstmal abnehmen und alles aushandeln (Authentisierung,
...), dann wird aufgelegt und zurückgerufen.
isdnctrl-Kommandos von Linux beeinflussen nur das Netzdevice
des Kernels und haben bezüglich des Callback wenig bis gar
keine Einflüsse auf den ipppd. Der bekommt gar nicht mit,
dass er erwarten soll, dass die Gegenstelle zurückruft.
Entsprechend beantwortet er auch Angebote des CISCO
über das PPP, dass der CISCO auch zum Zurückrufen bereit wäre,
mit einer Abweisung. Das veranlasst den CISCO zu der Annahme,
daß er dann doch nicht zurückrufen soll. Denn wenn er nicht
im Laufe der Initialisierung über PPP erfährt, daß der Anrufer
zurückgerufen werden will (er muss explizit sagen: "Ich will"),
tut er das auch nicht.
Der Cisco wird Dir das bestätigen, wenn Du Dich auf Deinem
Cisco einloggst und mit den Befehlen
deb ppp chap
deb ppp negotiotion
deb ppp error
term mon
ansiehst, was er zu den Einwählversuchen Deines Linux-Rechners
sagt, die dann, wenn sie zeitgleich geschehen, durch Debug-Meldungen
kommentiert werden. Mach das bitte nicht auf der Console, sondern
über einen Telnet, sonst kommt der CISCO mit dem Loggen über die
serielle Schnittstelle nicht nach.
isdnctrl callback isdn0 in
isdnctrl cbdelay isdn0 1
telesctrl <id> 3 1 ---> dec module_count
telesctrl <id> 4 1 ---> inc module_count
Zuerst mal kurz zum Fehler: deine Gegenseite mag die MP-MRU von 0x5dc
nicht sondern will eine kleinere (0x5d7) .. das übernimmt allerdings
der ipppd nicht (Bug) .. Probier einfach mal von vorneherein 0x5d7 als
MP-MRU auszuhandeln.
Wenn die MP-MRU nicht ausgehandelt wird, schaltet sich kein MPPP ein ..
daher wohl auch die Folgefehler.
EAZ 0: globaler Ruf (alle Telefone klingeln)
EAZ 9: globaler Ruf (aber kein Telefon klingelt)
0 würde ich nicht nehmen, da bestünde für meinen Geschmack zu
sehr die Möglichkeit, daß sich i4l alle Gespräche klaut.
* Modememulation:
"AT&e123456789" (ohne Null am Anfang)
* Netzinterfaces:
"isdnctrl eaz <interface> 123456789" (ohne Null am Anfang)
Für Testanrufe an sich selbst:
"isdnctrl addphone <interface> in 123456789" (ohne Null am Anfang)
"isdnctrl addphone <interface> out 0123456789" (mit Null am Anfang)
* Modememulation:
"AT&e123456789" (ohne Null am Anfang)
* Netzinterfaces:
"isdnctrl eaz <interface> 123456789" (ohne Null am Anfang)
Für Testanrufe an sich selbst:
"isdnctrl addphone <interface> in 123456789" (ohne Null am Anfang)
"isdnctrl addphone <interface> out 0123456789" (mit Null am Anfang)
In Österreich muß als eingehende MSN/EAZ immer "0" für die
erste (oder einzige) Rufnummer verwendet werden. Alle weiteren
MSNs sind normal zu setzen.
Ian James
Customer Service Manager
SpellCaster Telecommunications Inc.
73 Laird Drive, Suite 206
Toronto, Ontario
Canada M4G 3T4
Phone: 1 (800) 238-0547
Fax: (416) 425-0854
E-mail: ipj@spellcast.com or sales@spellcast.com
http://www.spellcast.com
http://www.siemens.de/, gibt's einen Haufen PDF-Files drauf.
Wenn Dir eine CD-ROM schriftlich genug ist: Technical Product Information
for Siemens Semiconductors, Best.Nr. B192-H6641-X5-X-7400
Siemens AG, Semiconductor Group, Balanstr. 73, Pf. 801709, D-81617
München, Fax 089-4144-3952.
(Zitat aus dem Siemens Handbuch)
Richten Sie bitte Ihre Bestellung an:
Siemens AG
LZF Semiconductor Book Shop
Postfach 2352
90713 Fürth-Bislohe
Tel (0911)3001-220/224
Fax (0911)3001-238
Preisgruppen (1994)
I DM 5.-
II DM 10.-
III DM 20.-
IV DM 30.-
ISAC S PEB 2085; PEB 2086 ISDN Subscriber Access Controller
Best-Nr. B115-H6485-G1-X-7600, 328 Seiten Preiskat. IV
HSCX - High Level Serial Communication Controller Extended
Best-Nr. B115-H6520-G1-X-7600, 140 Seiten Preiskat. III
oder als CD-ROM
Technical Product Information for Communication ICs (Edition 1, Jun
95)
Best-Nr. B193-H6905-X-X-7400, Preis ?
Zitat O'Reilly Katalog 1997 (frisch von der Buchmesse):
"Buchhändler erzählen uns, daß einige Bücher manchmal so stark mit den
Tieren identifiziert werden, daß Kunden z.B. gar nicht mehr nach dem
eigentlichen Titel, sondern z.B. einfach nur nach dem 'Kamel-Buch'
(Programming Perl) fragen."
Titel: sendmail (3. Auflage 9/94)
Autor: Costales, Allman, Rickert
ISBN: 1-56592-056-2
Kosten: 66.-- DM
http://www.ora.com/catalog/sendmail/noframes.html
http://www.lob.de/