OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /or1k/tags/before_ORP/uclinux/uClinux-2.0.x/Documentation/isdn
    from Rev 901 to Rev 1765
    ↔ Reverse comparison
  •

Rev 901 → Rev 1765

/INTERFACE
0,0 → 1,659
$Id: INTERFACE,v 1.1.1.1 2001-09-10 07:44:09 simons Exp $
 
Description of the Interface between Linklevel and Hardwarelevel
of isdn4linux:
 
 
The Communication between Linklevel (LL) and Hardwarelevel (HL)
is based on the struct isdn_if (defined in isdnif.h).
 
An HL-driver can register itself at LL by calling the function
register_isdn() with a pointer to that struct. Prior to that, it has
to preset some of the fields of isdn_if. The LL sets the rest of
the fields. All further communication is done via callbacks using
the function-pointers defined in isdn_if.
 
Changes/Version numbering:
 
During development of the ISDN subsystem, several changes have been
made to the interface. Before it went into kernel, the package
had a unique version number. The last version, distributed separately
was 0.7.4. When the subsystem went into kernel, every functional unit
got a separate version number. These numbers are shown at initialization,
separated by slashes:
 
c.c/t.t/n.n/p.p/a.a
 
where
 
c.c is the revision of the common code.
t.t is the revision of the tty related code.
n.n is the revision of the network related code.
p.p is the revision of the ppp related code.
a.a is the revision of the audio related code.
 
Changes in this document are marked with '***CHANGEx' where x representing
the version number. If that number starts with 0, it refers to the old,
separately distributed package. If it starts with one of the letters
above, it refers to the revision of the corresponding module.
 
1. Description of the fields of isdn_if:
 
int channels;
 
This field has to be set by the HL-driver to the number of channels
supported prior to calling register_isdn(). Upon return of the call,
the LL puts an id there, which has to be used by the HL-driver when
invoking the other callbacks.
 
int maxbufsize;
 
***CHANGE0.6: New since this version.
 
Also to be preset by the HL-driver. With this value the HL-driver
tells to the LL the maximum size of a data-packet it will accept.
 
unsigned long features;
 
To be preset by the HL-driver. Using this field, the HL-driver
announces the features supported. At the moment this is limited to
report the supported layer2 and layer3-protocols. For setting this
field the constants ISDN_FEATURE..., declared in isdnif.h have to be
used.
 
***CHANGE0.7.1: The line type (1TR6, EDSS1) has to be set.
 
unsigned short hl_hdrlen;
 
***CHANGED.7.4: New field.
 
To be preset by the HL-driver, if it supports sk_buff's. The driver
should put here the amount of additional space needed in sk-buff's for
its internal purposes. Drivers not supporting sk_buff's should put
initialize this field to 0.
 
void (*rcvcallb)(int, int, u_char*, int);
 
***CHANGEc1.14: Declared obsolete. Do NOT use this field/function
anymore, since it will be removed when all current
LL drivers have been changed accordingly. Use
rcvcallb_skb instead.
 
This field will be set by LL. The HL-driver delivers received data-
packets by calling this function.
 
Parameter:
int driver-Id
int Channel-number locally to the driver. (starting with 0)
u_char Pointer to received data. (in kernel-space)
int length of data-packet.
 
void (*rcvcallb_skb)(int, int, struct sk_buff *)
 
***CHANGED.7.4: New field.
 
This field will be set by LL. The HL-driver delivers received data-
packets by calling this function. Upon calling, the HL-driver must
already have its private data pulled off the head of the sk_buff.
 
Parameter:
int driver-Id
int Channel-number locally to the driver. (starting with 0)
struct sk_buff * Pointer to sk_buff, containing received data.
 
int (*statcallb)(isdn_ctrl*);
 
This field will be set by LL. This function has to be called by the
HL-driver for signaling status-changes or other events to the LL.
 
Parameter:
isdn_ctrl*
 
The struct isdn_ctrl also defined in isdn_if. The exact meanings of its
fields are described together with the descriptions of the possible
events. Here is only a short description of the fields:
 
driver = driver Id.
command = event-type. (one of the constants ISDN_STAT_...)
arg = depends on event-type.
num = depends on event-type.
 
Returnvalue:
0 on success, else -1
 
int (*command)(isdn_ctrl*);
 
This field has to be preset by the HL-driver. It points to a function,
to be called by LL to perform functions like dialing, B-channel
setup, etc. The exact meaning of the parameters is described with the
descriptions of the possible commands.
 
Parameter:
isdn_ctrl*
driver = driver-Id
command = command to perform. (one of the constants ISDN_CMD_...)
arg = depends on command.
num = depends on command.
Returnvalue:
>=0 on success, else error-code (-ENODEV etc.)
 
int (*writebuf)(int, int, u_char*, int, int);
 
***CHANGED1.14: Declared obsolete. Do NOT use this field/function
anymore, since it will be removed when all current
LL drivers have been changed accordingly. Set this
field to NULL and use writebuf_skb instead.
 
This field has to be preset by the HL-driver. The given function will
be called by the LL for delivering data to be send via B-Channel.
 
Parameter:
int driver-Id ***CHANGE.7.4: New parameter.
int channel-number locally to the HL-driver. (starts with 0)
u_char* pointer to data.
int length of data-packet.
int flag: 0 = call from within kernel-space. (HL-driver must use
memcpy, may NOT use schedule())
1 = call from user-space. (HL-driver must use
memcpy_fromfs, use of schedule() allowed)
 
Returnvalue:
Length of data accepted on success, else error-code (-EINVAL on
oversized packets etc.)
 
int (*writebuf_skb)(int, int, struct sk_buff *)
 
***CHANGED.7.4: New field.
 
This field has to be preset by the HL-driver. The given function will
be called by the LL for delivering data to be send via B-Channel.
 
Parameter:
int driver-Id ***CHANGE.7.4: New parameter.
int channel-number locally to the HL-driver. (starts with 0)
struct sk_buff * Pointer to sk_buff containing data to be send via
B-channel.
 
Returnvalue:
Length of data accepted on success, else error-code (-EINVAL on
oversized packets etc.)
 
int (*writecmd)(u_char*, int, int, int, int);
 
This field has to be preset by the HL-driver. The given function will be
called to perform write-requests on /dev/isdnctrl (i.e. sending commands
to the card) The data-format is hardware-specific. This function is
intended for debugging only. It is not necessary for normal operation
and never will be called by the tty-emulation- or network-code. If
this function is not supported, the driver has to set NULL here.
 
Parameter:
u_char* pointer to data.
int length of data.
int flag: 0 = call from within kernel-space. (HL-driver must use
memcpy, may NOT use schedule())
1 = call from user-space. (HL-driver must use
memcpy_fromfs, use of schedule() allowed)
int driver-Id.
int channel-number locally to the HL-driver. (starts with 0)
 
***CHANGED1.14: The driver-Id and channel-number are new since this revision.
 
Returnvalue:
Length of data accepted on success, else error-code (-EINVAL etc.)
 
int (*readstat)(u_char*, int, int, int, int);
 
This field has to be preset by the HL-driver. The given function will be
called to perform read-requests on /dev/isdnctrl (i.e. reading replies
from the card) The data-format is hardware-specific. This function is
intended for debugging only. It is not necessary for normal operation
and never will be called by the tty-emulation- or network-code. If
this function is not supported, the driver has to set NULL here.
 
Parameter:
u_char* pointer to data.
int length of data.
int flag: 0 = call from within kernel-space. (HL-driver must use
memcpy, may NOT use schedule())
1 = call from user-space. (HL-driver must use
memcpy_fromfs, use of schedule() allowed)
int driver-Id.
int channel-number locally to the HL-driver. (starts with 0)
 
***CHANGED1.14: The driver-Id and channel-number are new since this revision.
 
Returnvalue:
Length of data on success, else error-code (-EINVAL etc.)
 
char id[20];
***CHANGE0.7: New since this version.
 
This string has to be preset by the HL-driver. Its purpose is for
identification of the driver by the user. Eg.: it is shown in the
status-info of /dev/isdninfo. Furthermore it is used as Id for binding
net-interfaces to a specific channel. If a string of length zero is
given, upon return, isdn4linux will replace it by a generic name. (line0,
line1 etc.) It is recommended to make this string configurable during
module-load-time. (copy a global variable to this string.) For doing that,
modules 1.2.8 or newer are necessary.
 
2. Description of the commands, a HL-driver has to support:
 
All commands will be performed by calling the function command() described
above from within the LL. The field command of the struct-parameter will
contain the desired command, the field driver always is set to the
appropriate driver-Id.
 
Until now, the following commands are defined:
 
***CHANGED1.34: The parameter "num" has been replaced by a union "para" containing
the old "num" and a new setup_type struct used for ISDN_CMD_DIAL
and ISDN_STAT_ICALL callback.
 
ISDN_CMD_IOCTL:
 
This command is intended for performing ioctl-calls for configuring
hardware or similar purposes (setting port-addresses, loading firmware
etc.) For this purpose, in the LL all ioctl-calls with an argument
>= IIOCDRVCTL (0x100) will be handed transparently to this
function after subtracting 0x100 and placing the result in arg.
Example:
If a userlevel-program calls ioctl(0x101,...) the function gets
called with the field command set to 1.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_IOCTL
arg = Original ioctl-cmd - IIOCDRVCTL
para.num = first bytes filled with (unsigned long)arg
Returnvalue:
Depending on driver.
 
ISDN_CMD_DIAL:
 
This command is used to tell the HL-driver it should dial a given
number.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_DIAL
arg = channel-number locally to the driver. (starting with 0)
para.setup.phone = An ASCII-String containing the number to dial.
para.setup.eazmsn = An ASCII-Sting containing the own EAZ or MSN.
para.setup.si1 = The Service-Indicator.
para.setup.si2 = Additional Service-Indicator.
 
If the Line has been designed as SPV (a special german
feature, meaning semi-leased-line) the phone has to
start with an "S".
***CHANGE0.6: In previous versions the EAZ has been given in the
highbyte of arg.
***CHANGE0.7.1: New since this version: ServiceIndicator and AddInfo.
 
ISDN_CMD_ACCEPTD:
 
With this command, the HL-driver is told to accept a D-Channel-setup.
(Response to an incoming call)
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_ACCEPTD
arg = channel-number locally to the driver. (starting with 0)
para = unused.
 
ISDN_CMD_ACCEPTB:
 
With this command, the HL-driver is told to perform a B-Channel-setup.
(after establishing D-Channel-Connection)
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_ACCEPTB
arg = channel-number locally to the driver. (starting with 0)
para = unused.
 
ISDN_CMD_HANGUP:
 
With this command, the HL-driver is told to hangup (B-Channel if
established first, then D-Channel). This command is also used for
actively rejecting an incoming call.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_HANGUP
arg = channel-number locally to the driver. (starting with 0)
para = unused.
 
ISDN_CMD_CLREAZ:
 
With this command, the HL-driver is told not to signal incoming
calls to the LL.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_CLREAZ
arg = channel-number locally to the driver. (starting with 0)
para = unused.
 
ISDN_CMD_SETEAZ:
 
With this command, the HL-driver is told to signal incoming calls for
the given EAZs/MSNs to the LL.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_SETEAZ
arg = channel-number locally to the driver. (starting with 0)
para.num = ASCII-String, containing the desired EAZ's/MSN's
(comma-separated). If an empty String is given, the
HL-driver should respond to ALL incoming calls,
regardless of the destination-address.
***CHANGE0.6: New since this version the "empty-string"-feature.
 
ISDN_CMD_GETEAZ: (currently unused)
 
With this command, the HL-driver is told to report the current setting
given with ISDN_CMD_SETEAZ.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_GETEAZ
arg = channel-number locally to the driver. (starting with 0)
para.num = ASCII-String, containing the current EAZ's/MSN's
 
ISDN_CMD_SETSIL: (currently unused)
 
With this command, the HL-driver is told to signal only incoming
calls with the given Service-Indicators.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_SETSIL
arg = channel-number locally to the driver. (starting with 0)
para.num = ASCII-String, containing the desired Service-Indicators.
 
ISDN_CMD_GETSIL: (currently unused)
 
With this command, the HL-driver is told to return the current
Service-Indicators it will respond to.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_SETSIL
arg = channel-number locally to the driver. (starting with 0)
para.num = ASCII-String, containing the current Service-Indicators.
 
ISDN_CMD_SETL2:
 
With this command, the HL-driver is told to select the given Layer-2-
protocol. This command is issued by the LL prior to ISDN_CMD_DIAL or
ISDN_CMD_ACCEPTD.
 
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_SETL2
arg = channel-number locally to the driver. (starting with 0)
logical or'ed with (protocol-Id << 8)
protocol-Id is one of the constants ISDN_PROTO_L2...
para = unused.
 
