<!doctype linuxdoc system>

<article>

<title>FAQ for isdn4linux
<author>Matthias Hessler (<tt><htmlurl url="mailto:hessler@isdn4linux.de" name="hessler@isdn4linux.de"></tt>)
<date>v2.0.103, 15 January 2006
<abstract>
If you are reading this FAQ online, you may consider downloading the whole
thing, and reading it offline (much cheaper). To download the latest
version of this FAQ in TXT/HTML/SGML format, go to the homepage of this FAQ:
<url url="http://www.mhessler.de/i4lfaq/">.

A German translation of the FAQ is available at:
<url url="http://www.wolf-b.de">.

This FAQ answers questions that were frequently asked in the newsgroup
de.alt.comm.isdn4linux. It contains questions any user should
know about ISDN under Linux using isdn4linux, as well as hints on how
to best make use of all the features isdn4linux provides.

Version 2 of the FAQ is derived from an earlier version which had become
outdated at the time of this writing. To obtain information on old versions
of isdn4linux (1997 and earlier) please have a look at the FAQ version 1.3.4.

About the format of this FAQ:
The main basis of this FAQ is the i4l mailing list (see question
<ref id="docu_mailinglist" name="docu_mailinglist">). I've treated the
knowledge gained from reading as public domain, without quoting the author of
the original mail. The FAQ is now written in SGML, as this format is flexible
to convert into any other form of documentation (though some restrictions
apply). The FAQ is now maintained in English since German-speaking people can
easily follow the mailing list/newsgroup (or search in the archives). Whoever
wants to translate back to German is welcome to do so!

The countless links in this documents are not always complete and I'm sure many
are no longer correct. I do not have the time to check them all. If you
discover a bad link, please let me know (I'll try to install some automatic
checking when I have the time).

Additions, improvements and other suggestions are always welcome (also
correction of typographical errors!), preferably send "diffs" from the SGML
version. Thank you very much in advance!

Send feedback about this FAQ to:
<tt><htmlurl url="mailto:i4lfaq@isdn4linux.de"
	     name="i4lfaq@isdn4linux.de"></tt>
or:
<tt><htmlurl url="mailto:hessler@isdn4linux.de"
	     name="hessler@isdn4linux.de"></tt>.

The newest version of this FAQ can be found at:
<tt><url url="http://www.mhessler.de/i4lfaq/"></tt>
or:
<tt><url url="http://www.isdn4linux.de/faq/"></tt>.

This FAQ is protected by the GNU General Public License (GPL) Version 2;
(C) 1999-2002 Matthias Hessler (for version 2.0)
Distribution under the terms of the GPL is welcome. However,
we offer NO GUARANTEES for the information herein. Please read the GNU
General Public License for further details. A printed version is available
from Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
An electronic version is available from the author.
</abstract>

<!-- Table of Content
-->

<toc>


<!-- General Section: About isdn4linux, features
-->

<sect> general: General information about isdn4linux  
<label id="general">

