Das ist ein Speicherproblem. Es bedeutet, daß Du zuwenig unfragmentierten Speicher hast. Während 2.0.x Kernel mit kleiner Speicherausstattung/langsamer Hardware funktionieren mögen (das Anrufbeantworter-System des Autors ist ein 386er und läuft mit 4MB RAM), kannst Du auch mit 32M RAM mit dem Problem der Speicher-Fragmentierung konfrontiert werden. Das Problem wurde seit der Kernelversion 2.2.14 verringert indem ISDN4LINUX's Speicherbelegung auf den Gebrauch von vmalloc umgestellt wurde.
Du kannst versuchen, den Speicherbedarf zu senken (siehe trouble_littlememory), ISDN4LINUX in den Kernel fest einzubinden oder ein umfangreiches Programm zu starten und gleich wieder zu beenden um diese Probleme zu mindern.
Versuche die folgenden Ansätze:
/usr/src/linux/include/linux/isdn.h
die Zeile
#ifdef CONFIG_COBALT_MICRO_SERVER
#if 1
include/linux/isdn.h
und übersetze den Kernel neu.
Empfohlen werden die folgenden Schritte:
ATS18=1
auf
Audio setzen. Nun sollte das Telefon bei der Eingabe von
ATDxxxxxx
klingeln, wobei xxxxxx Deine eigene MSN ist./dev/ttyI0
und im zweiten auf
/dev/ttyI1
. Anschließend wähle 'Exit' und starte die
Modem-Emulation mit 'ATZ' und 'AT&Exxxxxx' (wobei
xxxxxx Deine eigene MSN ohne Vorwahl ist). Fertig. Im ersten Fenster
wählst Du Deine eigene Nummer mit ATDxxxxxx. Im zweiten Fenster
solltest Du nun 'CALLER NUMBER: xxxxxxx' und 'RING' sehen. Nimm den
Ruf im zweiten Fenster mit 'ATA' an und es erscheint die Meldung
'CONNECT 64000/X.75' in beiden Fenstern. Du kannst jetzt Zeichen
von einem zum anderen Fenster senden (schalte LOCAL ECHO ein um die
Zeichen im sendenden Fenster zu sehen).:-)
dmesg
einsehen kannst.
kernel: HSCX version A:5 B:5
und kernel: channels 2
erscheinen. A:4 B:4
ist ebenfalls in Ordnung. Andere Werte
(insbesondere A:??? B:???
) bedeuten, daß die Karte nicht
richtig erkannt wurde.
HiSax wird nur geladen wenn die Hardware gefunden wird und die passenden
Interrupts ausgelöst werden können. Das bedeutet, die Karte ist
richtig im Computer installiert und es bestehen keine
Hardware-Konflikte. Es bedeutet nicht, daß alles funktionieren
wird (z.B., verdrehte oder gebrochene Kabel, falsch gesetzte
Terminatoren).
cat /proc/interrupts
11: 3 + hisaxBei einem Anruf an Dich selbst sollte sich die Anzahl der ausgelösten Interrupts erhöhen.
cat /proc/ioports
Eine Erklärung dieser Meldung bekommst Du mit dem Befehl man
isdn_cause
.
Bei dem sehr verbreiteten Fehler "cause: E001B" sieh Dir die folgende Frage
trouble_e001b an.
Dies ist ein sehr verbreiteter Fehler und bedeutet (siehe man
isdn_cause
): EuroISDN (E), User-Seite (00), außer Funktion
(1b).
Zusammen genommen bedeutet das entweder, daß der Treiber keine
Layer 1 Verbindung herstellen kann (Kabelproblem, Hardwarefehler,
verborgene Hardwarekonflikte - siehe Bereich
hardware) oder er kann keine Layer 2 Verbindung bekommen
(falsche Konfiguration: kein EuroISDN, kein automatisches TEI
unterstützt, Point-to-Point BRI anstelle von Multi-Device - siehe
Bereich
config).
Das bedeutet, daß Du die Option Euro Protocol ISDN DSS1 bei der Kernelkonfiguration nicht gesetzt hast. Aktiviere diese Option und kompiliere den Kernel neu.
ISDN4LINUX setzt beim Wählen den Serviceindikator auf 'digital data'. Die Vermittlungsstelle stellt solche Anrufe tatsächlich an analoge Geräte wie Telefon oder Fax durch. Diese analogen Geräte antworten jedoch nur auf analoge Anrufe und ignorieren daher den digitalen Anruf.
Die folgenden Informationen sind ziemlich alt. Gib mir bitte bescheid, wenn Du feststellst, daß die Gastzugänge nicht mehr erreichbar sind:
Folgende Server bieten Gastzugänge für Modem-Emulation oder IP:
emoenke@gwdg.de
:
ftp://ftp.gwdg.de/pub/linux/isdn/isdn4linux-gwdg/rc.isdn-Beispiel
zu findenden Netz-Setup kannst Du NetCall unter 0551-7704103 erreichen
(funktioniert innerhalb Deutschlands so wie es dasteht, von ausserhalb
Deutschlands muss die Telefonnummer geändert werden).
hifi@scorpio.in-berlin.de
:
Es gibt einen 'Gast'-Zugang unter +49 30 67 19 81 01 (X.75, mgetty). Dort liegt die Stones-HTML-Seite mit Bildern in Postscript-Format bereit zum Testen eines Downloads. Jeder, der ein Ziel zum Anwählen braucht, kann es benutzen. Auf ...81 03 lauscht ein getty mit HDLC. Als Gast betrittst Du dort eine Art Mailbox und kannst einige News lesen.
In diesem Fall zeigt der Aufruf 'fuser -v /dev/isdn* /dev/ippp* /dev/cui* /dev/ttyI*' welche Prozesse diese Geräte belegen.
telesctrl id 3 1 --- dec module_count telesctrl id 4 1 --- inc module_count
tcpdump kommt nicht immer mit den besonderen encapsulations zurecht, die mit ISDN4LINUX möglich sind, speziell nicht mit syncPPP. Zur Abhilfe muss tcpdump gepatcht werden.
Michael Stiller
michael@toyland.ping.de
schrieb am 23. Okt. 1996:
Tip für ftp:
ftp://ftp.gwdg.de/pub/misc/isdn/linux/isdn4linux-gwdg
Dort gibt es den Patch: 'tcpdump-3.0.4-1-isdn.dif.gz'
und der Rest liegt auf:
/pub/linux/mirrors/funet/PEOPLE/Linus/net-source/tools/tcpdump-3.0.4-1.tar.gz
Du musst eventuell etwas ändern, abhängig von dem Namen Deines ISDN Interfaces (bei mir ist das bri0). Von sich aus erkennt der Patch nur Interfacenamen wie isdn* und isdnY*.
Des weiteren schrieb Henning Schmiedehausen
henning@pong.iconsult.com
am 30. Okt. 1996:
Nachdem ich feststellte, daß der Patch von Eberhard Moenkeberg auf ftp.gwdg.de mit CISCO-HDLC nicht zurechtkommt, schrieb ich meinen eigenen Patch für tcpdump-3.0.4, der das Interface fragt, welche encapsulation es benutzt und dann die entsprechende Einstellung vornimmt. Der Patch ist für die tcpdump-3.0.4-1.tar.gz Distribution, erhältlich z.B. bei
ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/tools
Dieser Patch erkennt rawIP, ISDN-IP und CISCO-HDLC und kann Dumps dieser Pakete durchführen.(Der Patch war der Message beigefügt - man sollte ihn leicht im Archiv der Mailingliste finden können - Editor.)
Sascha Ottolski
sascha@alzhimer.isdn.cs.tu-berlin.de
gab am 05. Nov. 1996
den folgenden Tip:
Dies ist ein isdn4k-utils-2.0/tcpdump-3.0.3-isdn.diff ! Es funktioniert mit folgenden Änderungen: In der Datei tcpdump-3.0.3-isdn/libpcap-0.0/pcap-linux.c findest Du nach dem Patchen die folgende Zeile: else if (strncmp('ppp', device, 3) == 0) Entweder benennst Du Deine PPP-Devices pppX anstatt ipppX, oder Du änderst diese Zeile entsprechend, z.B.: else if (strncmp('ippp', device, 4) == 0) Dann erkennt tcpdump auch syncPPP. Es macht es zumindest bei mir.
Der Treiber sollte mit dem Befehl 'insmod -m' geladen werden. Die Ausgabe des Befehls muss in eine Form ähnlich der System.map gebracht werden, z.B. so:
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
Prüfe ob die erhöhte Festplattenaktivität an der Menge der Meldungen liegt, die in das Logfile geschrieben werden. Wenn ja, kannst Du die Ausgabe durch:
isdnctrl verbose 0
Eigentlich läuft ISDN4LINUX, wenn es sauber konfiguriert ist, auf viel schwächeren Maschinen als Du erwarten wirst (bei mir läuft immer noch eine ältere Version auf einem 386-25, der nur 4MB RAM besitzt). Neuere Versionen von ISDN4LINUX und des Kernels benötigen jedoch mehr Speicher. Möglicherweise ist etwas Bearbeitung nötig um sie auf sehr alter Hardware laufen zu lassen. Schau Dir die Frage trouble_outofbuffers an, wenn Du knapp an Buffern wirst. Siehe Frage trouble_littlememory zur Reduzierung des benötigten Speichers.
Diese Fehler tauchen auf, wenn I4L seine Buffer nicht schnell genug
verarbeiten kann, was oft durch schlechte Soundkarten oder deren Treiber
verursacht wird, die die Interrupts zu lange deaktivieren! Es kann auch
durch alte Hardware ausgelöst werden (passierte dem Autor der FAQ, der
vbox
auf einem alten 386-25 mit nur 4MB RAM benutzen wollte). Du
kannst das mit einer Erhöhung der Anzahl und Größe der Buffer
umgehen. Suche in den Header-Dateien des Sourcecodes nach Definitionen
wie:
#define HSCX_RBUF_ORDER 1 #define HSCX_RBUF_BPPS 2 #define HSCX_RBUF_MAXPAGES 3
Nach einem Anhalten des Systems mit dem Befehl reboot
oder
Ctrl-Alt-Del
solltest Du den Reset-Knopf drücken (=
Kaltstart). Manchmal braucht die Karte ein Hardware-Signal um richtig
initialisiert zu werden.
Peter Hettkamp
Peter.Hettkamp@kassel.netsurf.de
schrieb:
xosview reagiert, zumindest bei mir in der Version 1.4, auf das IP Accounting im Kernel. Also konfiguriere und, falls nötig, baue einen neuen Kernel und aktiviere es mit:
ipfwadm -A -a -S deine-ip-addresse-hier -D 0.0.0.0/0 ipfwadm -A -a -D deine-ip-addresse-hier -S 0.0.0.0/0
(Ich weis nicht wie das mit dynamischen IP-Addressen geht. Ich habe eine feste Addresse.)
Was ist auf der 'Win95-Box' als Nameserver eingetragen? Solange im LAN kein eigener Nameserver betrieben wird, muss natürlich auf allen Computern des LAN der Nameserver des Providers eingetragen werden.
Prüfe nach:
Wolfgang Barth schrieb am 5. Januar 1997:
Ich habe festgestellt, dass das lokale Netzwerk nach der ersten Verbindung über ippp0 wieder erreichbar ist. Dann wird die Addresse 0.0.0.0 nicht mehr im ifconfig für ippp0 angezeigt sondern vielmehr die Addresse, die aus dem Pool des PPP-Partners zugewiesen wird. Dies wurde bereits in de.comp.os.linux.networking behandelt, zusammen mit dieser Lösung: Setze einfach ippp0 auf eine willkürliche IP aus dem Pool. Dann wird das lokale Netzwerk nach dem Booten auch mit der defaultroute Probleme haben und die IP in ifconfig wird auf jeden Fall überschrieben.
Da die Zulassung des HiSax-Treibers nur für den unveränderten Quellcode gilt ist dieser durch eine Prüfsumme geschützt. Wenn Du die Fehlermeldung bekommst, hast Du entweder selbst den Code geändert oder der Autor hat nach einer Änderung die Prüfsumme nicht aktualisiert (möglicherweise wurden die Zulassungstests mit dem geänderten Code noch nicht durchgeführt).