ISDN_CMD_GETL2: (currently unused)
 
With this command, the HL-driver is told to return the current
setting of the Layer-2-protocol.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_GETL2
arg = channel-number locally to the driver. (starting with 0)
para = unused.
Returnvalue:
current protocol-Id (one of the constants ISDN_L2_PROTO)
 
ISDN_CMD_SETL3:
 
With this command, the HL-driver is told to select the given Layer-3-
protocol. This command is issued by the LL prior to ISDN_CMD_DIAL or
ISDN_CMD_ACCEPTD.
 
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_SETL3
arg = channel-number locally to the driver. (starting with 0)
logical or'ed with (protocol-Id << 8)
protocol-Id is one of the constants ISDN_PROTO_L3...
para = unused.
 
ISDN_CMD_GETL2: (currently unused)
 
With this command, the HL-driver is told to return the current
setting of the Layer-3-protocol.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_GETL3
arg = channel-number locally to the driver. (starting with 0)
para = unused.
Returnvalue:
current protocol-Id (one of the constants ISDN_L3_PROTO)
 
ISDN_CMD_LOCK:
 
With this command the HL-driver is told, that it will be used by the
LL and therefore may not be unloaded. The HL-driver should use
MOD_INC_USE_COUNT to tell that to the kernel.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_LOCK
arg = unused.
para = unused.
 
ISDN_CMD_UNLOCK:
 
With this command the HL-driver is told, that it is no more used by the
LL and therefore may be unloaded. The HL-driver should use
DEC_INC_USE_COUNT to tell that to the kernel.
 
Parameter:
driver = driver-Id.
command = ISDN_CMD_UNLOCK
arg = unused.
para = unused.
 
3. Description of the events to be signaled by the HL-driver to th LL.
 
All status-changes are signaled via calling the previously described
function statcallb(). The field command of the struct isdn_cmd has
to be set by the HL-driver with the appropriate Status-Id (event-number).
The field arg has to be set to the channel-number (locally to the driver,
starting with 0) to which this event applies. (Exception: STAVAIL-event)
 
Until now, the following Status-Ids are defined:
 
ISDN_STAT_AVAIL:
 
With this call, the HL-driver signals the availability of new data
for readstat(). Used only for debugging-purposes, see description
of readstat().
 
Parameter:
driver = driver-Id
command = ISDN_STAT_STAVAIL
arg = length of available data.
para = unused.
 
ISDN_STAT_ICALL:
 
With this call, the HL-driver signals an incoming call to the LL.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_ICALL
arg = channel-number, locally to the driver. (starting with 0)
para.setup.phone = Callernumber.
para.setup.eazmsn = CalledNumber.
para.setup.si1 = Service Indicator.
para.setup.si2 = Additional Service Indicator.
para.setup.plan = octet 3 from Calling party number Information Element.
para.setup.screen = octet 3a from Calling party number Information Element.
 
Return:
0 = No device matching this call.
1 = At least one device matching this call (RING on ttyI).
HL-driver may send ALERTING on the D-channel in this case.
2 = Call will be rejected.
-1 = An error happened. (Invalid parameters for example.)
 
ISDN_STAT_RUN:
 
With this call, the HL-driver signals availability of the ISDN-card.
(after initializing, loading firmware)
 
Parameter:
driver = driver-Id
command = ISDN_STAT_RUN
arg = unused.
para = unused.
 
ISDN_STAT_STOP:
 
With this call, the HL-driver signals unavailability of the ISDN-card.
(before unloading, while resetting/reconfiguring the card)
 
Parameter:
driver = driver-Id
command = ISDN_STAT_STOP
arg = unused.
para = unused.
 
ISDN_STAT_DCONN:
 
With this call, the HL-driver signals the successful establishment of
a D-Channel-connection. (Response to ISDN_CMD_ACCEPTD or ISDN_CMD_DIAL)
 
Parameter:
driver = driver-Id
command = ISDN_STAT_DCONN
arg = channel-number, locally to the driver. (starting with 0)
para = unused.
 
ISDN_STAT_BCONN:
 
With this call, the HL-driver signals the successful establishment of
a B-Channel-connection. (Response to ISDN_CMD_ACCEPTB or because the
remote-station has initiated establishment)
 
Parameter:
driver = driver-Id
command = ISDN_STAT_BCONN
arg = channel-number, locally to the driver. (starting with 0)
para = unused.
 
ISDN_STAT_DHUP:
 
With this call, the HL-driver signals the shutdown of a
D-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP,
or caused by a remote-hangup or if the remote-station has actively
rejected a call.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_DHUP
arg = channel-number, locally to the driver. (starting with 0)
para = unused.
 
ISDN_STAT_BHUP:
 
With this call, the HL-driver signals the shutdown of a
B-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP,
or caused by a remote-hangup.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_BHUP
arg = channel-number, locally to the driver. (starting with 0)
para = unused.
 
ISDN_STAT_CINF:
 
With this call, the HL-driver delivers charge-unit information to the
LL.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_CINF
arg = channel-number, locally to the driver. (starting with 0)
para.num = ASCII string containing charge-units (digits only).
 
ISDN_STAT_LOAD: (currently unused)
 
ISDN_STAT_UNLOAD:
 
With this call, the HL-driver signals that it will be unloaded now. This
tells the LL to release all corresponding data-structures.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_UNLOAD
arg = unused.
para = unused.
 
ISDN_STAT_BSENT:
 
With this call the HL-driver signals the delivery of a data-packet.
This callback is used by the network-interfaces only, tty-Emulation
does not need this call.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_BSENT
arg = channel-number, locally to the driver. (starting with 0)
para = unused.
 
ISDN_STAT_NODCH:
 
With this call, the driver has to respond to a prior ISDN_CMD_DIAL, if
no D-Channel is available.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_NODCH
arg = channel-number, locally to the driver. (starting with 0)
para = unused.
 
ISDN_STAT_ADDCH: (currently unused)
 
This call is planned for HL-drivers, which are unable to check card-type
or numbers of supported channels before they have loaded any firmware
using ioctl. Those HL-driver simply set the channel-parameter to zero
or a minimum channel-number when registering, and later if they know
the real amount, perform this call, allocating additional channels.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_ADDCH
arg = to be defined.
para = to be defined.
 
ISDN_STAT_CAUSE:
 
With this call, the HL-driver delivers CAUSE-messages to the LL.
Currently the LL does not use this messages. Their contents is simply
logged via kernel-messages. Therefore, currently the format of the
messages is currently completely free. However they should be printable.
 
Parameter:
driver = driver-Id
command = ISDN_STAT_NODCH
arg = channel-number, locally to the driver. (starting with 0)
para.num = ASCII string containing CAUSE-message.
 
/README.sc
0,0 → 1,274
Welcome to Beta Release 2 of the combination ISDN driver for SpellCaster's
ISA ISDN adapters. Please note this release 2 includes support for the
DataCommute/BRI and TeleCommute/BRI adapters only and any other use is
guaranteed to fail. If you have a DataCommute/PRI installed in the test
computer, we recommend removing it as it will be detected but will not
be usable. To see what we have done to Beta Release 2, see section 3.
 
Speaking of guarantees, THIS IS BETA SOFTWARE and as such contains
bugs and defects either known or unknown. Use this software at your own
risk. There is NO SUPPORT for this software. Some help may be available
through the web site or the mailing list but such support is totally at
our own option and without warrantee. If you choose to assume all and
total risk by using this driver, we encourage you to join the beta
mailing list.
 
To join the Linux beta mailing list, send a message to:
majordomo@spellcast.com with the words "subscribe linux-beta" as the only
contents of the message. Do not include a signature. If you choose to
remove yourself from this list at a later date, send another message to
the same address with the words "unsubscribe linux-beta" as it's only
contents.
 
TABLE OF CONTENTS
-----------------
1. Introduction
1.1 What is ISDN4Linux?
1.2 What is different between this driver and previous drivers?
1.3 How do I setup my system with the correct software to use
this driver release?
2. Basic Operations
2.1 Unpacking and installing the driver
2.2 Read the man pages!!!
2.3 Installing the driver
2.4 Removing the driver
2.5 What to do if it doesn't load
2.6 How to setup ISDN4Linux with the driver
 
3. Beta Change Summaries and Miscellaneous Notes
 
1. Introduction
---------------
 
The revision 2 Linux driver for SpellCaster ISA ISDN adapters is built
upon ISDN4Linux available separately or as included in Linux 2.0 and later.
The driver will support a maximum of 4 adapters in any one system of any
type including DataCommute/BRI, DataCommute/PRI and TeleCommute/BRI for a
maximum of 92 channels for host. The driver is supplied as a module in
source form and needs to be complied before it can be used. It has been
tested on Linux 2.0.20.
 
1.1 What Is ISDN4Linux
 
ISDN4Linux is a driver and set of tools used to access and use ISDN devices
on a Linux platform in a common and standard way. It supports HDLC and PPP
protocols and offers channel bundling and MLPPP support. To use ISDN4Linux
you need to configure your kernel for ISDN support and get the ISDN4Linux
tool kit from our web site.
 
ISDN4Linux creates a channel pool from all of the available ISDN channels
and therefore can function across adapters. When an ISDN4Linux compliant
driver (such as ours) is loaded, all of the channels go into a pool and
are used on a first-come first-served basis. In addition, individual
channels can be specifically bound to particular interfaces.
 
1.2 What is different between this driver and previous drivers?
 
The revision 2 driver besides adopting the ISDN4Linux architecture has many
subtle and not so subtle functional differences from previous releases. These
include:
- More efficient shared memory management combined with a simpler
configuration. All adapters now use only 16Kbytes of shared RAM
versus between 16K and 64K. New methods for using the shared RAM
allow us to utilize all of the available RAM on the adapter through
only one 16K page.
- Better detection of available upper memory. The probing routines
have been improved to better detect avaialble shared RAM pages and
used pages are now locked.
- Decreased loading time and a wider range of I/O ports probed.
We have significantly reduced the amount of time it takes to load
the driver and at the same time doubled the number of I/O ports
probed increasing the likelyhood of finding an adapter.
- We now support all ISA adapter models with a single driver instead
of separate drivers for each model. The revision 2 driver supports
the DataCommute/BRI, DataCommute/PRI and TeleCommute/BRI in any
combination up to a maximum of four adapters per system.
- On board PPP protocol support has been removed in favour of the
sync-PPP support used in ISDN4Linux. This means more control of
the protocol parameters, faster negotiation time and a more
familiar interface.
 
1.3 How do I setup my system with the correct software to use
this driver release?
 
Before you can compile, install and use the SpellCaster ISA ISDN driver, you
must ensure that the following software is installed, configuraed and running:
 
- Linux kernel 2.0.20 or later with the required init and ps
versions. Please see your distribution vendor for the correct
utility packages. The latest kernel is available from
ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0/
 
- The latest modules package (modules-2.0.0.tar.gz) from
ftp://sunsite.unc.edu/pub/Linux/kernel/modules-2.0.0.tar.gz
 
- The ISDN4Linux tools available from
ftp://ftp.franken.de/pub/isdn4linux/v2.0/isdn4k-utils-2.0.tar.gz
This package may fail to compile for you so you can alternatively
get a pre-compiled version from
ftp://ftp.spellcast.com/pub/drivers/isdn4linux/isdn4k-bin-2.0.tar.gz
 
 
2. Basic Operations
-------------------
 
2.1 Unpacking and installing the driver
 
1. As root, create a directory in a convienient place. We suggest
/usr/src/spellcaster.
2. Unpack the archive with :
tar xzf sc-n.nn.tar.gz -C /usr/src/spellcaster
3. Change directory to /usr/src/spellcaster
 
4. Read the README and RELNOTES files.
 
5. Run 'make' and if all goes well, run 'make install'.
 
2.2 Read the man pages!!!
 
Make sure you read the scctrl(8) and sc(4) manual pages before continuing
any further. Type 'man 8 scctrl' and 'man 4 sc'.
 
2.3 Installing the driver
 
To install the driver, type '/sbin/insmod sc' as root. sc(4) details options
you can specify but you shouldn't need to use any unless this doesn't work.
 
Make sure the driver loaded and detected all of the adapters by typing
'dmesg'.
 
The driver can be configured so that it is loaded upon startup. To do this,
edit the file "/etc/modules/'uname -f'/'uname -v'" and insert the driver name
"sc" into this file.
 
2.4 Removing the driver
 
To remove the driver, delete any interfaces that may exist (see isdnctrl(8)
for more on this) and then type '/sbin/rmmod sc'.
 
2.5 What to do if it doesn't load
 
If, when you try to install the driver, you get a message mentioning
'register_isdn' then you do not have the ISDN4Linux system installed. Please
make sure that ISDN support is configured in the kernel.
 