<sect1> general_i4l: What is isdn4linux?  
<label id="general_i4l">
<p>
isdn4linux is a set of kernel modules which are part of the Linux
kernel. It consists of the main module <tt/isdn/ and the
actual hardware driver that control some specific card.
In addition, the package <tt/isdn4k-utils/ contains utilities to
make use of ISDN specific features.
Please note that since kernel 2.6.0 isdn4linux is considered legacy.
It has been superseded by the new mISDN drivers (see question
<ref id="general_misdn" name="general_misdn">.

<sect1> general_misdn: What is mISDN?  
<label id="general_misdn">
<p>
mISDN is the successor of isdn4linux, and also consists of kernel modules
that are part of the Linux kernel. The mISDN modules have been rewritten
from scratch since the old isdn4linux modules were difficult to maintain.

The new mISDN modules are based on the CAPI interface (see question
<ref id="feature_capi" name="feature_capi"> for more details on the CAPI
interface). Not all ISDN cards supported by isdn4linux have been/will be
ported to mISDN. However, it is planned to create a compatibility layer to
allow migration of the existing isdn4linux drivers. Also, ipppd would be
replaced by the standard pppd once pppd works as well as ipppd currently does.
For the moment, isdn4linux can still be used in parallel with mISDN, but this
may change in the future.

For more technical and configuration information about the mISDN driver
see question <ref id="config_misdn" name="config_misdn">.

<sect1> general_hardware: What hardware is supported by isdn4linux?  
<label id="general_hardware">
<p>
Generally, isdn4linux can control ISDN cards that are connected to the PC's
ISA or PCI bus. Also a few PCMCIA cards are supported. However, isdn4linux can
<bf/not/ make use of any devices connected via a serial or parallel
interface (which are called 'terminal adaptors'), with only a few exceptions:
the Creatix/Teles S0 box for the parallel port, and the Gazel 128 USB.
For more details on which cards are supported see section
<ref id="hardware" name="hardware">.

<sect1> general_features: What features are supported by isdn4linux?  
<label id="general_features">
<p>
Basically, isdn4linux can receive and transmit data via ISDN in several ways
(X.75, HDLC, raw ip, synchronous ppp, asynchronous ppp, V.110). Some of its
utilities offer additional features. Two examples are <tt/isdnlog/, which
allows logging of and reaction to ISDN events (including calculating any charges);
and <tt/vbox/, which provides voice answering machine capabilities. For more
details see the section <ref id="feature" name="feature">.

<sect1> general_countries: Which countries are supported by isdn4linux?  
<label id="general_countries">
<p>
At least all countries which use Euro-ISDN are supported, however some
pecularities apply. To find more about your country, check the section
<ref id="countries" name="countries">.

<sect1> general_docu: Where do I find more documentation, how-to's, helpful tips  
&amp; tricks?  
<label id="general_docu">
<p>
Besides this FAQ, take a look at the various man pages and Readme's that come
with the isdn4linux package. Then there is the isdn4linux website:
<url url="http://www.isdn4linux.de">. There is also a mailing list on
isdn4linux which will give you the most up to date information. To find out
more about these great information sources, see section <ref id="docu"
name="docu">.
And: check out all the great links listed in question
<ref id="config_links" name="config_links">!
You may find information in your language, or information specific to your
linux distribution.

<sect1> general_getlatest: Where do I get the latest version of isdn4linux?  
<label id="general_getlatest">
<p>
The latest version of the kernel drivers should be found in the Linux
kernel. However, sometimes the Linux kernel does not have the latest version or
does not yet support your ISDN card. Additionally, you may need to use the
isdn4k-util package. In those cases you could try to get the very latest
version that is currently in development. See the section
<ref id="distrib" name="distrib">.

<sect1> general_contacts: How can I get in contact with the developers?  
<label id="general_contacts">
<p>
You can contact the isdn4linux developers through the www.isdn4linux.de
website. Have a look at <url url="http://www.isdn4linux.de/contacts.shtml">.


<!-- Development & Distribution -->

<sect> distrib: Distribution  
<label id="distrib">

<!-- Who are the developers? -->  

<sect1> distrib_getlatest: How can I get the latest isdn4linux?  
<label id="distrib_getlatest">
<p>
There are different ways, depending on your kernel. Unless you are an
experienced user of Linux, you should use a recent kernel (=first option).
<itemize>
<item>You have a recent kernel (at least 2.0.36/2.2.11/2.3.14):
Great choice, you have already the current kernel ISDN stuff.
Additionally, you just need to get the current isdn4k-utils package from
<url url="ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/"> - unless it's already
included in your distribution.

<item>You have an older kernel (before 2.0.36/2.2.11/2.3.14):
An upgrade to a recent kernel is HIGHLY recommended. And it is MUCH easier
to do a kernel upgrade than to get ISDN to work with your older kernel.
Ok, now if you still want to keep your old kernel, here is how to do it:
First you have to identify the correct CVS extract for your kernel version
(CVS is the version control system the ISDN developers use to develop
ISDN4LINUX). Take a CVS snapshot that is dated with about the date when your
kernel came out. You find the kernel patches and the old isdn4k-utils packages
on <url url="ftp://ftp.isdn4linux.de/pub/isdn4linux/">
or on one of its mirrors
(see <url url="http://www.isdn4linux.de/download.shtml"> on how to find
mirrors).

<item>As a developer:
If you want to participate in the development of i4l, you can get the very
latest stuff via CVS. For this, see the question about access to CVS:
<ref id="distrib_cvs" name="distrib_cvs">.
</itemize>

<sect1> distrib_cvs: How can I access the source from the current  
development/what is the CVS tree all about?  
<label id="distrib_cvs">
<p>
CVS - Concurrent Version System:

This is a multiuser/server extension to RCS (Revision Control System).
The I4L drivers are developed under CVS, and there is a server
(cvs.isdn4linux.de) with a CVS tree to which all developers have
access.  In addition, Fritz has configured anonymous read-only access
to the CVS tree . If you must have the very latest versions, you can
get them there, however they may contain more bugs than the released
versions!!!

Here is how to get the latest version:
<enum>
<item>Create and go to the directory where you want to store i4l
<code>mkdir ~/cvs; cd ~/cvs
cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev login</code>
<item>Log in (asks for a password, enter <em>readonly</em>)
<item>Get the isdn kernel driver stuff (same hierarchy as in the linux source)
<code>cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev checkout isdn</code>
<item>Get the utility package into the current directory
<code>cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev checkout isdn4k-utils</code>
If you want to get the latest version for kernel 2.0.x rather than for the
latest kernel, then you have to give the additional option `-r':
<code>cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev checkout -r isdn4kernel_2_0 isdn</code>
<item>After having checked out, further updates can be done by first
changing into <tt>isdn</tt> or <tt>isdn4k-utils</tt> subdirectory and
running
<code>cvs update -P -d</code>
Tip: since cvs stores the password on your first login, you don't need to login
again when updating.
</enum>

WARNING!! THE NEWEST STUFF SOMETIMES IS VERY INSTABLE OR MAY NOT EVEN
COMPILE WITHOUT PROGRAMMING KNOWLEDGE -
No newbie questions on this PLEASE! Use the source, Luke!

People who want to <em>continuously</em> help develop isdn4linux by writing
new drivers etc. can get a real account for full access. In this case write
an email to Fritz Elfert <tt><htmlurl url="mailto:fritz@isdn4linux.de"
name="fritz@isdn4linux.de"></tt>


<!-- Features
-->

<sect> Features
<label id="feature">

<sect1> feature_not: Which ISDN features cannot be offered by isdn4linux?  
<label id="feature_not">
<p>
Some ISDN features are device-specific and cannot be activated by
isdn4linux for other devices, unless isdn4linux were to falsify
the TEI (which would probably confuse the other device).
Such device-specific ISDN features are, among others: rejection of a
waiting call, caller id on/off, hold, conference calls, differing COLP/CLRP.

<sect1> feature_data: Which ISDN data transmission modes are supported?  
<label id="feature_data">
<p>
These low-level formats are possible:
<itemize>
<item> 56k asynchronous : no
<item> 64k synchronous  : yes
<item>128k synchronous  : yes (channel bundling - see the question
<ref id="feature_2channel" name="feature_2channel">)
</itemize>
These level2 formats are possible:
<itemize>
<item>HDLC
<item>X.75
<item>transparent
<item>V.110
</itemize>
These encapsulations are possible:
<itemize>
<item>rawip
<item>ethernet
<item>Sync PPP
<item>X.25 (requires 2.1 or newer)
<item>cisco and cisco-h
<item>cisco-hk (=cisco with keepalive; requires 2.1 or newer)
<item>plus a few specialities: have a look at the man pages.
</itemize>

Please note that X.31a is supported as X.25 on top of ISDN, while X.31b
is not supported (neither in the B channel, nor in the D channel variation).

<sect1> feature_voice: Has isdn4linux voice support (e.g. answering  
machine, voice-over-ip gateway for H.323 clients)?  
<label id="feature_voice">
<p>
Yes, voice support is included in the current version of isdn4linux.
For an answering machine you can either use &dquot;vgetty&dquot; from Gert
Doerings &dquot;mgetty+sendfax&dquot;, or &dquot;vboxgetty&dquot; from
Michael Herold, which is made especially for isdn4linux.
The latter is part of the isdn4k-utils package, which can be found on:
<tt><url url="ftp://ftp.isdn4linux.de/pub/"></tt>

Also, you can use isdn4linux as a voice-over-ip gateway to let
H.323 clients (like Voxilla, Netmeeting) call normal telephones, and/or
the other way around. For configuration see question
<ref id="config_h323" name="config_h323">.

<sect1> feature_fax: Can I fax with isdn4linux?  
<label id="feature_fax">
<p>
<itemize>
<item><bf>For passive cards: Yes</bf>. Since 2005 the GPL software ivcall
is able to send and receive voice calls and faxes even via passive cards.
It makes use of the spandsp library which is part of the Asterisk project.
You can find it on:
<tt><url url="http://0pointer.de/lennart/projects/ivcall/"></tt>
An alternative project working on this problem existed (i4lfax) but has not
made any progress since 1999. For more info on its status have a look at:
<tt><url url="http://user.cs.tu-berlin.de/~ulfi/osvisions/i4lsoftfax/i4lfax/"></tt>
Also, an idea exists to extend the new modular mISDN with layer 2 and layer 3
protocols for fax. Once this works (e.g. with the Sedlbauer Speedfax card)
then the layer 1 protocol (modulation/demodulation) could be also be
implemented via the spandsp library.
<item><bf>For passive cards from AVM: Yes</bf>. AVM recently released a
binary CAPI 2.0 driver which supports faxing. However, the setup is rather
complicated. Get a start on:
<url url="http://www.avm.de/ftp/cardware/fritzcrd/linux/index.htm">.
Here is a German website which has some nice installation instructions:
<tt><url url="http://ixi.thepenguin.de"></tt> or
<tt><url url="http://capi4linux.thepenguin.de"></tt> or
<tt><url url="http://www.thepenguin.de"></tt>
Please also have a look on the mailing list for tips how to do it,
and what the consequences/disadvantages are.
<item><bf>For the active card AVM B1: Yes</bf> (its firmware has implemented
fax as one of its features). Get the newest stuff from:
<tt><url url="ftp://ftp.aeccom.com/pub/fax4i4l/howto/current/"></tt>
However, it has been reported that setting it up properly is very tricky.
Another site which could be helpful is:
<tt><url url="http://www.topf-sicret.de/help/capi20.html"></tt>
<item><bf>For the active Hypercope PCI cards HYSDN Ergo2 and
HYSDN Metro4: Yes, after upgrade with a special fax card</bf>.
The setup is similar to that of an AVM B1, but may require extra patches.
<item><bf>For the active Eicon Diva Server cards (except Diva 2.0Pro):
Yes</bf>. Have a look at README.fax and README.eicon in the
<tt>isdn/Documentation/isdn</tt> directory, as well as:
<tt><url url="http://www.melware.de/"></tt>. The Eicon Diva Server cards
allow faxing with class 2 commands.
<item><bf>For semiactive cards Sedlbauer Speedfax+ and Siemens I-SURF 1.0: Yes</bf>
But currently this requires some manual work. Check the mailing list on how
to do it (special patch needed). Only class 1 fax commands are supported.
You can obtain the patch from:
<tt><url url="//ftp.isdn4linux.de/pub/isdn4linux/kernel/v2.2/testing/i4l_isar_fclass1.tar.gz"></tt>
The patch is not needed if your kernel is 2.2.15 or later.
You have to enable the kernel option for FCLASS2 (CONFIG_ISDN_TTY_FAX=Y).
Also, you need to load the firmware of the card (part of the isdn4k-utils) with
<code>
hisaxctrl &lt;driver_id&gt; 9 ISAR.BIN
</code>
Then initialize the ttyI* interface with:
<code>
ATZ&amp;E&lt;your_msn&gt;S0=1S13=1+FCLASS=1
</code>
and use a normal Hylafax class 1 config file, where you've replaced
non-supported commands (flow control,...) by dummies.
For the I-Surf 1.0 also check question <ref id="hardware_isurf" name="hardware_isurf">.
</itemize>

If you do want to fax now, your best choice is to install an analog fax modem
along with your ISDN card. For companies who want to set up a fax server
servicing multiple connections you could also have a look at the active
ISDN cards.

More information for setting up a fax server with hylafax can be found on:
on the web site for Hylafax: <url url="http://www.hylafax.org"> or on
<url url="http://www.mnd.fh-wiesbaden.de/~dreymann/linux">.

<sect1> feature_modem: Can isdn4linux connect to/be called by an analog  
modem?  
<label id="feature_modem">
<p>
Generally: <bf>NO</bf>. It may only work for cards with which you can fax: see
question <ref id="feature_fax" name="feature_fax">.
For the Sedlbauer card, you can give the following command on the ttyI*:
<code>
AT&amp;FS14=10S15=0S18=1&amp;E&lt;your_msn&gt;
</code>

<sect1> feature_divert: Is it possible to initiate call forwarding with i4l?  
<label id="feature_divert">
<p>
Call diversion features have been implemented recently. Use the new
program <tt>divertctrl</tt> in conjunction with the HiSax driver.

If you make use of capi4linux, then you find a similar program named
<tt>capidivert</tt> at:
<url url="http://www.tp1.ruhr-uni-bochum.de/&tilde;kai/i4l/">.
For now this is something only for the more experienced user, as so far there
is no howto and only little documentation, and it is not automatically included
in most distributions. However, it can be used with active ISDN cards.

In the Netherlands, the keypad protocol can be used as an alternative. To use
it you just dial with the usual dial command from an ttyI device:
<code>
atd*123*0123456789#
</code>

<sect1> feature_ipx: Can I route ipx/spx over ISDN with Linux?  
<label id="feature_ipx">
<p>
Yes, set up an ISDN interface with encapsulation <tt/ethernet/, and use
IPX framing ETHERNET_II. <em/mars_nwe/ can do the rest (e.g. routing).
Also, you can route ipx with ipppd, see question
<ref id="syncppp_ipx" name="syncppp_ipx">.
To use pppd for ipx, you have to give it the compile option IPX_CHANGE.
However, be careful when using dial out on demand (dod), since frequent ipx
broadcasts may cause a dod disaster (see question
<ref id="dod_disaster" name="dod_disaster">).

<sect1> feature_2channel: Does isdn4linux support channel bundling?  
<label id="feature_2channel">
<p>
The current version of isdn4linux support 2 methods of channel
bundling:
<itemize>
<item><bf>MPPP</bf> (based on sync PPP)
<item><bf>Raw bundling</bf> (configured by so-called slave channels)
</itemize>
Both variants have their own advantages and disadvantages.
See section <ref id="2channel" name="2channel">.
Bonding (16bit channel) is not supported,
since it can not work reliably when the dialup connections have deviating
latency.
Warning: Channel bundling saves time, but not telephone charges.
It is useful only if you really need the extra bandwidth.

<sect1> feature_diald: Can I combine isdn4linux with diald?  
<label id="feature_diald">
<p>
Yes, you can. You have to configure it to use the ttyI* devices to dial
out. E.g. like this:
<code>
/usr/sbin/diald /dev/ttyI4 -m ppp [...]
</code>
where [...] stands for further dialout parameters.
The recent diald releases contain configuration files for ISDN. See
<url url="http://diald.sourceforge.net"> for details.

<sect1> feature_dod: Does the driver support &dquot;dial on demand&dquot;?  
<label id="feature_dod">
<p>
Yes. If a network interface (e.g. &dquot;isdn0&dquot;) is set up, the driver
will dial the number. If in addition a hangup timeout (Idle Timeout) has been
given (like: <tt>isdnctrl huptime &lt;interface&gt; &lt;time&gt;</tt>), then
the driver will automatically hang up when no data was been transferred over
the interface for &gt;time&lt; seconds. However, with syncPPP there are
problems (see the syncPPP section).
Also look at the dialmode description (see question
<ref id="dialout_dialmode" name="dialout_dialmode">).
You should definitely be very interested in the large section of this FAQ that
talks about the dangers of unwanted dialouts: (<ref id="dod" name="dod">).

<sect1> feature_sms: Can I send SMS (short messages) to my mobile phone  
via ISDN?  
<label id="feature_sms">
<p>
Yes, you can use the program <tt>yaps</tt> to do this. However, due to some
pecularities in the SMS-callcenter's ISDN connection, you have to compile the
kernel with the options <tt>Disable send complete</tt> and
<tt>Disable sending llc</tt>. For the new CAPI 2.0 interface a patched
version of yaps, <tt>capi4yaps</tt>, is available on
<url url="http://sourceforge.net/projects/capi4yaps/">.

Please note that mainly German providers support sending SMS via ISDN
connection, in other countries this might not work. Dutch as well as UK
SMS callcenters seem to not support this feature. Please let me know if
you have additional information on this.
A useful sample config for yaps you might find on:
<url url="http://www.tnt-computer.de/linux/yaps-suite1-1.tgz">

Another program to send SMS is <tt>asterisk</tt>. Have a look at:
<url url="http://www.asterisk.org"> and
<url url="http://www.voip-info.org/wiki-Asterisk+cmd+Sms">.
One advantage over yaps is that it can also receive SMS, for Germany
(you have to register for this first by sending a specific SMS -
otherwise the SMS will be communicated to you by an automated voice
call).

Yet another program to send SMS is <tt>smsclient</tt>. You can find it on:
<url url="http://www.smsclient.org">.

<sect1> feature_btx: Is the German videotex/Btx/Datex-J possible with  
isdn4linux?  
<label id="feature_btx">
<p>
Yes, it works with the modem emulation with the ttyI* devices. There is
a special register to set for videotex (ATSx=y -  see the Readme's)
Warning! XCept (formerly Xbtx) has an ISDN configuration option. This
should NOT be used. XCept should be configured as if a normal modem
were being used.

<sect1> feature_clock: Can I set the clock of my computer with ISDN?  
<label id="feature_clock">
<p>
Yes. Isdnlog offers this feature with option &dquot;-t&dquot;. Unfortunately,
the seconds are not transmitted via ISDN, and the transmitted time is
not very accurate - depending on the ISDN equipment of your
telephone company there may be a deviation of several minutes (!).
It's better to get a PC clock that is set by radio signals and
check it with, for example, xntp. You can also use a time server in
the Internet with &dquot;netdate&dquot; or &dquot;rdate&dquot;.
Check out the following urls on information about using time servers:
<itemize>
<item> <url url="http://www.eecis.udel.edu/~mills/ntp/servers.html">
<item> In German: <url url="http://www.ptb.de/deutsch/org/4/43/433/verb.htm">
<item> In German: <url url="http://www.ptb.de/deutsch/aktuell/pi/pi00/pi0100.htm">
</itemize>

<sect1> feature_dosemu: Can I use isdn4linux under dosemu?  
<label id="feature_dosemu">
<p>
Yes, you can! Steffan Henke
<tt><htmlurl url="mailto:henker@informatik.uni-bremen.de"
	     name="henker@informatik.uni-bremen.de"></tt> wrote on 25 Oct 96:
<quote>
In dosemu.conf it is enough to enter a virtual com port,
(for example com2) that can be used with e.g. Telix or
Terminate: serial { com 2 device /dev/ttyI3 }
Access with Fossil is possible if fossil.com (included with
dosemu) is started.  Tested with the following configurations:
- Kernel 2.0.21, Teles driver incl. Karsten's patches
- Kernel 2.0.21, HiSax
</quote>

<sect1> feature_capi: Is there a CAPI interface available?  
<label id="feature_capi">
<p>
Currently, these cards support the CAPI 2.0 interface:
<itemize>
<item> the active card AVM B1.
<item> the active DIVA Server cards from Eicon.
<item> the active cards from Hypercope (HYSDN Champ2, HYSDN Ergo2,
HYSDN Metro4)
<item> the passive Fritz card from AVM. However, please note that you
have to download and manually install the binary drivers for this from
AVMs ftp server. See the following web site for a nice howto:
<url url="http://www.topf-sicret.de/help/capi20.html">. There was also
lots of stuff written in the mailing list on this.
Here is a German website which has some nice installation instructions:
<tt><url url="http://ixi.thepenguin.de"></tt> or
<tt><url url="http://capi4linux.thepenguin.de"></tt> or
<tt><url url="http://www.thepenguin.de"></tt>
Please note that due to its binary nature, this driver will not work
if your distribution is incompatible with it (e.g. based on 64 bit).
</itemize>

This interface follows the official CAPI 2.0 standard that was established
recently for Linux by the CAPI Association (see
<url url="http://www.capi.org">).
Since kernel 2.6.0 the CAPI interface has been used as the general
interface, also for other cards. For passive cards, the new driver
mISDN will replace the old hisax driver once it is fully functional.

There are no plans to implement a CAPI 1.1 interface.

<sect1> feature_uus: Is UUS (user to user signaling) supported?  
<label id="feature_uus">
<p>
Yes, isdn4linux could support both sending and receiving, but the
implementation is currently rather incomplete due to the unclear legal
situation for using this facility. Receiving UUS is only possible through
the debug interfaces. Sending is supported in connection with the diversion
services (when rejecting a call or announcing a busy condition), but not
on an ordinary call. It is recommended to use subaddressing (see question
<ref id="feature_subaddressing" name="feature_subaddressing">) instead.
Please note that sending UUS it is not a free service (receiving is free),
at least with some German phone providers you have to pay extra for it
(also have a close look on the usage conditions). Additionally, please note
that if you are connected through a PBX, it may filter out all the UUS
stuff.

<sect1> feature_subaddressing: Is subaddressing supported?  
<label id="feature_subaddressing">
<p>
Yes, isdn4linux does support subaddressing (available in France).
To configure it, give HiSax the number in this format:
<tt>&lt;number&gt;.&lt;subaddress&gt;</tt>. However, you may have to order
it seperately and pay extra for receiving it (sending is free), depeding
on your ISDN provider.
Additionally, please note that if you are connected through a PBX, it will
most likely filter out all the subaddressing stuff.

<sect1> feature_gsmv110: Can I connect from my PDA via GMS cellular phone  
to isdn4linux?  
<label id="feature_gsmv110">
<p>
Yes, if the provider of the cellular phone has a GSM to ISDN/V.110 gateway.
This has been reported to work from a PalmPilot to isdn4linux with V.110.
See question <ref id="config_gsmv110" name="config_gsmv110"> for details on how to configure it.

<sect1> feature_reversedcard: Can isdn4linux log ALL actions happening on the  
ISDN bus (dual mode/reversed card/COLP/...)?  
<label id="feature_reversedcard">
<p>
Yes, isdn4linux offers several possibilities to do this. Have a look at
question <ref id="isdnlog_reversedcard" name="isdnlog_reversedcard">.

Please note that you may also use the software ISDN Sniffer for this,
see the German web site
<url url="http://krypt.cs.uni-sb.de/projects/isdnsniffer/">.

<sect1> feature_chargeint: Can isdn4linux hang up just before the ISDN  
provider would charge me for another unit?  
<label id="feature_chargeint">
<p>
Yes, isdn4linux can do this. Check out section <ref id="chargeint" name="chargeint">.

<sect1> feature_eurofile: Can isdn4linux download or offer files via EFT  
(Eurofile transfer)?  
<label id="feature_eurofile">
<p>
Yes, isdn4linux offers special tools for this which are part of the
isdn4k-utils.

<sect1> feature_leased: Can isdn4linux handle leased lines (e.g. D64S)?  
<label id="feature_leased">
<p>
Yes, isdn4linux can handle leased lines (explained in the glossary:
<ref id="glossary_leased" name="glossary_leased">). Have a look at section
<ref id="leased" name="leased">.

<sect1> feature_pointtopoint: Can isdn4linux work in point-to-point  
mode as well as in multi-device mode?  
<label id="feature_pointtopoint">
<p>
Yes, isdn4linux supports both. Check the glossary to understand the
difference: <ref id="glossary_pointtopointmode" name="glossary_pointtopointmode"> and
<ref id="glossary_multidevicemode" name="glossary_multidevicemode">.

<sect1> feature_ntmode: Does isdn4linux support running a card in NT mode?  
<label id="feature_ntmode">
<p>
Yes, isdn4linux does support it, but only for a few special cards.
See question <ref id="feature_crossedcable" name="feature_crossedcable">
for details. In the glossary there is more information on what the NT mode is:
<ref id="glossary_ntmode" name="glossary_ntmode">.

<sect1> feature_crossedcable: Can isdn4linux directly connect two  
ISDN user devices (two ISDN cards) via a crossed cable?  
<label id="feature_crossedcable">
<p>
Yes, isdn4linux can do this. However, this requires that the ISDN card
can run in NT mode (for details on this mode see the glossary:
<ref id="glossary_ntmode" name="glossary_ntmode">).
Only very few cards (e.g. HFC chipset) are cable of doing this.
Use the following command to start the ISDN card in NT mode:
<code>
hisaxctrl &lt;id&gt; 98 1
</code>
Make sure that the crossed cable is terminated even if it is very short!
Nothing will work without termination, not even a 1m cable. Some HFC card
already have jumpers for termination. Since TX as well as RX circuits must
be terminated with its own resistor, two jumpers should be present, like this:
<verb>
> 3 RX+ 2a --[100 Ohm]----+     ---------- /      ----------
> 4 TX+ 1a --[100 Ohm]--+ |    | 87654321 |      | 12345678 |
> 5 TX- 1b ---oJ1o------+ |    |__      __|/     |/_      /_|
> 6 RX- 2b ---oJ2o--------+       |____|            |/___|
</verb>

It has been reported that for proper functioning even on a short cable a
termination is required at/near both ends (at the ISDN card as well as at
the connecting ISDN device).

However, this will only give you the physical connection. Up to now
isdn4linux does not (yet?) implement the higher level ISDN protocol DSS1
(this means that isdn4linux can not pretend to an ISDN device that it is
an ISDN exchange, and give it the proper ISDN commands). As a result, you can
simulate a leased line, but not pretend to be the PBX with isdn4linux.

With the newer mISDN modules the situation is better. A special user space
module is available for the emulation of a PBX. Development of a kernel module
is in progress. In any case the chipset has to support the NT mode.


<sect1> feature_lcr: Can isdn4linux do least cost routing (LCR)?  
<label id="feature_lcr">
<p>
Yes, this feature is now being supported by isdnlog. What it does is that
it allows isdnlog to choose your telephone provider when placing a call
through your ISDN card, depending on the time of day and the current rate
information. Since isdnlog 4.16 an external script is called (if configured)
to change various ISP settings (e.g. DNS lookup, proxy setup,...).

Note: the ABC-extensions (s. <ref id="docu_abc" name="docu_abc">) must be
installed. Also, isdnlog should always be running (otherwise your dialout
will be delayed by 3 seconds). If the ABC-extensions are not installed,
isdnlog prints hints to the log file, which provider would have been chosen.

<sect1> feature_internetdialin: Can isdn4linux be setup such that it  
dials into the Internet, whenever I call it via telephone?  
<label id="feature_internetdialin">
<p>
Yes, this is possible with isdnlog. You have to configure isdnlog such that
it can execute a script whenever someone dials in. In the script you can
check for the correct telephone number, then trigger the dialin.
To access your computer then over the internet, you can then access it via
its ip address. In case of dynamic ip address assignment, you probably want
to store the new ip somehow. Storage in a html page or via dynamic DNS
may be good possibilities.

If you understand German, there was an article about exactly this setup in
ct 18/2002, page 204 (Bei Anruf Internet - Handy-Anruf l&ouml;st
Internet-Einwahl aus). Also, the following German web site explains
how to set up such a configuration:
<tt><url url="http://www.staschke.de/linux/anwahl.html"></tt>



<sect1> feature_future: Which features are planned for the future?  
<label id="feature_future">
<p>
Actually, most features have been implemented and are now being improved.
But, who knows what other interesting stuff the developers may come up.
We'll see...


<!-- Helpful docu, links, mailing list, config examples, howto's -->

<sect> docu: Documentation, Howto's, Tips &amp; Tricks, Mailing List/Newsgroup  
<label id="docu">

<sect1> docu_first: What documents should I read first?  
<label id="docu_first">
<p>
<itemize>
<item>ISDN kernel subsystem:
/usr/src/linux/Documentation/isdn/README
<item>ISDN cards:
/usr/src/linux/Documentation/isdn/README.card
E.g.: /usr/src/linux/Documentation/isdn/README.HiSax
<item>Synchronous PPP:
/usr/src/linux/Documentation/isdn/README.syncppp
/usr/src/linux/Documentation/isdn/README.syncPPP.FAQ
<item>Voice capability:
/usr/src/linux/Documentation/isdn/README.audio
<item>ISDN Utilities:
/usr/src/isdn4k-utils-version/README(.*)
</itemize>
Many of the utilities also have man pages!

To get a good technical overview over isdn4linux have a look at the
great whitepaper 'ISDN4Linux, CAPI4Linux, CPI4Hisax and other cute acronyms:
The ISDN subsystem in the Linux kernel', which can be found at:
<tt><url url="http://www.linux-kongress.org/2002/papers/lk2002-germaschewski.pdf"></tt>

For a Suse distribution the following information might be helpful:
<itemize>
<item><tt>/usr/doc/packages/i4l*</tt> (for i4l in general)
<item><tt>/usr/doc/faq/faq/PPP-FAQ</tt> (for synchronous PPP)
<item><tt>/usr/doc/howto/mini/Mail-Queue.gz</tt> (for email configuration)
</itemize>
Also, read the excellent manual!

For a Debian distribution the following information might be helpful:
<tt>/usr/share/doc/isdnutils/HOWTO.gz</tt>

If you are reader of the German computer magazine <tt/ct/, they had very
helpful articles at least on these issues:
<itemize>
<item>ct 5/1998, page 224: <tt>Der erste Kontakt/Linux: Mit PPP ans Internet</tt>
<item>ct 21/1998, page 288: <tt>Reiseleiter/Internet-Anbindung f&uuml;r das LAN</tt>
<item>ct 25/1998, page 218: <tt>Bei Anruf Netz/Linux: Dial-In Server</tt>
<item>ct 7/2001, page 228: <tt>Des Surfers Bastelstunde: Mobilfunktechnik
HSCSD aussch&ouml;pfen</tt>
(also contains information on dial-in configuration without HSCSD).
<item>ct 15/2002, page 204: <tt>Bei Anruf Internet: Handy-Anruf l&ouml;st
Internet-Einwahl aus</tt>
<item>ct 3/2004, page 182: <tt>Heimserver im Eigenbau - Teil 4: ISDN-Grundlagen
f&uuml;r Linux</tt> (also contains information about the new mISDN driver).
An online version is available on:
<tt><url url="http://www.heise.de/ct/04/03/182/"></tt>
<item>ct 9/2004, page 100: <tt>Tux vermittelt - Linux als Telefonanlage mit
VoIP</tt> (refers to software PBX4Linux)
<item>ct 12/2005, page 116: <tt>Guter Stern vom Amt - Asterisk: Linux als
professionelle Telefonanlage</tt> (refers to PBX software asterisk)
<item>ct 13/2005, page 216: <tt>Ein Pinguin als Sparfuchs - Linux-PC senkt
Handy-Geb&uuml;hren</tt> (refers to PBX software asterisk)
</itemize>

Also have a look at question <ref id="config_links" name="config_links"> for
helpful links on how to configure i4l (e.g. special help for SuSE, Red
Hat, or Mandrake users).

<sect1> docu_website: Where is the official website for isdn4linux?  
<label id="docu_website">
<p>
The offical website can be found at:
<url url="http://www.isdn4linux.de">.

<sect1> docu_abc: Where do I find documentation on the abc extensions?  
<label id="docu_abc">
<p>
You can find it on:
<url url="http://i4l.mediatronix.de/">

<sect1> docu_newsgroup: Where is the newsgroup for isdn4linux?  
<label id="docu_newsgroup">
<p>
The newsgroup was <tt>de.alt.comm.isdn4linux</tt>, however had been
closed down some time ago due to spam issues. To get in contact with
the developers your best choice is to use the mailing list
<ref id="docu_mailinglist" name="docu_mailinglist">. Alternatively, you find some interesting
stuff in <tt>de.comp.os.unix.linux.isdn</tt>.

<sect1> docu_mailinglist: Where is the mailing list for isdn4linux?  
<label id="docu_mailinglist">
<p>
The address of the mailing list is
<tt>isdn4linux@listserv.isdn4linux.de</tt>. Before posting a message
there please make sure it is not answered in this FAQ, and that the
question has not been answered numerous times in the past (search
<url url="http://www.deja.com/"> with keywords like ISDN, Linux, i4l,
isdn4linux,...). People on the mailing list get really annoyed when
the question "can I fax with my card xxx" is asked yet another time
(see question <ref id="feature_fax" name="feature_fax"> for the answer).
To reduce spam, as of 25. Aug. 2003 the mailing list has been changed
to permit posts from subscribed members only. To write, you must be
subscribed first.

When writing on the mailing list, please always provide:
<itemize>
<item> Your Kernel version
<item> Your i4l/hisax version
<item> Your card type
</itemize>

Most isdn4linux developers are present on the mailing list, and many
other knowledgeable people. <bf>English postings are very welcome,
and will be answered in English!</bf>

The mailing list contains the same messages as the newsgroup (see question
<ref id="docu_newsgroup" name="docu_newsgroup">), so you can read any
responses to your question with your news reader. A bidirectional
gateway ensures that mailing list and news are in sync.

To subscribe to the mailing list, go to the web frontend at
<tt><htmlurl url="https://www.isdn4linux.de/mailman/listinfo/isdn4linux"
name="https://www.isdn4linux.de/mailman/listinfo/isdn4linux"></tt> and
submit the filled form. After that, you will <bf>not</bf> be subscribed yet.
Instead, you will receive a confirmation at the mail address you entered
in the above form. This is a security precaution to prevent subscription
by other persons or subscription of mistyped mail addresses. When you
receive the confirmation, just follow the instructions in that mail.
(I.e.: simply reply). After having replied, you will be subscribed and
receive a welcome mail. The welcome mail will contain your password, so
you should probably keep it just in case you want to unsubscribe or change
some options at the web frontend.
To unsubscribe, go to the web frontend again, use your password to login
and then unsubscribe.
Please note: there are about 20-50 messages per day on this mailing list.
To receive only one message per day, containing all postings, have a look
at question <ref id="docu_maillistdigest" name="docu_maillistdigest">.

<sect1> docu_maillistdigest: How can I get a digest of the mailing list for  
isdn4linux (only one message per day)?  
<label id="docu_maillistdigest">
<p>
While filling the form as described in question
<ref id="docu_mailinglist" name="docu_mailinglist">, simply click "Yes"
at the radio-button, named "Would you like to receive list mail batched
in a daily digest". You can change this option later when logging in
the web frontend.

<sect1> docu_mailarchive: Is there an archive of the isdn4linux mailing list?  
<label id="docu_mailarchive">
<p>
To quickly search for keywords, you can use
<tt><url url="http://www.deja.com"></tt>. Make sure to also select older
archive to do a complete search.

Messages are also saved (unsorted) at listserv.isdn4linux.de, collected by
month. To access the archive, you can use
<url url="http://www.isdn4linux.de/listarch/">.

Other archives are:
<itemize>
<item><tt><url
url="ftp://ftp.uni-oldenburg.de/pub/unix/linux/isdn/isdn4linux/Mailing-List"></tt>
</itemize>

<sect1> docu_bugtracker: Is there a bug tracker available for isdn4linux?  
<label id="docu_bugtracker">
<p>
Yes, there is a bugtracker available under the following url:
<url url="https://www.isdn4linux.de/mantis">. You have to register yourself
before you can search for known bugs and enter new issues.

<!-- Supported Hardware & hardware-specific stuff
-->

<sect> hardware: Supported hardware, its specialities, and hardware-related  
problems  
<label id="hardware">

<sect1> hardware_support: Which hardware is supported?  
<label id="hardware_support">
<p>
Only internal cards that plug into an ISA or PCI slot are
supported. ISA Plug&amp;Play cards are also supported, but need some additional
manual configuration by means of the <tt/isapnptools/. For details on the
configuration see question <ref id="config_pnp" name="config_pnp">.

Internal cards may be <ref id="glossary_active" name="active">,
<ref id="glossary_semiactive" name="semi-active">, or
<ref id="glossary_passive" name="passive">. Unless you have paid big money,
assume you have a passive card. More about the difference: see question
<ref id="hardware_activepassive" name="hardware_activepassive">.

Right now there is a driver for all passive card with certain Siemens
chipsets (HiSax driver). Have a look at the <tt>README.HiSax</tt> that comes
with the driver for the most up to date information on supported cards and
which parameter to pass to Hisax.
Here the status from 1st February 2002 (constantly improving):
<itemize>
<item>Teles 8.0/16.0/16.3 and compatible ones (like: Dr. Neuhaus Niccy
1016, Creatix 16/S0)
<item>Teles 16.3c (can not be used as reversed card)
<item>Teles S0/PCMCIA (old hardware)
<item>Teles PCI
<item>Teles S0Box
<item>Creatix S0Box
<item>Creatix PnP S0
<item>Compaq ISDN S0 ISA card
<item>AVM A1 (Fritz, Teledat 150 ISA)
<item>AVM Fritz PCMCIA
<item>AVM Fritz PnP
<item>AVM Fritz PCI (Teledat 150 PCI)
<item>AVM Fritz PCI v2
<item>ELSA Microlink PCC-16, PCF, PCF-Pro, PCC-8
<item>ELSA Quickstep 1000
<item>ELSA Quickstep 1000PCI (new name: ELSA Microlink PCI)
<item>ELSA Quickstep 3000 (same settings as QS1000)
<item>ELSA Quickstep 3000PCI
<item>ELSA PCMCIA
<item>ITK ix1-micro Rev.2 (also: ITK colombus card)
<item>Eicon DIVA 2.0 ISA and PCI (S0 and U interface, no PRO version)
<item>Eicon.Diehl Diva 2.01 ISA and PCI, and Diva 2.02
<item>Eicon DIVA Piccola
<item>ASUSCOM NETWORK INC. ISDNLink 128K PC adapter (order code I-IN100-ST-D)
<item>Dynalink IS64PH (OEM version of ASUSCOM NETWORK INC. ISDNLink 128K
adapter)
<item>All other ASUSCOM/Dynalink cards (includes OEM versions; in total more
than 50 card versions)
<item>PCBIT-DP (OEM version of ASUSCOM NETWORK INC. ISDNLink)
<item>HFC-2BS0 based cards (TeleInt SA1)
<item>Sedlbauer Speed Card (Speed Win, Teledat 100, PCI, Fax+)
<item>Sedlbauer Speed Star/Speed Star2 (PCMCIA)
<item>Sedlbauer ISDN-Controller PC/104
<item>USR Sportster internal TA (compatible Stollmann tina-pp V3)
<item>ith Kommunikationstechnik GmbH MIC 16 ISA card
<item>Traverse Technologie NETjet PCI S0 card and NETspider U card
<item>Dr. Neuhaus Niccy PnP/PCI
<item>Siemens I-Surf 1.x (with ISAR =&lt; try type 29)
<item>Siemens I-Surf 2.x (with IPAC =&gt; try type 12 asuscom)
<item>Trust PCI (only the old one with Siemens chip;
the one called 'Wisecom' in NL does not work)
<item>ACER P10
<item>HSR Saphir
<item>Berkom Telekom A4T
<item>Scitel Quadro
<item>Gazel ISDN cards
<item>HFC-PCI based cards
<item>PCI/Winbond W6692 based cards
<item>HFC-S+, HFC-SP/PCMCIA cards
<item>HFC-USB ISDN TAs
<item>ST5481 based USB ISDN adapters, e.g. BeWan Gazel 128 USB
</itemize>
Note:
<itemize>
<item>AVM A1+ is not supported
<item>PCF, PCF-Pro: up to now, only the ISDN part is supported
<item>PCC-8: not tested yet
<item>Eicon Diva U interface not tested
<item>Some cards do not work when compiled into the kernel, only when
loaded as modules.
<item>Asuscom card: please note that the ISA version is a different type
(12) then the PCI version (35 for HFC chip or 36 for Winbond chip)!
<item>To distinguish between HFC-PCI and PCI/Winbond, have a look at the
output of <tt>cat /proc/pci</tt>. You have HFC-PCI if you have a line
saying "Master capable" for your card.
<item>DataFire Micro V PCI = HFC-based card (type 35)
<item>Xircom Cardbus Eth10/100+ (PCMCIA) is not supported by isdn4linux,
but you can use it like an active external ISDN terminal adapter
(requires the xircom and serial driver).
<item>Gazel 128 USB from BeWAN Systems is supported as hisax_st5481 module.
For configuration hints have a look at:
<url url="http://www.posern.org/my-prjs/isdn/">.
</itemize>

In Germany: every ISDN card which German Telekom distributed in the past is
supported (the same is NOT true for the PBX they distributed).

The following cards are definitely not supported and will probably
never be supported, since the manufacturers have not released the
specifications for their very proprietary hardware/protocols:
<itemize>
<item>Fritz!X
<item>Eumex 404
</itemize>

As for the Eumex 404, there is an unofficial binary driver for isdn4linux
with Suse 6.3, which may or may not help you. Use it at your own risk:
<url url="http://home.t-online.de/home/MetalMilitia/eumex.htm">

<sect1> hardware_activepassive: What is the difference between an active and a  
passive ISDN card?  
<label id="hardware_activepassive">
<p>
An active ISDN card handles most of the ISDN connection protocols
(dialing, accepting calls, etc.) itself. The card includes a kind
of minicomputer with its own software (firmware). With a passive card, the
computer in which the card is installed has to perform these functions.

In principle, both types are supported by isdn4linux. However, since
active cards have non-standard interfaces, a driver can only be made
when the producer publishes the specifications for the
interface. Also, the card's firmware needs to be made freely
available. In contrast, many passive cards share the same
chipset. Therefore many passive cards can be supported once a driver
supports this one chipset.

These active cards are currently supported by an individual driver:
<itemize>
<item>AVM B1
<item>AVM C4
<item>Eicon DIVA Server BRI PCI
<item>Eicon DIVA Server 4BRI
<item>IBM Active 2000 ISDN card
<item>ICN
<item>PCBIT-D
</itemize>

<sect1> hardware_recommend: Which card is recommended by the developers?  
<label id="hardware_recommend">
<p>
The developers suggest using ELSA cards. ELSA has made their specifications
available to the developers, and provided a lot of support, resulting in an
excellent driver. Also, their cards are certified for usage in Germany, see
question <ref id="country_certified" name="country_certified">.

If you want to buy an active card, then the developers would recommend
the PCI Server from Eicon. The reason is that it can fax on both channels
with AT class 2 commands, and includes a V.90 modem.
The AVM B1 works also very well, and is likewise recommended. Old versions
(up to 3.0) could receive faxes only on one channel, but since AVM B1 PCI V4
all channels can be used simulateously for sending and receiving faxes.
See also question <ref id="hardware_avmb1" name="hardware_avmb1"> for more details about this card.
The Hypercope cards have also been reported to work very well, servicing
all available channels for faxing. However, they require a hardware update
for faxing and their linux driver is fairly new. See also question
<ref id="hardware_hypercope" name="hardware_hypercope"> for more details about this card.

If faxing is important for you, but you don't want to spent the money for an
active card, then a card with ISAR chipset may work well for you, e.g.
Sedlbauer Speedfax+ (in Germany you may be able to buy it at Conrads).

And if you want to buy a USB terminal adapter, then the Gazel 128 USB from
BeWAN Systems <url url="http://www.bewan.com"> has been reported to work fine
with the hisax_st5481 module.

<sect1> hardware_external: Does isdn4linux support external terminal adapters?  
<label id="hardware_external">
<p>
Generally not, but it doesn't need to. Terminal adapters are designed to behave
either like a modem or like a network card. Linux already supports both
modems and network cards without isdn4linux - so no special ISDN driver
is necessary (which usually greatly simplifies the configuration).
For example, have a look at the dialout program wvdial.

However, there is (at least) one exception. The Gazel 128 USB from BeWAN
System in France <url url="http://www.bewan.com"> has been reported to
work fine with the hisax_st5481 module. For configuration hints
have a look at: <url url="http://www.posern.org/my-prjs/isdn/">.

<sect1> hardware_cabeling: How should I wire my ISDN cables?  
<label id="hardware_cabeling">
<p>
For any details in this direction have a look at the excellent cable FAQ,
which can be found at least in a German version at:
<url url="http://www.in-berlin.de/User/scorpio/faqkabel.html">.

<sect1> hardware_irq: Why should I avoid IRQ 12 and 15 for my ISDN card?  
<label id="hardware_irq">
<p>
On many PCI boards, interrupt 12 is often used by a PS/2 mouse (even though you
may not have any or the IRQ is not activated for it). It may be used even when
you have no PS/2 port. Interrupt 15 is also often used by the second IDE bus
(even when you are not using it or the IRQ is not activated for it).
Even though one thinks that some IRQs are available they are still somehow
reserved by the BIOS. Good IRQs to try are always IRQ 5 and IRQ 9. Without mice
or modems you could also try 4 and 3, which works even on very exotic boards.

<sect1> hardware_irqsharing: Can the isdn4linux driver work with shared  
interrupts?  
<label id="hardware_irqsharing">
<p>
Yes, the drivers have been written to work with shared interrupts. However,
at least for the AVM Fritz!PCI card occasional problems have been reported
for motherboards with a BIOS bug (DFI motherboards K6BV3+, P5BV3+ K6XV3).
Try to disable the BIOS option <tt>CPU to PCI WRITE Buffer</tt> in those
cases as a workaround.

<sect1> hardware_s2m: Which S2M cards are supported?  
<label id="hardware_s2m">
<p>
At least these S2M cards have been reported to work:
<itemize>
<item>AVM T1
<item>Eicon S2M-ISA or DIVA Server PRI family (see
<url url="http://www.melware.de/">)
</itemize>

<sect1> hardware_pcmcia: Which PCMCIA cards are supported?  
<label id="hardware_pcmcia">
<p>
At least these PCMCIA cards have been reported to work:
<itemize>
<item>ELSA Microlink (NOT: ELSA Microlink/all)
<item>Sedlbauer
<item>AVM
<item>Teles PCMCIA (old hardware) - deprecated, since Teles often changes
hardware, and does not support the developers (see question
<ref id="hardware_teles" name="hardware_teles">).
</itemize>

<sect1> hardware_smp: Can I run isdn4linux on my multi-CPU board?  
<label id="hardware_smp">
<p>
Yes, this works nicely. However, make sure to compile the kernel and all
modules with option <tt/SMP/. If you run into problems when both CPUs try to
handle the same IRQ, try to boot with <tt/noapic/.

<sect1> hardware_64bit: Can I run isdn4linux on 64bit hardware with Linux?  
<label id="hardware_64bit">
<p>
In principle yes, however your hardware choice is currently limited to
active cards and external devices. Most desired are external devices using
standard interfaces (network, USB) which do not require isdn4linux at all.
The drivers for passive cards are currently not working under 64bit.
Obviously you can also not make use of binary drivers, unless you find a
binary compiled for 64bit.

One external USB device based on the HFC-S chipset reported to work with
isdn4linux is the Sitecom DC 104 with serial number greater than SN 46000202
(olders are ST chipset based, they have the same box). Also "tiny USB TA"
from Billion, and "surf mini usb" from Acer have been reported to work.

<sect1> hardware_alpha: Can I run isdn4linux on a DEC Alpha with Linux?  
<label id="hardware_alpha">
<p>
Yes, most cards should run with isdn4linux on a DEC Alpha. Many cards have been
reported to work with the HiSax driver. Also the active ICN card has been
reported to work.

<sect1> hardware_sun: Can I run isdn4linux on a Sun workstation?  
<label id="hardware_sun">
<p>
Probably not. There are three options for (internal) isdn in the SUN
enviroment:
<enum>
<item> SBUS ISDN adapter:
Old SUN-workstations used to have a SBUS interface for additional
peripheral boards.
There exists an ISDN sbus board sold as "X1012". As no information is
available for these boards, they are NOT supported!

<item> Built-in ISDN adapter:
Sparc-Station-LX, Sparc-Station-10 and Sparc-Server-10 have a
motherboard with build-in isdn-adapter.
These machines were supported by HISAX (kernel 2.3.0) but the code has
been left unsupported for very long (over nine months).
All kinds of ancient hisax definitions are still left in these drivers.
Much work is to be done to get it properly working again.
Note from the original developer, not to expect too much: the dbri chip
is not capable of buffering (irq for each byte) and raw-hdlc has to be
done in software instead of hardware...
The author of dbri.c has stopped active work on it,
but made a copy of the DBRI data sheet available at:
<url url="http://www.freesoft.org/Linux/DBRI">
for anyone who wants to fix the remaining glitches (status as of Jan 10,
2000). Please be aware that the code of the latest developments can not be
compiled for 32 bit machines like all sun-4m machines.

<item> PCI ISDN adapter:
Modern SUN-workstations and servers have a different busstructure
nowadays. The ULTRA series uses the PCI-bus.
Allthough some pc boards seem to be working in a SUN, there are NO
reports (yet) of properly functioning ISDN-PCI-boards in the SUN
environment. Please write me if anyone ever succeeds.

</enum>


<sect1> hardware_ppc: Can I run isdn4linux on a PowerPC with Linux?  
<label id="hardware_ppc">
<p>
Yes, in theory most cards should work. However some Endian format issues
remain due to the bugs. I heard that the AVMFritz!PCIv2 card may work well
with the old isdn4linux drivers (even with asterisk via chan_modem_i4l).
Also the Eicon Diva Server cards should work. You are welcome to report any
bugs and fixes to the mailing list.

In any case, you may also get a terminal adapter (= external ISDN "modem").
Since then you don't need isdn4linux (see question
<ref id="hardware_external" name="hardware_external">), this is not covered
here any further.

<sect1> hardware_maxcards: How many ISDN cards can I put into my computer?  
<label id="hardware_maxcards">
<p>
It depends on the availability of slots, interrupts/IO addresses in your
computer as well as the possibilities of the ISDN card. Most passive cards
are limited by the supported IO addresses (e.g.: Teles 16.x: only 3 addresses
are legally possible: 0xf80, 0xd80, 0xe80), and the total usage of interrupts
(every card needs one).

To use more cards, the ICN card may be your choice. It has no interrupts, a
more flexible port configuration and the driver places the shared memory area
of all ICN cards at the same address. The card memory is shown only as
needed. Therefore, one can use as many cards are there are slots.

If you really need a lot of ports, then eventuelly, a S2M card might be
interesting for you, see question <ref id="hardware_s2m" name="hardware_s2m">.

See question <ref id="config_manycards" name="config_manycards"> about
the specialities for the configuration of more than one card.

<sect1> hardware_hfc: What is special about card with an HFC chip?  
<label id="hardware_hfc">
<p>
Cards with an HFC-PCI chip allow some specialities that are not possible with
other ISDN cards. So it is possible to run the card in NT mode (requires
crossing the ISDN connection and change by software) - this means you can
simulate to another ISDN card that your card is an NTBA. Since isdn4linux does
not implement the level 3 protocol used by the exchange, you can only use this
mode like a leased line.

However, some special software named PBX4Linux has been written for this.
You may want to have a look at the German article in ct 9/2004 on how to use
PBX4Linux. You can also check the web site
<tt><url url="http://isdn.jolly.de"></tt>.
You may especially be interested in the information about card support for the
NT mode with mISDN at: <tt><url url="http://isdn.jolly.de/cards.html"></tt>.

Another alternative for emulation of a PBX is Asterisk, to be found on:
<tt><url url="http://www.asterisk.org"></tt>.

Also, it is possible to give up one B-channel in exchange for reading the
complete D-channel protocol, which is great for isdnlog. The later can
also be done with a reversed card (see question
<ref id="isdnlog_reversedcard" name="isdnlog_reversedcard">)
but with HFC chips this works much more reliably and cleanly. You can
activate this special echo mode by calling:
<code>
hisaxctrl &lt;driver_name&gt; 10 1
hisaxctrl &lt;driver_name&gt; 12 1
</code>
You can deactivate it by calling:
<code>
hisaxctrl &lt;driver_name&gt; 12 0
hisaxctrl &lt;driver_name&gt; 10 2
</code>
Parameter 10 changes the number of available channels, parameter 12 switches
the echo mode.

Cards with HFC chips may be difficult to run on older mainboards.
Ensure with <tt>lspci -v</tt> that an IRQ has been assigned to the card
(if not check the PnP bios settings). Verify that the card is
located in a slot with busmaster DMA capabilities. Verify whether the
kernel is compiled such that it will run on your CPU (newer
distributions may not run on CPUs like 486 or Pentium; Suse provides
the kernel 'k_i386' to run with older hardware).

<sect1> hardware_elsa: What should I know about ISDN cards from ELSA?  
<label id="hardware_elsa">
<p>
Generally, ELSA supports the ISDN4LINUX developers quite well with
documentation on how to access their cards. Thus, these cards are well
supported and very recommendable for use under ISDN4LINUX. Also, the
ELSA Quickstep 1000 PCI (new name Microlink PCI) is one of the only brands
of cards that are officially certified for use in Germany, and therefore
in EC (see question <ref id="country_certified" name="country_certified">
for more information on certification).

However, there is a speciality with some non-PCI-conformal mainboards and
the ELSA Quickstep 1000pro-PCI. These mainboards set the IO address to
incorrect values (they need to be on 0x100 boundaries, and in a higher
area). This may create an error message like
"You may have the wrong PCI bios" and hang the system. The best fix
is a Bios upgrade. If this is not feasible, you can get the module
<tt/pcitest/ from Karsten Keil <tt><htmlurl url="mailto:keil@isdn4linux.de"
name="keil@isdn4linux.de"></tt>. It will initialize the card correctly,
then exit with an intentional error (thus not occupying any memory).

To interface from ELSA's RJ11 plug to an RJ45 cable, use the following
cabling scheme:
<verb>
	  RJ11   -   RJ45
pins      1234       12345678
Cable     abcd       --abcd--
</verb>

Regarding the Elsa Microlink ISDN USB: contrary to previous announcements
it does NOT works like a serial terminal adapter with the USB communication
class driver. Currently, it is not supported by isdn4linux.

<sect1> hardware_sedlbauer: What is special about the Sedlbauer card?  
<label id="hardware_sedlbauer">
<p>
The Sedlbauer card comes in several versions:
<itemize>
<item> Sedlbauer Speedwin
<item> Sedlbauer Speedfax
<item> Sedlbauer Speedfax PCI
</itemize>

The Speedwin is a normal passive card with no specialities.

The Speedfax has a very special hardware: it is a semiactive card based
on the ISAR chipset which supports sending/receiving faxes and an analog
modem up to 14400. It is special in that you use it with HiSax which
normally works only for passive cards.
As all active card you have to load its firmware (in this case
after loading HiSax) from the file ISAR.BIN, which is part of the
isdn4k-utils.

Please note that compression (V42bis, MNP) are not implemented in firmware,
and therefore not supported when using the analog modem. The ideal init
string for the card to allow modem dialin is <tt>AT&percnt;C0&bsol;N0</tt>.

If for some fax senders receiving by Hylafax does not work, then try to
set the following configuration parameter for Hylafax:
<code>
Class1SwitchingDelay:  75
</code>

The Sedlbauer Speedfax PCI is special in that it was produced just for
Linux - there is no driver for it under Windows.

<sect1> hardware_teles: What should I know about before buying an ISDN card  
from Teles?  
<label id="hardware_teles">
<p>
First the latest news: according to the German magazine ct 02/2001, Teles has
closed down its business activities in the ISDN area. Therefore, this
FAQ does not really apply any more. However, I'll keep this FAQ for now
to document Teles' attitude towards their customers. The author has had
personal experience with Teles since 1994.

One of the most frequently asked questions for Teles cards: The Teles card
16.3c has a crippled FIFO, therefore it is required to use
<tt/AT&amp;B1024/ when using the ttyI* devices (if the remote side still
send packets with more than 1024 bytes it will not work
- unfortunately many CAPIs use 2048 bytes as default).
The latest Teles PCI card needs the <tt/netjet/ driver, the teles driver
will NOT work (that card identifies itself as 'TigerJet Tiger300' when doing a
<tt>cat /proc/pci</tt>).

Now some comments about Teles in general (these are the personal opinions of
the author of this FAQ, please blame nobody else than me):

Teles' business practices are very customer- and developer-unfriendly when
compared to those of other companies. Naturally, the developers give
priority to cards for which support is available, and where the specifications
are freely available.

So far, Teles has had a very unfriendly attitude towards the i4l
developers. No support has ever been received from them, and they don't publish
any information about how to access their card. The developers have invested a
lot of private effort into getting this card to work from the beginning without
receiving any support. The driver has been a complete private effort. Yet,
Teles has bragged on their web site that their cards run under Linux, without
giving proper credit.

Even companies that buy Teles cards and resell them under their own name have
not been able to improve the support. This has lead to the situation where a
re-branding company (!) itself had to go through the effort of obtaining
approval to legally use i4l in Germany on a Teles card.

From a customer point of view, check out the prices for their hotline before
you buy any hardware from them! The author of the FAQ refuses to use any
hotline that charges 216,- DM per hour. Reports about quality and waiting time
have not always been favorable.

And this company did not even give away drivers for other operating
systems, like Windows, for free for many years (I know about 1995-2000).
Only since about April 2000 you can download the drivers over the Internet.
Before you had to dial up a very expensive number (0190) where you had to pay
about DM 1,20 per minute in Germany to download the driver. Not that it's
advisable to use Windows anyway, but just to let you know...

Warning: Teles has often changed their cards without notice, while still
using the same name. When you buy a Teles card, you may find out that your
brand-new card can not be supported by i4l! (As has happened many
times in the past...)

The developers will try to support new Teles cards when information about how
to access it becomes available, and when they have no other priorities. Of
course you can always send a patch.

<sect1> hardware_fritz: What should I know when configuring a Fritz! card  
(also known as: AVM A1, Teledat 150, BT Speedway)?  
<label id="hardware_fritz">
<p>
The Fritz! card comes in different variations. Since the PCI card and the
ISA/PNP card have the same type (27), hisax will assume an ISA/PNP card
if you pass an io address, and a PCI card if you do NOT pass an io address.
Make sure to give the parameters properly.

The newest Fritz! PCI card (v2.0) is now supported by a new driver, however
it has not yet been tested thoroughly. The card can be identified by lspci
returning 0e00 as the card id.

If the interrupt for the card is shared with other devices and your card does
not work, then there could be an issue with the motherboard. See question
<ref id="hardware_irqsharing" name="hardware_irqsharing"> for this.

One very interesting thing: the Fritz! card was the first card
for which a capi driver existed which can be configured to
fax. See question <ref id="feature_capi" name="feature_capi"> and
<url url="http://www.avm.de/ftp/cardware/fritzcrd/linux/index.htm">
for more information on this. Usage of the capi driver is completely optional,
you might as well stay with the standard driver if you do not need capi
support.

In total three drivers exist: the old Hisax driver (part of isdn4linux), the
new mISDN driver, and the binary AVM driver. Only the last one is prepared
for sending faxes.

<sect1> hardware_avmb1: What is special about the AVM B1 card?  
<label id="hardware_avmb1">
<p>
This card supports many special features in its firmware and is very well
supported by its Linux driver. It's currently one of the only ISDN cards
that you can use to fax under ISDN4LINUX, or which supports the
CAPI 2.0 interface. You can get the newest driver from:
<url url="ftp://ftp.in-berlin.de/pub/capi4linux/">.
To get the firmware download the two perl scripts from:
<url url="ftp://ftp.in-berlin.de/pub/capi4linux/firmware/">
They will download and extract the firmware from tar files on the avm
ftp server on: <url url="ftp://ftp.avm.de/cardware/b1/linux/">.

To use the AVM on a point-to-point connection (&dquot;Anlagenanschluss&dquot;)
add &dquot;DSS1 P2P&dquot; to the load command for the firmware, like:
<code>
avmcapictrl load /usr/lib/isdn/b1.t4 0 DSS1 P2P
</code>

There is also a mailing list for problems with the AVM B1 available.
Visit <url url="https://mlists.in-berlin.de/mailman/listinfo/linux-avmb1">
for more details about it.

<sect1> hardware_hypercope: What is special about the Hypercope cards?  
<label id="hardware_hypercope">
<p>
These cards support several special features in their firmware. They are newly
supported by a Linux driver. They are currently one of the only ISDN cards
that support the CAPI 2.0 interface. Also, you can use them very well for
faxing under ISDN4LINUX (after upgrade with a fax card - possible for
HYSDN Ergo2 and HYSDN Metro4).

More information on company and hardware is available on:
<url url="http://www.hypercope.de">
Configuration is similar to that of an AVM B1.

<sect1> hardware_icn: What is special about the ICN card?  
<label id="hardware_icn">
<p>
This was the first active card supported by isdn4linux. The manufacturer has
always supported i4l developers (<tt><url url="http://www.think.de/"></tt>).
The ICN does not need any interrupt (polling), therefore a PC can be equipped
with many of them without any interrupt conflicts. The newest firmware should
be available at
<tt><url url="ftp://ftp.think.de/pub/isdn4linux/icn/firmware/"></tt>.
Unfortunately, the ICN is not produced any more.

<sect1> hardware_isurf: What should I know about the Siemens I-Surf cards?  
<label id="hardware_isurf">
<p>
There are several interesting things.
<itemize>
<item> Two Versions: There are two different versions (version 1.0 and
version 2.0) with a different chipset. Both work fine, however you have
to set the type properly (29 for version 1.0, 12 for version 2.0).
<item> The USB version is currently not supported, there is no driver
available.
<item> PnP bug: Due to a bug in the pnp chip it is very important for the
I-Surf 1.0 to have the following PEEK and POKE lines in your isapnp file
to properly initialize the PnP register:
<code>
(MEM 0 (BASE 0x0c8000) (MODE bu) (UPPER 0x0c8400))
# (MEM 0 (BASE 0x0c8000) (MODE br) (UPPER 0x000400))
(REG 0x31 (PEEK))
(REG 0x31 (POKE 0))
(REG 0x31 (PEEK))
(ACT Y)
))
</code>
<item> Memory mapping: Since the I-Surf 1.0 uses memory mapping for the
ISA bus, ensure that the used memory area is not shadowed or cached
(see BIOS setup).
<item> Firmware loading: Before usage you have to load the firmware:
<code>
hisaxctrl &lt;id&gt; 9 ISAR.BIN
</code>
(You find the file ISAR.BIN in the isdn4k-utils or on the I-SURF cd.)
<item> Fax: The I-Surf 1.0 can be setup to send and receive faxes (see
question <ref id="feature_fax" name="feature_fax"> for details).
</itemize>

<sect1> hardware_diva: What should I know about the Eicon Diva cards?  
<label id="hardware_diva">
<p>
In general, a dedicated driver exists which supports the active Eicon
Diva cards very well. The Pro series are not supported by isdn4linux
since it is a semiactive card with a DSP as a B-channel controller.
There is no code available in isdn4linux to dynamically load DSP
programs into the card. However, check Eicon's website; maybe by now they
provide pre-compiled driver for their cards not supported by isdn4linux.


<!-- Trouble Hardware
-->

<sect1> hardware_crossedcable1: If i4l uses one B-channel then the other one  
will be blocked (incoming as well as outgoing)...  
<label id="hardware_crossedcable1">
<p>
This behavior is typical for a cable with confused a/b wiring. Some
NT from Quante had a wrong labeling. They caused exactly the
mentioned behavior if the PBX was connected to the plug of the NT
and the ISDN card to the pins of the NT. As soon as some device
activates the bus the other one can no longer get through.

<sect1> hardware_crossedcable2: How can I test whether a a/b cable pair has  
been crossed?  
<label id="hardware_crossedcable2">
<p>
This question assumes that you are connected by an internal bus that you
installed, attached directly to the NT (without using an RJ45 cable).

The easiest way to test it is to buy a little cable tester (the author of this
FAQ got one from Conrad Electronics in Germany for 29,- DM - just follow the
simple instructions).

Otherwise you have a bit more work. Switch line a1 and b1. If it doesn't work,
put them back and switch a2 and b2. If it still doesn't work, try switching
them both. As long as {a|b}1 and {a|b}2 are kept, nothing can break. If you
want to be sure, before plugging it in measure between pins 4 and 5 and between
Pins 2 and 6 on the socket; there should be no current, but between 3 and 4 and
between 6 and 5 should be 40 V, 6 and 3 positive.

With the Western plug this works similar. 4 lines are used:
<verb>
| | | |
| | | |
1 2 3 4
</verb>
Then you can try to switch (1 with 4) or (2 with 3) or both. Never switch the
outer with the inner lines - this would cross the RX and TX lines and nothing
will work.

Check the Cable FAQ for more details on which line should be connected how.

If both devices are attached via RJ45, then one of the cables
has been twisted. That usually happens if one of the RJ45 plugs
has been attached upside-down (a1/b1 are inside, a2/b2 are outside,
so the order of the sending/receiving pairs is maintained), then
you just need a new plug and of course pliers for the RJ45, old
plug off, and new plug (in the right direction) on.

<sect1> hardware_pbx: i4l is connected to the internal bus of a PBX. Any problem?  
<label id="hardware_pbx">
<p>
Many PBX run non-standard ISDN protocolls on their internal bus.

In old versions (before end of August 2003) this could cause i4l to print
warnings like "Unexpected discriminator 0xZZ" (where ZZ is a hexadecimal
number) when it encounters unexpected frames (some old versions even
crash). This can increase your message file by as much as 1 MB in 3 days. The
PBX <tt>Ackermann Euracom 181</tt> (discriminator 0xaa) as well as
<tt>Ascom</tt> (discriminator 0x44/0x47) seem to be notorious for this. You can
avoid the warning by adjusting the switch/case code for isdnlog in function
<tt>processctrl(...)</tt> in <tt>processor.c</tt> and recompiling isdnlog.
Since August 2003 ignoring these unknown packages has become the default,
therefore the recompile is not necessary any more.

Please note that isdnlog will not be able to log any incoming
data packages, since the PBX has to forward the packages. To see everything,
you have to bypass the PBX.

Please be aware, that the PBX may hang if the ISDN card does not respond to
the PBX requests - bypass the PBX in such a case.

Also, a PBX may run 1TR6 protocoll on the internal bus by default, rather
than Euro ISDN. You have to configure i4l (or the PBX) accordingly, best
is you try to configure both on the same or similar protocolls.

Also the MSN may be different than you expect. Check several versions, no
digit (then use <tt>0</tt>, which i4l will require in such a case), one digit,
or two digits, or the whole MSN. Best is you call some device (e.g. ISDN
telephone) on the internal bus and check what i4l writes into the log file.

When you can not dial out, the most common problem is that you have not
set the MSN properly for outgoing calls, which causes the PBX to refuse
your request.

For dial in be aware that some PBX add a leading 0 to any incoming
telephone number, so adjust your configuration for the secure option
accordingly.

Last, remember that you may have to configure your PBX to 'route' incoming
calls onto the internal ISDN bus.

If you have a point-to-point configuration ('Anlagenanschluss') then
you cannot connect your card directly to the S0 bus in parallel to the PBX
(otherwise nothing will work). You have to connect to an internal ISDN bus.
Your MSN is usually the extension at the end of your telefon number.

If your PBX is the <tt/Ackermann Euracom</tt>, then you may also check out
this German site for the configuration software maKs:
<url url="http://www.ganzfix.de">

<sect1> hardware_telestrouble: The PNP tools done work with my Teles 16.3 PNP  
card!  
<label id="hardware_telestrouble">
<p>
It's probably not a Plug 'n Play card at all - even though Teles
now prints PNP on all their card and packaging. The difference is easy
to recognize: a real Teles PNP card no longer has the (tiny) Dip switches
on the card to set the IO addresses.

<sect1> hardware_elsacabletrouble: On my ELSA card, the LED for the loss of the  
TEI often blinks. My connections are also often disrupted...  
<label id="hardware_elsacabletrouble">
<p>
These blinking LEDS are often caused by a bad cable or a too long or
unterminated SO bus.

<sect1> hardware_elsairq: My ELSA Quickstep 1000 ISA card produces very many  
interrupts with the HiSax driver. Is this normal or a problem with the HiSax  
driver?  
<label id="hardware_elsairq">
<p>
This is normal. The ELSA Quickstep 1000 ISA card has a hardware timer on the
card which can not be disabled by software. You have to modify the card
hardware to get rid of it. Check with Karsten Keil for this:
<tt><htmlurl url="mailto:keil@isdn4linux.de" name="keil@isdn4linux.de"></tt>



<!-- Configuration/Troubleshooting
-->

<sect> config: General information about Configuration  
<label id="config">

<sect1> config_msn: How should I set up isdn4linux with my MSNs?  
<label id="config_msn">
<p>
See section <ref id="msn" name="msn">.

<sect1> config_hardware: How should I configure my hardware? Is there  
something special I should know about my ISDN card?  
<label id="config_hardware">
<p>
Have a look in section <ref id="hardware" name="hardware">.

<sect1> config_dialout: How should I configure dialout?  
<label id="config_dialout">
<p>
See section <ref id="dialout" name="dialout">.

<sect1> config_dialin: How should I configure dialin?  
<label id="config_dialin">
<p>
See section <ref id="dialin" name="dialin">.

<sect1> config_suse: I can not select my card in yast?  
<label id="config_suse">
<p>
If you have a SuSE distribution, and you can not find your card in yast,
then select card <tt/generic/ and enter the exact parameters in the
special case line, like: <tt>type=27 protocol=2</tt> for Fritz!PCI and
Euro ISDN. Get a newer kernel if the desired type is not yet supported.

<sect1> config_pnp: How do I configure a PNP (Plug and Play) card?  
<label id="config_pnp">
<p>
For PCI cards Plug and Play works automatically, they don't need any manual
configuration if the correct card type is provided. ISA PNP cards will
require some manual configuration:
<enum>
<item>With &dquot;make menuconfig&dquot; (or &dquot;make config&dquot;) set the
following kernel options:
<itemize>
<item>ISDN = &dquot;M&dquot; (as module - otherwise PNP doesn't work!)
<item>HiSax = &dquot;M&dquot; (as module - otherwise PNP doesn't work!)
<item>16.3/PNP support
<item>EURO support
</itemize>
<item>Compile and install kernel and modules, depmod. (Reboot!)
<item>Read the configuration of the PNP card with:
<code>pnpdump -c &gt; /etc/isapnp.conf</code>
<item>Verify whether pnpdump has prepared the configuration file
<tt>/etc/isapnp.conf</tt> properly:
<itemize>
<item>INT0 - the interrupt used by the card (Default for Teles 16.3 PNP: 10).
Make sure that interrupt 3 and 4 are not used, since they are reserved for
the serial interface (which, unfortunately, the serial driver may have
forgotten to reserve).
<item>IO0, IO1 - the IO ports used by the card (Default for Teles 16.3 PNP:
0x580 and 0x180) (Attention: these values must be 64-bit aligned (ending with
0, 4, 8, or c)! Early versions of the PNP cards may suggest incorrect values!)
<item>Comment removed in front of ACT Y!
</itemize>
<item>Activate the configuration with:
<code>isapnp /etc/isapnp.conf</code> (must be started at every boot)
<item>Now the HiSax module can be started for Euro-ISDN with:
<code>modprobe hisax io=4,2,INT,IO0,IO1</code>
(Replace INT, IO0, and IO1 with your values in isapnp.conf.)
</enum>

<sect1> config_startstop: How can I start and stop the ISDN configuration?  
<label id="config_startstop">
<p>
There are several options:
<itemize>
<item> Reboot: rebooting your computer always works. If you compiled i4l into
the kernel, then this is actually your only chance. The remaining options
only work if you configure i4l using modules.
<item> Manual: Unload the modules used by i4l with rmmod, then reload them with
modprobe.
<item> Runlevel: use telinit to switch to a runlevel which does not contain
ISDN, then switch back to the original runlevel.
<item> Scripts: most distributions come with start/stop scripts.
For example, on a Suse 7.0 distribution, this will stop ISDN:
<code>
rcroute stop
rci4l stop
rci4l_hardware stop
</code>
This will restart ISDN:
<code>
rci4l_hardware start
rci4l start
rcroute start
</code>
</itemize>

<sect1> config_kerneld: Why shouldn't I use <em>kerneld</em> to load the ISDN  
modules in the kernel as needed?  
<label id="config_kerneld">
<p>
<em>kerneld</em> does not work well with the ISDN modules, since the ISDN
modules can not store their status, and could miss important messages on the
D channel. Newer versions of i4l ensure that they won't be unloaded by
kerneld, but you should not try to use kerneld with any version of i4l.

<sect1> config_runlevel: How can I boot Linux sometimes with  
ISDN, and sometimes without?  
<label id="config_runlevel">
<p>
Yes, you can define two different run level for this (under SysVInit) in
<tt>/etc/inittab</tt>. One run level includes the ISDN processes, where the
other one does not.

<sect1> config_manycards: How do I configure more than 1 ISDN card?  
<label id="config_manycards">
<p>
There are some specialities for configuration of more than 1 card:
<itemize>
<item>You have to start a driver for every type of card you have, with the
correct configuration arguments.
<item>To handle more than 1 card with the same driver (e.g. HiSax should
handle an ELSA and an ASUS card), you have to pass the configuration arguments
for all cards to this driver. Please note, that you'll have to use modules
for more than two cards, to pass all arguments. As an example, you can
load HiSax for two Sedlbauer cards with the following command:
<code>
modprobe -v hisax protocol=2,2 type=28,28
</code>
<item>Driver ID: the HiSax driver uses 'HiSax' as the default for a driver
id if you have only one card. For more cards you have to set the id
explicitely, e.g. for two cards in the form of
<code>
id="contr0%contr1"
</code>
<item>Dialin of many people at the same time: have a look at question
<ref id="dialin_manyparallel" name="dialin_manyparallel">.
<item>Dialout through several cards: have a look at question
<ref id="dialout_manycards" name="dialout_manycards">.
</itemize>

<sect1> config_manychannels: How can I increase i4l's maximum number of  
channels?  
<label id="config_manychannels">
<p>
You can adjust the parameter ISDN_MAX_CHANNELS and the ISDN_MINOR* parameters
in <tt>/usr/src/linux/include/linux/isdn.h</tt> and rebuild the isdn stuff.
It is unlikely you have more than 64 physical B channels available, therefore
you probably want to leave ISDN_MINOR_B and ISDN_MINOR_BMAX as they are.

Your bottleneck are probably the number of potential (logical) network
connections (ipppX devices). The maximum number for this (ISDN_MAX_CHANNELS)
is 127, since the minor devices start at 128 (see ISDN_MINOR_PPP) and have to
end before 255 (ISDN_MINOR_STATUS).

To further increase the maximum number of logical connections you either
have the possibility to use an additional major (e.g. 44 - not used any
more) - this requires some small changes to the driver and the installation
of one ipppd instance per logical connection; or to use only one
ipppd per physical B channel with external Radius authentication. In the
first case you have to modify and recompile the driver, in the second case
you have to modify and recompile ipppd (you'll find some preparations for
this already in the source code).

Don't forget to create the additional devices with makedev.sh (part of
isdn4k-utils) or by hand.

<sect1> config_gsmv110: How do I connect my PalmPilot via GSM over V.110  
to my computer?  
<label id="config_gsmv110">
<p>
A connection via GSM will first go to the GSM provider via a special air
transmission protocol. To forwarding the data on to an analog or ISDN
line, an adapter called IWF (interworking function) has to translate this
into the analog or ISDN specific transmission protocol. Which analog or
ISDN transmission protocol is being used depends on how the mobile phone
requests its GSM connection.
An analog connection is not very attractive due to the lengthy modem
handshaking on dialin. For ISDN, HDLC and X.75 are currently not supported
by the IWF, so the choices are down to V.110 and V.120.
V.120 has better flow control and error correction, but currently isdn4linux
only supports V.110.

On the dialup server set up async PPP with a normal pppd on a ttyI* device
(sync ppp will not work). Additionally to setting the msn, you have to set
V.110 and the transmission rate to 9600 with <tt/AT&amp;R9600/
(<tt>/usr/src/linux/Documentation/isdn/README</tt> gives more details on
the V.110 bitrate adaption for this command).
Switch off autoanswer with <tt/ATS0=0/ if you use mgetty.
pppd needs to be called with <tt/noccp/ and <tt/require-pap/.

On the GSM mobile phone side, request an ISDN V.110 connection with the
command
<code>
AT+CBST=71,0,1+CHSN=1,0,0,0
</code>
For a Nokia 7110, you may have to use the undocumented command
<code>
AT+CBST=75,0,1
</code>

If the bearer capability is reported as &dquot;88 90 21 48 06 bb&dquot; by
isdn4linux, then you have set it correctly (88 90 21 means V.110, 48 means
ASYNC 9.6kbit, 06 means flowcontrol RX/TX, bb means 8 bit 1 stop none parity).

If the call is indicated with service indicator byte 2 = 0 and not accepted
(happens with some wrongly configured PBX), then adjust with <tt/ATS19=0/.

A higher bandwidth of 19.2kbit (HSCSD) could be requested with the command
<code>
AT+CBST=81,0,1+CHSN=3,0,0,0
</code>
but you can not be sure that your GSM provider will really use this rate.
Configure your dialin server accordingly.

For a mini-howto see:
<url url="http://www.oltom.com/Linux/Docs/GSM%20over%20V.110%20Mini-HOWTO.txt">


<sect1> config_h323: How do I configure isdn4linux to act as a voice-over-ip  
gateway for H.323 clients?  
<label id="config_h323">
<p>
You have to install a gateway which handles the translation. Several
versions exist which are all based on the OpenH323 and PWLib libraries.
The latest recommendation is to use isdngw at:
<url url="http://www.gnugk.org/h323-isdn-gw.html">. This is an updated
version of the isdngw located at:
<url url="http://www.virtual-net.fr/h323/isdngw/">, which in turn is an
updated version of the Linux H.323 - ISDN Gateway found on
<url url="http://www.telos.de/linux/H323/">.

Please note that not all sound cards support full duplex audio. Depending
on your hardware you may end up with uni-directional voice.

<sect1> config_point2point: How do I configure a point-to-point connection?  
<label id="config_point2point">
<p>
First of all, the point-to-point connection will only work for one single
device connected to it - therefore nothing else but your ISDN card may
be attached to it. You can switch HiSax into point-to-point mode:
<code>
hisaxctrl &lt;driver_id&gt; 7 1
</code>
Additionally, you can use the &dquot;AT&amp;Lxxx$dquot; command to
configure the range of telephone numbers isdn4linux should be listening
to on the ttyI* devices.

If you really absolutely want to run your ISDN card for read-only purposes
in parallel to your pbx on a point-to-point connection, then you have
to disconnect the RX leads (pin 3 and 6 on western plug), so that the NTBA
will not see the ISDN card. In this case configure HiSax normally, NOT in
point-to-point mode.

<sect1> config_links: What helpful links are there about and around  
isdn4linux?  
<label id="config_links">
<p>
These are helpful links that are currently available on how to configure
isdn4linux:
<itemize>
<item>English: <url url="http://www.wurtel.cistron.nl/i4l-howto-uk.html">
<item>Dutch: <url url="http://www.wurtel.cistron.nl/i4l-howto-nl.html">
<item>German: <url url="http://www.franken.de/users/klaus/">
<item>French: <url url="http://www.linux-france.org/article/connex/ISDN/">
and <url url="http://www.linux-france.org/prj/inetdoc/guides/rnis/">
<item>Suse Support database:
<url url="http://sdb.suse.de/sdb/en/html/index.html">; there is also an ISDN
howto (isdn.html) and a ISDN quick-install guide (isdnquick.html).
<item>Tips to configure Suse (and about offline reading):
<url url="http://www.schlenn.de/isdn4linux/">
<item>Tips to configure Red Hat:
<url url="http://www.webideal.de/rh-isdn/">
<item>Tips to configure Debian with Fritz Card PCI and kernel 2.6 (in German):
<url url="http://www.plzk.de/archiv/files/docs/FritzCard.PCI.Linux-HOWTO.html">
<item>Tips to configure Mandrake:
<url url="http://www.mandrakeuser.org/connect/cisdn.html">
<item>Tips to configure Gentoo:
<url url="http://forums.gentoo.org/viewtopic.php?t=29991">
<url url="http://de.gentoo-wiki.com/ISDN">
<item>fli4l, a prepackaged Linux version to use an old PC as ISDN router:
<url url="http://www.fli4l.de"> (great!)
<item>LR101 (a project which tries to create a hardware router based on Linux):
<url url="http://lr101.linux-it-solutions.de">
<item>Scripts and installation tips from several people:
<tt><url url="http://www.rosat.mpe-garching.mpg.de/&tilde;web/ISDN.html"></tt>
<item>Documentation on abc extensions:
<tt><url url="http://i4l.mediatronix.de/"></tt>
<item>Installation of CAPI4LINUX, CAPI4LINUX, and CAPI4Hylafax (in German):
<tt><url url="http://ixi.thepenguin.de"></tt> or
<tt><url url="http://capi4linux.thepenguin.de"></tt> or
<tt><url url="http://www.thepenguin.de"></tt>
<item>Vbox development:
<tt><url url="http://innominate.org/projects/vbox/index.php3"></tt>
<item>Michael Hipp's page (general informations):
<tt><url url="http://www-ti.informatik.uni-tuebingen.de/~hippm/isdn.html"></tt>
<item>Chargeint tips:
<tt><url url="http://www.auf-der-er.de/chargeint.html"></tt>
<item>Homepage of linecontrol (manage isdn dialing similar to kisdn):
<tt><url url="http://linecontrol.sourceforge.net"></tt>
<item>(German) Homepage of ISDN Sniffer (read ISDN bus, e.g. via reversed
card): <tt><url url="http://krypt.cs.uni-sb.de/projects/isdnsniffer/"></tt>
<item>Homepage of Asterisk (Open Source Linux PBX):
<tt><url url="http://www.asterisk.org"></tt>
<item>Homepage of ivcall (send and receive fax/voice calls):
<tt><url url="http://0pointer.de/lennart/projects/ivcall/"></tt>
<item>Configuration software maKs for Ackermann Euracom (not isdn4linux related):
<tt><url url="http://www.ganzfix.de"></tt>
</itemize>

<sect1> config_misdn: How should I configure the new mISDN driver, and what  
is so special about it?  
<label id="config_misdn">
<p>
The mISDN driver stands for modular ISDN. It is a complete rewrite of the old
isdn drivers and now communicates via CAPI messages. The mISDN driver is
retire the historical drivers once it is fully functional within the 2.6.x
kernels. As a temporary work around the historical drivers have been
ported into the early 2.6.x kernels to get isdn working, however, this will
be fixed in later versions.

To start mISDN, you have to load all the following modules:
<itemize>
<item>capi
<item>mISDN_core
<item>mISDN_l1
<item>mISDN_l2
<item>l3udss1
<item>mISDN_capi
<item>mISDN_isac (for isa card)
<item>Hardware specific driver (e.g. hfcpci, or avmfritz)
</itemize>

Not all features are available. It is currently not planned to port
1TR6 (the ancient ISDN protocoll in Germany) to the new driver.

For more information on how to configure it have a look at the following
website: <tt><url url="http://rcum.uni-mb.si/~uvp00845b/"></tt>

For a more general description on the mISDN driver and the future of isdn4linux
you may also read the German article published in ct 3/2004. An online
version is available at: <tt><url url="http://www.heise.de/ct/04/03/182/"></tt>

Please note that the current FAQ applies mainly to the old isdn4linux drivers.
mISDN may work differently than described in this FAQ.
Please let me know about any amendmends for this FAQ.


<sect1> config_kernel26: What has changed with the kernels 2.6.x?  
<label id="config_kernel26">
<p>
With the kernels 2.6.x the mISDN driver has been introduced (see question
<ref id="config_misdn" name="config_misdn">). It is planned that the mISDN drivers will replace
the old isdn4linux drivers like HiSax, which have been ported to 2.6.x only
since mISDN was not ready yet.

Please note that the ported drivers have not been upgraded to make use of the
new kernel features like devfs. You still have to create all the devices you
need, either with makedev.sh (part of isdn4k-utils), or by hand. Some
distributions will do that for you (e.g. Suse), for others you have to do
this yourself (e.g. Mandrake 10).


<sect1> config_asterisk: How can I install asterisk with mISDN?  
<label id="config_asterisk">
<p>
First you have to get mISDNuser and compile it. Then you have to compile
chan_misdn (included with asterisk) so it works together with mISDNuser.
For this you have to modify the Makefile in <tt>asterisk/channels/misdn/</tt>
to configure the correct location of mISDNuser. A make in the same directory,
followed by a 'make install' in the asterisk directory should be sufficient.

The easiest way is to get the install script published at:
<url url="http://www.beronet.com/download/install-misdn.tar.gz">.


<!-- Troubleshooting
-->

<sect> trouble: Troubleshooting  
<label id="trouble">

<sect1> trouble_22memory: I can't start ISDN on my machine with kernel 2.2.x.  
I get the error messages "init_module: Device or resource busy" and  
"isdn: Could not allocate device-struct.".  
<label id="trouble_22memory">
<p>
This is a memory problem and means you don't have enough <bf>unfragmented</bf>
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
<ref id="trouble_littlememory" name="trouble_littlememory">), compile
ISDN4LINUX into the kernel, or start and then exit a large program to ease
the memory fragmentation problems.

<sect1> trouble_littlememory: How can I reduce isdn4linux's memory  
requirements?  
<label id="trouble_littlememory">
<p>
Try to do the following things:
<itemize>
<item> Stick with kernel 2.0.x if you have a 486 or lower.
<item> In <tt>/usr/src/linux/include/linux/isdn.h</tt>, change the line
<code>
#ifdef CONFIG_COBALT_MICRO_SERVER
</code>
into:
<code>
#if 1
</code>
and recompile kernel.
<item> Reduce ISDN_MAX_DRIVERS, ISDN_MAX_CHANNELS in
<tt>include/linux/isdn.h</tt>, then recompile kernel.
</itemize>

<sect1> trouble_debug: How do I get maximum debug output?  
<label id="trouble_debug">
<p>
Execute the following commands to get maximum debug output:
<code>
hisaxctrl &lt;id&gt; 1 0x33ff
hisaxctrl &lt;id&gt; 11 0xf4f
killall isdnlog
cat /dev/isdnctrl > /tmp/ilog
</code>
Be careful: this will generate a lot of output!

<sect1> trouble_strategy: My isdn4linux doesn't work! How do I best go about  
finding the problem?  
<label id="trouble_strategy">
<p>
The following steps are recommended:
<enum>
<item>Check everything is working when booting.
Are there unusual error messages in /var/log/messages?
Are all programs active that should be started at boot (check with
ps, or fuser /dev/xxx)? HiSax won't start if something isn't right.
Check question <ref id="trouble_boot" name="trouble_boot"> for what you can check.
The old Teles driver, on the other hand, will appear to start even if
it is not working. See the questions under Troubleshooting Teles.
<item>Make sure you configured the ISDN driver either as modules, or you
compiled them into the kernel - never both.
<item>Try calling your dialin number with a telephone. The number should be
shown in <tt>/var/log/messages</tt>. Check for a line like this:
<code>
Call from 0,1,2345 -> 6789
</code>
This means that on channel 0 a call from 2345 with service indicator (SI) 1
(1 = voice; data would be 7) to MSN 6789 was received. Now at least you know
that you have to configure your MSN to 6789 (or whatever other number you
find there), and that your isdn4linux kernel driver understand ISDN
commands coming from your ISDN card properly. If instead of the number 2345
you find a 0, then your ISDN provider does not pass you the caller id.
If you don't find such a line: perhaps the driver was incorrectly started?!
<item>As a next step we'll try to get the telephone or fax to ring by dialing
ourself using a ttyI device with minicom. First we have to change the service
recognition with the <tt>ATS18=1</tt> command to audio. Now you can get the
telephone to ring by dialing <tt>ATDxxxxxx</tt>, where xxxxxx is your own MSN.
<item>Next we try to transmit data via ISDN. Open 2 different consoles as root,
and on each run &dquot;minicom -s&dquot;... in the first set &dquot;Serial Port
Setup Serial Device&dquot; to <tt>/dev/ttyI0</tt>, and the other to
<tt>/dev/ttyI1</tt>. Then choose &dquot;Exit&dquot; and start the modem
emulation with &dquot;ATZ&dquot; and &dquot;AT&amp;Exxxxxx&dquot; (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 &dquot;CALLER NUMBER: xxxxxxx&dquot; and
&dquot;RING&dquot;. Accept the call on the second console with
&dquot;ATA&dquot;, and you should then see the message &dquot;CONNECT
64000/X.75&dquot; 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).
<item>Next, try calling a known ISDN BBS. If you don't know of any, try
Gernot (see &dquot;Are there sites that offer guest access where I can test my
isdn4linux setup?&dquot;). If you have problems with the modem emulation, see
&dquot;Troubleshooting Modem Emulation&dquot;
<item>Fifth, try configuring the network interface or ipppd. Experience shows
that they cause beginners (and not only beginners!) the most problems.
To make things easier and you're happy with asyncPPP (to see what
asyncPPP means, see the question &dquot;pppd, ipppd, syncPPP, asyncPPP -
what is that? What should I use?&dquot;), you can use the normal pppd with
modem emulation (i.e. /dev/ttyI*).
<item>Ensure that you set up your authentication configuration properly (see
questions in section <ref id="pap" name="pap">.
</enum>
Otherwise, it is highly recommended that use an example script form
the HowTo (see the question &dquot;Where can I find scripts and other
information on configuring i4l?&dquot;). For testing you can try your own
provider or of the guest accounts (see &dquot;Are there sites that offer
guest access where I can test my isdn4linux setup?&dquot;).  The latter
have the advantage of being able to see the log files as well as a
stable, working configuration. For example, if accessing via ipppd
doesn't work, you can log in via modem or modem emulation to find
out what happened on the other side. Not all providers are so
cooperative.... :-)

<sect1> trouble_boot: How can I tell whether my ISDN card has been correctly  
recognized?  
<label id="trouble_boot">
<p>
<enum>
<item>Check for error messages in the boot messages (you can review them at any
time with the command <tt/dmesg/.

<item>For the HiSax driver: During booting a message <tt>kernel: HSCX version
A:5 B:5</tt> and <tt>kernel: channels 2</tt> should appear. <tt>A:4 B:4</tt> is
also okay. Other values (in particular <tt>A:??? B:???</tt>) 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).

<item> Check that your card got an interrupt assigned, e.g. with
<code>
lspci -v
</code>
A common problem is that your BIOS did not assign an interrupt to your
card. HiSax will then complain with "No IRQ for PCI card found".
To fix, set the BIOS option "PnP OS" to NO.

<item>Check that the interrupts are registered correctly. Check with
<code>
cat /proc/interrupts
</code>
The following entry indicates that the card is configured on interrupt 11, and
so far has received 3 interrupts:
<verb>
11:        3 + hisax
</verb>
When you call yourself, the number of received interrupts should increase.

<item>Check the io ports with
<code>
cat /proc/ioports
</code>
</enum>

<sect1> trouble_isdncause: I get an error message like "cause: E1234" (or  
similar)?  
<label id="trouble_isdncause">
<p>
Just have a look at <tt>man isdn_cause</tt> to find out what the problem is.
For the very popular cause "E001B" see question
<ref id="trouble_e001b" name="trouble_e001b">.

<sect1> trouble_e001b: I get an error message with "cause: E001B"?  
<label id="trouble_e001b">
<p>
This is a very popular error and means (see <tt>man isdn_cause</tt>):
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
<ref id="hardware" name="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 <ref id="config" name="config">).

<sect1> trouble_noprotocol: upon startup of HiSax I get the message  
&dquot;Warning - no protocol specified&dquot;?  
<label id="trouble_noprotocol">
<p>
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.

<sect1> trouble_euronotsupported: upon startup of HiSax I get the error  
"kernel hisax: protocol euro not supported"?  
<label id="trouble_euronotsupported">
<p>
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.

<sect1> trouble_unknownprimitive: upon connection attempt I get the error  
"lldata_handler unknown primitive"?  
<label id="trouble_unknownprimitive">
<p>
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:
<code>
isdnctrl l2_prot &lt;interface&gt; &lt;protocol&gt;
</code>

<sect1> trouble_notelrings: Neither my telephone nor my fax machine ring  
when I call them with isdn4linux?  
<label id="trouble_notelrings">
<p>
Isdn4linux sets &dquot;digital data&dquot; 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.

<sect1> trouble_guestaccess: Are there sites that offer guest access where I  
can test my isdn4linux setup?  
<label id="trouble_guestaccess">
<p>
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:
<itemize>
<item>Eberhard Moenkeberg <tt><htmlurl url="mailto:emoenke@gwdg.de"
name="emoenke@gwdg.de"></tt>:
<itemize>
<item>Welcome to Linux at eberhard.moenkeberg.de (LAN, 192.168.99.1).
Under ++49-551-7704103, ISDN NetCalls (HDLC-trans-rawip)
for 192.168.99.1 get accepted. You should come as 192.168.*.*
because sometimes my &dquot;default&dquot; route is not your way.
/ftp is exported for NFS; try &dquot;showmount -e&dquot;.
You can login as &dquot;guest&dquot; without password.
FTP as &dquot;gast&dquot; with password &dquot;gast&dquot; avoids the
restricted shell.
<item>Under ++49-551-7704102, a 28800 bps modem and a Creatix ISDN
card (HDLC only, not X.75) are listening for logins.
<item>With the net setup from
<tt><url url="ftp://ftp.gwdg.de/pub/linux/isdn/isdn4linux-gwdg/rc.isdn-Beispiel"></tt>
you can test NetCall at 551-7704103 (works as is within Germany,
from outside Germany you just have to change the number).
</itemize>

<item>Gernot Zander <tt><htmlurl url="mailto:hifi@scorpio.in-berlin.de"
name="hifi@scorpio.in-berlin.de"></tt>:
<quote>
There's a &dquot;gast&dquot; 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.
</quote>
</itemize>

<sect1> trouble_unload: I can't unload my ISDN modules (&dquot;isdn: Device or  
resource busy&dquot;), even so I closed all ISDN applications?  
<label id="trouble_unload">
<p>
In this case &dquot;fuser -v /dev/isdn* /dev/ippp* /dev/cui* /dev/ttyI*&dquot;
is very helpful. This helpful program shows, which processes are using those
devices.
<itemize>
<item>Is some program still using an ISDN device?
<item>Did you remove all getty's? (They may have restarted automatically)
<item>Are isdnlog, imon, iprofd, etc., still running?
<item>Maybe there is still a route on your net interface and it's not yet
deleted with &dquot;route del xxx&dquot;?
<item>Maybe the net interface wasn't put down. This can easily happen when
killing ipppd. It does not react to signal 15 and has to be killed with
&dquot;kill -9 ipppd pid&dquot;. Then the net interface is left
&dquot;up&dquot;.
</itemize>
Sporadic errors of this type can be fixed by inserting sleep commands
between the unloading commands.
As a very, very last resort, there are two secret telesctrl commands to adjust
the module counter:
<code>
telesctrl id 3 1  --- dec module_count
telesctrl id 4 1  --- inc module_count
</code>
Please use with appropriate caution and on your own risk!


<sect1> trouble_tcpdump: Why does my tcpdump not work for ip packets going  
over ISDN (&dquot;truncated ip&dquot; or so)? How can I get a tcpdump  
patched for ISDN?  
<label id="trouble_tcpdump">
<p>
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.

Michael Stiller <tt><htmlurl url="mailto:michael@toyland.ping.de"
name="michael@toyland.ping.de"></tt> wrote on 23 Oct 1996:

Tip for ftp:

<tt><url url="ftp://ftp.gwdg.de/pub/misc/isdn/linux/isdn4linux-gwdg"></tt>

There is the patch: &dquot;tcpdump-3.0.4-1-isdn.dif.gz&dquot;

and the rest is at:

/pub/linux/mirrors/funet/PEOPLE/Linus/net-source/tools/tcpdump-3.0.4-1.tar.gz

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.

Henning Schmiedehausen <tt><htmlurl url="mailto:henning@pong.iconsult.com"
name="henning@pong.iconsult.com"></tt> further wrote on
30 Oct 1996:
<quote>
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
</quote>
<tt><url url="ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/tools"></tt>
<quote>
This patch recognizes rawIP, ISDN-IP and CISCO-HDLC and can
dump these packets.
</quote>
(The patch was attached to the message  - it should be easy to find in the
mailing list archive - Ed.)

Sascha Ottolski <tt><htmlurl url="mailto:sascha@alzhimer.isdn.cs.tu-berlin.de"
name="sascha@alzhimer.isdn.cs.tu-berlin.de"></tt> gave the following
tip on 5 Nov 1996:
<quote>
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(&dquot;ppp&dquot;, device, 3) == 0)
Either you name your ppp devices pppX instead of ipppX, or
change this line, e.g.
else if (strncmp(&dquot;ippp&dquot;, device, 4) == 0)
^^^^          ^^
Then tcpdump will also recognize syncPPP. At least it does for me.
</quote>

<sect1> trouble_locatecrash: My isdn driver crashes my machine! Since I've  
configured it as a module, the addresses change each time it's loaded. How can  
I find out where the driver is crashing?  
<label id="trouble_locatecrash">
<p>
The driver should be loaded with the command &dquot;insmod -m&dquot;. The output
has to be transformed somewhat to be a form similar to System.map. You can do
it like this:
<code>
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
</code>
(The line ending with &dquot;|&dquot; has to have the following text on
the same line!) iSystem.map should then be used instead of System.map for
finding the error.

<sect1> trouble_lotsdebug: My hard disk becomes very active when isdn4linux  
run. How can I turn this off?  
<label id="trouble_lotsdebug">
<p>
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:
<code>isdnctrl verbose 0
</code>
and/or by removing the &dquot;debug&dquot; option for ipppd.

<sect1> trouble_oldhardware: Maybe my hardware is too slow?  
<label id="trouble_oldhardware">
<p>
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 <ref id="trouble_outofbuffers" name="trouble_outofbuffers">
when running out of buffers.
See question <ref id="trouble_littlememory" name="trouble_littlememory"> on how to reduce the amount of
memory needed.

<sect1> trouble_outofbuffers: I get messages like &dquot;HSCX RME out of  
buffers&dquot;, &dquot;HSCX RFP out of buffers&dquot;, &dquot;HSCX B EXIR  
10&dquot; in the syslog?  
<label id="trouble_outofbuffers">
<p>
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 <tt/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:
<code>
&num;define HSCX_RBUF_ORDER 1
&num;define HSCX_RBUF_BPPS 2
&num;define HSCX_RBUF_MAXPAGES 3
</code>
The first two influence the size, the last one the maximum number of buffers.

<sect1> trouble_noresetinit: After a soft reset, my card does not initialize  
correctly.  
<label id="trouble_noresetinit">
<p>
After you stopped your system with the <tt/reboot/ command or with
<tt/Ctrl-Alt-Del/, press the reset button (=hard reset). Sometimes the card
needs to receive a hardware signal to reinitialize properly.


<sect1> trouble_noisdnctrl: When attempting to use isdnctrl, I get the  
error &dquot;/dev/isdnctrl: No such file or directory&dquot;?  
<label id="trouble_noisdnctrl">
<p>
First check whether there is a device /dev/isdnctrl0. If there is, just
create a symbolic link by executing
<code>
ln -s /dev/isdnctrl0 /dev/isdnctrl
</code>
If the device is not there, run the script <tt>scripts/makedev.sh</tt>,
which is part of the isdn4k-utils.


<sect1> trouble_noisdnctrl2: When attempting to use isdnctrl, I get the  
error &dquot;/dev/isdnctrl: No such device&dquot;?  
<label id="trouble_noisdnctrl2">
<p>
In contrast to &dquot;/dev/isdnctrl: No such file or directory&dquot; the
message &dquot;/dev/isdnctrl: No such device&dquot; indicates that the
device /dev/isdnctrl exists, but no ISDN device driver is available.
To fix, load the ISDN modules (verify with &dquot;cat /proc/modules&dquot;
that they are loaded) or compile the ISDN drivers into the kernel.


<sect1> trouble_xosview: xosview doesn't show any network activity since  
installing i4l.  
<label id="trouble_xosview">
<p>
Peter Hettkamp <tt><htmlurl url="mailto:Peter.Hettkamp@kassel.netsurf.de"
name="Peter.Hettkamp@kassel.netsurf.de"></tt> wrote:
<quote>
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.)
</quote>

<sect1> trouble_unknownhost: When I for example from a W95 box call up a page  
with Netscape, I only get the answer &dquot;unknown host&dquot;.  
<label id="trouble_unknownhost">
<p>
What is entered on the &dquot;Win95 box&dquot; 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.

<sect1> trouble_noroute: Addresses are now found, but now I get &dquot;no route  
to host&dquot;.  
<label id="trouble_noroute">
<p>
Please check:
<itemize>
<item>Is the Linux computer entered as the gateway? (Some 'operating systems'
have to be restarted before changes to the networking take effect)?
<item>Does the router have a default route to the prepared interface to the
provide (e.g. ippp0 with syncPPP or sl0 for diald (even when the real
connection is over ppp0, diald uses a slip interface as a &dquot;doorknob&dquot;)
<item>Does the provider require the use of proxies? Then the addresses
of the proxies have to the entered in the appropriate clients on the LAN
computers
<item>Maybe your route was removed when using syncppp? Check the questions
<ref id="syncppp_noroute" name="syncppp_noroute"> and
<ref id="syncppp_nodefaultroute" name="syncppp_nodefaultroute">.
</itemize>

<sect1> trouble_nolocalnet: After booting, my local network can no longer be  
reached. I use the network interface ippp0 with ifconfig 0.0.0.0; the default  
route points to ippp0.  
<label id="trouble_nolocalnet">
<p>
Wolfgang Barth wrote on 5 Jan 1997:
<quote>
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.
</quote>

<sect1> trouble_unauthorizedcodechange: When HiSax starts, I get the  
error messages 'Approval certification failed, unauthorized source code  
changes'?  
<label id="trouble_unauthorizedcodechange">
<p>
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).

<sect1> trouble_crcerror: How can I see the number of packets for HiSax with  
invalid CRC?  
<label id="trouble_crcerror">
<p>
With HiSax you can view the accumulated number of hardware CRC errors with:
<code>
hisaxctrl &lt;id&gt; 0 0
</code>
and reset them with:
<code>
hisaxctrl &lt;id&gt; 0 99
</code>
It is ok if you have the occasional CRC error, but if you see a lot of
errors then check your cable termination & connectivity.


<sect1> trouble_amproglibtool: When compiling isdn4k-utils I get the  
error 'AM_PROG_LIBTOOL not found'?  
<label id="trouble_amproglibtool">
<p>
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):
<code>
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
</code>

<sect1> trouble_hisaxparams: HiSax does not work - how can I set the  
HiSax parameters for newer Linux kernels?  
<label id="trouble_hisaxparams">
<p>
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:
<code>
rmmod hisax
</code>
then insert the kernel module with the correct parameters again, e.g.:
<code>
modprobe -v hisax type=35 protocol=2
</code>
In case this solves the issue, you can permanently fix it by providing the
needed parameters to the module loader, e.g. in /etc/modprobe.d/hisax on
a Suse distribution.


<!-- Config MSN
-->

<sect> msn: Configuration/MSNs  
<label id="msn">

<sect1> msn_my1: What is my MSN? What if I don't have any?  
<label id="msn_my1">
<p>
Your telephone company will tell you your MSN. It is your own telephone
number. Please note that you <bf/have/ to provide i4l with at least one MSN. If
you don't have any you can use `0', which is assumed if no MSN is transmitted
from your telephone company. Check section <ref id="countries"
						name="countries">, together
with the following questions, on how to configure your MSN(s).

<sect1> msn_my2: How can I find out how my telephone number is transmitted  
to the calling party?  
<label id="msn_my2">
<p>
The transmitted MSN can simply be determined by calling yourself
(for example by telephone). In the log files you will find the
entry that looks like: &dquot;isdn_tty: call from XXX - YYY ignored&dquot;
(in order for this to work, you must of course already have the ISDN
drivers in your kernel and active).

<sect1> msn_config: How do I configure my MSN?  
<label id="msn_config">
<p>
If your telephone number were 56789, then it would be configured as follows:
<itemize>
<item>Modem emulation: <tt>&dquot;AT&amp;e56789&dquot;</tt>
<item>Network interfaces: <tt>&dquot;isdnctrl msn interface 56789&dquot;</tt>
<item>For test calls to yourself add the area code (e.g. 01234):
<code>
&dquot;isdnctrl addphone interface in 123456789&dquot; (without leading zero)
&dquot;isdnctrl addphone interface out 0123456789&dquot; (with leading zero)
</code>
</itemize>
You may find national differences here (check section <ref id="countries"
							   name="countries">).


<sect1> msn_max: How many MSNs as a maximum can I use for an isdn card?  
<label id="msn_max">
<p>
For outgoing calls, at maximum one MSN can be used. Only incoming calls
may be configured to allow multiple MSNs.

For ttyI* devices, at a maximum you can listen to EVERY incoming MSN by
using the * as a wildcard:
<code>
at&amp;l*
</code>

When you have a point-to-point connection you should rather specify the
length of your number area with as many times &dquot;?&dquot; as you
have digits, otherwise your number may be accepted too early on overlapping
receiving. I.e. for 3 digits use:
<code>
at&amp;l???
</code>

For network devices, you can also use a '*' as a wildcard at the end of the
number for incoming calls (e.g. <tt>isdnctrl msn interface 123*</tt>).
However, this will create problems for outgoing calls. To handle such
a situation properly, please use the isdnctrl mapping feature
(see question <ref id="dialout_manycards" name="dialout_manycards">).


<sect1> msn_mindialin: How can I minimize usage of MSNs for digital data dialin?  
<label id="msn_mindialin">
<p>
i4l gives priority to net interfaces. Therefore, you can get away with only
one MSN when you set it up like this:
<enum>
<item>Set up net interfaces (sync ppp, rawip) for all users that will want to
use them (ipppd or rawip), with their incoming phone number (precondition is
that it is transmitted).
<item>Set up ttyI* for all other users (X.75, async ppp).
<item>Set option `secure on'.
</enum>
i4l gives priority to net interfaces. `secure on' ensures that only users
that have been set up will be connected to a net interface. Users that want
to choose between both will have to use different outgoing MSNs to call you.

<sect1> msn_onlyone: How can I use one MSN for everything?  
<label id="msn_onlyone">
<p>

In Germany, this is not much of an issue any more since you can get
10 MSN for free with Deutsche Telekom
(<url url="http://www.dtag.de/english/">). Other phone providers may offer
less MSN for free. In general, you can get at least 3 MSN. However,
minimizing MSN usage may still be very interesting for other countries
or if you have a large demand for numbers. On a normal ISDN bus with MSNs,
10 MSN per bus are the maximum. To get more numbers, your only alternative
would be to get a usually more expensive point-to-point ISDN connection.

Digital data dialin can easily be distinguished from voice/analog modem
dialin by the 'Service Recognition' code (&dquot;digital, data&dquot;).

For the differentiation between net interfaces (ipppd, rawip) and ttyI*
(X.75) see last question.

To get voice/analog modem to work in parallel, use mgetty for the analog
modem. Mgetty can handle analog data calls, faxes, and even voice calls as
answering machine if the modem supports it. Configure it for 10 rings. If
you take the phone and hear a fax or modem, send mgetty a USR1 signal (kill
-USR1 mgetty-pid). If your phone socket is correctly wired, the modem will
take over the connection, cutting off the phone. If you have an ISDN PBX
then you can forward the call to a different analog port when you picked up
a fax/modem call.

If your analog modem can not handle voice calls, then you have to
choose since incoming voice calls can not be distinguished from analog
fax/data calls. Use either VBOX to take your voice calls as an answering
machine. Or forget about voice calls and set up your modem to handle only
faxes and/or analog data calls.

<sect1> msn_buendel: Can I have several NTBAs, all with the same MSN?  
<label id="msn_buendel">
<p>
Yes, but you need the cooperation of your telecommunication company. They
can set up several BRIs in Point-to-point mode that have the same MSN. In
Germany it is called a bundled line (`B&uuml;ndelanschlu&szlig;').

Please note that in such a case the MSN may not be transmitted to you. Just
use the default MSN 0 then.


<sect> lan: ISDN4LINUX in a LAN  
<label id="lan">

<sect1> lan_config: How can I set up Linux so that other computers in my LAN can  
access the internet via my Linux computer?  
<label id="lan_config">
<p>
There are several possibilities:
<enum>
<item>Your LAN is an official Class C net with IP addresses valid on the Internet.
This case is the easiest of configure. You give each network card on your
network one of these addresses and set a default route on the ISDN card that
goes to your provider.
<item>You'd only like to do http in Internet from your LAN. In this case you
can make up IP addresses for your LAN; the only official IP address is that for
your ISDN card. Then install a proxy server on your Linux router, and enter it
in all of your browsers. In this case you do not need a default route.
<item>From your LAN you only want to log in to your Linux ISDN router and FROM
THERE do your work on the Internet. This is even simpler, then you don't even
need a proxy server.
<item>Use ip masquerading. This is the most comfortable one to use, but more
difficult to set up. The Linux computer acts as a gateway. The trick is that it
hides the ip addresses of the LAN, by giving its own internet address as
response address. When receiving the response, it will forward it to the
correct computer on the LAN. You can also use masquerading with dynamic ip
addresses. If you don't want to start the ISDN connection from the Linux
computer to your internet provider manually, then you can set up dial on demand
functionality (see section <ref id="dod" name="dod">).
</enum>

<sect1> lan_modemserver: How can forward ISDN data from a local computer in  
my LAN to the ISDN card(s) in my Linux PC (like a modem server)?  
<label id="lan_modemserver">
<p>
On the Linux PC you have to install a forwarding server.
One option is to use <tt>modemd</tt>. This is a very short perl script
(also see Linux Modem sharing mini-HOWTO at
<tt><url url="http://www.linuxdoc.org/HOWTO/mini/Linux-Modem-Sharing.html"></tt>):
<code>
&num;!/usr/bin/perl
select((select(STDOUT), &dollar;| = 1)[&dollar;[]);
select((select(STDIN), &dollar;| = 1)[&dollar;[]);
exec &dquot;cu&dquot;,&dquot;-E&dquot;,&dquot;''&dquot;, &dquot;-l&dquot;, &dquot;&dollar;ARGV[0]&dquot;;
die &dquot;&dollar;0: Cannot exec cu: &dollar;!\n&dquot;;
</code>
It has to be started by inetd, therefore this has to be added to
<tt>/etc/services</tt>:
<code>
modem           20006/tcp       modemd  &num; Modem service via TCP
isdn            20007/tcp       modemd  &num; ISDN  service via TCP
</code>
And this has to be added to <tt>/etc/inet.conf</tt>:
<code>
modemd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/modemd ttyI5
</code>

Instead of modemd you can also use the program <tt>mserver</tt>, which has
some additional functionality (e.g. rights based on ip address):
<tt><url url="ftp://ftp.innet.be/pub/staff/carl/"></tt>

Additionally, you need some software on your non-ISDN computer which emulates a
serial port, but redirects it via telnet to the Linux ISDN computer.
Some telnet clients allow this functionality (e.g. some uucicos).
If you generally want to offer all applications a kind of &dquot;remote COM
port&dquot;, then there is COMT for Windows (95), and
&dquot;telser.device&dquot; for Amigas. Disadvantage of COMT: it is only
visible to ancient 16bit Win applications, and not even working in the DOS box.
Another program is DialOut/IP, but it's fairly expensive ($70).

COMT may be found on Simtel:
<tt><url url="http://educom.sce.fct.unl.pt/ftp/pub/shareware/win-utils/comt2.zip"></tt>

DialOut/IP can be found on:
<tt><url url="http://tacticalsoftware.com"></tt>

Those who just want to save their CrossPoint installation should be aware that
it now offers tcp modem support, such that it will run without additional
software. Check out:
<tt><url url="http://www.openxp.de"></tt>

<sect1> lan_remotedialing: How can I allow the users in my LAN to trigger  
a dial out via   the ISDN card(s) in my Linux PC?  
<label id="lan_remotedialing">
<p>
For this you need two pieces of software. At the computer where the ISDN-line
is connected you need to install a <tt>dial daemon</tt>. The dial daemon
will execute any dial commands given from a <tt>dial frontend</tt> located on
a different computer on the LAN. You have several options to choose a dial
daemon and dial frontend.
<enum>
<item>
At first you can use the free software <tt>smpppd</tt> (SuSE Meta PPP
Daemon) from SuSE as the dial daemon. smpppd gets used in the SuSE distribution
for all ISDN, Modem and DSL connections. You can connect to smpppd locally or
over a LAN via different dial frontends and trigger dial-out, hang-up and so
on. The most known dial frontend is kinternet a small applet for the KDE
Kicker. Others are the qt-only qinternet and the command line tool cinternet.
Unfortunately there is no frontend for Windows or Mac OS available.

Obviously this is the easiest way if you already have SuSE installed on the
server, and all other involved computers are also based on Linux (installation
of the dial frontend should not be too difficult with non-SuSE distributions).
Some more hints:
<itemize>
<item>The software is available in SuSE-Linux within the packages smpppd,
kinternet and qinternet, see <url url="http://www.opensuse.org">
<item>In order to allow smpppd listening into the LAN change the following
two options in /etc/smpppd.conf (see also "man smpppd.conf"):
<code>
open-inet-socket = yes # (default is no)
bind-address = &lt;IP&gt; # IP of the LAN-network-card of the dial in server;
# default is listening on all network cards (!)
</code>
<item>On the client side you can either enter the dial server via GUI or via
/etc/smpppd-c.conf (see also "man smpppd-c.conf").
</itemize>
<item>
Another free software solution working the same way is <tt>LineControl</tt>.
It has a dial daemon (linesrv) which you can configure dialing different
connections (similar to smpppd) be it ISDN, Modem, DSL or another dial-out
connection. Dial frontends are available for Linux (one for KDE and one for
Gnome), Windows and Java.
Some more hints:
<itemize>
<item>The software and tutorials can be found at
<url url="http://linecontrol.srf.ch/">
<item>The config files is located at <tt>/etc/linesrv.conf</tt>
(the relevant configuration options are similar to that of smpppd)
<item>Several dial and hang up scripts where you can define the system
commands how to dial/hang up certain connections are below
<tt>/etc/linesrv/</tt>
<item>In order to have the linesrv daemon running at system start of your
server you also need to enter it in your system start configuration.
<item>On the client side you now can enter the dial server via GUI in one of
the frontends and dial/hang up a connection configured at the server.
</itemize>
</enum>


<!-- Dialout
-->

<sect> dialout: Configuration of Dial-Out  
<label id="dialout">

<sect1> dialout_config: How do I configure dialout properly?  
<label id="dialout_config">
<p>
First you have to decide on how you want to dial out. You will have to
use whatever your counterpart requires. These are your main options:
<itemize>
<item> Sync PPP: This is what most Internet Service Provider expect
from you. See section <ref id="syncppp" name="syncppp">.
<item> Async PPP: May also be handled by your Internet Service
Provider. Use when Sync PPP does not work for you. See section
<ref id="asyncppp" name="asyncppp">.
<item> Raw IP: Most efficient for TCP/IP over ISDN. It has very quick
dialouts, but is not as common. See section <ref id="rawip" name="rawip">.
<item> X.75: This is what you need to dial into an ISDN mailbox. See
section <ref id="ttyI" name="ttyI">.
<item> Leased line: For this special case, see section
<ref id="leased" name="leased">.
</itemize>

Have a look on section <ref id="dod" name="dod"> on how to configure dial on
demand - and on the dangers attached to it.

For more advanced dialout features see question
<ref id="dialout_advanced" name="dialout_advanced">.

Also you may have a look at section <ref id="remote" name="remote">
when you try to connect to a special remote ISDN device.

<sect1> dialout_dialmode: When an IP packet should go over the link (which  
usually triggers a dialout), all I see in the log is: &dquot;dial rejected:  
interface not in dialmode <tt/auto/&dquot;?  
<label id="dialout_dialmode">
<p>
The new ISDN drivers in 2.0.36 defaults to manual dialmode, not
autodial. This is done to prevent unexpected (and unnoticed) dialouts.
(See the big section about those and their dangers: <ref id="dod" name="dod">).
To enable autodial for a given interface e.g. ippp0, use
<code>isdnctrl dialmode ippp0 auto</code>

The meaning of the values for dialmode is:
<descrip>
<tag/off/
means that you (or the system) cannot make any connection
(neither incoming nor outgoing connections are possible). Use
this if you want to be sure that no connections will be made.

<tag/auto/
means that the interface is in auto-dial mode, and will
attempt to make a connection whenever a network data packet needs
the interface's link. Note that this can cause unexpected dialouts,
and lead to a high phone bill! Some daemons or other pc's that use
this interface can cause this.
Incoming connections are also possible.

<tag/manual/
(DEFAULT) is a dial mode created to prevent the unexpected dialouts.
In this mode, the interface will never make any connections on its
own. You must explicitly initiate a connection with:
<code>isdnctrl dial ippp0</code>
To end the connection, use:
<code>isdnctrl hangup ippp0</code>
Please note that the <tt/huptimeout/ may still end the connection
automatically! To ensure that you have to hang up manually, you have to switch
this off:
<code>isdnctrl huptimeout ippp0 0</code>
</descrip>

To allow a normal user to initiate a dialout, have a look at question
<ref id="dialout_permission" name="dialout_permission">.

<sect1> dialout_advanced: What special dialout features are available?  
<label id="dialout_advanced">
<p>
Check out these special dialout features:
<itemize>
<item> Save money by hanging up just before a charge unit:
see section <ref id="chargeint" name="chargeint">.
<item> Dialout on more than 1 channel at the same time:
see section <ref id="2channel" name="2channel">.
<item> Dialout on one specific channel:
see question <ref id="dialout_fixedchannel" name="dialout_fixedchannel">.
<item> Callback:
see section <ref id="callback" name="callback">.
</itemize>

<sect1> dialout_permission: How can I allow a normal user to initiate dialouts?  
<label id="dialout_permission">
<p>
ISDN usage depends on the permissions to the devices <tt>/dev/ttyI*</tt> and
<tt>/dev/cui*</tt>. You have several choices to selectively allow users to do
ISDN transactions.
<enum>
<item>You can establish the group `isdn' in <tt>/etc/group</tt>, and do:
<code>
chgrp isdn /dev/ttyI* /dev/cui*
chmod o-rw /dev/ttyI* /dev/cui*
</code>
It has been reported that you also may have to change group and
permissions on the programs <tt/ipppd/ and <tt/isdnctrl/ to 'isdn'.
Then all users not in the group 'isdn' have no reading or writing
privileges for the ISDN ttys. Those allowed to use ISDN have to be
explicitly added to the group 'isdn'.
<item>You can allow only root to log out, but set up exceptions for other users
with the su1 functionality (see man su1). As root edit
<tt>/etc/su1.priv</tt>. Add these lines if they (or similar ones) are not yet
there, to allow users XXXX and YYYY to initiate dialups/hangups:
<code>
# log all dialouts in syslog
syslog all
define PPPUSER XXXX YYYY
alias dial /sbin/isdnctrl dial ippp0
alias hangup /sbin/isdnctrl hangup ippp0
ask never
allow PPPUSER prefix dial
allow PPPUSER prefix hangup
</code>
Then create two links for dial and hangup:
<code>
ln -s /usr/bin/su1 /usr/local/bin/dial
ln -s /usr/bin/su1 /usr/local/bin/hangup
</code>
Now the users XXXX and YYYY can dial out by typing <tt/dial/, and hangup with
<tt/hangup/.
<item>isdnctrl can be set SETUID root. Please not that if it is called by a
user different from root, isdnctrl will only allow you to dialin/hangup,
and addlink/removelink/show. However, the setup/configuration data can only be
modified by root.
<item>If you only have one user that you use for ISDN interactions, you can
make him owner of the ISDN interface.
</enum>

<sect1> dialout_manycards: How do I configure dialout with more than 1 ISDN  
card?  
<label id="dialout_manycards">
<p>
There are several possibilities to configure dialout.
<itemize>
<item>Dialout anywhere (default: all available cards are a pool, dialout
on one MSN):
just configure your cards in the order in which you want them to be dialed out.
First all channels on the first card are used, then all on the second card,
and so on. Please note that the net interface or ttyI device will try to
dial out using the MSN it was configured for - on all cards. Even on those
that do not have this MSN! In such a case, the telco will replace that
invalid MSN with the correct one. Use <tt/isdnctrl mapping/ to configure the
correct MSNs (see item 'dialout on one specific card').
<item>Dialout on one specific channel: Use the <tt/isdnctrl bind/
(not pppbind) command to specify which channel should be used.
Please use this command after all other configuration with isdnctrl has
been done! Check with <tt/isdnctrl list/ that the binding actually works.
<item> Dialout with different MSN on each card:
You can configure this by using the <tt/isdnctrl mappping/ functionality.
Just map MSNs on the letters 0 to 9, like this:
<code>
isdnctrl mapping &lt;carddriver1&gt; 111,222,333,,
isdnctrl mapping &lt;carddriver2&gt; 999,888,,777
</code>
Now, you could configure for telephone number 0 when you really want to use
MSN 111 on &lt;carddriver1&gt; or 999 on &lt;carddriver2&gt; (however, since
0 has a special meaning, try to avoid using number 0). Configure to use
number 1 when you really want to use MSN 222 on &lt;carddriver1&gt; or 888
on &lt;carddriver2&gt;. Configure to use telephone number 2 when you really
want to use only MSN 333 on &lt;carddriver1&gt; (&lt;carddriver2&gt; will
use the default MSN when used). Configure to use telephone number 3 when you
really want to use only MSN 777 on &lt;carddriver2&gt; (&lt;carddriver1&gt;
will use the default MSN when used).
<item>Dialout on one specific card:
After installing a patch that was posted by Karsten Keil on the mailing
list against 2.2.12, you can disallow calls on some cards by using the
<tt/isdnctrl mapping/ functionality.
<code>
isdnctrl mapping &lt;carddriver1&gt; 111,222,333,-,
isdnctrl mapping &lt;carddriver2&gt; 999,888,-,777
</code>
It works as discribed for "Dialout with different MSN on each card", except
that the "-" means dialing is disallowed. Dialout on telephone number 2 will
now only dial out with MSN 333 on &lt;carddriver1&gt;, while dialout on 3 will
now only dial out with MSN 777 on &lt;carddriver2&gt;.
</itemize>

<sect1> dialout_fixedchannel: How can I force HiSax to always dial out on  
a specific B channel?  
<label id="dialout_fixedchannel">
<p>
HiSax has an undocumented feature for this. Add 'P1' in front of the dialout
phone number for the first B channel, or 'P2' for the second B channel, like
this:
<code>
isdnctrl addphone &lt;device&gt; out P1&lt;your_out_number&gt;
</code>
This will indicate the preferred B channel in the outgoing SETUP message.
Please note that some PBX may not like this.
Obviously, a dialout will fail when another device already uses
the second B channel.

<sect1> dialout_dynip: On dynamic ip assignment, how do I find out which ip  
address is being used for dialout?  
<label id="dialout_dynip">
<p>
Create a script called <tt>ip-up</tt>. It will be called by the ipppd
whenever the connection is established with several parameters.
The ip address is passed in as the fourth parameter (access it as <tt>$4</tt>).

<sect1> dialout_bind: A dns query causes bind to dial out. Why does it take  
about a minute before it is answered? How do I work around it?  
<label id="dialout_bind">
<p>
You are probably using the name server in 'forward' mode, and your ISP works
with dynamic ip addresses. The initial UDP query will be lost since it
carries the wrong source address. Unfortunately, bind will wait a whole minute
before retransmitting the query again if you have only one forwarder.

As a workaround, you can enter 4 times the same forwarder in named.conf
to adjust retransmission timing (in 'forward' mode, bind retransmits its
queries after the following period of time: 60 seconds divided by the number
of nameservers given in the section "forwarders" of named.conf).
<code>
forwarders { 10.0.0.40; 10.0.0.40; 10.0.0.40; 10.0.0.40; }
</code>
Bind will then retransmit the query every 15 seconds to your forwarder
(here the forwarder is 10.0.0.40).
The same principle applies to two or more forwarders.

Another option are the programs <tt/ip_resend/ and <tt/ip_resend_wakeup/
which you can find on:
<url url="http://www.baty.hanse.de/ip_resend/">


<!-- Authenticate properly
-->
<sect> pap: Authenticate properly (especially with PAP)  
<label id="pap">

<sect1> pap_optionauth: When dialing out, I get the message &dquot;pppd: peer  
authentication required but no authentication files accessible.&dquot;  
What does this mean?  
<label id="pap_optionauth">
<p>
Most likely the option &dquot;auth&dquot; was set by mistake. Then the
<em>other</em> side is required to be authorized.

<sect1> pap_requestauth: I cannot establish a connection -  it's rejected by the  
other side. In the log file I find a message that's something like: &dquot;sent  
(0) (LCP ConfReq id=0x1 mru 1500 auth pap magic 0xcd12e9c4&dquot;  
<label id="pap_requestauth">
<p>
Like in the last question, an option has been set that requires the
<em>other</em> side to be authorized. These options shouldn't be set.
Possible candidates are: &dquot;+pap&dquot; as well as &dquot;+chap&dquot;.

<sect1> pap_rejectauth: I cannot establish a connection -  it's rejected by the  
other side. In the log file I find a message that's something like:  
&dquot;sent (0) (LCP ConfRej id=0x1 auth pap&dquot;  
<label id="pap_rejectauth">
<p>
Your computer is refusing to identify itself with user name (e.g. XXX)
and password (e.g. YYY). That only works with the authorization options
&dquot;user XXX&dquot; and &dquot;remotename YYY&dquot; for ipppd or pppd
together with a correct (!) /etc/ppp/pap-secrets. With a password of ZZZ it
should ideally look like this:
<code>
XXX YYY ZZZ *
</code>
If you have special characters in XXX, YYY, or ZZZ, try to use quotes
around them. If that doesn't work for getting XXX or YYY correct, you can
use wild cards, something like:
<code>
* * ZZZ *
</code>
Then <em>every</em> partner has the password ZZZ. If chap is required
for authorization, then /etc/ppp/chap-secrets must be set up correctly.
Important: the format is different from that of pap-secrets!
One important point is to use only the tabulator instead of space to
separate username, computer, password.
Make sure to consult the README's, or check out:
<tt><url url="http://www.lrz-muenchen.de/&tilde;ui161ab/www/isdn/"></tt>
Also have a look at the next question: <ref id="pap_passwd" name="pap_passwd">.

<sect1> pap_checkpwd: How can I check which password is actually sent to  
the remote side?  
<label id="pap_checkpwd">
<p>
Use the options <tt/debug/ and <tt/+pwlog/ for ipppd or pppd. Then you can
see your password in the log file.

<sect1> pap_passwd: I have problems with PAP or CHAP authentication. It does  
not work although I'm sure I entered passwords etc. correctly.  
<label id="pap_passwd">
<p>
Stefan A. Muehlenweg <tt><htmlurl url="mailto:Stefan.A.Muehlenweg@samhh.hanse.de"
name="Stefan.A.Muehlenweg@samhh.hanse.de"></tt> wrote on
4 Oct 1996:
<quote>
I had exactly the same problem/the same error message. The cause for it
was that I had three entries in chap-secrets/pap-secrets (for client,
server, secret), but not a fourth one (IP addresses). BUT: after the third
entry were some BLANKs. After removing the trailing BLANKs and/or TABs
(i)pppd is now very satisfied with my auth-files.
</quote>
A further source of problems can be the password itself. If it contains
the &dquot;&num;&dquot; character, then everything after than is understood as a
comment. Spaces or tabs can cause similar problems. Solution: put
the password in quotes!


<!-- Config Sync PPP
-->

<sect> syncppp: Sync PPP  
<label id="syncppp">

<sect1> syncppp_whichppp: pppd, ipppd, syncPPP, asyncPPP .. what is they?  
Which should I use?  
<label id="syncppp_whichppp">
<p>
See this question in the <em/asnyc PPP/; section:
<ref id="asyncppp_whichppp" name="asyncppp_whichppp">.


<sect1> syncppp_compile: How do I compile isdn4linux with syncPPP?  
<label id="syncppp_compile">
<p>
To compile the kernel with syncPPP included in ISDN4Linux, you have to answer
the appropriate questions with &dquot;yes&dquot;. Don't forget to load the
module slhc.o before isdn.o, if VJ compression is not compiled into the kernel
e.g. if you have no PPP and no CSLIP in the kernel. (Note that the use of VJ
is problematic for elder kernels and does not work reliably - however, the
support should still be included in the kernel, since there can otherwise
be side effects.)

<sect1> syncppp_netinterface: How should I name my network interface?  
<label id="syncppp_netinterface">
<p>
The name of the network interface should <em>always</em> begin with
&dquot;ippp&dquot;, <em>not</em> with &dquot;syncppp&dquot; or
&dquot;isdn&dquot;; otherwise the communication with ipppd will not work
correctly. Please note that at least one of the interfaces has to be
&dquot;ippp0&dquot;, otherwise ipppd will not start. Check your
interfaces with the command <tt>ifconfig</tt>.

<sect1> syncppp_config: How do I configure isdn4linux with syncPPP?  
<label id="syncppp_config">
<p>
Synchronous PPP is simply another encapsulation for ISDN4Linux. This
encapsulation is called &dquot;syncppp&dquot;. Here is an example to
configure the link level device ippp0:
<code>
/sbin/isdnctrl addif ippp0
/sbin/isdnctrl encap ippp0 syncppp
</code>
Please note that syncppp is very peculiar about the names of the device.
Only devices starting with &dquot;ippp&dquot; will work, at least one
interface has to be named ippp0 (see question <ref id="syncppp_netinterface" name="syncppp_netinterface">
for details).
All ippp* devices in use must be configured separately. Each ippp* device
should be assigned to its own IP address (routing!). Several ippp* devices can
be assigned to a single MSN. Several callers can then simultaneously use
this MSN.

To use these devices you need the program <tt/ipppd/, which you have to
configure. You have to start ipppd once after the modules are installed. ipppd
needs to be constantly running to allow dialout/dialin. It communicates with
the isdn4linux link level devices through <tt>/dev/ippp0</tt> to
<tt>/dev/ippp63</tt>. A single ipppd can handle all devices at once. If you
want two PPP connections at the same time, you need to bind ipppd to two
devices, etc. As a result, <tt/ipppd/ provides the network device
<tt>ippp0</tt>, which can be checked with ifconfig (even so it has the same
name, the network device <tt/ippp0/ is not to be confused with
<tt>/dev/ippp0</tt> which is used for communication between ipppd and link
level.

ipppd has an additional option: &dquot;useifip&dquot; uses the IP address
of the connected network interface (if it is not 0.0.0.0). (Even then, ipppd
tries to use the pointopoint address as the remote IP.) For the beginning,
disable all compression (lzs/stac, bsd, van jacobson), later you can try to
enable it (see question <ref id="syncppp_compression" name="syncppp_compression">).

It is very important to set up the authentication information
properly. Improper authentication is probably the most frequently
reported problem on the mailing list. Please, work through section
<ref id="pap" name="pap"> completely yourself, before asking others for
help.

You can find an example configuration in the file <tt>etc/rc.isdn.syncppp</tt>
in the isdn4kernel-util package.

You can also run several ipppds to allow for different configurations,
in such a case use the <tt>&dquot;isdnctrl pppbind&quot;</tt>
functionality. However, normally one ipppd is meant to handle all traffic,
so it is highly recommended to only set up several ipppds if their
configuration has to be different.

<sect1> syncppp_busy: How can I tell if a connection is unsuccessful (busy)?  
<label id="syncppp_busy">
<p>
When giving the option <tt/defaultroute/, then you can wait a few seconds, then
check whether the default route exists. Another way, when giving option
<tt>useifip</tt> is to check whether you find entries like <tt>&dquot;Local IP:
x.y.z.a&dquot;</tt> and/or <tt>&dquot;Remote IP: x.y.z.a&dquot;</tt> in syslog.
In either case, the connection is up.

<sect1> syncppp_logindelay: How can I reduce login delay?  
<label id="syncppp_logindelay">
<p>
You can write out a login session with (&dquot;Debug-Log&dquot;), and see which
options the other computer is refusing. Next time, configure ipppd
without these unused options. A further side effect is that such
unused options increase the redundance (e.g. when the other computer
has bugs and refuses the options incorrectly). To create a log file,
see &dquot;How to I create a log for ipppd&dquot;.

<sect1> syncppp_2configs: I want to talk to remote machines which needs different  
configurations. The only way I found to do this is to kill the ipppd and start  
a new one with another config to connect to the second machine.  
<label id="syncppp_2configs">
<p>
You must bind a network interface explicitly to an ippp device, where you
can connect a (for this interface) individually configured ipppd. With the
(unfortunately poorly documented) command
<code>
isdnctrl pppbind interface Number
</code>
you can link the interface interface to the device ipppNummer. You can
release the link with &dquot;pppunbind&dquot;.

<sect1> syncppp_pppbind: How does the (little-documented) &dquot;pppbind&dquot;  
command in isdnctrl work?  
<label id="syncppp_pppbind">
<p>
You have to first know how ipppd gets its data. All data that come in
over the ISDN line is received by the network devices (these are
set up with isdnctrl). Then the data given to one of the /dev/ippp*
devices - to one where a ipppd daemon is waiting for data.

To the network interfaces, all ipppd's appear to be able to handle the
just-received data - therefore it is normally impossible to predict
which ipppd will receive data from which network interface.

In practice, you usually install several ipppd's with differing
configurations. Each of these should receive data <em>exclusively</em>
from a certain network interface (that has also be specially configured).
The &dquot;pppdbind&dquot; command serves just this purpose. With:
<code>
&dquot;isdnctrl pppbind interface number&dquot;
</code>
attaches the interface interface to the device /dev/ipppnumber.

Example: To attach the interface &dquot;ippp5&dquot; to /dev/ippp2, the
following configuration should be used:
<code>
&dquot;isdnctrl pppbind ippp5 2&dquot;
</code>
Similarly, the command &dquot;pppunbind&dquot; will undo this attachment.

<sect1> syncppp_dynip: I want to use dynamic IP address assignment. How must I  
configure the network device?  
<label id="syncppp_dynip">
<p>
At least you must have a route, which forwards a packet to the ippp
network interface to trigger dialing. A default route to the ippp interface
will work. Now you must choose a dummy IP address for your interface. If for
some reason you can't set the default route to the ippp interface, you may
take any address of the subnet from which you expect your dynamic IP number
and set a 'network route' for this subnet to the ippp interface. To allow
overriding of the dummy address you must call the ipppd with
the 'ipcp-accept-local' option. You must know how the ipppd gets the
addresses it has to configure. If you don't give any option, the ipppd
tries to negotiate the local host address!  With the option 'noipdefault'
it requests an address from the remote machine. With 'useifip' it gets the
addresses from the net interface. You also can set the addresses in the
option line with the a.b.c.d:e.f.g.h option. Note: the IP address of the
remote machine must be configured locally, or the remote machine must send
it in an IPCP request. If your side doesn't know the IP address after
negotiation, it will close the connection! You must allow overriding of
addresses with the 'ipcp-accept-*' options, if you have set your own or the
remote address explicitly. Try these options, e.g.:
<code>
/sbin/ipppd :&dollar;REMOTE noipdefault /dev/ippp0
</code>
where REMOTE must be the address of the remote machine (the machine giving
your address to you)

<sect1> syncppp_msgetdns: How do I configure ipppd to obtain or provide the  
nameserver address at dial in?  
<label id="syncppp_msgetdns">
<p>
Use the configuration option <tt/ms-get-dns/ to obtain the nameserver ip
address when you dial up your internet provider. Use <tt/ms-dns/ to
publish the nameserver ip address when someone dials up your ipppd.

<sect1> syncppp_ipx: How can I do IPX over ipppd?  
<label id="syncppp_ipx">
<p>
Give the option <tt/+ipx-protocol/ to the ipppd.

<sect1> syncppp_faster: How can I increase my PPP data transfer rates?  
<label id="syncppp_faster">
<p>
You can establish more channels with MPPP (see the MPPP section). Another way
is to use compression, see question
<ref id="syncppp_compression" name="syncppp_compression">.

<sect1> syncppp_compression: Which compressions can I use with ipppd?  
<label id="syncppp_compression">
<p>
Several compressions can now be used with ipppd. However, if in doubt and
it does not work: disable it.
<itemize>
<item><em>Van Jacobson compression</em> (header compression).
Should work fine now for current kernels (later than 2.2.14). To use it you
have to compile it into the kernel. To get around some problems with
automatic loading of the VJ module try to also compile SLIP and CSLIP
into the kernel. Disable with options <tt>&dquot;-vj -vjccomp&dquot;</tt>.
<item><em>BSD compression</em>.
Seems to work quite well if your peer supports it. It is independent
of Van Jacobson compression, so you can use them both together.
<item><em>LZS compression</em> (sometimes also
called <em>Stac compression</em>).
Also works quite well. To enable it, some manual work has to be done to add
the code to the ipppd (see the isdn4k-util package).
</itemize>


<!-- Trouble ipppd
-->

<sect1> syncppp_strategy: I can't get a connect. How can I find out where the  
problem is?  
<label id="syncppp_strategy">
<p>
The output of ipppd is very helpful... (see next question:
<ref id="syncppp_log" name="syncppp_log">)
<itemize>
<item>Have a look at the error messages and see the following questions...
<item>Check whether you can find a few &dquot;LCP-conf-req SENT&dquot; messages
(less than ten) and then a &dquot;TERM-REF&dquot;.
<item>Check whether the ISDN card was configured properly. It seems the
computer doesn't dial (IRQ, IO, protocol wrong?)
<item>At least a few &dquot;RECV&dquot; messages: good! The card is dialing and
your dialin computer tries to communicate. Maybe the pap/chap authentication
doesn't work (see question <ref id="pap" name="pap">). Check the ipppd
configuration!
<item>The message that ipppd was exited for some reason: not so good!
Check <tt>/var/log/messages</tt>, <tt>/var/log/debug</tt>, and
<tt>/var/adm/daemon</tt> (if existing). Could be a bug in ipppd.
<item>The error/cause E0010 is <bf/NOT/ an error! It is just the informal
message that the call has ended.
</itemize>

<sect1> syncppp_log: How can I get a log for ipppd?  
<label id="syncppp_log">
<p>
Normally when giving the option "debug" to ipppd, the debbuging output
may be logged in <tt>/var/log/messages</tt>, <tt>/var/log/debug</tt>, or
<tt>/var/adm/daemon</tt> (depends on your distribution, look around).

For debugging purposes you can redirect the PPP log into a separate file.
Just edit <tt>/etc/syslog.conf</tt> and add the following line (caution:
do NOT use blanks or tabs - check "man syslog.conf(5)" for more details):
<code>
daemon.*                      /var/log/ppp-log
</code>
then every information from PPP demon will be logged to /var/log/ppp-log.
Emil Stephan <tt><htmlurl url="mailto:ste@esqhen.su.eunet.de"
name="ste@esqhen.su.eunet.de"></tt> also wrote:
<verb>
Remove the comment sign in front of this line in /etc/syslog.conf:
&num;*.=debug                       /tmp/debug
After changing this file you can restart syslogd with &dquot;kill -1 pid of
syslogd&dquot;.
The output in /tmp/debug can be used to optimize the handshaking of
PPP options.
</verb>

<sect1> syncppp_nopppsupport: Starting ipppd I get the error message  
&dquot;this systems lacks ppp support&dquot; or &dquot;isdn driver is out  
of date. maybe ippp0 has no syncppp0 encapsulation&dquot;.  
<label id="syncppp_nopppsupport">
<p>
Check whether the device &dquot;ippp0&dquot; exists (i.e. with the program
&dquot;ifconfig&dquot;). See question
<ref id="syncppp_netinterface" name="syncppp_netinterface">
for details on the naming conventions for net interfaces.
The ipppd *needs* this device with exactly *that* name and *syncppp*
encapsulation. If it doesn't exist then you have to define it:
<code>
isdnctrl addif ippp0
isdnctrl encap ippp0 syncppp
(see i4l documentation or question
<ref id="syncppp_config" name="syncppp_config"> for more information...)
</code>
Maybe you compiled ipppd with the source of another kernel that you are not
using...

<sect1> syncppp_nousabledevice: When I try to start ipppd it says &dquot;Can't  
find usable ippp device&dquot;  
<label id="syncppp_nousabledevice">
<p>
This message occurs when the linklevel interface is told to dial out, but ipppd
is not running, or not available.

<sect1> syncppp_starterror: When I start ipppd, I only get error messages from  
the i4l driver.  
<label id="syncppp_starterror">
<p>
When ipppd is started, it calls functions that can trigger a network
packet (e.g. gethostbyname()). Without ipppd (since at this time, ipppd
it has not been fully started), this network access cannot be processed,
You should try to put the needed hostnames in the local /etc/hosts or
in some way define the name so that it can be resolved without having
the access the ISDN/ippp interface.

<sect1> syncppp_framesdelayed: I get the message <tt>IP frames delayed</tt> -  
but no connection.  
<label id="syncppp_framesdelayed">
<p>
Have you really dialed out? Check question
<ref id="dialout_dialmode" name="dialout_dialmode"> and your configuration on the
different dialmodes.

<sect1> syncppp_noroute: I cannot dial out with <tt>isdnctrl dial  
ippp0</tt>. It seems as if the route to ipppd is missing although I <bf/did/  
set it (<tt>network unreachable</tt>). With my old kernel 2.0 everything works  
fine!  
<label id="syncppp_noroute">
<p>
In the newer kernels you have to place <tt>route</tt> as the very last command
before the dialout command. Otherwise the kernel will delete the route.

<sect1> syncppp_nodefaultroute: After ipppd dials out my default route is gone.  
<label id="syncppp_nodefaultroute">
<p>
It's the kernel's fault. Newer kernels (= 2.0.x) have some changes in the
routing. Workaround: install a script /etc/ppp/ip-up like this:
<code>
&num;!/bin/sh
/sbin/route add default ippp*
</code>
Please note, that for 2.2.x kernel, you should NOT do this (routing has changed
yet again). Instead, give the "defaultroute" option to ipppd.

If you make your connections manually, can use something like this script:
<code>
/sbin/isdn
&num;! /bin/sh
case &dollar;1 in
on)
/sbin/isdnctrl dial ippp0       &num;  build up connection
sleep 5                         &num;  wait until line open
/sbin/route add default ippp0   &num;  set route
;;
off)
/sbin/isdnctrl hangup ippp0     &num;  hangup connection
/sbin/route del default         &num;  and delete route again
;;
*)
echo -e &dquot;\a Usage: 'isdn on' or 'isdn off'&dquot;
;;
esac
</code>
Please note, that for 2.2.x kernel, you should NOT use the
<tt>route add default</tt>, and <tt>route del default</tt> commands.
Instead, give the "defaultroute" option to ipppd.

<sect1> syncppp_packettoolarge: I often get the error message  
<tt>hscx_empty_fifo: incoming packet too large</tt>  
<label id="syncppp_packettoolarge">
<p>
Probably one of the compressions is activated (i4l can't handle those very
well). See also next question.
Another possible reason could be an IRQ problem - see question &dquot;Why should
I avoid IRQ 12 and 15 for my ISDN card?&dquot;.
Another problem can be `&num;' characters in your pap-secrets file. In this
case you have to surround user name and/or password with quotation marks
(depending on which one is affected).

<sect1> syncppp_slow: The connection with ipppd seems to work, but eventually it  
crashes or is very slow.  
<label id="syncppp_slow">
<p>
It could be that some compression is activated (that i4l can't
handle properly). Common error: &dquot;-vj&dquot; has to be used *additionally*
to &dquot;-vjccomp&dquot; (to completely switch off the VJ compression) - the
example scripts coming with ipppd don't have that option included already.
Other compression modes (bsd, pccomp) can cause trouble, too. Therefore, you
should switch off all compression options (see also question
<ref id="syncppp_compression" name="syncppp_compression">). Also giving the
option &dquot;noccp&dquot; can help.

<sect1> syncppp_loadproblem: I only have problems with ipppd when the  
connection is being heavily burdened. Then everything stops. What could be  
causing this?  
<label id="syncppp_loadproblem">
<p>
Sven Engelhardt <tt><htmlurl url="mailto:sven@sik.de"
name="sven@sik.de"></tt> wrote on 12 Dec 1996:
<quote>
We are an ISP here in Dresden and use Linux (among other systems)
for our access (with I4L as well as with external terminal adapters).
We have this problem mostly with Windows 95 and NT customers who
are using the &dquot;included&dquot; (modem network) software. It doesn't make
any difference whether the customer is dialing with async or sync PPP.
It also doesn't matter which modem emulation he is using on his side.
What they have in common is that the connection is made with Microsoft
modem adapter + Microsoft PPP (although a colleague recently told me
about a similar problem with a Macintosh customer).
Since it doesn't matter to PPP who is the server and who is the
client, ask your ISP what kind of hardware you are dialing into (we
have had no problems with Linux customers and Trumpet Winsock
users, therefore I suspect a bug in MS-PPP).
The following workaround usually works for us: (it's not a cure,
but helps to reduce the pain...)
* Reduce the Max MTU to 576 or even (296)
* Reduce the  DefaultRcvWindow to 2144
On the Windows 95 side these are 2 Registry entries; on the Linux
side you can set &dquot;mtu 576&dquot; and &dquot;mru 576&dquot; in the PPP
options. (See also: <tt><url url="http://www.winfiles.com/connect/trouble.html"></tt>)
</quote>

Erik Corry <tt><htmlurl url="mailto:ec@sign-tronic.dk"
name="ec@sign-tronic.dk"></tt> added on 16 Dec 1996:
<quote>
For me, neither PPP compression option nor mru/mtu 296 helped.
What did help was the AT command:
AT&amp;B512
that limits the sent packets to 512 bytes.
</quote>

<sect1> syncppp_mtu: My ipppd works, but I keep getting the message pppd(104):  
ioctl(SIOCSIFMTU): Invalid argument&dquot;?  
<label id="syncppp_mtu">
<p>
If mtu is not set, then a default value is assumed - possibly &dquot;0&dquot;
(which of course cannot be correct). Add <tt>&dquot;mtu 1024&dquot;</tt> to
your ipppd options (1500 could also be ok).

<sect1> syncppp_1stpacket: The first IP packet gets lost on automatic dialout  
with dynamic IP address allocation.  
<label id="syncppp_1stpacket">
<p>
There are some dialout problems in connection with syncPPP and dynamic IP
address allocation. In this case your IP address will change while packets
are waiting to be sent. All packets that should be sent before the change
in IP address have the wrong response ip address and will therefore never
receive an answer. The problem is that this may cause multiple dialouts
(see section <ref id="dod" name="dod">). Possible solutions:
<itemize>
<item>Dial out manually with &dquot;isdnctrl dial ippp*&dquot;
<item>Use diald to control when the connection goes up or down.
<item>Get a permanent IP address
<item>A workaround is included in the newest kernels, which can be
activated like this:
<code>
echo 7 > /proc/sys/net/ipv4/ip_dynaddr
</code>
(use 5 instad of 7 to not get warnings into /var/log/messages)
If you have a SuSE distribution, this workaround can also be configured by
setting <tt/IP_DYNIP=&dquot;yes&dquot;/ in <tt>/etc/rc.config</tt>.
<item>Increase the number of retries on your Windows machine for setting
up the connection. Change the registry entry
<tt>Hkey_Local_Machine\\System\\CurrentControlSet\\Services\\VxD\\MSTCP\\MaxConnectRetries</tt>
from 3 to a larger value (e.g. 5 or 7).
</itemize>

<sect1> syncppp_droppacket: What does the message &dquot;No phone number,  
packet dropped&dquot; mean?  
<label id="syncppp_droppacket">
<p>
Michael Engert <tt><htmlurl url="mailto:michi@bello.wor.de"
name="michi@bello.wor.de"></tt> wrote in Nov/Dec 1996:

That means that your computer has an IP packet from somewhat who was
logged on a few seconds before, but has since broken the connection.
Your computer tries to send this packet on and finds an appropriate
route. But the interface isdn(0|1|...) can't reach the other computer,
since it has no telephone number to dial.

<sect1> syncppp_leadingzero: Why does my ipppd dial one too many zeros  
(<tt>&dquot;ippp0: dialing 0 089XXXXXX...&dquot;</tt>)? I don't have any  
extensions!  
<label id="syncppp_leadingzero">
<p>
The first zero is not dialed. It only shows the retry counter, which is related
to the <tt/isdnctrl dialmax/ parameter.

<sect1> syncppp_ethfake: My ISDN device is shown with HWaddr and IRQ=0 and  
base address = 0 when I list it with ifconfig  
<label id="syncppp_ethfake">
<p>
The ISDN device fakes an Ethernet device. It ignores IRQ and baseaddr and
just needs the HWaddr for the Ethernet encapsulation.

<sect1> syncppp_lzsproblem: I get an error message like <tt>kernel check for  
lzs failed</tt>?  
<label id="syncppp_lzsproblem">
<p>
This means that ipppd tries to use lzs compression, but can't find a
compiled module which contains the code. The error message is only cosmetic,
since the system will still work fine. Either disable lzs compression by
providing <tt>noccp</tt> as an option for ipppd, or compile and load the
lzs module.


<!-- Config Async PPP
-->

<sect> asyncppp: Configuration Async PPP  
<label id="asyncppp">

<sect1> asyncppp_whichppp: pppd, ipppd, async PPP, sync PPP - what are they?  
Which should I use?  
<label id="asyncppp_whichppp">
<p>
<bf>async PPP</bf> is a character-based protocol which is usually used over
analog serial lines (async = asynchronous). You have to use the program
<tt/pppd/ for it, and use it with the ttyI* devices.

In contrast, <bf>Sync PPP</bf> is a bit-oriented protocol (sync = synchronous),
for which the original <tt/pppd/ cannot be used. Michael Hipp has written an
adapted version called <tt/ipppd/ which will use ipppd* net devices.

With i4l you can have both. It all depends on what your ISDN counterpart
supports. If it immediately begins to send frames, then you've probably reached
an sync PPP machine. If you can log in via same terminal screen, and then can
start <tt/pppd/, this can be an indication of async PPP.

Usually using <bf/sync PPP/ works fine, and it is slightly more efficient. To
take advantage of newer features of the <tt/pppd/, use <bf/async PPP/.

<sect1> asyncppp_config: How do I configure async PPP?  
<label id="asyncppp_config">
<p>
Just set up a normal pppd, but tell it to use one of the ttyI* devices,
e.g. /dev/ttyI0. You can set up several pppd's with different configuration on
different ttyI* devices.

It is very important to set up the authentication information
properly. Improper authentication is probably the most frequently
reported problem on the mailing list. Please, work through section
<ref id="pap" name="pap"> completely yourself, before asking others for
help.

On problems also check out the section about the syncppp problems, since many
configuration problems are common for pppd (async PPP) and ipppd (sync PPP).

<sect1> asyncppp_logindelay: How can I reduce login delay?  
<label id="asyncppp_logindelay">
<p>
You can write out a login session with (&dquot;Debug-Log&dquot;), and see which
options the other computer is refusing. Next time, configure ipppd
without these unused options. A further side effect is that such
unused options increase the redundance (e.g. when the other computer
has bugs and refuses the options incorrectly). To create a log file,
see &dquot;How to I create a log for ipppd&dquot;.

<sect1> asyncppp_fast: How can I increase my transfer rates with PPP?  
<label id="asyncppp_fast">
<p>
You can add more channels with MPPP (see question
<ref id="2channel_mppp" name="2channel_mppp">).
For everyone for whom that's to expensive and who use <em>async PPP</em>,
there's a little trick. With the option &dquot;asyncmap 0&dquot; you can avoid
escaping all control characters (ASCII32). If the other side goes
along with this, you can increase the transfer rate by about 12&percnt;.

<sect1> asyncppp_log: How can I get a log for pppd?  
<label id="asyncppp_log">
<p>
See this question for Sync PPP, it works the same way for pppd.

<sect1> asyncppp_suddendeath: Establishing the connection works fine,  
but pppd crashes just after that (i.e. the first bytes gets through,  
but then everything stops)  
<label id="asyncppp_suddendeath">
<p>
This is probably due to an incorrect block size on your side. Initialize your
ttyI* device with <tt/AT&amp;B512/ or even smaller block sizes.


<!-- Raw IP
-->

<sect> rawip: Raw IP  
<label id="rawip">

<sect1> rawip_whatis: What is Raw IP, when should I use it?  
<label id="rawip_whatis">
<p>
Raw IP does without the use of a protocol such as X.75 or HDLC
(for modem emulation, etc.) or PPP. TCP/IP packets are directly
exchanged.
Raw IP has both advantages and disadvantages.
Advantages:
<itemize>
<item> No handshaking (= faster connections)
<item> Authorization by Caller ID (= fast, safe, no password)
<item> Fixed IP address (= a broken connection can be continued by redialing)
<item> Higher data transfer rates
<item> Better stability (smaller driver = almost no bugs)
</itemize>
Disadvantages:
<itemize>
<item> No handshaking
=&gt; Configuration must occur beforehand (IP addresses,...)
=&gt; sensible to use for only for one provider at a time
<item> Authorization only by Caller ID
=&gt; Dialin only possible from one's own number
<item> Fixed IP address
=&gt; must be known ahead of time, more IP addresses required, no dynamic
assignment of addresses possible.
</itemize>
From this summary it should be clear under what conditions it makes sense
to use raw IP.

<sect1> rawip_capi: How can I use Raw IP with the new CAPI 2.0 interface (mISDN)?  
<label id="rawip_capi">
<p>
Raw IP can still be used with the new CAPI interface and drivers by using
<tt>ItunD</tt>, the ISDN tunnel Daemon. <tt>ItunD</tt> (ISDN tunnel Daemon)
provides a network tunnel over ISDN lines using the CAPI interface. The
ISDN4Linux isdn-net (raw IP) devices are supported.

You can find <tt>ItunD</tt> at:
<url url="http://sourceforge.net/projects/itund/">

<!-- ttyI* devices
-->

<sect> ttyI: Configuration of the ttyI* devices (`Modem emulation')  
<label id="ttyI">

<sect1> ttyI_nomodem: Don't the ttyI* devices emulate an analog modem?  
<label id="ttyI_nomodem">
<p>
No! The ttyI* devices just offer a similar communication interface, where
all commands are started with <em>AT</em>. This makes it easy to reuse software
that was written to communicate with a modem. <bf>Communication with a remote
analog modem is not possible via the ttyI* devices!</bf> The real communication
happens in digital, not analog form.

<sect1> ttyI_dev: Which devices should I use for calls out or calls in?  
<label id="ttyI_dev">
<p>
Only the ttyI* devices should be used. The cui* devices are created
only for reasons of compatibility. Now that there is mgetty, there is not
reason to use the cui* devices any longer. If they are used, locking will
not work correctly (several programs could simultaneously attempt to use
the same device).

<sect1> ttyI_hdlc: How to I switch the modem emulation from X.75 to HDLC?  
<label id="ttyI_hdlc">
<p>
With the option S14=3; for example &dquot;ATS14=3&dquot;.

<sect1> ttyI_uucp: How can I poll with Taylor-UUCP using isdn4linux?  
<label id="ttyI_uucp">
<p>
As usual, the same as with serial interfaces. Simply use /dev/ttyI* as the
device, as the init string for the modem emulation you have to set the
correct MSN or EAZ with &dquot;AT&amp;Emsn/eaz&dquot;.

<sect1> ttyI_speed: What speed should I set for the ttyI* devices?  
<label id="ttyI_speed">
<p>
It doesn't matter. The driver internally always uses the full speed that
ISDN offers. This is also given in the connect string.

<sect1> ttyI_max: How many devices are the maximum supported number?  
<label id="ttyI_max">
<p>
The maximum can be set by configuring ISDN_MAX at compile time.
Currently, it is set to 64 by default, which means that up to 64
ttyI devices are supported.

<!-- Trouble ttyI* devices
-->

<sect1> ttyI_nocarrier: When I dial with &dquot;ATD.....&dquot; I always  
get a &dquot;NO CARRIER&dquot;.  
<label id="ttyI_nocarrier">
<p>
Before dialing, you have to enter &dquot;AT&amp;E123456&dquot; (if 123456 is your
own MSN; with 1TR6 give the one-digit EAZ).


<sect1> ttyI_noincall: My ttyI* device/pppd does not recognize an incoming  
call.  
<label id="ttyI_noincall">
<p>
Probably you did not tell the modem emulation with <tt>AT&amp;E</tt> which
MSN to use. For example, use <tt>AT&amp;E123456</tt>; if your MSN is 123456.

Please also note that only one application using the ttyI* devices will
receive a ring for a particular MSN. Which will ring is selected by a loop
over all ttyI* devices. A device is selected based on whether its
parameters match (protocol, MSN) and whether it is currently not involved
with another call. Therefore it does not make sense for multiple applications
to register for the same MSN via the ttyI* devices, unless you want to
have load sharing between the applications.

<sect1> ttyI_callphone: Why can't I dial my telephone or fax from the ttyI*  
devices?  
<label id="ttyI_callphone">
<p>
You can. However, ISDN differentiates different services. All outgoing calls
with the ttyI* devices use the service &dquot;Digital Data&dquot;, which is
incompatible with telephone or fax, so the call never gets through.
Change the service recognition with the <tt>ATS18=1</tt> command to audio, then
you can dial your telephone or fax.

<sect1> ttyI_noconnect: I can't get a connection to my ISDN mailbox/BBS.  
<label id="ttyI_noconnect">
<p>
There are several possible protocol parameters. There is HDLC, there is
X.75 and there are several possible block sizes with X.75. You can tell
the modem emulation about the block size with <tt>AT&amp;</tt>. Mostly
used is a block size of 2048 byte: <tt>AT&amp;B2048</tt>.

<sect1> ttyI_forcehangup: My modem emulation hangs. How can I force my card to  
hang up?  
<label id="ttyI_forcehangup">
<p>
If there is really no process using your modem emulation any more, try:
<code>
cu -l /dev/ttyI0 dir
+++
ath0
&tilde;.
</code>
Before and after &dquot;+++&dquot; you have to wait for a second, otherwise the
modem emulation won't recognize it as the escape sequence (like a normal modem).
Watch out for processes that (with &dquot;ps -ax&dquot;) have something like
&dquot;I0&dquot; or &dquot;I1&dquot; in the second column, they have an ISDN
terminal as their controlling terminal. You may have to kill them with kill.

<sect1> ttyI_channelclosed: During a tty connection, I get a message from the  
kernel: &dquot;teles_writebuf: channel not open&dquot;. Then no more input is  
accepted for this connection.  
<label id="ttyI_channelclosed">
<p>
Can happen when the partner cannot handle the large frames from i4l and simply
closes the B channel during the transfer. Try making the frames smaller with
AT&amp;B512.

<sect1> ttyI_x75uucp: When I use UUCP with X.75, I always get transfer errors!  
<label id="ttyI_x75uucp">
<p>
Andreas Gutzwiller <tt><htmlurl url="mailto:andy@hippo.proxyon.imp.com"
name="andy@hippo.proxyon.imp.com"></tt> wrote on 5 Dec 1996:
<quote>
I had to use the following settings, otherwise I only had errors.
&num; Prot
protocol-parameter g packet-size 512
protocol-parameter g short-packets y
protocol-parameter g window 7
protocol-parameter g remote-window 7
protocol-parameter v packet-size 512
Now with large packets I can get ca 7300 cps.
</quote>
Holger Burbach <tt><htmlurl url="mailto:holly@cthulhu.pfalz.de"
name="holly@cthulhu.pfalz.de"></tt> on 5 Feb 1997 had another
solution:
<quote>
I have several XP users who poll without any problems. I did
the following: First I set the send packet size for ttyI?
to 1024 (&dquot;AT&amp;B1024&dquot;) and then set the packet size for the
g protocol in UUCP:
protocol-parameter g packet-size 2048
protocol-parameter g remote-packet-size 0
As I said, it works fine..
</quote>


<!-- Dial on demand = Unwanted dialouts
-->

<sect> dod: Unwanted dialout on demand  
<label id="dod">

<sect1> dod_how: How does dialout on demand work?  
<label id="dod_how">
<p>
After you habe set up a network interface, and defined a route to it, then all
ip packages will be routed to this interface. If the <tt/autodial/ mode has
been enabled (see question <ref id="dialout_dialmode" name="dialout_dialmode"> on
the dialmodes) then the interface will automatically trigger a dialout when it
receives ip packages. (This means that <bf>any</bf> user can trigger a
dialout.)

Example: You open a browser with no or a local homepage. Nothing happens. You
enter some url to connect to, this will send ip packages to the network
interface - thereby triggering a dialout.

Using dial on demand is a potentially dangerous (means expensive) feature:
see question <ref id="dod_disaster" name="dod_disaster">.

<sect1> dod_disaster: What is a charge unit disaster?  
<label id="dod_disaster">
<p>
The charge unit disaster can happen for many reasons (see question
<ref id="dod_causes" name="dod_causes"> for more details). However the results are identical:
your computer dials out to your Internet Provider more often than you want,
thereby increasing your telephone bill by a large amount (especially when
you are not only charged for time online, but also a minimum amount/charge unit
for every dialin). The term 'large amount' is rather flexible. Anything is
possible:
<itemize>
<item>"Cheap": any DNS request opens the line, causing several dialouts per
day (depending on your programs). If this happens 10 times a day, this makes
up about 300 unneeded dialouts per month.
<item>"Not so cheap": Some Windows 95 computer in your LAN triggers a dialout
every 15 minutes for one of its silly broadcasts (see question
<ref id="dod_winclient" name="dod_win95">). Makes up 96 dialouts per day, or 2880 per month.
<item>"Medium": Your email client is configured to check every 5 minutes
whether you have new emails at your Internet Service Provider. Makes up
288 dialouts per day, 8640 per month.
<item>"Expensive": Keep alive packets prevent that your line ever hangs up.
Your line is always on. Note: THIS IS NOT THE WORST CASE!
<item>"More Expensive": Something goes wrong with dynamic addresses,
leaving sockets open when hanging up. The sockets trigger another dialout
when they try to resolve this, but since now you have a new ip address, the
issue can't be resolved. The line will eventually hang up (when depends on
your timeouts), but then re-open - since the sockets trigger another dialout.
If you are unlucky, you never get the same ip address back, so this repeats
continuously. Your line is almost always on, but on top of it you have to pay
for many dialouts: if your timeout is 30 seconds, this makes up 2880 dialouts
per day, 86400 per month.
<item>"Most Expensive - Worst Case": You misconfigure dialout/callback, so
that when your (the initiating) computer dials out to your Internet Provider,
who then hangs up on you (e.g. authorization failed - maybe he also has some
misconfiguration or unhooks despite being down), your computer immediately
dials out again. This is only limited by the amount of time needed to dial
out. If we assume 2 seconds for each attempt (conservative estimate), this
makes up 43200 dialouts per day, or 1296000 per month!
</itemize>

This is no joke, and all these things have actually happened, even to real
isdn4linux experts! See question <ref id="dod_off" name="dod_off"> on how
to avoid any risk of this happening to you.

<sect1> dod_causes: What can cause a charge unit disaster?  
<label id="dod_causes">
<p>
There are many possibilities. See question <ref id="dod_strategy" name="dod_strategy"> on how
to track down what is happening to you. See question <ref id="dod_disaster" name="dod_disaster">
on how expensive that could be. Here a non-comprehensive list of causes:
<enum>
<item>You compiled your kernel with the option Bridging by mistake.
<item>ARP requests or broadcasts? You should run ifconfig with the options
<tt>-arp</tt> and <tt>-broadcast</tt> to keep from opening connections in this
way. You can recognize this one when you have a dialout, but <em/no/ data is
transferred.
<item>Other Broadcasts from the interfaces were being forwarded by ISDN.
<item>If IP connections are still open with the line is disconnected and
IP addresses are dynamically assigned, then the disaster is inevitable.
Then a new connection is started to bring down the open IP connections,
which fails because the IP address is now different. The line is hung up,
but the IP connections are still open, the line is dialed again, and
so on... This can only be avoided with the RST-provoking mode (see question
<ref id="dod_rstprovoking" name="dod_rstprovoking">. A patch for it may be
needed if it is not included in your distribution. The patch had found
its way into the 2.0.x kernels, but not into 2.1/2.2/2.3. However, you can get
an adjusted patch for 2.2.x kernels and some background information about it
from: <url url="http://www.another.de/linux/router/">. See also question
<ref id="syncppp_1stpacket" name="syncppp_1stpacket">.
Also make sure to use ipppd's "defaultroute" option rather than
<tt>route add/del default</tt> in ip-up/ip-down with it.
<item>TCP retries trigger dialout: when the kernel tries to send tcp packets
and does not receive any answer, then it will retry to send them (usually
every 120 seconds). Check out whether you want to adjust the following
parameters:
<itemize>
<item>/proc/sys/net/ipv4/tcp_syn_retries
<item>/proc/sys/net/ipv4/tcp_retries1
<item>/proc/sys/net/ipv4/tcp_retries2
</itemize>
Documentation can be found in <tt>/usr/src/linux/Documentation/proc.txt</tt>.
<item>Requests from your local DNS trigger a dialout: see question
<ref id="dod_localdns" name="dod_localdns">.
<item>Sendmail triggers the dialout: see question
<ref id="dod_sendmail" name="dod_sendmail">.
<item>Windows 95 clients trigger the dialout: see questions
<ref id="dod_winclient" name="dod_win95">,
<ref id="dod_localdns" name="dod_localdns">,
and <ref id="dod_winclient" name="dod_win95b">.
<item>Samba triggers the dialout: see question <ref id="dod_samba" name="dod_samba">.
<item>Netscape triggers a dialout when started: see question
<ref id="dod_netscape" name="dod_netscape">.
<item>dhcpd triggers dialouts: switch it off, and verify your configuration...
<item>Manually close IP connections which are still open when the line
goes down: see question <ref id="dod_closeipconnect" name="dod_closeipconnect">.
<item>Your computer is crashed, but still processes interrupts: see
question <ref id="dod_onlineoncrash" name="dod_onlineoncrash">.
</enum>

<sect1> dod_off: How can I safely turn off dialout on demand?  
<label id="dod_off">
<p>
<enum>
<item>To always dial out manually, set your dialmode to <tt/manual/ (see
question <ref id="dialout_dialmode" name="dialout_dialmode">).
Then use <tt>isdnctrl dial &lt;device&gt;</tt> to dial out, and
<tt>isdnctrl hangup &lt;device&gt;</tt> to hangup.
<item>Set your dialmode properly (see question
<ref id="dialout_dialmode" name="dialout_dialmode">). For example, set
dialmode to <tt/manual/ in <tt/ip-down/. Then dialouts will only be possible
once after setting dialmode to <tt/auto/.
<item>Delete the telephone number of the interface, or set an invalid one.
Then you can see from the complaints in the syslog whether a process wants
to send packets out to the world.
<item>Switch the system off.
<item>Delete your route to the ISDN device.
For example, to disable any automatic dialouts:
<code>
/sbin/route del default
/sbin/isdnctrl system off
/sbin/ifconfig ippp0 down
</code>
To get things running again:
<code>
/sbin/isdnctrl system on
/sbin/ifconfig ippp0 up
/sbin/route add &dollar;GATE-IP dev ippp0
/sbin/route add default ippp0
</code>
The latter method has the disadvantage that dialin is then no longer
possible.
</enum>

<sect1> dod_strategy: How can I track down unexplainable dialouts?  
<label id="dod_strategy">
<p>
Finding the reason of unexpected dialouts is the first step to stopping it.
However, finding is usually more difficult than fixing the problem. This is
what you can do to track it down:
<itemize>
<item> First disconnect your dialout server from your LAN to find out who
is responsible for the dialouts: the dialout server himself, or some
clients in your LAN. For Windows clients, see question
<ref id="dod_winclient" name="dod_winclient">.
<item> Try to find out which TCP/IP packet triggers the connection with
&dquot;isdnctrl verbose 3&dquot;. A message should appear in
the kernel message queue (visible with <tt>dmesg</tt>), like:
<tt>OPEN: 141.76.60.54 - 193.171.67.253 TCP, port: 1686 - 540</tt>
In this example, our computer is trying to pick up mail on
port 540 (UUCP over TCP/IP over ISDN) - the port number can be looked up
in <tt>/etc/services</tt>. Please note: only the triggering packet will
be logged.
<item> If you are using ipppd: get a tcpdump which can show data with the
syncPPP encapsulation (this may require a patch - see question
<ref id="trouble_tcpdump" name="trouble_tcpdump">).
<item> Try to turn off one daemon after the other and see if things have finally
quieted down. named, sendmail, and also smbd (Samba) are likely candidates to
open connections (see questions <ref id="dod_localdns" name="dod_localdns">,
<ref id="dod_sendmail" name="dod_sendmail">, <ref id="dod_samba" name="dod_samba">).
<item> If broadcasts are your problem, you can also redirect the
broadcast address to the dummy0 interface. It's not clean, but it works.
</itemize>

<sect1> dod_winclient: Can it be that the Win95 machine on my LAN is causing  
automatic dialouts?  
<label id="dod_winclient">
<p>
Yes. When Windows 3.11/95 is started, then it tries to talks to the name
server of your provider (if known), trying to look up some domains
(e.g. WORKGROUP.xxx). To avoid this, these are your options:
<itemize>
<item> Switch off the feature <tt>Use DNS for Windows Names Resolution</tt>
on all Windows computers on your LAN.
<item> Set up a local DNS name server such that it will answer all requests.
See question <ref id="dod_localdns" name="dod_localdns">.
</itemize>

<sect1> dod_localdns: I have set up a local DNS name server. Why does it cause  
unwanted dialouts? How can I find the cause?  
<label id="dod_localdns">
<p>
Turn on debug level 1 in named and look at the logfile in <tt>/var/tmp</tt>.
Often, you can find regular DNS requests from Windows machines.
The problem is that names like "WORKGROUP.domain.de" are requested,
i.e. names that the DNS could not know. Windows seems to be looking for
its master browser or a domain controller (if you are fluent in German, see
ct 12/99, page 224: "Schnitzeljagd - Netzwerkumgebung und Browserdienst
im Windows-Netzwerk" for more details). To work around this problem, you can
set up your domain name server with cname = "WORKGROUP.domain.de" (other
domain names are also possible). Or set up a Primary Domain Controller
within your LAN. You can also use diald to control dialouts for DNS request.

<sect1> dod_forwarddns: I have set up my name server in 'forward' mode,  
with one forward address. Now it dials out about every minute?  
<label id="dod_forwarddns">
<p>
From time to time, the name server will query its forwarder, which will
trigger a dialout. Since your ISP uses dynamic ip addresses, the request
is sent out with the wrong ip address at startup of the dial-in connection.
Therefore, no answer will be received. Bind waits for one minute
before resubmitting. If your line has come down in the mean time, this
will trigger a new dialout, resulting in a different ip address, and so on...

For a workaround to this problem you can shorten the retransmission time
as described in question <ref id="dialout_bind" name="dialout_bind">.

Alternatively, you can set the option &dquot;dialup yes;&dquot; in the
options block of named.conf. This will cause named to do only one
interaction with a forwarder (triggering a dod) at startup. After that it
will wait for some very long interval (24h?) before another query with
the forwarder. Only during actual lookup it will do negotiations with the
forwarder (this is usually when you have already dialed out anyway).

<sect1> dod_sendmail: How can I get sendmail to not initiate any connections  
without local mail being left undelivered?  
<label id="dod_sendmail">
<p>
First you have to get sendmail to no long open any DNS connections.
You need to activate the following features: &dquot;nodns&dquot;,
&dquot;nocanonify&dquot;.

If you have a smarthost, you need to make sure that this name does not
call the name server. You can either set it directly as an IP address,
or add the name to /etc/hosts (/etc/host.conf should then contain
&dquot;order hosts bind&dquot;)

You should set all non-local mailers as &dquot;expensive&dquot;
(&dquot;define(SMTP_MAILER_FLAGS, e)&dquot;), and then forbid sendmail with
&dquot;define(`confCON_EXPENSIVE', `True')&dquot; from automatically connection
to expensive mailers. The call to sendmail should no longer include
a time for the &dquot;-q&dquot; option (e.g. only &dquot;-bd -os
-q&dquot;). &dquot;-os&dquot; means that all mail will be queued (which won't
prevent local mail from being delivered immediately). The only catch is that
when booting, mail that might still be in the queue will be sent by sendmail,
even though the network is not yet up. Therefore, when booting you should
remove all mail from /var/mqueue before starting sendmail, and then return it
once sendmail has been started.

Mail to expensive mailers will now only be send with the explicit
call &dquot;sendmail -q&dquot;.

<sect1> dod_samba: The samba package always triggers dialouts for me. How can I  
prevent this?  
<label id="dod_samba">
<p>
When nmbd starts up it tries to bind to 0.0.0.0 or all interfaces, which
is what triggers the ISDN dialup.
The best way to solve this is to set "bind interfaces only = yes" and
"interfaces = eth0" in smb.conf (in case you want to use Samba only in
your LAN).
Alternatively, you can give the samba daemon an internal ip address upon
startup. First find out which ip address samba is trying to connect to
(e.g. with netstat or tcpdump). Then start samba with:
<code>
nmdb -S -B 192.168.99.255 -I 192.168.99.99
</code>
if your Linux computer has 192.168.99.99 as ip address, and all users
are in the same subnet (192.168.99.255).

See also the above question:  set -broadcast and possibly -arp
when defining the interfaces!

Check out the help pages for the Samba configuration file for further
possibilities on preventing dialout (I was told there should be some
explicit dialup parameter which prevents it to cause many dialouts).

<sect1> dod_netscape: How can I get Netscape to quit initiating dialouts when  
starting?  
<label id="dod_netscape">
<p>
Most likely in the preferences a non-local home page has been listed.
Only a home page that Netscape is able to load immediately (e.g.
&dquot;file://localhost/xxx&dquot;) won't cause an immediate
dialout. Alternatively you can also set up a cache daemon that saves pages that
are often needed.

Second check your proxy settings. When giving a complete name instead of an
ip address, Netscape may try to do a DNS lookup to resolve the name to an
ip address on startup. In this case provide Netscape with an ip address.

Another thing is that Netscape tries to contact its news server. If you don't
want to use this feature then you can enter the name Netscape uses for lookup
(probably 'news') in your local DNS or in your /etc/hosts, and let it point
to localhost.

<sect1> dod_rstprovoking: Why should I use the RST-provoking mode/patch?  
<label id="dod_rstprovoking">
<p>
If on every dialup (in auto dialout mode) you get a different ip address
(dynamic ip), and the dialup connection gets terminated (e.g due to
inactivity) while some ip connections have not yet been closed, then the
following problem will occur:
when the program tries to close the connection this will trigger a new dialout.
Since this will yield in a new ip address, the closing attempt will fail.
After the timeout period another dialout will be attempted, with the same
result, leading to a dial on demand disaster.
To prevent this problem the RST-provoking mode has been invented.
If on the closing attempt a new dialout is opened and the ip address changes,
then the kernel will send a ip packet with the reset flag on. This will close
down the open connection, preventing the dial on demand disaster.
To activate the RST-provoking mode use the command
<code>
echo 7 > /proc/sys/net/ipv4/ip_dynaddr
</code>
Use 5 instead of 7 to prevent syslog warnings. Check the current status with:
<code>
cat /proc/sys/net/ipv4/ip_dynaddr
</code>
Your distribution may or may not have the patch for this rst-provoking mode
included, it was not liked in the kernel code for kernels newer than 2.0.x.

<sect1> dod_closeipconnect: After closing the line, I discover with  
<tt>netstat -nt</tt> that IP connections are still open. How can I close  
these manually?  
<label id="dod_closeipconnect">
<p>
This may only work with the RST-provoking mode (mentioned in question
<ref id="dod_causes" name="dod_causes">): You can bring the interface
&dquot;down&dquot; then back &dquot;up&dquot;. When you do this, it will
try to dial out. But if you have removed the outgoing telephone number,
then &dquot;no outgoing number...&dquot; appears in the syslog, and as
soon as the interface is &dquot;up&dquot;, all connections will be closed.

You can prevent those open IP connections to trigger new dialouts if you
add a special firewall rule in <tt>/etc/ppp/ip-down</tt>, and remove it
in <tt>/etc/ppp/ip-up</tt>. This firewall rule drops all tcp packets
which are not in SYNSENT state. Add this in <tt>/etc/ppp/ip-down</tt> for
a 2.2.x kernel:
<code>
ipchains -A output -j DENY -p tcp -i &lt;interface&gt; ! -y
</code>
Add this in <tt>/etc/ppp/ip-up</tt>:
<code>
ipchains -A output -j DENY -p tcp -i &lt;interface&gt; ! -y
</code>
(As is the case for all firewall rules: it is best to put this into a
separate script which is called with either a start or a stop parameter.)
Please note that this firewall rule only matches whole packets, no fragments.
A fragment will always bypass the firewall and trigger a dialout.

<sect1> dod_onlineoncrash: Is it possible that even with a crashed computer  
a ISDN connection remains open (and the charge units accumulate)?  
<label id="dod_onlineoncrash">
<p>
The ISAC chipset, which is in use on many ISDN cards, can be run in either
auto mode, or in non-auto mode. When run in auto mode, the connection could
be up when the computer is crashed (the card keeps it up and running).
Since the HiSax driver uses nonauto mode, this should not happen with
ISDN4LINUX. Once no interrupt is processed on your machine, the connection
will stop at maximum half a minute later. Only in the unlikely event that
your machine is crashed, while interrupts are still processed normally, this
could happen.


<!-- Chargeint
-->
<sect> chargeint: Chargeint  
<label id="chargeint">

<sect1> chargeint_whatis: What does Chargeint?  
<label id="chargeint_whatis">
<p>
Chargeint is a way to reduce your costs when you have charges based on your
<bf/time online/, and the interval between two charges (the Charge Interval) is
relatively large (e.g. per minute).

Chargeint only hangs up two seconds before the end of a charge unit. isdnlog
can be used to set the length of the charge unit (i.e. Charge Interval)
according to the time of day and the date.

<sect1> chargeint_config: How should I configure Chargeint?  
<label id="chargeint_config">
<p>
You can set the length of a charge unit manually via the isdnctrl parameter
<tt/chargeset/, or set up isdnlog to do this automatically for you:
<enum>
<item>Set up isdnlog, so that it has all the information about your location
and your telephone company (so that it knows your rates).
<item>Start isdnlog with the options <tt>-h0</tt> and <tt>-w</tt>.
<item>Set your huptimeout as you like (idle time needed before i4l will
consider a hangup). E.g.:
<code>
/sbin/isdnctrl huptimeout ippp0 5
</code>
Then i4l will hang up 2 seconds before the end of your charge unit, if the 5
seconds before (huptimeout) no activity has happened on the line.
</enum>

<sect1> chargeint_whennot: When does it <bf/not/ make sense to use the  
chargeint?  
<label id="chargeint_whennot">
<p>
<enum>
<item>It does not make sense to use Chargeint when you are charged <bf/per data
volume/, or per <bf/flat fee/. Chargeint can only reduce your costs when you
are charged <bf/per time online/.
<item>Also it makes no sense if you are charged in small units (e.g. per second
rather than per minute).
<item>Chargeint may or may not make sense when every new dialup costs you fixed
amount on top of the variable charges (depending on the rates).
<item>There are problems when the ip address is assigned dynamically. A broken
connection cannot simply be restarted (since the IP address has changed). The
interrupted FTP, telnet or WWW connection must then be newly established.
</enum>

<sect1> chargeint_correcttime: How can I be sure that the chargeint patch is  
using the correct time?  
<label id="chargeint_correcttime">
<p>
It's best to synchronize the clock in your own computer with that of the
switching station by calling isdnlog with option <tt>-t2</tt>.

<sect1> chargeint_nohangup: The connection doesn't end with timeout.  
<label id="chargeint_nohangup">
<p>
Chargeint will only hangup if there was no activity on the line. Possibly your
service provider uses a router (e.g. Cisco) which sends a &dquot;keep
alive&dquot; packets every ten seconds. If the Cisco doesn't get an answer for
its keep alive packets then it will stop routing. This normally happens after
the 4. or 5. keep alive packet. Very recently (begin of 2001), support for
Cisco's keep alive packages has been corrected, so you can either use it,
or tell the provider not to use keep alive packets
(<tt>&dquot;no keepalive&dquot;</tt> in the Cisco configuration).

It could also be that it's not the keep alive packets that are keeping the
connection open, but rather OSPF routing updates. The sending of these
updates can only be switched off on the Cisco. You can configure
&dquot;snapshot server&dquot; on the BRI interface. That means it will
send out routing updates only when they are received through this interface.

However, nowadays the most likely cause for open connection is that
connection requests looking for a backdoor or a file sharing application
cause issues like this. You can use the <tt>active-filter</tt> option
of ipppd to indicate which packets should be regarded as link activity.
See the man page for more details. A configuration could be like this:
<code>
active-filter 'outbound and not icmp[0] == 3 and not tcp[13] & 4 != 0'
</code>

<!-- 2 and more channels: MPPP, raw bundling
-->

<sect> 2channel: Channel bundling (MPPP, raw bundling)  
<label id="2channel">

<sect1> 2channel_whatis: What is channel bundling and how can I use it?  
<label id="2channel_whatis">
<p>
Channel bundling is currently supported by isdn4Linux in two variations:
<itemize>
<item><bf>Raw Bundling</bf> (configuration of so-called slave channels)
<item><bf>MPPP</bf> (based on syncPPP)
</itemize>
Both variations have their own advantages and disadvantages. See the following
questions. Dynamic adjustment is supported for MPPP by the program
<tt>ibod</tt> - see question <ref id="2channel_mpppconfig" name="2channel_mpppconfig"> for more
details.

<sect1> 2channel_raw: What is raw bundling?  
<label id="2channel_raw">
<p>
Raw bundling works similarly to raw IP, only with several channels.
Therefore, it has the theoretical advantages and disadvantages of
raw IP. Raw bundling requires a network interface for each channel
that is used. One network interface, the so-called master interface,
controls the establishment and breaking of connections. For each
further channel, an additional so-called slave interface is configured,
that is automatically switched on by the master interface.

<sect1> 2channel_rawconfig: How do I configure raw bundling?  
<label id="2channel_rawconfig">
<p>
The master interface is created as usual with
<code>
isdnctrl addif master interface
</code>
and configured. For all required slave channels, slave interfaces
are created with the command:
<code>
isdnctrl addslave master interface slave interface
</code>
and configured as usual (e.g. &dquot;isdnctrl sdelay slave interface
delay&dquot;).

<sect1> 2channel_rawgoodbad: What are the advantages and disadvantages of raw  
bundling?  
<label id="2channel_rawgoodbad">
<p>
Raw bundling has all the advantages and disadvantages of raw IP.
Compared to MPPP, raw bundling has the advantage that isdn4linux
itself can open and close the needed slave channels. Unfortunately
raw bundling still has problems with transfer rates. See the further
questions below.

<sect1> 2channel_mppp: What is MPPP?  
<label id="2channel_mppp">
<p>
MPPP or MP or MPP (Warning: MP is also an acronym for 'Multi Processor')
stands for Multi Point to Point and means bundling of several channels to
one logical stream. It's a variation of the normal syncPPP. Accordingly, it
inherits all its advantages and disadvantages. Just for your information: ipppd
does MPPP according to RFC 1717, instead of the newer RFC 1990 (MLP).

In contrast to raw bundling only one net interface is needed as interface
to the ipppd, since the ipppd handles all its channels by itself. Incoming
data is distributed round-robin by the ipppd on all available channels.
These channels do not necessarily have to be ISDN channels. In theory,
modem connections could be mixed with ISDN channels. However, here we only
cover ISDN channels.

<sect1> 2channel_mpppgoodbad: What are the advantages and disadvantages of  
MPPP?  
<label id="2channel_mpppgoodbad">
<p>
A disadvantage is that the slave channel has to be activated
&dquot;manually&dquot;. ipppd cannot by itself turn the slave channel on and
off as it needs to. The normal automatic functions of ipppd are
either unreliable (auto hangup) don't work at all (auto dial).
This is not true for the other encapsulations. The transfers
rates are very good (ca. 30 KB/s with 4 channels).

<sect1> 2channel_mpppconfig: How do I configure MPPP?  
<label id="2channel_mpppconfig">
<p>
First ensure that support for MPPP has been switched on for compilation
of your ISDN modules. Then define a (normal) interface for ipppd (e.g.
&dquot;isdnctrl addif ippp0&dquot;, etc). This interface will be used as
your master interface.
Then you must configure a slave device for every additional channel (e.g.
&dquot;isdnctrl addslave ippp0 &lt;slave_interface&gt;&dquot;, configure
slave_interface, etc - see the i4l manual for more).
To enable MPPP negotiation, ipppd must be called with the &dquot;+mp&dquot;
option and both devices have to be given to ipppd. Please note that the
name of both devices has to start with &dquot;ippp&dquot;.

To use channel bundling you must first activate the 'master' or initial
call. Now you can add the slave channels with the command:
<code>
isdnctrl addlink device
</code>
and close them with the command:
<code>
isdnctrl removelink device
</code>
This is different to other encapsulations of isdn4linux!
If addlink gives you error -2, then this means that there are no slave devices
configured. Error -5 means that ippp0 is not connected.

Please also note, that the slave device has to be in dialmode <tt/auto/ for
this to work. For manual control, use
<code>
isdnctrl dial slave
</code>
and
<code>
isdnctrl hangup slave
</code>
When using manual control please ensure that the slave device is shut down
before the master device. Currently (August 2002) there is a hard-to-fix bug
in the MPPP code which will cause a crash on the next dialout. A patch exists
which cures the symptoms to prevent the crash (see mailing list). However,
since the dialout will fail in any case it is best to avoid this situation
altogether by using the proper shutdown sequence.

With syncPPP, there is no automatic activation of slave devices, they have to
be added and removed. However, there is the program <tt>ibod</tt> available,
which can do this automatically. Have a look at:
<url url="http://www.compound.se/ibod.html">
or (for a version extended by Karsten Keil):
<url url="http://www.suse.de/~kkeil/xibod/">

In the file <tt>etc/rc.isdn.syncppp.MPPP</tt> in the isdn4k-utils package you
can find a sample script (unfortunately missing in some i4l versions).

Please note that your Internet Provider has to allow you to make use of these
features. Also, there may be a limit on how many channels you are allowed to
open at the same time. It could be that all links are dropped when you exceed
this limit.

<sect1> 2channel_mpppcompile: I tried MPPP but it doesn't work. The ipppd  
writes in the debug log something like:  
&dquot; ...  rcvd (0)(proto=0x3d) c0 00 00 00 80 fd 01 01 00 0a ...  
sent (0)(LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01 ...&dquot;  
<label id="2channel_mpppcompile">
<p>
You forgot to compile MPPP/RFC1717 support into the ISDN Subsystem.
Recompile with this option enabled.

<sect1> 2channel_cantlocateippp1: When trying to use MPPP I get the error  
message &dquot;modprobe: Can't locate module ippp1&dquot; and  
&dquot;ipppd: ioctl(SIOCSIFMTU): No such device...&dquot;?  
<label id="2channel_cantlocateippp1">
<p>
This is a pecularity of ipppd. It tries to set MTU even for slave devices,
and the kernel can not find a corresponding network device. You can safely
ignore this information message, MPPP should work nevertheless.

<sect1> 2channel_multiplenumbers: How can I set up multiple number when  
using MPPP?  
<label id="2channel_multiplenumbers">
<p>
Master and slave device are fully independent of each other, except for using
the same network device to deliver packets. Setting up multiple number for
master and slave devices will result in synchronized dialout (to the same
number). Therefore it is best to give the slave device no number by default
and set up the slave with the same number as the master in some ip-up script.

<sect1> 2channel_freebchannel: How could I set up isdn4linux to free the  
second B-channel if a phone call comes in?  
<label id="2channel_freebchannel">
<p>
Well, this is a tough one, due to technical limits. Even if isdn4linux freed
a B-channel, the exchange would not repeat the setup call. Therefore, the
phone would not ring. The phone only signals a second incoming phone call if
you are on the phone with another call that could be suspended.

One option would be that isdn4linux frees one B-channel, then takes the call,
and transfers it to the phone via ECT (explicit call transfer); however, this
feature requires proprietary (unknown) protocol extensions, and is usually
only available behind large private exchanges - therefore not implemented
in isdn4linux.
Another option is that isdn4linux frees one B-channel, takes the call, then
suspends it. However, the user would have to know to resume it without any
phone ringing.
The most sensible option is that you handle it will a phone application
making use of isdn4linux. Possibly ant-phone could be used for such a purpose:
<tt><url url="http://www.antcom.de/"></tt>


<!-- Pecularities of your counterpart (remote device)
-->

<sect> remote: Pecularities of the remote ISDN device  
<label id="remote">

<sect1> remote_win95: How do I configure Windows95 to dial successfully into  
my isdn4linux computer?  
<label id="remote_win95">
<p>
Configure your dialout network like this:
<itemize>
<item>Type of server: PPP:Windows 95, Windows NT 3.5, Internet
<item>Extended options: unselect all options
<item>Network protocolls: only select TCP/IP
<item>Standard gateway
<item>Switch off IP header compression for the beginning
(for more details on compression with ipppd see question
<ref id="syncppp_compression" name="syncppp_compression">).
<item>Remainder of TCP/IP stuff (ip address, nameserver,...) as applies to you.
</itemize>

<sect1> remote_mac: I'd like to exchange data with a Macintosh (Leonardo  
card), what do I or the Mac user have to watch out for?  
<label id="remote_mac">
<p>
Currently, the Leonardo protocol is not supported by i4l. When you call the
Mac, he should set the protocol to X.75 or HDLC. When he calls you, he must
explicitly set the protocol (e.g. by inserting an &dquot;X&dquot; for X.75) in
the called number.

<sect1> remote_macpap: A Macintosh with a Leonardo card tries to call in,  
and wants to negotiate chap md5. How can I switch it to CHAP/PAP?  
<label id="remote_macpap">
<p>
You can't. The user should use LeoPort (always included with the card) and
switch the CTB port to the ISDN card. Then with FreePPP 2.5v2
<tt><url url="http://www.rockstar.com"></tt> set the Leo as the modem and
configure FreePPP as usual. Then PAP/CHAP can be set.

<sect1> remote_cisco: How does isdn4linux work with a Cisco (HDLC) on the  
other side?  
<label id="remote_cisco">
<p>
On the Cisco router the &dquot;keep alive&dquot; packets have to be turned off.
isdn4linux has to be configured with HDLC, transparent, with Cisco
encapsulation:
<code>
isdnctrl l2_prot &lt;interface&gt; hdlc
isdnctrl l3_prot &lt;interface&gt; trans
isdnctrl encap &lt;interface&gt; cisco-h
</code>

<sect1> remote_ispa: What settings does ISPA etc. (DOS, Windows) need to work  
with the standard settings of isdn4linux?  
<label id="remote_ispa">
<p>
The following configurations are possible (these also apply to the
other drivers from H. Hanewinkel, i.e. CINDI, CANDI, WISPA...)
that can be found via
<tt><url url="http://www.informatik.uni-bremen.de/&tilde;henker/dank"></tt>
<verb>
i4l side                             ISPA side
====================================================
isdnctrl l2_prot isdn0 hdlc           \
isdnctrl l3_prot isdn0 trans              -h0
isdnctrl encap   isdn0 rawip          /
----------------------------------------------------
isdnctrl l2_prot isdn0 hdlc           \
isdnctrl l3_prot isdn0 trans              -h1
isdnctrl encap   isdn0 uihdlc         /
----------------------------------------------------
isdnctrl l2_prot isdn0 x75i           \
isdnctrl l3_prot isdn0 trans              -l0
isdnctrl encap   isdn0 rawip          /
----------------------------------------------------
isdnctrl l2_prot isdn0 x75i           \
isdnctrl l3_prot isdn0 trans              -l1
isdnctrl encap   isdn0 uihdlc         /
----------------------------------------------------
</verb>
The parameter with the least problems is -h0.


<sect> leased: Leased lines  
<label id="leased">

<!-- Config Leased line/D64S  
-->  

<sect1> leased_flatrate: What's the difference between a leased line and  
a flat rate?  
<label id="leased_flatrate">
<p>
A leased line requires a special setup of your S0 interface. After that,
you can not reach any other destination than the one the leased line is
set up for. It's also rather expensive.

A flat rate is still a normal dialup, therefore the setup should be done
like any dialup connection. The only difference from a normal dialup is
the pricing. See section <ref id="dialout" name="dialout">. Also please
note that the connection on a flat rate will usually be stopped by your
internet provider if you stay on for too long - so you can not rely on
being online all the time, if this is what you desire.

<sect1> leased_nosignal: How does establishing and ending a connection work  
with D64S without signaling?  
<label id="leased_nosignal">
<p>
The data is simply sent out! Other than a ping, there is no way to find out
whether the D64S or 2MB line is up or not. Only S01 or S02 lines have a D
channel and have something to use with signaling, however the best
known solutions also use this 16kb for data transfers to get 144kb
instead of 128kb (i4l can only to 128kb).

<sect1> leased_hisaxconfig: With i4l, how do I configure my card on a D64  
leased line?  
<label id="leased_hisaxconfig">
<p>
A later version of the new HiSax driver supports D64. Configuration is normal
with the following specialities. HiSax has to be run in leased mode:
<code>
/sbin/hisaxctrl HiSax 5 &lt;channel&gt;
</code>
in case HiSax was loaded with &dquot;id=HiSax&dquot;, where &lt;channel&gt;
can be 0 or 1. Additionally to the normal configuration, the following
commands are important:
<code>
/sbin/isdnctrl bind HiSax,&lt;channel&gt
/sbin/isdnctrl eaz isdn0 1
/sbin/isdnctrl addphone isdn0 out 2
/sbin/isdnctrl addphone isdn0 in  3
</code>
if &dquot;isdn0&dquot; was used as interface name. The interface has to be
set to &dquot;up&dquot; and a route associated with it. See the Readme's
in the HiSax package.

<sect1> leased_x75: How do I configure X.75 on a D64 leased line?  
<label id="leased_x75">
<p>
Use a later HiSax version. First initialize the ttyI* device you want to use
with &dquot;AT&amp;E0&dquot; (set usage of first B-channel) and
&dquot;ATS0=1&dquot; (autoanswer on first ring). Then set HiSax in leased mode:
<code>
/sbin/hisaxctrl HiSax 5 &lt;channel&gt;
</code>
This will simulate a call for MSN1 on the configured channel (0 or 1)
(incoming number = LEASED0).

<sect1> leased_splitline: With i4l, can I use one channel as a leased line  
and the other as a dialup line?  
<label id="leased_splitline">
<p>
Yes and no. You can configure HiSax for both at the same time, however you can
only use one of them at any point in time (you have to switch off the leased
line before dialing out). It may work occasionally simultaneously, however
the driver has not been written for it so the results are not deterministic.
Also make sure that you use the correct channel.


<!-- Dialin
-->

<sect> dialin: Configuration of a Dial-In Server  
<label id="dialin">

<sect1> dialin_config: How can I enable others to login via ISDN?  
<label id="dialin_config">
<p>
Some configuration examples can be found at:
<url url="http://www.rosat.mpe-garching.mpg.de/~web/ISDN.html">.
If you have trouble setting it up, try to obtain the latest packages for
isdn4linux (see question <ref id="distrib_getlatest" name="distrib_getlatest">).
As usual, you can also ask in the mailing list.
In general, there are several ways to configure dialin, depending
on how you want others to dial in.
<itemize>
<item>Set up networking devices for dialin via syncppp, or rawip. Set option
<tt/secure off/ to allow everybody to dial in, or set option <tt/secure on/
to only allow dialin by the isdn numbers you configure, which you set
up with <tt>isdnctrl addphone &lt;device&gt; in &lt;phonenumber&gt;</tt>.
It has been reported that you need to set option <tt/ms-dns/ for ipppd to
have successful IPCP negotion.
<item>Use the ttyI* devices for asyncppp or X.75.
</itemize>
Here some more details for setting up the ttyI* devices. The setup is like for
a serial port.  Start a getty (mgetty from Gert Doering is highly recommended)
on one of the ISDN devices (/dev/ttyI*). The entry in /etc/inittab looks like
this:
<code>
I0:56:respawn:/usr/local/sbin/mgetty ttyI0
I1:56:respawn:/usr/local/sbin/mgetty ttyI1
</code>
The init string needs to be entered in the <tt>mgetty.config</tt>, since
mgetty needs to know which MSN or EAZ to listen to. For example, if your MSN is
123456:
<code>
port ttyI0
modem-type data
speed 38400
init-chat &dquot;&dquot; ATZ OK AT&amp;E123456 OK AT&amp;B512 OK
</code>
For X.75 the block size was set to 512 bytes.
Alternatively you can enter the entire configuration onto a single line
in <tt>/etc/inittab</tt> (here printed on two lines!):
<code>
i0:45:respawn:/sbin/mgetty -D -m '&dquot;&dquot; ATZ OK AT&amp;E123456 OK
AT&amp;B512 OK' -s 38400 ttyI0
</code>
The most elegant way is to use iprofd. This daemon takes advantage of
the <tt>AT&amp;W0</tt> command in the i4l modem emulation. You start iprofd
with a path as parameter, e.g. <tt>&dquot;iprofd /etc/i4lprofile&dquot;</tt>
Then with minicom or another terminal program, open an ISDN tty
device and enter the necessary AT command by hand.
When finished, enter the command <tt>AT&amp;W0</tt>, then the kernel notifies
iprofd to write the current configuration to the file. From now on it is enough
to start iprofd in you isdn init script, and to initialize the appropriate
ISDN tty devices with <tt>ATZ</tt>.

<sect1> dialin_manyparallel: How can I allow several people to call in  
to me at the same time?  
<label id="dialin_manyparallel">
<p>
You have to configure exactly as many gettys or network interfaces as the
number of people allowed to call in at one time. These gettys or network
interfaces can be set to the same MSN, since several people can be
connected to a MSN at the same time (as long as there are B channels free).
However, not more than one getty can be assigned to a single ttyI* device.

<sect1> dialin_manycards: When using several ISDN cards, how can I react  
upon on a call received via a specific ISDN card?  
<label id="dialin_manycards">
<p>
You can use the EAZ mapping feature for this to map incoming MSN numbers
to new internal MSN numbers, in the same way as described for question
<ref id="dialout_manycards" name="dialout_manycards">. Usage of a card can be prevented by
using the dash during the mapping. Please note that it is not possible to
have any limitations based upon the B channel, since channel assignment
is normally done by the exchange.

<sect1> dialin_analogditalsamettyi: Can I configure a ttyI* device to  
accept both digital and analog modem dialins?  
<label id="dialin_analogditalsamettyi">
<p>
Since the digital mode requires different register settings than the analog
mode, this is not possible. Therefore you have to set up a two dedicated
devices for this purpose. Please note that analog modem dialins are only
possible if card and isdn4linux driver support it, which is only the case
for a few cards.

<sect1> dialin_fixedip: How can I assign fixed ip addresses per user who  
dials in via ipppd?  
<label id="dialin_fixedip">
<p>
Just specify the fixed ip address with the user name and password in the
pap/chap-secrets file (see man ipppd).

<sect1> dialin_hdlc: Someone would like to dial in to my mgetty with HDLC. Is  
ttyI1 correct, or do I have to start with ttyI0?  
<label id="dialin_hdlc">
<p>
No, it doesn't matter. It also has nothing to do with the number of the
B channel (0 or 1). You just have to activate HDLC in the init string
(ATS14=3).

<sect1> dialin_autoppp: Is it possible with mgetty to automatically start pppd  
when LCP frames are received?  
<label id="dialin_autoppp">
<p>
Yes, it is. This feature is called `AutoPPP'. See the configuration for
mgetty.

<sect1> dialin_passwd: How can I have (i)pppd check passwords from /etc/passwd  
instead of /etc/ppp/pap-secrets when someone dials in?  
<label id="dialin_passwd">
<p>
ipppd needs to be started with the options &dquot;login&dquot; and
&dquot;auth&dquot;. In /etc/ppp/pap-secrets, each user must have the
following line to allow only certain users:
<code>
login-name * &dquot;&dquot; *
</code>
To allow all users simply:
<code>
* * &dquot;&dquot; *
</code>
The latter can also be achieved when the file pap-secrets does not
exist.

<sect1> dialin_ignored: I keep getting the message &dquot;isdn_tty: call from  
XXX - YYY ignored&dquot;. Why does isdn4linux (syncPPP) ignore this dialin  
attempt?  
<label id="dialin_ignored">
<p>
There are two possible explanations. Either your own MSN (here: YYY)
is not correctly set with &dquot;isdnctrl eaz interface YYY&dquot;. Or
&dquot;isdnctrl secure interface on&dquot; was set, without allowing calls from
the incoming number (here: XXX) with &dquot;isdnctrl addphone interface in
XXX&dquot;.

<sect1> dialin_async: A SunISDN tries to dial into my i4l system.  
<label id="dialin_async">
<p>
The Sun tries to communicate with asyncPPP. ipppd can't handle
this, you have to use the ttyI* devices and the standard pppd.



<!-- Callback
-->

<sect> callback: Callback  
<label id="callback">

<sect1> callback_delay: An incoming call is rejected by i4l. i4l then  
calls back. The reject is not recognized by the other side which keeps  
on dialing to i4l.  
<label id="callback_delay">
<p>
Most problems with callback can be solved by adjusting the callback
delay with <tt>isdnctrl cbdelay</tt>. One second on the triggering side A
(set callback mode to out) and two seconds on the triggered side B
(set callback mode to in) has been successful in most cases.
<p>
The reason for the problem is a design bug in the link level driver.
A calls B to trigger a callback. B rejects the call and calls back to A,
establishing a working connection within less than 4 seconds.
However, the triggering call from A to B will need 4 seconds to be
terminated by the ISDN provider (giving other devices on B's
side a chance to take the call). When it is finally terminated, the
working connection from B to A is unfortunately also terminated.

<sect1> callback_cisco: Somehow i4l can not callback a Cisco?  
<label id="callback_cisco">
<p>
Torsten Hentschel <tt><htmlurl url="mailto:Torsten.Hentschel@DInet.de"
name="Torsten.Hentschel@DInet.de"></tt> wrote on 3 Oct 1996:
<quote>
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 &dquot;dial on
demand&dquot; 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 &dquot;ping RemoteIP&dquot; 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 &dquot;callback
client&dquot; = 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).
</quote>
Torsten Hentschel <tt><htmlurl url="mailto:Torsten.Hentschel@DInet.de"
name="Torsten.Hentschel@DInet.de"></tt> additionally wrote on
20. Nov 1996:
<quote>
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.
</quote>

<sect1> callback_ascend: Callback from an Ascend works only when I set  
&dquot;Active=Yes&dquot; in the Ascend menu; but then the Ascend keeps calling  
me, even when my machine is off.  
<label id="callback_ascend">
<p>
Ulrich Klein <tt><htmlurl url="mailto:ulik@hprc.tandem.com"
name="ulik@hprc.tandem.com"></tt> wrote on 14 Dec 1996:

Somewhere in the Ascend menus you can set &dquot;dial broadcast&dquot; to
&dquot;no&dquot; or &dquot;off&dquot;. 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.

<sect1> callback_banzai: How can I callback a Banzai!?  
<label id="callback_banzai">
<p>
Jan-Olaf Droese <tt><htmlurl url="mailto:jano@layla.RoBIN.de"
name="jano@layla.RoBIN.de"></tt> 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:
<code>
isdnctrl callback isdn0 in
isdnctrl cbdelay isdn0 1
</code>

<sect1> callback_microsoft: Does isdn4linux support Microsoft Callback  
(CBCP)?  
<label id="callback_microsoft">
<p>
Yes, this is implemented in ipppd. To enable it you have to set the
parameter &dquot;callback 6&dquot; as an ipppd option on the client side
for an admin managed callback. This means the server will call back on
the number it has been configured for.
More interesting is a user managed callback, since the number to be called
back can be provided by the user. Set the paramter
&dquot;callback 123456&dquot; if you want to be dialed back on number 123456.
To start the callback trigger it from the client via:
<code>
isdnctrl cbdelay &lt;device&gt; 5
isdnctrl callback &lt;device&gt; out
</code>
Please remember that using the CBCP callback always requires both parties to
connect and exchange data, so telephone charges will be incurred.
Please note that the man page may be confusing about the callback parameter for
ipppd. Please note these hints from NOTES.IPPPD:
<verb>
- 'callback type[,message]' enables the callback feature
  also UNTESTED!
  ie: 'callback 0'       -> simple callback (info via auth. etc.)
      'callback 3,12346' -> us E.164 (tel) number 123456 for callback
      'callback 6' is different. This value means, that the whole negotiation
  is done with a seperate protocol after the authentification phase. Currently
  it's not possible to set any options in this case. The ipppd accepts
  everything from the remote side.
</verb>
The server side is not tested so far - please let me know if you have some
feedback on using CBCP as a server).

If you have a Red Hat distribution, setting the following parameters in
ifcfg-ippp0 might do the trick for an admin managed callback:
<code>
CALLBACK=out
CBDELAY=5
CBCP=on
</code>
For user managed callback please follow the hints on:
<url url="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125710">.


<!-- Isdnlog
-->

<sect> isdnlog: Isdnlog  
<label id="isdnlog">

<sect1> isdnlog_rates: Where do I get the latest rate information?  
<label id="isdnlog_rates">
<p>
This is the homepage of the rate data crew:
<tt><url url="http://sourceforge.net/projects/rates4linux"></tt>. There you
can download the latest rate files (which change very frequently),
or have a look at the latest rate news.

There is also a mailing list available for this kind of stuff. Subscribe
by sending an email with subject "subscribe" to:
<tt><htmlurl url="mailto:rates4linux-users-request@lists.sourceforge.net"
name="rates4linux-users-request@lists.sourceforge.net"></tt>
(send "help" in your subject to get instructions).
To write to the mailing list, send an email to:
<tt><htmlurl url="mailto:rates4linux-users@lists.sourceforge.net"
name="rates4linux-users@lists.sourceforge.net"></tt>.

<sect1> isdnlog_servicetype: Can I see the service type from an incoming call  
in the output from isdnrep?  
<label id="isdnlog_servicetype">
<p>
Andreas Kool <tt><htmlurl url="mailto:akool@Kool.f.EUnet.de"
name="akool@Kool.f.EUnet.de"></tt> wrote on 3 Dec 1996:

Indirectly in isdnrep, yes -- as soon as you enter an alias for the
decoded service types in your &dquot;isdnlog.conf&dquot; ...

<sect1> isdnlog_callerid1: Why don't I always receive from the German Telekom  
the number of a caller (&dquot;Caller ID&dquot;)?  
<label id="isdnlog_callerid1">
<p>
For data privacy reasons, telephone numbers from the analog network
are not transmitted unless the caller has explicitly allowed the Telekom
to do so (costs nothing).

Those with an ISDN connection, on the other hand, must explicitly
deny permission for the Telekom to transmit the number, or apply to
be able to do this on a call-by-call basis (CLIR). Call-by-call
denial is free; call-by-call transmission costs extra. However, it
seems to be <em>very</em> difficult for the Telekom to configure this
correctly on the first try.  If you depend on the transmission of
Caller ID, you should check closely that everything is configured
correctly.

<sect1> isdnlog_callerid2: Do I receive the Caller ID from foreign calls  
(German Telekom)?  
<label id="isdnlog_callerid2">
<p>
Yes, with calls from countries that don't view Caller ID quite as strictly
as does Germany (e.g. USA, Canada).

<sect1> isdnlog_spoofcallerid: I've heard that actually two Caller IDs are  
transmitted?  
<label id="isdnlog_spoofcallerid">
<p>
That's right, there's one that is &dquot;User-Provided, not
screened&dquot;, and the other is &dquot;Network-Provided&dquot; (from the
telephone company). As the name says, the first one is provided by the
user, whereas the second one is transmitted by the network.
Providing a caller ID is only possible for a PBX connected in
Point-to-point configuration with the feature &dquot;CLIP no
screening&dquot;.

<sect1> isdnlog_betterlogging: Why doesn't isdnlog record the number  
dialed by my other ISDN devices, since it records the charges?  
<label id="isdnlog_betterlogging">
<p>
Because the ISDN card, like all ISDN device, has separate lines for
sending and receiving (RX and TX lines). Isdnlog has to read data
from the receiving line to learn the number dialed. This isn't possible,
at least for the Teles cards, as Karsten Keil
<tt><htmlurl url="mailto:keil@isdn4linux.de" name="keil@isdn4linux.de"></tt>
wrote on 12 Feb 1997:
<quote>
This is the case for all cards with 1 Siemens ISAX; it has (and needs)
only 1 sender and 1 receiver.
Theoretically, it's possible to read the entire D channel with just one
receiver (even with the ISAC); the D bits from the RX line are copied
(somewhat delayed) to the TX line, over which the access control
(collision recognition) of the SO bus takes place.
Unfortunately with the ISAC it's not possible to read the echo bits
in TA mode from a register.
</quote>
See the next questions for a possible solution.

<sect1> isdnlog_reversedcard: How can I get isdnlog to also show the telephone  
numbers for other ISDN devices?  
<label id="isdnlog_reversedcard">
<p>
There are several possibilities.
<itemize>
<item> COLP: First, the German Telekom offers the service
COLP (Connected Line Identification Presentation, ca. DM 10 per month per
basic line) that returns all data sent. This can then be read by isdnlog
(=2.52) from the TX line.
<item> Reversed card/dual mode: Alternatively, isdnlog offers the possibility to
work with a second &dquot;re-poled&dquot; ISDN card. &dquot;re-poled&dquot;
means that the RX line is connected to the TX connection of the card; the
RX line of the card should not be connected to any line! (even if other
documents might tell you something else).  Because of this setup, this ISDN
card cannot be used for anything else. This is called a reversed card, or the
dual mode. The whole thing looks something like this:
<verb>
      3 -- RX+ 2a ---------------\
ISDN  4 -- TX+ 1a -- open         ------------  ISDN
bus   5 -- TX- 1b -- open         ------------  card
      6 -- RX- 2b ---------------/
</verb>
Please note that this only works when the second card is an ISAC based cards
(e.g. old Teles cards, Fritz! classic), since it requires a special
bug/feature of that chip. All other cards, like IPAC based cards (e.g. ELSA
QS1000pro) will not work in the role of a re-poled card.
Please note that this will only work on the standard BRI interface,
since for the more expensive PRI interface no card is available which
can be used (PRI is a point-to-point connection anyway).

<item> HFC cards: some HFC-PCI based cards allow a special feature where one
of the B channels can be sacrificed in exchange for reading the complete
D channel protocol - with just one single card. This is also supported
by isdn4linux. Set the HFC card in the following way:
<code>
hisaxctrl &lt;driver_id&gt; 1 4
hisaxctrl &lt;driver_id&gt; 10 1
hisaxctrl &lt;driver_id&gt; 12 1
</code>
You have to give isdnlog the command line option '-1' so that it
makes use of the HFC option.

Please note that a plain HFC-S does not work for hardware reasons, it has
to be a newer one. If your card works with Hisax type 35 or 37, then it
should work.

Please also note that there is no known card for logging on a PRI interface
in this way (also, the PRI interface is point-to-point, therefore only
one device can be connected).


<item> PBX: A third (theoretical) possibility exists for those who have
their own PBX to which the other devices are connected. If the PBX can
protocol all outgoing calls, this can be read (usually over a serial port).
There is a reason why isdnlog has not support for this until now. To evaluate
this data, isdnlog has to be able to access the date immediately after
the RELEASE COMPLETE, before any new data is sent on the D channel. The
PBXs tested up to now have all been too slow (in particular the widely
used ISTEC). The only possibility is to combine the data afterwards. But
then there are problems with synchronizing the different times. Whoever
want to attempt to do this is very welcome.
</itemize>

<sect1> isdnlog_rategraphic: How can I display the data transfer rates  
graphically?  
<label id="isdnlog_rategraphic">
<p>
You can use &dquot;xisdnload&dquot;. Clemens Perz
<tt><htmlurl url="mailto:listperz@gwsnet.ttt.de"
	     name="listperz@gwsnet.ttt.de"></tt> on 6 Feb 1997 knew of another
possibility:

On Sunsite I found a little tool for the console called netload, and
apapted it for the ISDN interfaces. With it you can quite easily see
the current traffic on the line. It can be found at:

<tt><url url="ftp://ftp.region.trier.de/pub/unix/linux/sources/network/isdn/netload-0.92.isdn.tar.gz"></tt>

Simply start with <tt>netload isdnxx</tt>.

<sect1> isdnlog_2callerid: Isdnlog (=2.52) shows for a caller <em>two</em>  
telephone numbers! Which one is correct?  
<label id="isdnlog_2callerid">
<p>
The caller has most likely activated the (costly) feature CLIP
(= Calling Line Identification Presentation, no screening), which means
any telephone number can be transmitted. See the question &dquot;I've heard
that actually two Caller IDs are transmitted?&dquot;.

Andreas Kool <tt><htmlurl url="mailto:akool@Kool.f.EUnet.de"
name="akool@Kool.f.EUnet.de"></tt> wrote on 26 Jan 1997:

In any case, you can only fool software/PBXs that do not evaluate
the screening indicator - isdnlog with version 2.52 shows both the
correct *and* the faked telephone number. 'CLIP, no screening' was
actually designed for transmitting internal company numbers in the
public network.

<sect1> isdnlog_soundbusy: I've set up a script to play sound per cat on  
/dev/sound or some other device. When several events occur, then there is an  
error: <tt>Can't open output file '/dev/sound': Device or resource busy</tt>  
<label id="isdnlog_soundbusy">
<p>
Only one process at a time can access the sound device. You need an upper
instance that coordinates access to the sound device. NAS (network audio
system), and rplay can be used for this.

<sect1> isdnlog_noshell: Isdnlog should call a program with redirected output  
(e.g. <tt>play anruf.au 2/dev/null</tt>). Why does ISDN tell me  
<tt>Can't start '/usr/local/bin/play anruf.au 2/dev/null' with execvp()</tt>?  
<label id="isdnlog_noshell">
<p>
Because isdnlog is not a (Bourne) shell ;-) Isdnlog can only start
<bf>real</bf> programs. Just write a little script for it and make it
executable (chmod +x):
<code>
&num;!/bin/sh
/usr/local/bin/play anruf.au 2/dev/null
</code>

<sect1> isdnlog_blankscreen: When dialing out, the screen goes momentarily black?  
<label id="isdnlog_blankscreen">
<p>
This may happen when you start isdnlog with the options <tt>-t1</tt>
or <tt>-t2</tt>, then the time is synchronized with the digital
switching station. The screen saver thinks that more than x minutes have
passed, which causes a short blackout of the screen.

<sect1> isdnlog_nologging: Isdnlog does not log any incoming call for me?  
<label id="isdnlog_nologging">
<p>
Please verify whether your setup complies with the restrictions given in the
isdnlog man page:

Isdnlog only works with the HiSax isdn driver. Other cards with their own
driver are not supported. Additionally you need to enable d-channel logging
(you can use "hisaxctrl &lt;DriverId&gt; 1 4" to do that, e.g.
"hisaxctrl line0  1  4").  Isdnlog can only log outgoing calls that
originate from your isdn card, and incoming calls. To get information
about outgoing calls from other isdn devices (e.g. telephones), you need
a second Teles isdn card, with crossed lines. Such a card is not usable
for communicating, but can log outgoing calls from any device.

See also question <ref id="isdnlog_reversedcard" name="isdnlog_reversedcard">
for using two ISDN cards for logging.

<sect1> isdnlog_enoughdata: How can I check whether isdnlog receives enough  
information from the kernel drivers?  
<label id="isdnlog_enoughdata">
<p>
First stop isdnlog (e.g. "killall isdnlog"), then run "cat /dev/isdnctrl0".
When you trigger some activity on the isdn line (e.g. by initiating an
incoming call) you should see lines starting with "HEX:" or "D2:" in the
output of the cat command. If these lines are missing then check your
configuration of the kernel drivers.

<sect1> isdnlog_database: How can I set up isdnlog with database support?  
<label id="isdnlog_database">
<p>
You have to rebuild isdnlog for this. You can find some instructions
(in German) on:
<url url="http://lists.suse.com/archive/suse-isdn/2005-May/0043.html">.


<!-- Audio
-->

<sect> audio: Handling Voice with ISDN  
<label id="audio">
<p>
(Most of the answers you will find here are taken from the - now
unfortunately outdated - vbox manual by
Matthias Hessler <tt><htmlurl url="mailto:hessler@isdn4linux.de"
name="hessler@isdn4linux.de"></tt> and
Bernhard Hailer <tt><htmlurl url="mailto:dl4mhk@lrz.uni-muenchen.de"
name="dl4mhk@lrz.uni-muenchen.de"></tt>; you can get the manual at:

<tt><url url="http://www.lrz-muenchen.de/&tilde;ui161ab/www/isdn/"></tt>

- click on &dquot;Audio!&dquot; (still in German we're afraid - sorry...)
They are currently very outdated, but may give you a few hints?

A newer place has now come up as a place for further vbox development.
Please check it out:
<tt><url url="http://innominate.org/projects/vbox/index.php3"></tt>

<sect1> audio_links: Where can I find helpful links regarding vbox?  
<label id="audio_links">
<p>
There are several scripts available to be used in connection to vbox,
but the author is not up to date. Here is the latest one I received
information about:
<tt><url url="http://innominate.org/projects/vbox/index.php3"></tt>
Please send me information if you know more helpful links, or howtos,
or whatever useful...

Also please note the documentation in the kernel source package:
<tt>/usr/src/linux/Documentation/isdn/README.audio</tt>

<sect1> audio_format: What is the format of the audio messages (.msg) vbox  
plays when it answers a call?  
<label id="audio_format">
<p>
You can get the format from the messages with rmdgetheader. The samples
messages in the packages are recorded using format 4 (the latest
Zyxel-Compression)


<sect1> audio_recordmsg: How can I record my own messages for vboxgetty?  
<label id="audio_recordmsg">
<p>
First call yourself on the number you configured vboxgetty to answer and
leave a message. Then rename the message to *.msg (standard.msg for the
main answering message) and copy it to the directory where all the
messages are kept (usually /var/spool/vbox/user/messages where user is
the user for which vboxgetty is configured).
You can also record a message using a microphone and the soundcard.

<sect1> audio_play: How can I play audio messages locally using /dev/audio?  
<label id="audio_play">
<p>
This is best achieved with vbox using format 6 (uLaw - must be compiled
in). You can then easily play the messages using:
<code>
cat xxx  /dev/audio
</code>
where xxx is the message-file.

<sect1> audio_convertto: How can I convert audio messages which where recorded by  
vbox to other formats (i.e. from uLaw to WAV)?  
<label id="audio_convertto">
<p>
The standard tool for converting all sound formats is SOX. SOX is
available as source code for both UNIX and DOS. You can get it at:

<tt><url url="http://www.powerweb.de/mpeg/util/msdos/sox10c.zip"></tt>

(including sources that compile under Linux).

<sect1> audio_convertfrom: How can I format WAV for uLaw (for my vbox  
announcement message)?  
<label id="audio_convertfrom">
<p>
We receive the following tip form Christian Stueble
<tt><htmlurl url="mailto:stueble@ls6.informatik.uni-dortmund.de"
name="stueble@ls6.informatik.uni-dortmund.de"></tt> on 15 Jan 1997:

For me, the following (somewhat indirect) method works:
<code>
sox file.wav -r 8000 file.ul rate
rmdcatheader -u file.ul  file.msg
cat file.ul  file.msg
</code>
It could be that you have to give different parameters to sox.
As a first test you can try file.msg  /dev/audio, you should
be able to hear something.

<sect1> audio_dtmf: How can I improve the recognition of (DTMF) dial tones?  
<label id="audio_dtmf">
<p>
You can adjust the parameters DTMF_TRESH, SILENCE_TRESH, and H2_TRESH in file
<tt>linux/drivers/isdn/isdn_audio.c</tt>. A DTMF tone is recognized
if the amplitude of the correct frequency is larger than DTMF_TRESH
and the amplitude of the second harmonian frequency is smaller than
H2_TRESH.
If a dial tone is recognized when no dialing took place, try to increase
DTMF_TRESH and/or decrease H2_TRESH. However, test with many
telephones - the current parameters were already set after some tuning.


<!-- Audio Troubleshooting
-->

<sect1> audio_e0265: My vboxgetty gets a modem timeout, and reports error  
E0265.  
<label id="audio_e0265">
<p>
Probably you need a patch that has been posted recently (8th December 1999)
on the mailing list.

<sect1> audio_noanswer: My vboxgetty does not answer any incoming calls.  
<label id="audio_noanswer">
<p>
vboxgetty needs &dquot;.vboxrc&dquot; in the home directory of the user for which
vboxgetty is configured. The number of rings is taken from this file.

<sect1> audio_nocat: If vboxgetty has recorded a message in a format which can  
not be played using &dquot;cat xxx/dev/audio&dquot; how can I still hear the  
message?  
<label id="audio_nocat">
<p>
Vboxgetty can play all formats. You can copy the message as the
standard message (standard.msg in the messages directory) and call
yourself, the message will be played then. (Don't forget to copy back the
original message when you are done :-) ). See question
<ref id="audio_recordmsg" name="audio_recordmsg">.

<sect1> audio_earlyrecording: At the beginning of a message recorded by vboxgetty,  
there's often a part of my own announcement?  
<label id="audio_earlyrecording">
<p>
This is a known bug that occurs when switching between the playing of
the announcement and recording the message. Up to now there is no
known workaround.


<!-- Countryspecific pecularities
-->

<sect> Supported Countries
<label id="countries">

<sect1> country_which: In which countries does isdn4linux work?  
<label id="country_which">
<p>
We are aware of at least the following countries:
<itemize>
<item>Austria (see question <ref id="country_austria" name="country_austria">)
<item>Australia
<item>Brazil (see question <ref id="country_brazil" name="country_brazil">)
<item>Belgium
<item>Denmark
<item>Finland
<item>France (see question <ref id="country_france" name="country_france">)
<item>Germany
<item>Hungary
<item>India
<item>Ireland
<item>Israel
<item>Italy (see question <ref id="country_italy" name="country_italy">)
<item>Japan
<item>Luxemburg
<item>Norway
<item>Pakistan (see question <ref id="country_pakistan" name="country_pakistan">)
<item>Peru
<item>Poland
<item>Portugal (see question <ref id="country_portugal" name="country_portugal">)
<item>Singapore
<item>Spain
<item>Sweden
<item>Switzerland (see question <ref id="country_switzerland" name="country_switzerland">)
<item>The Netherlands (see question <ref id="country_netherlands" name="country_netherlands">)
<item>United Arab Emirates
<item>United Kingdom (see question <ref id="country_uk" name="country_uk">)
<item>USA (see question <ref id="country_northamerica" name="country_northamerica">)
</itemize>
If your country is not on this list does not mean it is not supported. It just
means we have not seen a confirmation about its usage there. Check the mailing
list for other users from your country.

<sect1> country_certified: Is isdn4linux approved for use by the  
telecommunications authorities?  
<label id="country_certified">
<p>
That depends on the driver used, and your country. We only have information
about Germany (send me information if you have information about other
countries). However, that covers most other European countries as well,
since a certification in one EC country has to be accepted in all others.
These drivers are certified for use in Germany:
<itemize>
<item>Active cards: the approval covers the entire card including its
firmware. Thus the approval also covers the use of these cards with
isdn4linux.
<item>Elsa Quickstep series cards (new name Microlink PCI)
<item>Eicon Diva 2.01 PCI
<item>Teles 16.3 ISA (with Siemens chipset)
<item>Sedlbauer Speedfax+ PCI
<item>Passive cards: all cards based on the HFC-S chipset.
</itemize>
Actually, since April 2000 the rules for certification have changed. Now
the producer of an ISDN card has to do only hardware tests, the driver is
not part of the certification anymore. This applies to the whole European
Community.

<sect> 1tr6: German Pecularities for 1TR6  
<label id="1tr6">

<sect1> 1tr6_eaz: Which EAZ should I use for i4l?  
<label id="1tr6_eaz">
<p>
You can use all available EAZ. However, two EAZ have a special meaning and
can cause problems:
<verb>
EAZ 0: global call (all telephones ring)
EAZ 9: global call (no telephone rings)
</verb>
Gernot Zander <tt><htmlurl url="mailto:hifi@scorpio.in-berlin.de"
name="hifi@scorpio.in-berlin.de"></tt> wrote about this on 6. Jan 1997:
<quote>
I would not use 0, for my taste it is too likely that i4l will steal
all voice connections.
</quote>

<sect1> 1tr6_extension: I use 1TR6 on an extension - the extension number has  
more than one digit (e.g. 206). What is my EAZ?  
<label id="1tr6_extension">
<p>
Jens Ey <tt><htmlurl url="mailto:jens@jeyhh.shnet.org"
name="jens@jeyhh.shnet.org"></tt> wrote on 10 Jan 1997:

The EAZ for extensions is usuAlly the last digit of the extension number.
As EAZ for the Linux computer you should then enter a '6'.

<sect1> 1tr6_spv: What is a SPV?  
<label id="1tr6_spv">
<p>
SPV stands for &dquot;semipermanente Verbindung&dquot; (semipermanent connection)
and is a (soon to be obsolete) speciality of the German Telekom. Like
a leased line, the calling partner is fixed, however the connection
is only established as needed (which occurs very quickly, much quicker
that a dial connection). Since the Telekom can use the line for other
things when it's not needed, the SPV is cheaper than a leased line.

This SPV is not to be confused with the Austrian understanding of SPV. The
Austrian `SPV' has one channel leased line, and one channel for dialing.

<sect1> 1tr6_spvdial: Does isdn4linux support SPVs? How?  
<label id="1tr6_spvdial">
<p>
To switch on the support for SPVs, add an &dquot;S&dquot; before the number
to be dialed. This works (quite well) for modem emulations as well
as for defined network interfaces.


<sect> Other countries


<sect1> country_austria: Austria: We have neither an MSN nor an EAZ, only a  
normal plain telephone number. What do we have to use for i4l?  
<label id="country_austria">
<p>
In Austria ISDN lines are by standard installed <em>without</em> MSN (which is
different from Germany). That means when somebody calls the installed ISDN
number the called party gets signalled a &dquot;global call&dquot;. i4l then
says &dquot;incoming call without CPN&dquot; - &dquot;CPN&dquot; means called
party number. Solution: Set the incoming &dquot;MSN&dquot; (in reality: none) to
&dquot;0&dquot;, then i4l responds to the global call. Otherwise it waits for
the signalling of the number you told i4l, and that won't happen (happens only
for *additional* MSN). The same applies to the setup of your getty.

On the other hand you should set the outgoing MSN correctly (without area
code) -- however, a wrong MSN will be replaced with the correct one by your
telecommunications provider.

<sect1> country_brazil: Brazil: How does our MSN look like?  
<label id="country_brazil">
<p>
For use with Telemar you have to configure your MSN as your phone number
without the leading area code.

Brazil is using EuroISDN. The ISDN service DVI which was launched by Telemar
is based on a hardware solution from Teles (BRI PCI card), which has to be
configured as NETjet card. However, since this card is very incompatible
to the motherboards sold in Brazil, Telemar also offers the option of a
Teles 16.3c ISA. You may be able to find some configuration help on
<url url="http://www.olinux.com.br"> for this card.

<sect1> country_france: France: How does our MSN look like?  
<label id="country_france">
<p>
If you don't have MSN, you need to specify as local number only the last 4
digits of you phone number. A good thing is that you can also use
sub-addressing. If your phone number is 01 41 33 67 87, and you want to use
sub-address 02, then configure the local phone number of the HiSax driver as
6787.02 .

<sect1> country_italy: Italy: What does our MSN look like?  
<label id="country_italy">
<p>
isdn4linux also works in Italy (ICN card). The MSN must be the phone number
with the Italian area code, and since middle of 2001 includes the leading 0.
For example, if my phone number is 72004681 and my area code is 045, my MSN
is 04572004681.  Now with the setting AT&amp;E04572004681 isdn4linux works fine.

<sect1> country_netherlands: Netherlands: What does our MSN look like?  
<label id="country_netherlands">
<p>
In The Netherlands the MSN includes (as opposed to the German
Telekom) <em>also the area code</em> - but without the leading zero.

<sect1> country_northamerica: North America: Can we use isdn4linux in North  
America?  
<label id="country_northamerica">
<p>
Yes, you can use isdn4linux in North America. However, some specialties
apply.

In North America the telephone company will only provide a U instead of an S
interface. This means that the customer rather than the telephone company
has to supply the network terminator (NT-1). Your easiest solution
is a card which has an integrated NT-1 and supports the U interface.
Alternatively buy an external NT which translates between U and S interface,
and connect your ISDN card with S interface (without NT-1) to it.

In North America the channel protocol NI-1 is being used. NI-1 is related
to DSS1 (both are Q.931 Protocols), but both have totally different groups
of functions. Support for NI-1 has recently been added to HiSax, the driver
for passive cards, with great help from Traverse Technologies:
<tt><url url="http://www.ttcomms.com"></tt>.
Since they helped to implement and verify NI-1 usability, we would recommend
you buy their card NETspider-U (with integrated NT-1), as a thank-you
for their contribution to isdn4linux open source development.

See Documentation/isdn/README.HiSax for details on how to set up your
system with HiSax (protocol type is 4, give SPID together with your own
number in the form of &lt;OWNNUMBER&gt;:&lt;SPID&gt;).

Quite some time ago, the firm &dquot;Spellcaster&dquot; has written their own
isdn4linux driver for their (active) cards. Both BRI and PRI cards are
available. More information is available on:
<tt><url url="http://www.spellcast.com"></tt>

Also, the active Eicon DIVA cards work fine in North America and have
5ESS and NI drivers, which are currently ported to UltraSparc.


<sect1> country_pakistan: Pakistan: What should we use as MSN?  
<label id="country_pakistan">
<p>
It seems that no MSN functionality is supported. Therefore the MSN should be
set to &dquot;0&dquot;.

<sect1> country_portugal: Portugal: What should we use as MSN?  
<label id="country_portugal">
<p>
As long as only one telephone number or MSN was applied for, the telephone
company sends no caller ID. Therefore the MSN should be set to &dquot;0&dquot;.
If more than one MSNs was applied for, then these should be set as usual.

<sect1> country_switzerland: Switzerland: We have neither an MSN nor an EAZ,  
just a plain telephone number. What do we have to use for i4l?  
<label id="country_switzerland">
<p>
In Switzerland usually you have to use the telephone number without area
code. For old ISDN numbers where you have been assigned ten numbers in a
row this may be different; in that case use the <em>last digit</em> of your
telephone number as your MSN/EAZ (&dquot;6&dquot; if you have the telephone
number &dquot;123456&dquot;).

<sect1> country_uk: UK: What should we use as MSN?  
<label id="country_uk">
<p>
It depends on your ISDN option.
<itemize>
<item> ISDN: Does not allow normal MSNs in UK. Each MSN is actually a single
digit, 0 - 9, corresponding to the last digit of the actual phone number.
You either have *no* MSNs (then configure isdn4linux to use '0' as MSN,
e.g. with <tt>AT&amp;E0</tt>), or 10 MSNs; you then always get a block of
10 sequential telephone numbers
(xxx0-xxx9), of which the last digit (0-9) is your MSN (0 is used in case
you use an invalid number).
<item> ISDN2e: Seems to be normal EuroISDN. You are assigned MSNs which you
can use and configure for isdn4linux. The MSN is reported to consist of the
last 6 digits of your telephone number (try to add digits from your area
code, if the local number part is shorter than 6 digits).
<item> BTHH (BT HomeHighway): additionally to 2 ISDN ports it includes two
analog lines with separate telephone number - but calls to and fro for those
won't be signalled on the ISDN line, even so they use up a B-channel.
Additional MSN are NOT available (therefore use '0' as MSN to configure
isdn4linux). Charge info is possible for extra cost. Configure isdn4linux
only with your 'digital number' as MSN.
<item> BTBH (BT BusinessHighway): The additional paperwork including a
credit-check enables you to get MSNs and other extras for extra cost.
Otherwise pretty much like BTHH. Configure isdn4linux to use your 'digital
number' and/or your MSNs.
</itemize>
Please note that BT offers an unexpected special "feature" on
international calls. For international data calls you have to dial
000&lt;country_code&gt; (three zeros), rather than the 00&lt;country_code&gt;
(two zeros) for international voice calls.

By the way: for a BT Speedway card try to select AVM Fritz card (either
ISA or PCI - depends on what you got; see question <ref id="hardware_fritz" name="hardware_fritz">).

Since about November 2001, all BT home highway and possibly Business Highway
NTE boxes come with a built in USB terminal adapter. This terminal adapter is
based on the ST-5481 chipset. Load the module st5481 for this device, then
set up your isdn configuration with isdnctrl.

Also, check out <url url="http://www.wurtel.cistron.nl/i4l-howto-uk.html">.

<sect> misc: Miscellaneous  
<label id="misc">

<sect1> misc_standards: Which standards apply to the ISDN protocol layers?  
<label id="misc_standards">
<p>
These are the main standards:
<itemize>
<item> Layer 1: ITU I.430 and ETSI 300 012-1
<item> Layer 2: ITU Q.921 and ETSI 300 125-1
<item> Layer 3: ITU Q.931 and ETSI 300 102-1 (plus some changes and
clarifications in ETSI 300 403)
</itemize>
All layers are also described in TBR3. For study, the standards are freely
available from <url url="http://www.etsi.org">.

<sect1> misc_nonullcable: Can I connect two ISDN devices directly with a kind  
of &dquot;null modem cable&dquot;?  
<label id="misc_nonullcable">
<p>
This is only possible if one of the cable can run in NT mode (see glossary
on what this is: <ref id="glossary_ntmode" name="glossary_ntmode">). Only a few cards allow it,
all others need an NTBA or PBX with an internal bus to communicate with
each other. See question <ref id="feature_crossedcable" name="feature_crossedcable">.

<sect1> misc_uisdn: Can isdn4linux run in parallel to UISDN?  
<label id="misc_uisdn">
<p>
Yes. Both ISDN packages load the module isdn.o, otherwise the naming conventions
are different. Tip: rename Urlichs isdn.o to uisdn.o, and change
lib/modules/modules.isdn (or whatever the file is called that lists the modules
and is read by the script) accordingly. Happily the default names of the ISDN
devices are also different.



<!-- Glossary
-->

<sect> glossary: ISDN specific words which are used in this FAQ  
<label id="glossary">
<p>
<descrip>
<tag/active card/
<label id="glossary_active">
Cards can come in different versions: passive, semi-active, active.
Active cards handle the D-channel and B-channel protocol in their hardware.
The extra hardware makes them more expensive, but better suited to use
where a low CPU usage is needed (e.g. when having many ISDN cards in one
computer). Because of their special hardware, a special driver is required.
Depending on the hardware/driver, special tasks like sending/receiving analog
G3 faxes may be very easy to implement - if you need these features, get one
of them.

<tag/AOC-D/
&dquot;Advice Of Charge During the Call&dquot;.

<tag/AOC-E/
&dquot;Advice of Charge at the End of the Call&dquot;. In Germany, this
service	is included in the &dquot;Komfort&dquot; connection.

<tag/BRI/
BRI means basic rate interface and is the most commonly used interface.
In Europe, a BRI includes 2 B-channels for data communication, and 1
D-channel for administration of the data communication. The alternative
is a PRI interface.

<tag/CLIP/
CLIP (Calling Line Identification Presentation) can be offered
by the ISDN provider. When you call somebody, then your telephone number
will be transmitted to the other phone.
The opposite of CLIP is CLIR.
In Germany, CLIP is the default.

<tag/CLIR/
CLIR (Calling Line Identification Restriction) can be offered by
the ISDN provider: one can (from call to call) restrict the
identification of one's own caller ID to the other party.
The opposite of CLIR is CLIP.
In Germany, this must be applied for but is without charge (however
call by call transmission of the caller ID costs extra).

<tag/COLP/
COLP (Connected Line Identification Presentation) can also be offered
by the ISDN provider. If you've applied for COLP, you get an extended
dialing protocol. You will receive feedback from your telecommunication
company who picked up your outgoing call. Normally, you will get the
same number as you dialed beforehand; however, with call diversion this
could also be a different number.
In Germany, it must be applied for, and costs extra. More information
than COLP can be obtained with the help of a reverse-connected ISDN
card.

<tag/CVS Tree/
The i4l developers have formed a team. The tool CVS allows the
members to easily make patches. The history of the project is also
thereby documented, and it is also not difficult to reproduce older
versions.

<tag/EAZ/
This is a German name for an MSN. In Germany, EAZ and MSN are used
as synonyms, though in theory one ought to differentiate according
to the protocol used. That which is called MSN in the Euro-ISDN
protocol was called EAZ in the German 1TR6-ISDN protocol (a German
predecessor to Euro-ISDN).

<tag/HDLC/
A widely used low-level protocol, usually used to connect your computer
with your internet provider. To connect to a computer mailbox, usually
X.75 is being used.

<tag/HSCX/
A Siemens chip which is, similar to ISAC, on many passive cards.
It takes over the serial bus from ISAC and demultiplexes when
receiving or multiplexes (i.e. inserts the bits in the correct
position) the B channels.

<tag/ISAC/
A Siemens chip which is, similar to HSCX, on many passive cards.
It is responsible for Level 1, so it sits (almost) directly on
the line. It handles the D channel protocol and sends the
S0 data to a special serial bus (IOM). When sending it does the
opposite.

<tag/leased line/
<label id="glossary_leased">
Your telecommunication company can hardwire the connection between
two of their ISDN users. Then these users are always connected to
each other without dialing and can not dial out to someone else any more.

<tag/MSN/
Unlike a normal telephone connection, an ISDN connection can have more
than one telephone number - each of these is called an MSN (Multiple
Subscriber Number).

<tag/NT/
NT is the abbreviation of network terminator. This is the interface
between an ISDN user and the ISDN provider. It is a small hardware box
to which the user has to connect his ISDN devices via a so called S0
interface.
In most European countries, the ISDN provider supplies the NT. A user in
North America usually has to buy one, therefore the NT is often integrated
into the ISDN card there.

<tag/NT mode/
<label id="glossary_ntmode">
When multiple devices are connected to the ISDN connection, then all
user device behave as slaves, where the network terminator (NT) behaves
as master and synchronizes the communication on the S0 bus. The special
behavior of the network terminator is called NT mode. User devices are
normally not capable of running in NT mode.
As a result, user devices can not communicate with each other even when
they are connected via a crossed cable.
Only some special ISDN cards (HFC chipset) are capable of running in NT mode,
and can directly communicate with other ISDN user devices via a crossed
cable.

<tag/multi-device mode/
<label id="glossary_multidevicemode">
Your ISDN interface can be configured either in multi-device mode
(in German: Mehrgeraeteanschluss), or in point-to-point mode (in German:
Anlagenanschluss).
The multi-device mode is the normal connection mode for private ISDN users
or very small business users. The user can attach multiple devices to the
ISDN connection. The ISDN provider will assign a small number of fixed
telephone numbers (usually up to 10 MSN), if any, to the ISDN connection.

<tag/passive card/
<label id="glossary_passive">
Cards can come in different versions: passive, semi-active, active.
Passive cards handle the D-channel and B-channel protocol in software.
This makes them least expensive, but only suitable where the CPU is able
to do the additional work (for normal data communication any computer
starting from a 486 or even a 386 should be able to handle one or two cards).
Since only a few hardware chips are in wide usage, a generic driver, HiSax,
can handle almost all passive cards.

<tag/PBX/
A PBX (Private Branch eXchange) is used to connect different internal
devices to the ISDN network. This is usually for analog devices that
cannot be directly connected to an ISDN network. The PBX can also make
an internal digital S0 bus available, on which ISDN devices can be
connected. This allows for local calls without using the switching
station (thereby avoiding the charges from your telephone company).

<tag/point-to-point mode/
<label id="glossary_pointtopointmode">
Your ISDN interface can be configured either in multi-device mode
(in German: Mehrgeraeteanschluss), or in point-to-point mode (in German:
Anlagenanschluss).
The point-to-point mode is the normal connection mode for business ISDN
users. The user can attach only one single devices to the ISDN connection
which will have to handle all calls (typically a PBX will be used). The
ISDN provider will assign a range of numbers to the ISDN connection.
Any call within this number range will be sent to the user. The ISDN
provider will leave assignment of the last digits of the telephone number
to the ISDN user.
This setup usually allows for additional features, but is also more expensive.

<tag/PRI/
PRI means primary rate interface and is the used when a single or multiple
BRI are not sufficient in bandwidth. In Europe, a PRI includes 30 B-channels
for data communication, and 1 D-channel for administration of the data
communication.

<tag/semi-active card/
<label id="glossary_semiactive">
Cards can come in different versions: passive, semi-active, active.
For semi-active cards there is no fixed definition, so here is what we think:
semi-active cards handle the B-channel protocol in their hardware with
special DSP (digital signal processor) support, but they leave the D-channel
protocol to the software. This makes them better suitable to special tasks
like sending/receiving analog G3 faxes. Because of their special hardware,
a special driver is required. Be aware, that for marketing reasons some cards
are called semi-active when in fact they are passive (e.g.: Teleint).

<tag/subaddressing/
When dialing, it is possible to provide an additional number, the subaddresss.
The subaddress is transmitted to the remote side, and allows it to react on it.
This feature may not be available, at least not for free (with the exception
of France).

<tag/TEI/
TEI stands for Terminal End Identifier. The local switching station, or
with an internal S0 the PBX, automatically or permanently assigns each
end device a TEI. This simply allows the addressing of the D
channels. TEIs have the following values:
0-63 = permanent TEIs (e.g. 0 is used for point to point connections)
64-126 = automatically assigned
127 = broadcast to all devices (e.g. an incoming call)

<tag/UUS/
UUS is user to user signalling. It means, that when placing a call,
a few bytes of user-specific data can be transmitted along with the call
setup frame. This feature has been abused in the past in Germany, causing
the local exchanges to run out of available channels (the call setup causes
them to reserve a B-channel). Since then, this feature usually costs extra
and there is a data limit on it (depends on your ISDN provider). Have a look at
the usage condition, in short it's only allowed to use this feature, if
indeed you want to setup a call. Please note that it has been reported that
some buggy PBX (like ISTEC 1003) may refuse a connection when support of UUS is
signalled to them.

<tag/X.75/
A widely used low-level protocol, usually used to connect your computer
with a computer mailbox. For connections to the internet, HDLC is usually
used.

</descrip>

</article>
