Most problems with callback can be solved by adjusting the callback delay with "isdnctrl cbdelay". One second has been successful in many cases.
Manfred Dill
manfred.dill@bmw.de wrote on 18 Dec 1996:
You should use a second device ippp1 for which callback can be used. Because of an error in i4l, the first device is used for callback and is not released. When the connection is ended, the third device (if it exists) is opened and the circle is complete.
For devices, see the appropriate questions under "Dial-in".
Torsten Hentschel
Torsten.Hentschel@DInet.de wrote on 3 Oct 1996:
A Cisco may dial so heavily that the ipppd has no chance to callback. That's how they are programmed (firm statement of a Cisco developer): If a Cisco receives a packet that should be routed through a "dial on demand" telephone connection, and there is a D-channel available for dialing out, it dials out immediately. If in such a situation (which has be the case with Delta Internet for half a year now) a Cisco with 8 D-channels is on the other side and somebody does a simple "ping RemoteIP" then the Cisco will use (worst case) all 8 D-channels to dial out. Of course it can't dial the same telephone number with two D-channels in parallel (would be immediately busy). Its programming is not so stupid, but it sets up the next D-channel for dialout before it assumes the previous D-channel as failed. Such a Cisco works like a machine gun in respect to dialout. And i4l won't get a free D-channel for dialin if the Cisco doesn't want. The bad thing: a Cisco always expects (even when configured on "callback client" = i4l dials back) that the other side unhooks the line, then both hang up and then comes the callback. Username and password always have to be exchanged before the callback is allowed when using PPP, to be sure that the person requesting callback is allowed to do so. (Cisco seems to obey the rules of the (German) Telekom that no information are to be ex- changed without a B-channel connection. A callback request just by caller id could in doubt be considered as a transmission of information).Torsten Hentschel
Torsten.Hentschel@DInet.de additionally wrote on
20. Nov 1996:
I've often tried callback over PPP with two CISCOs. From my experience, trials in the combination CISCO - Linux will not be successful. A CISCO always handshakes a callback request via PPP. To do this, the other side has to first unhook and then do all the handshaking (authentication,...). Then both hang up and the callback is placed. isdnctrl commands of Linux influence only the kernels net devices and have no or hardly any influence on how the ipppd handles callbacks. He does not recognize that he is supposed to expect that the remote side calls back. Accordingly he rejects the offer of the CISCO via PPP, that the CISCO is ready to call back. Then the CISCO assumes that it should not call back (it wants to see an explicit callback request during the PPP handshaking). The CISCO will confirm this when you log onto it and check with these commands: deb ppp chap deb ppp negotiotion deb ppp error term mon its debug messages about the dial in trials of your Linux computer. You have to do this via telnet instead of on the console - otherwise the CISCO won't be able to handle the logging via the serial interface.
Ulrich Klein
ulik@hprc.tandem.com wrote on 14 Dec 1996:
Somewhere in the Ascend menus you can set "dial broadcast" to "no" or "off". Otherwise the thing will dial with every broadcast. At least that helped me. In case anyone from the network on which the Ascend is attached really wants to establish a connection, then you have to use the strange filters. I believe there's one that will dial out only for callback.
Jan-Olaf Droese
jano@layla.RoBIN.de wrote on 31 Jan 1997:
On the Banzai side, a `c' should be added to the outgoing number, so it will be ready for the return call. Just to be safe, you can the dialout attempts on the Banzai to 1, so there won't be any call collisions. On the i4l I've set the following:
isdnctrl callback isdn0 in isdnctrl cbdelay isdn0 1