If you get a message that says 'initialization of sc failed', then the
driver failed to detect an adapter or failed to find resources needed such
as a free IRQ line or shared memory segment. If you are sure there are free
resources available, use the insmod options detailed in sc(4) to override
the probing function.
 
Upon testing, the following problem was noted, the driver would load without
problems, but the board would not respond beyond that point. When a check was
done with 'cat /proc/interrupts' the interrupt count for sc was 0. In the event
of this problem, change the BIOS settings so that the interrupts in question are
reserved for ISA use only.
 
 
2.6 How to setup ISDN4Linux with the driver
 
There are two main configurations which you can use with the driver:
 
A) Basic HDLC connection
B) PPP connection
C) MLPPP connection
 
It should be mentioned here that you may also use a tty connection if you desire.
The Documentation directory of the isdn4linux subsystem offers a good documentation
on this feature.
 
A) 10 steps to the establishment of a basic HDLC connection
-----------------------------------------------------------
 
- please open the isdn-hdlc file in the examples directory and follow along...
This file is a script used to configure a BRI ISDN TA to establish a basic HDLC
connection between its two channels. There two network interfaces which are
created and two routes added between the channels.
 
i) using the isdnctrl utitity, add an interface with "addif" and name it "isdn0"
ii) add the outgoing and inbound telephone numbers
iii) set the Layer 2 protocol to hdlc
iv) set the eaz of the interface to be the phone number of that specific channel
v) to turn the callback features off, set the callback to "off" and
the callback delay (cbdelay) to 0.
vi) the hangup timeout can be set to a specified number of seconds
vii) the hangup upon incomming call can be set on or off
viii) use the ifconfig command to bring-up the network interface with a specific
IP address and point to point address
viv) add a route to the IP address through the isdn0 interface
x) a ping should result in the establishment of the connection
 
B) Establishment of a PPP connection
------------------------------------
 
- please open the isdn-ppp file in the examples directory and follow along...
This file is a script used to configure a BRI ISDN TA to establish a PPP connection
between the two channels. The file is almost identical to the HDLC connection
example except that the packet ecapsulation type has to be set.
use the same procedure as in the HDLC connection from steps i) to iii) then,
after the Layer 2 protocol is set, set the encapsulation "encap" to syncppp.
With this done, the rest of the steps, iv) to x) can be followed from above.
 
Then, the ipppd (ippp daemon) must be setup:
xi) use the ipppd function found in /sbin/ipppd to set the following:
xii) take out (minus) VJ compression and bsd compression
xiii) set the mru size to 2000
xiv) link the two /dev interfaces to the daemon
 
NOTE: A "*" in the inbound telephone number specifies that a call can be accepted
on any number.
 
C) Establishment of a MLPPP connection
--------------------------------------
 
- please open the isdn-mppp file in the examples directory and follow along...
This file is a script used to configure a BRI ISDN TA to accept a Multi Link PPP
connection.
i) using the isdnctrl utitity, add an interface with "addif" and name it "ippp0"
ii) add the inbound telephone number
iii) set the Layer 2 protocol to hdlc and the Layer 3 protocol to trans (transparent)
iv) set the packet encapsulation to syncppp
v) set the eaz of the interface to be the phone number of that specific channel
vi) to turn the callback features off, set the callback to "off" and
the callback delay (cbdelay) to 0.
vi) the hangup timeout can be set to a specified number of seconds
vii) the hangup upon incomming call can be set on or off
viii) add a slave interface and name it "ippp32" for example
viv) set the similar parameters for the ippp32 interface
x) use the ifconfig command to bring-up the ippp0 interface with a specific
IP address and point to point address
xi) add a route to the IP address through the ippp0 interface
xii) use the ipppd function found in /sbin/ipppd to set the following:
xiii) take out (minus) bsd compression
xiv) set the mru size to 2000
xv) add (+) the multi-link function "+mp"
xv) link the two /dev interfaces to the daemon
 
NOTE: To use the MLPPP connection to dial OUT to a MLPPP connection, change the
inbound telephone numbers to the outgoing telephone numbers of the MLPPP
host.
 
3. Beta Change Summaries and Miscellaneous Notes
------------------------------------------------
When using the "scctrl" utility to upload firmware revisions on the board, please
note that the byte count displayed at the end of the operation may be different
than the total number of bytes in the "dcbfwn.nn.sr" file. Please disregard the
displayed byte count.
 
It was noted that in Beta Release 1, the module would fail to load and result in a
segmentation fault when insmod"ed". This problem was created when one of the
isdn4linux parameters, (isdn_ctrl, data field) was filled in. In some cases, this
data field was NULL, and was left unchecked, so when it was referenced.. segv.
The bug has been fixed around line 63-68 of event.c.
 
/syncPPP.FAQ
0,0 → 1,224
simple isdn4linux PPP FAQ .. to be continued .. not 'debugged'
-------------------------------------------------------------------
 
Q01: what's pppd,ipppd, syncPPP , asyncPPP ??
Q02: error message "this systems lacks PPP support"
Q03: strange information using 'ifconfig'
Q04: MPPP?? What's that and how can I use it ...
Q05: I tried MPPP but it doesn't work
Q06: can I use asynchronous PPP encapsulation with network devices
Q07: A SunISDN machine can't connect to my i4l system
Q08: I wanna talk to several machines, which need different configs
Q09: Starting the ipppd, I get only error messages from i4l
Q10: I wanna use dynamic IP address assignment
Q11: I can't connect. How can I check where the problem is.
Q12: How can I reduce login delay?
 
-------------------------------------------------------------------
 
Q01: pppd,ipppd, syncPPP , asyncPPP .. what is that ?
what should I use?
A: The pppd is for asynchronous PPP .. asynchronous means
here, the framing is character based. (e.g when
using ttyI* or tty* devices)
 
The ipppd handles PPP packets coming in HDLC
frames (bit based protocol) ... The PPP driver
in isdn4linux pushes all IP packets direct
to the network layer and all PPP protocol
frames to the /dev/ippp* device.
So, the ipppd is a simple external network
protocol handler.
 
If you login into a remote machine using the
/dev/ttyI* devices and then enable PPP on the
remote terminal server -> use the 'old' pppd
 
If your remote side immediately starts to send
frames ... you probably connect to a
syncPPP machine .. use the network device part
of isdn4linux with the 'syncppp' encapsulation
and make sure, that the ipppd is running and
connected to at least one /dev/ippp*. Check the
isdn4linux manual on how to configure a network device.
 
--
 
Q02: when I start the ipppd .. I only get the
error message "this systems lacks PPP support"
A: check that at least the device 'ippp0' exists.
(you can check this e.g with the program 'ifconfig')
The ipppd NEEDS this device under THIS name ..
If this device doesn't exists, use:
isdnctrl addif ippp0
isdnctrl encap ippp0 syncppp
... (see isdn4linux doc for more) ...
A: Maybe you have compiled the ipppd with another
kernel source tree than the kernel you currently
run ...
 
--
 
Q03: when I list the netdevices with ifconfig I see, that
my ISDN interface has a HWaddr and IRQ=0 and Base
address = 0
A: The device is a fake ethernet device .. ignore IRQ and baseaddr
You need the HWaddr only for ethernet encapsulation.
--
 
Q04: MPPP?? What's that and how can I use it ...
 
A: 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.
To enable MPPP negotiation you must call the
ipppd with the '+mp' option.
You must also configure a slave device for
every additional channel. (see the i4l manual
for more)
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>
e.g:
isdnctrl addlink ippp0
This is different from other encapsulations of
isdn4linux! With syncPPP, there is no automatic
activation of slave devices.
 
--
 
Q05: I tried MPPP but it doesn't work .. the ipppd
writes in the debug log something like:
.. 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 ...
 
A: you forgot to compile MPPP/RFC1717 support into the
ISDN Subsystem. Recompile with this option enabled.
 
--
 
Q06: can I use asynchronous PPP encapsulation
over the network interface of isdn4linux ..
 
A: No .. that's not possible .. Use the standard
PPP package over the /dev/ttyI* devices. You
must not use the ipppd for this.
--
 
Q07: A SunISDN machine tries to connect my i4l system,
which doesn't work.
Checking the debug log I just saw garbage like:
!![ ... fill in the line ... ]!!
 
A: The Sun tries to talk asynchronous PPP ... i4l
can't understand this ... try to use the ttyI*
devices with the standard PPP/pppd package
 
A: (from Alexanter Strauss: )
!![ ... fill in mail ]!!
 
--
 
Q08: A wanna talk to remote machines, which need
a different configuration. The only way
I found to do this is to kill the ipppd and
start a new one with another config to connect
to the second machine.
 
A: you must bind a network interface explicitly to
an ippp device, where you can connect a (for this
interface) individually configured ipppd.
 
--
 
Q09: When I start the ipppd I only get error messages
from the i4l driver ..
 
A: When starting, the ipppd calls functions which may
trigger a network packet. (e.g gethostbyname()).
Without the ipppd (at this moment, it is not
fully started) we can't handle this network request.
Try to configure hostnames necessary for the ipppd
in your local /etc/hosts file or in a way, that
your system can resolve it without using an
isdn/ippp network-interface.
 
--
 
Q10: I wanna use dynamic IP address assignment ... How
must I configure the network device.
 
A: At least you must have a routing, which forwards
a packet to the ippp network-interface to trigger
the dial-on-demand.
A default routing to the ippp-interface will work.
Now you must choose a dummy IP address for your
interface.
If for some reason you can't set the default
routing to the ippp interface, you may take any
address of the subnet from which you expect your
dynamic IP number and set a 'network route' for
this subnet to the ippp interface.
To allow overriding of the dummy address you
must call the ipppd with the 'ipcp-accept-local' option.
 
A: You must know, how the ipppd gets the addresses it wanna
configure. If you don't give any option, the ipppd
tries to negotiate the local host address!
With the option 'noipdefault' it requests an address
from the remote machine. With 'useifip' it gets the
addresses from the net interface. Or you set the address
on the option line with the <a.b.c.d:e.f.g.h> option.
Note: the IP address of the remote machine must be configured
locally or the remote machine must send it in an IPCP request.
If your side doesn't know the IP address after negotiation, it
closes the connection!
You must allow overriding of address with the 'ipcp-accept-*'
options, if you have set your own or the remote address
explicitly.
 
A: Maybe you try these options .. e.g:
 
/sbin/ipppd :$REMOTE noipdefault /dev/ippp0
 
where REMOTE must be the address of the remote machine (the
machine, which gives you your address)
 
--
 
Q11: I can't connect. How can I check where the problem is.
 
A: A good help log is the debug output from the ipppd...
Check whether you can find there:
- only a few LCP-conf-req SENT messages (less then 10)
and then a Term-REQ:
-> check whether your ISDN card is well configured
it seems, that your machine doesn't dial
(IRQ,IO,Proto, etc problems)
Configure your ISDN card to print debug messages and
check the /dev/isdnctrl output next time. There
you can see, whether there is activity on the card/line.
- there are at least a few RECV messages in the log:
-> fine: your card is dialing and your remote machine
tries to talk with you. Maybe only a missing
authentication. Check your ipppd configuration again.
- the ipppd exits for some reason:
-> not good ... check /var/adm/syslog and /var/adm/daemon.
Could be a bug in the ipppd.
 
--
 
Q12: How can I reduce login delay?
 
A: Log a login session ('debug' log) and check which options
your remote side rejects. Next time configure your ipppd
to not negotiate these options. Another 'side effect' is, that
this increases redundancy. (e.g your remote side is buggy and
rejects options in a wrong way).
 
 
 
/README.avmb1
0,0 → 1,62
The driver provides a kernel capi2.0 Interface (kernelcapi) and
on top of this a User-Level-CAPI2.0-interface (capi)
and a driver to connect isdn4linux with CAPI2.0 (capidrv).
 
The Author can be reached at calle@calle.in-berlin.de
The command avmcapictrl is part of the isdn4linux-utils.
t4-files can be found at ftp.avm.de.
 
Installing
----------
 
You need at least /dev/capi20 to load the firmware.
 
mknod /dev/capi20 c 68 0
mknod /dev/capi20.00 c 68 1
mknod /dev/capi20.01 c 68 2
.
.
.
mknod /dev/capi20.19 c 68 20
 
Running
-------
 
To use the card you need the t4-files to download the firmware.
AVM GmbH provides several t4-files for the different D-channel
protocols (b1.t4 for Euro-ISDN). Install these file in /lib/isdn.
 
If you not compile the driver as modules, you have to add the
card(s) and load them after booting:
 
avmcapictrl add 0x150 15
avmcapictrl load /lib/isdn/b1.t4 1
 
if you configure as modules you have two possibilities:
 
