This is a memory problem and means you don't have enough unfragmented memory. While 2.0.x kernels may work on low memory/slow hardware (the author's answering machine is a 386 and used to run with 4MB of RAM), you can run into the memory fragmentation problem even if you have as much as 32MB of RAM when running 2.2.x kernels. The problem has been eased since 2.2.14, when ISDN4LINUX's memory allocation has been changed to use vmalloc.
You can try to reduce the memory requirements (see question trouble_littlememory), compile ISDN4LINUX into the kernel, or start and then exit a large program to ease the memory fragmentation problems.
Try to do the following things:
/usr/src/linux/include/linux/isdn.h, change the line
include/linux/isdn.h, then recompile kernel.
Execute the following commands to get maximum debug output:
hisaxctrl <id> 1 0x33ff hisaxctrl <id> 11 0xf4f killall isdnlog cat /dev/isdnctrl > /tmp/ilog
The following steps are recommended:
/var/log/messages. Check for a line like this:
Call from 0,1,2345 -> 6789
ATS18=1command to audio. Now you can get the telephone to ring by dialing
ATDxxxxxx, where xxxxxx is your own MSN.
/dev/ttyI0, and the other to
/dev/ttyI1. Then choose "Exit" and start the modem emulation with "ATZ" and "AT&Exxxxxx" (where xxxxxx is your own MSN without the area code). Then you can start. On the first console you can dial your own number with ATDxxxxxx. On the second console you should now see "CALLER NUMBER: xxxxxxx" and "RING". Accept the call on the second console with "ATA", and you should then see the message "CONNECT 64000/X.75" on both consoles. You can then send characters to the other console by typing (to see the characters on your own console, turn on local echo).
kernel: HSCX version A:5 B:5and
kernel: channels 2should appear.
A:4 B:4is also okay. Other values (in particular
A:??? B:???) mean the card is not recognized correctly. HiSax is only loaded if the hardware can be found and the appropriate interrupts can be generated. This means the card is installed correctly in the computer, and there are no hardware conflicts. It does not mean that everything will work (e.g. twisted cables, broken cables, terminators).
11: 3 + hisaxWhen you call yourself, the number of received interrupts should increase.
Just have a look at
man isdn_cause to find out what the problem is.
For the very popular cause "E001B" see question
This is a very popular error and means (see
euro ISDN (E), location user (00), and out of order (1b).
Taken together means that the driver either can't get a layer 1 connect
(cable problem, hardware error, hidden hardware conflict - see section
hardware), or it can't get a layer 2 connect (wrong
configuration: no Euro ISDN, no automatic TEI supported, point-to-point
BRI instead of multi-device - see section
This means that you did not specify which D-channel protocol you want to use with HiSax. In most cases this is wrong, and you have to specify that you want to use the Euro Protocol ISDN DSS1. Only if you have a leased line you don't need to specify any D-channel protocol.
This means that you did not select the Euro Protocol ISDN DSS1 option when compiling your kernel. You have to switch this on and recompile your kernel to be able to use it.
This means that the link level protocols do not match (e.g. you tried to connect with X.75, whereas your provider answers with HDLC). Check and fix your connection parameters with:
isdnctrl l2_prot <interface> <protocol>
Isdn4linux sets "digital data" as it's own service when it calls out. The switching station does in fact route such calls to analog devices like a telephone or a fax machine. However, since the machine is analog, it will only answer analog call, and ignore the digital data call.
The following information is quite old. Please tell me if you find out that the guest sites are not available any more:
The following sites offer guest access for modem emulation or IP:
ftp://ftp.gwdg.de/pub/linux/isdn/isdn4linux-gwdg/rc.isdn-Beispielyou can test NetCall at 551-7704103 (works as is within Germany, from outside Germany you just have to change the number).
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. Whoever needs a target to call can use it. At ...81 03 there's a getty with HDLC. As guest you enter a kind of BBS and can read some news.
In this case "fuser -v /dev/isdn* /dev/ippp* /dev/cui* /dev/ttyI*" is very helpful. This helpful program shows, which processes are using those devices.
telesctrl id 3 1 --- dec module_count telesctrl id 4 1 --- inc module_count
The reason is that tcpdump does not always understand the special encapsulations that are possible with isdn4linux, especially syncppp. To change this, you need to patch tcpdump.
email@example.com wrote on 23 Oct 1996:
Tip for ftp:
There is the patch: "tcpdump-3.0.4-1-isdn.dif.gz"
and the rest is at:
You might need to hack some, depending on the name of your ISDN interface (mine is bri0). By default, it recognizes only isdn* and isdnY* as interface names.
firstname.lastname@example.org further wrote on
30 Oct 1996:
After finding the patch from Eberhard Moenkeberg at ftp.gwdg.de cannot dump cisco HDLC, I made my own patch for tcpdump-3.0.4 that asks the interface which encapsulation it used and sets itself accordingly. The patch is against a tcpdump-3.0.4-1.tar.gz distribution, for example at
This patch recognizes rawIP, ISDN-IP and CISCO-HDLC and can dump these packets.(The patch was attached to the message - it should be easy to find in the mailing list archive - Ed.)
email@example.com gave the following
tip on 5 Nov 1996:
This is a isdn4k-utils-2.0/tcpdump-3.0.3-isdn.diff ! It work, if one makes some changes: In the file tcpdump-3.0.3-isdn/libpcap-0.0/pcap-linux.c after patching you find the following: else if (strncmp("ppp", device, 3) == 0) Either you name your ppp devices pppX instead of ipppX, or change this line, e.g. else if (strncmp("ippp", device, 4) == 0) ^^^^ ^^ Then tcpdump will also recognize syncPPP. At least it does for me.
The driver should be loaded with the command "insmod -m". The output has to be transformed somewhat to be a form similar to System.map. You can do it like this:
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
Check whether the reason for the hard disk activity is caused by the amount of messages written into the logfile. If this is the case, you can reduce the output by:
isdnctrl verbose 0
Actually, properly configured, isdn4linux will on much smaller machines, than you might expect (still running an elder version on my 386-25, which used to have only 4MB RAM). However, newer isdn4linux/kernel versions need more memory, and may require some tweaking before they run on very old hardware. Have a look at question trouble_outofbuffers when running out of buffers. See question trouble_littlememory on how to reduce the amount of memory needed.
These errors happen when i4l is not able to process its buffers fast
enough. They are often caused by bad sound cards or their drivers when
they disable the interrupts too long! It may also happen on old hardware
(happened to the author of this FAQ when using
vbox on an old 386-25 with
only 4MB RAM). You may be able to work around it by increasing the number and
size of the buffers. Check the source code header files for definitions like:
#define HSCX_RBUF_ORDER 1 #define HSCX_RBUF_BPPS 2 #define HSCX_RBUF_MAXPAGES 3
After you stopped your system with the
reboot command or with
Ctrl-Alt-Del, press the reset button (=hard reset). Sometimes the card
needs to receive a hardware signal to reinitialize properly.
First check whether there is a device /dev/isdnctrl0. If there is, just create a symbolic link by executing
ln -s /dev/isdnctrl0 /dev/isdnctrl
scripts/makedev.sh, which is part of the isdn4k-utils.
In contrast to "/dev/isdnctrl: No such file or directory" the message "/dev/isdnctrl: No such device" indicates that the device /dev/isdnctrl exists, but no ISDN device driver is available. To fix, load the ISDN modules (verify with "cat /proc/modules" that they are loaded) or compile the ISDN drivers into the kernel.
xosview reacts, at least for me with version 1.4, to the IP accounting in the kernel. So, configure, if necessary build a new kernel, then couple with: 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 (I don't know who it works with variable IP addresses. I have a fixed address.)
What is entered on the "Win95 box" for the name server? As long as the router has no name server of its own, then the provider's name server of course has to be entered on all computers on the LAN.
Wolfgang Barth wrote on 5 Jan 1997:
I've noticed that after the first connection via ippp0 that the local network can again be reached. Then the address 0.0.0.0 is no longer listed in ifconfig for ippp0, but instead the address assigned from the pool by the PPP partner. This was already discussed in de.comp.os.linux.networking, along this possible solution: Simply set ippp0 to a dummy IP number from the pool. Then the local network will have problems after booting, even with the default route, and the IP number in ifconfig will be overwritten anyway.
Since the certification of the HiSax driver is only valid for unchanged source code, the source code is protected by a checksum. When you get this message, then either you have changed the source code yourself, or the author did not update the checksum when changing the source code (reason could be that the complete certification tests have not yet been run on the changed code).
With HiSax you can view the accumulated number of hardware CRC errors with:
hisaxctrl <id> 0 0
hisaxctrl <id> 0 99
You have to regenerate the files from automake/autoconf with your version of automake/autoconf. You can do it with the following shell script (assuming you stored the source code for the isdn4k-utils under /isdn/isdn4k-util):
cd ~/isdn/isdn4k-utils for i in capi20 capiinfo capifax capiinit rcapid ; do cd $i rm -f lt* aclocal libtoolize --force --automake --copy automake --add-missing --copy autoconf cd .. done for i in eicon isdnlog ipppd ; do cd $i autoconf cd .. done
Unfortunately the udev/hotplug mechanism of current kernels (written in November 2005) loads hisax without the needed parameters. To check whether this is the issue of missing parameters unload the hisax module with rmmod:
modprobe -v hisax type=35 protocol=2