4675 lines
197 KiB
Plaintext
4675 lines
197 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.41, 4. June 2000
|
||
<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.html">.
|
||
|
||
A German translation of the FAQ is available at:
|
||
<url url="http://www.wolf-b.de/i4l/i4lfaq-de.html">.
|
||
|
||
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.html"></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 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.
|
||
|
||
<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 one exception:
|
||
the Creatix/Teles S0 box for the parallel port. 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 news group and 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">.
|
||
|
||
<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.php3">.
|
||
|
||
|
||
<!-- 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.php3"> 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 all passive cards: NO</bf>. However, there is a project working
|
||
on this rather complicated problem. For more info on its status have a look at:
|
||
<tt><url url="http://home.telia.no/Morten.Rolland/linux/i4lfax/index.html"></tt>
|
||
<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.
|
||
<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>
|
||
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.
|
||
</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.
|
||
|
||
<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">.
|
||
|
||
<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/. So far there is no howto and only little
|
||
documentation, so for now this is something only for the more
|
||
experienced user. In the Netherlands, the keypad protocol can be used
|
||
as an alternative.
|
||
|
||
<sect1> feature_ipx: Can I route ipx/spx over ISDN with Linux?
|
||
<label id="feature_ipx">
|
||
<p>
|
||
Yes, just set up an ISDN interface with encapsulation
|
||
<tt/ethernet/. <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.
|
||
|
||
<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.
|
||
|
||
<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/ 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/ and
|
||
<tt/Disable sending llc/.
|
||
|
||
<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: How can I set the clock of my computer with ISDN?
|
||
<label id="feature_clock">
|
||
<p>
|
||
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;. One time server
|
||
can be found in Cologne: time.rrz.uni-koeln.de, but there are many more.
|
||
|
||
<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 cards from Hypercope (HYSDN Champ2, HYSDN Ergo2,
|
||
HYSDN Metro4)
|
||
</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">).
|
||
There are activities to make this a general interface, also for
|
||
other cards. However, 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 seperately and pay extra for receiving it (sending is free), depeding
|
||
on your ISDN provider.
|
||
Additionally, please note that if you are connected through a PBX, it will
|
||
most likely filter out all the subaddressing stuff.
|
||
|
||
<sect1> feature_gsmv110: Can I connect from my PDA via GMS cellular phone
|
||
to isdn4linux?
|
||
<label id="feature_gsmv110">
|
||
<p>
|
||
Yes, if the provider of the cellular phone has a GSM to ISDN/V.110 gateway.
|
||
This has been reported to work from a PalmPilot to isdn4linux with V.110.
|
||
See question <ref id="config_gsmv110" name="config_gsmv110"> for details on how to configure it.
|
||
|
||
<!-- Feature reversed card -->
|
||
|
||
<!-- Chargeint -->
|
||
|
||
<!-- Feature Raw-IP -->
|
||
|
||
<!-- Feature both caller ids -->
|
||
|
||
<!-- Feature leased line -->
|
||
|
||
<!-- Eurofile -->
|
||
|
||
<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.
|
||
Please note, that it does not make much sense to choose a call-by-call
|
||
Internet Provider this way, since more things would have to be adjusted
|
||
to make it work (e.g. DNS lookup, proxy setup,...). Also, isdnlog should
|
||
always be running (otherwise your dialout may be delayed by 3 seconds).
|
||
|
||
<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!
|
||
|
||
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 in these issues:
|
||
<itemize>
|
||
<item>ct 05/98, page 224: <tt>Der erste Kontakt/Linux: Mit PPP ans Internet</tt>
|
||
<item>ct 21/98, page 288: <tt>Reiseleiter/Internet-Anbindung für das LAN</tt>
|
||
<item>ct 25/98, page 218: <tt>Bei Anruf Netz/Linux: Dial-In Server</tt>
|
||
</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 is <tt/de.alt.comm.isdn4linux/.
|
||
You can read what is going on, or send a message yourself (before please
|
||
make sure it is not answered in this FAQ).
|
||
Most isdn4linux developers are present, and many other knowledgeable
|
||
people. Don't be confused by the many German messages on it.
|
||
<bf>English postings are very welcome, and will be
|
||
answered in English!</bf>
|
||
|
||
<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).
|
||
|
||
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 constantly to the mailing list, send an email message to
|
||
<tt><htmlurl url="mailto:majordomo@listserv.isdn4linux.de"
|
||
name="majordomo@listserv.isdn4linux.de"></tt>.
|
||
The subject doesn't matter. The message body should read <tt/subscribe
|
||
isdn4linux <email address>/, where <email address> is the
|
||
address to which mail from the list should be sent. To unsubscribe send a
|
||
message with the body <tt/unsubscribe isdn4linux <email address>/ at the
|
||
same address. 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>
|
||
Subscribe to the mailing list as described in question
|
||
<ref id="docu_mailinglist" name="docu_mailinglist">, but as mailing list name
|
||
use <tt/isdn4linux-digest/ rather than <tt/isdn4linux/. So your message body
|
||
should read <tt/subscribe isdn4linux-digest <email address>/ for
|
||
subscription, and <tt/unsubscribe isdn4linux-digest <email address>/
|
||
for unsubscription.
|
||
|
||
<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/">.
|
||
|
||
Alternatively, you can send an email to
|
||
<tt><htmlurl url="mailto:majordomo@listserv.isdn4linux.de"
|
||
name="majordomo@listserv.isdn4linux.de"></tt>.
|
||
The subject doesn't matter. These commands are possible:
|
||
<itemize>
|
||
<item>index isdn4linux - list which archive files are available
|
||
<item>get isdn4linux filename - retrieves the file filename
|
||
</itemize>
|
||
The archives are named &dquot;archiv.yearmonth&dquot;, so
|
||
&dquot;archiv.9610&dquot; is the archive for October 1996.
|
||
|
||
Other archives are:
|
||
<itemize>
|
||
<item><tt><url
|
||
url="ftp://ftp.uni-oldenburg.de/pub/unix/linux/isdn/isdn4linux/Mailing-List"></tt>
|
||
</itemize>
|
||
|
||
|
||
<!-- 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/ 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 4th September 1999 (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>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.Diehl Diva 2.0 ISA and PCI (S0 and U interface, no PRO version)
|
||
<item>Eicon.Diehl 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
|
||
<item>Dr. Neuhaus Niccy PnP/PCI
|
||
<item>Siemens I-Surf 1.0
|
||
<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
|
||
</itemize>
|
||
Note:
|
||
<itemize>
|
||
<item>PCF, PCF-Pro: up to now, only the ISDN part is supported
|
||
<item>PCC-8: not tested yet
|
||
<item>Teles PCMCIA is EXPERIMENTAL
|
||
<item>Teles 16.3c is EXPERIMENTAL
|
||
<item>Teles PCI is EXPERIMENTAL
|
||
<item>Teles S0Box is EXPERIMENTAL
|
||
<item>Eicon.Diehl Diva U interface not tested
|
||
<item>Some cards do not work when compiled into the kernel, only when
|
||
started as modules
|
||
<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.
|
||
</itemize>
|
||
|
||
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>
|
||
|
||
<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>Eicon.Diehl
|
||
<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, but can only fax on one channel.
|
||
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.
|
||
|
||
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).
|
||
|
||
<sect1> hardware_external: Does isdn4linux support external terminal adapters?
|
||
<label id="hardware_external">
|
||
<p>
|
||
No, 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).
|
||
|
||
<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_s2m: Which S2M cards are supported?
|
||
<label id="hardware_s2m">
|
||
<p>
|
||
At least these S2M cards have been reported to work:
|
||
<itemize>
|
||
<item>Eicon.Diehl: S2M-ISA or DIVA Server PRI/PCI (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_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>
|
||
In principle, hisax works with the built-in ISDN adapter of a
|
||
Sparc-Station-LX and a Sparc-Station-10, with development
|
||
kernels version 2.3.x. The code for Sun is only available there.
|
||
Please be aware that the code of the latest developments can not be
|
||
compiled for 32 bit machines like all sun-4m machines.
|
||
|
||
Audio works, but not well; ISDN works, but randomly
|
||
crashes the machine. 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).
|
||
|
||
<sect1> hardware_ppc: Can I run isdn4linux on a PowerPC with Linux?
|
||
<label id="hardware_ppc">
|
||
<p>
|
||
Yes, most cards should work. However, at least the AVMFritz!PCI card won't
|
||
work, due to the different Endian format for 32bit B-channel data on the PPC.
|
||
|
||
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.
|
||
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.
|
||
|
||
<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>
|
||
|
||
<sect1> hardware_sedlbauer: What is special about the Sedlbauer card?
|
||
<label id="hardware_sedlbauer">
|
||
<p>
|
||
It is a semiactive card based on the ISAR chipset which supports
|
||
sending/receiving faxes. It is special in that you use it with HiSax which
|
||
normally works only for passive cards. However, 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. The ideal init string for the card to allow
|
||
modem dialin is <tt>AT%C0\N0</tt>.
|
||
|
||
<sect1> hardware_teles: What should I know about before buying an ISDN card
|
||
from Teles?
|
||
<label id="hardware_teles">
|
||
<p>
|
||
First the latest news: 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 doesn't even give away drivers for other operating
|
||
systems, like Windows, for free. You have to dial up a very expensive
|
||
number (0190) where you have 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 is currently the case...)
|
||
|
||
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_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://calle.in-berlin.de/pub/linux/avmb1">
|
||
or
|
||
<url url="ftp://ftp.avm.de/cardware/b1/linux/">.
|
||
The firmware is available on:
|
||
<url url="ftp://ftp.avm.de/cardware/b1/linux/firmware">.
|
||
The latest firmware will also allow D channel traces with isdnlog without
|
||
usage of a reversed card.
|
||
|
||
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 on:
|
||
linux-avmb1@calle.in-berlin.de (send an email to majordomo@calle.in-berlin.de
|
||
with <tt>subscribe linux-avmb1 <your email address></tt> in its body).
|
||
|
||
<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.
|
||
|
||
|
||
<!-- 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. This may 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/ (discriminator 0xaa) as well as
|
||
<tt/Ascom/ (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.
|
||
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/, 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.
|
||
|
||
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.
|
||
|
||
<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_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.
|
||
<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>
|
||
Increase the parameter ISDN_MAX_CHANNELS in
|
||
<tt>/usr/src/linux/include/linux/isdn.h</tt> and rebuild the isdn stuff. 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>
|
||
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 initialize the ttyI* device
|
||
with <tt/ATS19=0/ for V.110. The rate should be set to 9600 with
|
||
<tt/AT&R9600/. pppd needs to be called with <tt/noccp/ and
|
||
<tt/require-pap/. For a mini-howto see:
|
||
<url url="http://www.oltom.com/Linux/Docs/GSM%20over%20V.110%20Mini-HOWTO.txt">
|
||
|
||
You also have to set up your GSM accordingly. As an example, to switch the
|
||
Nokia 7110 into V.110 mode, 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).
|
||
|
||
|
||
<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 the Linux H.323 - ISDN Gateway, which can be 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>
|
||
|
||
<sect1> config_links: What helpful links are there about 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.demon.nl/i4l-howto-uk.html">
|
||
<item>German: <url url="http://www.franken.de/users/klaus/">
|
||
<item>French: <url url="http://www.perso.wanadoo.fr/philippe.latu/">
|
||
<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/linux.html">
|
||
<item>Tips to configure Red Hat:
|
||
<url url="http://www.webideal.de/rh-isdn/">
|
||
<item>Tips to configure Mandrake:
|
||
<url url="http://www.mandrakeuser.org/connect/cisdn.html">
|
||
<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>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.provi.de/˜gvz/chargeint.html"></tt>
|
||
<item>Homepage of kisdn (only works with Qt/KDE):
|
||
<tt><url url="http://www.millenniumx.de/kisdn.html"></tt>
|
||
<item>Configuration not only for UK (follow link to Linux Setup):
|
||
<tt><url url="http://www.oakhaven-consultants.co.uk"></tt>
|
||
</itemize>
|
||
|
||
|
||
<!-- 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> 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_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.
|
||
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 in - never both.
|
||
<item>Try calling with a telephone. The number should be shown in
|
||
/var/log/messages. Otherwise, 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 corrected
|
||
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 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_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_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).
|
||
|
||
|
||
<!-- 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">).
|
||
|
||
An additional thing is that you could use a '*' as a wildcard at the end of the
|
||
number for incoming calls (e.g. <tt>isdnctrl msn interface 123*&dquot;</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 I allow the users in my LAN to dial out via
|
||
the ISDN card(s) in my Linux PC (like a modem server)?
|
||
<label id="lan_modemserver">
|
||
<p>
|
||
On the Linux side use modemd, which is a very short perl script
|
||
(also see Windows-Modem-Sharing-MiniHowto):
|
||
<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>
|
||
|
||
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 16bit applications. Another program is DialOut/IP, but it<69>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
|
||
there are plans to have telnet support added, such that it will run without
|
||
additional software. Watch out for news on:
|
||
<tt><url url="http://www.openxp.de"></tt>
|
||
|
||
|
||
<!-- 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:
|
||
see section <ref id="2channel" name="2channel">.
|
||
<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>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>
|
||
|
||
|
||
<!-- 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!
|
||
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.
|
||
|
||
<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.
|
||
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_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;.
|
||
<label id="syncppp_nopppsupport">
|
||
<p>
|
||
Check whether the device &dquot;ippp0&dquot; exists (i.e. with the program
|
||
&dquot;ifconfig&dquot;).
|
||
The ipppd *needs* this device with exactly *that* name. If it doesn't exist
|
||
one has to define it:
|
||
<code>
|
||
isdnctrl addif ippp0
|
||
isdnctrl encap ippp0 syncppp
|
||
(see i4l documentation for more information...)
|
||
</code>
|
||
Maybe you compiled ipppd with the source of another kernel that you are not
|
||
using...
|
||
See also the question &dquot;How should I name my network interface?&dquot;
|
||
under &dquot;Sync PPP&dquot; in the &dquot;Configuration&dquot; section.
|
||
|
||
<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. 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>
|
||
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.
|
||
|
||
|
||
<!-- 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/. 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;ATS13=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.
|
||
|
||
|
||
<!-- 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.
|
||
|
||
<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_uucp: When I use UUCP with X.75, I always get transfer errors!
|
||
<label id="ttyI_uucp">
|
||
<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-Revoking patch, which has 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/">. Make sure to use ipppd's
|
||
"defaultroute" option rather than <tt>route add/del default</tt> in
|
||
ip-up/ip-down with it.
|
||
<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>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_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>
|
||
Andreas Glahn <tt><htmlurl url="mailto:andreas@tao.westfalen.de"
|
||
name="andreas@tao.westfalen.de"></tt> wrote on 31 Jan 1997:
|
||
I had this problems too. Then when starting the samba daemon I gave
|
||
it the internal IP address I use here at home. Since then a samba
|
||
request is no longer sent to default, but stays here.
|
||
|
||
Take a look at the configuration with netstat and tcpdump. With tcpdump
|
||
you can quickly find out to which IP address samba is trying to
|
||
connect.
|
||
|
||
My internal Linux computer has, e.g.: 192.168.99.99
|
||
|
||
My Win95 computer: n 192.168.99.88
|
||
|
||
On the Linux computer I started samba with:
|
||
<code>
|
||
nmdb -S -B 192.168.99.255 -I 192.168.99.99
|
||
</code>
|
||
See also the above question: se -broadcast and possibly -arp
|
||
when defining the interfaces!
|
||
|
||
<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.
|
||
|
||
A proxy should not cause a dial out, even when the complete name is
|
||
entered. Only when a new proxy is given does Netscape do a DNS
|
||
lookup (and in this special case cause a dialout.
|
||
However, on 17 Mar 97 Steffan Henke
|
||
<tt><htmlurl url="mailto:henker@informatik.uni-bremen.de" name="henker@informatik.uni-bremen.de"></tt>
|
||
wrote:
|
||
<quote>
|
||
Unfortunately reality has caught up with us. I've heard that
|
||
Netscape now in version.4.02 really does establish a
|
||
connection...
|
||
</quote>
|
||
|
||
<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>
|
||
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.
|
||
|
||
<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. The best solution is to 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.
|
||
|
||
|
||
<!-- 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.
|
||
|
||
<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_mpppconfig: How do I configure MPPP?
|
||
<label id="2channel_mpppconfig">
|
||
<p>
|
||
First you 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>
|
||
|
||
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">
|
||
|
||
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_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_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.
|
||
|
||
|
||
<!-- 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_nosignal: How does establishing and ending a connection work
|
||
with D64S without signaling?
|
||
<label id="leased_nosignal">
|
||
<p>
|
||
The data are 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 ISDN, can I use one channel as a leased line
|
||
and other as a dialup line?
|
||
<label id="leased_splitline">
|
||
<p>
|
||
Yes, you can. But you have to 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_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 has been successful
|
||
in many cases.
|
||
|
||
<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>
|
||
|
||
|
||
<!-- 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://rates4linux.sourceforge.net/"></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 two possibilities. 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.
|
||
|
||
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!
|
||
Because of this setup, this ISDN
|
||
card cannot be used for anything else. 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.
|
||
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.
|
||
|
||
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 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 welcome (I'll make the logs from my
|
||
Ackermann Euracom available - Matthias Hessler
|
||
<tt><htmlurl url="mailto:hessler@wi-inf.uni-essen.de"
|
||
name="hessler@wi-inf.uni-essen.de"></tt>).
|
||
|
||
<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.
|
||
|
||
|
||
<!-- 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?
|
||
|
||
<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://members.myworld.at/mren/vbox4php.html"></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.
|
||
|
||
|
||
<!-- 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>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_switherland" name="country_switherland">)
|
||
<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
|
||
</itemize>
|
||
|
||
<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_spv: Does isdn4linux support SPVs? How?
|
||
<label id="1tr6_spv">
|
||
<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_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 but without the leading 0. For example, if my phone
|
||
number is 72004681 and my area code is 045, my MSN is 4572004681.
|
||
Now with the setting AT&E4572004681 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>
|
||
Unfortunately, European ISDN cards can not be used in North America.
|
||
In Europe, the telephone company normally makes the network terminator
|
||
(NTBA) available. In North America <em>the customer</em> has to supply such
|
||
a device(NT-1) himself! Therefore, most ISDN cards offer an
|
||
integrated NT-1.
|
||
|
||
There are also other differences; e.g. in Europe a PRI (Primary
|
||
Rate Interface) has 30 B channels, in North America only 23. Also the
|
||
channel protocols NI-1 and 5ESS are used. NI-1 is related to DSS1 (both
|
||
are Q.931 Protocols), but both have totally different groups of functions
|
||
and are therefore not compatible to one other.
|
||
|
||
Unfortunately, neither the NI-1 nor the 5ESS protocol have so far been
|
||
implemented for isdn4linux to work with passive cards.
|
||
|
||
However, the firm &dquot;Spellcaster&dquot; has written an isdn4linux driver
|
||
for its own (active) cards. Both BRI and PRI cards are available. More
|
||
information is available from:
|
||
<verb>
|
||
Ian James
|
||
Customer Service Manager
|
||
SpellCaster Telecommunications Inc.
|
||
73 Laird Drive, Suite 206
|
||
Toronto, Ontario
|
||
Canada M4G 3T4
|
||
Phone: 1 (800) 238-0547
|
||
Fax: (416) 425-0854
|
||
</verb>
|
||
E-mail: <tt><htmlurl url="mailto:ipj@spellcast.com"
|
||
name="ipj@spellcast.com"></tt> or <tt><htmlurl url="mailto:sales@spellcast.com"
|
||
name="sales@spellcast.com"></tt>
|
||
<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_switherland: 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_switherland">
|
||
<p>
|
||
In Switzerland you have to 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 (?).
|
||
<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).
|
||
|
||
Also, check out <url url="http://www.wurtel.demon.nl/i4l-howto-uk.html">.
|
||
|
||
<sect> misc: Miscellaneous
|
||
<label id="misc">
|
||
|
||
<sect1> misc_nonullcable: Can I connect two ISDN devices directly with a kind
|
||
of &dquot;null modem cable&dquot;?
|
||
<label id="misc_nonullcable">
|
||
<p>
|
||
No, that's not possible. The concept of ISDN doesn't allow it. A NTBA or a
|
||
PBX with an internal bus is required.
|
||
|
||
<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.
|
||
|
||
<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/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/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/
|
||
Your interface can be configured either in a multi-device mode
|
||
(in German: Mehrgeraeteanschluss), or in a point-to-point mode (in German:
|
||
Anlagenanschluss). In the multi-device mode, several ISDN devices can
|
||
be attached to the ISDN bus at the same time. Usually a few (if any)
|
||
numbers are related to this bus, and the devices can pick the call that
|
||
they want to receive. In contrast, the point-to-point mode allows only
|
||
one device to be connected which handles all calls. This is usually
|
||
meant for at least small companies that want to attach their PBX and
|
||
be able to handle the last digits of their telephone numbers by themselves,
|
||
under their own control. The 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.
|
||
</descrip>
|
||
|
||
</article>
|
||
|
||
|
||
<!-- Keep this comment at the end of the file
|
||
Local variables:
|
||
mode: sgml
|
||
sgml-omittag:t
|
||
sgml-shorttag:t
|
||
sgml-namecase-general:t
|
||
sgml-general-insert-case:lower
|
||
sgml-minimize-attributes:nil
|
||
sgml-always-quote-attributes:t
|
||
sgml-indent-step:2
|
||
sgml-indent-data:nil
|
||
sgml-parent-document:nil
|
||
sgml-exposed-tags:nil
|
||
sgml-local-catalogs:nil
|
||
sgml-local-ecat-files:nil
|
||
End:
|
||
-->
|