insmod /lib/modules/current/misc/capiutil.o
insmod /lib/modules/current/misc/kernelcapi.o portbase=0x150 irq=15
insmod /lib/modules/current/misc/capidrv.o
insmod /lib/modules/current/misc/capi.o
avmcapictrl load /lib/isdn/b1.t4
 
or
 
insmod /lib/modules/current/misc/capiutil.o
insmod /lib/modules/current/misc/kernelcapi.o
insmod /lib/modules/current/misc/capidrv.o
insmod /lib/modules/current/misc/capi.o
avmcapictrl add 0x150 15
avmcapictrl load /lib/isdn/b1.t4
 
Questions
---------
Check out the FAQ (ftp.franken.de).
 
Bugs
----
If you find any please let me know.
 
Enjoy,
 
Carsten Paeth (calle@calle.in-berlin.de)
/00-INDEX
0,0 → 1,22
00-INDEX
- this file (info on ISDN implementation for Linux)
CREDITS
- list of the kind folks that brought you this stuff.
INTERFACE
- description of Linklevel and Hardwarelevel ISDN interface.
README
- general info on what you need and what to do for Linux ISDN.
README.audio
- info for running audio over ISDN.
README.icn
- info on the ICN-ISDN-card and its driver.
README.HiSax
- info on the HiSax driver which replaces the old teles.
README.pcbit
- info on the PCBIT-D ISDN adapter and driver.
README.syncppp
- info on running Sync PPP over ISDN.
syncPPP.FAQ
- frequently asked questions about running PPP over ISDN.
README.avmb1
- info on driver for AVM-B1 ISDN card
/README.icn
0,0 → 1,148
$Id: README.icn,v 1.1.1.1 2001-09-10 07:44:10 simons Exp $
 
You can get the ICN-ISDN-card from:
 
Thinking Objects Software GmbH
 
 
Tel: +49 931 2877950
Fax: +49 931 2877951
 
email info@think.de
WWW http:/www.think.de
 
 
The card communicates with the PC by two interfaces:
1. A range of 4 successive port-addresses, whose base address can be
configured with the switches.
2. A memory window with 16KB-256KB size, which can be setup in 16k steps
over the whole range of 16MB. Isdn4linux only uses a 16k window.
The base address of the window can be configured when loading
the lowlevel-module (see README). If using more than one card,
all cards are mapped to the same window and activated as needed.
 
Setting up the IO-address dipswitches for the ICN-ISDN-card:
 
Two types of cards exist, one with dip-switches and one with
hook-switches.
 
1. Setting for the card with hook-switches:
 
(0 = switch closed, 1 = switch open)
 
S3 S2 S1 Base-address
0 0 0 0x300
0 0 1 0x310
0 1 0 0x320 (Default for isdn4linux)
0 1 1 0x330
1 0 0 0x340
1 0 1 0x350
1 1 0 0x360
1 1 1 NOT ALLOWED!
2. Setting for the card with dip-switches:
 
(0 = switch closed, 1 = switch open)
 
S1 S2 S3 S4 Base-Address
0 0 0 0 0x300
0 0 0 1 0x310
0 0 1 0 0x320 (Default for isdn4linux)
0 0 1 1 0x330
0 1 0 0 0x340
0 1 0 1 0x350
0 1 1 0 0x360
0 1 1 1 NOT ALLOWED!
1 0 0 0 0x308
1 0 0 1 0x318
1 0 1 0 0x328
1 0 1 1 0x338
1 1 0 0 0x348
1 1 0 1 0x358
1 1 1 0 0x368
1 1 1 1 NOT ALLOWED!
 
The ICN driver either may be build into kernel or as a module. Initialization
depends on how the drive is built:
 
Driver built into the kernel:
 
The ICN driver can be configured using the commandline-feature while
loading the kernel with LILO or LOADLIN. It accepts the following syntax:
 
icn=p,m[,idstring1[,idstring2]]
 
where
 
p = portbase (default: 0x320)
m = shared memory (default: 0xd0000)
 
When using the ICN double card (4B), you MUST define TWO idstrings.
idstring must start with a character! There is no way for the driver
to distinguish between a 2B and 4B type card. Therefore, by supplying
TWO idstrings, you tell the driver that you have a 4B installed.
If you like to use more than one card, you can use the program
"icnctrl" from the utility-package to configure additional cards.
You need to configure shared memory only once, since the icn-driver
maps all cards into the same address-space.
 
Using the "icnctrl"-utility, portbase and shared memory can also be
changed during runtime.
 
The D-channel protocol is configured by loading different firmware
into the card's memory using the "icnctrl"-utility.
 
 
Driver built as module:
 
The module icn.o can be configured during "insmod'ing" it by
appending its parameters to the insmod-commandline. The following
syntax is accepted:
 
portbase=p membase=m icn_id=idstring [icn_id2=idstring2]
 
where p, m, idstring1 and idstring2 have the same meanings like
parameters described for the kernel-version above.
When using the ICN double card (4B), you MUST define TWO idstrings.
idstring must start with a character! There is no way for the driver
to distinguish between a 2B and 4B type card. Therefore, by supplying
TWO idstrings, you tell the driver that you have a 4B installed.
Using the "icnctrl"-utility, the same features apply to the modularized
version like to the kernel-builtin one.
 
The D-channel protocol is configured by loading different firmware
into the card's memory using the "icnctrl"-utility.
 
Loading the firmware into the card:
 
The firmware is supplied together with the isdn4k-utils package. It
can be found in the subdirectory icnctrl/firmware/
 
There are 3 files:
 
loadpg.bin - Image of the bootstrap loader.
pc_1t_ca.bin - Image of firmware for german 1TR6 protocol.
pc_eu_ca.bin - Image if firmware for EDSS1 (Euro-ISDN) protocol.
 
Assumed you have installed the utility-package correctly, the firmware
will be downloaded into the 2B-card using the following command:
 
icnctrl -d Idstring load /etc/isdn/loadpg.bin /etc/isdn/pc_XX_ca.bin
 
where XX is either "1t" or "eu", depending of the D-Channel protocol
used on your S0-bus and Idstring is the Name of the card, given during
insmod-time or (for kernel-builtin driver) on the kernel commandline.
 
To load a 4B-card, the same command is used, except a second firmware
file is appended to the commandline of icnctrl.
 
-> After dowloading firmware, the two LEDs at the back cover of the card
(ICN-4B: 4 LEDs) must be blinking intermittently now. If a connection
is up, the corresponding led is lit continuously.
 
For further documentation (adding more ICN-cards), refer to the manpage
icnctrl.8 which is included in the isdn4k-utils package.
 
/HiSax.cert
0,0 → 1,76
-----BEGIN PGP SIGNED MESSAGE-----
 
First:
 
HiSax is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
However, if you wish to modify the HiSax sources, please note the following:
 
HiSax has passed the ITU approval test suite with ELSA Quickstep ISDN cards.
The certification is only valid for the combination of the tested software
version and the tested hardware. Any changes to the HiSax source code may
therefore affect the certification.
 
If you change the main files of the HiSax ISDN stack, the certification will
become invalid. Because in most countries it is illegal to connect
unapproved ISDN equipment to the public network, I have to guarantee that
changes in HiSax do not affect the certification.
 
In order to make a valid certification apparent to the user, I have built in
some validation checks that are made during the make process. The HiSax main
files are protected by md5 checksums and the md5sum file is pgp signed by
myself:
 
KeyID 1024/FF992F6D 1997/01/16 Karsten Keil <keil@temic-ech.spacenet.de>
Key fingerprint = 92 6B F7 58 EE 86 28 C8 C4 1A E6 DC 39 89 F2 AA
 
Only if the checksums are OK, and the signature of the file
"drivers/isdn/hisax/md5sums.asc" match, is the certification valid; a
message confirming this is then displayed during the hisax init process.
 
The affected files are:
 
drivers/isdn/hisax/isac.c
drivers/isdn/hisax/isdnl1.c
drivers/isdn/hisax/isdnl2.c
drivers/isdn/hisax/isdnl3.c
drivers/isdn/hisax/tei.c
drivers/isdn/hisax/callc.c
drivers/isdn/hisax/l3dss1.c
drivers/isdn/hisax/l3_1tr6.c
drivers/isdn/hisax/cert.c
drivers/isdn/hisax/elsa.c
 
Please send any changes, bugfixes and patches to me rather than implementing
them directly into the HiSax sources.
 
This does not reduce your rights granted by the GNU General Public License.
If you wish to change the sources, go ahead; but note that then the
certification is invalid even if you use ELSA Quickstep cards.
 
Here are the certification registration numbers for ELSA Quickstep cards:
German D133361J CETECOM ICT Services GmbH 0682
European D133362J CETECOM ICT Services GmbH 0682
 
 
Karsten Keil
keil@isdn4linux.de
 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
 
iQCVAwUBNj5OKDpxHvX/mS9tAQFHuQP/WeImlqCcDZ2d132yAvRBWFULlJoSf1P/
c1lVTeaWvsSaY5Cu9hrKhXXhPzeEaitUbcUBPXdpzFWCA5CE902lnz7AhgRC+HF1
0qiKgkZZyc/5HKasFymR1+IWSLw30GesP3Di/ZMR3NJi8SlY9PIjx7hnEMunGSRO
1ufPvfWWuu8=
=nGJk
-----END PGP SIGNATURE-----
/README.syncppp
0,0 → 1,58
Some additional information for setting up a syncPPP
connection using network interfaces.
---------------------------------------------------------------
 
You need one thing beside the isdn4linux package:
 
a patched pppd .. (I called it ipppd to show the difference)
 
Compiling isdn4linux with sync PPP:
-----------------------------------
To compile isdn4linux with the sync PPP part, you have
to answer the appropriate question when doing a "make config"
Don't forget to load the slhc.o
module before the isdn.o module, if VJ-compression support
is not compiled into your kernel. (e.g if you have no PPP or
CSLIP in the kernel)
 
Using isdn4linux with sync PPP:
-------------------------------
Sync PPP is just another encapsulation for isdn4linux. The
name to enable sync PPP encapsulation is 'syncppp' .. e.g:
 
/sbin/isdnctrl encap ippp0 syncppp
 
The name of the interface is here 'ippp0'. You need
one interface with the name 'ippp0' to saturate the
ipppd, which checks the ppp version via this interface.
Currently, all devices must have the name ipppX where
'X' is a decimal value.
 
To set up a PPP connection you need the ipppd .. You must start
the ipppd once after installing the modules. The ipppd
communicates with the isdn4linux link-level driver using the
/dev/ippp0 to /dev/ippp15 devices. One ipppd can handle
all devices at once. If you want to use two PPP connections
at the same time, you have to connect the ipppd to two
devices .. and so on.
I've implemented one additional option for the ipppd:
'useifip' will get (if set to not 0.0.0.0) the IP address
for the negotiation from the attached network-interface.
(also: ipppd will try to negotiate pointopoint IP as remote IP)
You must disable BSD-compression, this implementation can't
handle compressed packets.
 
Check the etc/rc.isdn.syncppp in the isdn4kernel-util package
for an example setup script.
 
To use the MPPP stuff, you must configure a slave device
with isdn4linux. Now call the ipppd with the '+mp' option.
To increase the number of links, you must use the
'addlink' option of the isdnctrl tool. (rc.isdn.syncppp.MPPP is
an example script)
 
enjoy it,
michael
 
 
/README.HiSax
0,0 → 1,602
HiSax is a Linux hardware-level driver for passive ISDN cards with Siemens
chipset (ISAC_S 2085/2086/2186, HSCX SAB 82525). It is based on the Teles
driver from Jan den Ouden.
It is meant to be used with isdn4linux, an ISDN link-level module for Linux
written by Fritz Elfert.
 
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 
 
Supported cards
---------------
 
Teles 8.0/16.0/16.3 and compatible ones
Teles 16.3c
Teles S0/PCMCIA
Teles PCI
Teles S0Box
Creatix S0Box
Creatix PnP S0
Compaq ISDN S0 ISA card
AVM A1 (Fritz, Teledat 150)
AVM Fritz PCMCIA
AVM Fritz PnP
AVM Fritz PCI
ELSA Microlink PCC-16, PCF, PCF-Pro, PCC-8
ELSA Quickstep 1000
ELSA Quickstep 1000PCI
ELSA Quickstep 3000 (same settings as QS1000)
ELSA Quickstep 3000PCI
ELSA PCMCIA
ITK ix1-micro Rev.2
Eicon.Diehl Diva 2.0 ISA and PCI (S0 and U interface, no PRO version)
Eicon.Diehl Diva Piccola
ASUSCOM NETWORK INC. ISDNLink 128K PC adapter (order code I-IN100-ST-D)
Dynalink IS64PH (OEM version of ASUSCOM NETWORK INC. ISDNLink 128K adapter)
PCBIT-DP (OEM version of ASUSCOM NETWORK INC. ISDNLink)
HFC-2BS0 based cards (TeleInt SA1)
Sedlbauer Speed Card (Speed Win, Teledat 100, PCI, Fax+)
Sedlbauer Speed Star/Speed Star2 (PCMCIA)
Sedlbauer ISDN-Controller PC/104
USR Sportster internal TA (compatible Stollmann tina-pp V3)
ith Kommunikationstechnik GmbH MIC 16 ISA card
Traverse Technologie NETjet PCI S0 card
Dr. Neuhaus Niccy PnP/PCI
 
