6007 lines
260 KiB
Plaintext
6007 lines
260 KiB
Plaintext
<!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
|
|
& 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 <driver_id> 9 ISAR.BIN
|
|
</code>
|
|
Then initialize the ttyI* interface with:
|
|
<code>
|
|
ATZ&E<your_msn>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&FS14=10S15=0S18=1&E<your_msn>
|
|
</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/˜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 <interface> <time></tt>), then
|
|
the driver will automatically hang up when no data was been transferred over
|
|
the interface for >time< 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><number>.<subaddress></tt>. However, you may have to order
|
|
it separately 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 <id> 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ö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 & 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ü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öpfen</tt>
|
|
(also contains information on dial-in configuration without HSCSD).
|
|
<item>ct 15/2002, page 204: <tt>Bei Anruf Internet: Handy-Anruf löst
|
|
Internet-Einwahl aus</tt>
|
|
<item>ct 3/2004, page 182: <tt>Heimserver im Eigenbau - Teil 4: ISDN-Grundlagen
|
|
fü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ü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&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 =< try type 29)
|
|
<item>Siemens I-Surf 2.x (with IPAC => 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 <driver_name> 10 1
|
|
hisaxctrl <driver_name> 12 1
|
|
</code>
|
|
You can deactivate it by calling:
|
|
<code>
|
|
hisaxctrl <driver_name> 12 0
|
|
hisaxctrl <driver_name> 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%C0\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&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 <id> 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 > /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&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 <driver_id> 7 1
|
|
</code>
|
|
Additionally, you can use the &dquot;AT&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/˜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 <id> 1 0x33ff
|
|
hisaxctrl <id> 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&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 <interface> <protocol>
|
|
</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>
|
|
#define HSCX_RBUF_ORDER 1
|
|
#define HSCX_RBUF_BPPS 2
|
|
#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 <id> 0 0
|
|
</code>
|
|
and reset them with:
|
|
<code>
|
|
hisaxctrl <id> 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&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&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&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ündelanschluß').
|
|
|
|
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>
|
|
#!/usr/bin/perl
|
|
select((select(STDOUT), $| = 1)[$[]);
|
|
select((select(STDIN), $| = 1)[$[]);
|
|
exec &dquot;cu&dquot;,&dquot;-E&dquot;,&dquot;''&dquot;, &dquot;-l&dquot;, &dquot;$ARGV[0]&dquot;;
|
|
die &dquot;$0: Cannot exec cu: $!\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 # Modem service via TCP
|
|
isdn 20007/tcp modemd # 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 = <IP> # 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 <carddriver1> 111,222,333,,
|
|
isdnctrl mapping <carddriver2> 999,888,,777
|
|
</code>
|
|
Now, you could configure for telephone number 0 when you really want to use
|
|
MSN 111 on <carddriver1> or 999 on <carddriver2> (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 <carddriver1> or 888
|
|
on <carddriver2>. Configure to use telephone number 2 when you really
|
|
want to use only MSN 333 on <carddriver1> (<carddriver2> will
|
|
use the default MSN when used). Configure to use telephone number 3 when you
|
|
really want to use only MSN 777 on <carddriver2> (<carddriver1>
|
|
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 <carddriver1> 111,222,333,-,
|
|
isdnctrl mapping <carddriver2> 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 <carddriver1>, while dialout on 3 will
|
|
now only dial out with MSN 777 on <carddriver2>.
|
|
</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 <device> out P1<your_out_number>
|
|
</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/˜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;#&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"</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 :$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:
|
|
#*.=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>
|
|
#!/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
|
|
#! /bin/sh
|
|
case $1 in
|
|
on)
|
|
/sbin/isdnctrl dial ippp0 # build up connection
|
|
sleep 5 # wait until line open
|
|
/sbin/route add default ippp0 # set route
|
|
;;
|
|
off)
|
|
/sbin/isdnctrl hangup ippp0 # hangup connection
|
|
/sbin/route del default # 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 `#' 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&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%.
|
|
|
|
<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&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
|
|
=> Configuration must occur beforehand (IP addresses,...)
|
|
=> sensible to use for only for one provider at a time
|
|
<item> Authorization only by Caller ID
|
|
=> Dialin only possible from one's own number
|
|
<item> Fixed IP address
|
|
=> 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&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&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&E</tt> which
|
|
MSN to use. For example, use <tt>AT&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&</tt>. Mostly
|
|
used is a block size of 2048 byte: <tt>AT&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
|
|
˜.
|
|
</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&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.
|
|
# 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&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 <device></tt> to dial out, and
|
|
<tt>isdnctrl hangup <device></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 $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 <interface> ! -y
|
|
</code>
|
|
Add this in <tt>/etc/ppp/ip-up</tt>:
|
|
<code>
|
|
ipchains -A output -j DENY -p tcp -i <interface> ! -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 <slave_interface>&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 <interface> hdlc
|
|
isdnctrl l3_prot <interface> trans
|
|
isdnctrl encap <interface> 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/˜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 <channel>
|
|
</code>
|
|
in case HiSax was loaded with &dquot;id=HiSax&dquot;, where <channel>
|
|
can be 0 or 1. Additionally to the normal configuration, the following
|
|
commands are important:
|
|
<code>
|
|
/sbin/isdnctrl bind HiSax,<channel>
|
|
/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&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 <channel>
|
|
</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 <device> in <phonenumber></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&E123456 OK AT&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&E123456 OK
|
|
AT&B512 OK' -s 38400 ttyI0
|
|
</code>
|
|
The most elegant way is to use iprofd. This daemon takes advantage of
|
|
the <tt>AT&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&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 <device> 5
|
|
isdnctrl callback <device> 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 separate 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 <driver_id> 1 4
|
|
hisaxctrl <driver_id> 10 1
|
|
hisaxctrl <driver_id> 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>
|
|
#!/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 <DriverId> 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/˜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&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 <OWNNUMBER>:<SPID>).
|
|
|
|
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&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<country_code> (three zeros), rather than the 00<country_code>
|
|
(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>
|