ISDN4Linux, how?

ISN network and Linux, how?

Thu Mar 10 19:41:07 CET 2005
Copied from



isdn4linux configuration (kernel part)

patching the kernel

Somtimes it can be necessary to patch the kernel sources with a newer version of the ISDN code. The ISDN stuff is still a work in progress, and sometimes it can be advantageous to be able to use the newest features (e.g. a new type of ISDN card). At this time this is especially important for the 2.2.x kernels; these have not been updated with respect to the ISDN code for a very long time. Note: the "2.1" ISDN code is also used for the 2.2.x kernels! Anyhow, from now on the intention is to keep the official kernel versions in sync with the isdn4linux development, so adding your own patches shouldn't be necessary anymore.

You want to patch regardless? Well, then follow these steps :-)

Kernel config

The following must be selected in the kernel config:
    <*> ISDN support
    [*] Support synchronous PPP
    <M> HiSax SiemensChipSet driver support
    [*] HiSax Support for EURO/DSS1
Here ISDN is part of the monolithic kernel, and HiSax is configured as a module. Having HiSax as a module is a must if you have a Plug-n-Pray card; after all, you must first configure the card before the HiSax driver can access it. See further down for info on using isapnp.

You must also select one or more types of card. For the "normal" Teles kaart this is:

    [*] HiSax Support for Teles 16.3 or PNP or PCMCIA
but if you have another card, choose whatever is appropriate. You can also select more than one card here; however, each additional type causes the driver to increase its size.


HiSax parameters

The Teles S0/16.3 ISDN adapter is commonly used with the following settings: This can be configured via the modprobe command when HiSax is used as a module, or else with a LILO argument when HiSax is compiled into the kernel. So:
modprobe hisax io=0x180 irq=10 type=3 protocol=2 id=line0
in kernel (via lilo.conf append= or supply it manually at the LILO prompt)
Note: the IRQ is set by the driver; you do not need a (DOS/Win) configuration program for this! Great, isn't it... Only the I/O address needs to be configured on the card via the dipswitches.

For other cards than the Teles 16.3 the parameters will probably be different! Look in the HiSax documentation supplied with the ISDN4Linux kernel source (probably to be found here). Some type numbers are the same for ISA and PCI; in that case, the ISA card is indicated by supplying the IRQ etc.; don't do that with a PCI card! Those parameters are detected automatically with PCI cards.

Plug-n-Pray cards

ISA crds are increasingly of the "Plug-n-Pray" type (officially it's "Plug-n-Play" but that's a mistake made by the marketing department :-). These cards don't have any jumpers or switches; instead, they must be configured by software according to some standard. By the way, PCI cards are actually also a sort of PnP, but this time done right (buggy BIOSes and cards aside). So, it's silly to speak of "PnP PCI" cards.

To be able to use PnP cards under Linux, an isapnp utility has been developed. You use this utility in two steps:

De eerste stap hoeft maar een keer te gebeuren. De tweede steeds nadat het systeem geboot is.