Note: PCF, PCF-Pro: up to now, only the ISDN part is supported
PCC-8: not tested yet
Teles PCMCIA is EXPERIMENTAL
Teles 16.3c is EXPERIMENTAL
Teles PCI is EXPERIMENTAL
Teles S0Box is EXPERIMENTAL
Eicon.Diehl Diva U interface not tested
 
If you know other passive cards with the Siemens chipset, please let me know.
To use the PNP cards you need the isapnptools.
You can combine any card, if there is no conflict between the ressources
(io, mem, irq).
 
 
Configuring the driver
----------------------
 
The HiSax driver can either be built directly into the kernel or as a module.
It can be configured using the command line feature while loading the kernel
with LILO or LOADLIN or, if built as a module, using insmod/modprobe with
parameters.
There is also some config needed before you compile the kernel and/or
modules. It is included in the normal "make [menu]config" target at the
kernel. Don't forget it, especially to select the right D-channel protocol.
 
Please note: All PnP cards need to be configured with isapnp and will work
only with the HiSax driver used as a module.
 
a) when built as a module
-------------------------
 
insmod/modprobe hisax.o \
io=iobase irq=IRQ mem=membase type=card_type \
protocol=D_channel_protocol id=idstring
 
or, if several cards are installed:
 
insmod/modprobe hisax.o \
io=iobase1,iobase2,... irq=IRQ1,IRQ2,... mem=membase1,membase2,... \
type=card_type1,card_type2,... \
protocol=D_channel_protocol1,D_channel_protocol2,... \
id=idstring1%idstring2 ...
 
where "iobaseN" represents the I/O base address of the Nth card, "membaseN"
the memory base address of the Nth card, etc.
 
The reason for the delimiter "%" being used in the idstrings is that ","
won't work with the current modules package.
 
The parameters may be specified in any order. For example, the "io"
parameter may precede the "irq" parameter, or vice versa. If several
cards are installed, the ordering within the comma separated parameter
lists must of course be consistent.
 
Only parameters applicable to the card type need to be specified. For
example, the Teles 16.3 card is not memory-mapped, so the "mem"
parameter may be omitted for this card. Sometimes it may be necessary
to specify a dummy parameter, however. This is the case when there is
a card of a different type later in the list that needs a parameter
which the preceding card does not. For instance, if a Teles 16.0 card
is listed after a Teles 16.3 card, a dummy memory base parameter of 0
must be specified for the 16.3. Instead of a dummy value, the parameter
can also be skipped by simply omitting the value. For example:
mem=,0xd0000. See example 6 below.
 
The parameter for the D-Channel protocol may be omitted if you selected the
correct one during kernel config. Valid values are "1" for German 1TR6,
"2" for EDSS1 (Euro ISDN) and "3" for leased lines (no D-Channel).
 
The Creatix/Teles PnP cards use io1= and io2= instead of io= for specifying
the I/O addresses of the ISAC and HSCX chips, respectively.
 
Card types:
 
Type Required parameters (in addition to type and protocol)
 
1 Teles 16.0 irq, mem, io
2 Teles 8.0 irq, mem
3 Teles 16.3 (non PnP) irq, io
4 Creatix/Teles PnP irq, io0 (ISAC), io1 (HSCX)
5 AVM A1 (Fritz) irq, io
6 ELSA PCC/PCF cards io or nothing for autodetect (the iobase is
required only if you have more than one ELSA
card in your PC)
7 ELSA Quickstep 1000 irq, io (from isapnp setup)
8 Teles 16.3 PCMCIA irq, io
9 ITK ix1-micro Rev.2 irq, io
10 ELSA PCMCIA irq, io (set with card manager)
11 Eicon.Diehl Diva ISA PnP irq, io
11 Eicon.Diehl Diva PCI no parameter
12 ASUS COM ISDNLink irq, io (from isapnp setup)
13 HFC-2BS0 based cards irq, io
14 Teles 16.3c PnP irq, io
15 Sedlbauer Speed Card irq, io
15 Sedlbauer PC/104 irq, io
15 Sedlbauer Speed PCI no parameter
16 USR Sportster internal irq, io
17 MIC card irq, io
18 ELSA Quickstep 1000PCI no parameter
19 Compaq ISDN S0 ISA card irq, io0, io1, io (from isapnp setup io=IO2)
20 NETjet PCI card no parameter
21 Teles PCI no parameter
22 Sedlbauer Speed Star (PCMCIA) irq, io (set with card manager)
24 Dr. Neuhaus Niccy PnP irq, io0, io1 (from isapnp setup)
24 Dr. Neuhaus Niccy PCI no parameter
25 Teles S0Box irq, io (of the used lpt port)
26 AVM A1 PCMCIA (Fritz!) irq, io (set with card manager)
27 AVM PnP (Fritz!PnP) irq, io (from isapnp setup)
27 AVM PCI (Fritz!PCI) no parameter
28 Sedlbauer Speed Fax+ irq, io (from isapnp setup)
 
 
At the moment IRQ sharing is only possible with PCI cards. Please make sure
that your IRQ is free and enabled for ISA use.
 
 
Examples for module loading
 
1. Teles 16.3, Euro ISDN, I/O base 280 hex, IRQ 10
modprobe hisax type=3 protocol=2 io=0x280 irq=10
 
2. Teles 16.0, 1TR6 ISDN, I/O base d80 hex, IRQ 5, Memory d0000 hex
modprobe hisax protocol=1 type=1 io=0xd80 mem=0xd0000 irq=5
 
3. Fritzcard, Euro ISDN, I/O base 340 hex, IRQ 10 and ELSA PCF, Euro ISDN
modprobe hisax type=5,6 protocol=2,2 io=0x340 irq=10 id=Fritz%Elsa
 
4. Any ELSA PCC/PCF card, Euro ISDN
modprobe hisax type=6 protocol=2
 
5. Teles 16.3 PnP, Euro ISDN, with isapnp configured
isapnp config: (INT 0 (IRQ 10 (MODE +E)))
(IO 0 (BASE 0x0580))
(IO 1 (BASE 0x0180))
modprobe hisax type=4 protocol=2 irq=10 io0=0x580 io1=0x180
 
6. Teles 16.3, Euro ISDN, I/O base 280 hex, IRQ 12 and
Teles 16.0, 1TR6, IRQ 5, Memory d0000 hex
modprobe hisax type=3,1 protocol=2,1 io=0x280 mem=0,0xd0000
 
Please note the dummy 0 memory address for the Teles 16.3, used as a
placeholder as described above, in the last example.
 
7. Teles PCMCIA, Euro ISDN, I/O base 180 hex, IRQ 15 (default values)
modprobe hisax type=8 protocol=2 io=0x180 irq=15
 
 
b) using LILO/LOADLIN, with the driver compiled directly into the kernel
------------------------------------------------------------------------
 
hisax=typ1,dp1,pa_1,pb_1,pc_1[,typ2,dp2,pa_2 ... \
typn,dpn,pa_n,pb_n,pc_n][,idstring1[,idstring2,...,idstringn]]
 
