Software: Apache/2.2.3 (CentOS). PHP/5.1.6 

uname -a: Linux mx-ll-110-164-51-230.static.3bb.co.th 2.6.18-194.el5PAE #1 SMP Fri Apr 2 15:37:44
EDT 2010 i686 

uid=48(apache) gid=48(apache) groups=48(apache) 

Safe-mode: OFF (not secure)

/usr/share/doc/isdn4k-utils-3.2/   drwxr-xr-x
Free 51 GB of 127.8 GB (39.9%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     i4lfaq-de-23.html (7.52 KB)      -rw-r--r--

23. callback: Callback

23.1 callback_delay: Ein hereinkommender Ruf wird von I4L abgelehnt. Anschließend ruft I4L zurück. Die Rufablehnung wird von der anderen Seite nicht erkannt und sie versucht, sich weiterhin bei I4L einzuwählen.

Die meisten Probleme bei Callback können durch die Einstellung des callback delay mit isdnctrl cbdelay gelöst werden. Eine Sekunde auf der wählenden Seite A (den Callbackmodus auf 'out' setzen) und zwei Sekunden auf der angewählten Seite B (den Callbackmodus auf 'in' setzen) genügt in den meisten Fällen.

Der Grund für dieses Problem liegt in einem Designfehler des Treibers für den Verbindungslevel.

A wählt B an um einen Rückruf auszulösen. B wehrt den Anruf ab und ruft A zurück und stellt so eine arbeitende Verbindung innerhalb weniger als 4 Sekunden her. Der auslösende Anruf von A nach B wird jedoch erst nach 4 Sekunden vom ISDN Dienstleister beendet (um anderen Geräten auf der B Seite eine Chance der Rufannahme zu geben). Wenn dieser Ruf beendet wird, wird leider auch die bestehende Verbindung von B nach A beendet.

23.2 callback_cisco: Aus irgendeinem Grund kann I4L nicht bei einer Cisco zurückrufen?

Torsten Hentschel Torsten.Hentschel@DInet.de schrieb am 03. Oktober 1996:

Eine Cisco wählt möglicherweise so schnell und häufig, daß der ipppd keine Chance des Zurückrufens hat. Die Ciscos sind so programmiert (klare Aussage eines Cisco-Entwicklers): Wenn eine Cisco ein Paket empfängt, das durch eine auf 'dial on demand' eingestellte Telefonverbindung hinausgehen soll, und es ist ein B-Kanal zur Hinauswahl frei, wird sofort gewählt. Wenn in einem solchen Fall (wie bei Delta Internet seit einem halben Jahr) eine Cisco mit 8 B-Kanälen auf der anderen Seite steht und jemand ein einfaches 'ping RemoteIP' eingibt, wird die Cisco im schlimmsten Fall alle 8 B-Kanäle zum Hinauswählen benutzen. Natürlich kann sie nicht eine Telefonnummer gleichzeitig auf zwei B-Kanälen wählen (es wäre sofort "besetzt"). Die Programmierung der Cisco ist nicht so dumm, sie richtet den nächsten B-Kanal zum Hinauswählen ein bevor sie annimmt, daß der vorherige B-Kanal versagt hat. Solch eine Cisco arbeitet wie ein Maschinengewehr was das Hinauswählen betrifft. Und I4L bekommt keinen freien B-Kanal zur Einwahl wenn die Cisco das nicht will. Das Schlechte daran ist, daß eine Cisco immer (auch bei einer Konfiguration mit 'callback client' = I4L ruft zurück) erwartet, daß die andere Seite den Ruf annimmt, beide auflegen und dann der Rückruf kommt. Username und Password müssen beim Gebrauch von PPP immer vor einem Rückruf ausgetauscht werden. Dadurch stellt man sicher, daß die Person, die den Rückruf verlangt, auch dazu berechtigt ist. (Cisco scheint sich an die Regel der (Deutschen) Telekom zu halten, daß keine Informationen ohne B-Kanal-Verbindung ausgetauscht werden dürfen. Ein Rückruf-Verlangen, identifiziert nur durch die anrufende Telefonnummer, kann im Zweifelsfall als Übertragung von Informationen betrachtet werden).

Torsten Hentschel Torsten.Hentschel@DInet.de schrieb zusätzlich am 20. November 1996:

Ich habe den Rückruf über PPP mit zwei CISCOs oft versucht. Nach meiner Erfahrung werden Versuche mit der Kombination CISCO - Linux nicht funktionieren. Eine CISCO handelt ein Rückruf-Verlangen immer per PPP aus. Dazu muss die Gegenseite zuerst den Ruf annehmen und die gesamte Verhandlung (Berechtigung,...) durchführen. Dann legen beide auf und der Rückruf wird durchgeführt. Die Befehle von isdnctrl in Linux beeinflussen nur die Netzwerk-Devices des Kernels und haben keinen oder nur wenig Einfluß darauf, wie ipppd Rückrufe durchführt. ipppd erkennt nicht, daß er einen Rückruf der Gegenseite erwarten soll. Daher lehnt er das Angebot der CISCO über PPP, daß sie zum Rückruf bereit ist, ab. Dann nimmt die CISCO an, daß sie nicht zurück rufen soll (sie erwartet ein explizites Rückruf-Verlangen während der PPP-Verhandlung zu sehen). Die CISCO bestätigt dies, wenn Du bei ihr einloggst und ihre Debug-Meldungen über die Einwahlversuche Deines Linux-Computers mit den folgenden Befehlen ansiehst:

---

deb ppp chap
deb ppp negotiotion
deb ppp error
term mon

---

Du musst Dich über telnet einloggen, nicht auf der Konsole, da sonst die CISCO das Loggen nicht über das serielle Interface durchführen kann.

23.3 callback_ascend: Callback von einer Ascend funktioniert nur, wenn ich im Ascend-Menue 'Active=Yes' eingebe. Dann wählt die Ascend mich aber auch an, wenn meine Maschine ausgeschaltet ist.

Ulrich Klein ulik@hprc.tandem.com schrieb am 14. Dezember 1996:

Irgendwo in den Ascend-Menues kannst Du 'dial broadcast' auf "no" oder "off" setzen. Anderenfalls wird das Ding mit jedem Rundruf wählen. Zumindest mir half das. Falls jemand aus dem Netzwerk, an das die Ascend angeschlossen ist, wirklich eine Verbindung aufbauen will, musst Du die etwas seltsamen Filter benutzen. Ich glaube, es gibt da einen, der nur als Rückruf hinauswählt.

23.4 callback_banzai: Wie kann ich eine Banzai zurückrufen?

Jan-Olaf Droese jano@layla.RoBIN.de schrieb am 31. Januar 1997:

Auf der Seite der Banzai sollte ein 'c' zu der zu wählenden Nummer hinzugefügt werden. Dadurch ist sie bereit für den Rückruf. Zur Sicherheit kannst Du die Anzahl der Wählversuche der Banzai auf 1 setzen, sodaß es keine Rufüberschneidungen gibt. Auf der I4L-Maschine habe ich folgende Einstellungen vorgenommen:

---

isdnctrl callback isdn0 in
isdnctrl cbdelay isdn0 1

---

23.5 callback_microsoft: Unterstützt ISDN4LINUX Microsoft Callback (CBCP)?

Nein, das geht mit ISDN4LINUX nicht. Da es nicht so trivial zu implementieren ist, gibt es z.Zt. keinen Plan dafür.