ATTENTION! The following header is not fully valid yet!
From: dl4mhk@lrz.uni-muenchen.de (Bernhard Hailer)
Newsgroups: de.alt.comm.isdn4linux,de.answers,news.answers
Subject: ISDN4linux-FAQ
Followup-To: de.alt.comm.isdn4linux
Summary: This posting describes what every reader of de.alt.comm.isdn4linux
ought to know about ISDN under Linux using isdn4linux.
This is an English translation of the original document, which is
in German, like the Newsgroup.
Archive-name: eng-i4l-faq
Posting-frequency: monthly
Last-modified: 18-Mar-97
URL: http://www.lrz-muenchen.de/~ui161ab/www/isdn/
+49 931 781464 Zyxel U-1496E V.32(bis), V.42(bis), Zyxel 19200
+49 931 781465 Atrie 1914A V.32(bis), V.42(bis), V32terbo
+49 931 781467 Atrie 1914A V.32(bis), V.42(bis), V32terbo
+49 931 781468 Atrie 1914A V.32(bis), V.42(bis), V32terbo
+49 931 79002055 Motorola 3400 V.32(bis), V.42(bis), V.34
+49 931 7840724 ICN X.75 2 B channels
+49 931 7841020 ICN X.75 2 B channels
+49 931 7841060 ICN X.75 2 B channels
+49 931 7841070 ICN X.75 2 B channels
+49 931 7841080 ICN X.75 2 B channels
ftp://freja.frontier.dk/linux/isdn4linux/ ftp://ftp.cs.tu-berlin.de/pub/net/isdn/isdn4linux/ ftp://ftp.fokus.gmd.de/.mount2/pub/Linux/isdn/isdn4linux/ ftp://ftp.franken.de/pub/isdn4linux/ ftp://ftp.germany.eu.net/pub/os/Linux/Local.EUnet/ISDN/isdn4linux/ ftp://ftp.kiss.de/pub/linux/isdn4linux/ ftp://ftp.leo.org/pub/comp/os/linux/isdn/isdn4linux/ ftp://ftp.lame.org/mirrors/isdn/ ftp://ftp.mathematik.th-darmstadt.de/pub/linux/mirrors/misc/isdn4linux/ ftp://ftp.nvg.unit.no/pub/linux/isdn/ ftp://ftp.pop.de/pub/local/linux/isdn/ ftp://ftp.rz.fh-hannover.de/pub/linux/local/isdn4linux/ ftp://ftp.rz.hu-berlin.de:/pub/linux/isdn4linux/ ftp://ftp.tu-dresden.de/pub/soft/isdn/isdn4linux/ ftp://ftp.uni-mainz.de/pub/internet/starter-kit/isdn/isdn4linux/ ftp://ftp.uni-wuppertal.de/pub/linux/isdn4linux/ ftp://ftp.xlink.net/pub/mirror.ftp.franken.de/isdn4linux/ ftp://fvkma.tu-graz.ac.at/pub/isdn4linux/ ftp://wildsau.idv.uni-linz.ac.at/pub/isdn4linux/
ISDN kernel subsystem:/usr/src/linux/Documentation/isdn/README
ISDN cards: /usr/src/linux/Documentation/isdn/README.<card>
Synchronous PPP: /usr/src/linux/Documentation/isdn/README.syncppp
/usr/src/linux/Documentation/isdn/README.syncPPP.FAQ
Voice capability: /usr/src/linux/Documentation/isdn/README.audio
ISDN Utilities: /usr/src/isdn4k-utils-<version>/README(.*)
Many of the utilities also have man pages!
In a Suse distribution the following information might also be
helpful:
Synchronous PPP: /usr/doc/faq/faq/PPP-FAQ
Email configuration: /usr/doc/howto/mini/Mail-Queue.gz
index isdn4linux - list which archive files are available
get isdn4linux <filename> - retrieves the file <filename>
Austria
Belgium
Finland
France
Germany
Israel
Italy
Norway
Peru
Portugal
Spain
Sweden
Switzerland
The Netherlands
United Kingdom
USA
[Translator's note: I've also seen messages on the mailing list from isdn4linux users in Canada, Denmark, Hungary and Slovenia . I've also seen mentions of isdn4linux from Australia, the Czech Republic and Poland, but I'm not sure if it is actually in use in those countries.]
[Translator's note: Unfortunately the HiSax driver did not get included in kernel 2.0.30, and the Teles driver no longer works with this kernel. To use HiSax with 2.0.30, you need the patch
ftp://ftp.franken.de/pub/isdn4linux/v2.0/isdn4kernel-2.0.30A.gz
(or from one of the many isdn4linux mirrors). This patch is also included in the kernel pre-patch-2.0.31 (which I've been using without problems). The kernels provided with some distributions have the patch already applied (for example Debian 1.3.x and Suse 5.0).]
* ITK ix1 micro V2.0 and V2.1
* Cisco 200
* ITK Columbus
* Teles S0-8
* Teles S0-16 and S0-16.2
(identical to: Dr. Neuhaus Niccy 1016, Creatix 16/S0)
* Teles S0-16.3
* Teles S0-16.3 PNP
* Teles PCMCIA
* Creatix S0 PNP
* AVM A1 (Fritz!)
* ELSA Microlink PCC-16
* ELSA Microlink PCF
* ELSA Microlink PCF/pro (only ISDN, not the V34 Modem Chip)
* ITK ix1-micro Rev.2
The first goal of the HiSax driver was to add support for more ISDN
cards to i4l, and this goal remains. Secondly, it should be as simple
as possible to configure and not appear to work when there is a
hardware problem (IRQ, reset problems with Teles). I can't fix the
hardware problems directly, but driver will not load if such problems
appear. Third (this part has just now begun) is to fully rewrite the
state machines into a complete DSS1 or 1TR6 that could be approved
(which doesn't mean that I personally can or want to obtain approval).
In addition, if possible I'd like to support US ISDN protocols, so
that i4l can be used outside of Europe. Also, further l2/l3 protocols
should be added (e.g. V110), leased line support.... a lot of work,
that I'm sure I cannot do alone. Anyone with any knowledge of
programming and ISDN (I myself first heard of ISDN in January, and my
work has nothing to do with ISDN... I learned everything on my own
time), and anyone who wants to help can contact me.
1st choice ELSA
ELSA (as opposed to AVM) makes the specifications available.
2nd choice Creatix PNP
Creatix employees are also not completely negative towards Linux ;-).
By the way, this card has been developed by Creatix and
is not identical to the Teles 16.3 PNP.
56k asynchronous : no
64k synchronous : yes
128k synchronous : yes (channel bundling - see the next question)
* 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.
* Under ++49-551-7704102, a 28800 bps modem and a Creatix ISDN
card (HDLC only, not X.75) are listening for logins.
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.
#!/bin/sh
exec rsh -l guest $*
cvs -z9 checkout isdn4k-utils
checkout
diff
export
status
update
In dosemu.conf it is enough to enter a virtual com port,
(for example com2) that can be used with e.g. Telix or
Terminate: serial { com 2 device /dev/ttyI3 }
Access with Fossil is possible if fossil.com (included with
dosemu) is started. Tested with the following configurations:
- Kernel 2.0.21, Teles driver incl. Karsten's patches
- Kernel 2.0.21, HiSax
They run parallel. And they run under 2.0.X.
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.
"Advice Of Charge During the Call".
"Advice of Charge at the End of the Call". In Germany, this service
is included in the "Komfort" connection.
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. In Germany, this must be applied
for but is without charge (however call by call transmission of the
caller ID costs extra).
COLP can also be offered by the ISDN provider. In Germany, it must be
applied for, and costs an extra 10.-- DM per month. If you've applied
for COLP, you get an extended dialing protocol that, for example, can be
evaluated in the PBX. Current the possibility is being worked on to get
around this with the help of a backwards-connected Teles card. One could
then get more information than with a running COLP without using any units.
That could quickly pay off...
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.
A widely used low-level protocol.
A Siemens chip, that similar to ISAC is 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.
A Siemens chip, that similar to HSCX is on many passive cards.
Et 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.
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 PBX connections)
64-126 automatically assigned
127 call for all (e.g. an incoming call)
A PBX 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.
Try out port 0x080h, DIP-SW in the undocumented
position!
1. HiSax has to be patched into the kernel
(Attention: use the "-pn" parameter!)
2. With "make menuconfig" (or "make config") set the following
kernel options :
* ISDN = "M" (as module - otherwise PNP doesn't work!)
* HiSax = "M" (as module - otherwise PNP doesn't work!)
* 16.3/PNP support
* EURO support
3. Compile and install kernel and modules, depmod. (Reboot!)
4. Read the configuration of the PNP card with:
"pnpdump > /etc/isapnp.conf".
5. The configuration file "/etc/isapnp.conf" has to be set by hand.
Set the following values:
INT0 - the interrupt used by the card
(Default for Teles 16.3 PNP: 10)
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! Early
versions of the PNP cards my suggest incorrect values!)
6. Activate the configuration with:
"isapnp /etc/isapnp.conf"
(must be started at every boot)
7. Now the HiSax module can be started with:
"modprobe hisax io=4,<P>,<INT>,<IO0>,<IO1>"
4 - PNP card
<P> - Protocol:
2 - for Euro-ISDN (normally)
1 - for 1TR6-ISDN (German predecessor to Euro-ISDN)
<INT> - the value in etc/isapnp.conf for INT0
<IO0> - the value in etc/isapnp.conf for IO0
<IO1> - the value in etc/isapnp.conf for IO1
On my computer I've defined 2 run levels (3 and 4), 3 runs without ISDN,
4 with. If I want to quit ISDN with all the associated processes like
ipppd, isdnlog and mgetty, as root I enter "init 3"; and to start "init
4". init then makes sure with "/sbin/init.d/i4l start" or
"... stop" that the necessary things are done.
That's no problem - we've done that for a while now.
- Simply set up an ISDN interface.
- Important: encap isdnX ethernet
The rest is done by "mars_nwe" (incl. routing).
By default, kerneld unloads a module after it has not been needed for one
minute. This is no problem for device drivers ala floppy, etc., but it is
a problem for drivers that need to keep settings over a longer period
of time, e.g. the mixer settings for a sound card or the configuration of
dialin and dialout parameters for ISDN. Unloading the ISDN drivers also
kills the IP interface ippp0 or isdn0. The entries in the IP layer of the
kernel then disappear. If you look in the start-up scripts for i4l,
you'll a lot of things that are configured with isdnctrl, etc.; they
would have to be reconfigured by kerneld each time the module is
reloaded. The status of the D channel could also be lost. Therefore, my
recommendation is not to use kerneld, rather load the modules at start-up
and only unload if necessary for some technical reason.
For some time now there has been an extension to the modules package just
for this purpose; it allows the installation of a databank with the
current status of the modules. Unfortunately, this feature usually not
supported by the modules. An alternative are such options as the
"post-install" hook in "/etc/conf.modules". It would then be necessary to
write the appropriate scripts by hand, but in principle that would work
just as well as the modules automatically using the initializations
settings from a database.
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
ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/tools.
This patch recognizes rawIP, ISDN-IP and CISCO-HDLC and can
dump these packets.
This is a isdn4k-utils-2.0/tcpdump-3.0.3-isdn.diff ! It work,
if one makes some changes:
In the file tcpdump-3.0.3-isdn/libpcap-0.0/pcap-linux.c after patching
you find the following:
else if (strncmp("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.
chgrp isdn /dev/ttyI* /dev/cui*
chmod o-rw /dev/ttyI* /dev/cui*
* Telephone * Analogue modem (used for data, fax or voice mailbox) * Dialin for X.75 (modem emulation) * Dialin for syncPPP
- Telephony (voice) - VBOX (voice, of course) - X.75 login (mgetty, /dev/ttyI?) - IP interface for IP connections to other computers?
The first comes from the PBX and is not checked.
The second is that assigned by the Telekom.
Here I had calls where a Siemens employee from Munich called
in with a long Caller ID with a Berlin area code (030).
I called the Telekom to ask what was going on; they didn't know
either until they found somewhat competent who told me that
it's allowed.
"CLIP no screening". The caller has the feature (which costs extra
and is only available with the "Komfort" PBX connection(!)),
that allows him to transmit any Caller ID he chooses.
The addresses actually used are:
isac 980
hscx 180/580
cfg d80
The confusion is the result of a misunderstanding. Teles gives the
HSCX0 address as a reference, while the old Teles driver needs the
cfg address. Since users were confused by this, both driver can
now use either address (which confuses the users even further ;-))
#define NEW_GET_FREE_PAGES
/* #define NEW_GET_FREE_PAGES */
/* #define NEW_TIMERS */
struct IsdnCard cards[]={
{ (byte *)0xd0000,11,0xd00,NULL } ,
/* 1. Karte */ { (byte *)0xd8000,10,0xe80,NULL } ,
/* 2. Karte */ ...
/* u.s.w. */
};
# load modules
/sbin/modprobe isdn.o
echo "teles0 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles0 teles_id=teles0
io=0xd0000,5,0xd80,2
echo "teles1 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles1 teles_id=teles1
io=0xd2000,9,0xe80,2
echo "teles2 - Teles S0/16.2"
/sbin/insmod $MODPATH/misc/teles.o -o teles2 teles_id=teles2
io=0xd4000,12,0xf80,2
/sbin/lsmod | grep teles > /dev/null
If you want to read more about Teles's business practices, look at
http://www.inx.de/~chris/isdn.htm
HiSax checks the hardware and the behavior of the IRQ, so that the
driver will only be loaded if it can access the register and the
interrupts can be generated.
THEREFORE:
loading twice is taken care of
HSCX version 0 or F is taken care of
BUSY with minicom only if :
* REALLY BUSY
* no MSN/EAZ
* cable/line problems
It can never hurt to first backup the original kernel sources.
Then go to /usr/src/linux (where the current source should be.
The patch itself:
zcat HiSax_1.1.patch.gz |patch -p1 >& /tmp/HiSax.log
The -p1 is very important, otherwise all files will end up in new
directories under /usr/src/linux.
Then look at /tmp/HiSax.log for errors/warnings/rejects, if there are
any then look at those files and correct by hand, if necessary.
If you have Gnu Patch, you can also use "... |patch -s -p1 ". Then
_only_ the errors will be reported. If you want a log, you can also
"... |patch -s -p1 | tee /tmp/HiSax.log". Then you get a logfile in
addition to the screen output.
The patches (until the next version) will be "numbered" with letters
and be available via FTP.
1. The above statement is not quite correct:
if ((channel &1)+1 == B-channel )
2. I described the bug the other way around: if B channel 1 is
being used by another ISDN device and i4l dials out, then the
logical channel 0 from the VST is assigned B channel 2 ---> OK
The other ISDN device hangs up. Another call comes in for i4l,
this time on B channel 1. Since channel 0 is taken, and there is
a fixed order B1->chan 0,2,4... B2->chan 1,3,5... the call is
not accepted. (chan 2,3 is for 2 cards, etc.) This happens only
seldomly, and will be fixed soon (if I get a brilliant idea).
l1 is down
=> both LEDs blink ca. 1s on 1s off.
l1 is activated (also though the telephone or whatever)
=> Blink in sequence 0.5 yellow 0.5 green
In use
=> 1.5 on 0.5 off
green HSCX A active
yellow HSCX B active
The constant blinking is caused when the card hangs, as I noticed
during development.
Thinking Objects Software GmbH Obere Heerbergstr. 17 97078 Würzburg Germany Tel: +49-931-2877950 Fax: +49-931-2877951 email isdn-support@think.de WWW http://www.think.de/
The newest firmware should be available under the URL
ftp://ftp.think.de/pub/isdn4linux/firmware/
/sbin/insmod -m /lib/modules/1.2.13/misc/isdn.o >/etc/isdn.map
/sbin/insmod -m /lib/modules/1.2.13/misc/icn.o >/etc/icn.map
/sbin/insmod -m -o icn2 /lib/modules/1.2.13/misc/icn.o >/etc/icn2.map
/sbin/insmod -m /lib/modules/`uname -r`/misc/isdn.o > /etc/isdn.map
#
# ICN-2B, default port and mem (0x320, 0xd0000)
#
/sbin/insmod -m /lib/modules/`uname \
-r`/misc/icn.o icn_id=icn0 > /etc/icn.map
#
# ICN-4B inserted at port 0x328
#
/sbin/icnctrl add 0x328 icn1 icn2
#
# Another ICN-4B at port 0x300
#
/sbin/icnctrl add 0x300 icn3 icn4
#
# Load firmware
# ICN-2B: 1TR6
# 1. ICN-4B, both S0 EDSS1
# 2. ICN-4B, 1. S0: 1TR6, 2. S0: EDSS1
#
/sbin/icnctrl -d icn0 \
load /etc/loadpg.bin /etc/pc_1t_ca.bin
/sbin/icnctrl -d icn1 \
load /etc/loadpg.bin /etc/pc_eu_ca.bin /etc/pc_eu_ca.bin
/sbin/icnctrl -d icn3 \
load /etc/loadpg.bin /etc/pc_1t_ca.bin /etc/pc_eu_ca.bin
I use the following script to "start" the card:
#!/bin/sh
#
# load modules
/sbin/modprobe isdn.o
/sbin/modprobe icn.o icn_id=icn0 icn_id2=icn2
# ^^^^^^^^^^^^
# Important here is the entry for
# icn_id2. Then the driver recognizes,
# that a 4B should be used.
#
# download firmware
cd /usr/src/isdn4k-utils-1.3.97/icn
icnctrl load download/loadpg.bin download/pc_1t_ca.bin \
download/pc_1t_ca.bin
/sbin/isdnctrl verbose 2
modprobe icn icn_id=line0 icn_id2=line1 icnctrl io 0xd0000 0x340
icnctrl add 0x340 line0 line1
icnctrl load /sw/linux-i386/isdn4kutils-2.0.0/lib/loadpg.bin \
/sw/linux-i386/isdn4kutils-2.0.0/lib/pc_1t_ca.bin \
/sw/linux-i386/isdn4kutils-2.0.0/lib/pc_1t_ca.bin
For EDSS1:
DRV1.11EC-Q.931-CAPI-CNS-BETA-15.07.95,BRV2.3
For 1TR6:
DRV1.01TC-1TR6-CAPI-CNS-BETA-03.05.95,BRV2.3
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 /
----------------------------------------------------
Modem network: yes. This might also be possible with CINDI,
WISPA etc. from Herbert Hahnewinkel (costs ca 80 DM per license, and
every user needs one), but I didn't spend the money.
use AVMPort (Capi modem emulation for Win' 95), important: on
Win 0.95 "Register on network" should be turned on.
Control Panels/Software/Diskette CD-ROM Admin/Apptools/Dscript
- Script administration for modem networks (after installing
see Start/Programs/Utilities)
So that the script receives something, with ISDN turn echo. With
the AVMPort put E1 in the init string.
When you call the Mac, he should set the protocol to X.75 or HDLC.
When he calls you, he must explicitly set the protocol (e.g.
by inserting an "X" for X.75) in the called number - otherwise the Mac
might call with the Leonardo protocol.
isdnctrl l2_prot <interface> hdlc
isdnctrl l3_prot <interface> trans
isdnctrl encap <interface> cisco-h
isdnctrl addif <interface>
Since Cisco-IOS 11.0.x (x = 7 is the only one I know about) I've had no
more problems with Cisco <-> HDLC <-> non-Cisco. That applies for netgw
as well as i4l and Banzai! on the other side, although in each case the
special Cisco HDLC options are important.
Until yesterday we had problems with AVM+W95 and Mini Port driver
(PPP with PAP). The Ascend took the call and 3-4 sec later hung up.
In the Ascend Log is just Call refused, which isn't right, since
the Ascend did take the call... With a new firmware on the
Ascend (4.6C+) instead of 4.6B+p2, the problem seems to be gone.
Since before we had another RACK (from ITK) that did _not_ behave
this way with our customers, I'm assuming that is was the Ascend.
New firmware for the Ascend can be found at
ftp://ftp.ascend.com/
or
ftp://ftp.ascend.de/
although you have to pay very close attention that you are taking the
correct image!
subscribe [my mail alias address] ascend-users-de
subscribe ascend-users-de
There is a more widely subscribed mailing list on Ascend.
It is in English (so Ascend technicians also read and send
messages there).
One can subscribe at:
majordomo@bungi.com
In the message body:
subscribe ascend-users
It could by, that the Authentication Type works this way, however
I use password "Ascend-CLID" to do this.
An entry in the users file has to look like this:
69123456 Password="Ascend-CLID"
User-Name = "Username"
User-Service = Framed-User
That means, the Caller ID as username, and "Ascend-CLID" as Password.
[...] Here I have several clean connections every day to a
EL310, I poll using ifcico FIDO with it. Here is the config
for the Elink:
ati Elink 310 Version 1.36 OK ati4
Baudrate: 115k2,N
SIN unbekannt: Ruf annehmen
Anschaltung: EDSS1
SIN ungleich &B: Ruf annehmen
Betriebsart: X.75
SIN gesendet: neutral
Mehrfachrufnummer: 980031
E1 M1 Q0 V1 X2 &B049 &C1 &D2 &R0 &S1
\A3 \J0 \N3 \Q3 \V1 %A013 %C1 %F1 FCLASS=000
S00=000 S01=000 S02=043 S03=013
S04=010 S05=008 S06=002 S07=040
S08=003 S09=000 S10=007 S11=000
S12=050 S13=01010000B S14=10011010B S15=00001110B
S16=10110011B S17=049 S18=013 S19=003
S20=000 S21=00000100B S22=000 S23=006
S24=120 S25=128 S26=016 S27=002
S28=003 S29=128 S30=000 S31=000
OK
(the same works of course with a modem. However, the initializing
sequence looks different.)
Step 1: Get diald. I don't know where to find it - ask archie.
(diald is used to set a default route to a physically
non-existent SLIP or CSLIP connection; when packets are set to
this pseudo-interface, diald establishes the (C)SLIP connection;
which packets start the connections and when/how the connection
is terminated can all be configured.) Then install the binary and
config files (you can use the sample files as they are, but if
you want e.g. ping to start a connection, you need to make minor
changes, the timeouts can also be adjusted as needed - simply
try it out).
Step 2: Use a kernel with integrated SLIP/CSLIP or with SLIP/CSLIP
modules (which has to be loaded, of course).
Step 3: Isdn4Linux also has to be installed, of course; the important
part is the modem emulation (ttyIX),
Step 4: Start diald, e.g. with the following script (I call it
/etc/rc.d/rc.diald.t-online):
/usr/sbin/diald /dev/ttyI2 -m aslip local 192.168.90.9 \
remote 192.168.90.1 defaultroute dynamic modem crtscts \
lock speed 38400 connect "chat -v -f /etc/diald/t-online" \
mtu 1500 dslip-mode local-remote
(This can also be sensibly written in a _single_ line :-)
Step 5: Write the script, I call it "etc/diald/t-online".
Looks something like this:
TIMEOUT 30
ABORT "NO CARRIER"
ABORT ERROR
ABORT "NO DIALTONE"
ABORT BUSY
ABORT "NO ANSWER"
ABORT "NO MSN/EAZ"
"" ATZ
OK AT&B2000&E<MyMSN>&X1
OK ATD01910
CONNECT .
"[?25h" <ZugangsKennung>\c
"[?25h" ""
"[?25h" ""
"[?25h" <passwort>
"[?25h" *53#\c
"[?25h" *190144100#\c
"[?25h" 19\c
"STATUS OK" LIN
"" "OK"
Certain place holders need to be replaced, of course:
<MyMSN> is the MSN, that you want to explore the world with.
<Zugangskennung>: The digit monster than usually begins with "000..."
that has been given to you by the Telekom.
<passwort>: The password.
This example script assumes that the default "Anschlußnummer" and
"Mitbenutzernummer" are used. If this is not the case, you have to
adjust the two lines before "[?25h" <passwort> accordingly. For example,
for the Mitbenutzernummer "0003", the line before "[?25h" <passwort>
should read:
"[?25h" 0003\c
(since the entry field is full after "0003", no CR is entered
afterwards) When diald is running, an interface "sl0" should
suddenly be available (ask ifconfig), and the default route
should point to it (route -n will tell you; without "-n", "route"
will try to resolve the fantasy IP addresses (which are later
replaced with real addresses) - we don't need it do to
that). Those who don't work only with numeric addresses, but also
want to successfully try to "ftp ftp.sunsite.edu", should of
course enter a name server in /etc/resolv.conf (one from the
Telekom has the address 94.25.2.129). Then start ftp, telnet,
netscape, whatever. That's it. By the way, diald will write
novels in your syslog. You can read the entire login procedure,
even if it looks somewhat chaotic. If a request doesn't work, use
"kill" to stop diald (routes will be automatically erased) and
check the syslog - if there is something like "Zur Zeit keine
verbindung möglich", then the Telekom's gateway is down. Or
perhaps the login is incorrect... watch out, after three
unsuccessful login attempts, the login will be closed and has to
be reactivated (either per telephone or directly from BTX
(e.g. seyon or minicom, dial 01910, slowly go through the login
screen by hand and follow the instructions).
In the mentioned version of chat, there is a small mistake in logf():
it keeps writing in a 256 byte buffer until a line feed comes in.
"T-Offline" sends many more bytes for its login page. Therefore, either
use chat without -v or enlarge the bugger (best with capacity checking).
* No handshaking
=> faster connections
* Authorization by Caller ID
=> fast, safe, no password
* Fixed IP address
=> a broken connection can be continued by redialing
* Higher data transfer rates
* Better stability (smaller driver => almost no bugs)
* No handshaking
=> Configuration must occur beforehand (IP addresses,...)
=> sensible to use for only for one provider at a time
* Authorization only by Caller ID
=> Dialin only possible from one's own number
* Fixed IP address
=> must be known ahead of time, more IP addresses required,
no dynamic assignment of addresses possible.
tail -f /var/log/messages |
awk '/isdn0 connected/ { system ("ip-up") }
/hangup isdn0/ { system ("ip-down") } '
(The following questions are mostly from the syncPPP FAQ by Michael Hipp.)
#
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
[...]
# PPPD for asyncPPP over ISDN
i1:45:respawn:/usr/sbin/pppd -detach silent noipdefault /dev/ttyI0
(The following questions are mostly from the syncPPP FAQ by Michael Hipp.)
/sbin/isdnctrl encap ippp0 syncppp
"isdnctrl pppbind <interface> <number>"
"isdnctrl pppbind ippp5 2"
/sbin/ipppd :$REMOTE noipdefault /dev/ippp0
lcp-restart 1
1. Your LAN is an official Class C net with IP addresses valid on
the Internet.
This case is the easiest of configure. You give each network
card on your network one of these addresses and set a
default route on the ISDN card that goes to your
provider.
2. You'd only like to do http in Internet from your LAN.
In this case you can make up IP addresses for your LAN;
the only official IP address is that for your ISDN card.
Then install a proxy server on your Linux router, and
enter it in all of your browsers. In this case you do
not need a default route.
3. From your LAN you only want to log in to your Linux ISDN
router and FROM THERE do your work on the Internet.
This is even simpler, then you don't even need a proxy
server.
There is a fourth possibility I'd like to add, although I've
never tried it out (since I prefer the 1st choice and have a
a Class C Subnet, hehe ;), but I have a friend who after
some playing with the Linux kernel has actually gotten IP
masquerading to work.
It works somewhat like a proxy (when looking at the effect of
hiding the IP). It doesn't offer any caching, of course, but
masks to the outside all internal IPs with that of the ISDN
interface. Don't ask me how the routing functions, but it
works...
If I'm not completely mistaken, my friend does this with a
dynamically assigned IP ?!
The following instructions were assembled by Rainer May
<r_may@khavi.desaster.heide.de>.
Prompt for development and/or incomplete code/drivers Y
Enable loadable module support Y
Networking support Y
Network firewalls Y
TCP/IP networking Y
IP: forwarding/gatewaying Y
IP: firewalling Y
IP: masquerading Y
PPP (point-to-point) support (if you PPP to the ISP) Y
SLIP (serial line) support Y
Ethernet (10 or 100Mbit) (or Arcnet or ...) Y
ISDN support [1] M
Support synchronous PPP (if you're using ipppd) Y
HiSax SiemensChipSet driver support M
(Then select the HiSax support)
(You can also choose to make a kernel with build in ISDN support
instead of modules)
Then do a "make dep", "make zImage", "make modules" and "make
modules_install" to build the kernel. The installation of ISDN and PPP is
explained somewhere else in this FAQ. We now continue with the following
assumptions:
* The ISDN system is operational; you can build a connection to your ISP.
* The LAN is operational (i.e. Ethernet or Arcnet) and IP addresses
have been assigned (i.e. 192.168.xx.xx). The Linux box can be reached by
the other computers (i.e. by ping).
Now we need to accomplish two things:
* A computer in the LAN with a "non-local" IP address will request the
Linux router to establish a connection to the provider
* The Linux router itself will connect the computers in the LAN to the
provider. It will also "hide" the computers in the LAN from the ISP, and
all the IP packets will appear to come from or go to the router. While in
fact the are coming from the computers in the LAN.
We'll start with the second one: This hiding doesn't mean we're trying
to cheat our provider. (Although it is possible to provide "clients" with
a cheap connection to the Internet). It is required technically. Only the
IP address of the Linux box is known to the provider. So the Linux box must
"mask" all the packet with it's own IP address and keep track of which
computer in the LAN sent which packet so the it can return the
incoming packets to the correct computer in the LAN. Luckily this
function is built in kernels>=2.0.0 and is called "IP-Masquerading". Here's
how it works:
A computer on the LAN sends a packet that contains (next to the IP address
and target port of the receiver) it's own sender address (in IP form) and
an answering port. The masquerading Linux router will replace this address
with it's own and the answering port with a free one. Under this free port
the sender address is stored. Now when a packet comes in from the Internet
the receiver address and port gets overwritten with the return address and
port and the packet is send to the correct computer in the LAN. Packet for
packet. This only works if the application sends along a return address,
telnet, http, (irc, tcp differently) all do this (ping doesn't work).
To get TCP and IRC to work while masquerading 2 modules need to be loaded:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b
The way I see it, that doesn't matter, the computers in the LAN will
continue to communicate over the fake IP addresses. You can test this by
turning off your Linux box (shutdown). Nothing will happen. This is because
masquerading is a forwarding rule in the firewall and will only be used
when forwarding (literally "passing on"). On the LAN nothing is forwarded
so nothing is masqueraded, unless you have multiple Ethernet cards in one
computer then you need to enter some extra firewall rules.
#!/usr/bin/perl
select((select(STDOUT), $| = 1)[$[]);
select((select(STDIN), $| = 1)[$[]);
exec "cu","-E","''", "-l", "$ARGV[0]";
die "$0: Cannot exec cu: $!\n";
modem 20006/tcp modemd # Modem service via TCP
isdn 20007/tcp modemd # ISDN service via TCP
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.
B 3 -- RX+ 2a ---------------\
U 4 -- TX+ 1a -- open ------------
S 5 -- TX- 1b -- open ------------ card
6 -- RX- 2b ---------------/
#!/bin/bash
#ISDNBUTTON: Disconnect ISDN
/sbin/isdnctrl list isdn0 | grep Outgoing | grep -q 0251XYZ &&
/sbin/isdnctrl delphone isdn0 out 0251XYZ
/sbin/isdnctrl hangup isdn0
exit 0
#!/bin/bash
#ISDNBUTTON: Connect ISDN
/sbin/isdnctrl list isdn0 | grep Outgoing | grep -q 0251925020 ||
/sbin/isdnctrl addphone isdn0 out 0251925020
exit 0
GREEN - at least one ISDN connection is active. Unfortunately
I'm unable to check how the connection was activated.
It doesn't have to be a network connection, and can
also be an incoming connection (at least for me, it would
be useful to distinguish these).
YELLOW- no active ISDN connection was found, but at least one
ISDN interface has an outgoing telephone number for
demand dialing. There is therefore the "danger" that
a connection will occur automatically.
RED - Neither of the above is true. This usually means that
a) the kernel doesn't recognize ISDN, or the ISDN
subsystem is not active, or
b) the outgoing ISDN connections are deactivated.
(Most of the answers you will find here are taken from the vbox manual by
Matthias Hessler <hessler@wi-inf.uni-essen.de> and
Bernhard Hailer <dl4mhk@lrz.uni-muenchen.de>; you can get the manual at:
http://www.lrz-muenchen.de/~ui161ab/www/isdn/
- click on "Audio!" (still in German we're afraid - sorry...)
cat xxx > /dev/audio
sox <file>.wav -r 8000 <file>.ul rate
rmdcatheader -u <file.ul> > <file>.msg
cat <file>.ul >> <file>.msg
At boot "diald" is configured:
# /etc/rc.d/rc.diald
/usr/sbin/diald /dev/ttyI4 -m ppp \
local 192.168.90.9 remote 192.168.90.1 \
defaultroute dynamic modem crtscts lock connect "chat -v -f \
In /etc/ppp/chat.provider the following entry is made:
TIMEOUT 240 "" AT&E1234 OK ATD047110815 ogin: Puser sword: topsecret
(phone number, name and password are fictional)
I use chargeint, it works great; for me charge units come during the
connections, but I think that can be adjusted by hand. The two patches in
isdnlog-2.50/contrib/chargeint are for the kernel sources and for
isdn4k-utils-2.0; then compile isdn with the -Dchargeint flag (see
Makefile). The kernel and isdnctrl of course also have to be recompiled.
Then start isdnlog with the -hx option, where x is the number of seconds
left until the next charge unit. Then chargeint will hang up. In the
start script for ISDN, define a huptimeout as usual to activate the
chargeint:
/sbin/isdnctrl huptimeout ippp0 80 # in sec;
if needed /sbin/isdnctrl chargeint ippp0
The chargeint always hangs up two seconds before the end of the charge
unit. isdnlog, if compiled with -Dchargeint, sets the length of the
charge unit (i.e. Charge Interval) according to the time of day and the
date. An additional parameter for "-h" will reduce this length of time by
the given value. This additional parameter should not be used with
chargeint, otherwise chargeint will end the connection too early. This
error increases with the number of charge units. Therefore: "-h0" to
avoid this problem.
> /sbin/isdnctrl huptimeout ippp0 80 # in sec;
In this example is can be much short; I use 5 seconds. Then I can use the
last charge unit up the last 7 seconds (huptimeout + 2 seconds
"chargeint reserve").
> /sbin/isdnctrl chargeint ippp0
Not needed; taken care of with by isdnlog with "-h".
1. Apply the patch "isdnlog-2.50/contrib/chargeint/patch-chargeint-2.04"
to the kernel, rebuild the kernel and reboot.
2. Patch isdn4k-utils-2.0 with
"isdnlog-2.50/contrib/chargeint/patch-chargeint-kutils",
make clean; make install
3. In etc/isdnlog/isdnlog.conf" enter the appropriate interface
in column 4 for those partners you wish to add, and double check
that the zone entries are correct.
4. In the "Makefile" for isdnlog, insert "-DCHARGEINT" for "COPTS",
make clean; make install
5. start isdnlog the additional option "-h0", done!
#
# ISDN Lines
#
I0:56:respawn:/usr/local/sbin/mgetty ttyI0
I1:56:respawn:/usr/local/sbin/mgetty ttyI1
port ttyI0
modem-type data
speed 38400
init-chat "" ATZ OK AT&E0 OK AT&B512 OK
i0:45:respawn:/sbin/mgetty -D -m '"" ATZ OK AT&E0 OK AT&B512 OK'
-s 38400 ttyI0
#/AutoPPP/ - ppp /usr/sbin/pppd auth -chap +pap login kdebug 7 debug
<login-name> * ""
* * ""
MSN Analog Digital
=== ====== =======
1 Voice + ISDN answering machine HDLC, PPP
2 Voice (Mother) Net interface
3 Modem/Fax X.75
There seems to be a lot of routers with 1 BRI, those that have more
are expensive (Cisco 4000 with four connection about DM 15000.--,
Ascend Pipeline 400: ?).
ISDN routers with 4xBRI are less expensive from a German
manufacturer - see http://www.conware.de/
A Banzai! might also help. As hardware any PC with (e.g.) Teles
cards would work, the software costs around 800-1000 DM. I
personally don't like Banzai! routers at all because of their
poor diagnostic capabilities, in particular remote maintenance as
pretty much impossible (unless you have the SNMP capable version,
but it costs somewhat more). But when they run, they run stable
and as opposed to Ciscos they are capable of real callback. From
Cisco as an alternative there is the Cisco 2503 for about 5000
DM, that has only one Port, but two serial interfaces, on which
you can connect a TA (each about 800 DM). Finally, last, not
least you can bit the bullet and get several Cisco 1003s
(ca. 2000DM each). In case the price does not play such a bit
role, I would take this variation. I simply like Ciscos. :-)
You need to decide, which is more important to you:
(1) saving money
(2) saving time
For (1) there are two solutions:
- Banzai! (now called Flux or Concorde..)
-> http://www.concorde.de/ (from cls, www.cls.de)
-> http://www.flux.de/ (from INS, www.ins.de).
Based on at least a 386 and routes Ethernet -> ISDN, works with
many cards, the programmers themselves work with Teles.
Disadvantages: not cleanly remotely configurable, unless you
buy the SNMP option, which makes it more expensive and
therefore more unattractive...
- ISPA + PCROUTE
-> http://www.biochem.mpg.de/~heha/
also requires a PC (also works with 286). Has much
fewer options than Banzai, Flux, Concorde etc., and is not at all
remotely configurable, but runs totally stable.
PCROUTE costs nothing, ISPA now costs 70.-, perhaps you can still find
version 2.41 that runs unlimited even without a key.
Both solutions support pretty much all ISDN protocols (including
the diverse HDLC variations etc..). Support for SPVs (soon
obsolete) and D64S is there at least for Teles cards (depends on
the CAPI, not the software). You can get old PCs for <1.000 DM,
the Teles card also doesn't cost much but die Flux, Concorde
software is expensive if you get SNMP as well -> you are then at
2.000.- and you could just as well buy a cisco1003... (2) IF you
don't want to assemble anything yourself, you can take with 4
individual Cisco1003 routers, at around 2300.- and all of your
problems are more or less solved (other than the diverse IOS
bugs...). But CISCO router can't do "correct" callback... and as
protocol only PPP (although there are IOS versions, that don't do
it cleanly) and CISCO-HDLC. If you need 4 BRIs -> CISCO 4000,
but then you should get the 8 BRIs, costs just under 2.000 DM
less. But then you have to invest somewhat more than
10.000.-...:-( Another variation: ELSA LANCOM MPR, also costs <
2.000 DM, can do callback, various protocols (HDLC, X.75, PPP)
and is really nice to configure. At the Interop, a Shiva ISDN
Router with a/b switch for 1600 DM was exhibited, but with 4 BRI
ports you'd be somewhat over 6000 DM... Then there are
several manufacturers that offer simple BRI routers (prices
tending to fall well under 2.000), e.g. ASCEND, MIRO etc... But
if you must have 4 BRIs, there's only the choice between Cisco
and Ascend.. uh... and since you asked about Ascend, I have a
price list here from Ascend (July 96), the max400 WITHOUT BRI
port already costs 15.750.-, the 4-way BRI is then an additional
11.250 DM... I think that's enough about Ascend...:-(
In case you have nothing against a PC solution, you could also
use netGW from netcs (http://www.netcs.com). This is software
for SCO, AIX, Sun etc. and is based on PCs e.g. the cards from
Diehl ISDN. netGW should offer by far the most protocols and
options, but then you have to become familiar with a PC the
problems that come along with it. A SCO solution with 4- ISDN
cards + Software costs also around 10.000 DM, however. We have
now returned almost all of our Banzai! and Co, since in the long
run they are only poorly remotely administrable and are nowhere
near as stable as Cisco or other stand-alone routers... In the
end, it is a decision of you would rather spend more money, and it
runs right away, or you build your own PC router and have to play
to get it going. You have to decide for yourself, although Teles
can drive you to desperation since the CAPI versions often have
huge problems as normal users can't get any older
versions. Support at Teles is not that great (toll 0190-8 phone
number), and you can easily spend 20-30 DM on support call
without getting an solution to your problem...
Cisco is even cheaper than Linux for PRI. Or have you checked what
PRI cards for PCs cost. ;) Then you need the right drivers etc...
Then you'll quickly be well over 20k. You can get a 4000 with PRI
for 12-15kDM. And if you try to it with individual SOs, then it really
gets expensive...
For dialup up to 4 x BRI (which is what fits into one case), Linux
is unbeatable for price/performance. Even a second machine still
makes sense.
But then you need to start thinking about a PRI solution. Both
run stable and with not problems for us.
If you don't want to wait for Karsten's patch, you can try the
so-called isachscx driver. It can be found at
http://www.sfs.nphil.uni-tuebingen.de/~hipp/isdn/isachscx.c.gz
The driver is derived from the i4l Teles driver, but doesn't need
the i4l link level. A desire to experiment is required to try
this driver.
That surely works. We have it working here. It's also stable
(kernel >2.0.26 is necessary, otherwise the router might come
to a halt). Only, if you pull out the plug to the terminal
adapter and insert it again, or if the Telekom produces an error,
then you have to have both sides hang up once (or twice) to
bring the connection backup. In emergency you have a "ping"
and a "isdnctrl hangup" done with cron. I don't know of any
other docs or source code, but I'd be happy to help with any
further questions, since other helped me before
There are several things to watch out for. LEASEDx is the
incoming number on the device; an outgoing number is not
necessary, since the kernel (or the firmware, I'm not sure)
generates pseudo-incoming calls, as long as no one has "picked
up". In LEASED x, the small "x" should be replaced by the
number of the SO interface.
In each of our routers we have four interfaces (numbered as
0, 1, 2, 3), and I used the last interface as the LEASED line.
That makes sense, since the other three interfaces are used for
6 B channels for dialup lines, and the kernel always uses the
first free line for outgoing calls. If the leased line were on
interface 0, then the second B channel of the leased line would
appear (but only appear) to be free. The kernel doesn't notice
(because of the active card) that there is no D channel for
dialing there, and will dial, and dial, and dial.
For this reason, I've created an extra ISDN network interface
and have bound it exclusively to the apparent B channel of the
leased line, so that after 6 dialout lines are in use the
kernel attempt to dial out on the leased line.
Another important stumbling block is that the first pseudo-
incoming call must be answered (otherwise only the third, then
the fifth will work, I don't know exactly why, but I suspect
it's caused by the two B channels, for which calls are generated
in turn, while a D64 has only one B channel).
The immediate acceptance of the call is setup as follows:
* Load the module for the ICN card and configure (load the firmware,
bus reject, ...) BUT NOT YET icnctrl -d XXX leased"
* Generate the network interface for the kernel with innumber LEASEDx
and all the other stuff you need (IP address, ...).
Don't forget to bind to the appropriate S0 interface.
* NOW: icnctrl -d XXX leased
The network interface has to already be up when "icnctrl -d XXX leased"
is called. Then this command starts the first call and can then be
immediately answered - and pop, the connection is made.
Yes, you can (at least in Switzerland). You have to make sure you are
on the correct channel ;)
TIMER_BCREAD = Intervall für B-Kanal-Poll (unit = jiffies = 20ms)
TIMER_DCREAD = Intervall für D-Kanal-Poll ditto
FLAG_RBTIMER (and other FLAG_...) call the appropriate functions from the
main time dispatcher.
Because of the ping times, I've reduced BCREAD, (was 3 before)
[since 2.0.16 at 1, Ed.]
The resolution of the timer in Linux is only 20ms, so
ICN_TIMER_BCREAD=0 does nothing. In addition, this is only a
cosmetic problem. Both (sending and receiving) routines empty the
queue. i.e. when there is real traffic, in each cycle is not only
just one fragment sent, but up to 16. The card buffer contains 16
fragments. Only with ping and Co. is this visible. FTP (or also
Z-Modem over ttyI) can do close to 8k cps without problem. In
addition, in each cycle both directions are served, so the
calculation 20ms-receive + 20ms-send is therefore incorrect. Even
not considering this, 40ms is a really good value. Many ISDN
routers (also i4l before the reduction to BCREAD=1) have 60ms and
more.
Due to a couple of lawsuits against the Telekom before the
European Court of Justice, most likely until the end of
1997. This will be posted in the appropriate newsgroups
and probably also at http://www.birch.de
(who is suing).
isdnctrl addif <master interface>
isdnctrl addslave <master interface> <slave interface>
1st: There seems to have been a change in the "BogoCharsPerSecond"
calculations. This now gives values (for me) from 60 ->101.
The values used by the isdn-net code for starting the slaves is
still set to 7000 cps! Needless to say it doesn't see these
values anymore. After setting it to 75, I get the channels
starting again.
2nd: With 1 B-channel, I get 8K /sec (full)
With 2 B-Channels, I get ~14K /sec (~88 % util.)
With 3 B-Channels, I get ~18K /sec (~75 % util.)
With 4 B-Channels, I get ~15K /sec (~50 % util.)
isdnctrl addlink <device>
isdnctrl addlink ippp0
...
rcvd [0][proto=0x3d] c0 00 00 00 80 fd 01 01 00 0a
...
sent [0][LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01
...
I found a typo in kernel 2.0.20, that also exists in newer kernels.
If you replace the following line in isdn_ppp.c (function
isdn_timer_funct()):
#if (defined CONFIG_ISDN_PPP ) && (defined ISDN_CONFIG_MPP)
with
#if (defined CONFIG_ISDN_PPP) && (defined CONFIG_ISDN_MPP)
then MPP connection has a better chance.
Without this change, MPP will hang when just one packet is lost.
1. First, check everything is working when booting.
Are there unusual error messages in /var/log/messages?
Are all programs active that should be started at boot (check with
ps, or fuser /dev/xxx)? HiSax won't start if something isn't right.
The old Teles driver, on the other hand, will appear to start even if
it is not working. See the questions under Troubleshooting Teles.
2. Second, try calling with a telephone. The number should be shown in
/var/log/messages. Otherwise, perhaps the driver was incorrectly
started?!
3. Third, continue experimenting using modem emulation. Because of the
differently service recognition, you can't get the telephone or fax to
ring, so we have to try something else. 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).
4. Fourth, 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"
5. 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*).
ln -s /usr/include/curses.h /usr/include/ncurses.h
I haven't yet seen a newer distribution (neither Slackware
nor Debian) that contains a complete ncurses package.
/usr/include/ncurses.h is there - sometimes it's called curses.h,
but the include file panel.h must come from an original
ncurses package.
With Debian you need to install not only ncurses nut also ncurses-dev
if you want to compile anything with it.
bash$ dpkg -S panel.h
ncurses3.0-dev: /usr/include/panel.h
| | | |
| | | |
1 2 3 4
As I don't have a patch at hand I'll explain it this way: search for
CC_ALERTING_REQ in linux/drivers/isdn/teles/callc.c and comment out that
line. It should look like:
if (((chanp->chan & 1) + 1) & chanp->para.bchannel) { /* \
chanp->is.l4.l4l3(&chanp->is, CC_ALERTING_REQ, NULL); */
FsmChangeState(fi, ST_IN);
if (chanp->debug & 1)
That's the clean solution. For data connections there is no ALERT required
or expected. Voice applications only need ALERT when the want to wait for
several rings.
There is no alerting any more [in older HiSax versions - Ed.]
In some cases the Telekom activated the charge impulses only for some
services. It seems they have to activate it separately for each service
(voice, data, G4-fax,...).
I think I found the reason why the Ascotel PBX crashes linux. It's not an
overly big "FACILITY" frame (as I wrote earlier) but a frame of an unknown
protocol (0x44, while EDSS1=0x08 and DIS_N0=0x40, DIS_N1=0x41).
[...]
Jan den Ouden made a patch for it that ignores such frames. Yes, I *did*
try that patch... but I must have made some silly mistake (did not load
modules properly?) or there was another reason for the crash. I don't know
what to do any more :-( I just tested 2.0.18 and tried to do a hexdump
instead of interpreting it - and now the machine doesn't crash any more.
And now I've tried to use 2.0.20 and it did not crash. *shrug*,
confusion...
Whatever the causes the crash, remember that Jan's patch should be
included with the standard driver. It's not a good idea that frames that
are not 1TR6 are interpreted as EDSS1 by default.
Remark: the patch mentioned here has a bug: X.75 won't work anymore.
1. unplug the PBX
2. turn off the PC
3. plug in the PBX
4. turn on the PC
Cause 64 means "invalid information element contents" and is from the
12TR7 protocol that some PBX (in our case Octopus-M) use internally.
12TR7 includes 1TR6. I don't know more about it. My source was a nice
guy from the Telekom. They have "Richtlinien" (guidelines) that describe
the protocols.
diff isdnctrl.c.dist isdnctrl.c
240c240
< if (strlen(cfg.slave))
---
> if (cfg.slave && strlen(cfg.slave))
#define HSCX_RBUF_ORDER 1
#define HSCX_RBUF_BPPS 2
#define HSCX_RBUF_MAXPAGES 3
(4096<<HSCX_RBUF_ORDER)/HSCX_RBUF_BPPS
I had the same error until using the correct netmask.
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
Best is you check that the interrupt is registered correctly. Check it
with "cat /proc/interrupts". The following entry indicates an error:
11: 0 + teles
The 11 is correct when the Teles card is configured on interrupt 11.
However, the 0 means that the Teles card does not accept interrupts, so it
does not work. That's the well known "busy bug". Often it can be worked
around by loading, unloading, and reloading the ISDN modules on bootup.
The IRQ counter does have to be 0; low values also point to the same
problem. You can test for it quite easily:
1. cat /proc/interrupts, note the count
2. Call the card with a telephone.
3. Again cat /proc/interrupts, the count should be quite
different from the first value.
On PCI boards never use IRQ 12. It is often used by the bus mouse (even
though you may not have any or the IRQ is not activated for it), which is
why that IRQ often is lost and you will get errors trying to use it.
On PCI boards never use IRQ 15. It is often used by IDE 2 (even when you
are not using it or the IRQ is not activated for it), which is why that
IRQ often is lost and you will get errors trying to use it.
Instead of a "reboot" command or pressing "Ctrl-Alt-Del"
try a "Hard Reset" with the reset button.
With some motherboards (which is not necessarily the motherboard's
fault) the cards are not completely reset with a "Soft Reset" so that
some drivers will have problems finding the cards.
l1state 4
l1state 8
l1state 13
ph_command 9
l1state 4
l1state 0
ph_command 0
l1state 7
ph_command 9
Clear case of IRQ problems. Especially the 11 gives trouble on some
boards. 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. That even works on very exotic boards.
#ifndef PROTO_H
#define PROTO_H
#define PROTO_EURO 0x08
#define PROTO_DIS_N0 0x40
#define PROTO_DIS_N1 0x41
#endif
HiSax: Teles 16.3 found,irq:5 isac:a80 cfg:e80
HiSax: hscx A:280 hscx B:680
Teles3: HSCX version A: V2.1 B: V2.1
<date> <time> foo kernel: HSCX B EXIR 10
<date> <time> last message repeated <n> times
A few weeks ago I reported on my problems connecting to a EL 310.
No connect message came for the data channel from ISDN. The
Elink was connected to 1TR6 and had identical settings to another
Elink on Euro-ISDN, with which I've never had problems. But now
for the past 2 weeks everything suddenly works fine, without
having changed anything locally.
Conclusion: The software at the switching station seems to play
a role...
{ PPP_CCP, ccp_init, ccp_input, ccp_protrej,
ccp_printpkt, ccp_datainput, "CCP" }
More information can be found in the "Configuration" section under this same title!
Especially the first packets of the protocol can be lost when they are
fired out onto the B-channel immediately after the connect message.
I had a problem with raw HDLC: it lost packets, but only when dialing from
one side to the other.
It may be a problem with your ISDN cable...
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 normal modem).
Watch out for processes that (with "ps -ax") have something like "I0" or
"I1" in the second column, they have an ISDN terminal as their controlling
terminal. You may have to kill them with kill.
I had to use the following settings, otherwise I only had errors.
# Prot
protocol-parameter g packet-size 512
protocol-parameter g short-packets y
protocol-parameter g window 7
protocol-parameter g remote-window 7
protocol-parameter v packet-size 512
Now with large packets I can get ca 7300 cps.
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
protocol-parameter g remote-packet-size 0
As I said, it works fine..
#define DATA_VERSION 1
#define DATA_VERSION 2
daemon.* /var/log/ppp-log
Remove the comment sign in front of this line in /etc/syslog.conf:
#*.=debug /tmp/debug
After changing this file you can restart syslogd with "kill -1 <pid of
syslogd>".
The output in /tmp/debug can be used to optimize the handshaking of
PPP options.
I had the same thing! (S.u.S.E. 4.2 Kernel 2.0.0, isdn4k-utils 3.91 with
patch). After recompiling the kernel and configuring PPP as module I could
start ipppd. Looks like version problems.
(The following questions are from the sync PPP FAQ.)
isdnctrl addif ippp0
isdnctrl encap ippp0 syncppp
... (see i4l documentation for more information) ...
In 1.2.13 you tell the kernel *not* to include PPP support, then compile
the kernel, *after that* do a 'make modules' and a 'make modules_install'.
This way everything that's not compiled into the kernel, but that can be
loaded as modules is prepared for loading via insmod. 'modprobe ppp' on
bootup (in the rc.xxx script) will load the PPP module and all
additionally needed modules (slhc etc).
Prerequisite for ipppd with 1.2.13: install PPP version 2.2.0c. Also in
the kernel sources (ppp-2.2.0c.tar.gz). And you need modutils 1.2.8
(modules-1.2.8.tar.gz).
I had the same problem. Interestingly, after about 5 minutes with
several of those messages the ipppd said "started". And then it
worked! Well, I included several test prints into the ipppd
source and located the problem: The ipppd calculates a random
number on startup (forgot where) and uses gethostid() for
that. That causes a DNS lookup. Then linux tries to find the
nameserver mentioned in /etc/resolv.conf. As ipppd isn't up it
can't reach the name server, which gives those messages. The
solution was easy: I not only included my computer in /etc/hosts
with its short name (e.g. isdn), but also its full name
including the domain in /etc/resolv.conf:
x.x.x.x isdn isdn.who.knows.where
Then it stopped complaining and just runs! Even earlier there is
a call from main() to setipdefault(), which (in options.c) calls
gethostbyname(). This also causes a DNS lookup and the message
"isdn_ppp_bind: Can't find usable ippp device". So two lines in
the source have to be changed to avoid the DNS lookup. It's
easier to include your own name in /etc/hosts, I used the IP
address of my Ethernet card.
There were some changes in patch-2.0.16 that could have caused the
problem. You can try the unoffical patch from ftp.gwdg.de
/pub/misc/isdn/linux/ippp/isdn.dif... until it is included in the official
patch.
My ipppd (from my Suse distribution) was broken. The packet i4l-43b2.tar
from ftp://ftp.suse.de/ helped me.
(The following question was taken from the syncPPP FAQ)
- a few "LCP-conf-req SENT" messages (less than ten) and then a
"TERM-REF":
-> check whether the ISDN card was configured properly. It seems the
computer doesn't dial (IRQ, IO, protocol wrong?)
- at least a few "RECV" messages
-> good: the card is dialing and the and your dialin computer tries
to communicate. Maybe the authentication doesn't work. Check the
ipppd configuration!
- the message that ipppd was exited for some reason
-> not so good... Check /var/log/messages and /var/adm/daemon.
Could be a bug in ipppd.
Please downgrade to 2.0.14... In later version (since 2.0.16) there is a
little bug which causes ipppd to exit if it can't get a connection.
(Should not be a problem once you get a connection.) A "quick and dirty
hack" is possible by removing some lines in ipppd, but better stay with
2.0.14 until the bugfix finds its way into the new kernels.
#!/bin/sh
/sbin/route add default ippp*
/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
XXX YYY ZZZ
* * ZZZ
I had exactly the same problem/the same error message. The cause for it
was that I had three entries in chap-secrets/pap-secrets (for client,
server, secret), but not a fourth one (IP addresses). BUT: after the third
entry were some BLANKs. After removing the trailing BLANKs and/or TABs
(i)pppd is now very satisfied with my auth-files.
My PAP script was broken because I had a "#" in my password!
After I had quoted the password cleanly (e.g. with quotation
marks), the problem was solved.
We are an ISP here in Dresden and use Linux (among other systems)
for our access (with I4L as well as with external terminal adapters).
We have this problem mostly with Windows 95 and NT customers who
are using the "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 suspect a bug in MS-PPP).
The following workaround usually works for us: (it's not a cure,
but helps to reduce the pain...)
* Reduce the Max MTU to 576 or even (296)
* Reduce the DefaultRcvWindow to 2144
On the Windows 95 side these are 2 Registry entries; on the Linux
side you can set "mtu 576" and "mru 576" in the PPP options.
(see also http://www.windows95.com/connect/trouble.html)
For me, neither PPP compression option nor mru/mtu 296 helped.
What did help was the AT command:
AT&B512
that limits the sent packets to 512 bytes.
mtu 1024
Yesterday I got a permanent IP address and since then the automatic dial-
out via ipppd works beautifully. The same goes for the serial interface
with asyncPPP over V.120 and diald (per ELSA Microlink ISDN/TLpro ---
also over the V.34 modem). I had the same symptoms there in the past.
Summary: When using automatic (!) dialout you definitely need a permanent
IP address. If you start and end your connection manually (!) then you can
live with dynamic address allocation.
It surely is time to extend PPP's functionality to not only hold outgoing
packets that initiate a connection, but also correct the IP address to the
new address before sending it out. The same goes for other packets that
arrive before the connection is up.
Also diald has to get that functionality to control when the connection
goes up or down.
1) No local name server/name server cache
2) Local squid proxy WWW server (and Netscape must use it).
3) set positive_dns_ttl to 1 in /usr/local/squid/etc/squid.conf
so squid doesn't cache IP addresses
Now the connection will always start with a DNS lookup,
which is immune to IP address changes (because it runs on
UDP and not TCP?). If you have other programs that cache
IP addresses, you'll have to figure you how to get around
them. Normally a program caches an IP address when it
has to connect twice to the same server. That isn't a
problem, of course, when the second connection occurs so
quickly after the first that the dial-on-demand connection
is still the same.
*** 1.14 1996/06/06 22:08:46
--- isdnctrl.c 1996/09/04 19:13:39
***************
*** 498,504 ****
}
printf("MSN/EAZ-mapping for %s:\n%s\n",argv[2],nstring);
} else {
! iocts.arg = (unsigned long)argv[3];
if ((result=ioctl(fd,IIOCSETMAP,&iocts))<0) {
perror(argv[2]);
exit(-1);
--- 498,506 ----
}
printf("MSN/EAZ-mapping for %s:\n%s\n",argv[2],nstring);
} else {
! char buf[400];
! strncpy(buf, argv[3], sizeof(buf)-1);
! iocts.arg = (unsigned long)buf;
if ((result=ioctl(fd,IIOCSETMAP,&iocts))<0) {
perror(argv[2]);
(The following question was taken from the syncPPP FAQ)
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.)
Rainer May <r_may@khavi.desaster.heide.de> has put together questions and answers on "i4l and Masquerading:
* Is the Linux computer entered as the gateway? (Some 'operating systems'
have to be restarted before changes to the networking take effect)?
* 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")
* 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
I've noticed that after the first connection via ippp0 that the local
network can again be reached. Then the address 0.0.0.0 is no longer
listed in ifconfig for ippp0, but instead the address assigned from
the pool by the PPP partner.
This was already discussed in de.comp.os.linux.networking, along
this possible solution:
Simply set ippp0 to a dummy IP number from the pool. Then the
local network will have problems after booting, even with the
default route, and the IP number in ifconfig will be overwritten
anyway.
Is one of the "usual messages":
"(HiSax driver detected)"?
If not:
- have you started version 2.52 - not just compiled?
- have you remembered "telesctrl <DriverID> 1 4" ?
- ISDN connections are working otherwise?
If so: Contact me (isdnlog@Kool.f.EUnet.de) with the
appropriate log files (created with "isdnlog -v7").
My problem with isdnlog 2.50 and "wrong structure error" was caused
only by leaving out the leading zero.
Example:
017201234567 Handy 1 -
Previously I had it so:
*17201234567 Handy 1 -
This seems to have fixed everything.
For me, isdnlog crashed because it was not entered in /etc/services
#!/bin/sh
/usr/local/bin/play anruf.au 2>/dev/null
(The following question and answer is from Andreas Kool <akool@Kool.f.EUnet.de>)
- right when starting isdnlog or isdnrep:
Here the 2 programs have choked trying to read "isdnlog.conf"
Solutions:
- never use blanks in the alias column!
(e.g.: "My MSN")
- never use "#" in the alias column!
(e.g.: "MSN#3")
- never use "\" in the alias column!
(e.g.: "MSN\#3") (Thank you, Holger Wirtz <chick@midips.snafu.de>)
- never use "*" as the entry in the flags column!
(Thank you, Werner Wiethege <ww@slarti.frankfurt.netsurf.de>)
- the "START=" line requires an entry indicated _when_ it is to be started
for example
START=IOH=auplay hangup.au
and _not_
START=auplay hangup.au
(Thank you, Dirk Staneker <zxmjy04@student.uni-tuebingen.de>)
- when using the "-S" option to start external programs.
Here isdnlog ran into the code the X11 client "xisdn"
and started looping in itself, leaving behind zombies - this was fixed
in isdnlog-2.50.
I recently had the same effect when I mistakenly started isdnlog twice
In the meantime I've patched isdnlog. The problem is the
strftime() call in line 264 of isdnlog.c. There the "%e"
should be replaced with a "%d", then everything works again.
/sbin/route del default
/sbin/isdnctrl system off
/sbin/ifconfig ippp0 down
/sbin/isdnctrl system on
/sbin/ifconfig ippp0 up
/sbin/route add $GATE-IP dev ippp0
/sbin/route add default ippp0
Unfortunately, I don't know of any syncPPP encapsulation patch for
tcpdump. If you use ipppd, then your only chance is to turn off
one daemon after the other and see if things have finally quieted
down. Likely candidates are named, sendmail, and also smbd (Samba)
that are likely to open connections.
I too was only able to find this out by killing suspicious processes.
More information on the search for these processes and how to make
them quit can be found at:
http://www.fzi.de/sim/people/trautw/i4l/index.html
Try to find out which lookup triggers the connection with
"isdnctrl verbose 3". Then a message should appear in
the kernel message queue (visible with "dmesg") a'la:
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).
Another tip. There are a lot of daemons on the Linux side that
broadcasts on all interfaces. This leads to frequent autodials.
In this case you can redirected the broadcast address to the
dummy0 interface. It's not clean, but it works.
Whin in Wintel the name server of your provider is given, and
Windows 3.11/95 is started, then it has to talk to the name
server (only Bill Gates knows why).
Why not simply set the "Use DNS for Windows Names Resolution"
(or similar) to No? Then it should be quiet, at least it
is for me.
nmdb -S -B 192.168.99.255 -I 192.168.99.99
Unfortunately reality has caught up with us. I've heard that
Netscape now in version.4.02 really does establish a
connection...
If the Cisco doesn't get an answer for its keep alive packets then it will
stop routing! That normally happens after the 4. or 5. keep alive packet.
The best solution is to tell the provider not to use keep alive packets
("no keepalive" in the Cisco configuration).
There is NO REASON to use keep alive packets, especially between two Cisco
routers and on leased lines.
LCP messages are considered traffic and keep the line open. There was a
little patch for kernel 2.0.21 in relation with the patch chargeint-2.04
for isdnlog-2.50. This patch ignores *all* syncPPP LCP data for the
calculation of the hangup timer, so hangup works even with LCP-echo-
requests.
Warning: The code works for *me* and my provider. I don't know if it will
work for *you*. Just try it!
After some experimenting, I found a solution on the Cisco
(IOS 11.0.7), that's called "snapshot routing". I configured
"snapshot server" on the BRI interface. That means it will
send out routing updates only when they are received through
this interface.
In the module isdn_net.c (line 1720) there is a comment "/* if this
interface is dialing, it does it probably on a different device, so free
this device */" and function isdn_free_channel is called.
[...]
It looks now like this:
#ifdef CONFIG_ISDN_PPP
if (p->local.p_encap == ISDN_NET_ENCAP_SYNCPPP)
ippp_table[lp->ppp_minor]->state = IPPP_OPEN;
#endif
> ... I've looked through the code an found
> a possible error triggered by incoming calls.
> Is this the case for your scenario? If so,
> try removing: (isdn_net.c, around line 1730)
> p->local.pppbind = -1;
> in the function isdn_net_find_icall().
I took out this line and now it works.
(The following question was taken from the syncPPP FAQ)
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 callback. Username and password always have to
be exchanged before the callback is allowed when using PPP, to be sure
that the person requesting callback is allowed to do so. (Cisco seems to
obey the rules of the [German] Telekom that no information are to be ex-
changed without a B-channel connection. A callback request just by caller
id could in doubt be considered as a transmission of information).
isdnctrl callback isdn0 in
isdnctrl cbdelay isdn0 1
telesctrl <id> 3 1 ---> dec module_count
telesctrl <id> 4 1 ---> inc module_count
At first about your bug: the other side does not like the MP-MRU (0x5dc)
but wants a smaller one (0x5d7) ... which is what ipppd doesn't like (bug)
... Just try 0x5d7 as MP-MRU.
Without a MP-MRU agreed about MPPP won't switch on .. which is why it is
not working.
EAZ 0: global call (all telephones ring)
EAZ 9: global call (no telephone rings)
[Translator's note: The original FAQ seems to have the wrong paragraph here. Paolo Sommaruga <psomma@portcros.garda-access.com> wrote on 7 May 1997:isdn4linux also works in Italy (ICN card). I accept Internet connections from my customers with X.75 and asyncPPP. I would like to migrate to synchronous PPP. For the FAQ, here is a problem that I found with Italian lines.
The MSN must be the phone number with the Italian area code but without the leading 0. For example, if my phone number is 72004681 and my area code is 045, my MSN is 4572004681.
Now with the setting AT&E4572004681 isdn4linux works fine. ]
* Modem emulation:
"AT&e123456789" (without leading zero)
* Network interfaces:
"isdnctrl eaz <interface> 123456789" (without leading zero)
For test calls to yourself:
"isdnctrl addphone <interface> in 123456789" (without leading zero)
"isdnctrl addphone <interface> out 0123456789" (with leading zero)
In Austria you always have to use "0" as the ingoing EAZ/MSN for the
first (or only). Any further MSNs can be set normally.
Ian James
Customer Service Manager
SpellCaster Telecommunications Inc.
73 Laird Drive, Suite 206
Toronto, Ontario
Canada M4G 3T4
Phone: 1 (800) 238-0547
Fax: (416) 425-0854
E-mail: ipj@spellcast.com or sales@spellcast.com
http://www.spellcast.com
http://www.siemens.de/, there are a lot of PDF files available.
If a CD-ROM is ok: Technical Product Information for Siemens
Semiconductors, order# B192-H6641-X5-X-7400
Siemens AG, Semiconductor Group, Balanstr. 73, Pf. 801709, D-81617
Muenchen, Fax 089-4144-3952.
From the Siemens handbook:
Place your order at:
Siemens AG
LZF Semiconductor Book Shop
Postfach 2352
90713 Fuerth-Bislohe
Tel (0911)3001-220/224
Fax (0911)3001-238
Price groups (1994)
I DM 5.-
II DM 10.-
III DM 20.-
IV DM 30.-
ISAC S PEB 2085; PEB 2086 ISDN Subscriber Access Controller
Order# B115-H6485-G1-X-7600, 328 pages price category IV
HSCX - High Level Serial Communication Controller Extended
Order# B115-H6520-G1-X-7600, 140 pages price category III
or as CD-ROM
Technical Product Information for Communication ICs (Edition 1, Jun 95)
Order# B193-H6905-X-X-7400, price ?
O'Reilly catalog 1997 (brand new from the book fair): "book
dealers report to us that some books are so strongly associated
with animals that many clients won't ask for the normal title,
but just for the (i.e.) 'camel book' (Programming Perl)."
Title: sendmail (3rd edition 9/94)
Author: Costales, Allman, Rickert
ISBN: 1-56592-056-2
Costs: 66.-- DM
More on:
http://www.ora.com/catalog/sendmail/noframes.html
http://www.lob.de/