where
typ1 = type of 1st card (default depends on kernel settings)
dp1 = D-Channel protocol of 1st card. 1=1TR6, 2=EDSS1, 3=leased
pa_1 = 1st parameter (depending on the type of the card)
pb_1 = 2nd parameter ( " " " " " " " )
pc_1 = 3rd parameter ( " " " " " " " )
 
typ2,dp2,pa_2,pb_2,pc_2 = Parameters of the second card (defaults: none)
typn,dpn,pa_n,pb_n,pc_n = Parameters of the n'th card (up to 16 cards are
supported)
 
idstring = Driver ID for accessing the particular card with utility
programs and for identification when using a line monitor
(default: "HiSax")
 
Note: the ID string must start with an alphabetical character!
 
Card types:
 
type
1 Teles 16.0 pa=irq pb=membase pc=iobase
2 Teles 8.0 pa=irq pb=membase
3 Teles 16.3 pa=irq pb=iobase
4 Creatix/Teles PNP ONLY WORKS AS A MODULE !
5 AVM A1 (Fritz) pa=irq pb=iobase
6 ELSA PCC/PCF cards pa=iobase or nothing for autodetect
7 ELSA Quickstep 1000 ONLY WORKS AS A MODULE !
8 Teles S0 PCMCIA pa=irq pb=iobase
9 ITK ix1-micro Rev.2 pa=irq pb=iobase
10 ELSA PCMCIA pa=irq, pb=io (set with card manager)
11 Eicon.Diehl Diva ISAPnP ONLY WORKS AS A MODULE !
11 Eicon.Diehl Diva PCI no parameter
12 ASUS COM ISDNLink ONLY WORKS AS A MODULE !
13 HFC-2BS0 based cards pa=irq pb=io
14 Teles 16.3c PnP ONLY WORKS AS A MODULE !
15 Sedlbauer Speed Card pa=irq pb=io (Speed Win only as module !)
15 Sedlbauer PC/104 pa=irq pb=io
15 Sedlbauer Speed PCI no parameter
16 USR Sportster internal pa=irq pb=io
17 MIC card pa=irq pb=io
18 ELSA Quickstep 1000PCI no parameter
19 Compaq ISDN S0 ISA card ONLY WORKS AS A MODULE !
20 NETjet PCI card no parameter
21 Teles PCI no parameter
22 Sedlbauer Speed Star (PCMCIA) pa=irq, pb=io (set with card manager)
24 Dr. Neuhaus Niccy PnP ONLY WORKS AS A MODULE !
24 Dr. Neuhaus Niccy PCI no parameter
25 Teles S0Box irq, io (of the used lpt port)
26 AVM A1 PCMCIA (Fritz!) irq, io (set with card manager)
27 AVM PnP (Fritz!PnP) ONLY WORKS AS A MODULE !
27 AVM PCI (Fritz!PCI) no parameter
28 Sedlbauer Speed Fax+ ONLY WORKS AS A MODULE !
 
 
Running the driver
------------------
 
When you insmod isdn.o and hisax.o (or with the in-kernel version, during
boot time), a few lines should appear in your syslog. Look for something like:
 
Apr 13 21:01:59 kke01 kernel: HiSax: Driver for Siemens chip set ISDN cards
Apr 13 21:01:59 kke01 kernel: HiSax: Version 2.9
Apr 13 21:01:59 kke01 kernel: HiSax: Revisions 1.14/1.9/1.10/1.25/1.8
Apr 13 21:01:59 kke01 kernel: HiSax: Total 1 card defined
Apr 13 21:01:59 kke01 kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax1 (0)
Apr 13 21:01:59 kke01 kernel: HiSax: Elsa driver Rev. 1.13
...
Apr 13 21:01:59 kke01 kernel: Elsa: PCF-Pro found at 0x360 Rev.:C IRQ 10
Apr 13 21:01:59 kke01 kernel: Elsa: timer OK; resetting card
Apr 13 21:01:59 kke01 kernel: Elsa: HSCX version A: V2.1 B: V2.1
Apr 13 21:01:59 kke01 kernel: Elsa: ISAC 2086/2186 V1.1
...
Apr 13 21:01:59 kke01 kernel: HiSax: DSS1 Rev. 1.14
Apr 13 21:01:59 kke01 kernel: HiSax: 2 channels added
 
This means that the card is ready for use.
Cabling problems or line-downs are not detected, and only some ELSA cards can
detect the S0 power.
 
Remember that, according to the new strategy for accessing low-level drivers
from within isdn4linux, you should also define a driver ID while doing
insmod: Simply append hisax_id=<SomeString> to the insmod command line. This
string MUST NOT start with a digit or a small 'x'!
 
At this point you can run a 'cat /dev/isdnctrl0' and view debugging messages.
 
At the moment, debugging messages are enabled with the hisaxctrl tool:
 
hisaxctrl <DriverId> DebugCmd <debugging_flags>
 
<DriverId> default is HiSax, if you didn't specify one.
 
DebugCmd is 1 for generic debugging
11 for layer 1 development debugging
13 for layer 3 development debugging
 
where <debugging_flags> is the integer sum of the following debugging
options you wish enabled:
 
With DebugCmd set to 1:
 
0x0001 Link-level <--> hardware-level communication
0x0002 Top state machine
0x0004 D-Channel Frames for isdnlog
0x0008 D-Channel Q.921
0x0010 B-Channel X.75
0x0020 D-Channel l2
0x0040 B-Channel l2
0x0080 D-Channel link state debugging
0x0100 B-Channel link state debugging
0x0200 TEI debug
0x0400 LOCK debug in callc.c
0x0800 More paranoid debug in callc.c (not for normal use)
0x1000 D-Channel l1 state debugging
0x2000 B-Channel l1 state debugging
 
With DebugCmd set to 11:
 
0x0001 Warnings (default: on)
0x0002 IRQ status
0x0004 ISAC
0x0008 ISAC FIFO
0x0010 HSCX
0x0020 HSCX FIFO (attention: full B-Channel output!)
0x0040 D-Channel LAPD frame types
0x0080 IPAC debug
0x0100 HFC receive debug
0x0200 ISAC monitor debug
0x0400 D-Channel frames for isdnlog (set with 1 0x4 too)
0x0800 D-Channel message verbose
 
With DebugCmd set to 13:
 
1 Warnings (default: on)
2 l3 protocol descriptor errors
4 l3 state machine
8 charge info debugging (1TR6)
 
For example, 'hisaxctrl HiSax 1 0x3ff' enables full generic debugging.
 
Because of some obscure problems with some switch equipment, the delay
between the CONNECT message and sending the first data on the B-channel is now
configurable with
 
hisaxctrl <DriverId> 2 <delay>
<delay> in ms Value between 50 and 800 ms is recommended.
 
Downloading Firmware
--------------------
At the moment, the Sedlbauer speed fax+ is the only card, which
needs to download firmware.
The firmware is downloaded with the hisaxctrl tool:
 
hisaxctrl <DriverId> 9 <firmware_filename>
 
<DriverId> default is HiSax, if you didn't specify one,
 
where <firmware_filename> is the filename of the firmware file.
 
For example, 'hisaxctrl HiSax 9 ISAR.BIN' downloads the firmware for
ISAR based cards (like the Sedlbauer speed fax+).
 
Warning
-------
HiSax is a work in progress and may crash your machine.
For certification look at HiSax.cert file.
 
Limitations
-----------
At this time, HiSax only works on Euro ISDN lines and German 1TR6 lines.
For leased lines see appendix.
 
Bugs
----
If you find any, please let me know.
 
 
Thanks
------
Special thanks to:
 
Emil Stephan for the name HiSax which is a mix of HSCX and ISAC.
 
Fritz Elfert, Jan den Ouden, Michael Hipp, Michael Wein,
Andreas Kool, Pekka Sarnila, Sim Yskes, Johan Myrre'en,
Klaus-Peter Nischke (ITK AG), Christof Petig, Werner Fehn (ELSA GmbH),
Volker Schmidt
Edgar Toernig and Marcus Niemann for the Sedlbauer driver
Stephan von Krawczynski
Juergen Quade for the Leased Line part
Klaus Lichtenwalder (Klaus.Lichtenwalder@WebForum.DE), for ELSA PCMCIA support
Enrik Berkhan (enrik@starfleet.inka.de) for S0BOX specific stuff
Ton van Rosmalen for Teles PCI
and more people who are hunting bugs. (If I forgot somebody, please
send me a mail).
 
Firma ELSA GmbH
Firma Eicon.Diehl GmbH
Firma Dynalink NL
Firma ASUSCOM NETWORK INC. Taiwan
Firma S.u.S.E
Firma ith Kommunikationstechnik GmbH
Firma Traverse Technologie Australia
Firma Medusa GmbH (www.medusa.de).
Firma Quant-X Austria for sponsoring a DEC Alpha board+CPU
Firma Cologne Chip Designs GmbH
 
My girl friend and partner in life Ute for her patience with me.
 
 
Enjoy,
 
Karsten Keil
keil@isdn4linux.de
 
 
Appendix: Teles PCMCIA driver
-----------------------------
 
See
http://www.stud.uni-wuppertal.de/~ea0141/pcmcia.html
for instructions.
 
Appendix: Linux and ISDN-leased lines
-------------------------------------
 
Original from Juergen Quade, new version KKe.
 
Attention NEW VERSION, the old leased line syntax won't work !!!
 
You can use HiSax to connect your Linux-Box via an ISDN leased line
to e.g. the Internet:
 
1. Build a kernel which includes the HiSax driver either as a module
or as part of the kernel.
cd /usr/src/linux
make menuconfig
<ISDN subsystem - ISDN support -- HiSax>
make clean; make dep; make zImage; make modules; make modules_install
2. Install the new kernel
cp /usr/src/linux/arch/i386/boot/zImage /etc/kernel/linux.isdn
vi /etc/lilo.conf
<add new kernel in the bootable image section>
lilo
3. in case the hisax driver is a "fixed" part of the kernel, configure
the driver with lilo:
vi /etc/lilo.conf
<add HiSax driver parameter in the global section (see below)>
lilo
Your lilo.conf _might_ look like the following:
 
# LILO configuration-file
# global section
# teles 16.0 on IRQ=5, MEM=0xd8000, PORT=0xd80
append="hisax=1,3,5,0xd8000,0xd80,HiSax"
# teles 16.3 (non pnp) on IRQ=15, PORT=0xd80
# append="hisax=3,3,5,0xd8000,0xd80,HiSax"
boot=/dev/sda
compact # faster, but won't work on all systems.
linear
read-only
prompt
timeout=100
vga = normal # force sane state
# Linux bootable partition config begins
image = /etc/kernel/linux.isdn
root = /dev/sda1
label = linux.isdn
#
image = /etc/kernel/linux-2.0.30
root = /dev/sda1
label = linux.secure
 
In the line starting with "append" you have to adapt the parameters
according to your card (see above in this file)
 
3. boot the new linux.isdn kernel
4. start the ISDN subsystem:
a) load - if necessary - the modules (depends, whether you compiled
the ISDN driver as module or not)
According to the type of card you have to specify the necessary
driver parameter (irq, io, mem, type, protocol).
For the leased line the protocol is "3". See the table above for
the parameters, which you have to specify depending on your card.
b) configure i4l
/sbin/isdnctrl addif isdn0
# EAZ 1 -- B1 channel 2 --B2 channel
/sbin/isdnctrl eaz isdn0 1
/sbin/isdnctrl secure isdn0 on
/sbin/isdnctrl huptimeout isdn0 0
/sbin/isdnctrl l2_prot isdn0 hdlc
# Attention you must not set an outgoing number !!! This won't work !!!
# The incomming number is LEASED0 for the first card, LEASED1 for the
# second and so on.
/sbin/isdnctrl addphone isdn0 in LEASED0
# Here is no need to bind the channel.
c) in case the remote partner is a CISCO:
/sbin/isdnctrl encap isdn0 cisco-h
d) configure the interface
/sbin/ifconfig isdn0 ${LOCAL_IP} pointopoint ${REMOTE_IP}
e) set the routes
/sbin/route add -host ${REMOTE_IP} isdn0
/sbin/route add default gw ${REMOTE_IP}
f) switch the card into leased mode for each used B-channel
/sbin/hisaxctrl HiSax 5 1
 
Remarks:
a) If you have a CISCO don't forget to switch off the KEEP ALIVE option!
b) Use state of the art isdn4k-utils
 
Here an example script:
#!/bin/sh
# Start/Stop ISDN lesaed line connection
 
I4L_AS_MODULE=yes
I4L_REMOTE_IS_CISCO=no
I4L_MODULE_PARAMS="type=16 io=0x268 irq=7 "
I4L_DEBUG=no
I4L_LEASED_128K=yes
LOCAL_IP=192.168.1.1
REMOTE_IP=192.168.2.1
 
case "$1" in
start)
echo "Starting ISDN ..."
if [ ${I4L_AS_MODULE} = "yes" ]; then
echo "loading modules..."
/sbin/modprobe hisax ${I4L_MODULE_PARAMS}
fi
# configure interface
/sbin/isdnctrl addif isdn0
/sbin/isdnctrl secure isdn0 on
if [ ${I4L_DEBUG} = "yes" ]; then
/sbin/isdnctrl verbose 7
/sbin/hisaxctrl HiSax 1 0xffff
/sbin/hisaxctrl HiSax 11 0xff
cat /dev/isdnctrl >/tmp/lea.log &
fi
if [ ${I4L_REMOTE_IS_CISCO} = "yes" ]; then
/sbin/isdnctrl encap isdn0 cisco-h
fi
/sbin/isdnctrl huptimeout isdn0 0
# B-CHANNEL 1
/sbin/isdnctrl eaz isdn0 1
/sbin/isdnctrl l2_prot isdn0 hdlc
# 1. card
/sbin/isdnctrl addphone isdn0 in LEASED0
if [ ${I4L_LEASED_128K} = "yes" ]; then
/sbin/isdnctrl addslave isdn0 isdn0s
/sbin/isdnctrl secure isdn0s on
/sbin/isdnctrl huptimeout isdn0s 0
# B-CHANNEL 2
/sbin/isdnctrl eaz isdn0s 2
/sbin/isdnctrl l2_prot isdn0s hdlc
# 1. card
/sbin/isdnctrl addphone isdn0s in LEASED0
if [ ${I4L_REMOTE_IS_CISCO} = "yes" ]; then
/sbin/isdnctrl encap isdn0s cisco-h
fi
fi
/sbin/isdnctrl status isdn0 on
# configure tcp/ip
/sbin/ifconfig isdn0 ${LOCAL_IP} pointopoint ${REMOTE_IP}
/sbin/route add -host ${REMOTE_IP} isdn0
/sbin/route add default gw ${REMOTE_IP}
# switch to leased mode
# B-CHANNEL 1
/sbin/hisaxctrl HiSax 5 1
if [ ${I4L_LEASED_128K} = "yes" ]; then
# B-CHANNEL 2
/sbin/hisaxctrl HiSax 5 2
fi
;;
stop)
/sbin/ifconfig isdn0 down
/sbin/isdnctrl delif isdn0
if [ ${I4L_DEBUG} = "yes" ]; then
killall cat
fi
if [ ${I4L_AS_MODULE} = "yes" ]; then
/sbin/rmmod hisax
/sbin/rmmod isdn
/sbin/rmmod ppp
/sbin/rmmod slhc
fi
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
esac
exit 0
 
/CREDITS
0,0 → 1,54
 
I want to thank all who contributed to this project and especially to:
(in alphabetical order)
 
 
Tester, lots of bugfixes and hints.
 
Alan Cox (alan@cymru.net)
For help getting into standard-kernel.
 
 
For contribution of man-pages, the imontty-tool and a perfect
maintaining of the mailing-list at hub-wue.
 
Bernhard Hailer (Bernhard.Hailer@lrz.uni-muenchen.de)
For maintaining the FAQ.
 
Michael 'Ghandi' Herold (michael@abadonna.franken.de)
For contribution of the vbox answering machine.
 
Michael Hipp (Michael.Hipp@student.uni-tuebingen.de)
For his Sync-PPP-code.
 
Karsten Keil (isdn4@temic-ech.spacenet.de)
For adding 1TR6-support to the Teles-driver.
For the HiSax-driver.
 
Michael Knigge (knick@cove.han.de)
For contributing the imon-tool
 
Andreas Kool (akool@Kool.f.EUnet.de)
For contribution of the isdnlog/isdnrep-tool
 
Pedro Roque Marques (roque@di.fc.ul.pt)
For lot of new ideas and the pcbit driver.
 
Eberhard Moenkeberg (emoenke@gwdg.de)
For testing and help to get into kernel.
 
Jan den Ouden (denouden@groovin.xs4all.nl)
For contribution of the teles-driver
 
Max Riegel (riegel@max.franken.de)
For making the ICN hardware-documentation and test-equipment available.
 
Gerhard 'Fido' Schneider (fido@wuff.franken.de)
For heavy-duty-beta-testing with his BBS ;)
 
Thomas Uhl (uhl@think.de)
For distributing the cards.
For pushing me to work ;-)
 
Carsten Paeth (calle@calle.in-berlin.de)
For the AVM-B1-CAPI2.0 driver
/README.pcbit
0,0 → 1,40
------------------------------------------------------------------------------
README file for the PCBIT-D Device Driver.
------------------------------------------------------------------------------
 
The PCBIT is a Euro ISDN adapter manufactured in Portugal by Octal and
developed in cooperation with Portugal Telecom and Inesc.
The driver interfaces with the standard kernel isdn facilities
originally developed by Fritz Elfert in the isdn4linux project.
 
The common versions of the pcbit board require a firmware that is
distributed (and copyrighted) by the manufacturer. To load this
firmware you need "pcbitctl" available on the standard isdn4k-utils
package or in the pcbit package available in:
 
ftp://ftp.di.fc.ul.pt/pub/systems/Linux/isdn
 
