FAQ for isdn4linux
Matthias Hessler (hessler@isdn4linux.de)
v2.0.97, 11 June 2005
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: . 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 ``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 documenta-
tion (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 docu-
ments 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: i4lfaq@isdn4linux.de or:
hessler@isdn4linux.de. The newest version of this FAQ can be found
at:
. There is also a mailing list on
isdn4linux which will give you the most up to date information. To
find out more about these great information sources, see section
``docu''. And: check out all the great links listed in question
``config_links''! You may find information in your language, or
information specific to your linux distribution.
11..66.. ggeenneerraall__ggeettllaatteesstt:: WWhheerree ddoo II ggeett tthhee llaatteesstt vveerrssiioonn ooff
iissddnn44lliinnuuxx??
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 ``distrib''.
11..77.. ggeenneerraall__ccoonnttaaccttss:: HHooww ccaann II ggeett iinn ccoonnttaacctt wwiitthh tthhee ddeevveellooppeerrss??
You can contact the isdn4linux developers through the
www.isdn4linux.de website. Have a look at
.
22.. ddiissttrriibb:: DDiissttrriibbuuttiioonn
22..11.. ddiissttrriibb__ggeettllaatteesstt:: HHooww ccaann II ggeett tthhee llaatteesstt iissddnn44lliinnuuxx??
There are different ways, depending on your kernel. Unless you are an
experienced user of Linux, you should use a recent kernel (=first
option).
+o 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 on how to find
mirrors).
+o 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: ``distrib_cvs''.
22..22.. ddiissttrriibb__ccvvss:: HHooww ccaann II aacccceessss tthhee ssoouurrccee ffrroomm tthhee ccuurrrreenntt ddeevveell--
ooppmmeenntt//wwhhaatt iiss tthhee CCVVSS ttrreeee aallll aabboouutt??
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:
1. Create and go to the directory where you want to store i4l
___________________________________________________________________
mkdir ~/cvs; cd ~/cvs
cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev login
___________________________________________________________________
2. Log in (asks for a password, enter _r_e_a_d_o_n_l_y)
3. Get the isdn kernel driver stuff (same hierarchy as in the linux
source)
___________________________________________________________________
cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev checkout isdn
___________________________________________________________________
4. Get the utility package into the current directory
___________________________________________________________________
cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev checkout isdn4k-utils
___________________________________________________________________
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':
______________________________________________________________________
cvs -d :pserver:guest@cvs.isdn4linux.de:/i4ldev checkout -r isdn4kernel_2_0 isdn
______________________________________________________________________
5. After having checked out, further updates can be done by first
changing into isdn or isdn4k-utils subdirectory and running
___________________________________________________________________
cvs update -P -d
___________________________________________________________________
Tip: since cvs stores the password on your first login, you don't need
to login again when updating.
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 _c_o_n_t_i_n_u_o_u_s_l_y 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 fritz@isdn4linux.de
33.. FFeeaattuurreess
33..11.. ffeeaattuurree__nnoott:: WWhhiicchh IISSDDNN ffeeaattuurreess ccaannnnoott bbee ooffffeerreedd bbyy
iissddnn44lliinnuuxx??
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.
33..22.. ffeeaattuurree__ddaattaa:: WWhhiicchh IISSDDNN ddaattaa ttrraannssmmiissssiioonn mmooddeess aarree ssuuppppoorrtteedd??
These low-level formats are possible:
+o 56k asynchronous : no
+o 64k synchronous : yes
+o 128k synchronous : yes (channel bundling - see the question
``feature_2channel'')
These level2 formats are possible:
+o HDLC
+o X.75
+o transparent
+o V.110
These encapsulations are possible:
+o rawip
+o ethernet
+o Sync PPP
+o X.25 (requires 2.1 or newer)
+o cisco and cisco-h
+o cisco-hk (=cisco with keepalive; requires 2.1 or newer)
+o plus a few specialities: have a look at the man pages.
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).
33..33.. ffeeaattuurree__vvooiiccee:: HHaass iissddnn44lliinnuuxx vvooiiccee ssuuppppoorrtt ((ee..gg.. aannsswweerriinngg
mmaacchhiinnee,, vvooiiccee--oovveerr--iipp ggaatteewwaayy ffoorr HH..332233 cclliieennttss))??
Yes, voice support is included in the current version of isdn4linux.
For an answering machine you can either use "vgetty" from Gert
Doerings "mgetty+sendfax", or "vboxgetty" from Michael Herold, which
is made especially for isdn4linux. The latter is part of the isdn4k-
utils package, which can be found on:
. Here is
a German website which has some nice installation instructions:
or
or
Please also have a look on the mailing
list for tips how to do it, and what the consequences/disadvantages
are.
+o FFoorr tthhee aaccttiivvee ccaarrdd AAVVMM BB11:: YYeess (its firmware has implemented fax
as one of its features). Get the newest stuff from:
+o FFoorr tthhee aaccttiivvee HHyyppeerrccooppee PPCCII ccaarrddss HHYYSSDDNN EErrggoo22 aanndd HHYYSSDDNN MMeettrroo44::
YYeess,, aafftteerr uuppggrraaddee wwiitthh aa ssppeecciiaall ffaaxx ccaarrdd. The setup is similar
to that of an AVM B1, but may require extra patches.
+o FFoorr tthhee aaccttiivvee EEiiccoonn DDiivvaa SSeerrvveerr ccaarrddss ((eexxcceepptt DDiivvaa 22..00PPrroo)):: YYeess.
Have a look at README.fax and README.eicon in the
isdn/Documentation/isdn directory, as well as:
9 ISAR.BIN
___________________________________________________________________
Then initialize the ttyI* interface with:
______________________________________________________________________
ATZ&ES0=1S13=1+FCLASS=1
______________________________________________________________________
and use a normal Hylafax class 1 config file, where you've replaced
non-supported commands (flow control,...) by dummies. For the I-Surf
1.0 also check question ``hardware_isurf''.
If you do want to fax now, your best choice is to install an analog
fax modem along with your ISDN card. For companies who want to set up
a fax server servicing multiple connections you could also have a look
at the active ISDN cards.
More information for setting up a fax server with hylafax can be found
on: on the web site for Hylafax: or on
.
33..55.. ffeeaattuurree__mmooddeemm:: CCaann iissddnn44lliinnuuxx ccoonnnneecctt ttoo//bbee ccaalllleedd bbyy aann aannaalloogg
mmooddeemm??
Generally: NNOO. It may only work for cards with which you can fax: see
question ``feature_fax''. For the Sedlbauer card, you can give the
following command on the ttyI*:
______________________________________________________________________
AT&FS14=10S15=0S18=1&E
______________________________________________________________________
33..66.. ffeeaattuurree__ddiivveerrtt:: IIss iitt ppoossssiibbllee ttoo iinniittiiaattee ccaallll ffoorrwwaarrddiinngg wwiitthh
ii44ll??
Call diversion features have been implemented recently. Use the new
program divertctrl in conjunction with the HiSax driver.
If you make use of capi4linux, then you find a similar program named
capidivert at: for details.
33..1100.. ffeeaattuurree__ddoodd:: DDooeess tthhee ddrriivveerr ssuuppppoorrtt ""ddiiaall oonn ddeemmaanndd""??
Yes. If a network interface (e.g. "isdn0") is set up, the driver will
dial the number. If in addition a hangup timeout (Idle Timeout) has
been given (like: isdnctrl huptime ), 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 ``dialout_dialmode''). You should
definitely be very interested in the large section of this FAQ that
talks about the dangers of unwanted dialouts: (``dod'').
33..1111.. ffeeaattuurree__ssmmss:: CCaann II sseenndd SSMMSS ((sshhoorrtt mmeessssaaggeess)) ttoo mmyy mmoobbiillee pphhoonnee
vviiaa IISSDDNN??
Yes, you can use the program 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 Disable send complete and Disable
sending llc. Please note that mainly German providers support sending
SMS via ISDN connection, in other countries this might not work. Dutch
as well as UK SMS callcenters seem to not support this feature. Please
let me know if you have additional information on this. A useful
sample config for yaps you might find on:
Another program to send SMS is asterisk. Have a look at:
and . One advantage over yaps is that it can also
receive SMS, for Germany (you have to register for this first by
sending a specific SMS - otherwise the SMS will be communicated to you
by an automated voice call).
Yet another program to send SMS is smsclient. You can find it on:
.
33..1122.. ffeeaattuurree__bbttxx:: IIss tthhee GGeerrmmaann vviiddeeootteexx//BBttxx//DDaatteexx--JJ ppoossssiibbllee wwiitthh
iissddnn44lliinnuuxx??
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.
33..1133.. ffeeaattuurree__cclloocckk:: CCaann II sseett tthhee cclloocckk ooff mmyy ccoommppuutteerr wwiitthh IISSDDNN??
Yes. Isdnlog offers this feature with option "-t". 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
"netdate" or "rdate". Check out the following urls on information
about using time servers:
+o
+o In German:
+o In German:
33..1144.. ffeeaattuurree__ddoosseemmuu:: CCaann II uussee iissddnn44lliinnuuxx uunnddeerr ddoosseemmuu??
Yes, you can! Steffan Henke henker@informatik.uni-bremen.de wrote on
25 Oct 96:
In dosemu.conf it is enough to enter a virtual com port,
(for example com2) that can be used with e.g. Telix or Ter-
minate: serial { com 2 device /dev/ttyI3 } Access with Fos-
sil 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
33..1155.. ffeeaattuurree__ccaappii:: IIss tthheerree aa CCAAPPII iinntteerrffaaccee aavvaaiillaabbllee??
Currently, these cards support the CAPI 2.0 interface:
+o the active card AVM B1.
+o the active DIVA Server cards from Eicon.
+o the active cards from Hypercope (HYSDN Champ2, HYSDN Ergo2, HYSDN
Metro4)
+o the passive Fritz card from AVM. However, please note that you have
to download and manually install the binary drivers for this from
AVMs ftp server. See the following web site for a nice howto:
. There was also lots
of stuff written in the mailing list on this. Here is a German
website which has some nice installation instructions:
or
or
Please note that due to its binary
nature, this driver will not work if your distribution is
incompatible with it (e.g. based on 64 bit).
This interface follows the official CAPI 2.0 standard that was
established recently for Linux by the CAPI Association (see
). Since kernel 2.6.0 the CAPI interface has
been used as the general interface, also for other cards. For passive
cards, the new driver mISDN will replace the old hisax driver once it
is fully functional.
There are no plans to implement a CAPI 1.1 interface.
33..1166.. ffeeaattuurree__uuuuss:: IIss UUUUSS ((uusseerr ttoo uusseerr ssiiggnnaalliinngg)) ssuuppppoorrtteedd??
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 ``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.
33..1177.. ffeeaattuurree__ssuubbaaddddrreessssiinngg:: IIss ssuubbaaddddrreessssiinngg ssuuppppoorrtteedd??
Yes, isdn4linux does support subaddressing (available in France). To
configure it, give HiSax the number in this format:
.. 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.
33..1188.. ffeeaattuurree__ggssmmvv111100:: CCaann II ccoonnnneecctt ffrroomm mmyy PPDDAA vviiaa GGMMSS cceelllluullaarr
pphhoonnee ttoo iissddnn44lliinnuuxx??
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 ``config_gsmv110'' for details on
how to configure it.
33..1199.. ffeeaattuurree__rreevveerrsseeddccaarrdd:: CCaann iissddnn44lliinnuuxx lloogg AALLLL aaccttiioonnss hhaappppeenniinngg
oonn tthhee IISSDDNN bbuuss ((dduuaall mmooddee//rreevveerrsseedd ccaarrdd//CCOOLLPP//......))??
Yes, isdn4linux offers several possibilities to do this. Have a look
at question ``isdnlog_reversedcard''.
Please note that you may also use the software ISDN Sniffer for this,
see the German web site 98 1
______________________________________________________________________
Make sure that the crossed cable is terminated even if it is very
short! Nothing will work without termination, not even a 1m cable.
Some HFC card already have jumpers for termination.
However, this will only give you the physical connection. Up to now
isdn4linux does not (yet?) implement the higher level ISDN protocol
DSS1 (this means that isdn4linux can not pretend to an ISDN device
that it is an ISDN exchange, and give it the proper ISDN commands).
As a result, you can simulate a leased line, but not pretend to be the
PBX.
33..2266.. ffeeaattuurree__llccrr:: CCaann iissddnn44lliinnuuxx ddoo lleeaasstt ccoosstt rroouuttiinngg ((LLCCRR))??
Yes, this feature is now being supported by isdnlog. What it does is
that it allows isdnlog to choose your telephone provider when placing
a call through your ISDN card, depending on the time of day and the
current rate information. Since isdnlog 4.16 an external script is
called (if configured) to change various ISP settings (e.g. DNS
lookup, proxy setup,...).
Note: the ABC-extensions (s. ``docu_abc'') must be installed. Also,
isdnlog should always be running (otherwise your dialout will be
delayed by 3 seconds). If the ABC-extensions are not installed,
isdnlog prints hints to the log file, which provider would have been
chosen.
33..2277.. ffeeaattuurree__iinntteerrnneettddiiaalliinn:: CCaann iissddnn44lliinnuuxx bbee sseettuupp ssuucchh tthhaatt iitt
ddiiaallss iinnttoo tthhee IInntteerrnneett,, wwhheenneevveerr II ccaallll iitt vviiaa tteelleepphhoonnee??
Yes, this is possible with isdnlog. You have to configure isdnlog such
that it can execute a script whenever someone dials in. In the script
you can check for the correct telephone number, then trigger the
dialin. To access your computer then over the internet, you can then
access it via its ip address. In case of dynamic ip address
assignment, you probably want to store the new ip somehow. Storage in
a html page or via dynamic DNS may be good possibilities.
If you understand German, there was an article about exactly this
setup in ct 18/2002, page 204 (Bei Anruf Internet - Handy-Anruf loest
Internet-Einwahl aus). Also, the following German web site explains
how to set up such a configuration:
33..2288.. ffeeaattuurree__ffuuttuurree:: WWhhiicchh ffeeaattuurreess aarree ppllaannnneedd ffoorr tthhee ffuuttuurree??
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...
44.. ddooccuu:: DDooccuummeennttaattiioonn,, HHoowwttoo''ss,, TTiippss && TTrriicckkss,, MMaaiilliinngg LLiisstt//NNeewwss--
ggrroouupp
44..11.. ddooccuu__ffiirrsstt:: WWhhaatt ddooccuummeennttss sshhoouulldd II rreeaadd ffiirrsstt??
+o ISDN kernel subsystem: /usr/src/linux/Documentation/isdn/README
+o ISDN cards: /usr/src/linux/Documentation/isdn/README.card E.g.:
/usr/src/linux/Documentation/isdn/README.HiSax
+o Synchronous PPP: /usr/src/linux/Documentation/isdn/README.syncppp
/usr/src/linux/Documentation/isdn/README.syncPPP.FAQ
+o Voice capability: /usr/src/linux/Documentation/isdn/README.audio
+o ISDN Utilities: /usr/src/isdn4k-utils-version/README(.*)
Many of the utilities also have man pages!
To get a good technical overview over isdn4linux have a look at the
great whitepaper 'ISDN4Linux, CAPI4Linux, CPI4Hisax and other cute
acronyms: The ISDN subsystem in the Linux kernel', which can be found
at:
For a Suse distribution the following information might be helpful:
+o /usr/doc/packages/i4l* (for i4l in general)
+o /usr/doc/faq/faq/PPP-FAQ (for synchronous PPP)
+o /usr/doc/howto/mini/Mail-Queue.gz (for email configuration)
Also, read the excellent manual!
For a Debian distribution the following information might be helpful:
/usr/share/doc/isdnutils/HOWTO.gz
If you are reader of the German computer magazine ct, they had very
helpful articles at least on these issues:
+o ct 5/1998, page 224: Der erste Kontakt/Linux: Mit PPP ans Internet
+o ct 21/1998, page 288: Reiseleiter/Internet-Anbindung fuer das LAN
+o ct 25/1998, page 218: Bei Anruf Netz/Linux: Dial-In Server
+o ct 7/2001, page 228: Des Surfers Bastelstunde: Mobilfunktechnik
HSCSD ausschoepfen (also contains information on dial-in
configuration without HSCSD).
+o ct 15/2002, page 204: Bei Anruf Internet: Handy-Anruf loest
Internet-Einwahl aus
+o ct 3/2004, page 182: Heimserver im Eigenbau - Teil 4: ISDN-
Grundlagen fuer Linux(also contains information about the new mISDN
driver). An online version is available on:
.
44..33.. ddooccuu__aabbcc:: WWhheerree ddoo II ffiinndd ddooccuummeennttaattiioonn oonn tthhee aabbcc eexxtteennssiioonnss??
You can find it on: . 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
55.. hhaarrddwwaarree:: SSuuppppoorrtteedd hhaarrddwwaarree,, iittss ssppeecciiaalliittiieess,, aanndd hhaarrddwwaarree--
rreellaatteedd pprroobblleemmss
55..11.. hhaarrddwwaarree__ssuuppppoorrtt:: WWhhiicchh hhaarrddwwaarree iiss ssuuppppoorrtteedd??
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 isapnptools. For details on the
configuration see question ``config_pnp''.
Internal cards may be ``active'', ``semi-active'', or ``passive''.
Unless you have paid big money, assume you have a passive card. More
about the difference: see question ``hardware_activepassive''.
Right now there is a driver for all passive card with certain Siemens
chipsets (HiSax driver). Have a look at the 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 1st
February 2002 (constantly improving):
+o Teles 8.0/16.0/16.3 and compatible ones (like: Dr. Neuhaus Niccy
1016, Creatix 16/S0)
+o Teles 16.3c (can not be used as reversed card)
+o Teles S0/PCMCIA (old hardware)
+o Teles PCI
+o Teles S0Box
+o Creatix S0Box
+o Creatix PnP S0
+o Compaq ISDN S0 ISA card
+o AVM A1 (Fritz, Teledat 150 ISA)
+o AVM Fritz PCMCIA
+o AVM Fritz PnP
+o AVM Fritz PCI (Teledat 150 PCI)
+o AVM Fritz PCI v2
+o ELSA Microlink PCC-16, PCF, PCF-Pro, PCC-8
+o ELSA Quickstep 1000
+o ELSA Quickstep 1000PCI (new name: ELSA Microlink PCI)
+o ELSA Quickstep 3000 (same settings as QS1000)
+o ELSA Quickstep 3000PCI
+o ELSA PCMCIA
+o ITK ix1-micro Rev.2 (also: ITK colombus card)
+o Eicon DIVA 2.0 ISA and PCI (S0 and U interface, no PRO version)
+o Eicon.Diehl Diva 2.01 ISA and PCI, and Diva 2.02
+o Eicon DIVA Piccola
+o ASUSCOM NETWORK INC. ISDNLink 128K PC adapter (order code I-
IN100-ST-D)
+o Dynalink IS64PH (OEM version of ASUSCOM NETWORK INC. ISDNLink 128K
adapter)
+o All other ASUSCOM/Dynalink cards (includes OEM versions; in total
more than 50 card versions)
+o PCBIT-DP (OEM version of ASUSCOM NETWORK INC. ISDNLink)
+o HFC-2BS0 based cards (TeleInt SA1)
+o Sedlbauer Speed Card (Speed Win, Teledat 100, PCI, Fax+)
+o Sedlbauer Speed Star/Speed Star2 (PCMCIA)
+o Sedlbauer ISDN-Controller PC/104
+o USR Sportster internal TA (compatible Stollmann tina-pp V3)
+o ith Kommunikationstechnik GmbH MIC 16 ISA card
+o Traverse Technologie NETjet PCI S0 card and NETspider U card
+o Dr. Neuhaus Niccy PnP/PCI
+o Siemens I-Surf 1.x (with ISAR =< try type 29)
+o Siemens I-Surf 2.x (with IPAC => try type 12 asuscom)
+o Trust PCI (only the old one with Siemens chip; the one called
'Wisecom' in NL does not work)
+o ACER P10
+o HSR Saphir
+o Berkom Telekom A4T
+o Scitel Quadro
+o Gazel ISDN cards
+o HFC-PCI based cards
+o PCI/Winbond W6692 based cards
+o HFC-S+, HFC-SP/PCMCIA cards
+o HFC-USB ISDN TAs
+o ST5481 based USB ISDN adapters, e.g. BeWan Gazel 128 USB
Note:
+o AVM A1+ is not supported
+o PCF, PCF-Pro: up to now, only the ISDN part is supported
+o PCC-8: not tested yet
+o Eicon Diva U interface not tested
+o Some cards do not work when compiled into the kernel, only when
loaded as modules.
+o Asuscom card: please note that the ISA version is a different type
(12) then the PCI version (35 for HFC chip or 36 for Winbond chip)!
+o To distinguish between HFC-PCI and PCI/Winbond, have a look at the
output of cat /proc/pci. You have HFC-PCI if you have a line saying
"Master capable" for your card.
+o DataFire Micro V PCI = HFC-based card (type 35)
+o Xircom Cardbus Eth10/100+ (PCMCIA) is not supported by isdn4linux,
but you can use it like an active external ISDN terminal adapter
(requires the xircom and serial driver).
+o Gazel 128 USB from BeWAN Systems is supported as hisax_st5481
module. For configuration hints have a look at:
55..22.. hhaarrddwwaarree__aaccttiivveeppaassssiivvee:: WWhhaatt iiss tthhee ddiiffffeerreennccee bbeettwweeeenn aann aaccttiivvee
aanndd aa ppaassssiivvee IISSDDNN ccaarrdd??
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:
+o AVM B1
+o AVM C4
+o Eicon DIVA Server BRI PCI
+o Eicon DIVA Server 4BRI
+o IBM Active 2000 ISDN card
+o ICN
+o PCBIT-D
55..33.. hhaarrddwwaarree__rreeccoommmmeenndd:: WWhhiicchh ccaarrdd iiss rreeccoommmmeennddeedd bbyy tthhee ddeevveellooppeerrss??
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 ``country_certified''.
If you want to buy an active card, then the developers would recommend
the PCI Server from Eicon. The reason is that it can fax on both
channels with AT class 2 commands, and includes a V.90 modem. The AVM
B1 works also very well, and is likewise recommended. Old versions (up
to 3.0) could receive faxes only on one channel, but since AVM B1 PCI
V4 all channels can be used simulateously for sending and receiving
faxes. See also question ``hardware_avmb1'' for more details about
this card. The Hypercope cards have also been reported to work very
well, servicing all available channels for faxing. However, they
require a hardware update for faxing and their linux driver is fairly
new. See also question ``hardware_hypercope'' for more details about
this card.
If faxing is important for you, but you don't want to spent the money
for an active card, then a card with ISAR chipset may work well for
you, e.g. Sedlbauer Speedfax+ (in Germany you may be able to buy it
at Conrads).
And if you want to buy a USB terminal adapter, then the Gazel 128 USB
from BeWAN Systems has been reported to work
fine with the hisax_st5481 module.
55..44.. hhaarrddwwaarree__eexxtteerrnnaall:: DDooeess iissddnn44lliinnuuxx ssuuppppoorrtt eexxtteerrnnaall tteerrmmiinnaall
aaddaapptteerrss??
Generally not, but it doesn't need to. Terminal adapters are designed
to behave either like a modem or like a network card. Linux already
supports both modems and network cards without isdn4linux - so no
special ISDN driver is necessary (which usually greatly simplifies the
configuration). For example, have a look at the dialout program
wvdial.
However, there is (at least) one exception. The Gazel 128 USB from
BeWAN System in France has been reported to
work fine with the hisax_st5481 module. For configuration hints have a
look at: .
55..66.. hhaarrddwwaarree__iirrqq:: WWhhyy sshhoouulldd II aavvooiidd IIRRQQ 1122 aanndd 1155 ffoorr mmyy IISSDDNN ccaarrdd??
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.
55..77.. hhaarrddwwaarree__iirrqqsshhaarriinngg:: CCaann tthhee iissddnn44lliinnuuxx ddrriivveerr wwoorrkk wwiitthh sshhaarreedd
iinntteerrrruuppttss??
Yes, the drivers have been written to work with shared interrupts.
However, at least for the AVM Fritz!PCI card occasional problems have
been reported for motherboards with a BIOS bug (DFI motherboards
K6BV3+, P5BV3+ K6XV3). Try to disable the BIOS option CPU to PCI
WRITE Buffer in those cases as a workaround.
55..88.. hhaarrddwwaarree__ss22mm:: WWhhiicchh SS22MM ccaarrddss aarree ssuuppppoorrtteedd??
At least these S2M cards have been reported to work:
+o AVM T1
+o Eicon S2M-ISA or DIVA Server PRI family (see
for anyone
who wants to fix the remaining glitches (status as of Jan 10,
2000). Please be aware that the code of the latest developments can
not be compiled for 32 bit machines like all sun-4m machines.
3. PCI ISDN adapter: Modern SUN-workstations and servers have a
different busstructure nowadays. The ULTRA series uses the PCI-bus.
Allthough some pc boards seem to be working in a SUN, there are NO
reports (yet) of properly functioning ISDN-PCI-boards in the SUN
environment. Please write me if anyone ever succeeds.
55..1144.. hhaarrddwwaarree__ppppcc:: CCaann II rruunn iissddnn44lliinnuuxx oonn aa PPoowweerrPPCC wwiitthh LLiinnuuxx??
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
``hardware_external''), this is not covered here any further.
55..1155.. hhaarrddwwaarree__mmaaxxccaarrddss:: HHooww mmaannyy IISSDDNN ccaarrddss ccaann II ppuutt iinnttoo mmyy ccoomm--
ppuutteerr??
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 ``hardware_s2m''.
See question ``config_manycards'' about the specialities for the
configuration of more than one card.
55..1166.. hhaarrddwwaarree__hhffcc:: WWhhaatt iiss ssppeecciiaall aabboouutt ccaarrdd wwiitthh aann HHFFCC cchhiipp??
Cards with an HFC-PCI chip allow some specialities that are not
possible with other ISDN cards. So it is possible to run the card in
NT mode (requires crossing the ISDN connection and change by software)
- this means you can simulate to another ISDN card that your card is
an NTBA. Since isdn4linux does not implement the level 3 protocol used
by the exchange, you can only use this mode like a leased line.
However, some special software named PBX4Linux has been written for
this. You may want to have a look at the German article in ct 9/2004
on how to use PBX4Linux. You can also check the web site
. You may especially be interested in the
information about card support for the NT mode with mISDN at:
.
Another alternative for emulation of a PBX is Asterisk, to be found
on:
.
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
``isdnlog_reversedcard'') but with HFC chips this works much more
reliably and cleanly. You can activate this special echo mode by
calling:
______________________________________________________________________
hisaxctrl 10 1
hisaxctrl 12 1
______________________________________________________________________
You can deactivate it by calling:
______________________________________________________________________
hisaxctrl 12 0
hisaxctrl 10 2
______________________________________________________________________
Parameter 10 changes the number of available channels, parameter 12
switches the echo mode.
Cards with HFC chips may be difficult to run on older mainboards.
Ensure with lspci -v that an IRQ has been assigned to the card (if not
check the PnP bios settings). Verify that the card is located in a
slot with busmaster DMA capabilities. Verify whether the kernel is
compiled such that it will run on your CPU (newer distributions may
not run on CPUs like 486 or Pentium; Suse provides the kernel 'k_i386'
to run with older hardware).
55..1177.. hhaarrddwwaarree__eellssaa:: WWhhaatt sshhoouulldd II kknnooww aabboouutt IISSDDNN ccaarrddss ffrroomm EELLSSAA??
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 ``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 pcitest from
Karsten Keil keil@isdn4linux.de. 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:
RJ11 - RJ45
pins 1234 12345678
Cable abcd --abcd--
Regarding the Elsa Microlink ISDN USB: contrary to previous
announcements it does NOT works like a serial terminal adapter with
the USB communication class driver. Currently, it is not supported by
isdn4linux.
55..1188.. hhaarrddwwaarree__sseeddllbbaauueerr:: WWhhaatt iiss ssppeecciiaall aabboouutt tthhee SSeeddllbbaauueerr ccaarrdd??
The Sedlbauer card comes in several versions:
+o Sedlbauer Speedwin
+o Sedlbauer Speedfax
+o Sedlbauer Speedfax PCI
The Speedwin is a normal passive card with no specialities.
The Speedfax has a very special hardware: it is a semiactive card
based on the ISAR chipset which supports sending/receiving faxes and
an analog modem up to 14400. It is special in that you use it with
HiSax which normally works only for passive cards. As all active card
you have to load its firmware (in this case after loading HiSax) from
the file ISAR.BIN, which is part of the isdn4k-utils.
Please note that compression (V42bis, MNP) are not implemented in
firmware, and therefore not supported when using the analog modem. The
ideal init string for the card to allow modem dialin is AT%C0\N0.
If for some fax senders receiving by Hylafax does not work, then try
to set the following configuration parameter for Hylafax:
______________________________________________________________________
Class1SwitchingDelay: 75
______________________________________________________________________
The Sedlbauer Speedfax PCI is special in that it was produced just for
Linux - there is no driver for it under Windows.
55..1199.. hhaarrddwwaarree__tteelleess:: WWhhaatt sshhoouulldd II kknnooww aabboouutt bbeeffoorree bbuuyyiinngg aann IISSDDNN
ccaarrdd ffrroomm TTeelleess??
First the latest news: according to the German magazine ct 02/2001,
Teles has closed down its business activities in the ISDN area.
Therefore, this FAQ does not really apply any more. However, I'll keep
this FAQ for now to document Teles' attitude towards their customers.
The author has had personal experience with Teles since 1994.
One of the most frequently asked questions for Teles cards: The Teles
card 16.3c has a crippled FIFO, therefore it is required to use
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 netjet driver, the teles driver will NOT work (that card
identifies itself as 'TigerJet Tiger300' when doing a cat /proc/pci).
Now some comments about Teles in general (these are the personal
opinions of the author of this FAQ, please blame nobody else than me):
Teles' business practices are very customer- and developer-unfriendly
when compared to those of other companies. Naturally, the developers
give priority to cards for which support is available, and where the
specifications are freely available.
So far, Teles has had a very unfriendly attitude towards the i4l
developers. No support has ever been received from them, and they
don't publish any information about how to access their card. The
developers have invested a lot of private effort into getting this
card to work from the beginning without receiving any support. The
driver has been a complete private effort. Yet, Teles has bragged on
their web site that their cards run under Linux, without giving proper
credit.
Even companies that buy Teles cards and resell them under their own
name have not been able to improve the support. This has lead to the
situation where a re-branding company (!) itself had to go through the
effort of obtaining approval to legally use i4l in Germany on a Teles
card.
From a customer point of view, check out the prices for their hotline
before you buy any hardware from them! The author of the FAQ refuses
to use any hotline that charges 216,- DM per hour. Reports about
quality and waiting time have not always been favorable.
And this company did not even give away drivers for other operating
systems, like Windows, for free for many years (I know about
1995-2000). Only since about April 2000 you can download the drivers
over the Internet. Before you had to dial up a very expensive number
(0190) where you had to pay about DM 1,20 per minute in Germany to
download the driver. Not that it's advisable to use Windows anyway,
but just to let you know...
Warning: Teles has often changed their cards without notice, while
still using the same name. When you buy a Teles card, you may find out
that your brand-new card can not be supported by i4l! (As has happened
many times in the past...)
The developers will try to support new Teles cards when information
about how to access it becomes available, and when they have no other
priorities. Of course you can always send a patch.
55..2200.. hhaarrddwwaarree__ffrriittzz:: WWhhaatt sshhoouulldd II kknnooww wwhheenn ccoonnffiigguurriinngg aa FFrriittzz!!
ccaarrdd ((aallssoo kknnoowwnn aass:: AAVVMM AA11,, TTeelleeddaatt 115500,, BBTT SSppeeeeddwwaayy))??
The Fritz! card comes in different variations. Since the PCI card and
the ISA/PNP card have the same type (27), hisax will assume an ISA/PNP
card if you pass an io address, and a PCI card if you do NOT pass an
io address. Make sure to give the parameters properly.
The newest Fritz! PCI card (v2.0) is now supported by a new driver,
however it has not yet been tested thoroughly. The card can be
identified by lspci returning 0e00 as the card id.
If the interrupt for the card is shared with other devices and your
card does not work, then there could be an issue with the motherboard.
See question ``hardware_irqsharing'' for this.
One very interesting thing: the Fritz! card is currently the only
passive card for which a capi driver exists. As a result, it can be
configured to fax. See question ``feature_capi'' and
for more
information on this. Usage of the capi driver is completely optional,
you might as well stay with the standard driver if you do not need
capi support.
55..2211.. hhaarrddwwaarree__aavvmmbb11:: WWhhaatt iiss ssppeecciiaall aabboouutt tthhee AAVVMM BB11 ccaarrdd??
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:
for
more details about it.
55..2222.. hhaarrddwwaarree__hhyyppeerrccooppee:: WWhhaatt iiss ssppeecciiaall aabboouutt tthhee HHyyppeerrccooppee ccaarrddss??
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:
Configuration is similar to that of an AVM
B1.
55..2233.. hhaarrddwwaarree__iiccnn:: WWhhaatt iiss ssppeecciiaall aabboouutt tthhee IICCNN ccaarrdd??
This was the first active card supported by isdn4linux. The
manufacturer has always supported i4l developers (
9 ISAR.BIN
___________________________________________________________________
(You find the file ISAR.BIN in the isdn4k-utils or on the I-SURF cd.)
+o Fax: The I-Surf 1.0 can be setup to send and receive faxes (see
question ``feature_fax'' for details).
55..2255.. hhaarrddwwaarree__ddiivvaa:: WWhhaatt sshhoouulldd II kknnooww aabboouutt tthhee EEiiccoonn DDiivvaa ccaarrddss??
In general, a dedicated driver exists which supports the active Eicon
Diva cards very well. The Pro series are not supported by isdn4linux
since it is a semiactive card with a DSP as a B-channel controller.
There is no code available in isdn4linux to dynamically load DSP
programs into the card. However, check Eicon's website; maybe by now
they provide pre-compiled driver for their cards not supported by
isdn4linux.
55..2266.. hhaarrddwwaarree__ccrroosssseeddccaabbllee11:: IIff ii44ll uusseess oonnee BB--cchhaannnneell tthheenn tthhee
ootthheerr oonnee wwiillll bbee bblloocckkeedd ((iinnccoommiinngg aass wweellll aass oouuttggooiinngg))......
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.
55..2277.. hhaarrddwwaarree__ccrroosssseeddccaabbllee22:: HHooww ccaann II tteesstt wwhheetthheerr aa aa//bb ccaabbllee ppaaiirr
hhaass bbeeeenn ccrroosssseedd??
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:
| | | |
| | | |
1 2 3 4
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.
55..2288.. hhaarrddwwaarree__ppbbxx:: ii44ll iiss ccoonnnneecctteedd ttoo tthhee iinntteerrnnaall bbuuss ooff aa PPBBXX..
AAnnyy pprroobblleemm??
Many PBX run non-standard ISDN protocolls on their internal bus.
In old versions (before end of August 2003) this could cause i4l to
print warnings like "Unexpected discriminator 0xZZ" (where ZZ is a
hexadecimal number) when it encounters unexpected frames (some old
versions even crash). This can increase your message file by as much
as 1 MB in 3 days. The PBX Ackermann Euracom 181 (discriminator 0xaa)
as well as 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 processctrl(...) in processor.c and recompiling
isdnlog. Since August 2003 ignoring these unknown packages has become
the default, therefore the recompile is not necessary any more.
Please note that isdnlog will not be able to log any incoming data
packages, since the PBX has to forward the packages. To see
everything, you have to bypass the PBX.
Please be aware, that the PBX may hang if the ISDN card does not
respond to the PBX requests - bypass the PBX in such a case.
Also, a PBX may run 1TR6 protocoll on the internal bus by default,
rather than Euro ISDN. You have to configure i4l (or the PBX)
accordingly, best is you try to configure both on the same or similar
protocolls.
Also the MSN may be different than you expect. Check several versions,
no digit (then use 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.
When you can not dial out, the most common problem is that you have
not set the MSN properly for outgoing calls, which causes the PBX to
refuse your request.
For dial in be aware that some PBX add a leading 0 to any incoming
telephone number, so adjust your configuration for the secure option
accordingly.
Last, remember that you may have to configure your PBX to 'route'
incoming calls onto the internal ISDN bus.
If you have a point-to-point configuration ('Anlagenanschluss') then
you cannot connect your card directly to the S0 bus in parallel to the
PBX (otherwise nothing will work). You have to connect to an internal
ISDN bus. Your MSN is usually the extension at the end of your
telefon number.
If your PBX is the Ackermann Euracom, then you may also check out this
German site for the configuration software maKs:
55..2299.. hhaarrddwwaarree__tteelleessttrroouubbllee:: TThhee PPNNPP ttoooollss ddoonnee wwoorrkk wwiitthh mmyy TTeelleess
1166..33 PPNNPP ccaarrdd!!
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.
55..3300.. hhaarrddwwaarree__eellssaaccaabblleettrroouubbllee:: OOnn mmyy EELLSSAA ccaarrdd,, tthhee LLEEDD ffoorr tthhee
lloossss ooff tthhee TTEEII oofftteenn bblliinnkkss.. MMyy ccoonnnneeccttiioonnss aarree aallssoo oofftteenn ddiiss--
rruupptteedd......
These blinking LEDS are often caused by a bad cable or a too long or
unterminated SO bus.
55..3311.. hhaarrddwwaarree__eellssaaiirrqq:: MMyy EELLSSAA QQuuiicckksstteepp 11000000 IISSAA ccaarrdd pprroodduucceess vveerryy
mmaannyy iinntteerrrruuppttss wwiitthh tthhee HHiiSSaaxx ddrriivveerr.. IIss tthhiiss nnoorrmmaall oorr aa pprroobblleemm
wwiitthh tthhee HHiiSSaaxx ddrriivveerr??
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:
keil@isdn4linux.de
66.. ccoonnffiigg:: GGeenneerraall iinnffoorrmmaattiioonn aabboouutt CCoonnffiigguurraattiioonn
66..11.. ccoonnffiigg__mmssnn:: HHooww sshhoouulldd II sseett uupp iissddnn44lliinnuuxx wwiitthh mmyy MMSSNNss??
See section ``msn''.
66..22.. ccoonnffiigg__hhaarrddwwaarree:: HHooww sshhoouulldd II ccoonnffiigguurree mmyy hhaarrddwwaarree?? IIss tthheerree
ssoommeetthhiinngg ssppeecciiaall II sshhoouulldd kknnooww aabboouutt mmyy IISSDDNN ccaarrdd??
Have a look in section ``hardware''.
66..33.. ccoonnffiigg__ddiiaalloouutt:: HHooww sshhoouulldd II ccoonnffiigguurree ddiiaalloouutt??
See section ``dialout''.
66..44.. ccoonnffiigg__ddiiaalliinn:: HHooww sshhoouulldd II ccoonnffiigguurree ddiiaalliinn??
See section ``dialin''.
66..55.. ccoonnffiigg__ssuussee:: II ccaann nnoott sseelleecctt mmyy ccaarrdd iinn yyaasstt??
If you have a SuSE distribution, and you can not find your card in
yast, then select card generic and enter the exact parameters in the
special case line, like: type=27 protocol=2 for Fritz!PCI and Euro
ISDN. Get a newer kernel if the desired type is not yet supported.
66..66.. ccoonnffiigg__ppnnpp:: HHooww ddoo II ccoonnffiigguurree aa PPNNPP ((PPlluugg aanndd PPllaayy)) ccaarrdd??
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:
1. With "make menuconfig" (or "make config") set the following kernel
options:
+o ISDN = "M" (as module - otherwise PNP doesn't work!)
+o HiSax = "M" (as module - otherwise PNP doesn't work!)
+o 16.3/PNP support
+o EURO support
2. Compile and install kernel and modules, depmod. (Reboot!)
3. Read the configuration of the PNP card with:
___________________________________________________________________
pnpdump -c > /etc/isapnp.conf
___________________________________________________________________
4. Verify whether pnpdump has prepared the configuration file
/etc/isapnp.conf properly:
+o 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).
+o 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!)
+o Comment removed in front of ACT Y!
5. Activate the configuration with:
___________________________________________________________________
isapnp /etc/isapnp.conf
___________________________________________________________________
6. Now the HiSax module can be started for Euro-ISDN with:
___________________________________________________________________
modprobe hisax io=4,2,INT,IO0,IO1
___________________________________________________________________
(Replace INT, IO0, and IO1 with your values in isapnp.conf.)
66..77.. ccoonnffiigg__ssttaarrttssttoopp:: HHooww ccaann II ssttaarrtt aanndd ssttoopp tthhee IISSDDNN ccoonnffiigguurraa--
ttiioonn??
There are several options:
+o Reboot: rebooting your computer always works. If you compiled i4l
into the kernel, then this is actually your only chance. The
remaining options only work if you configure i4l using modules.
+o Manual: Unload the modules used by i4l with rmmod, then reload them
with modprobe.
+o Runlevel: use telinit to switch to a runlevel which does not
contain ISDN, then switch back to the original runlevel.
+o Scripts: most distributions come with start/stop scripts. For
example, on a Suse 7.0 distribution, this will stop ISDN:
___________________________________________________________________
rcroute stop
rci4l stop
rci4l_hardware stop
___________________________________________________________________
This will restart ISDN:
______________________________________________________________________
rci4l_hardware start
rci4l start
rcroute start
______________________________________________________________________
66..88.. ccoonnffiigg__kkeerrnneelldd:: WWhhyy sshhoouullddnn''tt II uussee kkeerrnneelldd ttoo llooaadd tthhee IISSDDNN
mmoodduulleess iinn tthhee kkeerrnneell aass nneeeeddeedd??
_k_e_r_n_e_l_d 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.
66..99.. ccoonnffiigg__rruunnlleevveell:: HHooww ccaann II bboooott LLiinnuuxx ssoommeettiimmeess wwiitthh IISSDDNN,, aanndd
ssoommeettiimmeess wwiitthhoouutt??
Yes, you can define two different run level for this (under SysVInit)
in /etc/inittab. One run level includes the ISDN processes, where the
other one does not.
66..1100.. ccoonnffiigg__mmaannyyccaarrddss:: HHooww ddoo II ccoonnffiigguurree mmoorree tthhaann 11 IISSDDNN ccaarrdd??
There are some specialities for configuration of more than 1 card:
+o You have to start a driver for every type of card you have, with
the correct configuration arguments.
+o To handle more than 1 card with the same driver (e.g. HiSax should
handle an ELSA and an ASUS card), you have to pass the
configuration arguments for all cards to this driver. Please note,
that you'll have to use modules for more than two cards, to pass
all arguments. As an example, you can load HiSax for two Sedlbauer
cards with the following command:
___________________________________________________________________
modprobe -v hisax protocol=2,2 type=28,28
___________________________________________________________________
+o Driver ID: the HiSax driver uses 'HiSax' as the default for a
driver id if you have only one card. For more cards you have to set
the id explicitely, e.g. for two cards in the form of
___________________________________________________________________
id="contr0%contr1"
___________________________________________________________________
+o Dialin of many people at the same time: have a look at question
``dialin_manyparallel''.
+o Dialout through several cards: have a look at question
``dialout_manycards''.
66..1111.. ccoonnffiigg__mmaannyycchhaannnneellss:: HHooww ccaann II iinnccrreeaassee ii44ll''ss mmaaxxiimmuumm nnuummbbeerr ooff
cchhaannnneellss??
Increase the parameter ISDN_MAX_CHANNELS in
/usr/src/linux/include/linux/isdn.h and rebuild the isdn stuff. Don't
forget to create the additional devices with makedev.sh (part of
isdn4k-utils) or by hand.
66..1122.. ccoonnffiigg__ggssmmvv111100:: HHooww ddoo II ccoonnnneecctt mmyy PPaallmmPPiilloott vviiaa GGSSMM oovveerr
VV..111100 ttoo mmyy ccoommppuutteerr??
A connection via GSM will first go to the GSM provider via a special
air transmission protocol. To forwarding the data on to an analog or
ISDN line, an adapter called IWF (interworking function) has to
translate this into the analog or ISDN specific transmission protocol.
Which analog or ISDN transmission protocol is being used depends on
how the mobile phone requests its GSM connection. An analog
connection is not very attractive due to the lengthy modem handshaking
on dialin. For ISDN, HDLC and X.75 are currently not supported by the
IWF, so the choices are down to V.110 and V.120. V.120 has better
flow control and error correction, but currently isdn4linux only
supports V.110.
On the dialup server set up async PPP with a normal pppd on a ttyI*
device (sync ppp will not work). Additionally to setting the msn, you
have to set V.110 and the transmission rate to 9600 with AT&R9600
(/usr/src/linux/Documentation/isdn/README gives more details on the
V.110 bitrate adaption for this command). Switch off autoanswer with
ATS0=0 if you use mgetty. pppd needs to be called with noccp and
require-pap.
On the GSM mobile phone side, request an ISDN V.110 connection with
the command
______________________________________________________________________
AT+CBST=71,0,1+CHSN=1,0,0,0
______________________________________________________________________
For a Nokia 7110, you may have to use the undocumented command
______________________________________________________________________
AT+CBST=75,0,1
______________________________________________________________________
If the bearer capability is reported as "88 90 21 48 06 bb" by
isdn4linux, then you have set it correctly (88 90 21 means V.110, 48
means ASYNC 9.6kbit, 06 means flowcontrol RX/TX, bb means 8 bit 1 stop
none parity).
If the call is indicated with service indicator byte 2 = 0 and not
accepted (happens with some wrongly configured PBX), then adjust with
ATS19=0.
A higher bandwidth of 19.2kbit (HSCSD) could be requested with the
command
______________________________________________________________________
AT+CBST=81,0,1+CHSN=3,0,0,0
______________________________________________________________________
but you can not be sure that your GSM provider will really use this
rate. Configure your dialin server accordingly.
For a mini-howto see:
66..1133.. ccoonnffiigg__hh332233:: HHooww ddoo II ccoonnffiigguurree iissddnn44lliinnuuxx ttoo aacctt aass aa vvooiiccee--
oovveerr--iipp ggaatteewwaayy ffoorr HH..332233 cclliieennttss??
You have to install the Linux H.323 - ISDN Gateway, which can be found
on 7 1
______________________________________________________________________
Additionally, you can use the "AT&Lxxx$dquot; command to configure the
range of telephone numbers isdn4linux should be listening to on the
ttyI* devices.
If you really absolutely want to run your ISDN card for read-only
purposes in parallel to your pbx on a point-to-point connection, then
you have to disconnect the RX leads (pin 3 and 6 on western plug), so
that the NTBA will not see the ISDN card. In this case configure HiSax
normally, NOT in point-to-point mode.
66..1155.. ccoonnffiigg__lliinnkkss:: WWhhaatt hheellppffuull lliinnkkss aarree tthheerree aabboouutt aanndd aarroouunndd
iissddnn44lliinnuuxx??
These are helpful links that are currently available on how to
configure isdn4linux:
+o English:
+o Dutch:
+o German: ;
there is also an ISDN howto (isdn.html) and a ISDN quick-install
guide (isdnquick.html).
+o Tips to configure Suse (and about offline reading):
+o Tips to configure Gentoo:
+o fli4l, a prepackaged Linux version to use an old PC as ISDN router:
(great!)
+o LR101 (a project which tries to create a hardware router based on
Linux):
+o Scripts and installation tips from several people:
+o Documentation on abc extensions:
or
or
+o Vbox development:
+o Michael Hipp's page (general informations):
+o Chargeint tips:
+o Homepage of linecontrol (manage isdn dialing similar to kisdn):
+o (German) Homepage of ISDN Sniffer (read ISDN bus, e.g. via reversed
card):
+o Homepage of ivcall (send and receive fax/voice calls):
66..1166.. ccoonnffiigg__mmiissddnn:: HHooww sshhoouulldd II ccoonnffiigguurree tthhee nneeww mmIISSDDNN ddrriivveerr,, aanndd
wwhhaatt iiss ssoo ssppeecciiaall aabboouutt iitt??
The mISDN driver stands for modular ISDN. It is a complete rewrite of
the old isdn drivers and now communicates via CAPI messages. The mISDN
driver is retire the historical drivers once it is fully functional
within the 2.6.x kernels. As a temporary work around the historical
drivers have been ported into the early 2.6.x kernels to get isdn
working, however, this will be fixed in later versions.
To start mISDN, you have to load all the following modules:
+o capi
+o mISDN_core
+o mISDN_l1
+o mISDN_l2
+o l3udss1
+o mISDN_capi
+o mISDN_isac (for isa card)
+o Hardware specific driver (e.g. hfcpci, or avmfritz)
Not all features are available. It is currently not planned to port
1TR6 (the ancient ISDN protocoll in Germany) to the new driver.
For more information on how to configure it have a look at the
following website: 1 0x33ff
hisaxctrl 11 0xf4f
killall isdnlog
cat /dev/isdnctrl > /tmp/ilog
______________________________________________________________________
Be careful: this will generate a lot of output!
77..44.. ttrroouubbllee__ssttrraatteeggyy:: MMyy iissddnn44lliinnuuxx ddooeessnn''tt wwoorrkk!! HHooww ddoo II bbeesstt ggoo
aabboouutt ffiinnddiinngg tthhee pprroobblleemm??
The following steps are recommended:
1. Check everything is working when booting. Are there unusual error
messages in /var/log/messages? Are all programs active that should
be started at boot (check with ps, or fuser /dev/xxx)? HiSax won't
start if something isn't right. Check question ``trouble_boot''
for what you can check. The old Teles driver, on the other hand,
will appear to start even if it is not working. See the questions
under Troubleshooting Teles.
2. Make sure you configured the ISDN driver either as modules, or you
compiled them into the kernel - never both.
3. Try calling your dialin number with a telephone. The number should
be shown in /var/log/messages. Check for a line like this:
___________________________________________________________________
Call from 0,1,2345 -> 6789
___________________________________________________________________
This means that on channel 0 a call from 2345 with service indicator
(SI) 1 (1 = voice; data would be 7) to MSN 6789 was received. Now at
least you know that you have to configure your MSN to 6789 (or what-
ever other number you find there), and that your isdn4linux kernel
driver understand ISDN commands coming from your ISDN card properly.
If instead of the number 2345 you find a 0, then your ISDN provider
does not pass you the caller id. If you don't find such a line: per-
haps the driver was incorrectly started?!
4. 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 ATS18=1 command to audio.
Now you can get the telephone to ring by dialing ATDxxxxxx, where
xxxxxx is your own MSN.
5. Next we try to transmit data via ISDN. Open 2 different consoles as
root, and on each run "minicom -s"... in the first set "Serial Port
Setup Serial Device" to /dev/ttyI0, and the other to /dev/ttyI1.
Then choose "Exit" and start the modem emulation with "ATZ" and
"AT&Exxxxxx" (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
"CALLER NUMBER: xxxxxxx" and "RING". Accept the call on the second
console with "ATA", and you should then see the message "CONNECT
64000/X.75" 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).
6. Next, try calling a known ISDN BBS. If you don't know of any, try
Gernot (see "Are there sites that offer guest access where I can
test my isdn4linux setup?"). If you have problems with the modem
emulation, see "Troubleshooting Modem Emulation"
7. 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 "pppd, ipppd, syncPPP,
asyncPPP - what is that? What should I use?"), you can use the
normal pppd with modem emulation (i.e. /dev/ttyI*).
8. Ensure that you set up your authentication configuration properly
(see questions in section ``pap''.
Otherwise, it is highly recommended that use an example script form
the HowTo (see the question "Where can I find scripts and other
information on configuring i4l?"). For testing you can try your own
provider or of the guest accounts (see "Are there sites that offer
guest access where I can test my isdn4linux setup?"). 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.... :-)
77..55.. ttrroouubbllee__bboooott:: HHooww ccaann II tteellll wwhheetthheerr mmyy IISSDDNN ccaarrdd hhaass bbeeeenn ccoorr--
rreeccttllyy rreeccooggnniizzeedd??
1. Check for error messages in the boot messages (you can review them
at any time with the command dmesg.
2. For the HiSax driver: During booting a message kernel: HSCX version
A:5 B:5 and kernel: channels 2 should appear. A:4 B:4 is also okay.
Other values (in particular A:??? B:???) 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).
3. Check that your card got an interrupt assigned, e.g. with
___________________________________________________________________
lspci -v
___________________________________________________________________
A common problem is that your BIOS did not assign an interrupt to your
card. HiSax will then complain with "No IRQ for PCI card found". To
fix, set the BIOS option "PnP OS" to NO.
4. Check that the interrupts are registered correctly. Check with
___________________________________________________________________
cat /proc/interrupts
___________________________________________________________________
The following entry indicates that the card is configured on interrupt
11, and so far has received 3 interrupts:
11: 3 + hisax
When you call yourself, the number of received interrupts should
increase.
5. Check the io ports with
___________________________________________________________________
cat /proc/ioports
___________________________________________________________________
77..66.. ttrroouubbllee__iissddnnccaauussee:: II ggeett aann eerrrroorr mmeessssaaggee lliikkee ""ccaauussee:: EE11223344""
((oorr ssiimmiillaarr))??
Just have a look at man isdn_cause to find out what the problem is.
For the very popular cause "E001B" see question ``trouble_e001b''.
77..77.. ttrroouubbllee__ee000011bb:: II ggeett aann eerrrroorr mmeessssaaggee wwiitthh ""ccaauussee:: EE000011BB""??
This is a very popular error and means (see man isdn_cause): 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 ``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 ``config'').
77..88.. ttrroouubbllee__nnoopprroottooccooll:: uuppoonn ssttaarrttuupp ooff HHiiSSaaxx II ggeett tthhee mmeessssaaggee
""WWaarrnniinngg -- nnoo pprroottooccooll ssppeecciiffiieedd""??
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.
77..99.. ttrroouubbllee__eeuurroonnoottssuuppppoorrtteedd:: uuppoonn ssttaarrttuupp ooff HHiiSSaaxx II ggeett tthhee eerrrroorr
""kkeerrnneell hhiissaaxx:: pprroottooccooll eeuurroo nnoott ssuuppppoorrtteedd""??
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.
77..1100.. ttrroouubbllee__uunnkknnoowwnnpprriimmiittiivvee:: uuppoonn ccoonnnneeccttiioonn aatttteemmpptt II ggeett tthhee
eerrrroorr ""llllddaattaa__hhaannddlleerr uunnkknnoowwnn pprriimmiittiivvee""??
This means that the link level protocols do not match (e.g. you tried
to connect with X.75, whereas your provider answers with HDLC). Check
and fix your connection parameters with:
______________________________________________________________________
isdnctrl l2_prot
______________________________________________________________________
77..1111.. ttrroouubbllee__nnootteellrriinnggss:: NNeeiitthheerr mmyy tteelleepphhoonnee nnoorr mmyy ffaaxx mmaacchhiinnee
rriinngg wwhheenn II ccaallll tthheemm wwiitthh iissddnn44lliinnuuxx??
Isdn4linux sets "digital data" 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.
77..1122.. ttrroouubbllee__gguueessttaacccceessss:: AArree tthheerree ssiitteess tthhaatt ooffffeerr gguueesstt aacccceessss
wwhheerree II ccaann tteesstt mmyy iissddnn44lliinnuuxx sseettuupp??
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:
+o Eberhard Moenkeberg emoenke@gwdg.de:
+o 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 "default" route is not your way. /ftp is
exported for NFS; try "showmount -e". You can login as "guest"
without password. FTP as "gast" with password "gast" avoids the
restricted shell.
+o Under ++49-551-7704102, a 28800 bps modem and a Creatix ISDN
card (HDLC only, not X.75) are listening for logins.
+o With the net setup from
you can test NetCall at 551-7704103 (works as is
within Germany, from outside Germany you just have to change the
number).
+o Gernot Zander hifi@scorpio.in-berlin.de:
There's a "gast" 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.
77..1133.. ttrroouubbllee__uunnllooaadd:: II ccaann''tt uunnllooaadd mmyy IISSDDNN mmoodduulleess ((""iissddnn:: DDeevviiccee
oorr rreessoouurrccee bbuussyy"")),, eevveenn ssoo II cclloosseedd aallll IISSDDNN aapppplliiccaattiioonnss??
In this case "fuser -v /dev/isdn* /dev/ippp* /dev/cui* /dev/ttyI*" is
very helpful. This helpful program shows, which processes are using
those devices.
+o Is some program still using an ISDN device?
+o Did you remove all getty's? (They may have restarted automatically)
+o Are isdnlog, imon, iprofd, etc., still running?
+o Maybe there is still a route on your net interface and it's not yet
deleted with "route del xxx"?
+o 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 "kill -9 ipppd pid". Then the net interface is left
"up".
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:
___________________________________________________________________
telesctrl id 3 1 --- dec module_count
telesctrl id 4 1 --- inc module_count
___________________________________________________________________
Please use with appropriate caution and on your own risk!
77..1144.. ttrroouubbllee__ttccppdduummpp:: WWhhyy ddooeess mmyy ttccppdduummpp nnoott wwoorrkk ffoorr iipp ppaacckkeettss
ggooiinngg oovveerr IISSDDNN ((""ttrruunnccaatteedd iipp"" oorr ssoo))?? HHooww ccaann II ggeett aa ttccppdduummpp
ppaattcchheedd ffoorr IISSDDNN??
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 michael@toyland.ping.de wrote on 23 Oct 1996:
Tip for ftp:
There is the patch: "tcpdump-3.0.4-1-isdn.dif.gz"
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 henning@pong.iconsult.com further wrote on 30
Oct 1996:
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
This patch recognizes rawIP, ISDN-IP and CISCO-HDLC and can
dump these packets.
(The patch was attached to the message - it should be easy to find in
the mailing list archive - Ed.)
Sascha Ottolski sascha@alzhimer.isdn.cs.tu-berlin.de gave the
following tip on 5 Nov 1996:
This is a isdn4k-utils-2.0/tcpdump-3.0.3-isdn.diff ! It
work, if one makes some changes: In the file tcp-
dump-3.0.3-isdn/libpcap-0.0/pcap-linux.c after patching you
find the following: else if (strncmp("ppp", device, 3) == 0)
Either you name your ppp devices pppX instead of ipppX, or
change this line, e.g. else if (strncmp("ippp", device, 4)
== 0) ^^^^ ^^ Then tcpdump will also recognize
syncPPP. At least it does for me.
77..1155.. ttrroouubbllee__llooccaatteeccrraasshh:: MMyy iissddnn ddrriivveerr ccrraasshheess mmyy mmaacchhiinnee!! SSiinnccee
II''vvee ccoonnffiigguurreedd iitt aass aa mmoodduullee,, tthhee aaddddrreesssseess cchhaannggee eeaacchh ttiimmee iitt''ss
llooaaddeedd.. HHooww ccaann II ffiinndd oouutt wwhheerree tthhee ddrriivveerr iiss ccrraasshhiinngg??
The driver should be loaded with the command "insmod -m". The output
has to be transformed somewhat to be a form similar to System.map. You
can do it like this:
______________________________________________________________________
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
______________________________________________________________________
(The line ending with "|" has to have the following text on the same
line!) iSystem.map should then be used instead of System.map for find-
ing the error.
77..1166.. ttrroouubbllee__lloottssddeebbuugg:: MMyy hhaarrdd ddiisskk bbeeccoommeess vveerryy aaccttiivvee wwhheenn
iissddnn44lliinnuuxx rruunn.. HHooww ccaann II ttuurrnn tthhiiss ooffff??
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:
______________________________________________________________________
isdnctrl verbose 0
______________________________________________________________________
and/or by removing the "debug" option for ipppd.
77..1177.. ttrroouubbllee__oollddhhaarrddwwaarree:: MMaayybbee mmyy hhaarrddwwaarree iiss ttoooo ssllooww??
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 ``trouble_outofbuffers'' when running out of buffers. See
question ``trouble_littlememory'' on how to reduce the amount of
memory needed.
77..1188.. ttrroouubbllee__oouuttooffbbuuffffeerrss:: II ggeett mmeessssaaggeess lliikkee ""HHSSCCXX RRMMEE oouutt ooff
bbuuffffeerrss"",, ""HHSSCCXX RRFFPP oouutt ooff bbuuffffeerrss"",, ""HHSSCCXX BB EEXXIIRR 1100"" iinn tthhee ssyysslloogg??
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 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:
______________________________________________________________________
#define HSCX_RBUF_ORDER 1
#define HSCX_RBUF_BPPS 2
#define HSCX_RBUF_MAXPAGES 3
______________________________________________________________________
The first two influence the size, the last one the maximum number of
buffers.
77..1199.. ttrroouubbllee__nnoorreesseettiinniitt:: AAfftteerr aa ssoofftt rreesseett,, mmyy ccaarrdd ddooeess nnoott iinnii--
ttiiaalliizzee ccoorrrreeccttllyy..
After you stopped your system with the reboot command or with Ctrl-
Alt-Del, press the reset button (=hard reset). Sometimes the card
needs to receive a hardware signal to reinitialize properly.
77..2200.. ttrroouubbllee__nnooiissddnnccttrrll:: WWhheenn aatttteemmppttiinngg ttoo uussee iissddnnccttrrll,, II ggeett tthhee
eerrrroorr ""//ddeevv//iissddnnccttrrll:: NNoo ssuucchh ffiillee oorr ddiirreeccttoorryy""??
First check whether there is a device /dev/isdnctrl0. If there is,
just create a symbolic link by executing
______________________________________________________________________
ln -s /dev/isdnctrl0 /dev/isdnctrl
______________________________________________________________________
If the device is not there, run the script scripts/makedev.sh, which
is part of the isdn4k-utils.
77..2211.. ttrroouubbllee__nnooiissddnnccttrrll22:: WWhheenn aatttteemmppttiinngg ttoo uussee iissddnnccttrrll,, II ggeett tthhee
eerrrroorr ""//ddeevv//iissddnnccttrrll:: NNoo ssuucchh ddeevviiccee""??
In contrast to "/dev/isdnctrl: No such file or directory" the message
"/dev/isdnctrl: No such device" indicates that the device
/dev/isdnctrl exists, but no ISDN device driver is available. To fix,
load the ISDN modules (verify with "cat /proc/modules" that they are
loaded) or compile the ISDN drivers into the kernel.
77..2222.. ttrroouubbllee__xxoossvviieeww:: xxoossvviieeww ddooeessnn''tt sshhooww aannyy nneettwwoorrkk aaccttiivviittyy
ssiinnccee iinnssttaalllliinngg ii44ll..
Peter Hettkamp Peter.Hettkamp@kassel.netsurf.de wrote:
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.)
77..2233.. ttrroouubbllee__uunnkknnoowwnnhhoosstt:: WWhheenn II ffoorr eexxaammppllee ffrroomm aa WW9955 bbooxx ccaallll uupp
aa ppaaggee wwiitthh NNeettssccaappee,, II oonnllyy ggeett tthhee aannsswweerr ""uunnkknnoowwnn hhoosstt""..
What is entered on the "Win95 box" 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.
77..2244.. ttrroouubbllee__nnoorroouuttee:: AAddddrreesssseess aarree nnooww ffoouunndd,, bbuutt nnooww II ggeett ""nnoo
rroouuttee ttoo hhoosstt""..
Please check:
+o Is the Linux computer entered as the gateway? (Some 'operating
systems' have to be restarted before changes to the networking take
effect)?
+o 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
"doorknob")
+o 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
+o Maybe your route was removed when using syncppp? Check the
questions ``syncppp_noroute'' and ``syncppp_nodefaultroute''.
77..2255.. ttrroouubbllee__nnoollooccaallnneett:: AAfftteerr bboooottiinngg,, mmyy llooccaall nneettwwoorrkk ccaann nnoo
lloonnggeerr bbee rreeaacchheedd.. II uussee tthhee nneettwwoorrkk iinntteerrffaaccee iipppppp00 wwiitthh iiffccoonnffiigg
00..00..00..00;; tthhee ddeeffaauulltt rroouuttee ppooiinnttss ttoo iipppppp00..
Wolfgang Barth wrote on 5 Jan 1997:
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 part-
ner. This was already discussed in de.comp.os.linux.net-
working, 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.
77..2266.. ttrroouubbllee__uunnaauutthhoorriizzeeddccooddeecchhaannggee:: WWhheenn HHiiSSaaxx ssttaarrttss,, II ggeett tthhee
eerrrroorr mmeessssaaggeess ''AApppprroovvaall cceerrttiiffiiccaattiioonn ffaaiilleedd,, uunnaauutthhoorriizzeedd ssoouurrccee
ccooddee cchhaannggeess''??
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).
77..2277.. ttrroouubbllee__ccrrcceerrrroorr:: HHooww ccaann II sseeee tthhee nnuummbbeerr ooff ppaacckkeettss ffoorr HHiiSSaaxx
wwiitthh iinnvvaalliidd CCRRCC??
With HiSax you can view the accumulated number of hardware CRC errors
with:
______________________________________________________________________
hisaxctrl 0 0
______________________________________________________________________
and reset them with:
______________________________________________________________________
hisaxctrl 0 99
______________________________________________________________________
It is ok if you have the occasional CRC error, but if you see a lot of
errors then check your cable termination & connectivity.
77..2288.. ttrroouubbllee__aammpprroogglliibbttooooll:: WWhheenn ccoommppiilliinngg iissddnn44kk--uuttiillss II ggeett tthhee
eerrrroorr ''AAMM__PPRROOGG__LLIIBBTTOOOOLL nnoott ffoouunndd''??
You have to regenerate the files from automake/autoconf with your
version of automake/autoconf. You can do it with the following shell
script (assuming you stored the source code for the isdn4k-utils under
/isdn/isdn4k-util):
______________________________________________________________________
cd ~/isdn/isdn4k-utils
for i in capi20 capiinfo capifax capiinit rcapid ; do
cd $i
rm -f lt*
aclocal
libtoolize --force --automake --copy
automake --add-missing --copy
autoconf
cd ..
done
for i in eicon isdnlog ipppd ; do
cd $i
autoconf
cd ..
done
______________________________________________________________________
88.. mmssnn:: CCoonnffiigguurraattiioonn//MMSSNNss
88..11.. mmssnn__mmyy11:: WWhhaatt iiss mmyy MMSSNN?? WWhhaatt iiff II ddoonn''tt hhaavvee aannyy??
Your telephone company will tell you your MSN. It is your own
telephone number. Please note that you hhaavvee 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
``countries'', together with the following questions, on how to
configure your MSN(s).
88..22.. mmssnn__mmyy22:: HHooww ccaann II ffiinndd oouutt hhooww mmyy tteelleepphhoonnee nnuummbbeerr iiss ttrraannssmmiitt--
tteedd ttoo tthhee ccaalllliinngg ppaarrttyy??
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: "isdn_tty: call from XXX - YYY ignored" (in order for this
to work, you must of course already have the ISDN drivers in your
kernel and active).
88..33.. mmssnn__ccoonnffiigg:: HHooww ddoo II ccoonnffiigguurree mmyy MMSSNN??
If your telephone number were 56789, then it would be configured as
follows:
+o Modem emulation: "AT&e56789"
+o Network interfaces: "isdnctrl msn interface 56789"
+o For test calls to yourself add the area code (e.g. 01234):
___________________________________________________________________
"isdnctrl addphone interface in 123456789" (without leading zero)
"isdnctrl addphone interface out 0123456789" (with leading zero)
___________________________________________________________________
You may find national differences here (check section ``countries'').
88..44.. mmssnn__mmaaxx:: HHooww mmaannyy MMSSNNss aass aa mmaaxxiimmuumm ccaann II uussee ffoorr aann iissddnn ccaarrdd??
For outgoing calls, at maximum one MSN can be used. Only incoming
calls may be configured to allow multiple MSNs.
For ttyI* devices, at a maximum you can listen to EVERY incoming MSN
by using the * as a wildcard:
______________________________________________________________________
at&l*
______________________________________________________________________
When you have a point-to-point connection you should rather specify
the length of your number area with as many times "?" as you have
digits, otherwise your number may be accepted too early on overlapping
receiving. I.e. for 3 digits use:
______________________________________________________________________
at&l???
______________________________________________________________________
For network devices, you can also use a '*' as a wildcard at the end
of the number for incoming calls (e.g. isdnctrl msn interface 123*).
However, this will create problems for outgoing calls. To handle such
a situation properly, please use the isdnctrl mapping feature (see
question ``dialout_manycards'').
88..55.. mmssnn__mmiinnddiiaalliinn:: HHooww ccaann II mmiinniimmiizzee uussaaggee ooff MMSSNNss ffoorr ddiiggiittaall ddaattaa
ddiiaalliinn??
i4l gives priority to net interfaces. Therefore, you can get away with
only one MSN when you set it up like this:
1. 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).
2. Set up ttyI* for all other users (X.75, async ppp).
3. Set option `secure on'.
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.
88..66.. mmssnn__oonnllyyoonnee:: HHooww ccaann II uussee oonnee MMSSNN ffoorr eevveerryytthhiinngg??
In Germany, this is not much of an issue any more since you can get 10
MSN for free with Deutsche Telekom ( ):
______________________________________________________________________
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cannot exec cu: $!\n";
______________________________________________________________________
It has to be started by inetd, therefore this has to be added to
/etc/services:
______________________________________________________________________
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
______________________________________________________________________
And this has to be added to /etc/inet.conf:
______________________________________________________________________
modemd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/modemd ttyI5
______________________________________________________________________
Instead of modemd you can also use the program mserver, which has some
additional functionality (e.g. rights based on ip address):
DialOut/IP can be found on:
Those who just want to save their CrossPoint installation should be
aware that it now offers tcp modem support, such that it will run
without additional software. Check out:
1100.. ddiiaalloouutt:: CCoonnffiigguurraattiioonn ooff DDiiaall--OOuutt
1100..11.. ddiiaalloouutt__ccoonnffiigg:: HHooww ddoo II ccoonnffiigguurree ddiiaalloouutt pprrooppeerrllyy??
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:
+o Sync PPP: This is what most Internet Service Provider expect from
you. See section ``syncppp''.
+o Async PPP: May also be handled by your Internet Service Provider.
Use when Sync PPP does not work for you. See section ``asyncppp''.
+o Raw IP: Most efficient for TCP/IP over ISDN. It has very quick
dialouts, but is not as common. See section ``rawip''.
+o X.75: This is what you need to dial into an ISDN mailbox. See
section ``ttyI''.
+o Leased line: For this special case, see section ``leased''.
Have a look on section ``dod'' on how to configure dial on demand -
and on the dangers attached to it.
For more advanced dialout features see question ``dialout_advanced''.
Also you may have a look at section ``remote'' when you try to connect
to a special remote ISDN device.
1100..22.. ddiiaalloouutt__ddiiaallmmooddee:: WWhheenn aann IIPP ppaacckkeett sshhoouulldd ggoo oovveerr tthhee lliinnkk
((wwhhiicchh uussuuaallllyy ttrriiggggeerrss aa ddiiaalloouutt)),, aallll II sseeee iinn tthhee lloogg iiss:: ""ddiiaall
rreejjeecctteedd:: iinntteerrffaaccee nnoott iinn ddiiaallmmooddee aauuttoo ""??
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: ``dod''). To
enable autodial for a given interface e.g. ippp0, use
______________________________________________________________________
isdnctrl dialmode ippp0 auto
______________________________________________________________________
The meaning of the values for dialmode is:
ooffff
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.
aauuttoo
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.
mmaannuuaall
(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:
________________________________________________________________
isdnctrl dial ippp0
________________________________________________________________
To end the connection, use:
___________________________________________________________________
isdnctrl hangup ippp0
___________________________________________________________________
Please note that the huptimeout may still end the connection auto-
matically! To ensure that you have to hang up manually, you have to
switch this off:
___________________________________________________________________
isdnctrl huptimeout ippp0 0
___________________________________________________________________
To allow a normal user to initiate a dialout, have a look at question
``dialout_permission''.
1100..33.. ddiiaalloouutt__aaddvvaanncceedd:: WWhhaatt ssppeecciiaall ddiiaalloouutt ffeeaattuurreess aarree aavvaaiillaabbllee??
Check out these special dialout features:
+o Save money by hanging up just before a charge unit: see section
``chargeint''.
+o Dialout on more than 1 channel at the same time: see section
``2channel''.
+o Dialout on one specific channel: see question
``dialout_fixedchannel''.
+o Callback: see section ``callback''.
1100..44.. ddiiaalloouutt__ppeerrmmiissssiioonn:: HHooww ccaann II aallllooww aa nnoorrmmaall uusseerr ttoo iinniittiiaattee
ddiiaalloouuttss??
ISDN usage depends on the permissions to the devices /dev/ttyI* and
/dev/cui*. You have several choices to selectively allow users to do
ISDN transactions.
1. You can establish the group `isdn' in /etc/group, and do:
___________________________________________________________________
chgrp isdn /dev/ttyI* /dev/cui*
chmod o-rw /dev/ttyI* /dev/cui*
___________________________________________________________________
It has been reported that you also may have to change group and per-
missions on the programs ipppd and 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'.
2. 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
/etc/su1.priv. Add these lines if they (or similar ones) are not
yet there, to allow users XXXX and YYYY to initiate
dialups/hangups:
___________________________________________________________________
# 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
___________________________________________________________________
Then create two links for dial and hangup:
______________________________________________________________________
ln -s /usr/bin/su1 /usr/local/bin/dial
ln -s /usr/bin/su1 /usr/local/bin/hangup
______________________________________________________________________
Now the users XXXX and YYYY can dial out by typing dial, and hangup
with hangup.
3. If you only have one user that you use for ISDN interactions, you
can make him owner of the ISDN interface.
1100..55.. ddiiaalloouutt__mmaannyyccaarrddss:: HHooww ddoo II ccoonnffiigguurree ddiiaalloouutt wwiitthh mmoorree tthhaann 11
IISSDDNN ccaarrdd??
There are several possibilities to configure dialout.
+o 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 isdnctrl mapping to configure the
correct MSNs (see item 'dialout on one specific card').
+o Dialout on one specific channel: Use the 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 isdnctrl list that the binding actually
works.
+o Dialout with different MSN on each card: You can configure this by
using the isdnctrl mappping functionality. Just map MSNs on the
letters 0 to 9, like this:
___________________________________________________________________
isdnctrl mapping 111,222,333,,
isdnctrl mapping 999,888,,777
___________________________________________________________________
Now, you could configure for telephone number 0 when you really want
to use MSN 111 on or 999 on (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
or 888 on . Configure to use telephone number 2 when you
really want to use only MSN 333 on ( will
use the default MSN when used). Configure to use telephone number 3
when you really want to use only MSN 777 on ( will use the default MSN when used).
+o 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 isdnctrl mapping
functionality.
___________________________________________________________________
isdnctrl mapping 111,222,333,-,
isdnctrl mapping 999,888,-,777
___________________________________________________________________
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 , while
dialout on 3 will now only dial out with MSN 777 on .
1100..66.. ddiiaalloouutt__ffiixxeeddcchhaannnneell:: HHooww ccaann II ffoorrccee HHiiSSaaxx ttoo aallwwaayyss ddiiaall oouutt
oonn aa ssppeecciiffiicc BB cchhaannnneell??
HiSax has an undocumented feature for this. Add 'P1' in front of the
dialout phone number for the first B channel, or 'P2' for the second B
channel, like this:
______________________________________________________________________
isdnctrl addphone out P1
______________________________________________________________________
This will indicate the preferred B channel in the outgoing SETUP mes-
sage. Please note that some PBX may not like this. Obviously, a
dialout will fail when another device already uses the second B chan-
nel.
1100..77.. ddiiaalloouutt__ddyynniipp:: OOnn ddyynnaammiicc iipp aassssiiggnnmmeenntt,, hhooww ddoo II ffiinndd oouutt
wwhhiicchh iipp aaddddrreessss iiss bbeeiinngg uusseedd ffoorr ddiiaalloouutt??
Create a script called ip-up. It will be called by the ipppd whenever
the connection is established with several parameters. The ip address
is passed in as the fourth parameter (access it as $4).
1100..88.. ddiiaalloouutt__bbiinndd:: AA ddnnss qquueerryy ccaauusseess bbiinndd ttoo ddiiaall oouutt.. WWhhyy ddooeess iitt
ttaakkee aabboouutt aa mmiinnuuttee bbeeffoorree iitt iiss aannsswweerreedd?? HHooww ddoo II wwoorrkk aarroouunndd iitt??
You are probably using the name server in 'forward' mode, and your ISP
works with dynamic ip addresses. The initial UDP query will be lost
since it carries the wrong source address. Unfortunately, bind will
wait a whole minute before retransmitting the query again if you have
only one forwarder.
As a workaround, you can enter 4 times the same forwarder in
named.conf to adjust retransmission timing (in 'forward' mode, bind
retransmits its queries after the following period of time: 60 seconds
divided by the number of nameservers given in the section "forwarders"
of named.conf).
______________________________________________________________________
forwarders { 10.0.0.40; 10.0.0.40; 10.0.0.40; 10.0.0.40; }
______________________________________________________________________
Bind will then retransmit the query every 15 seconds to your forwarder
(here the forwarder is 10.0.0.40). The same principle applies to two
or more forwarders.
Another option are the programs ip_resend and ip_resend_wakeup which
you can find on: [ for more information...)
______________________________________________________________________
Maybe you compiled ipppd with the source of another kernel that you
are not using...
1122..1177.. ssyynnccpppppp__nnoouussaabblleeddeevviiccee:: WWhheenn II ttrryy ttoo ssttaarrtt iippppppdd iitt ssaayyss
""CCaann''tt ffiinndd uussaabbllee iipppppp ddeevviiccee""
This message occurs when the linklevel interface is told to dial out,
but ipppd is not running, or not available.
1122..1188.. ssyynnccpppppp__ssttaarrtteerrrroorr:: WWhheenn II ssttaarrtt iippppppdd,, II oonnllyy ggeett eerrrroorr mmeess--
ssaaggeess ffrroomm tthhee ii44ll ddrriivveerr..
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.
1122..1199.. ssyynnccpppppp__ffrraammeessddeellaayyeedd:: II ggeett tthhee mmeessssaaggee IIPP ffrraammeess ddeellaayyeedd --
bbuutt nnoo ccoonnnneeccttiioonn..
Have you really dialed out? Check question ``dialout_dialmode'' and
your configuration on the different dialmodes.
1122..2200.. ssyynnccpppppp__nnoorroouuttee:: II ccaannnnoott ddiiaall oouutt wwiitthh iissddnnccttrrll ddiiaall iipppppp00 ..
IItt sseeeemmss aass iiff tthhee rroouuttee ttoo iippppppdd iiss mmiissssiinngg aalltthhoouugghh II ddiidd sseett iitt ((
nneettwwoorrkk uunnrreeaacchhaabbllee )).. WWiitthh mmyy oolldd kkeerrnneell 22..00 eevveerryytthhiinngg wwoorrkkss ffiinnee!!
In the newer kernels you have to place route as the very last command
before the dialout command. Otherwise the kernel will delete the
route.
1122..2211.. ssyynnccpppppp__nnooddeeffaauullttrroouuttee:: AAfftteerr iippppppdd ddiiaallss oouutt mmyy ddeeffaauulltt rroouuttee
iiss ggoonnee..
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:
______________________________________________________________________
#!/bin/sh
/sbin/route add default ippp*
______________________________________________________________________
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:
______________________________________________________________________
/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 "\a Usage: 'isdn on' or 'isdn off'"
;;
esac
______________________________________________________________________
Please note, that for 2.2.x kernel, you should NOT use the route add
default, and route del default commands. Instead, give the "default-
route" option to ipppd.
1122..2222.. ssyynnccpppppp__ppaacckkeettttoooollaarrggee:: II oofftteenn ggeett tthhee eerrrroorr mmeessssaaggee
hhssccxx__eemmppttyy__ffiiffoo:: iinnccoommiinngg ppaacckkeett ttoooo llaarrggee
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 "Why should I avoid IRQ 12 and 15 for my
ISDN card?". 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).
1122..2233.. ssyynnccpppppp__ssllooww:: TThhee ccoonnnneeccttiioonn wwiitthh iippppppdd sseeeemmss ttoo wwoorrkk,, bbuutt
eevveennttuuaallllyy iitt ccrraasshheess oorr iiss vveerryy ssllooww..
It could be that some compression is activated (that i4l can't handle
properly). Common error: "-vj" has to be used *additionally* to
"-vjccomp" (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 ``syncppp_compression''). Also giving the option "noccp" can
help.
1122..2244.. ssyynnccpppppp__llooaaddpprroobblleemm:: II oonnllyy hhaavvee pprroobblleemmss wwiitthh iippppppdd wwhheenn tthhee
ccoonnnneeccttiioonn iiss bbeeiinngg hheeaavviillyy bbuurrddeenneedd.. TThheenn eevveerryytthhiinngg ssttooppss.. WWhhaatt
ccoouulldd bbee ccaauussiinngg tthhiiss??
Sven Engelhardt sven@sik.de wrote on 12 Dec 1996:
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 Win-
dows 95 and NT customers who are using the "included" (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 sus-
pect 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 "mtu
576" and "mru 576" in the PPP options. (See also:
])
Erik Corry ec@sign-tronic.dk added on 16 Dec 1996:
For me, neither PPP compression option nor mru/mtu 296
helped. What did help was the AT command: AT&B512 that lim-
its the sent packets to 512 bytes.
1122..2255.. ssyynnccpppppp__mmttuu:: MMyy iippppppdd wwoorrkkss,, bbuutt II kkeeeepp ggeettttiinngg tthhee mmeessssaaggee
ppppppdd((110044)):: iiooccttll((SSIIOOCCSSIIFFMMTTUU)):: IInnvvaalliidd aarrgguummeenntt""??
If mtu is not set, then a default value is assumed - possibly "0"
(which of course cannot be correct). Add "mtu 1024" to your ipppd
options (1500 could also be ok).
1122..2266.. ssyynnccpppppp__11ssttppaacckkeett:: TThhee ffiirrsstt IIPP ppaacckkeett ggeettss lloosstt oonn aauuttoommaattiicc
ddiiaalloouutt wwiitthh ddyynnaammiicc IIPP aaddddrreessss aallllooccaattiioonn..
There are some dialout problems in connection with syncPPP and dynamic
IP address allocation. In this case your IP address will change while
packets are waiting to be sent. All packets that should be sent before
the change in IP address have the wrong response ip address and will
therefore never receive an answer. The problem is that this may cause
multiple dialouts (see section ``dod''). Possible solutions:
+o Dial out manually with "isdnctrl dial ippp*"
+o Use diald to control when the connection goes up or down.
+o Get a permanent IP address
+o A workaround is included in the newest kernels, which can be
activated like this:
___________________________________________________________________
echo 7 > /proc/sys/net/ipv4/ip_dynaddr
___________________________________________________________________
(use 5 instad of 7 to not get warnings into /var/log/messages) If you
have a SuSE distribution, this workaround can also be configured by
setting IP_DYNIP="yes" in /etc/rc.config.
+o Increase the number of retries on your Windows machine for setting
up the connection. Change the registry entry
Hkey_Local_Machine\\System\\CurrentControlSet\\Services\\VxD\\MSTCP\\MaxConnectRetries
from 3 to a larger value (e.g. 5 or 7).
1122..2277.. ssyynnccpppppp__ddrrooppppaacckkeett:: WWhhaatt ddooeess tthhee mmeessssaaggee ""NNoo pphhoonnee nnuummbbeerr,,
ppaacckkeett ddrrooppppeedd"" mmeeaann??
Michael Engert michi@bello.wor.de 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.
1122..2288.. ssyynnccpppppp__lleeaaddiinnggzzeerroo:: WWhhyy ddooeess mmyy iippppppdd ddiiaall oonnee ttoooo mmaannyy zzeerrooss
(( ""iipppppp00:: ddiiaalliinngg 00 008899XXXXXXXXXXXX......"" ))?? II ddoonn''tt hhaavvee aannyy eexxtteennssiioonnss!!
The first zero is not dialed. It only shows the retry counter, which
is related to the isdnctrl dialmax parameter.
1122..2299.. ssyynnccpppppp__eetthhffaakkee:: MMyy IISSDDNN ddeevviiccee iiss sshhoowwnn wwiitthh HHWWaaddddrr aanndd IIRRQQ==00
aanndd bbaassee aaddddrreessss == 00 wwhheenn II lliisstt iitt wwiitthh iiffccoonnffiigg
The ISDN device fakes an Ethernet device. It ignores IRQ and baseaddr
and just needs the HWaddr for the Ethernet encapsulation.
1122..3300.. ssyynnccpppppp__llzzsspprroobblleemm:: II ggeett aann eerrrroorr mmeessssaaggee lliikkee kkeerrnneell cchheecckk
ffoorr llzzss ffaaiilleedd ??
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 noccp as an option for ipppd, or compile and
load the lzs module.
1133.. aassyynnccpppppp:: CCoonnffiigguurraattiioonn AAssyynncc PPPPPP
1133..11.. aassyynnccpppppp__wwhhiicchhpppppp:: ppppppdd,, iippppppdd,, aassyynncc PPPPPP,, ssyynncc PPPPPP -- wwhhaatt aarree
tthheeyy?? WWhhiicchh sshhoouulldd II uussee??
aassyynncc PPPPPP is a character-based protocol which is usually used over
analog serial lines (async = asynchronous). You have to use the
program pppd for it, and use it with the ttyI* devices.
In contrast, SSyynncc PPPPPP is a bit-oriented protocol (sync = synchronous),
for which the original pppd cannot be used. Michael Hipp has written
an adapted version called 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 pppd, this can be an
indication of async PPP.
Usually using ssyynncc PPPPPP works fine, and it is slightly more efficient.
To take advantage of newer features of the pppd, use aassyynncc PPPPPP.
1133..22.. aassyynnccpppppp__ccoonnffiigg:: HHooww ddoo II ccoonnffiigguurree aassyynncc PPPPPP??
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
``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).
1133..33.. aassyynnccpppppp__llooggiinnddeellaayy:: HHooww ccaann II rreedduuccee llooggiinn ddeellaayy??
You can write out a login session with ("Debug-Log"), 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 "How to I create a log for ipppd".
1133..44.. aassyynnccpppppp__ffaasstt:: HHooww ccaann II iinnccrreeaassee mmyy ttrraannssffeerr rraatteess wwiitthh PPPPPP??
You can add more channels with MPPP (see question ``2channel_mppp'').
For everyone for whom that's to expensive and who use _a_s_y_n_c _P_P_P,
there's a little trick. With the option "asyncmap 0" 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%.
1133..55.. aassyynnccpppppp__lloogg:: HHooww ccaann II ggeett aa lloogg ffoorr ppppppdd??
See this question for Sync PPP, it works the same way for pppd.
1133..66.. aassyynnccpppppp__ssuuddddeennddeeaatthh:: EEssttaabblliisshhiinngg tthhee ccoonnnneeccttiioonn wwoorrkkss ffiinnee,,
bbuutt ppppppdd ccrraasshheess jjuusstt aafftteerr tthhaatt ((ii..ee.. tthhee ffiirrsstt bbyytteess ggeettss tthhrroouugghh,,
bbuutt tthheenn eevveerryytthhiinngg ssttooppss))
This is probably due to an incorrect block size on your side.
Initialize your ttyI* device with AT&B512 or even smaller block sizes.
1144.. rraawwiipp:: RRaaww IIPP
1144..11.. rraawwiipp__wwhhaattiiss:: WWhhaatt iiss RRaaww IIPP,, wwhheenn sshhoouulldd II uussee iitt??
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:
+o No handshaking (= faster connections)
+o Authorization by Caller ID (= fast, safe, no password)
+o Fixed IP address (= a broken connection can be continued by
redialing)
+o Higher data transfer rates
+o Better stability (smaller driver = almost no bugs)
Disadvantages:
+o No handshaking => Configuration must occur beforehand (IP
addresses,...) => sensible to use for only for one provider at a
time
+o Authorization only by Caller ID => Dialin only possible from one's
own number
+o Fixed IP address => must be known ahead of time, more IP addresses
required, no dynamic assignment of addresses possible.
From this summary it should be clear under what conditions it makes
sense to use raw IP.
1155.. ttttyyII:: CCoonnffiigguurraattiioonn ooff tthhee ttttyyII** ddeevviicceess ((``MMooddeemm eemmuullaattiioonn''))
1155..11.. ttttyyII__nnoommooddeemm:: DDoonn''tt tthhee ttttyyII** ddeevviicceess eemmuullaattee aann aannaalloogg mmooddeemm??
No! The ttyI* devices just offer a similar communication interface,
where all commands are started with _A_T. This makes it easy to reuse
software that was written to communicate with a modem. CCoommmmuunniiccaattiioonn
wwiitthh aa rreemmoottee aannaalloogg mmooddeemm iiss nnoott ppoossssiibbllee vviiaa tthhee ttttyyII** ddeevviicceess!! The
real communication happens in digital, not analog form.
1155..22.. ttttyyII__ddeevv:: WWhhiicchh ddeevviicceess sshhoouulldd II uussee ffoorr ccaallllss oouutt oorr ccaallllss iinn??
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).
1155..33.. ttttyyII__hhddllcc:: HHooww ttoo II sswwiittcchh tthhee mmooddeemm eemmuullaattiioonn ffrroomm XX..7755 ttoo
HHDDLLCC??
With the option S14=3; for example "ATS14=3".
1155..44.. ttttyyII__uuuuccpp:: HHooww ccaann II ppoollll wwiitthh TTaayylloorr--UUUUCCPP uussiinngg iissddnn44lliinnuuxx??
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 "AT&Emsn/eaz".
1155..55.. ttttyyII__ssppeeeedd:: WWhhaatt ssppeeeedd sshhoouulldd II sseett ffoorr tthhee ttttyyII** ddeevviicceess??
It doesn't matter. The driver internally always uses the full speed
that ISDN offers. This is also given in the connect string.
1155..66.. ttttyyII__mmaaxx:: HHooww mmaannyy ddeevviicceess aarree tthhee mmaaxxiimmuumm ssuuppppoorrtteedd nnuummbbeerr??
The maximum can be set by configuring ISDN_MAX at compile time.
Currently, it is set to 64 by default, which means that up to 64 ttyI
devices are supported.
1155..77.. ttttyyII__nnooccaarrrriieerr:: WWhheenn II ddiiaall wwiitthh ""AATTDD.........."" II aallwwaayyss ggeett aa ""NNOO
CCAARRRRIIEERR""..
Before dialing, you have to enter "AT&E123456" (if 123456 is your own
MSN; with 1TR6 give the one-digit EAZ).
1155..88.. ttttyyII__nnooiinnccaallll:: MMyy ttttyyII** ddeevviiccee//ppppppdd ddooeess nnoott rreeccooggnniizzee aann
iinnccoommiinngg ccaallll..
Probably you did not tell the modem emulation with AT&E which MSN to
use. For example, use AT&E123456; if your MSN is 123456.
Please also note that only one application using the ttyI* devices
will receive a ring for a particular MSN. Which will ring is selected
by a loop over all ttyI* devices. A device is selected based on
whether its parameters match (protocol, MSN) and whether it is
currently not involved with another call. Therefore it does not make
sense for multiple applications to register for the same MSN via the
ttyI* devices, unless you want to have load sharing between the
applications.
1155..99.. ttttyyII__ccaallllpphhoonnee:: WWhhyy ccaann''tt II ddiiaall mmyy tteelleepphhoonnee oorr ffaaxx ffrroomm tthhee
ttttyyII** ddeevviicceess??
You can. However, ISDN differentiates different services. All outgoing
calls with the ttyI* devices use the service "Digital Data", which is
incompatible with telephone or fax, so the call never gets through.
Change the service recognition with the ATS18=1 command to audio, then
you can dial your telephone or fax.
1155..1100.. ttttyyII__nnooccoonnnneecctt:: II ccaann''tt ggeett aa ccoonnnneeccttiioonn ttoo mmyy IISSDDNN mmaaiill--
bbooxx//BBBBSS..
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 AT&. Mostly used is
a block size of 2048 byte: AT&B2048.
1155..1111.. ttttyyII__ffoorrcceehhaanngguupp:: MMyy mmooddeemm eemmuullaattiioonn hhaannggss.. HHooww ccaann II ffoorrccee mmyy
ccaarrdd ttoo hhaanngg uupp??
If there is really no process using your modem emulation any more,
try:
______________________________________________________________________
cu -l /dev/ttyI0 dir
+++
ath0
~.
______________________________________________________________________
Before and after "+++" you have to wait for a second, otherwise the
modem emulation won't recognize it as the escape sequence (like a nor-
mal modem). Watch out for processes that (with "ps -ax") have some-
thing like "I0" or "I1" in the second column, they have an ISDN termi-
nal as their controlling terminal. You may have to kill them with
kill.
1155..1122.. ttttyyII__cchhaannnneellcclloosseedd:: DDuurriinngg aa ttttyy ccoonnnneeccttiioonn,, II ggeett aa mmeessssaaggee
ffrroomm tthhee kkeerrnneell:: ""tteelleess__wwrriitteebbuuff:: cchhaannnneell nnoott ooppeenn"".. TThheenn nnoo mmoorree
iinnppuutt iiss aacccceepptteedd ffoorr tthhiiss ccoonnnneeccttiioonn..
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.
1155..1133.. ttttyyII__xx7755uuuuccpp:: WWhheenn II uussee UUUUCCPP wwiitthh XX..7755,, II aallwwaayyss ggeett ttrraannssffeerr
eerrrroorrss!!
Andreas Gutzwiller andy@hippo.proxyon.imp.com wrote on 5 Dec 1996:
I had to use the following settings, otherwise I only had
errors. # Prot protocol-parameter g packet-size 512 proto-
col-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.
Holger Burbach holly@cthulhu.pfalz.de on 5 Feb 1997 had another solu-
tion:
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 ("AT&B1024") and then set the packet size for the g
protocol in UUCP: protocol-parameter g packet-size 2048 pro-
tocol-parameter g remote-packet-size 0 As I said, it works
fine..
1166.. ddoodd:: UUnnwwaanntteedd ddiiaalloouutt oonn ddeemmaanndd
1166..11.. ddoodd__hhooww:: HHooww ddooeess ddiiaalloouutt oonn ddeemmaanndd wwoorrkk??
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 autodial
mode has been enabled (see question ``dialout_dialmode'' on the
dialmodes) then the interface will automatically trigger a dialout
when it receives ip packages. (This means that aannyy 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 ``dod_disaster''.
1166..22.. ddoodd__ddiissaasstteerr:: WWhhaatt iiss aa cchhaarrggee uunniitt ddiissaasstteerr??
The charge unit disaster can happen for many reasons (see question
``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:
+o "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.
+o "Not so cheap": Some Windows 95 computer in your LAN triggers a
dialout every 15 minutes for one of its silly broadcasts (see
question ``dod_win95''). Makes up 96 dialouts per day, or 2880 per
month.
+o "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.
+o "Expensive": Keep alive packets prevent that your line ever hangs
up. Your line is always on. Note: THIS IS NOT THE WORST CASE!
+o "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.
+o "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!
This is no joke, and all these things have actually happened, even to
real isdn4linux experts! See question ``dod_off'' on how to avoid any
risk of this happening to you.
1166..33.. ddoodd__ccaauusseess:: WWhhaatt ccaann ccaauussee aa cchhaarrggee uunniitt ddiissaasstteerr??
There are many possibilities. See question ``dod_strategy'' on how to
track down what is happening to you. See question ``dod_disaster'' on
how expensive that could be. Here a non-comprehensive list of causes:
1. You compiled your kernel with the option Bridging by mistake.
2. ARP requests or broadcasts? You should run ifconfig with the
options -arp and -broadcast to keep from opening connections in
this way. You can recognize this one when you have a dialout, but
_n_o data is transferred.
3. Other Broadcasts from the interfaces were being forwarded by ISDN.
4. If IP connections are still open with the line is disconnected and
IP addresses are dynamically assigned, then the disaster is
inevitable. Then a new connection is started to bring down the
open IP connections, which fails because the IP address is now
different. The line is hung up, but the IP connections are still
open, the line is dialed again, and so on... This can only be
avoided with the RST-provoking mode (see question
``dod_rstprovoking''. A patch for it may be needed if it is not
included in your distribution. The patch had found its way into the
2.0.x kernels, but not into 2.1/2.2/2.3. However, you can get an
adjusted patch for 2.2.x kernels and some background information
about it from: to
dial out, and isdnctrl hangup to hangup.
2. Set your dialmode properly (see question ``dialout_dialmode''). For
example, set dialmode to manual in ip-down. Then dialouts will only
be possible once after setting dialmode to auto.
3. 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.
4. Switch the system off.
5. Delete your route to the ISDN device. For example, to disable any
automatic dialouts:
___________________________________________________________________
/sbin/route del default
/sbin/isdnctrl system off
/sbin/ifconfig ippp0 down
___________________________________________________________________
To get things running again:
______________________________________________________________________
/sbin/isdnctrl system on
/sbin/ifconfig ippp0 up
/sbin/route add $GATE-IP dev ippp0
/sbin/route add default ippp0
______________________________________________________________________
The latter method has the disadvantage that dialin is then no longer
possible.
1166..55.. ddoodd__ssttrraatteeggyy:: HHooww ccaann II ttrraacckk ddoowwnn uunneexxppllaaiinnaabbllee ddiiaalloouuttss??
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:
+o 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
``dod_winclient''.
+o Try to find out which TCP/IP packet triggers the connection with
"isdnctrl verbose 3". A message should appear in the kernel message
queue (visible with dmesg), like: OPEN: 141.76.60.54 -
193.171.67.253 TCP, port: 1686 - 540 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 /etc/services. Please note:
only the triggering packet will be logged.
+o If you are using ipppd: get a tcpdump which can show data with the
syncPPP encapsulation (this may require a patch - see question
``trouble_tcpdump'').
+o 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
``dod_localdns'', ``dod_sendmail'', ``dod_samba'').
+o If broadcasts are your problem, you can also redirect the broadcast
address to the dummy0 interface. It's not clean, but it works.
1166..66.. ddoodd__wwiinncclliieenntt:: CCaann iitt bbee tthhaatt tthhee WWiinn9955 mmaacchhiinnee oonn mmyy LLAANN iiss
ccaauussiinngg aauuttoommaattiicc ddiiaalloouuttss??
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:
+o Switch off the feature Use DNS for Windows Names Resolution on all
Windows computers on your LAN.
+o Set up a local DNS name server such that it will answer all
requests. See question ``dod_localdns''.
1166..77.. ddoodd__llooccaallddnnss:: II hhaavvee sseett uupp aa llooccaall DDNNSS nnaammee sseerrvveerr.. WWhhyy ddooeess
iitt ccaauussee uunnwwaanntteedd ddiiaalloouuttss?? HHooww ccaann II ffiinndd tthhee ccaauussee??
Turn on debug level 1 in named and look at the logfile in /var/tmp.
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.
1166..88.. ddoodd__ffoorrwwaarrddddnnss:: II hhaavvee sseett uupp mmyy nnaammee sseerrvveerr iinn ''ffoorrwwaarrdd'' mmooddee,,
wwiitthh oonnee ffoorrwwaarrdd aaddddrreessss.. NNooww iitt ddiiaallss oouutt aabboouutt eevveerryy mmiinnuuttee??
From time to time, the name server will query its forwarder, which
will trigger a dialout. Since your ISP uses dynamic ip addresses, the
request is sent out with the wrong ip address at startup of the dial-
in connection. Therefore, no answer will be received. Bind waits for
one minute before resubmitting. If your line has come down in the mean
time, this will trigger a new dialout, resulting in a different ip
address, and so on...
For a workaround to this problem you can shorten the retransmission
time as described in question ``dialout_bind''.
Alternatively, you can set the option "dialup yes;" in the options
block of named.conf. This will cause named to do only one interaction
with a forwarder (triggering a dod) at startup. After that it will
wait for some very long interval (24h?) before another query with the
forwarder. Only during actual lookup it will do negotiations with the
forwarder (this is usually when you have already dialed out anyway).
1166..99.. ddoodd__sseennddmmaaiill:: HHooww ccaann II ggeett sseennddmmaaiill ttoo nnoott iinniittiiaattee aannyy ccoonn--
nneeccttiioonnss wwiitthhoouutt llooccaall mmaaiill bbeeiinngg lleefftt uunnddeelliivveerreedd??
First you have to get sendmail to no long open any DNS connections.
You need to activate the following features: "nodns", "nocanonify".
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
"order hosts bind")
You should set all non-local mailers as "expensive"
("define(SMTP_MAILER_FLAGS, e)"), and then forbid sendmail with
"define(`confCON_EXPENSIVE', `True')" from automatically connection to
expensive mailers. The call to sendmail should no longer include a
time for the "-q" option (e.g. only "-bd -os -q"). "-os" 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
"sendmail -q".
1166..1100.. ddoodd__ssaammbbaa:: TThhee ssaammbbaa ppaacckkaaggee aallwwaayyss ttrriiggggeerrss ddiiaalloouuttss ffoorr mmee..
HHooww ccaann II pprreevveenntt tthhiiss??
When nmbd starts up it tries to bind to 0.0.0.0 or all interfaces,
which is what triggers the ISDN dialup. The best way to solve this is
to set "bind interfaces only = yes" and "interfaces = eth0" in
smb.conf (in case you want to use Samba only in your LAN).
Alternatively, you can give the samba daemon an internal ip address
upon startup. First find out which ip address samba is trying to
connect to (e.g. with netstat or tcpdump). Then start samba with:
______________________________________________________________________
nmdb -S -B 192.168.99.255 -I 192.168.99.99
______________________________________________________________________
if your Linux computer has 192.168.99.99 as ip address, and all users
are in the same subnet (192.168.99.255).
See also the above question: set -broadcast and possibly -arp when
defining the interfaces!
Check out the help pages for the Samba configuration file for further
possibilities on preventing dialout (I was told there should be some
explicit dialup parameter which prevents it to cause many dialouts).
1166..1111.. ddoodd__nneettssccaappee:: HHooww ccaann II ggeett NNeettssccaappee ttoo qquuiitt iinniittiiaattiinngg
ddiiaalloouuttss wwhheenn ssttaarrttiinngg??
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.
"file://localhost/xxx") won't cause an immediate dialout.
Alternatively you can also set up a cache daemon that saves pages that
are often needed.
Second check your proxy settings. When giving a complete name instead
of an ip address, Netscape may try to do a DNS lookup to resolve the
name to an ip address on startup. In this case provide Netscape with
an ip address.
Another thing is that Netscape tries to contact its news server. If
you don't want to use this feature then you can enter the name
Netscape uses for lookup (probably 'news') in your local DNS or in
your /etc/hosts, and let it point to localhost.
1166..1122.. ddoodd__rrssttpprroovvookkiinngg:: WWhhyy sshhoouulldd II uussee tthhee RRSSTT--pprroovvookkiinngg
mmooddee//ppaattcchh??
If on every dialup (in auto dialout mode) you get a different ip
address (dynamic ip), and the dialup connection gets terminated (e.g
due to inactivity) while some ip connections have not yet been closed,
then the following problem will occur: when the program tries to close
the connection this will trigger a new dialout. Since this will yield
in a new ip address, the closing attempt will fail. After the timeout
period another dialout will be attempted, with the same result,
leading to a dial on demand disaster. To prevent this problem the
RST-provoking mode has been invented. If on the closing attempt a new
dialout is opened and the ip address changes, then the kernel will
send a ip packet with the reset flag on. This will close down the open
connection, preventing the dial on demand disaster. To activate the
RST-provoking mode use the command
______________________________________________________________________
echo 7 > /proc/sys/net/ipv4/ip_dynaddr
______________________________________________________________________
Use 5 instead of 7 to prevent syslog warnings. Check the current sta-
tus with:
______________________________________________________________________
cat /proc/sys/net/ipv4/ip_dynaddr
______________________________________________________________________
Your distribution may or may not have the patch for this rst-provoking
mode included, it was not liked in the kernel code for kernels newer
than 2.0.x.
1166..1133.. ddoodd__cclloosseeiippccoonnnneecctt:: AAfftteerr cclloossiinngg tthhee lliinnee,, II ddiissccoovveerr wwiitthh
nneettssttaatt --nntt tthhaatt IIPP ccoonnnneeccttiioonnss aarree ssttiillll ooppeenn.. HHooww ccaann II cclloossee tthheessee
mmaannuuaallllyy??
This may only work with the RST-provoking mode (mentioned in question
``dod_causes''): You can bring the interface "down" then back "up".
When you do this, it will try to dial out. But if you have removed the
outgoing telephone number, then "no outgoing number..." appears in the
syslog, and as soon as the interface is "up", all connections will be
closed.
You can prevent those open IP connections to trigger new dialouts if
you add a special firewall rule in /etc/ppp/ip-down, and remove it in
/etc/ppp/ip-up. This firewall rule drops all tcp packets which are not
in SYNSENT state. Add this in /etc/ppp/ip-down for a 2.2.x kernel:
______________________________________________________________________
ipchains -A output -j DENY -p tcp -i ! -y
______________________________________________________________________
Add this in /etc/ppp/ip-up:
______________________________________________________________________
ipchains -A output -j DENY -p tcp -i ! -y
______________________________________________________________________
(As is the case for all firewall rules: it is best to put this into a
separate script which is called with either a start or a stop parame-
ter.) Please note that this firewall rule only matches whole packets,
no fragments. A fragment will always bypass the firewall and trigger
a dialout.
1166..1144.. ddoodd__oonnlliinneeoonnccrraasshh:: IIss iitt ppoossssiibbllee tthhaatt eevveenn wwiitthh aa ccrraasshheedd
ccoommppuutteerr aa IISSDDNN ccoonnnneeccttiioonn rreemmaaiinnss ooppeenn ((aanndd tthhee cchhaarrggee uunniittss aaccccuummuu--
llaattee))??
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.
1177.. cchhaarrggeeiinntt:: CChhaarrggeeiinntt
1177..11.. cchhaarrggeeiinntt__wwhhaattiiss:: WWhhaatt ddooeess CChhaarrggeeiinntt??
Chargeint is a way to reduce your costs when you have charges based on
your ttiimmee oonnlliinnee, 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.
1177..22.. cchhaarrggeeiinntt__ccoonnffiigg:: HHooww sshhoouulldd II ccoonnffiigguurree CChhaarrggeeiinntt??
You can set the length of a charge unit manually via the isdnctrl
parameter chargeset, or set up isdnlog to do this automatically for
you:
1. Set up isdnlog, so that it has all the information about your
location and your telephone company (so that it knows your rates).
2. Start isdnlog with the options -h0 and -w.
3. Set your huptimeout as you like (idle time needed before i4l will
consider a hangup). E.g.:
___________________________________________________________________
/sbin/isdnctrl huptimeout ippp0 5
___________________________________________________________________
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.
1177..33.. cchhaarrggeeiinntt__wwhheennnnoott:: WWhheenn ddooeess iitt nnoott mmaakkee sseennssee ttoo uussee tthhee
cchhaarrggeeiinntt??
1. It does not make sense to use Chargeint when you are charged ppeerr
ddaattaa vvoolluummee, or per ffllaatt ffeeee. Chargeint can only reduce your costs
when you are charged ppeerr ttiimmee oonnlliinnee.
2. Also it makes no sense if you are charged in small units (e.g. per
second rather than per minute).
3. 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).
4. 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.
1177..44.. cchhaarrggeeiinntt__ccoorrrreeccttttiimmee:: HHooww ccaann II bbee ssuurree tthhaatt tthhee cchhaarrggeeiinntt
ppaattcchh iiss uussiinngg tthhee ccoorrrreecctt ttiimmee??
It's best to synchronize the clock in your own computer with that of
the switching station by calling isdnlog with option -t2.
1177..55.. cchhaarrggeeiinntt__nnoohhaanngguupp:: TThhee ccoonnnneeccttiioonn ddooeessnn''tt eenndd wwiitthh ttiimmeeoouutt..
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 "keep alive" packets every ten seconds. If the Cisco doesn't get an
answer for its keep alive packets then it will stop routing. This
normally happens after the 4. or 5. keep alive packet. Very recently
(begin of 2001), support for Cisco's keep alive packages has been
corrected, so you can either use it, or tell the provider not to use
keep alive packets ("no keepalive" 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
"snapshot server" on the BRI interface. That means it will send out
routing updates only when they are received through this interface.
However, nowadays the most likely cause for open connection is that
connection requests looking for a backdoor or a file sharing
application cause issues like this. You can use the active-filter
option of ipppd to indicate which packets should be regarded as link
activity. See the man page for more details. A configuration could be
like this:
______________________________________________________________________
active-filter 'outbound and not icmp[0] == 3 and not tcp[13] & 4 != 0'
______________________________________________________________________
1188.. 22cchhaannnneell:: CChhaannnneell bbuunnddlliinngg ((MMPPPPPP,, rraaww bbuunnddlliinngg))
1188..11.. 22cchhaannnneell__wwhhaattiiss:: WWhhaatt iiss cchhaannnneell bbuunnddlliinngg aanndd hhooww ccaann II uussee iitt??
Channel bundling is currently supported by isdn4Linux in two
variations:
+o RRaaww BBuunnddlliinngg (configuration of so-called slave channels)
+o MMPPPPPP (based on syncPPP)
Both variations have their own advantages and disadvantages. See
the following questions. Dynamic adjustment is supported for MPPP
by the program ibod - see question ``2channel_mpppconfig'' for more
details.
1188..22.. 22cchhaannnneell__rraaww:: WWhhaatt iiss rraaww bbuunnddlliinngg??
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.
1188..33.. 22cchhaannnneell__rraawwccoonnffiigg:: HHooww ddoo II ccoonnffiigguurree rraaww bbuunnddlliinngg??
The master interface is created as usual with
______________________________________________________________________
isdnctrl addif master interface
______________________________________________________________________
and configured. For all required slave channels, slave interfaces are
created with the command:
______________________________________________________________________
isdnctrl addslave master interface slave interface
______________________________________________________________________
and configured as usual (e.g. "isdnctrl sdelay slave interface
delay").
1188..44.. 22cchhaannnneell__rraawwggooooddbbaadd:: WWhhaatt aarree tthhee aaddvvaannttaaggeess aanndd ddiissaaddvvaannttaaggeess
ooff rraaww bbuunnddlliinngg??
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.
1188..55.. 22cchhaannnneell__mmpppppp:: WWhhaatt iiss MMPPPPPP??
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.
1188..66.. 22cchhaannnneell__mmppppppggooooddbbaadd:: WWhhaatt aarree tthhee aaddvvaannttaaggeess aanndd ddiissaaddvvaannttaaggeess
ooff MMPPPPPP??
A disadvantage is that the slave channel has to be activated
"manually". 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).
1188..77.. 22cchhaannnneell__mmppppppccoonnffiigg:: HHooww ddoo II ccoonnffiigguurree MMPPPPPP??
First ensure that support for MPPP has been switched on for
compilation of your ISDN modules. Then define a (normal) interface for
ipppd (e.g. "isdnctrl addif ippp0", etc). This interface will be used
as your master interface. Then you must configure a slave device for
every additional channel (e.g. "isdnctrl addslave ippp0
", configure slave_interface, etc - see the i4l
manual for more). To enable MPPP negotiation, ipppd must be called
with the "+mp" option and both devices have to be given to ipppd.
Please note that the name of both devices has to start with "ippp".
To use channel bundling you must first activate the 'master' or
initial call. Now you can add the slave channels with the command:
______________________________________________________________________
isdnctrl addlink device
______________________________________________________________________
and close them with the command:
______________________________________________________________________
isdnctrl removelink device
______________________________________________________________________
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 auto for
this to work. For manual control, use
______________________________________________________________________
isdnctrl dial slave
______________________________________________________________________
and
______________________________________________________________________
isdnctrl hangup slave
______________________________________________________________________
When using manual control please ensure that the slave device is shut
down before the master device. Currently (August 2002) there is a
hard-to-fix bug in the MPPP code which will cause a crash on the next
dialout. A patch exists which cures the symptoms to prevent the crash
(see mailing list). However, since the dialout will fail in any case
it is best to avoid this situation altogether by using the proper
shutdown sequence.
With syncPPP, there is no automatic activation of slave devices, they
have to be added and removed. However, there is the program ibod
available, which can do this automatically. Have a look at:
or (for a version extended by
Karsten Keil): set the Leo as the modem and configure
FreePPP as usual. Then PAP/CHAP can be set.
1199..44.. rreemmoottee__cciissccoo:: HHooww ddooeess iissddnn44lliinnuuxx wwoorrkk wwiitthh aa CCiissccoo ((HHDDLLCC)) oonn
tthhee ootthheerr ssiiddee??
On the Cisco router the "keep alive" packets have to be turned off.
isdn4linux has to be configured with HDLC, transparent, with Cisco
encapsulation:
______________________________________________________________________
isdnctrl l2_prot hdlc
isdnctrl l3_prot trans
isdnctrl encap cisco-h
______________________________________________________________________
1199..55.. rreemmoottee__iissppaa:: WWhhaatt sseettttiinnggss ddooeess IISSPPAA eettcc.. ((DDOOSS,, WWiinnddoowwss)) nneeeedd
ttoo wwoorrkk wwiitthh tthhee ssttaannddaarrdd sseettttiinnggss ooff iissddnn44lliinnuuxx??
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
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 /
----------------------------------------------------
The parameter with the least problems is -h0.
2200.. lleeaasseedd:: LLeeaasseedd lliinneess
2200..11.. lleeaasseedd__ffllaattrraattee:: WWhhaatt''ss tthhee ddiiffffeerreennccee bbeettwweeeenn aa lleeaasseedd lliinnee
aanndd aa ffllaatt rraattee??
A leased line requires a special setup of your S0 interface. After
that, you can not reach any other destination than the one the leased
line is set up for. It's also rather expensive.
A flat rate is still a normal dialup, therefore the setup should be
done like any dialup connection. The only difference from a normal
dialup is the pricing. See section ``dialout''. Also please note that
the connection on a flat rate will usually be stopped by your internet
provider if you stay on for too long - so you can not rely on being
online all the time, if this is what you desire.
2200..22.. lleeaasseedd__nnoossiiggnnaall:: HHooww ddooeess eessttaabblliisshhiinngg aanndd eennddiinngg aa ccoonnnneeccttiioonn
wwoorrkk wwiitthh DD6644SS wwiitthhoouutt ssiiggnnaalliinngg??
The data is simply sent out! Other than a ping, there is no way to
find out whether the D64S or 2MB line is up or not. Only S01 or S02
lines have a D channel and have something to use with signaling,
however the best known solutions also use this 16kb for data transfers
to get 144kb instead of 128kb (i4l can only to 128kb).
2200..33.. lleeaasseedd__hhiissaaxxccoonnffiigg:: WWiitthh ii44ll,, hhooww ddoo II ccoonnffiigguurree mmyy ccaarrdd oonn aa
DD6644 lleeaasseedd lliinnee??
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:
______________________________________________________________________
/sbin/hisaxctrl HiSax 5
______________________________________________________________________
in case HiSax was loaded with "id=HiSax", where can be 0 or
1. Additionally to the normal configuration, the following commands
are important:
______________________________________________________________________
/sbin/isdnctrl bind HiSax,/sbin/isdnctrl eaz isdn0 1
/sbin/isdnctrl addphone isdn0 out 2
/sbin/isdnctrl addphone isdn0 in 3
______________________________________________________________________
if "isdn0" was used as interface name. The interface has to be set to
"up" and a route associated with it. See the Readme's in the HiSax
package.
2200..44.. lleeaasseedd__xx7755:: HHooww ddoo II ccoonnffiigguurree XX..7755 oonn aa DD6644 lleeaasseedd lliinnee??
Use a later HiSax version. First initialize the ttyI* device you want
to use with "AT&E0" (set usage of first B-channel) and "ATS0=1"
(autoanswer on first ring). Then set HiSax in leased mode:
______________________________________________________________________
/sbin/hisaxctrl HiSax 5
______________________________________________________________________
This will simulate a call for MSN1 on the configured channel (0 or 1)
(incoming number = LEASED0).
2200..55.. lleeaasseedd__sspplliittlliinnee:: WWiitthh ii44ll,, ccaann II uussee oonnee cchhaannnneell aass aa lleeaasseedd
lliinnee aanndd tthhee ootthheerr aass aa ddiiaalluupp lliinnee??
Yes and no. You can configure HiSax for both at the same time, however
you can only use one of them at any point in time (you have to switch
off the leased line before dialing out). It may work occasionally
simultaneously, however the driver has not been written for it so the
results are not deterministic. Also make sure that you use the
correct channel.
2211.. ddiiaalliinn:: CCoonnffiigguurraattiioonn ooff aa DDiiaall--IInn SSeerrvveerr
2211..11.. ddiiaalliinn__ccoonnffiigg:: HHooww ccaann II eennaabbllee ootthheerrss ttoo llooggiinn vviiaa IISSDDNN??
Some configuration examples can be found at: . If you have trouble setting it up,
try to obtain the latest packages for isdn4linux (see question
``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.
+o Set up networking devices for dialin via syncppp, or rawip. Set
option secure off to allow everybody to dial in, or set option
secure on to only allow dialin by the isdn numbers you configure,
which you set up with isdnctrl addphone in .
It has been reported that you need to set option ms-dns for ipppd
to have successful IPCP negotion.
+o Use the ttyI* devices for asyncppp or X.75.
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:
___________________________________________________________________
I0:56:respawn:/usr/local/sbin/mgetty ttyI0
I1:56:respawn:/usr/local/sbin/mgetty ttyI1
___________________________________________________________________
The init string needs to be entered in the mgetty.config, since mgetty
needs to know which MSN or EAZ to listen to. For example, if your MSN
is 123456:
______________________________________________________________________
port ttyI0
modem-type data
speed 38400
init-chat "" ATZ OK AT&E123456 OK AT&B512 OK
______________________________________________________________________
For X.75 the block size was set to 512 bytes. Alternatively you can
enter the entire configuration onto a single line in /etc/inittab
(here printed on two lines!):
______________________________________________________________________
i0:45:respawn:/sbin/mgetty -D -m '"" ATZ OK AT&E123456 OK
AT&B512 OK' -s 38400 ttyI0
______________________________________________________________________
The most elegant way is to use iprofd. This daemon takes advantage of
the AT&W0 command in the i4l modem emulation. You start iprofd with a
path as parameter, e.g. "iprofd /etc/i4lprofile" Then with minicom or
another terminal program, open an ISDN tty device and enter the neces-
sary AT command by hand. When finished, enter the command AT&W0, 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 ATZ.
2211..22.. ddiiaalliinn__mmaannyyppaarraalllleell:: HHooww ccaann II aallllooww sseevveerraall ppeeooppllee ttoo ccaallll iinn
ttoo mmee aatt tthhee ssaammee ttiimmee??
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.
2211..33.. ddiiaalliinn__mmaannyyccaarrddss:: WWhheenn uussiinngg sseevveerraall IISSDDNN ccaarrddss,, hhooww ccaann II
rreeaacctt uuppoonn oonn aa ccaallll rreecceeiivveedd vviiaa aa ssppeecciiffiicc IISSDDNN ccaarrdd??
You can use the EAZ mapping feature for this to map incoming MSN
numbers to new internal MSN numbers, in the same way as described for
question ``dialout_manycards''. Usage of a card can be prevented by
using the dash during the mapping. Please note that it is not possible
to have any limitations based upon the B channel, since channel
assignment is normally done by the exchange.
2211..44.. ddiiaalliinn__aannaallooggddiittaallssaammeettttyyii:: CCaann II ccoonnffiigguurree aa ttttyyII** ddeevviiccee ttoo
aacccceepptt bbootthh ddiiggiittaall aanndd aannaalloogg mmooddeemm ddiiaalliinnss??
Since the digital mode requires different register settings than the
analog mode, this is not possible. Therefore you have to set up a two
dedicated devices for this purpose. Please note that analog modem
dialins are only possible if card and isdn4linux driver support it,
which is only the case for a few cards.
2211..55.. ddiiaalliinn__ffiixxeeddiipp:: HHooww ccaann II aassssiiggnn ffiixxeedd iipp aaddddrreesssseess ppeerr uusseerr
wwhhoo ddiiaallss iinn vviiaa iippppppdd??
Just specify the fixed ip address with the user name and password in
the pap/chap-secrets file (see man ipppd).
2211..66.. ddiiaalliinn__hhddllcc:: SSoommeeoonnee wwoouulldd lliikkee ttoo ddiiaall iinn ttoo mmyy mmggeettttyy wwiitthh
HHDDLLCC.. IIss ttttyyII11 ccoorrrreecctt,, oorr ddoo II hhaavvee ttoo ssttaarrtt wwiitthh ttttyyII00??
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).
2211..77.. ddiiaalliinn__aauuttoopppppp:: IIss iitt ppoossssiibbllee wwiitthh mmggeettttyy ttoo aauuttoommaattiiccaallllyy
ssttaarrtt ppppppdd wwhheenn LLCCPP ffrraammeess aarree rreecceeiivveedd??
Yes, it is. This feature is called `AutoPPP'. See the configuration
for mgetty.
2211..88.. ddiiaalliinn__ppaasssswwdd:: HHooww ccaann II hhaavvee ((ii))ppppppdd cchheecckk ppaasssswwoorrddss ffrroomm
//eettcc//ppaasssswwdd iinnsstteeaadd ooff //eettcc//pppppp//ppaapp--sseeccrreettss wwhheenn ssoommeeoonnee ddiiaallss iinn??
ipppd needs to be started with the options "login" and "auth". In
/etc/ppp/pap-secrets, each user must have the following line to allow
only certain users:
______________________________________________________________________
login-name * "" *
______________________________________________________________________
To allow all users simply:
______________________________________________________________________
* * "" *
______________________________________________________________________
The latter can also be achieved when the file pap-secrets does not
exist.
2211..99.. ddiiaalliinn__iiggnnoorreedd:: II kkeeeepp ggeettttiinngg tthhee mmeessssaaggee ""iissddnn__ttttyy:: ccaallll ffrroomm
XXXXXX -- YYYYYY iiggnnoorreedd"".. WWhhyy ddooeess iissddnn44lliinnuuxx ((ssyynnccPPPPPP)) iiggnnoorree tthhiiss ddiiaalliinn
aatttteemmpptt??
There are two possible explanations. Either your own MSN (here: YYY)
is not correctly set with "isdnctrl eaz interface YYY". Or "isdnctrl
secure interface on" was set, without allowing calls from the incoming
number (here: XXX) with "isdnctrl addphone interface in XXX".
2211..1100.. ddiiaalliinn__aassyynncc:: AA SSuunnIISSDDNN ttrriieess ttoo ddiiaall iinnttoo mmyy ii44ll ssyysstteemm..
The Sun tries to communicate with asyncPPP. ipppd can't handle this,
you have to use the ttyI* devices and the standard pppd.
2222.. ccaallllbbaacckk:: CCaallllbbaacckk
2222..11.. ccaallllbbaacckk__ddeellaayy:: AAnn iinnccoommiinngg ccaallll iiss rreejjeecctteedd bbyy ii44ll.. ii44ll tthheenn
ccaallllss bbaacckk.. TThhee rreejjeecctt iiss nnoott rreeccooggnniizzeedd bbyy tthhee ootthheerr ssiiddee wwhhiicchh kkeeeeppss
oonn ddiiaalliinngg ttoo ii44ll..
Most problems with callback can be solved by adjusting the callback
delay with isdnctrl cbdelay. One second on the triggering side A (set
callback mode to out) and two seconds on the triggered side B (set
callback mode to in) has been successful in most cases.
The reason for the problem is a design bug in the link level driver.
A calls B to trigger a callback. B rejects the call and calls back to
A, establishing a working connection within less than 4 seconds.
However, the triggering call from A to B will need 4 seconds to be
terminated by the ISDN provider (giving other devices on B's side a
chance to take the call). When it is finally terminated, the working
connection from B to A is unfortunately also terminated.
2222..22.. ccaallllbbaacckk__cciissccoo:: SSoommeehhooww ii44ll ccaann nnoott ccaallllbbaacckk aa CCiissccoo??
Torsten Hentschel Torsten.Hentschel@DInet.de wrote on 3 Oct 1996:
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 "dial on demand" 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
"ping RemoteIP" 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
"callback client" = i4l dials back) that the other side
unhooks the line, then both hang up and then comes the call-
back. 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).
Torsten Hentschel Torsten.Hentschel@DInet.de additionally wrote on 20.
Nov 1996:
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 nego-
tiotion 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 inter-
face.
2222..33.. ccaallllbbaacckk__aasscceenndd:: CCaallllbbaacckk ffrroomm aann AAsscceenndd wwoorrkkss oonnllyy wwhheenn II sseett
""AAccttiivvee==YYeess"" iinn tthhee AAsscceenndd mmeennuu;; bbuutt tthheenn tthhee AAsscceenndd kkeeeeppss ccaalllliinngg mmee,,
eevveenn wwhheenn mmyy mmaacchhiinnee iiss ooffff..
Ulrich Klein ulik@hprc.tandem.com wrote on 14 Dec 1996:
Somewhere in the Ascend menus you can set "dial broadcast" to "no" or
"off". 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.
2222..44.. ccaallllbbaacckk__bbaannzzaaii:: HHooww ccaann II ccaallllbbaacckk aa BBaannzzaaii!!??
Jan-Olaf Droese jano@layla.RoBIN.de 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:
______________________________________________________________________
isdnctrl callback isdn0 in
isdnctrl cbdelay isdn0 1
______________________________________________________________________
2222..55.. ccaallllbbaacckk__mmiiccrroossoofftt:: DDooeess iissddnn44lliinnuuxx ssuuppppoorrtt MMiiccrroossoofftt CCaallllbbaacckk
((CCBBCCPP))??
Yes, this is implemented in ipppd. To enable it you have to set the
parameter "callback 6" as an ipppd option on the client side for an
admin managed callback. This means the server will call back on the
number it has been configured for. More interesting is a user managed
callback, since the number to be called back can be provided by the
user. Set the paramter "callback 123456" if you want to be dialed back
on number 123456. To start the callback trigger it from the client
via:
______________________________________________________________________
isdnctrl cbdelay 5
isdnctrl callback out
______________________________________________________________________
Please remember that using the CBCP callback always requires both par-
ties to connect and exchange data, so telephone charges will be
incurred. Please note that the man page may be confusing about the
callback parameter for ipppd. Please note these hints from
NOTES.IPPPD:
- 'callback type[,message]' enables the callback feature
also UNTESTED!
ie: 'callback 0' -> simple callback (info via auth. etc.)
'callback 3,12346' -> us E.164 (tel) number 123456 for callback
'callback 6' is different. This value means, that the whole negotiation
is done with a seperate protocol after the authentification phase. Currently
it's not possible to set any options in this case. The ipppd accepts
everything from the remote side.
The server side is not tested so far - please let me know if you have
some feedback on using CBCP as a server).
If you have a Red Hat distribution, setting the following parameters
in ifcfg-ippp0 might do the trick for an admin managed callback:
______________________________________________________________________
CALLBACK=out
CBDELAY=5
CBCP=on
______________________________________________________________________
For user managed callback please follow the hints on:
.
2233.. iissddnnlloogg:: IIssddnnlloogg
2233..11.. iissddnnlloogg__rraatteess:: WWhheerree ddoo II ggeett tthhee llaatteesstt rraattee iinnffoorrmmaattiioonn??
This is the homepage of the rate data crew:
. 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:
rates4linux-users-request@lists.sourceforge.net (send "help" in your
subject to get instructions). To write to the mailing list, send an
email to: rates4linux-users@lists.sourceforge.net.
2233..22.. iissddnnlloogg__sseerrvviicceettyyppee:: CCaann II sseeee tthhee sseerrvviiccee ttyyppee ffrroomm aann iinnccoomm--
iinngg ccaallll iinn tthhee oouuttppuutt ffrroomm iissddnnrreepp??
Andreas Kool akool@Kool.f.EUnet.de wrote on 3 Dec 1996:
Indirectly in isdnrep, yes -- as soon as you enter an alias for the
decoded service types in your "isdnlog.conf" ...
2233..33.. iissddnnlloogg__ccaalllleerriidd11:: WWhhyy ddoonn''tt II aallwwaayyss rreecceeiivvee ffrroomm tthhee GGeerrmmaann
TTeelleekkoomm tthhee nnuummbbeerr ooff aa ccaalllleerr ((""CCaalllleerr IIDD""))??
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
_v_e_r_y 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.
2233..44.. iissddnnlloogg__ccaalllleerriidd22:: DDoo II rreecceeiivvee tthhee CCaalllleerr IIDD ffrroomm ffoorreeiiggnn
ccaallllss ((GGeerrmmaann TTeelleekkoomm))??
Yes, with calls from countries that don't view Caller ID quite as
strictly as does Germany (e.g. USA, Canada).
2233..55.. iissddnnlloogg__ssppooooffccaalllleerriidd:: II''vvee hheeaarrdd tthhaatt aaccttuuaallllyy ttwwoo CCaalllleerr IIDDss
aarree ttrraannssmmiitttteedd??
That's right, there's one that is "User-Provided, not screened", and
the other is "Network-Provided" (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 "CLIP no screening".
2233..66.. iissddnnlloogg__bbeetttteerrllooggggiinngg:: WWhhyy ddooeessnn''tt iissddnnlloogg rreeccoorrdd tthhee nnuummbbeerr
ddiiaalleedd bbyy mmyy ootthheerr IISSDDNN ddeevviicceess,, ssiinnccee iitt rreeccoorrddss tthhee cchhaarrggeess??
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 keil@isdn4linux.de wrote on
12 Feb 1997:
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.
See the next questions for a possible solution.
2233..77.. iissddnnlloogg__rreevveerrsseeddccaarrdd:: HHooww ccaann II ggeett iissddnnlloogg ttoo aallssoo sshhooww tthhee
tteelleepphhoonnee nnuummbbeerrss ffoorr ootthheerr IISSDDNN ddeevviicceess??
There are several possibilities.
+o COLP: First, the German Telekom offers the service COLP (Connected
Line Identification Presentation, ca. DM 10 per month per basic
line) that returns all data sent. This can then be read by isdnlog
(=2.52) from the TX line.
+o Reversed card/dual mode: Alternatively, isdnlog offers the
possibility to work with a second "re-poled" ISDN card. "re-poled"
means that the RX line is connected to the TX connection of the
card; the RX line of the card should not be connected to any line!
(even if other documents might tell you something else). Because
of this setup, this ISDN card cannot be used for anything else.
This is called a reversed card, or the dual mode. The whole thing
looks something like this:
3 -- RX+ 2a ---------------\
ISDN 4 -- TX+ 1a -- open ------------ ISDN
bus 5 -- TX- 1b -- open ------------ card
6 -- RX- 2b ---------------/
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 spe-
cial bug/feature of that chip. All other cards, like IPAC based cards
(e.g. ELSA QS1000pro) will not work in the role of a re-poled card.
Please note that this will only work on the standard BRI interface,
since for the more expensive PRI interface no card is available which
can be used (PRI is a point-to-point connection anyway).
+o HFC cards: some HFC-PCI based cards allow a special feature where
one of the B channels can be sacrificed in exchange for reading the
complete D channel protocol - with just one single card. This is
also supported by isdn4linux. Set the HFC card in the following
way:
___________________________________________________________________
hisaxctrl 1 4
hisaxctrl 10 1
hisaxctrl 12 1
___________________________________________________________________
You have to give isdnlog the command line option '-1' so that it makes
use of the HFC option.
Please note that a plain HFC-S does not work for hardware reasons, it
has to be a newer one. If your card works with Hisax type 35 or 37,
then it should work.
Please also note that there is no known card for logging on a PRI
interface in this way (also, the PRI interface is point-to-point,
therefore only one device can be connected).
+o PBX: A third (theoretical) possibility exists for those who have
their own PBX to which the other devices are connected. If the PBX
can protocol all outgoing calls, this can be read (usually over a
serial port). There is a reason why isdnlog has not support for
this until now. To evaluate this data, isdnlog has to be able to
access the date immediately after the RELEASE COMPLETE, before any
new data is sent on the D channel. The PBXs tested up to now have
all been too slow (in particular the widely used ISTEC). The only
possibility is to combine the data afterwards. But then there are
problems with synchronizing the different times. Whoever want to
attempt to do this is welcome (I'll make the logs from my Ackermann
Euracom available - Matthias Hessler hessler@wi-inf.uni-essen.de).
2233..88.. iissddnnlloogg__rraatteeggrraapphhiicc:: HHooww ccaann II ddiissppllaayy tthhee ddaattaa ttrraannssffeerr rraatteess
ggrraapphhiiccaallllyy??
You can use "xisdnload". Clemens Perz listperz@gwsnet.ttt.de 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:
Simply start with netload isdnxx.
2233..99.. iissddnnlloogg__22ccaalllleerriidd:: IIssddnnlloogg ((==22..5522)) sshhoowwss ffoorr aa ccaalllleerr ttwwoo
tteelleepphhoonnee nnuummbbeerrss!! WWhhiicchh oonnee iiss ccoorrrreecctt??
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 "I've heard
that actually two Caller IDs are transmitted?".
Andreas Kool akool@Kool.f.EUnet.de 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.
2233..1100.. iissddnnlloogg__ssoouunnddbbuussyy:: II''vvee sseett uupp aa ssccrriipptt ttoo ppllaayy ssoouunndd ppeerr ccaatt
oonn //ddeevv//ssoouunndd oorr ssoommee ootthheerr ddeevviiccee.. WWhheenn sseevveerraall eevveennttss ooccccuurr,, tthheenn
tthheerree iiss aann eerrrroorr:: CCaann''tt ooppeenn oouuttppuutt ffiillee ''//ddeevv//ssoouunndd'':: DDeevviiccee oorr
rreessoouurrccee bbuussyy
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.
2233..1111.. iissddnnlloogg__nnoosshheellll:: IIssddnnlloogg sshhoouulldd ccaallll aa pprrooggrraamm wwiitthh rreeddiirreecctteedd
oouuttppuutt ((ee..gg.. ppllaayy aannrruuff..aauu 22//ddeevv//nnuullll )).. WWhhyy ddooeess IISSDDNN tteellll mmee CCaann''tt
ssttaarrtt ''//uussrr//llooccaall//bbiinn//ppllaayy aannrruuff..aauu 22//ddeevv//nnuullll'' wwiitthh eexxeeccvvpp(()) ??
Because isdnlog is not a (Bourne) shell ;-) Isdnlog can only start
rreeaall programs. Just write a little script for it and make it
executable (chmod +x):
______________________________________________________________________
#!/bin/sh
/usr/local/bin/play anruf.au 2/dev/null
______________________________________________________________________
2233..1122.. iissddnnlloogg__bbllaannkkssccrreeeenn:: WWhheenn ddiiaalliinngg oouutt,, tthhee ssccrreeeenn ggooeess mmoommeenn--
ttaarriillyy bbllaacckk??
This may happen when you start isdnlog with the options -t1 or -t2,
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.
2233..1133.. iissddnnlloogg__nnoollooggggiinngg:: IIssddnnlloogg ddooeess nnoott lloogg aannyy iinnccoommiinngg ccaallll ffoorr
mmee??
Please verify whether your setup complies with the restrictions given
in the isdnlog man page:
Isdnlog only works with the HiSax isdn driver. Other cards with their
own driver are not supported. Additionally you need to enable d-
channel logging (you can use "hisaxctrl 1 4" to do that,
e.g. "hisaxctrl line0 1 4"). Isdnlog can only log outgoing calls
that originate from your isdn card, and incoming calls. To get
information about outgoing calls from other isdn devices (e.g.
telephones), you need a second Teles isdn card, with crossed lines.
Such a card is not usable for communicating, but can log outgoing
calls from any device.
See also question ``isdnlog_reversedcard'' for using two ISDN cards
for logging.
2244.. aauuddiioo:: HHaannddlliinngg VVooiiccee wwiitthh IISSDDNN
(Most of the answers you will find here are taken from the - now
unfortunately outdated - vbox manual by Matthias Hessler
hessler@isdn4linux.de and Bernhard Hailer dl4mhk@lrz.uni-muenchen.de;
you can get the manual at:
2244..11.. aauuddiioo__lliinnkkss:: WWhheerree ccaann II ffiinndd hheellppffuull lliinnkkss rreeggaarrddiinngg vvbbooxx??
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:
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:
/usr/src/linux/Documentation/isdn/README.audio
2244..22.. aauuddiioo__ffoorrmmaatt:: WWhhaatt iiss tthhee ffoorrmmaatt ooff tthhee aauuddiioo mmeessssaaggeess ((..mmssgg))
vvbbooxx ppllaayyss wwhheenn iitt aannsswweerrss aa ccaallll??
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)
2244..33.. aauuddiioo__rreeccoorrddmmssgg:: HHooww ccaann II rreeccoorrdd mmyy oowwnn mmeessssaaggeess ffoorr
vvbbooxxggeettttyy??
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.
2244..44.. aauuddiioo__ppllaayy:: HHooww ccaann II ppllaayy aauuddiioo mmeessssaaggeess llooccaallllyy uussiinngg
//ddeevv//aauuddiioo??
This is best achieved with vbox using format 6 (uLaw - must be
compiled in). You can then easily play the messages using:
______________________________________________________________________
cat xxx /dev/audio
______________________________________________________________________
where xxx is the message-file.
2244..55.. aauuddiioo__ccoonnvveerrttttoo:: HHooww ccaann II ccoonnvveerrtt aauuddiioo mmeessssaaggeess wwhhiicchh wwhheerree
rreeccoorrddeedd bbyy vvbbooxx ttoo ootthheerr ffoorrmmaattss ((ii..ee.. ffrroomm uuLLaaww ttoo WWAAVV))??
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:
(including sources that compile under Linux).
2244..66.. aauuddiioo__ccoonnvveerrttffrroomm:: HHooww ccaann II ffoorrmmaatt WWAAVV ffoorr uuLLaaww ((ffoorr mmyy vvbbooxx
aannnnoouunncceemmeenntt mmeessssaaggee))??
We receive the following tip form Christian Stueble
stueble@ls6.informatik.uni-dortmund.de on 15 Jan 1997:
For me, the following (somewhat indirect) method works:
______________________________________________________________________
sox file.wav -r 8000 file.ul rate
rmdcatheader -u file.ul file.msg
cat file.ul file.msg
______________________________________________________________________
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.
2244..77.. aauuddiioo__ddttmmff:: HHooww ccaann II iimmpprroovvee tthhee rreeccooggnniittiioonn ooff ((DDTTMMFF)) ddiiaall
ttoonneess??
You can adjust the parameters DTMF_TRESH, SILENCE_TRESH, and H2_TRESH
in file linux/drivers/isdn/isdn_audio.c. A DTMF tone is recognized if
the amplitude of the correct frequency is larger than DTMF_TRESH and
the amplitude of the second harmonian frequency is smaller than
H2_TRESH. If a dial tone is recognized when no dialing took place,
try to increase DTMF_TRESH and/or decrease H2_TRESH. However, test
with many telephones - the current parameters were already set after
some tuning.
2244..88.. aauuddiioo__ee00226655:: MMyy vvbbooxxggeettttyy ggeettss aa mmooddeemm ttiimmeeoouutt,, aanndd rreeppoorrttss
eerrrroorr EE00226655..
Probably you need a patch that has been posted recently (8th December
1999) on the mailing list.
2244..99.. aauuddiioo__nnooaannsswweerr:: MMyy vvbbooxxggeettttyy ddooeess nnoott aannsswweerr aannyy iinnccoommiinngg
ccaallllss..
vboxgetty needs ".vboxrc" in the home directory of the user for which
vboxgetty is configured. The number of rings is taken from this file.
2244..1100.. aauuddiioo__nnooccaatt:: IIff vvbbooxxggeettttyy hhaass rreeccoorrddeedd aa mmeessssaaggee iinn aa ffoorrmmaatt
wwhhiicchh ccaann nnoott bbee ppllaayyeedd uussiinngg ""ccaatt xxxxxx//ddeevv//aauuddiioo"" hhooww ccaann II ssttiillll hheeaarr
tthhee mmeessssaaggee??
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
``audio_recordmsg''.
2244..1111.. aauuddiioo__eeaarrllyyrreeccoorrddiinngg:: AAtt tthhee bbeeggiinnnniinngg ooff aa mmeessssaaggee rreeccoorrddeedd
bbyy vvbbooxxggeettttyy,, tthheerree''ss oofftteenn aa ppaarrtt ooff mmyy oowwnn aannnnoouunncceemmeenntt??
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.
2255.. SSuuppppoorrtteedd CCoouunnttrriieess
2255..11.. ccoouunnttrryy__wwhhiicchh:: IInn wwhhiicchh ccoouunnttrriieess ddooeess iissddnn44lliinnuuxx wwoorrkk??
We are aware of at least the following countries:
+o Austria (see question ``country_austria'')
+o Australia
+o Brazil (see question ``country_brazil'')
+o Belgium
+o Denmark
+o Finland
+o France (see question ``country_france'')
+o Germany
+o Hungary
+o India
+o Ireland
+o Israel
+o Italy (see question ``country_italy'')
+o Japan
+o Luxemburg
+o Norway
+o Pakistan (see question ``country_pakistan'')
+o Peru
+o Poland
+o Portugal (see question ``country_portugal'')
+o Singapore
+o Spain
+o Sweden
+o Switzerland (see question ``country_switzerland'')
+o The Netherlands (see question ``country_netherlands'')
+o United Arab Emirates
+o United Kingdom (see question ``country_uk'')
+o USA (see question ``country_northamerica'')
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.
2255..22.. ccoouunnttrryy__cceerrttiiffiieedd:: IIss iissddnn44lliinnuuxx aapppprroovveedd ffoorr uussee bbyy tthhee
tteelleeccoommmmuunniiccaattiioonnss aauutthhoorriittiieess??
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:
+o Active cards: the approval covers the entire card including its
firmware. Thus the approval also covers the use of these cards with
isdn4linux.
+o Elsa Quickstep series cards (new name Microlink PCI)
+o Eicon Diva 2.01 PCI
+o Teles 16.3 ISA (with Siemens chipset)
+o Sedlbauer Speedfax+ PCI
+o Passive cards: all cards based on the HFC-S chipset.
Actually, since April 2000 the rules for certification have
changed. Now the producer of an ISDN card has to do only hardware
tests, the driver is not part of the certification anymore. This
applies to the whole European Community.
2266.. 11ttrr66:: GGeerrmmaann PPeeccuullaarriittiieess ffoorr 11TTRR66
2266..11.. 11ttrr66__eeaazz:: WWhhiicchh EEAAZZ sshhoouulldd II uussee ffoorr ii44ll??
You can use all available EAZ. However, two EAZ have a special meaning
and can cause problems:
EAZ 0: global call (all telephones ring)
EAZ 9: global call (no telephone rings)
Gernot Zander hifi@scorpio.in-berlin.de wrote about this on 6. Jan
1997:
I would not use 0, for my taste it is too likely that i4l
will steal all voice connections.
2266..22.. 11ttrr66__eexxtteennssiioonn:: II uussee 11TTRR66 oonn aann eexxtteennssiioonn -- tthhee eexxtteennssiioonn nnuumm--
bbeerr hhaass mmoorree tthhaann oonnee ddiiggiitt ((ee..gg.. 220066)).. WWhhaatt iiss mmyy EEAAZZ??
Jens Ey jens@jeyhh.shnet.org 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'.
2266..33.. 11ttrr66__ssppvv:: WWhhaatt iiss aa SSPPVV??
SPV stands for "semipermanente Verbindung" (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.
2266..44.. 11ttrr66__ssppvvddiiaall:: DDooeess iissddnn44lliinnuuxx ssuuppppoorrtt SSPPVVss?? HHooww??
To switch on the support for SPVs, add an "S" before the number to be
dialed. This works (quite well) for modem emulations as well as for
defined network interfaces.
2277.. OOtthheerr ccoouunnttrriieess
2277..11.. ccoouunnttrryy__aauussttrriiaa:: AAuussttrriiaa:: WWee hhaavvee nneeiitthheerr aann MMSSNN nnoorr aann EEAAZZ,,
oonnllyy aa nnoorrmmaall ppllaaiinn tteelleepphhoonnee nnuummbbeerr.. WWhhaatt ddoo wwee hhaavvee ttoo uussee ffoorr ii44ll??
In Austria ISDN lines are by standard installed _w_i_t_h_o_u_t MSN (which is
different from Germany). That means when somebody calls the installed
ISDN number the called party gets signalled a "global call". i4l then
says "incoming call without CPN" - "CPN" means called party number.
Solution: Set the incoming "MSN" (in reality: none) to "0", 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.
2277..22.. ccoouunnttrryy__bbrraazziill:: BBrraazziill:: HHooww ddooeess oouurr MMSSNN llooookk lliikkee??
For use with Telemar you have to configure your MSN as your phone
number without the leading area code.
Brazil is using EuroISDN. The ISDN service DVI which was launched by
Telemar is based on a hardware solution from Teles (BRI PCI card),
which has to be configured as NETjet card. However, since this card is
very incompatible to the motherboards sold in Brazil, Telemar also
offers the option of a Teles 16.3c ISA. You may be able to find some
configuration help on for this card.
2277..33.. ccoouunnttrryy__ffrraannccee:: FFrraannccee:: HHooww ddooeess oouurr MMSSNN llooookk lliikkee??
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 .
2277..44.. ccoouunnttrryy__iittaallyy:: IIttaallyy:: WWhhaatt ddooeess oouurr MMSSNN llooookk lliikkee??
isdn4linux also works in Italy (ICN card). The MSN must be the phone
number with the Italian area code, and since middle of 2001 includes
the leading 0. For example, if my phone number is 72004681 and my
area code is 045, my MSN is 04572004681. Now with the setting
AT&E04572004681 isdn4linux works fine.
2277..55.. ccoouunnttrryy__nneetthheerrllaannddss:: NNeetthheerrllaannddss:: WWhhaatt ddooeess oouurr MMSSNN llooookk lliikkee??
In The Netherlands the MSN includes (as opposed to the German Telekom)
_a_l_s_o _t_h_e _a_r_e_a _c_o_d_e - but without the leading zero.
2277..66.. ccoouunnttrryy__nnoorrtthhaammeerriiccaa:: NNoorrtthh AAmmeerriiccaa:: CCaann wwee uussee iissddnn44lliinnuuxx iinn
NNoorrtthh AAmmeerriiccaa??
Yes, you can use isdn4linux in North America. However, some
specialties apply.
In North America the telephone company will only provide a U instead
of an S interface. This means that the customer rather than the
telephone company has to supply the network terminator (NT-1). Your
easiest solution is a card which has an integrated NT-1 and supports
the U interface. Alternatively buy an external NT which translates
between U and S interface, and connect your ISDN card with S interface
(without NT-1) to it.
In North America the channel protocol NI-1 is being used. NI-1 is
related to DSS1 (both are Q.931 Protocols), but both have totally
different groups of functions. Support for NI-1 has recently been
added to HiSax, the driver for passive cards, with great help from
Traverse Technologies:
. Since they helped to implement and verify
NI-1 usability, we would recommend you buy their card NETspider-U
(with integrated NT-1), as a thank-you for their contribution to
isdn4linux open source development.
See Documentation/isdn/README.HiSax for details on how to set up your
system with HiSax (protocol type is 4, give SPID together with your
own number in the form of :).
Quite some time ago, the firm "Spellcaster" has written their own
isdn4linux driver for their (active) cards. Both BRI and PRI cards are
available. More information is available on:
Also, the active Eicon DIVA cards work fine in North America and have
5ESS and NI drivers, which are currently ported to UltraSparc.
2277..77.. ccoouunnttrryy__ppaakkiissttaann:: PPaakkiissttaann:: WWhhaatt sshhoouulldd wwee uussee aass MMSSNN??
It seems that no MSN functionality is supported. Therefore the MSN
should be set to "0".
2277..88.. ccoouunnttrryy__ppoorrttuuggaall:: PPoorrttuuggaall:: WWhhaatt sshhoouulldd wwee uussee aass MMSSNN??
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 "0". If more than one MSNs was applied for, then these should be
set as usual.
2277..99.. ccoouunnttrryy__sswwiittzzeerrllaanndd:: SSwwiittzzeerrllaanndd:: WWee hhaavvee nneeiitthheerr aann MMSSNN nnoorr aann
EEAAZZ,, jjuusstt aa ppllaaiinn tteelleepphhoonnee nnuummbbeerr.. WWhhaatt ddoo wwee hhaavvee ttoo uussee ffoorr ii44ll??
In Switzerland usually you have to use the telephone number without
area code. For old ISDN numbers where you have been assigned ten
numbers in a row this may be different; in that case use the _l_a_s_t
_d_i_g_i_t of your telephone number as your MSN/EAZ ("6" if you have the
telephone number "123456").
2277..1100.. ccoouunnttrryy__uukk:: UUKK:: WWhhaatt sshhoouulldd wwee uussee aass MMSSNN??
It depends on your ISDN option.
+o 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 AT&E0), 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).
+o ISDN2e: Seems to be normal EuroISDN. You are assigned MSNs which
you can use and configure for isdn4linux. The MSN is reported to
consist of the last 6 digits of your telephone number (try to add
digits from your area code, if the local number part is shorter
than 6 digits).
+o 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.
+o 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.
Please note that BT offers an unexpected special "feature" on
international calls. For international data calls you have to dial
000 (three zeros), rather than the 00
(two zeros) for international voice calls.
By the way: for a BT Speedway card try to select AVM Fritz card
(either ISA or PCI - depends on what you got; see question
``hardware_fritz'').
Since about November 2001, all BT home highway and possibly Business
Highway NTE boxes come with a built in USB terminal adapter. This
terminal adapter is based on the ST-5481 chipset. Load the module
st5481 for this device, then set up your isdn configuration with
isdnctrl.
Also, check out .
2288.. mmiisscc:: MMiisscceellllaanneeoouuss
2288..11.. mmiisscc__ssttaannddaarrddss:: WWhhiicchh ssttaannddaarrddss aappppllyy ttoo tthhee IISSDDNN pprroottooccooll llaayy--
eerrss??
These are the main standards:
+o Layer 1: ITU I.430 and ETSI 300 012-1
+o Layer 2: ITU Q.921 and ETSI 300 125-1
+o Layer 3: ITU Q.931 and ETSI 300 102-1 (plus some changes and
clarifications in ETSI 300 403)
All layers are also described in TBR3. For study, the standards are
freely available from .
2288..22.. mmiisscc__nnoonnuullllccaabbllee:: CCaann II ccoonnnneecctt ttwwoo IISSDDNN ddeevviicceess ddiirreeccttllyy wwiitthh
aa kkiinndd ooff ""nnuullll mmooddeemm ccaabbllee""??
This is only possible if one of the cable can run in NT mode (see
glossary on what this is: ``glossary_ntmode''). Only a few cards allow
it, all others need an NTBA or PBX with an internal bus to communicate
with each other. See question ``feature_crossedcable''.
2288..33.. mmiisscc__uuiissddnn:: CCaann iissddnn44lliinnuuxx rruunn iinn ppaarraalllleell ttoo UUIISSDDNN??
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.
2299.. gglloossssaarryy:: IISSDDNN ssppeecciiffiicc wwoorrddss wwhhiicchh aarree uusseedd iinn tthhiiss FFAAQQ
aaccttiivvee ccaarrdd
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.
AAOOCC--DD
"Advice Of Charge During the Call".
AAOOCC--EE
"Advice of Charge at the End of the Call". In Germany, this
service is included in the "Komfort" connection.
BBRRII
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.
CCLLIIPP
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.
CCLLIIRR
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).
CCOOLLPP
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.
CCVVSS TTrreeee
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.
EEAAZZ
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).
HHDDLLCC
A widely used low-level protocol, usually used to connect your
computer with your internet provider. To connect to a computer
mailbox, usually X.75 is being used.
HHSSCCXX
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.
IISSAACC
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.
lleeaasseedd lliinnee
Your telecommunication company can hardwire the connection
between two of their ISDN users. Then these users are always
connected to each other without dialing and can not dial out to
someone else any more.
MMSSNN
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).
NNTT NT is the abbreviation of network terminator. This is the
interface between an ISDN user and the ISDN provider. It is a
small hardware box to which the user has to connect his ISDN
devices via a so called S0 interface. In most European
countries, the ISDN provider supplies the NT. A user in North
America usually has to buy one, therefore the NT is often
integrated into the ISDN card there.
NNTT mmooddee
When multiple devices are connected to the ISDN connection, then
all user device behave as slaves, where the network terminator
(NT) behaves as master and synchronizes the communication on the
S0 bus. The special behavior of the network terminator is called
NT mode. User devices are normally not capable of running in NT
mode. As a result, user devices can not communicate with each
other even when they are connected via a crossed cable. Only
some special ISDN cards (HFC chipset) are capable of running in
NT mode, and can directly communicate with other ISDN user
devices via a crossed cable.
mmuullttii--ddeevviiccee mmooddee
Your ISDN interface can be configured either in multi-device
mode (in German: Mehrgeraeteanschluss), or in point-to-point
mode (in German: Anlagenanschluss). The multi-device mode is
the normal connection mode for private ISDN users or very small
business users. The user can attach multiple devices to the ISDN
connection. The ISDN provider will assign a small number of
fixed telephone numbers (usually up to 10 MSN), if any, to the
ISDN connection.
ppaassssiivvee ccaarrdd
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.
PPBBXX
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).
ppooiinntt--ttoo--ppooiinntt mmooddee
Your ISDN interface can be configured either in multi-device
mode (in German: Mehrgeraeteanschluss), or in point-to-point
mode (in German: Anlagenanschluss). The point-to-point mode is
the normal connection mode for business ISDN users. The user can
attach only one single devices to the ISDN connection which will
have to handle all calls (typically a PBX will be used). The
ISDN provider will assign a range of numbers to the ISDN
connection. Any call within this number range will be sent to
the user. The ISDN provider will leave assignment of the last
digits of the telephone number to the ISDN user. This setup
usually allows for additional features, but is also more
expensive.
PPRRII
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.
sseemmii--aaccttiivvee ccaarrdd
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).
ssuubbaaddddrreessssiinngg
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).
TTEEII
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)
UUUUSS
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.
XX..7755
A widely used low-level protocol, usually used to connect your
computer with a computer mailbox. For connections to the
internet, HDLC is usually used.