isdnctrl dialmodean important change to the configuration of a network interface.
isdnctrl dialmodeabout an important change.
For debian the isdnutils package is available, so no problems there. SuSE also supports ISDN completely out of the box.
For Red Hat an RPM is available at
(located in Germany).
Possibly you can find a better RPM
Red Hat 6.1 apparently has ISDN utilities included.
The differences in configuring these cards is minor. The
categories are plain ISA, PnP ISA, and PCI. I'm ignoring
PCMCIA for now until someone donates a laptop with a PCMCIA
ISDN card :-) (it's apparently also not very easy to do...).
The reason why I don't list Teles above is that Teles have not been helpful in the development of ISDN4Linux (putting it mildly), and still ignore any requests from the developers. Many other vendors do support Linux, happily, so support them! Anyway, I mention Teles 16.3 in the rest of this howto because that's what I had when I first wrote this.
The "pro" in the typename of the Elsa cards means that software is included. As usual, that software is MS-based, so if you're only interested in using it with Linux, having Elsa's software is of no added value.
Recent Fritz! cards are said to have problems with IRQs other than 5. I myself have one in my Alpha XLT on IRQ 10... YMMV. BTW, ISDN4Linux works fine since 2.0.36 on Alpha/Linux.
If you want audio support (e.g. for vbox, the
answering machine), then do not use the following
AFAIK the following cards are not yet supported:
You want to patch regardless? Well, then follow these steps :-)
cd /tmp tar xvzf isdn-2.1.tar.gz
cd /tmp/isdn-2.1 ./std2kern -k /usr/local/src/linuxIt may be that you need to supply a -d option; when in doubt, do both. Additionally you may leave out the -k /usr/... if your kernel sources are in /usr/src/linux (that happens to be the default).
<*> ISDN support [*] Support synchronous PPP <M> HiSax SiemensChipSet driver support [*] HiSax Support for EURO/DSS1Here 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 PCMCIAbut 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.
CONFIG_ISDN_PPP_VJ) seems to work nowadays, but it's not of much use (it's mainly designed for slow links).
Support audio via ISDN (CONFIG_ISDN_AUDIO) [N/y/?] y.
make configis not recommended! You may miss parts of the config with
modprobe hisax io=0x180 irq=10 type=3 protocol=2 id=line0
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.
To be able to use PnP cards under Linux, an
utility has been developed. You use this utility in two steps:
pnpdumpthe information of all PnP cards is dumped, usually into the file
/etc/isapnp.conf. This file is then modified to reflect the desired configuration.
isapnpthe configuration is applied. The first step only needs to be done once. The second step must always be done after booting the system, and before using the card(s).
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
pcpdumpstep, 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.confare passed to HiSax.
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 220.127.116.11 Jul 29 15:53:12 wurtel kernel: HiSax: Layer2 Revision 18.104.22.168 Jul 29 15:53:12 wurtel kernel: HiSax: TeiMgr Revision 22.214.171.124 Jul 29 15:53:12 wurtel kernel: HiSax: Layer3 Revision 126.96.36.199 Jul 29 15:53:12 wurtel kernel: HiSax: LinkLayer Revision 188.8.131.52 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. 184.108.40.206 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. 220.127.116.11 Jul 29 15:53:12 wurtel kernel: HiSax: 2 channels added Jul 29 15:53:12 wurtel kernel: HiSax: module installedIf 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).
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).
ncurses.h not found, make sure you have an
ncursespackage installed. Some distributions have separate runtime and development packages; you need both. Sometimes
ncurses.his not in
/usr/include. If not, use a symlink so that it can be found in
/usr/include. Possibly the Makefile may need to have
ndbm.h not foundimplies that you need to have the Gnu DBM package installed. If you're installing that from sources, in addition to the
make installstep you also have to run
make install-compatto get the
Don't forget to run the
script! This creates the device entries in
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/isdnctrlIsdnlog 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
dmesgcommand to check on kernel messages, which also contain number info.
minicomas a terminal emulation program here. Of course another program with similar functionality can be used, e.g. seyon or even cu.
minicom isdn0(nowadays you have to use
minicom -s isdn0), and at port settings (ctrl-A O) enter
/dev/ttyI0as the device. For modem init string enter
AT&E546851514^M~AT&B512^M(my number is 0546-851514, so leave out the leading zero and the dash; block size is set to 512). Set speed to 38400 or whatever; it doesn't really matter, as the speed will be 64kb/s anyway. Save these settings. Now choose
exit minicom). Minicom will now initialize the "modem", and then you're connected to the ISDN modem emulator (note: only the AT commands are emulated; you cannot connect to analogue modems!). Type
AT&V<enter>to convince yourself of this.
/dev/ttyI1a virtal ISDN tty can only be used once, of course. Preferably also use a different number (MSN). It'll work with the same number used twice, but debugging is a lot easier if you use different numbers. Again, save these settings and choose
ATD851514<enter>. The areacode isn't necessary (of course, use the number you defined in the first screen!). In the first screen you should now see
ATA<enter>you can accept the call; now, what you type in this screen should appear in the other, and vice versa.
RING, then maybe you have to enter the number with areacode. Check the system logging to see to which number the call is directed.
BUSYapppear, then a number of things may be wrong; unfortunately most failures are simply indicated with
BUSY(only when there is no physical connection working do you see a different message, namely
NO CARRIER). If
BUSYappears after 1-3 seconds, then the message may be right, and the remote number is in fact busy. However, if it takes longer, then probably something else is the cause of the problem. Look in the system log messages for hints.
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
|types of messages for -m and -l|
|bit||type of messages|
|0x0008||Log /dev/DEVICE (b.v. isdnctrl) messages to /tmp/DEVICE|
|0x0010||show phone numbers immediately|
|0x0020||charge info (subscription may be needed)|
|0x0100||cause when hangup|
|0x0400||throughput in bytes (each -wX seconds)|
|0x1000||service indicator (voice, data, ...) with notice msgs|
|0x2000||est. 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.
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 ttyI1and in /etc/mgetty/mgetty.config (amongst others):
port ttyI1 init-chat "" ATZ OK AT&Exxxxxxxxx OK AT&B512 OK data-only y speed 38400Put 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 qto get the new inittab read.
echo 1 > /proc/sys/net/ipv4/ip_dynaddrecho a 2 for 'verbose mode'.
The procedure for initializing an ISDN network interface is basically:
MYUSER=myname # my username at the ISP REMNAME=demon # name of ISP's system MYIP=18.104.22.168 # my fixed IP number (use 10.0.0.2 if no fixed) REMIP=22.214.171.124 # 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
and apply the
/proc/sys/net/ipv4/ip_dynaddr stuff as
You should also have a
/etc/ppp/pap-secrets with the following
hostname ispname secretOf course modify this for your situation. For
ispnameyou could fill in an asterisk. Don't forget to change the secret :-)
Creating the files
/etc/ppp/ip-down with the following contents:
#!/bin/shand "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:
#!/bin/sh /sbin/route del default >/dev/null 2>&1 /sbin/route add default netmask 0 ippp0This 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 ippp0and 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 ippp0to 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 ippp0Of 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.
/sbin/isdnctrl addphone ippp0 out 0748800806Alternatively, 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 offThis re-enables dialling:
/sbin/isdnctrl dialmode ippp0 auto
dialout:x:20:If it doesn't exist, or you want to use a different one, just add a line to the bottom.
chgrp dialout /dev/isdninfo /dev/isdnctrl*
chmod g=rw /dev/isdninfo /dev/isdnctrl*
ln -s /usr/sbin/isdnctrl /usr/local/binYour shell probably searches that directory per default.
uid=124(paul) gid=100(users) groups=100(users),20(dialout)
Teles: 16.3 Byte at d82 is 39then you have a Teles 16.3 revision 1.1 card. Solution: get 2.0.36.
Feb 5 11:30:27 wurtel kernel: ippp0: dialing 0 793600036...This seems like the right thing, however, the '0' has nothing to do with the phone number. It is in fact the retry count. A line as above is usually followed quickly by a line such as:
Feb 5 11:30:35 wurtel kernel: isdn_net: local hangup ippp0and isdnlog may say something about "unassigned number". So, don't forget to include '0' in "ISPMSN"!
debugto the list of options for ipppd the necessary messages will be generated by ipppd, which will be passed to syslog with facility set to daemon (or perhaps local2) and level debug (see manpage of syslogd and syslog.conf for more info).
Nov 4 18:11:30 wurtel kernel: HiSax, ch0 cause: E0010is not an error. It simply means that the local system caused the disconnection of the ISDN link. See the
isdn_causemanpage for more info. This is usually a result of an ipppd configuration error (see the previous item). If your password contains "strange" characters, then you need to enclose it with quotes . Starting your password with @ is generally a very bad idea...
Sep 27 21:19:21 wurtel kernel: HiSax, ch0 cause: E0322means the VPop network is overloaded. Keep on trying... See the
isdn_causemanpage for more info.
Solution: diable VJ-compression by adding this to the ipppd
"-vj -vjccomp". Or enable it in
the kernel after all...
See also the next item:
There are three possible dialmode settings:
isdnctrl dialare possible.
Also check out the
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.