Known Limitations:
 
- The board reset proceeding is at the moment incorrect and will only
allow you to load the firmware after a hard reset.
 
- Only HDLC in B-channels is supported at the moment. There is now
current support to X.25 in B or D channels nor LAPD in B
channels. The main reason is that this two other protocol modes have,
to my knowledge, very little use. If you want to see them implemented
*do* send me a mail.
 
- The driver often triggers errors in the board that i and the
manufacturer believe to be caused by bugs in the firmware. The current
version includes several proceedings for error recovery that should
allow normal operation. Plans for the future include cooperation with
the manufacturer in order to solve this problems.
 
Information/hints/help can be obtained in the linux isdn
mailing list (isdn4linux@hub-wue.franken.de) or directly from me.
 
regards,
Pedro.
<roque@di.fc.ul.pt>
/README
0,0 → 1,534
README for the ISDN-subsystem
 
1. Preface
 
1.1 Introduction
 
This README describes how to set up and how to use the different parts
of the ISDN-subsystem.
 
For using the ISDN-subsystem, some additional userlevel programs are
necessary. Those programs and some contributed utilities are available
at
 
ftp.franken.de
 
/pub/isdn4linux/isdn4k-utils-<VersionNumber>.tar.gz
 
 
We also have set up a mailing-list:
 
The isdn4linux-project originates in Germany, and therefore by historical
reasons, the mailing-list's primary language is german. However mails
written in english have been welcome all the time.
 
to subscribe: write a email to majordomo@hub-wue.franken.de,
Subject irrelevant, in the message body:
subscribe isdn4linux <your_email_address>
 
To write to the mailing-list, write to isdn4linux@hub-wue.franken.de
 
This mailinglist is bidirectionally gated to the newsgroup
 
de.alt.comm.isdn4linux
There is also a well maintained FAQ (both english and german) available
at ftp.franken.de in /pub/isdn4linux/FAQ/
This FAQ is also available at http://www.lrz-muenchen.de/~ui161ab/www/isdn/
 
1.1 Technical details
 
In the following Text, the terms MSN and EAZ are used.
 
MSN is the abbreviation for (M)ultiple(S)ubscriber(N)umber, and applies
to Euro(EDSS1)-type lines. Usually it is simply the phone number.
 
EAZ is the abbreviation of (E)ndgeraete(A)uswahl(Z)iffer and
applies to German 1TR6-type lines. This is a one-digit string,
simply appended to the base phone number
 
The internal handling is nearly identical, so replace the appropriate
term to that one, which applies to your local ISDN-environment.
 
When the link-level-module isdn.o is loaded, it supports up to 16
low-level-modules with up to 64 channels. (The number 64 is arbitrarily
chosen and can be configured at compile-time --ISDN_MAX in isdn.h).
A low-level-driver can register itself through an interface (which is
defined in isdnif.h) and gets assigned a slot.
The following char-devices are made available for each channel:
A raw-control-device with the following functions:
write: raw D-channel-messages (format: depends on driver).
read: raw D-channel-messages (format: depends on driver).
ioctl: depends on driver, i.e. for the ICN-driver, the base-address of
the ports and the shared memory on the card can be set and read
also the boot-code and the protocol software can be loaded into
the card.
 
O N L Y !!! for debugging (no locking against other devices):
One raw-data-device with the following functions:
write: data to B-channel.
read: data from B-channel.
 
In addition the following devices are made available:
 
128 tty-devices (64 cuix and 64 ttyIx) with integrated modem-emulator:
The functionality is almost the same as that of a serial device
(the line-discs are handled by the kernel), which lets you run
SLIP, CSLIP and asynchronous PPP through the devices. We have tested
Seyon, minicom, CSLIP (uri-dip) PPP and mgetty (compiled with NO_FAX),
XCept.
 
The modem-emulation supports the following:
1.3.1 Commands:
 
ATA Answer incoming call.
ATD<No.> Dial, the number may contain:
[0-9] and [,#.*WPT-S]
the latter are ignored until 'S'.
The 'S' must precede the number, if
the line is a SPV (German 1TR6).
ATE0 Echo off.
ATE1 Echo on (default).
ATH Hang-up.
ATH1 Off hook (ignored).
ATH0 Hang-up.
ATI Return "ISDN for Linux...".
ATI0 "
ATI1 "
ATI2 Report of last connection.
ATO On line (data mode).
ATQ0 Enable result codes (default).
ATQ1 Disable result codes (default).
ATSx=y Set register x to y.
ATSx? Show contents of register x.
ATV0 Numeric responses.
ATV1 English responses (default).
ATZ Load registers and EAZ/MSN from Profile.
AT&Bx Set Send-Packet-size to x (max. 4000)
The real packet-size may be limited by the
low-level-driver used. e.g. the HiSax-Module-
limit is 2000. You will get NO Error-Message,
if you set it to higher values, because at the
time of giving this command the corresponding
driver may not be selected (see "Automatic
Assignment") however the size of outgoing packets
will be limited correctly.
AT&D0 Ignore DTR
AT&D2 DTR-low-edge: Hang up and return to
command mode (default).
AT&D3 Same as AT&D2 but also resets all registers.
AT&Ex Set the EAZ/MSN for this channel to x.
AT&F Reset all registers and profile to "factory-defaults"
AT&Sx Set window-size (x = 1..8) (not yet implemented)
AT&V Show all settings.
AT&W0 Write registers and EAZ/MSN to profile. See also
iprofd (5.c in this README).
AT&X0 BTX-mode off (default)
AT&X1 BTX-mode on. (S13.1=1, S14=0, S16=7, S18=7, S19=0)
 
For voice-mode commands refer to README.audio
 
1.3.2 Escape sequence:
During a connection, the emulation reacts just like
a normal modem to the escape sequence <DELAY>+++<DELAY>.
(The escape character - default '+' - can be set in the
register 2).
The DELAY must at least be 1.5 seconds long and delay
between the escape characters must not exceed 0.5 seconds.
1.3.3 Registers:
 
Nr. Default Description
0 0 Answer on ring number.
(no auto-answer if S0=0).
1 0 Count of rings.
2 43 Escape character.
(a value >= 128 disables the escape sequence).
3 13 Carriage return character (ASCII).
4 10 Line feed character (ASCII).
5 8 Backspace character (ASCII).
6 3 Delay in seconds before dialing.
7 60 Wait for carrier (ignored).
8 2 Pause time for comma (ignored)
9 6 Carrier detect time (ignored)
10 7 Carrier loss to disconnect time (ignored).
11 70 Touch tone timing (ignored).
12 69 Bit coded register:
Bit 0: 0 = Suppress response messages.
1 = Show response messages.
Bit 1: 0 = English response messages.
1 = Numeric response messages.
Bit 2: 0 = Echo off.
1 = Echo on.
Bit 3 0 = DCD always on.
1 = DCD follows carrier.
Bit 4 0 = CTS follows RTS
1 = Ignore RTS, CTS always on.
Bit 5 0 = return to command mode on DTR low.
1 = Same as 0 but also resets all
registers.
See also register 13, bit 2
Bit 6 0 = DSR always on.
1 = DSR only on if channel is available.
Bit 7 0 = Cisco-PPP-flag-hack off (default).
1 = Cisco-PPP-flag-hack on.
13 0 Bit coded register:
Bit 0: 0 = Use delayed tty-send-algorithm
1 = Direct tty-send.
Bit 1: 0 = T.70 protocol (Only for BTX!) off
1 = T.70 protocol (Only for BTX!) on
Bit 2: 0 = Don't hangup on DTR low.
1 = Hangup on DTR low.
Bit 3: 0 = Standard response messages
1 = Extended response messages
Bit 4: 0 = CALLER NUMBER before every RING.
1 = CALLER NUMBER after first RING.
14 0 Layer-2 protocol:
0 = X75/LAPB with I-frames
1 = X75/LAPB with UI-frames
2 = X75/LAPB with BUI-frames
3 = HDLC
4 = Transparent (audio)
15 0 Layer-3 protocol: (at the moment always 0)
0 = transparent
16 250 Send-Packet-size/16
17 8 Window-size (not yet implemented)
18 4 Bit coded register, Service-Octet-1 to accept,
or to be used on dialout:
Bit 0: Service 1 (audio) when set.
Bit 1: Service 5 (BTX) when set.
Bit 2: Service 7 (data) when set.
Note: It is possible to set more than one
bit. In this case, on incoming calls
the selected services are accepted,
and if the service is "audio", the
Layer-2-protocol is automatically
changed to 4 regardless of the setting
of register 14. On outgoing calls,
the most significant 1-bit is chosen to
select the outgoing service octet.
19 0 Service-Octet-2
20 0 Bit coded register (readonly)
Service-Octet-1 of last call.
Bit mapping is the same as register 18
21 0 Bit coded register (readonly)
Set on incoming call (during RING) to
octet 3 of calling party number IE (Numbering plan)
See section 4.5.10 of ITU Q.931
22 0 Bit coded register (readonly)
Set on incoming call (during RING) to
octet 3a of calling party number IE (Screening info)
See section 4.5.10 of ITU Q.931
 
Last but not least a (at the moment fairly primitive) device to request
the line-status (/dev/isdninfo) is made available.
 
Automatic assignment of devices to lines:
 
All inactive physical lines are listening to all EAZs for incoming
calls and are NOT assigned to a specific tty or network interface.
When an incoming call is detected, the driver looks first for a network
interface and then for an opened tty which:
 
1. is configured for the same EAZ.
2. has the same protocol settings for the B-channel.
3. (only for network interfaces if the security flag is set)
contains the caller number in its access list.
4. Either the channel is not bound exclusively to another Net-interface, or
it is bound AND the other checks apply to exactly this interface.
(For usage of the bind-features, refer to the isdnctrl-man-page)
 
Only when a matching interface or tty is found is the call accepted
and the "connection" between the low-level-layer and the link-level-layer
is established and kept until the end of the connection.
In all other cases no connection is established. Isdn4linux can be
configured to either do NOTHING in this case (which is useful, if
other, external devices with the same EAZ/MSN are connected to the bus)
or to reject the call actively. (isdnctrl busreject ...)
 
For an outgoing call, the inactive physical lines are searched.
The call is placed on the first physical line, which supports the
requested protocols for the B-channel. If a net-interface, however
is pre-bound to a channel, this channel is used directly.
 
This makes it possible to configure several network interfaces and ttys
for one EAZ, if the network interfaces are set to secure operation.
If an incoming call matches one network interface, it gets connected to it.
If another incoming call for the same EAZ arrives, which does not match
a network interface, the first tty gets a "RING" and so on.
As soon as voice gets supported (with the availability of the Diehl-driver),
the service-identifier will be evaluated in addition.
 
2 System prerequisites:
 
ATTENTION!
 
Always use the latest module utilities. The current version is
named in Documentation/Changes. Some old versions of insmod
are not capable of setting the driver-Ids correctly.
3. Lowlevel-driver configuration.
 
Configuration depends on how the drivers are built. See the
README.<yourDriver> for information on driver-specific setup.
 
4. Device-inodes
 
The major and minor numbers and their names are described in
Documentation/devices.txt. The major numbers are:
 
43 for the ISDN-tty's.
44 for the ISDN-callout-tty's.
45 for control/info/debug devices.
 
5. Application
 
a) For some card-types, firmware has to be loaded into the cards, before
proceeding with device-independent setup. See README.<yourDriver>
for how to do that.
 
b) If you only intend to use ttys, you are nearly ready now.
 
c) If you want to have really permanent "Modem"-settings on disk, you
can start the daemon iprofd. Give it a path to a file at the command-
line. It will store the profile-settings in this file every time
an AT&W0 is performed on any ISDN-tty. If the file already exists,
all profiles are initialized from this file. If you want to unload
any of the modules, kill iprofd first.
 
d) For networking, continue: Create an interface:
isdnctrl addif isdn0
 
e) Set the EAZ (or MSN for Euro-ISDN):
isdnctrl eaz isdn0 2
 
(For 1TR6 a single digit is allowed, for Euro-ISDN the number is your
real MSN e.g.: Phone-Number)
 
f) Set the number for outgoing calls on the interface:
isdnctrl addphone isdn0 out 1234567
... (this can be executed more than once, all assigned numbers are
tried in order)
and the number(s) for incoming calls:
isdnctrl addphone isdn0 in 1234567
 
g) Set the timeout for hang-up:
isdnctrl huptimeout isdn0 <timeout_in_seconds>
 
h) additionally you may activate charge-hang-up (= Hang up before
next charge-info, this only works, if your isdn-provider transmits
the charge-info during and after the connection):
isdnctrl chargehup isdn0 on
 