Example: configuring a Dynalink IS64PH (Asuscom) card: the /etc/isapnp.conf contains the following:

   (CONFIGURE ASU1688/68 (LD 0
   #     Logical device decodes 10 bit IO address lines
   #         Minimum IO base address 0x0100
   #         Maximum IO base address 0x03f8
   #         IO base alignment 4 bytes
   #         Number of IO addresses required: 4
   (IO 0 (BASE 0x0104))
   #     IRQ 3, 4, 5, 9, 10, 11, 12 or 15.
   #         High true, edge sensitive interrupt
   (INT 0 (IRQ 10 (MODE +E)))
   #     *** ERROR *** No IRQ specified!
   (ACT Y)
If you've just done the pcpdump step, all lines have '#' in front of them. Remove the '#' characters from the lines you want to activate; don't forget to do that with the"(ACT Y)" line. Now do "isapnp /etc/isapnp.conf" to pass the configuration to the card.

Tip: If isapnp complains "already in use", look if there's a (CHECK) in the file. If so, remove it and try again.

After that, HiSax can be loaded with

   modprobe hisax io=0x104 irq=10 type=12 protocol=2 id=line0
; note that the I/O and IRQ from the isapnp.conf are passed to HiSax.

HiSax messages

When HiSax is booted or loaded, something like this should appear:
    Jul 29 15:53:12 wurtel kernel: HiSax: Linux Driver for passive ISDN cards
    Jul 29 15:53:12 wurtel kernel: HiSax: Version 3.0
    Jul 29 15:53:12 wurtel kernel: HiSax: Layer1 Revision
    Jul 29 15:53:12 wurtel kernel: HiSax: Layer2 Revision
    Jul 29 15:53:12 wurtel kernel: HiSax: TeiMgr Revision
    Jul 29 15:53:12 wurtel kernel: HiSax: Layer3 Revision
    Jul 29 15:53:12 wurtel kernel: HiSax: LinkLayer Revision
    Jul 29 15:53:12 wurtel kernel: HiSax: Total 1 card defined
    Jul 29 15:53:12 wurtel kernel: HiSax: Card 1 Protocol EDSS1 Id=line0 (0)
    Jul 29 15:53:12 wurtel kernel: HiSax: Teles IO driver Rev.
    Jul 29 15:53:12 wurtel kernel: HiSax: Teles 16.3 config irq:9 isac:0x980  cfg:0xD80
    Jul 29 15:53:12 wurtel kernel: HiSax: hscx A:0x180  hscx B:0x580
    Jul 29 15:53:12 wurtel kernel: Teles3: ISAC version (0): 2086/2186 V1.1
    Jul 29 15:53:12 wurtel kernel: Teles3: HSCX version A: V2.1  B: V2.1
    Jul 29 15:53:12 wurtel kernel: Teles 16.3: IRQ 9 count 3
    Jul 29 15:53:12 wurtel kernel: Teles 16.3: IRQ 9 count 6
    Jul 29 15:53:12 wurtel kernel: HiSax: DSS1 Rev.
    Jul 29 15:53:12 wurtel kernel: HiSax: 2 channels added
    Jul 29 15:53:12 wurtel kernel: HiSax: module installed
If your system is not configured to show these messages on the console, recent kernel messages can be displayed with "dmesg".

With the old teles driver, the card could be specified incorrectly, and that wrong type would be "found". Howeverm the HiSax driver is pretty good at detecting such errors; if HiSax detects a specific card, you can assume that it will work. HiSax can also generate interrupts (first 3 interrupts, then 6), so that it can check whether the interrupt setting is correct (i.e. no conflicts).

i4k-utils installation

To be able to use the ISDN facilities, the isdn4k-utils 3.0(-beta) package must be built and installed.

Download the package, unpack it, and configure it withmake config (this works in a similar way to configuring the kernel with "make menuconfig"), and compile it with make. The config options should be fairly self-explanatory; otherwise, try the help for each option.

If there are problems with this step, then the cause can usually be found in differences between the installed packages on the developers' systems and yours. Often these packages are the cause:

However, it should not be difficult to work out (possibly with the help of the isdn4linux mailing list; english postings cheerfully accepted and answered also in english, even tough most messages are in german).

Don't forget to run the script! This creates the device entries in /dev necessary for ISDN. Unfortunately this script was not included in the 2.1b1 utilities package. This has been remedied in the 3.0 version.

You usually want to run some commands etc. during system boot / initialization. In Slackware you put put these into /etc/rc.d/rc.local. I used to have the following there (back when I ran Slackware instead of Debian):

    /sbin/isdnctrl verbose 3
    /sbin/isdnlog -sS -v1 -w10 -m0x17d7 -l0x3d7 -C /dev/console -D /dev/isdnctrl
Isdnlog can log all ISDN activity, and hence can be useful when testing with minicom (see below); you see all incoming calls, and hence know whether you are using the right number for yourself. See here for more info about isdnlog. You can also use the dmesg command to check on kernel messages, which also contain number info.


Testing the card and the physical connection

At first I didn't succeed in calling myself, because I did not include my areacode in my "own" number. Now it works, by performing the following steps:

isdnlog and friends

You can log all sorts of things with isdnlog. Incoming calls can be displayed and with some luck the areacode is translated into a town name as well. Of course, the number info (CLI) must be available for this.

Somewhere further up in this document I gave an example of invoking isdnlog; here it is again:

    /sbin/isdnlog -S -v1 -w10 -m0x17d7 -l0x3d7 -C /dev/console -D /dev/isdnctrl
execute scripts (what scripts and when are configured in isdn.conf)
verbosity 1
display the throughput statistices every 10 seconds.
show certain types of messages on the output
send certain types of messages to the syslog
-C /dev/console
send output (e.g. from -m) to /dev/console
-D /dev/isdnctrl
obtain the ISDN activity info from here

types of messages for -m and -l
bittype of messages
0x0008Log /dev/DEVICE (b.v. isdnctrl) messages to /tmp/DEVICE
0x0010show phone numbers immediately
0x0020charge info (subscription may be needed)
0x0040connect messages
0x0080hangup messages
0x0100cause when hangup
0x0200time messages
0x0400throughput in bytes (each -wX seconds)
0x0800B-channel state
0x1000service indicator (voice, data, ...) with notice msgs
0x2000est. time until next charge pulse (german usage)

Add the desired message types (in hex!) and pass the result with the -m and -l options.

I'll give some additional explanation at some later stage.

mgetty configuration

It is possible to enable login sessions directly on your Linux system via ISDN (i.e. not via a network connection, but via X.75). This can be useful when configuring a friend's system, and you want to connect to your system at home to check on something; at that stage you usually don't have the rest working yet...

In most cases mgetty is used for this, so that's what I've done as well. I myself currently use version 1.1.14 (the debian version that I downloaded at the time), but undoubtedly there are more recent versions available, or simply use the version supplied with your distribution. Compiling and installing this is pretty straightforward (at least, I thought so). I have this in my inittab:

i1:23:respawn:/sbin/mgetty ttyI1
and in /etc/mgetty/mgetty.config (amongst others):
port ttyI1
  init-chat "" ATZ OK AT&Exxxxxxxxx OK AT&B512 OK
  data-only y
  speed 38400
Put your MSN in the place of the 9 x characters, probably with the areacode without the zero; refer to what you used in the minicom test, this is basically the same principle except that mgetty will take care of answering the connection. Similarly you can use minicom to test whether mgetty is configured correctly. Don't forget that you may need to run init q to get the new inittab read.

syncPPP to your ISP

Now, for the part that is the most interesting (at least, that's what I think!) I use to use Demon, where you get a static IP address. I now have a Cistron Broadband ADSL line. Dynamic IP numbers have the disadvantage that when the connection drops (due to an idle timeout), and fresh IP activity causes a dial-on-demand reconnection, you'll probably receive another IP address which makes it impossible to continue the old IP connection (new IP connections aren't a problem). This is bad when logged into a remote system; for HTTP connections it's not, as those don't last so long. Another problem is that the outgoing IP packet that caused the dialout probably has the wrong source IP address; however, in 2.0.31 and later there is a workaround for this:
    echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo a 2 for 'verbose mode'.
echo a 0 to disable the facility.

The procedure for initializing an ISDN network interface is basically:

I recommend the following script to initialize the whole ISDN network stuff (of course, replace the xxx's, the 999's, "hostname", "ispname" etc. with the correct values!):
MYUSER=myname           # my username at the ISP
REMNAME=demon           # name of ISP's system
MYIP=       # my fixed IP number (use if no fixed)
REMIP=    # IP nummer van ISP (this is almost always fixed)
MYMSN=123456789         # my number, without 0, with areacode
REMMSN=0748800806       # number of ISP
REMMSN2=0206233733      # alternate ISP number

/sbin/isdnctrl verbose 3            # probably already done
/sbin/isdnctrl system on            # ditto, but to be sure...
/sbin/isdnctrl addif ippp0          # first interface should be ippp0
/sbin/isdnctrl eaz ippp0 $MYMSN
/sbin/isdnctrl addphone ippp0 out $REMMSN2  # last one added is
/sbin/isdnctrl addphone ippp0 out $REMMSN   # called first!
/sbin/isdnctrl huptimeout ippp0 90  # after 90s of no traffic: hangup
/sbin/isdnctrl l2_prot ippp0 hdlc   # default, may be left out
/sbin/isdnctrl l3_prot ippp0 trans  # also default
/sbin/isdnctrl encap ippp0 syncppp  # we want syncPPP, dammit!
#/sbin/isdnctrl status ippp0 on     # if using HiSax 3.0
/sbin/isdnctrl dialmode ippp0 auto  # if using 2.0.36 or current CVS version
/sbin/ifconfig ippp0 $MYIP pointopoint $REMIP
/sbin/route add $REMIP ippp0        # $REMIP can be reached via ippp0
/sbin/route add default netmask 0 ippp0     # all non-local traffic goes to ippp0
/sbin/ifconfig ippp0 -arp -broadcast # don't allow arps and broadcasts

/sbin/ipppd user $MYUSER remotename $REMNAME \
    $MYIP:$REMIP                    \
    name $MYUSER                    \
    -detach                         \
    mru 1500                        \
    mtu 1500                        \
    lcp-restart 1                   \
    /dev/ippp0 &

Make sure that the IP numbers $MYIP and $REMIP are already listed in /etc/hosts; the ifconfig ippp0 command will try to resolve the IP numbers, which will otherwise fail.

The  lcp-restart 1 has to do with retries with the LCP (link control protocol) negociation to check user / password etc.; often this is started before the other side is prepared for this, and this speeds up the retry, saving a couple of "costly" seconds.

People with dynamic IP numbers should replace the $MYIP:$REMIP with ipcp-accept-local ipcp-accept-remote and apply the /proc/sys/net/ipv4/ip_dynaddr stuff as escribed above.

You should also have a  /etc/ppp/options  file (empty), and  /etc/ppp/pap-secrets  with the following contents:

hostname    ispname         secret
Of course modify this for your situation. For  ispname  you could fill in an asterisk. Don't forget to change the secret :-)

Creating the files  /etc/ppp/ip-up  and  /etc/ppp/ip-down  with the following contents:

and "chmod +x /etc/ppp/ip-up /etc/ppp/ip-down" prevents ipppd from generating confusing error messages ("bad file descriptor").

If you have dynamic IP numbers, put this into the ip-down and ip-up scripts:


/sbin/route del default >/dev/null 2>&1
/sbin/route add default netmask 0 ippp0
This is necessary to keep the dial-on-demand working and to keep the routing correct after a connection is made (changing the interface's IP number removes all routes using that interface).

After the above script has been run, you can do

        isdnctrl dial ippp0
and 4 seconds later you should have a connection. This "dial" may also be skipped, and simply let dial-on-demand do its work. Just use netscape or whatever to generate IP traffic, which should cause the link to come up. After that do
        isdnctrl hangup ippp0
to forcibly throw out the connection (which will happen after 90s of no traffic). To make sure that no connection will be made when you don't want it, you can remove the phone number (without that info, the system can hardly bring up the link!). So:
        /sbin/isdnctrl delphone ippp0 out 0748800806
        /sbin/isdnctrl hangup ippp0
Of course, use the right phone number here... If you have configured more than one number, then you'll have to remove them all one by one.
Autodial can be re-enabled again by adding the number(s) again:
	/sbin/isdnctrl addphone ippp0 out 0748800806
Alternatively, with 2.0.36, you can manipulate the dialmode setting to control the dialling; this hangs up and prevents any new connection from being made:
        /sbin/isdnctrl dialmode ippp0 off
This re-enables dialling:
        /sbin/isdnctrl dialmode ippp0 auto

isdnctrl as non-root

You can make it so that a normal user can run the isdnctrl command; you then don't have to be root e.g. to change the dialmode! This is done by putting the devices in a special "group;", and also putting the user in that group.
This is done as follows: When you now login again (important!) then you will be in the dialout group, and you will be able to access the /dev/isdn* devices. You can check whether you're really in the group with the id command. E.g. I see:
uid=124(paul) gid=100(users) groups=100(users),20(dialout)


Where to start; there are so many things that can go wrong... However, if you follow the above instructions, it shouldn't be a problem to get things going.

If anything else goes wrong, let me know about it (including the solution, if known!), so that I can add it to this list. I'm also interested in special cases...



CVS is often referred to in relation to isdn4linux, as in "CVS version"; by this the developers' version is meant, where all the latest changes etc. are available as soon as the developers themselves "commit" those changes.

The term CVS comes from "Concurrent Versions System", and is the name of the software that manages access to a central repository of software. With this system a group of people can work at the same time on a collection of sources without worrying about hindering one another. Very useful for a group of programmers who live far apart (such as with isdn4linux where the developers are spread across Europe and at most see each other once or twice a year).

So, a "CVS snapshot" is a dump of such a repository made at a given time. As the development is an ongoing process, it's possible that such a snapshot won't work (a mistake was made, or perhaps a change hasn't been implemented completely yet). To work around such problems, there's also the concept of a "known-good" snapshot; such a snapshot has been tested to ensure it works.


ISDN4Linux homepage
E.g. links to the developers.
Linux and ISDN
A number of different configurations for different situations. Also a FAQ (currently outdated, see below) and HOWTOs can be found here. German and english.
Building a low cost ISDN Internet Gateway
Nice story about applying ISDN4Linux to the real world.
Linux and ISDN
more configuration examples from Germany.
updated! ISDN4Linux FAQ, alternative site
Linux 2.0 kernel sources
Linux 2.2 kernel sources
HiSax 3.1 (2.0 kernels)
new isdn4linux version for 2.0.x kernels. This is a "known-good" CVS snapshot, but not updated that frequently. Also not really necessary.
HiSax 3.1 (2.2 kernels)
(bzip2 version)
new isdn4linux for 2.2.x kernels, recommended!
isdn4linux of 1999/07/02
Experimental version of isdn4linux for 2.2.x with diva 2.01 PCI support and keypad protocol support via ttyI
3.0(beta) version of isdn4k-utils
(bzip2 version)
Official version of utilities needed for configuring and using ISDN4Linux.
isdn4k-utils, my version
My version of the utils, should also compile on Red Hat 6.0 and other glibc2.1 systems. This version is largely based on the 3.0beta2 version.
isdn4linux-utils RPM directory
ready-made package for Red Hat, on
The script that was missing from isdn4k-utils 2.1b1, needed for creating ISDN devices in /dev
ISDN en Red Hat (5.2 and 6.0)
Guide to getting ISDN working on Red Hat (5.2 and also 6.0), with links and an RPM of the utils
directory with mgetty sources
for logging in with X.75 (as far as ISDN is concerned; this can do many more things with regular modems. Worth looking at.)
isdn4linux for use in north America
This page from Traverse Technologies describes how to use isdn4linux with the NI-1 protocol in use in the USA and Canada.

back to my homepage

© 1996-1999,2002 Paul Slootman
May be used, copied and distributed freely, but my name, this copyright text, and the URL must be kept intact. See it as a sort of GPL. Exception: Teles may only use this after express written or PGP/GPG signed permission.
Please send any changes and/or additions to me directly so that I can integrate them into my original document (if they are worthy).