diff options
Diffstat (limited to 'Documentation/isdn')
| -rw-r--r-- | Documentation/isdn/00-INDEX | 21 | ||||
| -rw-r--r-- | Documentation/isdn/CREDITS | 45 | ||||
| -rw-r--r-- | Documentation/isdn/INTERFACE | 644 | ||||
| -rw-r--r-- | Documentation/isdn/README | 620 | ||||
| -rw-r--r-- | Documentation/isdn/README.audio | 119 | ||||
| -rw-r--r-- | Documentation/isdn/README.icn | 64 | ||||
| -rw-r--r-- | Documentation/isdn/README.pcbit | 40 | ||||
| -rw-r--r-- | Documentation/isdn/README.syncppp | 58 | ||||
| -rw-r--r-- | Documentation/isdn/README.teles | 73 | ||||
| -rw-r--r-- | Documentation/isdn/syncPPP.FAQ | 224 |
10 files changed, 1908 insertions, 0 deletions
diff --git a/Documentation/isdn/00-INDEX b/Documentation/isdn/00-INDEX new file mode 100644 index 000000000..b707c346d --- /dev/null +++ b/Documentation/isdn/00-INDEX @@ -0,0 +1,21 @@ +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.pcbit + - info on the PCBIT-D ISDN adapter and driver. +README.syncppp + - info on running Sync PPP over ISDN. +README.teles + - info on driver for Teles compatible ISDN cards. +syncPPP.FAQ + - frequently asked questions about running PPP over ISDN. + diff --git a/Documentation/isdn/CREDITS b/Documentation/isdn/CREDITS new file mode 100644 index 000000000..6c546c4e1 --- /dev/null +++ b/Documentation/isdn/CREDITS @@ -0,0 +1,45 @@ + +I want to thank all who contributed to this project and especially to: +(in alphabetical order) + +Thomas Bogendörfer (tsbogend@bigbug.franken.de) + Tester, lots of bugfixes and hints. + +Alan Cox (alan@cymru.net) + For help getting into standard-kernel. + +Volker Götz (volker@oops.franken.de) + For contribution of man-pages, the imontty-tool and a perfect + maintaining of the mailing-list at hub-wue. + +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. + +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@hn-net.de) + For distributing the cards. + For pushing me to work ;-) + diff --git a/Documentation/isdn/INTERFACE b/Documentation/isdn/INTERFACE new file mode 100644 index 000000000..6ba401123 --- /dev/null +++ b/Documentation/isdn/INTERFACE @@ -0,0 +1,644 @@ +$Id: INTERFACE,v 1.3 1996/06/25 17:52:41 fritz 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); + + ***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. 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) + +***CHANGEc1.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) + +***CHANGEc1.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: + + + 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 + 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) + num = An ASCII-String containing the number to dial, the own + EAZ or MSN, the Service-Indicator and the Additional + Info. Format: + "%s,%s,%d,%d" RemotePhoneNumber,EazOrMsn,SI,AI + If the Line has been designed as SPV (a special german + feature, meaning semi-leased-line) the number 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) + num = 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) + num = 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) + num = 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) + num = 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) + 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) + 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) + 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) + 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... + num = 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) + num = 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... + num = 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) + num = 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. + num = 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. + num = 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. + num = 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) + num = ASCII-String in the following format: + "%s,%d,%d,%s",CallerNumber,ServiceIndicator,AddInfo, + CalledNumber. + + 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. + num = 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. + num = 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) + num = 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) + num = 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) + num = 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) + num = 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) + 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. + num = 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) + num = 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) + num = 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. + num = 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) + num = ASCII string containing CAUSE-message. + diff --git a/Documentation/isdn/README b/Documentation/isdn/README new file mode 100644 index 000000000..36cc1336f --- /dev/null +++ b/Documentation/isdn/README @@ -0,0 +1,620 @@ +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 + + + 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, 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 an 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 " + 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. i.e.: the Teles-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 for Teles-driver (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. + 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 for Teles-driver (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 like register 18 + + 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 + interfaces 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 exact this Interface. + (For usage of the bind-features, refer to the isdnctrl-man-page) + + Only when a matching interface or tty is found, the call is 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! The program "insmod" from the Package "modules-1.2.8" (It's + on nearly all newer distributions) has a bug, which makes + it impossible to set both driver-Id's when loading the + icn-module for the Double-ICN-Card. A patch is supplied + in the utility-package called "insmod-1.2.8.patch". Change into + the source-directory of insmod, and type + "patch < insmod-1.2.8.patch". Then recompile it. This will fix + the bug. + This bug does NOT occur when using insmod with the Teles-driver + or a single ICN-card. + +3. Lowlevel-driver configuration. + + Configuration depends on how the drivers are built. + + 3.1 Drivers built into the kernel. + + 3.1.1 Teles driver. + + The Teles driver can be configured using the commandline-feature + while loading the kernel with LILO or LOADLIN. It accepts the + following syntax: + + teles=p0,i0,m0,d0[,p1,i1,m1,d1 ... ,pn,in,mn,dn][,idstring] + + where + + p0 = portbase of 1st card. (default: 0xd80) + i0 = irq of 1st card. (default: 15) + m0 = shared memory of 1st card. (default: 0xd0000) + d0 = D-channel protocol of 1st card. 1=1TR6, 2=EDSS1 (default: 2) + + p1,i1,m1,d1 = Parameters of second card (defaults: none) + pn,in,mn,d1 = Parameters of n'th card (up to 16 cards are supported) + + idstring = Driver-Id for accessing with utilities and identification + when using a Line-monitor. (default: none) + idstring must start with a character! + + The type of the card is determined by the port, irq and shared memory: + + port == 0, shared memory != 0 -> Teles S0-8 + port != 0, shared memory != 0 -> Teles S0-16.0 + port != 0, shared memory == 0 -> Teles S0-16.3 + + ATTENTION: + + Due to limited hardware-capabilities, there is no way to check the + existence of a card. Therefore you need to be sure your card's setup + is correct. Also there are bugs in the printed manual of some newer + 16.3 cards. Have a look to the kernel-syslog. With most of the cards, + you should see a line "HSCX version A:5 B:5" there. + + 3.1.2 ICN driver. + + 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, you MUST define TWO idstrings. + idstring must start with a character! + + 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. + + + 3.2 Drivers built as modules. + + 3.2.1 Teles driver. + + The module teles.o can be configured during "insmod'ing" it by + appending its parameters to the insmod-commandline. The following + syntax is accepted: + + io=m0,i0,p0,d0[,m1,i1,p1,d1 ... ,mn,in,pn,dn] teles_id=idstring + + where + + m0,i0,p0,d0 ... mn,in,pn,dn have the same meanings like the + parameters described for the kernel- + version above. Watch out: different + sequence! + + 3.2.2 ICN driver. + + 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, you MUST define TWO idstrings. + idstring must start with a character! + + 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. + +4. Device-inodes + + The major and minor-numbers and its 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) (Only for ICN-cards) Load the firmware into the card: + + cd icn + For 1TR6: + icnctrl [-d IDstring] load download/loadpg.bin download/pc_1t_ca.bin + For Euro-ISDN: + icnctrl [-d IDstring] load download/loadpg.bin download/pc_eu_ca.bin + + When using the ICN-4B, the protocol-software for the second half of + the card must be appended to the command line. + + -> 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 loading pcbit-firmware, refer to Documentation/isdn/README.pcbit + and the pcbit manpage, included in the utility-package. + + 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, it does NOT work + with the Teles on an EDSS1-Line.): + isdnctrl chargehup isdn0 on + + i) Setup the interface with ifconfig as usual, and set a route to it. + + j) (optional) If you run X11 and have Tcl/Tk-wish Version4.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 + contributed by Michael Knigge (imon), Volker Götz (imontty) and + Andreas Kool (isdnmon). + + k) 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 a + 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 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 of 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 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 th 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 Teles-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 counting 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-adaptor 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@wuemaus.franken.de), if you want to join that list. + +Have fun! + + -Fritz + diff --git a/Documentation/isdn/README.audio b/Documentation/isdn/README.audio new file mode 100644 index 000000000..c2c2d272d --- /dev/null +++ b/Documentation/isdn/README.audio @@ -0,0 +1,119 @@ +$Id: README.audio,v 1.3 1996/06/05 02:19:36 fritz 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 3 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. + NO EFFECT, supported for compatibility + only. Possible parameters: + x = 0 ... 31 + y = 0 ... 255 + 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. Emulator stops + recording, responding with VCON. + <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. + + Currently unsupported DLE sequences: + + <DLE>c FAX calling tone received. + <DLE>b busy tone received. + <DLE>q quiet. Silence detected after non-silence. + <DLE>s silence. Silence detected from the + start of recording. + + Any character sent by the application, except XON (0x11) or XOFF (0x13) + immediately stops recording. + + 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. + + diff --git a/Documentation/isdn/README.icn b/Documentation/isdn/README.icn new file mode 100644 index 000000000..f2dd3ba03 --- /dev/null +++ b/Documentation/isdn/README.icn @@ -0,0 +1,64 @@ +$Id: README.icn,v 1.4 1996/06/03 19:57:07 fritz Exp $ + +You can get the ICN-ISDN-card from: + +Thinking Objects Software GmbH +Obere Heerbergstr. 17 +97078 Würzburg +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! + diff --git a/Documentation/isdn/README.pcbit b/Documentation/isdn/README.pcbit new file mode 100644 index 000000000..e93562b2c --- /dev/null +++ b/Documentation/isdn/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> diff --git a/Documentation/isdn/README.syncppp b/Documentation/isdn/README.syncppp new file mode 100644 index 000000000..27d260095 --- /dev/null +++ b/Documentation/isdn/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 + + + diff --git a/Documentation/isdn/README.teles b/Documentation/isdn/README.teles new file mode 100644 index 000000000..904a55925 --- /dev/null +++ b/Documentation/isdn/README.teles @@ -0,0 +1,73 @@ +This is my Linux hardware level driver for Teles compatible ISDN cards. It is +meant to be used with isdn4isdn4linux, an ISDN Link-level module for Linux written +by Fritz Elfert. + +Isdn4linux can be obtained from ftp.franken.de:/pub/isdn4linux. The most recent +Teles driver can be found on my homepage, http://www.xs4all.nl:/~jdo. + +Warning +------- +Teles4isdn4linux is a work in progress and may crash your machine. It has not +been certified and therefore operation on your PTT's ISDN network is probably +illegal. + +Limitations +----------- +Teles4isdn4linux only works on Euro ISDN lines and german 1TR6-lines. + +For the B channel transparent (HDLC) protocol and X.75 have been implemented. + +Running +------- +When you insmod isdn.o and teles.o (or with the kernel-version, during boottime) +a few lines should appear in your syslog. Look for something like: + +Oct 11 16:53:30 jedi kernel: channels 2 +Oct 11 16:53:31 jedi kernel: Teles module installed + +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 teles_id=<SomeString> to the insmod-commandline. 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. Debugging messages are enabled with the telesctrl tool: + + teles/telesctrl <DriverId> 1 <debugging_flags> + +where <debugging_flags> is the integer sum of the following debugging +options you wish enabled: + + 1 Link-level <--> Hardware-level communication + 2 Top state machine + 4 D channel Q.931 (call control messages) + 8 D channel Q.921 + 16 B channel X.75 + 32 Lowlevel (irq and Layer1 stuff) + +For example 'teles/telesctrl MyTeles 1 63' enables full +debugging. + +Questions +--------- +Check out the FAQ (ftp.franken.de). + +Bugs +---- +If you find any please let me know. + +Thanks +------ +Special thanks to: + + Erik Bos,Beat Doebeli,Fritz Elfert, + Pauline Middelink,Paula de Nie, + Bernd Oerding,Stephan Seidl,Matthias Urlichs, + Rogier Wolff + + + +Enjoy, + +Jan den Ouden denouden@groovin.xs4all.nl + diff --git a/Documentation/isdn/syncPPP.FAQ b/Documentation/isdn/syncPPP.FAQ new file mode 100644 index 000000000..6813818e0 --- /dev/null +++ b/Documentation/isdn/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). + + + |