i) Set the dial mode of the interface:
isdnctrl dialmode isdn0 auto
"off" means that you (or the system) cannot make any connection
(neither incoming or outgoing connections are possible). Use
this if you want to be sure that no connections will be made.
"auto" means that the interface is in auto-dial mode, and will
attempt to make a connection whenever a network data packet needs
the interface's link. Note that this can cause unexpected dialouts,
and lead to a high phone bill! Some daemons or other pc's that use
this interface can cause this.
Incoming connections are also possible.
"manual" 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
sdn0". However, after an idle time of no traffic as configured for
the huptimeout value with isdnctrl, the connection _will_ be ended.
If you don't want any automatic hangup, set the huptimeout value to 0.
"manual" is the default.
 
j) Setup the interface with ifconfig as usual, and set a route to it.
 
k) (optional) If you run X11 and have Tcl/Tk-wish version 4.0, you can use
the script tools/tcltk/isdnmon. You can add actions for line-status
changes. See the comments at the beginning of the script for how to
do that. There are other tty-based tools in the tools-subdirectory
 
Andreas Kool (isdnmon).
 
l) For initial testing, you can set the verbose-level to 2 (default: 0).
Then all incoming calls are logged, even if they are not addressed
to one of the configured net-interfaces:
isdnctrl verbose 2
 
Now you are ready! A ping to the set address should now result in an
automatic dial-out (look at syslog kernel-messages).
The phone numbers and EAZs can be assigned at any time with isdnctrl.
You can add as many interfaces as you like with addif following the
directions above. Of course, there may be some limitations. But we have
tested as many as 20 interfaces without any problem. However, if you
don't give an interface name to addif, the kernel will assign a name
which starts with "eth". The number of "eth"-interfaces is limited by
the kernel.
 
5. Additional options for isdnctrl:
 
"isdnctrl secure <InterfaceName> on"
Only incoming calls, for which the caller-id is listed in the access
list of the interface are accepted. You can add caller-id's With the
command "isdnctrl addphone <InterfaceName> in <caller-id>"
Euro-ISDN does not transmit the leading '0' of the caller-id for an
incoming call, therefore you should configure it accordingly.
If the real number for the dialout e.g. is "09311234567" the number
to configure here is "9311234567". The pattern-match function
works similar to the shell mechanism.
 
? one arbitrary digit
* zero or arbitrary many digits
[123] one of the digits in the list
[1-5] one digit between '1' and '5'
a '^' as the first character in a list inverts the list
 
 
"isdnctrl secure <InterfaceName> off"
Switch off secure operation (default).
 
"isdnctrl ihup <InterfaceName> [on|off]"
Switch the hang-up-timer for incoming calls on or off.
 
"isdnctrl eaz <InterfaceName>"
Returns the EAZ of an interface.
 
"isdnctrl delphone <InterfaceName> in|out <number>"
Deletes a number from one of the access-lists of the interface.
 
"isdnctrl delif <InterfaceName>"
Removes the interface (and possible slaves) from the kernel.
(You have to unregister it with "ifconfig <InterfaceName> down" before).
 
"isdnctrl callback <InterfaceName> [on|off]"
Switches an interface to callback-mode. In this mode, an incoming call
will be rejected and after this the remote-station will be called. If
you test this feature by using ping, some routers will re-dial very
quickly, so that the callback from isdn4linux may not be recognized.
In this case use ping with the option -i <sec> to increase the interval
between echo-packets.
 
"isdnctrl cbdelay <InterfaceName> [seconds]"
Sets the delay (default 5 sec) between an incoming call and start of
dialing when callback is enabled.
 
"isdnctrl cbhup <InterfaceName> [on|off]"
This enables (default) or disables an active hangup (reject) when getting an
incoming call for an interface which is configured for callback.
 
"isdnctrl encap <InterfaceName> <EncapType>"
Selects the type of packet-encapsulation. The encapsulation can be changed
only while an interface is down.
 
At the moment the following values are supported:
rawip (Default) Selects raw-IP-encapsulation. This means, MAC-headers
are stripped off.
ip IP with type-field. Same as IP but the type-field of the MAC-header
is preserved.
cisco-h A special-mode for communicating with a Cisco, which is configured
to do "hdlc"
ethernet No stripping. Packets are sent with full MAC-header.
The Ethernet-address of the interface is faked, from its
IP-address: fc:fc:i1:i2:i3:i4, where i1-4 are the IP-addr.-values.
syncppp Synchronous PPP
 
uihdlc HDLC with UI-frame-header (for use with DOS ISPA, option -h1)
 
Watching packets, using standard-tcpdump will fail for all encapsulations
except ethernet because tcpdump does not know how to handle packets
without MAC-header. A patch for tcpdump is included in the utility-package
mentioned above.
 
"isdnctrl l2_prot <InterfaceName> <L2-ProtocolName>"
Selects a layer-2-protocol.
(With the ICN-driver and the HiSax-driver, "x75i" and "hdlc" is available.
With other drivers, "x75ui", "x75bui" may be possible too.)
 
isdnctrl l3_prot <InterfaceName> <L3-ProtocolName>
The same for layer-3. (At the moment only "trans" is allowed)
 
"isdnctrl list <InterfaceName>"
Shows all parameters of an interface and the charge-info.
Try "all" as the interface name.
 
"isdnctrl hangup <InterfaceName>"
Forces hangup of an interface.
 
"isdnctrl bind <InterfaceName> <DriverId>,<ChannelNumber> [exclusive]"
If you are using more than one ISDN card, it is sometimes necessary to
dial out using a specific card or even preserve a specific channel for
dialout of a specific net-interface. This can be done with the above
command. Replace <DriverId> by whatever you assigned while loading the
module. The <ChannelNumber> is counted from zero. The upper limit
depends on the card used. At the moment no card supports more than
2 channels, so the upper limit is one.
 
"isdnctrl unbind <InterfaceName>"
unbinds a previously bound interface.
 
"isdnctrl busreject <DriverId> on|off"
If switched on, isdn4linux replies a REJECT to incoming calls, it
cannot match to any configured interface.
If switched off, nothing happens in this case.
You normally should NOT enable this feature, if the ISDN adapter is not
the only device connected to the S0-bus. Otherwise it could happen that
isdn4linux rejects an incoming call, which belongs to another device on
the bus.
 
"isdnctrl addslave <InterfaceName> <SlaveName>
Creates a slave interface for channel-bundling. Slave interfaces are
not seen by the kernel, but their ISDN-part can be configured with
isdnctrl as usual. (Phone numbers, EAZ/MSN, timeouts etc.) If more
than two channels are to be bundled, feel free to create as many as you
want. InterfaceName must be a real interface, NOT a slave. Slave interfaces
start dialing, if the master interface resp. the previous slave interface
has a load of more than 7000 cps. They hangup if the load goes under 7000
cps, according to their "huptimeout"-parameter.
 
"isdnctrl sdelay <InterfaceName> secs."
This sets the minimum time an Interface has to be fully loaded, until
it sends a dial-request to its slave.
 
"isdnctrl dial <InterfaceName>"
Forces an interface to start dialing even if no packets are to be
transferred.
 
"isdnctrl mapping <DriverId> MSN0,MSN1,MSN2,...MSN9"
This installs a mapping table for EAZ<->MSN-mapping for a single line.
Missing MSN's have to be given as "-" or can be omitted, if at the end
of the commandline.
With this command, it's now possible to have an interface listening to
mixed 1TR6- and Euro-Type lines. In this case, the interface has to be
configured to a 1TR6-type EAZ (one digit). The mapping is also valid
for tty-emulation. Seen from the interface/tty-level the mapping
CAN be used, however it's possible to use single tty's/interfaces with
real MSN's (more digits) also, in which case the mapping will be ignored.
Here is an example:
 
You have a 1TR6-type line with base-nr. 1234567 and a Euro-line with
MSN's 987654, 987655 and 987656. The DriverId for the Euro-line is "EURO".
 
isdnctrl mapping EURO -,987654,987655,987656,-,987655
...
isdnctrl eaz isdn0 1 # listen on 12345671(1tr6) and 987654(euro)
...
isdnctrl eaz isdn1 4 # listen on 12345674(1tr6) only.
...
isdnctrl eaz isdn2 987654 # listen on 987654(euro) only.
Same scheme is used with AT&E... at the tty's.
6. If you want to write a new low-level-driver, you are welcome.
The interface to the link-level-module is described in the file INTERFACE.
If the interface should be expanded for any reason, don't do it
on your own, send me a mail containing the proposed changes and
some reasoning about them.
If other drivers will not be affected, I will include the changes
in the next release.
For developers only, there is a second mailing-list. Write to me
(fritz@isdn4linux.de), if you want to join that list.
 
Have fun!
 
-Fritz
 
/README.audio
0,0 → 1,127
$Id: README.audio,v 1.1.1.1 2001-09-10 07:44:10 simons Exp $
 
ISDN subsystem for Linux.
Description of audio mode.
 
When enabled during kernel configuration, the tty emulator of the ISDN
subsystem is capable of a reduced set of commands to support audio.
This document describes the commands supported and the format of
audio data.
 
Commands for enabling/disabling audio mode:
 
AT+FCLASS=8 Enable audio mode.
This affects the following registers:
S18: Bits 0 and 2 are set.
S16: Set to 48 and any further change to
larger values is blocked.
AT+FCLASS=0 Disable audio mode.
Register 18 is set to 4.
AT+FCLASS=? Show possible modes.
AT+FCLASS? Report current mode (0 or 8).
 
Commands supported in audio mode:
 
All audio mode commands have the one of the following form:
 
AT+Vxx? Show current setting.
AT+Vxx=? Show possible settings.
AT+Vxx=v Set simple parameter.
AT+Vxx=v,v ... Set complex parameter.
 
where xx is a two-character code and v are alphanumerical parameters.
The following commands are supported:
 
AT+VNH=x Auto hangup setting. NO EFFECT, supported
for compatibility only.
AT+VNH? Always reporting "1"
AT+VNH=? Always reporting "1"
 
AT+VIP Reset all audio parameters.
 
AT+VLS=x Line select. x is one of the following:
0 = No device.
2 = Phone line.
AT+VLS=? Always reporting "0,2"
AT+VLS? Show current line.
 
AT+VRX Start recording. Emulator responds with
CONNECT and starts sending audio data to
the application. See below for data format
 
AT+VSD=x,y Set silence-detection parameters.
Possible parameters:
x = 0 ... 31 sensitivity threshold level.
(default 0 , deactivated)
y = 0 ... 255 range of interval in units
of 0.1 second. (default 70)
AT+VSD=? Report possible parameters.
AT+VSD? Show current parameters.
 
AT+VSM=x Select audio data format.
Possible parameters:
2 = ADPCM-2
3 = ADPCM-3
4 = ADPCM-4
5 = aLAW
6 = uLAW
AT+VSM=? Show possible audio formats.
 
AT+VTX Start audio playback. Emulator responds
with CONNECT and starts sending audio data
received from the application via phone line.
General behavior and description of data formats/protocol.
when a connection is made:
 
On incoming calls, if the application responds to a RING
with ATA, depending on the calling service, the emulator
responds with either CONNECT (data call) or VCON (voice call).
On outgoing voice calls, the emulator responds with VCON
upon connection setup.
 
Audio recording.
 
When receiving audio data, a kind of bisync protocol is used.
Upon AT+VRX command, the emulator responds with CONNECT, and
starts sending audio data to the application. There are several
escape sequences defined, all using DLE (0x10) as Escape char:
 
<DLE><ETX> End of audio data. (i.e. caused by a
hangup of the remote side) Emulator stops
recording, responding with VCON.
<DLE><DC4> Abort recording, (send by appl.) Emulator
stops recording, sends DLE,ETX.
<DLE><DLE> Escape sequence for DLE in data stream.
<DLE>0 Touchtone "0" received.
...
<DLE>9 Touchtone "9" received.
<DLE># Touchtone "#" received.
<DLE>* Touchtone "*" received.
<DLE>A Touchtone "A" received.
<DLE>B Touchtone "B" received.
<DLE>C Touchtone "C" received.
<DLE>D Touchtone "D" received.
 
<DLE>q quiet. Silence detected after non-silence.
<DLE>s silence. Silence detected from the
start of recording.
 
Currently unsupported DLE sequences:
 
<DLE>c FAX calling tone received.
<DLE>b busy tone received.
 
Audio playback.
 
When sending audio data, upon AT+VTX command, emulator responds with
CONNECT, and starts transferring data from application to the phone line.
The same DLE sequences apply to this mode.
 
Full-Duplex-Audio:
 
When _both_ commands for recording and playback are given in _one_
AT-command-line (i.e.: "AT+VTX+VRX"), full-duplex-mode is selected.
In this mode, the only way to stop recording is sending <DLE><DC4>
and the only way to stop playback is to send <DLE><ETX>.
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.