diff options
Diffstat (limited to 'Documentation/isdn')
-rw-r--r-- | Documentation/isdn/00-INDEX | 43 | ||||
-rw-r--r-- | Documentation/isdn/CREDITS | 70 | ||||
-rw-r--r-- | Documentation/isdn/HiSax.cert | 96 | ||||
-rw-r--r-- | Documentation/isdn/INTERFACE | 759 | ||||
-rw-r--r-- | Documentation/isdn/INTERFACE.fax | 163 | ||||
-rw-r--r-- | Documentation/isdn/README | 599 | ||||
-rw-r--r-- | Documentation/isdn/README.FAQ | 26 | ||||
-rw-r--r-- | Documentation/isdn/README.HiSax | 659 | ||||
-rw-r--r-- | Documentation/isdn/README.act2000 | 104 | ||||
-rw-r--r-- | Documentation/isdn/README.audio | 138 | ||||
-rw-r--r-- | Documentation/isdn/README.avmb1 | 187 | ||||
-rw-r--r-- | Documentation/isdn/README.concap | 259 | ||||
-rw-r--r-- | Documentation/isdn/README.diversion | 127 | ||||
-rw-r--r-- | Documentation/isdn/README.fax | 45 | ||||
-rw-r--r-- | Documentation/isdn/README.hfc-pci | 41 | ||||
-rw-r--r-- | Documentation/isdn/README.hysdn | 195 | ||||
-rw-r--r-- | Documentation/isdn/README.icn | 148 | ||||
-rw-r--r-- | Documentation/isdn/README.pcbit | 40 | ||||
-rw-r--r-- | Documentation/isdn/README.sc | 281 | ||||
-rw-r--r-- | Documentation/isdn/README.syncppp | 58 | ||||
-rw-r--r-- | Documentation/isdn/README.x25 | 184 | ||||
-rw-r--r-- | Documentation/isdn/syncPPP.FAQ | 224 |
22 files changed, 4446 insertions, 0 deletions
diff --git a/Documentation/isdn/00-INDEX b/Documentation/isdn/00-INDEX new file mode 100644 index 000000000000..9fee5f2e5c62 --- /dev/null +++ b/Documentation/isdn/00-INDEX | |||
@@ -0,0 +1,43 @@ | |||
1 | 00-INDEX | ||
2 | - this file (info on ISDN implementation for Linux) | ||
3 | CREDITS | ||
4 | - list of the kind folks that brought you this stuff. | ||
5 | INTERFACE | ||
6 | - description of Linklevel and Hardwarelevel ISDN interface. | ||
7 | README | ||
8 | - general info on what you need and what to do for Linux ISDN. | ||
9 | README.FAQ | ||
10 | - general info for FAQ. | ||
11 | README.audio | ||
12 | - info for running audio over ISDN. | ||
13 | README.fax | ||
14 | - info for using Fax over ISDN. | ||
15 | README.icn | ||
16 | - info on the ICN-ISDN-card and its driver. | ||
17 | README.HiSax | ||
18 | - info on the HiSax driver which replaces the old teles. | ||
19 | README.hfc-pci | ||
20 | - info on hfc-pci based cards. | ||
21 | README.pcbit | ||
22 | - info on the PCBIT-D ISDN adapter and driver. | ||
23 | README.syncppp | ||
24 | - info on running Sync PPP over ISDN. | ||
25 | syncPPP.FAQ | ||
26 | - frequently asked questions about running PPP over ISDN. | ||
27 | README.avmb1 | ||
28 | - info on driver for AVM-B1 ISDN card. | ||
29 | README.act2000 | ||
30 | - info on driver for IBM ACT-2000 card. | ||
31 | README.eicon | ||
32 | - info on driver for Eicon active cards. | ||
33 | README.concap | ||
34 | - info on "CONCAP" encapsulation protocol interface used for X.25. | ||
35 | README.diversion | ||
36 | - info on module for isdn diversion services. | ||
37 | README.sc | ||
38 | - info on driver for Spellcaster cards. | ||
39 | README.x25 | ||
40 | _ info for running X.25 over ISDN. | ||
41 | README.hysdn | ||
42 | - info on driver for Hypercope active HYSDN cards | ||
43 | |||
diff --git a/Documentation/isdn/CREDITS b/Documentation/isdn/CREDITS new file mode 100644 index 000000000000..e1b3023efaa8 --- /dev/null +++ b/Documentation/isdn/CREDITS | |||
@@ -0,0 +1,70 @@ | |||
1 | |||
2 | I want to thank all who contributed to this project and especially to: | ||
3 | (in alphabetical order) | ||
4 | |||
5 | Thomas Bogendörfer (tsbogend@bigbug.franken.de) | ||
6 | Tester, lots of bugfixes and hints. | ||
7 | |||
8 | Alan Cox (alan@redhat.com) | ||
9 | For help getting into standard-kernel. | ||
10 | |||
11 | Henner Eisen (eis@baty.hanse.de) | ||
12 | For X.25 implementation. | ||
13 | |||
14 | Volker Götz (volker@oops.franken.de) | ||
15 | For contribution of man-pages, the imontty-tool and a perfect | ||
16 | maintaining of the mailing-list at hub-wue. | ||
17 | |||
18 | Matthias Hessler (hessler@isdn4linux.de) | ||
19 | For creating and maintaining the FAQ. | ||
20 | |||
21 | Bernhard Hailer (Bernhard.Hailer@lrz.uni-muenchen.de) | ||
22 | For creating the FAQ, and the leafsite HOWTO. | ||
23 | |||
24 | Michael 'Ghandi' Herold (michael@abadonna.franken.de) | ||
25 | For contribution of the vbox answering machine. | ||
26 | |||
27 | Michael Hipp (Michael.Hipp@student.uni-tuebingen.de) | ||
28 | For his Sync-PPP-code. | ||
29 | |||
30 | Karsten Keil (keil@isdn4linux.de) | ||
31 | For adding 1TR6-support to the Teles-driver. | ||
32 | For the HiSax-driver. | ||
33 | |||
34 | Michael Knigge (knick@cove.han.de) | ||
35 | For contributing the imon-tool | ||
36 | |||
37 | Andreas Kool (akool@Kool.f.EUnet.de) | ||
38 | For contribution of the isdnlog/isdnrep-tool | ||
39 | |||
40 | Pedro Roque Marques (roque@di.fc.ul.pt) | ||
41 | For lot of new ideas and the pcbit driver. | ||
42 | |||
43 | Eberhard Moenkeberg (emoenke@gwdg.de) | ||
44 | For testing and help to get into kernel. | ||
45 | |||
46 | Thomas Neumann (tn@ruhr.de) | ||
47 | For help with Cisco-SLARP and keepalive | ||
48 | |||
49 | Jan den Ouden (denouden@groovin.xs4all.nl) | ||
50 | For contribution of the original teles-driver | ||
51 | |||
52 | Carsten Paeth (calle@calle.in-berlin.de) | ||
53 | For the AVM-B1-CAPI2.0 driver | ||
54 | |||
55 | Thomas Pfeiffer (pfeiffer@pds.de) | ||
56 | For V.110, extended T.70 and Hylafax extensions in isdn_tty.c | ||
57 | |||
58 | Max Riegel (riegel@max.franken.de) | ||
59 | For making the ICN hardware-documentation and test-equipment available. | ||
60 | |||
61 | Armin Schindler (mac@melware.de) | ||
62 | For the eicon active card driver. | ||
63 | |||
64 | Gerhard 'Fido' Schneider (fido@wuff.mayn.de) | ||
65 | For heavy-duty-beta-testing with his BBS ;) | ||
66 | |||
67 | Thomas Uhl (uhl@think.de) | ||
68 | For distributing the cards. | ||
69 | For pushing me to work ;-) | ||
70 | |||
diff --git a/Documentation/isdn/HiSax.cert b/Documentation/isdn/HiSax.cert new file mode 100644 index 000000000000..f2a6fcb8efee --- /dev/null +++ b/Documentation/isdn/HiSax.cert | |||
@@ -0,0 +1,96 @@ | |||
1 | -----BEGIN PGP SIGNED MESSAGE----- | ||
2 | |||
3 | First: | ||
4 | |||
5 | HiSax is free software; you can redistribute it and/or modify | ||
6 | it under the terms of the GNU General Public License as published by | ||
7 | the Free Software Foundation; either version 2 of the License, or | ||
8 | (at your option) any later version. | ||
9 | |||
10 | This program is distributed in the hope that it will be useful, | ||
11 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
12 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
13 | GNU General Public License for more details. | ||
14 | |||
15 | However, if you wish to modify the HiSax sources, please note the following: | ||
16 | |||
17 | HiSax has passed the ITU approval test suite with ELSA Quickstep ISDN cards | ||
18 | and Eicon Technology Diva 2.01 PCI card. | ||
19 | The certification is only valid for the combination of the tested software | ||
20 | version and the tested hardware. Any changes to the HiSax source code may | ||
21 | therefore affect the certification. | ||
22 | |||
23 | Additional ITU approval tests have been carried out for all generic cards | ||
24 | using Colognechip single chip solutions HFC-S PCI A for PCI cards as well | ||
25 | as HFC-S USB based USB ISDN ta adapters. | ||
26 | These tests included all layers 1-3 and as well all functional tests for | ||
27 | the layer 1. Because all hardware based on these chips are complete ISDN | ||
28 | solutions in one chip all cards and USB-TAs using these chips are to be | ||
29 | regarded as approved for those tests. Some additional electrical tests | ||
30 | of the layer 1 which are independent of the driver and related to a | ||
31 | special hardware used will be regarded as approved if at least one | ||
32 | solution has been tested including those electrical tests. So if cards | ||
33 | or tas have been completely approved for any other os, the approval | ||
34 | for those electrical tests is valid for linux, too. | ||
35 | Please send any questions regarding this drivers or approval abouts to | ||
36 | werner@isdn-development.de | ||
37 | Additional information and the type approval documents will be found | ||
38 | shortly on the Colognechip website www.colognechip.com | ||
39 | |||
40 | If you change the main files of the HiSax ISDN stack, the certification will | ||
41 | become invalid. Because in most countries it is illegal to connect | ||
42 | unapproved ISDN equipment to the public network, I have to guarantee that | ||
43 | changes in HiSax do not affect the certification. | ||
44 | |||
45 | In order to make a valid certification apparent to the user, I have built in | ||
46 | some validation checks that are made during the make process. The HiSax main | ||
47 | files are protected by md5 checksums and the md5sum file is pgp signed by | ||
48 | myself: | ||
49 | |||
50 | KeyID 1024/FF992F6D 1997/01/16 Karsten Keil <kkeil@suse.de> | ||
51 | Key fingerprint = 92 6B F7 58 EE 86 28 C8 C4 1A E6 DC 39 89 F2 AA | ||
52 | |||
53 | Only if the checksums are OK, and the signature of the file | ||
54 | "drivers/isdn/hisax/md5sums.asc" match, is the certification valid; a | ||
55 | message confirming this is then displayed during the hisax init process. | ||
56 | |||
57 | The affected files are: | ||
58 | |||
59 | drivers/isdn/hisax/isac.c | ||
60 | drivers/isdn/hisax/isdnl1.c | ||
61 | drivers/isdn/hisax/isdnl2.c | ||
62 | drivers/isdn/hisax/isdnl3.c | ||
63 | drivers/isdn/hisax/tei.c | ||
64 | drivers/isdn/hisax/callc.c | ||
65 | drivers/isdn/hisax/l3dss1.c | ||
66 | drivers/isdn/hisax/l3_1tr6.c | ||
67 | drivers/isdn/hisax/cert.c | ||
68 | drivers/isdn/hisax/elsa.c | ||
69 | drivers/isdn/hisax/diva.c | ||
70 | drivers/isdn/hisax/hfc_pci.c | ||
71 | |||
72 | Please send any changes, bugfixes and patches to me rather than implementing | ||
73 | them directly into the HiSax sources. | ||
74 | |||
75 | This does not reduce your rights granted by the GNU General Public License. | ||
76 | If you wish to change the sources, go ahead; but note that then the | ||
77 | certification is invalid even if you use one of the approved cards. | ||
78 | |||
79 | Here are the certification registration numbers for ELSA Quickstep cards: | ||
80 | German D133361J CETECOM ICT Services GmbH 0682 | ||
81 | European D133362J CETECOM ICT Services GmbH 0682 | ||
82 | |||
83 | |||
84 | Karsten Keil | ||
85 | keil@isdn4linux.de | ||
86 | |||
87 | -----BEGIN PGP SIGNATURE----- | ||
88 | Version: 2.6.3i | ||
89 | Charset: noconv | ||
90 | |||
91 | iQCVAwUBOFAwqTpxHvX/mS9tAQFI2QP9GLDK2iy/KBhwReE3F7LeO+tVhffTVZ3a | ||
92 | 20q5/z/WcIg/pnH0uTkl2UgDXBFXYl45zJyDGNpAposIFmT+Edd14o7Vj1w/BBdn | ||
93 | Y+5rBmJf+gyBu61da5d6bv0lpymwRa/um+ri+ilYnZ/XPfg5JKhdjGSBCJuJAElM | ||
94 | d2jFbTrsMYw= | ||
95 | =LNf9 | ||
96 | -----END PGP SIGNATURE----- | ||
diff --git a/Documentation/isdn/INTERFACE b/Documentation/isdn/INTERFACE new file mode 100644 index 000000000000..5df17e5b25c8 --- /dev/null +++ b/Documentation/isdn/INTERFACE | |||
@@ -0,0 +1,759 @@ | |||
1 | $Id: INTERFACE,v 1.15.8.2 2001/03/13 16:17:07 kai Exp $ | ||
2 | |||
3 | Description of the Interface between Linklevel and Hardwarelevel | ||
4 | of isdn4linux: | ||
5 | |||
6 | |||
7 | The Communication between Linklevel (LL) and Hardwarelevel (HL) | ||
8 | is based on the struct isdn_if (defined in isdnif.h). | ||
9 | |||
10 | An HL-driver can register itself at LL by calling the function | ||
11 | register_isdn() with a pointer to that struct. Prior to that, it has | ||
12 | to preset some of the fields of isdn_if. The LL sets the rest of | ||
13 | the fields. All further communication is done via callbacks using | ||
14 | the function-pointers defined in isdn_if. | ||
15 | |||
16 | Changes/Version numbering: | ||
17 | |||
18 | During development of the ISDN subsystem, several changes have been | ||
19 | made to the interface. Before it went into kernel, the package | ||
20 | had a unique version number. The last version, distributed separately | ||
21 | was 0.7.4. When the subsystem went into kernel, every functional unit | ||
22 | got a separate version number. These numbers are shown at initialization, | ||
23 | separated by slashes: | ||
24 | |||
25 | c.c/t.t/n.n/p.p/a.a/v.v | ||
26 | |||
27 | where | ||
28 | |||
29 | c.c is the revision of the common code. | ||
30 | t.t is the revision of the tty related code. | ||
31 | n.n is the revision of the network related code. | ||
32 | p.p is the revision of the ppp related code. | ||
33 | a.a is the revision of the audio related code. | ||
34 | v.v is the revision of the V.110 related code. | ||
35 | |||
36 | Changes in this document are marked with '***CHANGEx' where x representing | ||
37 | the version number. If that number starts with 0, it refers to the old, | ||
38 | separately distributed package. If it starts with one of the letters | ||
39 | above, it refers to the revision of the corresponding module. | ||
40 | ***CHANGEIx refers to the revision number of the isdnif.h | ||
41 | |||
42 | 1. Description of the fields of isdn_if: | ||
43 | |||
44 | int channels; | ||
45 | |||
46 | This field has to be set by the HL-driver to the number of channels | ||
47 | supported prior to calling register_isdn(). Upon return of the call, | ||
48 | the LL puts an id there, which has to be used by the HL-driver when | ||
49 | invoking the other callbacks. | ||
50 | |||
51 | int maxbufsize; | ||
52 | |||
53 | ***CHANGE0.6: New since this version. | ||
54 | |||
55 | Also to be preset by the HL-driver. With this value the HL-driver | ||
56 | tells the LL the maximum size of a data-packet it will accept. | ||
57 | |||
58 | unsigned long features; | ||
59 | |||
60 | To be preset by the HL-driver. Using this field, the HL-driver | ||
61 | announces the features supported. At the moment this is limited to | ||
62 | report the supported layer2 and layer3-protocols. For setting this | ||
63 | field the constants ISDN_FEATURE..., declared in isdnif.h have to be | ||
64 | used. | ||
65 | |||
66 | ***CHANGE0.7.1: The line type (1TR6, EDSS1) has to be set. | ||
67 | |||
68 | unsigned short hl_hdrlen; | ||
69 | |||
70 | ***CHANGE0.7.4: New field. | ||
71 | |||
72 | To be preset by the HL-driver, if it supports sk_buff's. The driver | ||
73 | should put here the amount of additional space needed in sk_buff's for | ||
74 | its internal purposes. Drivers not supporting sk_buff's should | ||
75 | initialize this field to 0. | ||
76 | |||
77 | void (*rcvcallb_skb)(int, int, struct sk_buff *) | ||
78 | |||
79 | ***CHANGE0.7.4: New field. | ||
80 | |||
81 | This field will be set by LL. The HL-driver delivers received data- | ||
82 | packets by calling this function. Upon calling, the HL-driver must | ||
83 | already have its private data pulled off the head of the sk_buff. | ||
84 | |||
85 | Parameter: | ||
86 | int driver-Id | ||
87 | int Channel-number locally to the driver. (starting with 0) | ||
88 | struct sk_buff * Pointer to sk_buff, containing received data. | ||
89 | |||
90 | int (*statcallb)(isdn_ctrl*); | ||
91 | |||
92 | This field will be set by LL. This function has to be called by the | ||
93 | HL-driver for signaling status-changes or other events to the LL. | ||
94 | |||
95 | Parameter: | ||
96 | isdn_ctrl* | ||
97 | |||
98 | The struct isdn_ctrl also defined in isdn_if. The exact meanings of its | ||
99 | fields are described together with the descriptions of the possible | ||
100 | events. Here is only a short description of the fields: | ||
101 | |||
102 | driver = driver Id. | ||
103 | command = event-type. (one of the constants ISDN_STAT_...) | ||
104 | arg = depends on event-type. | ||
105 | num = depends on event-type. | ||
106 | |||
107 | Returnvalue: | ||
108 | 0 on success, else -1 | ||
109 | |||
110 | int (*command)(isdn_ctrl*); | ||
111 | |||
112 | This field has to be preset by the HL-driver. It points to a function, | ||
113 | to be called by LL to perform functions like dialing, B-channel | ||
114 | setup, etc. The exact meaning of the parameters is described with the | ||
115 | descriptions of the possible commands. | ||
116 | |||
117 | Parameter: | ||
118 | isdn_ctrl* | ||
119 | driver = driver-Id | ||
120 | command = command to perform. (one of the constants ISDN_CMD_...) | ||
121 | arg = depends on command. | ||
122 | num = depends on command. | ||
123 | |||
124 | Returnvalue: | ||
125 | >=0 on success, else error-code (-ENODEV etc.) | ||
126 | |||
127 | int (*writebuf_skb)(int, int, int, struct sk_buff *) | ||
128 | |||
129 | ***CHANGE0.7.4: New field. | ||
130 | ***CHANGEI.1.21: New field. | ||
131 | |||
132 | This field has to be preset by the HL-driver. The given function will | ||
133 | be called by the LL for delivering data to be send via B-Channel. | ||
134 | |||
135 | |||
136 | Parameter: | ||
137 | int driver-Id ***CHANGE0.7.4: New parameter. | ||
138 | int channel-number locally to the HL-driver. (starts with 0) | ||
139 | int ack ***ChangeI1.21: New parameter | ||
140 | If this is !0, the driver has to signal the delivery | ||
141 | by sending an ISDN_STAT_BSENT. If this is 0, the driver | ||
142 | MUST NOT send an ISDN_STAT_BSENT. | ||
143 | struct sk_buff * Pointer to sk_buff containing data to be send via | ||
144 | B-channel. | ||
145 | |||
146 | Returnvalue: | ||
147 | Length of data accepted on success, else error-code (-EINVAL on | ||
148 | oversized packets etc.) | ||
149 | |||
150 | int (*writecmd)(u_char*, int, int, int, int); | ||
151 | |||
152 | This field has to be preset by the HL-driver. The given function will be | ||
153 | called to perform write-requests on /dev/isdnctrl (i.e. sending commands | ||
154 | to the card) The data-format is hardware-specific. This function is | ||
155 | intended for debugging only. It is not necessary for normal operation | ||
156 | and never will be called by the tty-emulation- or network-code. If | ||
157 | this function is not supported, the driver has to set NULL here. | ||
158 | |||
159 | Parameter: | ||
160 | u_char* pointer to data. | ||
161 | int length of data. | ||
162 | int flag: 0 = call from within kernel-space. (HL-driver must use | ||
163 | memcpy, may NOT use schedule()) | ||
164 | 1 = call from user-space. (HL-driver must use | ||
165 | memcpy_fromfs, use of schedule() allowed) | ||
166 | int driver-Id. | ||
167 | int channel-number locally to the HL-driver. (starts with 0) | ||
168 | |||
169 | ***CHANGEI1.14: The driver-Id and channel-number are new since this revision. | ||
170 | |||
171 | Returnvalue: | ||
172 | Length of data accepted on success, else error-code (-EINVAL etc.) | ||
173 | |||
174 | int (*readstat)(u_char*, int, int, int, int); | ||
175 | |||
176 | This field has to be preset by the HL-driver. The given function will be | ||
177 | called to perform read-requests on /dev/isdnctrl (i.e. reading replies | ||
178 | from the card) The data-format is hardware-specific. This function is | ||
179 | intended for debugging only. It is not necessary for normal operation | ||
180 | and never will be called by the tty-emulation- or network-code. If | ||
181 | this function is not supported, the driver has to set NULL here. | ||
182 | |||
183 | Parameter: | ||
184 | u_char* pointer to data. | ||
185 | int length of data. | ||
186 | int flag: 0 = call from within kernel-space. (HL-driver must use | ||
187 | memcpy, may NOT use schedule()) | ||
188 | 1 = call from user-space. (HL-driver must use | ||
189 | memcpy_fromfs, use of schedule() allowed) | ||
190 | int driver-Id. | ||
191 | int channel-number locally to the HL-driver. (starts with 0) | ||
192 | |||
193 | ***CHANGEI1.14: The driver-Id and channel-number are new since this revision. | ||
194 | |||
195 | Returnvalue: | ||
196 | Length of data on success, else error-code (-EINVAL etc.) | ||
197 | |||
198 | char id[20]; | ||
199 | ***CHANGE0.7: New since this version. | ||
200 | |||
201 | This string has to be preset by the HL-driver. Its purpose is for | ||
202 | identification of the driver by the user. Eg.: it is shown in the | ||
203 | status-info of /dev/isdninfo. Furthermore it is used as Id for binding | ||
204 | net-interfaces to a specific channel. If a string of length zero is | ||
205 | given, upon return, isdn4linux will replace it by a generic name. (line0, | ||
206 | line1 etc.) It is recommended to make this string configurable during | ||
207 | module-load-time. (copy a global variable to this string.) For doing that, | ||
208 | modules 1.2.8 or newer are necessary. | ||
209 | |||
210 | 2. Description of the commands, a HL-driver has to support: | ||
211 | |||
212 | All commands will be performed by calling the function command() described | ||
213 | above from within the LL. The field command of the struct-parameter will | ||
214 | contain the desired command, the field driver is always set to the | ||
215 | appropriate driver-Id. | ||
216 | |||
217 | Until now, the following commands are defined: | ||
218 | |||
219 | ***CHANGEI1.34: The parameter "num" has been replaced by a union "parm" containing | ||
220 | the old "num" and a new setup_type struct used for ISDN_CMD_DIAL | ||
221 | and ISDN_STAT_ICALL callback. | ||
222 | |||
223 | ISDN_CMD_IOCTL: | ||
224 | |||
225 | This command is intended for performing ioctl-calls for configuring | ||
226 | hardware or similar purposes (setting port-addresses, loading firmware | ||
227 | etc.) For this purpose, in the LL all ioctl-calls with an argument | ||
228 | >= IIOCDRVCTL (0x100) will be handed transparently to this | ||
229 | function after subtracting 0x100 and placing the result in arg. | ||
230 | Example: | ||
231 | If a userlevel-program calls ioctl(0x101,...) the function gets | ||
232 | called with the field command set to 1. | ||
233 | |||
234 | Parameter: | ||
235 | driver = driver-Id. | ||
236 | command = ISDN_CMD_IOCTL | ||
237 | arg = Original ioctl-cmd - IIOCDRVCTL | ||
238 | parm.num = first bytes filled with (unsigned long)arg | ||
239 | |||
240 | Returnvalue: | ||
241 | Depending on driver. | ||
242 | |||
243 | |||
244 | ISDN_CMD_DIAL: | ||
245 | |||
246 | This command is used to tell the HL-driver it should dial a given | ||
247 | number. | ||
248 | |||
249 | Parameter: | ||
250 | driver = driver-Id. | ||
251 | command = ISDN_CMD_DIAL | ||
252 | arg = channel-number locally to the driver. (starting with 0) | ||
253 | |||
254 | parm.setup.phone = An ASCII-String containing the number to dial. | ||
255 | parm.setup.eazmsn = An ASCII-Sting containing the own EAZ or MSN. | ||
256 | parm.setup.si1 = The Service-Indicator. | ||
257 | parm.setup.si2 = Additional Service-Indicator. | ||
258 | |||
259 | If the Line has been designed as SPV (a special german | ||
260 | feature, meaning semi-leased-line) the phone has to | ||
261 | start with an "S". | ||
262 | ***CHANGE0.6: In previous versions the EAZ has been given in the | ||
263 | highbyte of arg. | ||
264 | ***CHANGE0.7.1: New since this version: ServiceIndicator and AddInfo. | ||
265 | |||
266 | ISDN_CMD_ACCEPTD: | ||
267 | |||
268 | With this command, the HL-driver is told to accept a D-Channel-setup. | ||
269 | (Response to an incoming call) | ||
270 | |||
271 | Parameter: | ||
272 | driver = driver-Id. | ||
273 | command = ISDN_CMD_ACCEPTD | ||
274 | arg = channel-number locally to the driver. (starting with 0) | ||
275 | parm = unused. | ||
276 | |||
277 | ISDN_CMD_ACCEPTB: | ||
278 | |||
279 | With this command, the HL-driver is told to perform a B-Channel-setup. | ||
280 | (after establishing D-Channel-Connection) | ||
281 | |||
282 | Parameter: | ||
283 | driver = driver-Id. | ||
284 | command = ISDN_CMD_ACCEPTB | ||
285 | arg = channel-number locally to the driver. (starting with 0) | ||
286 | parm = unused. | ||
287 | |||
288 | ISDN_CMD_HANGUP: | ||
289 | |||
290 | With this command, the HL-driver is told to hangup (B-Channel if | ||
291 | established first, then D-Channel). This command is also used for | ||
292 | actively rejecting an incoming call. | ||
293 | |||
294 | Parameter: | ||
295 | driver = driver-Id. | ||
296 | command = ISDN_CMD_HANGUP | ||
297 | arg = channel-number locally to the driver. (starting with 0) | ||
298 | parm = unused. | ||
299 | |||
300 | ISDN_CMD_CLREAZ: | ||
301 | |||
302 | With this command, the HL-driver is told not to signal incoming | ||
303 | calls to the LL. | ||
304 | |||
305 | Parameter: | ||
306 | driver = driver-Id. | ||
307 | command = ISDN_CMD_CLREAZ | ||
308 | arg = channel-number locally to the driver. (starting with 0) | ||
309 | parm = unused. | ||
310 | |||
311 | ISDN_CMD_SETEAZ: | ||
312 | |||
313 | With this command, the HL-driver is told to signal incoming calls for | ||
314 | the given EAZs/MSNs to the LL. | ||
315 | |||
316 | Parameter: | ||
317 | driver = driver-Id. | ||
318 | command = ISDN_CMD_SETEAZ | ||
319 | arg = channel-number locally to the driver. (starting with 0) | ||
320 | parm.num = ASCII-String, containing the desired EAZ's/MSN's | ||
321 | (comma-separated). If an empty String is given, the | ||
322 | HL-driver should respond to ALL incoming calls, | ||
323 | regardless of the destination-address. | ||
324 | ***CHANGE0.6: New since this version the "empty-string"-feature. | ||
325 | |||
326 | ISDN_CMD_GETEAZ: (currently unused) | ||
327 | |||
328 | With this command, the HL-driver is told to report the current setting | ||
329 | given with ISDN_CMD_SETEAZ. | ||
330 | |||
331 | Parameter: | ||
332 | driver = driver-Id. | ||
333 | command = ISDN_CMD_GETEAZ | ||
334 | arg = channel-number locally to the driver. (starting with 0) | ||
335 | parm.num = ASCII-String, containing the current EAZ's/MSN's | ||
336 | |||
337 | ISDN_CMD_SETSIL: (currently unused) | ||
338 | |||
339 | With this command, the HL-driver is told to signal only incoming | ||
340 | calls with the given Service-Indicators. | ||
341 | |||
342 | Parameter: | ||
343 | driver = driver-Id. | ||
344 | command = ISDN_CMD_SETSIL | ||
345 | arg = channel-number locally to the driver. (starting with 0) | ||
346 | parm.num = ASCII-String, containing the desired Service-Indicators. | ||
347 | |||
348 | ISDN_CMD_GETSIL: (currently unused) | ||
349 | |||
350 | With this command, the HL-driver is told to return the current | ||
351 | Service-Indicators it will respond to. | ||
352 | |||
353 | Parameter: | ||
354 | driver = driver-Id. | ||
355 | command = ISDN_CMD_SETSIL | ||
356 | arg = channel-number locally to the driver. (starting with 0) | ||
357 | parm.num = ASCII-String, containing the current Service-Indicators. | ||
358 | |||
359 | ISDN_CMD_SETL2: | ||
360 | |||
361 | With this command, the HL-driver is told to select the given Layer-2- | ||
362 | protocol. This command is issued by the LL prior to ISDN_CMD_DIAL or | ||
363 | ISDN_CMD_ACCEPTD. | ||
364 | |||
365 | |||
366 | Parameter: | ||
367 | driver = driver-Id. | ||
368 | command = ISDN_CMD_SETL2 | ||
369 | arg = channel-number locally to the driver. (starting with 0) | ||
370 | logical or'ed with (protocol-Id << 8) | ||
371 | protocol-Id is one of the constants ISDN_PROTO_L2... | ||
372 | parm = unused. | ||
373 | |||
374 | ISDN_CMD_GETL2: (currently unused) | ||
375 | |||
376 | With this command, the HL-driver is told to return the current | ||
377 | setting of the Layer-2-protocol. | ||
378 | |||
379 | Parameter: | ||
380 | driver = driver-Id. | ||
381 | command = ISDN_CMD_GETL2 | ||
382 | arg = channel-number locally to the driver. (starting with 0) | ||
383 | parm = unused. | ||
384 | Returnvalue: | ||
385 | current protocol-Id (one of the constants ISDN_L2_PROTO) | ||
386 | |||
387 | ISDN_CMD_SETL3: | ||
388 | |||
389 | With this command, the HL-driver is told to select the given Layer-3- | ||
390 | protocol. This command is issued by the LL prior to ISDN_CMD_DIAL or | ||
391 | ISDN_CMD_ACCEPTD. | ||
392 | |||
393 | |||
394 | Parameter: | ||
395 | driver = driver-Id. | ||
396 | command = ISDN_CMD_SETL3 | ||
397 | arg = channel-number locally to the driver. (starting with 0) | ||
398 | logical or'ed with (protocol-Id << 8) | ||
399 | protocol-Id is one of the constants ISDN_PROTO_L3... | ||
400 | parm.fax = Pointer to T30_s fax struct. (fax usage only) | ||
401 | |||
402 | ISDN_CMD_GETL2: (currently unused) | ||
403 | |||
404 | With this command, the HL-driver is told to return the current | ||
405 | setting of the Layer-3-protocol. | ||
406 | |||
407 | Parameter: | ||
408 | driver = driver-Id. | ||
409 | command = ISDN_CMD_GETL3 | ||
410 | arg = channel-number locally to the driver. (starting with 0) | ||
411 | parm = unused. | ||
412 | Returnvalue: | ||
413 | current protocol-Id (one of the constants ISDN_L3_PROTO) | ||
414 | |||
415 | ISDN_CMD_PROCEED: | ||
416 | |||
417 | With this command, the HL-driver is told to proceed with a incoming call. | ||
418 | |||
419 | Parameter: | ||
420 | driver = driver-Id. | ||
421 | command = ISDN_CMD_PROCEED | ||
422 | arg = channel-number locally to the driver. (starting with 0) | ||
423 | setup.eazmsn= empty string or string send as uus1 in DSS1 with | ||
424 | PROCEED message | ||
425 | |||
426 | ISDN_CMD_ALERT: | ||
427 | |||
428 | With this command, the HL-driver is told to alert a proceeding call. | ||
429 | |||
430 | Parameter: | ||
431 | driver = driver-Id. | ||
432 | command = ISDN_CMD_ALERT | ||
433 | arg = channel-number locally to the driver. (starting with 0) | ||
434 | setup.eazmsn= empty string or string send as uus1 in DSS1 with | ||
435 | ALERT message | ||
436 | |||
437 | ISDN_CMD_REDIR: | ||
438 | |||
439 | With this command, the HL-driver is told to redirect a call in proceeding | ||
440 | or alerting state. | ||
441 | |||
442 | Parameter: | ||
443 | driver = driver-Id. | ||
444 | command = ISDN_CMD_REDIR | ||
445 | arg = channel-number locally to the driver. (starting with 0) | ||
446 | setup.eazmsn= empty string or string send as uus1 in DSS1 protocol | ||
447 | setup.screen= screening indicator | ||
448 | setup.phone = redirected to party number | ||
449 | |||
450 | ISDN_CMD_PROT_IO: | ||
451 | |||
452 | With this call, the LL-driver invokes protocol specific features through | ||
453 | the LL. | ||
454 | The call is not implicitely bound to a connection. | ||
455 | |||
456 | Parameter: | ||
457 | driver = driver-Id | ||
458 | command = ISDN_CMD_PROT_IO | ||
459 | arg = The lower 8 Bits define the addressed protocol as defined | ||
460 | in ISDN_PTYPE..., the upper bits are used to differentiate | ||
461 | the protocol specific CMD. | ||
462 | |||
463 | para = protocol and function specific. See isdnif.h for detail. | ||
464 | |||
465 | |||
466 | ISDN_CMD_FAXCMD: | ||
467 | |||
468 | With this command the HL-driver receives a fax sub-command. | ||
469 | For details refer to INTERFACE.fax | ||
470 | |||
471 | Parameter: | ||
472 | driver = driver-Id. | ||
473 | command = ISDN_CMD_FAXCMD | ||
474 | arg = channel-number locally to the driver. (starting with 0) | ||
475 | parm = unused. | ||
476 | |||
477 | |||
478 | 3. Description of the events to be signaled by the HL-driver to the LL. | ||
479 | |||
480 | All status-changes are signaled via calling the previously described | ||
481 | function statcallb(). The field command of the struct isdn_cmd has | ||
482 | to be set by the HL-driver with the appropriate Status-Id (event-number). | ||
483 | The field arg has to be set to the channel-number (locally to the driver, | ||
484 | starting with 0) to which this event applies. (Exception: STAVAIL-event) | ||
485 | |||
486 | Until now, the following Status-Ids are defined: | ||
487 | |||
488 | ISDN_STAT_AVAIL: | ||
489 | |||
490 | With this call, the HL-driver signals the availability of new data | ||
491 | for readstat(). Used only for debugging-purposes, see description | ||
492 | of readstat(). | ||
493 | |||
494 | Parameter: | ||
495 | driver = driver-Id | ||
496 | command = ISDN_STAT_STAVAIL | ||
497 | arg = length of available data. | ||
498 | parm = unused. | ||
499 | |||
500 | ISDN_STAT_ICALL: | ||
501 | ISDN_STAT_ICALLW: | ||
502 | |||
503 | With this call, the HL-driver signals an incoming call to the LL. | ||
504 | If ICALLW is signalled the incoming call is a waiting call without | ||
505 | a available B-chan. | ||
506 | |||
507 | Parameter: | ||
508 | driver = driver-Id | ||
509 | command = ISDN_STAT_ICALL | ||
510 | arg = channel-number, locally to the driver. (starting with 0) | ||
511 | para.setup.phone = Callernumber. | ||
512 | para.setup.eazmsn = CalledNumber. | ||
513 | para.setup.si1 = Service Indicator. | ||
514 | para.setup.si2 = Additional Service Indicator. | ||
515 | para.setup.plan = octet 3 from Calling party number Information Element. | ||
516 | para.setup.screen = octet 3a from Calling party number Information Element. | ||
517 | |||
518 | Return: | ||
519 | 0 = No device matching this call. | ||
520 | 1 = At least one device matching this call (RING on ttyI). | ||
521 | HL-driver may send ALERTING on the D-channel in this case. | ||
522 | 2 = Call will be rejected. | ||
523 | 3 = Incoming called party number is currently incomplete. | ||
524 | Additional digits are required. | ||
525 | Used for signalling with PtP connections. | ||
526 | 4 = Call will be held in a proceeding state | ||
527 | (HL driver sends PROCEEDING) | ||
528 | Used when a user space prog needs time to interpret a call | ||
529 | para.setup.eazmsn may be filled with an uus1 message of | ||
530 | 30 octets maximum. Empty string if no uus. | ||
531 | 5 = Call will be actively deflected to another party | ||
532 | Only available in DSS1/EURO protocol | ||
533 | para.setup.phone must be set to destination party number | ||
534 | para.setup.eazmsn may be filled with an uus1 message of | ||
535 | 30 octets maximum. Empty string if no uus. | ||
536 | -1 = An error happened. (Invalid parameters for example.) | ||
537 | The keypad support now is included in the dial command. | ||
538 | |||
539 | |||
540 | ISDN_STAT_RUN: | ||
541 | |||
542 | With this call, the HL-driver signals availability of the ISDN-card. | ||
543 | (after initializing, loading firmware) | ||
544 | |||
545 | Parameter: | ||
546 | driver = driver-Id | ||
547 | command = ISDN_STAT_RUN | ||
548 | arg = unused. | ||
549 | parm = unused. | ||
550 | |||
551 | ISDN_STAT_STOP: | ||
552 | |||
553 | With this call, the HL-driver signals unavailability of the ISDN-card. | ||
554 | (before unloading, while resetting/reconfiguring the card) | ||
555 | |||
556 | Parameter: | ||
557 | driver = driver-Id | ||
558 | command = ISDN_STAT_STOP | ||
559 | arg = unused. | ||
560 | parm = unused. | ||
561 | |||
562 | ISDN_STAT_DCONN: | ||
563 | |||
564 | With this call, the HL-driver signals the successful establishment of | ||
565 | a D-Channel-connection. (Response to ISDN_CMD_ACCEPTD or ISDN_CMD_DIAL) | ||
566 | |||
567 | Parameter: | ||
568 | driver = driver-Id | ||
569 | command = ISDN_STAT_DCONN | ||
570 | arg = channel-number, locally to the driver. (starting with 0) | ||
571 | parm = unused. | ||
572 | |||
573 | ISDN_STAT_BCONN: | ||
574 | |||
575 | With this call, the HL-driver signals the successful establishment of | ||
576 | a B-Channel-connection. (Response to ISDN_CMD_ACCEPTB or because the | ||
577 | remote-station has initiated establishment) | ||
578 | |||
579 | The HL driver should call this when the logical l2/l3 protocol | ||
580 | connection on top of the physical B-channel is established. | ||
581 | |||
582 | Parameter: | ||
583 | driver = driver-Id | ||
584 | command = ISDN_STAT_BCONN | ||
585 | arg = channel-number, locally to the driver. (starting with 0) | ||
586 | parm.num = ASCII-String, containing type of connection (for analog | ||
587 | modem only). This will be appended to the CONNECT message | ||
588 | e.g. 14400/V.32bis | ||
589 | |||
590 | ISDN_STAT_DHUP: | ||
591 | |||
592 | With this call, the HL-driver signals the shutdown of a | ||
593 | D-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP, | ||
594 | or caused by a remote-hangup or if the remote-station has actively | ||
595 | rejected a call. | ||
596 | |||
597 | Parameter: | ||
598 | driver = driver-Id | ||
599 | command = ISDN_STAT_DHUP | ||
600 | arg = channel-number, locally to the driver. (starting with 0) | ||
601 | parm = unused. | ||
602 | |||
603 | ISDN_STAT_BHUP: | ||
604 | |||
605 | With this call, the HL-driver signals the shutdown of a | ||
606 | B-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP, | ||
607 | or caused by a remote-hangup. | ||
608 | |||
609 | The HL driver should call this as soon as the logical l2/l3 protocol | ||
610 | connection on top of the physical B-channel is released. | ||
611 | |||
612 | Parameter: | ||
613 | driver = driver-Id | ||
614 | command = ISDN_STAT_BHUP | ||
615 | arg = channel-number, locally to the driver. (starting with 0) | ||
616 | parm = unused. | ||
617 | |||
618 | ISDN_STAT_CINF: | ||
619 | |||
620 | With this call, the HL-driver delivers charge-unit information to the | ||
621 | LL. | ||
622 | |||
623 | Parameter: | ||
624 | driver = driver-Id | ||
625 | command = ISDN_STAT_CINF | ||
626 | arg = channel-number, locally to the driver. (starting with 0) | ||
627 | parm.num = ASCII string containing charge-units (digits only). | ||
628 | |||
629 | ISDN_STAT_LOAD: (currently unused) | ||
630 | |||
631 | ISDN_STAT_UNLOAD: | ||
632 | |||
633 | With this call, the HL-driver signals that it will be unloaded now. This | ||
634 | tells the LL to release all corresponding data-structures. | ||
635 | |||
636 | Parameter: | ||
637 | driver = driver-Id | ||
638 | command = ISDN_STAT_UNLOAD | ||
639 | arg = unused. | ||
640 | parm = unused. | ||
641 | |||
642 | ISDN_STAT_BSENT: | ||
643 | |||
644 | With this call the HL-driver signals the delivery of a data-packet. | ||
645 | This callback is used by the network-interfaces only, tty-Emulation | ||
646 | does not need this call. | ||
647 | |||
648 | Parameter: | ||
649 | driver = driver-Id | ||
650 | command = ISDN_STAT_BSENT | ||
651 | arg = channel-number, locally to the driver. (starting with 0) | ||
652 | parm.length = ***CHANGEI.1.21: New field. | ||
653 | the driver has to set this to the original length | ||
654 | of the skb at the time of receiving it from the linklevel. | ||
655 | |||
656 | ISDN_STAT_NODCH: | ||
657 | |||
658 | With this call, the driver has to respond to a prior ISDN_CMD_DIAL, if | ||
659 | no D-Channel is available. | ||
660 | |||
661 | Parameter: | ||
662 | driver = driver-Id | ||
663 | command = ISDN_STAT_NODCH | ||
664 | arg = channel-number, locally to the driver. (starting with 0) | ||
665 | parm = unused. | ||
666 | |||
667 | ISDN_STAT_ADDCH: | ||
668 | |||
669 | This call is for HL-drivers, which are unable to check card-type | ||
670 | or numbers of supported channels before they have loaded any firmware | ||
671 | using ioctl. Those HL-driver simply set the channel-parameter to a | ||
672 | minimum channel-number when registering, and later if they know | ||
673 | the real amount, perform this call, allocating additional channels. | ||
674 | |||
675 | Parameter: | ||
676 | driver = driver-Id | ||
677 | command = ISDN_STAT_ADDCH | ||
678 | arg = number of channels to be added. | ||
679 | parm = unused. | ||
680 | |||
681 | ISDN_STAT_CAUSE: | ||
682 | |||
683 | With this call, the HL-driver delivers CAUSE-messages to the LL. | ||
684 | Currently the LL does not use this messages. Their contents is simply | ||
685 | logged via kernel-messages. Therefore, currently the format of the | ||
686 | messages is completely free. However they should be printable. | ||
687 | |||
688 | Parameter: | ||
689 | driver = driver-Id | ||
690 | command = ISDN_STAT_NODCH | ||
691 | arg = channel-number, locally to the driver. (starting with 0) | ||
692 | parm.num = ASCII string containing CAUSE-message. | ||
693 | |||
694 | ISDN_STAT_DISPLAY: | ||
695 | |||
696 | With this call, the HL-driver delivers DISPLAY-messages to the LL. | ||
697 | Currently the LL does not use this messages. | ||
698 | |||
699 | Parameter: | ||
700 | driver = driver-Id | ||
701 | command = ISDN_STAT_DISPLAY | ||
702 | arg = channel-number, locally to the driver. (starting with 0) | ||
703 | para.display= string containing DISPLAY-message. | ||
704 | |||
705 | ISDN_STAT_PROT: | ||
706 | |||
707 | With this call, the HL-driver delivers protocol specific infos to the LL. | ||
708 | The call is not implicitely bound to a connection. | ||
709 | |||
710 | Parameter: | ||
711 | driver = driver-Id | ||
712 | command = ISDN_STAT_PROT | ||
713 | arg = The lower 8 Bits define the addressed protocol as defined | ||
714 | in ISDN_PTYPE..., the upper bits are used to differentiate | ||
715 | the protocol specific STAT. | ||
716 | |||
717 | para = protocol and function specific. See isdnif.h for detail. | ||
718 | |||
719 | ISDN_STAT_DISCH: | ||
720 | |||
721 | With this call, the HL-driver signals the LL to disable or enable the | ||
722 | use of supplied channel and driver. | ||
723 | The call may be used to reduce the available number of B-channels after | ||
724 | loading the driver. The LL has to ignore a disabled channel when searching | ||
725 | for free channels. The HL driver itself never delivers STAT callbacks for | ||
726 | disabled channels. | ||
727 | The LL returns a nonzero code if the operation was not successful or the | ||
728 | selected channel is actually regarded as busy. | ||
729 | |||
730 | Parameter: | ||
731 | driver = driver-Id | ||
732 | command = ISDN_STAT_DISCH | ||
733 | arg = channel-number, locally to the driver. (starting with 0) | ||
734 | parm.num[0] = 0 if channel shall be disabled, else enabled. | ||
735 | |||
736 | ISDN_STAT_L1ERR: | ||
737 | |||
738 | ***CHANGEI1.21 new status message. | ||
739 | A signal can be sent to the linklevel if an Layer1-error results in | ||
740 | packet-loss on receive or send. The field errcode of the cmd.parm | ||
741 | union describes the error more precisely. | ||
742 | |||
743 | Parameter: | ||
744 | driver = driver-Id | ||
745 | command = ISDN_STAT_L1ERR | ||
746 | arg = channel-number, locally to the driver. (starting with 0) | ||
747 | parm.errcode= ISDN_STAT_L1ERR_SEND: Packet lost while sending. | ||
748 | ISDN_STAT_L1ERR_RECV: Packet lost while receiving. | ||
749 | ISDN_STAT_FAXIND: | ||
750 | |||
751 | With this call the HL-driver signals a fax sub-command to the LL. | ||
752 | For details refer to INTERFACE.fax | ||
753 | |||
754 | Parameter: | ||
755 | driver = driver-Id. | ||
756 | command = ISDN_STAT_FAXIND | ||
757 | arg = channel-number, locally to the driver. (starting with 0) | ||
758 | parm = unused. | ||
759 | |||
diff --git a/Documentation/isdn/INTERFACE.fax b/Documentation/isdn/INTERFACE.fax new file mode 100644 index 000000000000..7e5731319e30 --- /dev/null +++ b/Documentation/isdn/INTERFACE.fax | |||
@@ -0,0 +1,163 @@ | |||
1 | $Id: INTERFACE.fax,v 1.2 2000/08/06 09:22:50 armin Exp $ | ||
2 | |||
3 | |||
4 | Description of the fax-subinterface between linklevel and hardwarelevel of | ||
5 | isdn4linux. | ||
6 | |||
7 | The communication between linklevel (LL) and hardwarelevel (HL) for fax | ||
8 | is based on the struct T30_s (defined in isdnif.h). | ||
9 | This struct is allocated in the LL. | ||
10 | In order to use fax, the LL provides the pointer to this struct with the | ||
11 | command ISDN_CMD_SETL3 (parm.fax). This pointer expires in case of hangup | ||
12 | and when a new channel to a new connection is assigned. | ||
13 | |||
14 | |||
15 | Data handling: | ||
16 | In send-mode the HL-driver has to handle the <DLE> codes and the bit-order | ||
17 | conversion by itself. | ||
18 | In receive-mode the LL-driver takes care of the bit-order conversion | ||
19 | (specified by +FBOR) | ||
20 | |||
21 | Structure T30_s description: | ||
22 | |||
23 | This structure stores the values (set by AT-commands), the remote- | ||
24 | capability-values and the command-codes between LL and HL. | ||
25 | |||
26 | If the HL-driver receives ISDN_CMD_FAXCMD, all needed information | ||
27 | is in this struct set by the LL. | ||
28 | To signal information to the LL, the HL-driver has to set the | ||
29 | the parameters and use ISDN_STAT_FAXIND. | ||
30 | (Please refer to INTERFACE) | ||
31 | |||
32 | Structure T30_s: | ||
33 | |||
34 | All members are 8-bit unsigned (__u8) | ||
35 | |||
36 | - resolution | ||
37 | - rate | ||
38 | - width | ||
39 | - length | ||
40 | - compression | ||
41 | - ecm | ||
42 | - binary | ||
43 | - scantime | ||
44 | - id[] | ||
45 | Local faxmachine's parameters, set by +FDIS, +FDCS, +FLID, ... | ||
46 | |||
47 | - r_resolution | ||
48 | - r_rate | ||
49 | - r_width | ||
50 | - r_length | ||
51 | - r_compression | ||
52 | - r_ecm | ||
53 | - r_binary | ||
54 | - r_scantime | ||
55 | - r_id[] | ||
56 | Remote faxmachine's parameters. To be set by HL-driver. | ||
57 | |||
58 | - phase | ||
59 | Defines the actual state of fax connection. Set by HL or LL | ||
60 | depending on progress and type of connection. | ||
61 | If the phase changes because of an AT command, the LL driver | ||
62 | changes this value. Otherwise the HL-driver takes care of it, but | ||
63 | only necessary on call establishment (from IDLE to PHASE_A). | ||
64 | (one of the constants ISDN_FAX_PHASE_[IDLE,A,B,C,D,E]) | ||
65 | |||
66 | - direction | ||
67 | Defines outgoing/send or incoming/receive connection. | ||
68 | (ISDN_TTY_FAX_CONN_[IN,OUT]) | ||
69 | |||
70 | - code | ||
71 | Commands from LL to HL; possible constants : | ||
72 | ISDN_TTY_FAX_DR signals +FDR command to HL | ||
73 | |||
74 | ISDN_TTY_FAX_DT signals +FDT command to HL | ||
75 | |||
76 | ISDN_TTY_FAX_ET signals +FET command to HL | ||
77 | |||
78 | |||
79 | Other than that the "code" is set with the hangup-code value at | ||
80 | the end of connection for the +FHNG message. | ||
81 | |||
82 | - r_code | ||
83 | Commands from HL to LL; possible constants : | ||
84 | ISDN_TTY_FAX_CFR output of +FCFR message. | ||
85 | |||
86 | ISDN_TTY_FAX_RID output of remote ID set in r_id[] | ||
87 | (+FCSI/+FTSI on send/receive) | ||
88 | |||
89 | ISDN_TTY_FAX_DCS output of +FDCS and CONNECT message, | ||
90 | switching to phase C. | ||
91 | |||
92 | ISDN_TTY_FAX_ET signals end of data, | ||
93 | switching to phase D. | ||
94 | |||
95 | ISDN_TTY_FAX_FCON signals the established, outgoing connection, | ||
96 | switching to phase B. | ||
97 | |||
98 | ISDN_TTY_FAX_FCON_I signals the established, incoming connection, | ||
99 | switching to phase B. | ||
100 | |||
101 | ISDN_TTY_FAX_DIS output of +FDIS message and values. | ||
102 | |||
103 | ISDN_TTY_FAX_SENT signals that all data has been sent | ||
104 | and <DLE><ETX> is acknowledged, | ||
105 | OK message will be sent. | ||
106 | |||
107 | ISDN_TTY_FAX_PTS signals a msg-confirmation (page sent successful), | ||
108 | depending on fet value: | ||
109 | 0: output OK message (more pages follow) | ||
110 | 1: switching to phase B (next document) | ||
111 | |||
112 | ISDN_TTY_FAX_TRAIN_OK output of +FDCS and OK message (for receive mode). | ||
113 | |||
114 | ISDN_TTY_FAX_EOP signals end of data in receive mode, | ||
115 | switching to phase D. | ||
116 | |||
117 | ISDN_TTY_FAX_HNG output of the +FHNG and value set by code and | ||
118 | OK message, switching to phase E. | ||
119 | |||
120 | |||
121 | - badlin | ||
122 | Value of +FBADLIN | ||
123 | |||
124 | - badmul | ||
125 | Value of +FBADMUL | ||
126 | |||
127 | - bor | ||
128 | Value of +FBOR | ||
129 | |||
130 | - fet | ||
131 | Value of +FET command in send-mode. | ||
132 | Set by HL in receive-mode for +FET message. | ||
133 | |||
134 | - pollid[] | ||
135 | ID-string, set by +FCIG | ||
136 | |||
137 | - cq | ||
138 | Value of +FCQ | ||
139 | |||
140 | - cr | ||
141 | Value of +FCR | ||
142 | |||
143 | - ctcrty | ||
144 | Value of +FCTCRTY | ||
145 | |||
146 | - minsp | ||
147 | Value of +FMINSP | ||
148 | |||
149 | - phcto | ||
150 | Value of +FPHCTO | ||
151 | |||
152 | - rel | ||
153 | Value of +FREL | ||
154 | |||
155 | - nbc | ||
156 | Value of +FNBC (0,1) | ||
157 | (+FNBC is not a known class 2 fax command, I added this to change the | ||
158 | automatic "best capabilities" connection in the eicon HL-driver) | ||
159 | |||
160 | |||
161 | Armin | ||
162 | mac@melware.de | ||
163 | |||
diff --git a/Documentation/isdn/README b/Documentation/isdn/README new file mode 100644 index 000000000000..761595243931 --- /dev/null +++ b/Documentation/isdn/README | |||
@@ -0,0 +1,599 @@ | |||
1 | README for the ISDN-subsystem | ||
2 | |||
3 | 1. Preface | ||
4 | |||
5 | 1.1 Introduction | ||
6 | |||
7 | This README describes how to set up and how to use the different parts | ||
8 | of the ISDN-subsystem. | ||
9 | |||
10 | For using the ISDN-subsystem, some additional userlevel programs are | ||
11 | necessary. Those programs and some contributed utilities are available | ||
12 | at | ||
13 | |||
14 | ftp.isdn4linux.de | ||
15 | |||
16 | /pub/isdn4linux/isdn4k-utils-<VersionNumber>.tar.gz | ||
17 | |||
18 | |||
19 | We also have set up a mailing-list: | ||
20 | |||
21 | The isdn4linux-project originates in Germany, and therefore by historical | ||
22 | reasons, the mailing-list's primary language is german. However mails | ||
23 | written in english have been welcome all the time. | ||
24 | |||
25 | to subscribe: write a email to majordomo@listserv.isdn4linux.de, | ||
26 | Subject irrelevant, in the message body: | ||
27 | subscribe isdn4linux <your_email_address> | ||
28 | |||
29 | To write to the mailing-list, write to isdn4linux@listserv.isdn4linux.de | ||
30 | |||
31 | This mailinglist is bidirectionally gated to the newsgroup | ||
32 | |||
33 | de.alt.comm.isdn4linux | ||
34 | |||
35 | There is also a well maintained FAQ in English available at | ||
36 | http://www.mhessler.de/i4lfaq/ | ||
37 | It can be viewed online, or downloaded in sgml/text/html format. | ||
38 | The FAQ can also be viewed online at | ||
39 | http://www.isdn4inux.de/faq/ | ||
40 | or downloaded from | ||
41 | ftp://ftp.isdn4linux.de/pub/isdn4linux/FAQ/ | ||
42 | |||
43 | 1.1 Technical details | ||
44 | |||
45 | In the following Text, the terms MSN and EAZ are used. | ||
46 | |||
47 | MSN is the abbreviation for (M)ultiple(S)ubscriber(N)umber, and applies | ||
48 | to Euro(EDSS1)-type lines. Usually it is simply the phone number. | ||
49 | |||
50 | EAZ is the abbreviation of (E)ndgeraete(A)uswahl(Z)iffer and | ||
51 | applies to German 1TR6-type lines. This is a one-digit string, | ||
52 | simply appended to the base phone number | ||
53 | |||
54 | The internal handling is nearly identical, so replace the appropriate | ||
55 | term to that one, which applies to your local ISDN-environment. | ||
56 | |||
57 | When the link-level-module isdn.o is loaded, it supports up to 16 | ||
58 | low-level-modules with up to 64 channels. (The number 64 is arbitrarily | ||
59 | chosen and can be configured at compile-time --ISDN_MAX in isdn.h). | ||
60 | A low-level-driver can register itself through an interface (which is | ||
61 | defined in isdnif.h) and gets assigned a slot. | ||
62 | The following char-devices are made available for each channel: | ||
63 | |||
64 | A raw-control-device with the following functions: | ||
65 | write: raw D-channel-messages (format: depends on driver). | ||
66 | read: raw D-channel-messages (format: depends on driver). | ||
67 | ioctl: depends on driver, i.e. for the ICN-driver, the base-address of | ||
68 | the ports and the shared memory on the card can be set and read | ||
69 | also the boot-code and the protocol software can be loaded into | ||
70 | the card. | ||
71 | |||
72 | O N L Y !!! for debugging (no locking against other devices): | ||
73 | One raw-data-device with the following functions: | ||
74 | write: data to B-channel. | ||
75 | read: data from B-channel. | ||
76 | |||
77 | In addition the following devices are made available: | ||
78 | |||
79 | 128 tty-devices (64 cuix and 64 ttyIx) with integrated modem-emulator: | ||
80 | The functionality is almost the same as that of a serial device | ||
81 | (the line-discs are handled by the kernel), which lets you run | ||
82 | SLIP, CSLIP and asynchronous PPP through the devices. We have tested | ||
83 | Seyon, minicom, CSLIP (uri-dip) PPP, mgetty, XCept and Hylafax. | ||
84 | |||
85 | The modem-emulation supports the following: | ||
86 | 1.3.1 Commands: | ||
87 | |||
88 | ATA Answer incoming call. | ||
89 | ATD<No.> Dial, the number may contain: | ||
90 | [0-9] and [,#.*WPT-S] | ||
91 | the latter are ignored until 'S'. | ||
92 | The 'S' must precede the number, if | ||
93 | the line is a SPV (German 1TR6). | ||
94 | ATE0 Echo off. | ||
95 | ATE1 Echo on (default). | ||
96 | ATH Hang-up. | ||
97 | ATH1 Off hook (ignored). | ||
98 | ATH0 Hang-up. | ||
99 | ATI Return "ISDN for Linux...". | ||
100 | ATI0 " | ||
101 | ATI1 " | ||
102 | ATI2 Report of last connection. | ||
103 | ATO On line (data mode). | ||
104 | ATQ0 Enable result codes (default). | ||
105 | ATQ1 Disable result codes (default). | ||
106 | ATSx=y Set register x to y. | ||
107 | ATSx? Show contents of register x. | ||
108 | ATV0 Numeric responses. | ||
109 | ATV1 English responses (default). | ||
110 | ATZ Load registers and EAZ/MSN from Profile. | ||
111 | AT&Bx Set Send-Packet-size to x (max. 4000) | ||
112 | The real packet-size may be limited by the | ||
113 | low-level-driver used. e.g. the HiSax-Module- | ||
114 | limit is 2000. You will get NO Error-Message, | ||
115 | if you set it to higher values, because at the | ||
116 | time of giving this command the corresponding | ||
117 | driver may not be selected (see "Automatic | ||
118 | Assignment") however the size of outgoing packets | ||
119 | will be limited correctly. | ||
120 | AT&D0 Ignore DTR | ||
121 | AT&D2 DTR-low-edge: Hang up and return to | ||
122 | command mode (default). | ||
123 | AT&D3 Same as AT&D2 but also resets all registers. | ||
124 | AT&Ex Set the EAZ/MSN for this channel to x. | ||
125 | AT&F Reset all registers and profile to "factory-defaults" | ||
126 | AT&Lx Set list of phone numbers to listen on. x is a | ||
127 | list of wildcard patterns separated by semicolon. | ||
128 | If this is set, it has precedence over the MSN set | ||
129 | by AT&E. | ||
130 | AT&Rx Select V.110 bitrate adaption. | ||
131 | This command enables V.110 protocol with 9600 baud | ||
132 | (x=9600), 19200 baud (x=19200) or 38400 baud | ||
133 | (x=38400). A value of x=0 disables V.110 switching | ||
134 | back to default X.75. This command sets the following | ||
135 | Registers: | ||
136 | Reg 14 (Layer-2 protocol): | ||
137 | x = 0: 0 | ||
138 | x = 9600: 7 | ||
139 | x = 19200: 8 | ||
140 | x = 38400: 9 | ||
141 | Reg 18.2 = 1 | ||
142 | Reg 19 (Additional Service Indicator): | ||
143 | x = 0: 0 | ||
144 | x = 9600: 197 | ||
145 | x = 19200: 199 | ||
146 | x = 38400: 198 | ||
147 | Note on value in Reg 19: | ||
148 | There is _NO_ common convention for 38400 baud. | ||
149 | The value 198 is chosen arbitrarily. Users | ||
150 | _MUST_ negotiate this value before establishing | ||
151 | a connection. | ||
152 | AT&Sx Set window-size (x = 1..8) (not yet implemented) | ||
153 | AT&V Show all settings. | ||
154 | AT&W0 Write registers and EAZ/MSN to profile. See also | ||
155 | iprofd (5.c in this README). | ||
156 | AT&X0 BTX-mode and T.70-mode off (default) | ||
157 | AT&X1 BTX-mode on. (S13.1=1, S13.5=0 S14=0, S16=7, S18=7, S19=0) | ||
158 | AT&X2 T.70-mode on. (S13.1=1, S13.5=1, S14=0, S16=7, S18=7, S19=0) | ||
159 | AT+Rx Resume a suspended call with CallID x (x = 1,2,3...) | ||
160 | AT+Sx Suspend a call with CallID x (x = 1,2,3...) | ||
161 | |||
162 | For voice-mode commands refer to README.audio | ||
163 | |||
164 | 1.3.2 Escape sequence: | ||
165 | During a connection, the emulation reacts just like | ||
166 | a normal modem to the escape sequence <DELAY>+++<DELAY>. | ||
167 | (The escape character - default '+' - can be set in the | ||
168 | register 2). | ||
169 | The DELAY must at least be 1.5 seconds long and delay | ||
170 | between the escape characters must not exceed 0.5 seconds. | ||
171 | |||
172 | 1.3.3 Registers: | ||
173 | |||
174 | Nr. Default Description | ||
175 | 0 0 Answer on ring number. | ||
176 | (no auto-answer if S0=0). | ||
177 | 1 0 Count of rings. | ||
178 | 2 43 Escape character. | ||
179 | (a value >= 128 disables the escape sequence). | ||
180 | 3 13 Carriage return character (ASCII). | ||
181 | 4 10 Line feed character (ASCII). | ||
182 | 5 8 Backspace character (ASCII). | ||
183 | 6 3 Delay in seconds before dialing. | ||
184 | 7 60 Wait for carrier. | ||
185 | 8 2 Pause time for comma (ignored) | ||
186 | 9 6 Carrier detect time (ignored) | ||
187 | 10 7 Carrier loss to disconnect time (ignored). | ||
188 | 11 70 Touch tone timing (ignored). | ||
189 | 12 69 Bit coded register: | ||
190 | Bit 0: 0 = Suppress response messages. | ||
191 | 1 = Show response messages. | ||
192 | Bit 1: 0 = English response messages. | ||
193 | 1 = Numeric response messages. | ||
194 | Bit 2: 0 = Echo off. | ||
195 | 1 = Echo on. | ||
196 | Bit 3 0 = DCD always on. | ||
197 | 1 = DCD follows carrier. | ||
198 | Bit 4 0 = CTS follows RTS | ||
199 | 1 = Ignore RTS, CTS always on. | ||
200 | Bit 5 0 = return to command mode on DTR low. | ||
201 | 1 = Same as 0 but also resets all | ||
202 | registers. | ||
203 | See also register 13, bit 2 | ||
204 | Bit 6 0 = DSR always on. | ||
205 | 1 = DSR only on if channel is available. | ||
206 | Bit 7 0 = Cisco-PPP-flag-hack off (default). | ||
207 | 1 = Cisco-PPP-flag-hack on. | ||
208 | 13 0 Bit coded register: | ||
209 | Bit 0: 0 = Use delayed tty-send-algorithm | ||
210 | 1 = Direct tty-send. | ||
211 | Bit 1: 0 = T.70 protocol (Only for BTX!) off | ||
212 | 1 = T.70 protocol (Only for BTX!) on | ||
213 | Bit 2: 0 = Don't hangup on DTR low. | ||
214 | 1 = Hangup on DTR low. | ||
215 | Bit 3: 0 = Standard response messages | ||
216 | 1 = Extended response messages | ||
217 | Bit 4: 0 = CALLER NUMBER before every RING. | ||
218 | 1 = CALLER NUMBER after first RING. | ||
219 | Bit 5: 0 = T.70 extended protocol off | ||
220 | 1 = T.70 extended protocol on | ||
221 | Bit 6: 0 = Special RUNG Message off | ||
222 | 1 = Special RUNG Message on | ||
223 | "RUNG" is delivered on a ttyI, if | ||
224 | an incoming call happened (RING) and | ||
225 | the remote party hung up before any | ||
226 | local ATA was given. | ||
227 | Bit 7: 0 = Don't show display messages from net | ||
228 | 1 = Show display messages from net | ||
229 | (S12 Bit 1 must be 0 too) | ||
230 | 14 0 Layer-2 protocol: | ||
231 | 0 = X75/LAPB with I-frames | ||
232 | 1 = X75/LAPB with UI-frames | ||
233 | 2 = X75/LAPB with BUI-frames | ||
234 | 3 = HDLC | ||
235 | 4 = Transparent (audio) | ||
236 | 7 = V.110, 9600 baud | ||
237 | 8 = V.110, 19200 baud | ||
238 | 9 = V.110, 38400 baud | ||
239 | 10 = Analog Modem (only if hardware supports this) | ||
240 | 11 = Fax G3 (only if hardware supports this) | ||
241 | 15 0 Layer-3 protocol: | ||
242 | 0 = transparent | ||
243 | 1 = transparent with audio features (e.g. DSP) | ||
244 | 2 = Fax G3 Class 2 commands (S14 has to be set to 11) | ||
245 | 3 = Fax G3 Class 1 commands (S14 has to be set to 11) | ||
246 | 16 250 Send-Packet-size/16 | ||
247 | 17 8 Window-size (not yet implemented) | ||
248 | 18 4 Bit coded register, Service-Octet-1 to accept, | ||
249 | or to be used on dialout: | ||
250 | Bit 0: Service 1 (audio) when set. | ||
251 | Bit 1: Service 5 (BTX) when set. | ||
252 | Bit 2: Service 7 (data) when set. | ||
253 | Note: It is possible to set more than one | ||
254 | bit. In this case, on incoming calls | ||
255 | the selected services are accepted, | ||
256 | and if the service is "audio", the | ||
257 | Layer-2-protocol is automatically | ||
258 | changed to 4 regardless of the setting | ||
259 | of register 14. On outgoing calls, | ||
260 | the most significant 1-bit is chosen to | ||
261 | select the outgoing service octet. | ||
262 | 19 0 Service-Octet-2 | ||
263 | 20 0 Bit coded register (readonly) | ||
264 | Service-Octet-1 of last call. | ||
265 | Bit mapping is the same as register 18 | ||
266 | 21 0 Bit coded register (readonly) | ||
267 | Set on incoming call (during RING) to | ||
268 | octet 3 of calling party number IE (Numbering plan) | ||
269 | See section 4.5.10 of ITU Q.931 | ||
270 | 22 0 Bit coded register (readonly) | ||
271 | Set on incoming call (during RING) to | ||
272 | octet 3a of calling party number IE (Screening info) | ||
273 | See section 4.5.10 of ITU Q.931 | ||
274 | 23 0 Bit coded register: | ||
275 | Bit 0: 0 = Add CPN to RING message off | ||
276 | 1 = Add CPN to RING message on | ||
277 | Bit 1: 0 = Add CPN to FCON message off | ||
278 | 1 = Add CPN to FCON message on | ||
279 | Bit 2: 0 = Add CDN to RING/FCON message off | ||
280 | 1 = Add CDN to RING/FCON message on | ||
281 | |||
282 | Last but not least a (at the moment fairly primitive) device to request | ||
283 | the line-status (/dev/isdninfo) is made available. | ||
284 | |||
285 | Automatic assignment of devices to lines: | ||
286 | |||
287 | All inactive physical lines are listening to all EAZs for incoming | ||
288 | calls and are NOT assigned to a specific tty or network interface. | ||
289 | When an incoming call is detected, the driver looks first for a network | ||
290 | interface and then for an opened tty which: | ||
291 | |||
292 | 1. is configured for the same EAZ. | ||
293 | 2. has the same protocol settings for the B-channel. | ||
294 | 3. (only for network interfaces if the security flag is set) | ||
295 | contains the caller number in its access list. | ||
296 | 4. Either the channel is not bound exclusively to another Net-interface, or | ||
297 | it is bound AND the other checks apply to exactly this interface. | ||
298 | (For usage of the bind-features, refer to the isdnctrl-man-page) | ||
299 | |||
300 | Only when a matching interface or tty is found is the call accepted | ||
301 | and the "connection" between the low-level-layer and the link-level-layer | ||
302 | is established and kept until the end of the connection. | ||
303 | In all other cases no connection is established. Isdn4linux can be | ||
304 | configured to either do NOTHING in this case (which is useful, if | ||
305 | other, external devices with the same EAZ/MSN are connected to the bus) | ||
306 | or to reject the call actively. (isdnctrl busreject ...) | ||
307 | |||
308 | For an outgoing call, the inactive physical lines are searched. | ||
309 | The call is placed on the first physical line, which supports the | ||
310 | requested protocols for the B-channel. If a net-interface, however | ||
311 | is pre-bound to a channel, this channel is used directly. | ||
312 | |||
313 | This makes it possible to configure several network interfaces and ttys | ||
314 | for one EAZ, if the network interfaces are set to secure operation. | ||
315 | If an incoming call matches one network interface, it gets connected to it. | ||
316 | If another incoming call for the same EAZ arrives, which does not match | ||
317 | a network interface, the first tty gets a "RING" and so on. | ||
318 | |||
319 | 2 System prerequisites: | ||
320 | |||
321 | ATTENTION! | ||
322 | |||
323 | Always use the latest module utilities. The current version is | ||
324 | named in Documentation/Changes. Some old versions of insmod | ||
325 | are not capable of setting the driver-Ids correctly. | ||
326 | |||
327 | 3. Lowlevel-driver configuration. | ||
328 | |||
329 | Configuration depends on how the drivers are built. See the | ||
330 | README.<yourDriver> for information on driver-specific setup. | ||
331 | |||
332 | 4. Device-inodes | ||
333 | |||
334 | The major and minor numbers and their names are described in | ||
335 | Documentation/devices.txt. The major numbers are: | ||
336 | |||
337 | 43 for the ISDN-tty's. | ||
338 | 44 for the ISDN-callout-tty's. | ||
339 | 45 for control/info/debug devices. | ||
340 | |||
341 | 5. Application | ||
342 | |||
343 | a) For some card-types, firmware has to be loaded into the cards, before | ||
344 | proceeding with device-independent setup. See README.<yourDriver> | ||
345 | for how to do that. | ||
346 | |||
347 | b) If you only intend to use ttys, you are nearly ready now. | ||
348 | |||
349 | c) If you want to have really permanent "Modem"-settings on disk, you | ||
350 | can start the daemon iprofd. Give it a path to a file at the command- | ||
351 | line. It will store the profile-settings in this file every time | ||
352 | an AT&W0 is performed on any ISDN-tty. If the file already exists, | ||
353 | all profiles are initialized from this file. If you want to unload | ||
354 | any of the modules, kill iprofd first. | ||
355 | |||
356 | d) For networking, continue: Create an interface: | ||
357 | isdnctrl addif isdn0 | ||
358 | |||
359 | e) Set the EAZ (or MSN for Euro-ISDN): | ||
360 | isdnctrl eaz isdn0 2 | ||
361 | |||
362 | (For 1TR6 a single digit is allowed, for Euro-ISDN the number is your | ||
363 | real MSN e.g.: Phone-Number) | ||
364 | |||
365 | f) Set the number for outgoing calls on the interface: | ||
366 | isdnctrl addphone isdn0 out 1234567 | ||
367 | ... (this can be executed more than once, all assigned numbers are | ||
368 | tried in order) | ||
369 | and the number(s) for incoming calls: | ||
370 | isdnctrl addphone isdn0 in 1234567 | ||
371 | |||
372 | g) Set the timeout for hang-up: | ||
373 | isdnctrl huptimeout isdn0 <timeout_in_seconds> | ||
374 | |||
375 | h) additionally you may activate charge-hang-up (= Hang up before | ||
376 | next charge-info, this only works, if your isdn-provider transmits | ||
377 | the charge-info during and after the connection): | ||
378 | isdnctrl chargehup isdn0 on | ||
379 | |||
380 | i) Set the dial mode of the interface: | ||
381 | isdnctrl dialmode isdn0 auto | ||
382 | "off" means that you (or the system) cannot make any connection | ||
383 | (neither incoming or outgoing connections are possible). Use | ||
384 | this if you want to be sure that no connections will be made. | ||
385 | "auto" means that the interface is in auto-dial mode, and will | ||
386 | attempt to make a connection whenever a network data packet needs | ||
387 | the interface's link. Note that this can cause unexpected dialouts, | ||
388 | and lead to a high phone bill! Some daemons or other pc's that use | ||
389 | this interface can cause this. | ||
390 | Incoming connections are also possible. | ||
391 | "manual" is a dial mode created to prevent the unexpected dialouts. | ||
392 | In this mode, the interface will never make any connections on its | ||
393 | own. You must explicitly initiate a connection with "isdnctrl dial | ||
394 | isdn0". However, after an idle time of no traffic as configured for | ||
395 | the huptimeout value with isdnctrl, the connection _will_ be ended. | ||
396 | If you don't want any automatic hangup, set the huptimeout value to 0. | ||
397 | "manual" is the default. | ||
398 | |||
399 | j) Setup the interface with ifconfig as usual, and set a route to it. | ||
400 | |||
401 | k) (optional) If you run X11 and have Tcl/Tk-wish version 4.0, you can use | ||
402 | the script tools/tcltk/isdnmon. You can add actions for line-status | ||
403 | changes. See the comments at the beginning of the script for how to | ||
404 | do that. There are other tty-based tools in the tools-subdirectory | ||
405 | contributed by Michael Knigge (imon), Volker Götz (imontty) and | ||
406 | Andreas Kool (isdnmon). | ||
407 | |||
408 | l) For initial testing, you can set the verbose-level to 2 (default: 0). | ||
409 | Then all incoming calls are logged, even if they are not addressed | ||
410 | to one of the configured net-interfaces: | ||
411 | isdnctrl verbose 2 | ||
412 | |||
413 | Now you are ready! A ping to the set address should now result in an | ||
414 | automatic dial-out (look at syslog kernel-messages). | ||
415 | The phone numbers and EAZs can be assigned at any time with isdnctrl. | ||
416 | You can add as many interfaces as you like with addif following the | ||
417 | directions above. Of course, there may be some limitations. But we have | ||
418 | tested as many as 20 interfaces without any problem. However, if you | ||
419 | don't give an interface name to addif, the kernel will assign a name | ||
420 | which starts with "eth". The number of "eth"-interfaces is limited by | ||
421 | the kernel. | ||
422 | |||
423 | 5. Additional options for isdnctrl: | ||
424 | |||
425 | "isdnctrl secure <InterfaceName> on" | ||
426 | Only incoming calls, for which the caller-id is listed in the access | ||
427 | list of the interface are accepted. You can add caller-id's With the | ||
428 | command "isdnctrl addphone <InterfaceName> in <caller-id>" | ||
429 | Euro-ISDN does not transmit the leading '0' of the caller-id for an | ||
430 | incoming call, therefore you should configure it accordingly. | ||
431 | If the real number for the dialout e.g. is "09311234567" the number | ||
432 | to configure here is "9311234567". The pattern-match function | ||
433 | works similar to the shell mechanism. | ||
434 | |||
435 | ? one arbitrary digit | ||
436 | * zero or arbitrary many digits | ||
437 | [123] one of the digits in the list | ||
438 | [1-5] one digit between '1' and '5' | ||
439 | a '^' as the first character in a list inverts the list | ||
440 | |||
441 | |||
442 | "isdnctrl secure <InterfaceName> off" | ||
443 | Switch off secure operation (default). | ||
444 | |||
445 | "isdnctrl ihup <InterfaceName> [on|off]" | ||
446 | Switch the hang-up-timer for incoming calls on or off. | ||
447 | |||
448 | "isdnctrl eaz <InterfaceName>" | ||
449 | Returns the EAZ of an interface. | ||
450 | |||
451 | "isdnctrl delphone <InterfaceName> in|out <number>" | ||
452 | Deletes a number from one of the access-lists of the interface. | ||
453 | |||
454 | "isdnctrl delif <InterfaceName>" | ||
455 | Removes the interface (and possible slaves) from the kernel. | ||
456 | (You have to unregister it with "ifconfig <InterfaceName> down" before). | ||
457 | |||
458 | "isdnctrl callback <InterfaceName> [on|off]" | ||
459 | Switches an interface to callback-mode. In this mode, an incoming call | ||
460 | will be rejected and after this the remote-station will be called. If | ||
461 | you test this feature by using ping, some routers will re-dial very | ||
462 | quickly, so that the callback from isdn4linux may not be recognized. | ||
463 | In this case use ping with the option -i <sec> to increase the interval | ||
464 | between echo-packets. | ||
465 | |||
466 | "isdnctrl cbdelay <InterfaceName> [seconds]" | ||
467 | Sets the delay (default 5 sec) between an incoming call and start of | ||
468 | dialing when callback is enabled. | ||
469 | |||
470 | "isdnctrl cbhup <InterfaceName> [on|off]" | ||
471 | This enables (default) or disables an active hangup (reject) when getting an | ||
472 | incoming call for an interface which is configured for callback. | ||
473 | |||
474 | "isdnctrl encap <InterfaceName> <EncapType>" | ||
475 | Selects the type of packet-encapsulation. The encapsulation can be changed | ||
476 | only while an interface is down. | ||
477 | |||
478 | At the moment the following values are supported: | ||
479 | |||
480 | rawip (Default) Selects raw-IP-encapsulation. This means, MAC-headers | ||
481 | are stripped off. | ||
482 | ip IP with type-field. Same as IP but the type-field of the MAC-header | ||
483 | is preserved. | ||
484 | x25iface X.25 interface encapsulation (first byte semantics as defined in | ||
485 | ../networking/x25-iface.txt). Use this for running the linux | ||
486 | X.25 network protocol stack (AF_X25 sockets) on top of isdn. | ||
487 | cisco-h A special-mode for communicating with a Cisco, which is configured | ||
488 | to do "hdlc" | ||
489 | ethernet No stripping. Packets are sent with full MAC-header. | ||
490 | The Ethernet-address of the interface is faked, from its | ||
491 | IP-address: fc:fc:i1:i2:i3:i4, where i1-4 are the IP-addr.-values. | ||
492 | syncppp Synchronous PPP | ||
493 | |||
494 | uihdlc HDLC with UI-frame-header (for use with DOS ISPA, option -h1) | ||
495 | |||
496 | |||
497 | NOTE: x25iface encapsulation is currently experimental. Please | ||
498 | read README.x25 for further details | ||
499 | |||
500 | |||
501 | Watching packets, using standard-tcpdump will fail for all encapsulations | ||
502 | except ethernet because tcpdump does not know how to handle packets | ||
503 | without MAC-header. A patch for tcpdump is included in the utility-package | ||
504 | mentioned above. | ||
505 | |||
506 | "isdnctrl l2_prot <InterfaceName> <L2-ProtocolName>" | ||
507 | Selects a layer-2-protocol. | ||
508 | (With the ICN-driver and the HiSax-driver, "x75i" and "hdlc" is available. | ||
509 | With other drivers, "x75ui", "x75bui", "x25dte", "x25dce" may be | ||
510 | possible too. See README.x25 for x25 related l2 protocols.) | ||
511 | |||
512 | isdnctrl l3_prot <InterfaceName> <L3-ProtocolName> | ||
513 | The same for layer-3. (At the moment only "trans" is allowed) | ||
514 | |||
515 | "isdnctrl list <InterfaceName>" | ||
516 | Shows all parameters of an interface and the charge-info. | ||
517 | Try "all" as the interface name. | ||
518 | |||
519 | "isdnctrl hangup <InterfaceName>" | ||
520 | Forces hangup of an interface. | ||
521 | |||
522 | "isdnctrl bind <InterfaceName> <DriverId>,<ChannelNumber> [exclusive]" | ||
523 | If you are using more than one ISDN card, it is sometimes necessary to | ||
524 | dial out using a specific card or even preserve a specific channel for | ||
525 | dialout of a specific net-interface. This can be done with the above | ||
526 | command. Replace <DriverId> by whatever you assigned while loading the | ||
527 | module. The <ChannelNumber> is counted from zero. The upper limit | ||
528 | depends on the card used. At the moment no card supports more than | ||
529 | 2 channels, so the upper limit is one. | ||
530 | |||
531 | "isdnctrl unbind <InterfaceName>" | ||
532 | unbinds a previously bound interface. | ||
533 | |||
534 | "isdnctrl busreject <DriverId> on|off" | ||
535 | If switched on, isdn4linux replies a REJECT to incoming calls, it | ||
536 | cannot match to any configured interface. | ||
537 | If switched off, nothing happens in this case. | ||
538 | You normally should NOT enable this feature, if the ISDN adapter is not | ||
539 | the only device connected to the S0-bus. Otherwise it could happen that | ||
540 | isdn4linux rejects an incoming call, which belongs to another device on | ||
541 | the bus. | ||
542 | |||
543 | "isdnctrl addslave <InterfaceName> <SlaveName> | ||
544 | Creates a slave interface for channel-bundling. Slave interfaces are | ||
545 | not seen by the kernel, but their ISDN-part can be configured with | ||
546 | isdnctrl as usual. (Phone numbers, EAZ/MSN, timeouts etc.) If more | ||
547 | than two channels are to be bundled, feel free to create as many as you | ||
548 | want. InterfaceName must be a real interface, NOT a slave. Slave interfaces | ||
549 | start dialing, if the master interface resp. the previous slave interface | ||
550 | has a load of more than 7000 cps. They hangup if the load goes under 7000 | ||
551 | cps, according to their "huptimeout"-parameter. | ||
552 | |||
553 | "isdnctrl sdelay <InterfaceName> secs." | ||
554 | This sets the minimum time an Interface has to be fully loaded, until | ||
555 | it sends a dial-request to its slave. | ||
556 | |||
557 | "isdnctrl dial <InterfaceName>" | ||
558 | Forces an interface to start dialing even if no packets are to be | ||
559 | transferred. | ||
560 | |||
561 | "isdnctrl mapping <DriverId> MSN0,MSN1,MSN2,...MSN9" | ||
562 | This installs a mapping table for EAZ<->MSN-mapping for a single line. | ||
563 | Missing MSN's have to be given as "-" or can be omitted, if at the end | ||
564 | of the commandline. | ||
565 | With this command, it's now possible to have an interface listening to | ||
566 | mixed 1TR6- and Euro-Type lines. In this case, the interface has to be | ||
567 | configured to a 1TR6-type EAZ (one digit). The mapping is also valid | ||
568 | for tty-emulation. Seen from the interface/tty-level the mapping | ||
569 | CAN be used, however it's possible to use single tty's/interfaces with | ||
570 | real MSN's (more digits) also, in which case the mapping will be ignored. | ||
571 | Here is an example: | ||
572 | |||
573 | You have a 1TR6-type line with base-nr. 1234567 and a Euro-line with | ||
574 | MSN's 987654, 987655 and 987656. The DriverId for the Euro-line is "EURO". | ||
575 | |||
576 | isdnctrl mapping EURO -,987654,987655,987656,-,987655 | ||
577 | ... | ||
578 | isdnctrl eaz isdn0 1 # listen on 12345671(1tr6) and 987654(euro) | ||
579 | ... | ||
580 | isdnctrl eaz isdn1 4 # listen on 12345674(1tr6) only. | ||
581 | ... | ||
582 | isdnctrl eaz isdn2 987654 # listen on 987654(euro) only. | ||
583 | |||
584 | Same scheme is used with AT&E... at the tty's. | ||
585 | |||
586 | 6. If you want to write a new low-level-driver, you are welcome. | ||
587 | The interface to the link-level-module is described in the file INTERFACE. | ||
588 | If the interface should be expanded for any reason, don't do it | ||
589 | on your own, send me a mail containing the proposed changes and | ||
590 | some reasoning about them. | ||
591 | If other drivers will not be affected, I will include the changes | ||
592 | in the next release. | ||
593 | For developers only, there is a second mailing-list. Write to me | ||
594 | (fritz@isdn4linux.de), if you want to join that list. | ||
595 | |||
596 | Have fun! | ||
597 | |||
598 | -Fritz | ||
599 | |||
diff --git a/Documentation/isdn/README.FAQ b/Documentation/isdn/README.FAQ new file mode 100644 index 000000000000..356f7944641d --- /dev/null +++ b/Documentation/isdn/README.FAQ | |||
@@ -0,0 +1,26 @@ | |||
1 | |||
2 | The FAQ for isdn4linux | ||
3 | ====================== | ||
4 | |||
5 | Please note that there is a big FAQ available in the isdn4k-utils. | ||
6 | You find it in: | ||
7 | isdn4k-utils/FAQ/i4lfaq.sgml | ||
8 | |||
9 | In case you just want to see the FAQ online, or download the newest version, | ||
10 | you can have a look at my website: | ||
11 | http://www.mhessler.de/i4lfaq/ (view + download) | ||
12 | or: | ||
13 | http://www.isdn4linux.de/faq/ (view) | ||
14 | |||
15 | As the extension tells, the FAQ is in SGML format, and you can convert it | ||
16 | into text/html/... format by using the sgml2txt/sgml2html/... tools. | ||
17 | Alternatively, you can also do a 'configure; make all' in the FAQ directory. | ||
18 | |||
19 | |||
20 | Please have a look at the FAQ before posting anything in the Mailinglist, | ||
21 | or the newsgroup! | ||
22 | |||
23 | |||
24 | Matthias Hessler | ||
25 | hessler@isdn4linux.de | ||
26 | |||
diff --git a/Documentation/isdn/README.HiSax b/Documentation/isdn/README.HiSax new file mode 100644 index 000000000000..031c8d814337 --- /dev/null +++ b/Documentation/isdn/README.HiSax | |||
@@ -0,0 +1,659 @@ | |||
1 | HiSax is a Linux hardware-level driver for passive ISDN cards with Siemens | ||
2 | chipset (ISAC_S 2085/2086/2186, HSCX SAB 82525). It is based on the Teles | ||
3 | driver from Jan den Ouden. | ||
4 | It is meant to be used with isdn4linux, an ISDN link-level module for Linux | ||
5 | written by Fritz Elfert. | ||
6 | |||
7 | This program is free software; you can redistribute it and/or modify | ||
8 | it under the terms of the GNU General Public License as published by | ||
9 | the Free Software Foundation; either version 2 of the License, or | ||
10 | (at your option) any later version. | ||
11 | |||
12 | This program is distributed in the hope that it will be useful, | ||
13 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
14 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
15 | GNU General Public License for more details. | ||
16 | |||
17 | You should have received a copy of the GNU General Public License | ||
18 | along with this program; if not, write to the Free Software | ||
19 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
20 | |||
21 | |||
22 | Supported cards | ||
23 | --------------- | ||
24 | |||
25 | Teles 8.0/16.0/16.3 and compatible ones | ||
26 | Teles 16.3c | ||
27 | Teles S0/PCMCIA | ||
28 | Teles PCI | ||
29 | Teles S0Box | ||
30 | Creatix S0Box | ||
31 | Creatix PnP S0 | ||
32 | Compaq ISDN S0 ISA card | ||
33 | AVM A1 (Fritz, Teledat 150) | ||
34 | AVM Fritz PCMCIA | ||
35 | AVM Fritz PnP | ||
36 | AVM Fritz PCI | ||
37 | ELSA Microlink PCC-16, PCF, PCF-Pro, PCC-8 | ||
38 | ELSA Quickstep 1000 | ||
39 | ELSA Quickstep 1000PCI | ||
40 | ELSA Quickstep 3000 (same settings as QS1000) | ||
41 | ELSA Quickstep 3000PCI | ||
42 | ELSA PCMCIA | ||
43 | ITK ix1-micro Rev.2 | ||
44 | Eicon Diva 2.0 ISA and PCI (S0 and U interface, no PRO version) | ||
45 | Eicon Diva 2.01 ISA and PCI | ||
46 | Eicon Diva 2.02 PCI | ||
47 | Eicon Diva Piccola | ||
48 | ASUSCOM NETWORK INC. ISDNLink 128K PC adapter (order code I-IN100-ST-D) | ||
49 | Dynalink IS64PH (OEM version of ASUSCOM NETWORK INC. ISDNLink 128K adapter) | ||
50 | PCBIT-DP (OEM version of ASUSCOM NETWORK INC. ISDNLink) | ||
51 | HFC-2BS0 based cards (TeleInt SA1) | ||
52 | Sedlbauer Speed Card (Speed Win, Teledat 100, PCI, Fax+) | ||
53 | Sedlbauer Speed Star/Speed Star2 (PCMCIA) | ||
54 | Sedlbauer ISDN-Controller PC/104 | ||
55 | USR Sportster internal TA (compatible Stollmann tina-pp V3) | ||
56 | USR internal TA PCI | ||
57 | ith Kommunikationstechnik GmbH MIC 16 ISA card | ||
58 | Traverse Technologie NETjet PCI S0 card and NETspider U card | ||
59 | Ovislink ISDN sc100-p card (NETjet driver) | ||
60 | Dr. Neuhaus Niccy PnP/PCI | ||
61 | Siemens I-Surf 1.0 | ||
62 | Siemens I-Surf 2.0 (with IPAC, try type 12 asuscom) | ||
63 | ACER P10 | ||
64 | HST Saphir | ||
65 | Berkom Telekom A4T | ||
66 | Scitel Quadro | ||
67 | Gazel ISDN cards | ||
68 | HFC-PCI based cards | ||
69 | Winbond W6692 based cards | ||
70 | HFC-S+, HFC-SP/PCMCIA cards | ||
71 | formula-n enternow | ||
72 | Gerdes Power ISDN | ||
73 | |||
74 | Note: PCF, PCF-Pro: up to now, only the ISDN part is supported | ||
75 | PCC-8: not tested yet | ||
76 | Eicon.Diehl Diva U interface not tested | ||
77 | |||
78 | If you know other passive cards with the Siemens chipset, please let me know. | ||
79 | You can combine any card, if there is no conflict between the resources | ||
80 | (io, mem, irq). | ||
81 | |||
82 | |||
83 | Configuring the driver | ||
84 | ---------------------- | ||
85 | |||
86 | The HiSax driver can either be built directly into the kernel or as a module. | ||
87 | It can be configured using the command line feature while loading the kernel | ||
88 | with LILO or LOADLIN or, if built as a module, using insmod/modprobe with | ||
89 | parameters. | ||
90 | There is also some config needed before you compile the kernel and/or | ||
91 | modules. It is included in the normal "make [menu]config" target at the | ||
92 | kernel. Don't forget it, especially to select the right D-channel protocol. | ||
93 | |||
94 | Please note: In older versions of the HiSax driver, all PnP cards | ||
95 | needed to be configured with isapnp and worked only with the HiSax | ||
96 | driver used as a module. | ||
97 | |||
98 | In the current version, HiSax will automatically use the in-kernel | ||
99 | ISAPnP support, provided you selected it during kernel configuration | ||
100 | (CONFIG_ISAPNP), if you don't give the io=, irq= command line parameters. | ||
101 | |||
102 | The affected card types are: 4,7,12,14,19,27-30 | ||
103 | |||
104 | a) when built as a module | ||
105 | ------------------------- | ||
106 | |||
107 | insmod/modprobe hisax.o \ | ||
108 | io=iobase irq=IRQ mem=membase type=card_type \ | ||
109 | protocol=D_channel_protocol id=idstring | ||
110 | |||
111 | or, if several cards are installed: | ||
112 | |||
113 | insmod/modprobe hisax.o \ | ||
114 | io=iobase1,iobase2,... irq=IRQ1,IRQ2,... mem=membase1,membase2,... \ | ||
115 | type=card_type1,card_type2,... \ | ||
116 | protocol=D_channel_protocol1,D_channel_protocol2,... \ | ||
117 | id=idstring1%idstring2 ... | ||
118 | |||
119 | where "iobaseN" represents the I/O base address of the Nth card, "membaseN" | ||
120 | the memory base address of the Nth card, etc. | ||
121 | |||
122 | The reason for the delimiter "%" being used in the idstrings is that "," | ||
123 | won't work with the current modules package. | ||
124 | |||
125 | The parameters may be specified in any order. For example, the "io" | ||
126 | parameter may precede the "irq" parameter, or vice versa. If several | ||
127 | cards are installed, the ordering within the comma separated parameter | ||
128 | lists must of course be consistent. | ||
129 | |||
130 | Only parameters applicable to the card type need to be specified. For | ||
131 | example, the Teles 16.3 card is not memory-mapped, so the "mem" | ||
132 | parameter may be omitted for this card. Sometimes it may be necessary | ||
133 | to specify a dummy parameter, however. This is the case when there is | ||
134 | a card of a different type later in the list that needs a parameter | ||
135 | which the preceding card does not. For instance, if a Teles 16.0 card | ||
136 | is listed after a Teles 16.3 card, a dummy memory base parameter of 0 | ||
137 | must be specified for the 16.3. Instead of a dummy value, the parameter | ||
138 | can also be skipped by simply omitting the value. For example: | ||
139 | mem=,0xd0000. See example 6 below. | ||
140 | |||
141 | The parameter for the D-Channel protocol may be omitted if you selected the | ||
142 | correct one during kernel config. Valid values are "1" for German 1TR6, | ||
143 | "2" for EDSS1 (Euro ISDN), "3" for leased lines (no D-Channel) and "4" | ||
144 | for US NI1. | ||
145 | With US NI1 you have to include your SPID into the MSN setting in the form | ||
146 | <MSN>:<SPID> for example (your phonenumber is 1234 your SPID 5678): | ||
147 | AT&E1234:5678 on ttyI interfaces | ||
148 | isdnctrl eaz ippp0 1234:5678 on network devices | ||
149 | |||
150 | The Creatix/Teles PnP cards use io1= and io2= instead of io= for specifying | ||
151 | the I/O addresses of the ISAC and HSCX chips, respectively. | ||
152 | |||
153 | Card types: | ||
154 | |||
155 | Type Required parameters (in addition to type and protocol) | ||
156 | |||
157 | 1 Teles 16.0 irq, mem, io | ||
158 | 2 Teles 8.0 irq, mem | ||
159 | 3 Teles 16.3 (non PnP) irq, io | ||
160 | 4 Creatix/Teles PnP irq, io0 (ISAC), io1 (HSCX) | ||
161 | 5 AVM A1 (Fritz) irq, io | ||
162 | 6 ELSA PCC/PCF cards io or nothing for autodetect (the iobase is | ||
163 | required only if you have more than one ELSA | ||
164 | card in your PC) | ||
165 | 7 ELSA Quickstep 1000 irq, io (from isapnp setup) | ||
166 | 8 Teles 16.3 PCMCIA irq, io | ||
167 | 9 ITK ix1-micro Rev.2 irq, io | ||
168 | 10 ELSA PCMCIA irq, io (set with card manager) | ||
169 | 11 Eicon.Diehl Diva ISA PnP irq, io | ||
170 | 11 Eicon.Diehl Diva PCI no parameter | ||
171 | 12 ASUS COM ISDNLink irq, io (from isapnp setup) | ||
172 | 13 HFC-2BS0 based cards irq, io | ||
173 | 14 Teles 16.3c PnP irq, io | ||
174 | 15 Sedlbauer Speed Card irq, io | ||
175 | 15 Sedlbauer PC/104 irq, io | ||
176 | 15 Sedlbauer Speed PCI no parameter | ||
177 | 16 USR Sportster internal irq, io | ||
178 | 17 MIC card irq, io | ||
179 | 18 ELSA Quickstep 1000PCI no parameter | ||
180 | 19 Compaq ISDN S0 ISA card irq, io0, io1, io (from isapnp setup io=IO2) | ||
181 | 20 NETjet PCI card no parameter | ||
182 | 21 Teles PCI no parameter | ||
183 | 22 Sedlbauer Speed Star (PCMCIA) irq, io (set with card manager) | ||
184 | 24 Dr. Neuhaus Niccy PnP irq, io0, io1 (from isapnp setup) | ||
185 | 24 Dr. Neuhaus Niccy PCI no parameter | ||
186 | 25 Teles S0Box irq, io (of the used lpt port) | ||
187 | 26 AVM A1 PCMCIA (Fritz!) irq, io (set with card manager) | ||
188 | 27 AVM PnP (Fritz!PnP) irq, io (from isapnp setup) | ||
189 | 27 AVM PCI (Fritz!PCI) no parameter | ||
190 | 28 Sedlbauer Speed Fax+ irq, io (from isapnp setup) | ||
191 | 29 Siemens I-Surf 1.0 irq, io, memory (from isapnp setup) | ||
192 | 30 ACER P10 irq, io (from isapnp setup) | ||
193 | 31 HST Saphir irq, io | ||
194 | 32 Telekom A4T none | ||
195 | 33 Scitel Quadro subcontroller (4*S0, subctrl 1...4) | ||
196 | 34 Gazel ISDN cards (ISA) irq,io | ||
197 | 34 Gazel ISDN cards (PCI) none | ||
198 | 35 HFC 2BDS0 PCI none | ||
199 | 36 W6692 based PCI cards none | ||
200 | 37 HFC 2BDS0 S+, SP irq,io | ||
201 | 38 NETspider U PCI card none | ||
202 | 39 HFC 2BDS0 SP/PCMCIA irq,io (set with cardmgr) | ||
203 | 40 hotplug interface | ||
204 | 41 Formula-n enter:now PCI none | ||
205 | |||
206 | At the moment IRQ sharing is only possible with PCI cards. Please make sure | ||
207 | that your IRQ is free and enabled for ISA use. | ||
208 | |||
209 | |||
210 | Examples for module loading | ||
211 | |||
212 | 1. Teles 16.3, Euro ISDN, I/O base 280 hex, IRQ 10 | ||
213 | modprobe hisax type=3 protocol=2 io=0x280 irq=10 | ||
214 | |||
215 | 2. Teles 16.0, 1TR6 ISDN, I/O base d80 hex, IRQ 5, Memory d0000 hex | ||
216 | modprobe hisax protocol=1 type=1 io=0xd80 mem=0xd0000 irq=5 | ||
217 | |||
218 | 3. Fritzcard, Euro ISDN, I/O base 340 hex, IRQ 10 and ELSA PCF, Euro ISDN | ||
219 | modprobe hisax type=5,6 protocol=2,2 io=0x340 irq=10 id=Fritz%Elsa | ||
220 | |||
221 | 4. Any ELSA PCC/PCF card, Euro ISDN | ||
222 | modprobe hisax type=6 protocol=2 | ||
223 | |||
224 | 5. Teles 16.3 PnP, Euro ISDN, with isapnp configured | ||
225 | isapnp config: (INT 0 (IRQ 10 (MODE +E))) | ||
226 | (IO 0 (BASE 0x0580)) | ||
227 | (IO 1 (BASE 0x0180)) | ||
228 | modprobe hisax type=4 protocol=2 irq=10 io0=0x580 io1=0x180 | ||
229 | |||
230 | In the current version of HiSax, you can instead simply use | ||
231 | |||
232 | modprobe hisax type=4 protocol=2 | ||
233 | |||
234 | if you configured your kernel for ISAPnP. Don't run isapnp in | ||
235 | this case! | ||
236 | |||
237 | 6. Teles 16.3, Euro ISDN, I/O base 280 hex, IRQ 12 and | ||
238 | Teles 16.0, 1TR6, IRQ 5, Memory d0000 hex | ||
239 | modprobe hisax type=3,1 protocol=2,1 io=0x280 mem=0,0xd0000 | ||
240 | |||
241 | Please note the dummy 0 memory address for the Teles 16.3, used as a | ||
242 | placeholder as described above, in the last example. | ||
243 | |||
244 | 7. Teles PCMCIA, Euro ISDN, I/O base 180 hex, IRQ 15 (default values) | ||
245 | modprobe hisax type=8 protocol=2 io=0x180 irq=15 | ||
246 | |||
247 | |||
248 | b) using LILO/LOADLIN, with the driver compiled directly into the kernel | ||
249 | ------------------------------------------------------------------------ | ||
250 | |||
251 | hisax=typ1,dp1,pa_1,pb_1,pc_1[,typ2,dp2,pa_2 ... \ | ||
252 | typn,dpn,pa_n,pb_n,pc_n][,idstring1[,idstring2,...,idstringn]] | ||
253 | |||
254 | where | ||
255 | typ1 = type of 1st card (default depends on kernel settings) | ||
256 | dp1 = D-Channel protocol of 1st card. 1=1TR6, 2=EDSS1, 3=leased | ||
257 | pa_1 = 1st parameter (depending on the type of the card) | ||
258 | pb_1 = 2nd parameter ( " " " " " " " ) | ||
259 | pc_1 = 3rd parameter ( " " " " " " " ) | ||
260 | |||
261 | typ2,dp2,pa_2,pb_2,pc_2 = Parameters of the second card (defaults: none) | ||
262 | typn,dpn,pa_n,pb_n,pc_n = Parameters of the n'th card (up to 16 cards are | ||
263 | supported) | ||
264 | |||
265 | idstring = Driver ID for accessing the particular card with utility | ||
266 | programs and for identification when using a line monitor | ||
267 | (default: "HiSax") | ||
268 | |||
269 | Note: the ID string must start with an alphabetical character! | ||
270 | |||
271 | Card types: | ||
272 | |||
273 | type | ||
274 | 1 Teles 16.0 pa=irq pb=membase pc=iobase | ||
275 | 2 Teles 8.0 pa=irq pb=membase | ||
276 | 3 Teles 16.3 pa=irq pb=iobase | ||
277 | 4 Creatix/Teles PNP ONLY WORKS AS A MODULE ! | ||
278 | 5 AVM A1 (Fritz) pa=irq pb=iobase | ||
279 | 6 ELSA PCC/PCF cards pa=iobase or nothing for autodetect | ||
280 | 7 ELSA Quickstep 1000 ONLY WORKS AS A MODULE ! | ||
281 | 8 Teles S0 PCMCIA pa=irq pb=iobase | ||
282 | 9 ITK ix1-micro Rev.2 pa=irq pb=iobase | ||
283 | 10 ELSA PCMCIA pa=irq, pb=io (set with card manager) | ||
284 | 11 Eicon.Diehl Diva ISAPnP ONLY WORKS AS A MODULE ! | ||
285 | 11 Eicon.Diehl Diva PCI no parameter | ||
286 | 12 ASUS COM ISDNLink ONLY WORKS AS A MODULE ! | ||
287 | 13 HFC-2BS0 based cards pa=irq pb=io | ||
288 | 14 Teles 16.3c PnP ONLY WORKS AS A MODULE ! | ||
289 | 15 Sedlbauer Speed Card pa=irq pb=io (Speed Win only as module !) | ||
290 | 15 Sedlbauer PC/104 pa=irq pb=io | ||
291 | 15 Sedlbauer Speed PCI no parameter | ||
292 | 16 USR Sportster internal pa=irq pb=io | ||
293 | 17 MIC card pa=irq pb=io | ||
294 | 18 ELSA Quickstep 1000PCI no parameter | ||
295 | 19 Compaq ISDN S0 ISA card ONLY WORKS AS A MODULE ! | ||
296 | 20 NETjet PCI card no parameter | ||
297 | 21 Teles PCI no parameter | ||
298 | 22 Sedlbauer Speed Star (PCMCIA) pa=irq, pb=io (set with card manager) | ||
299 | 24 Dr. Neuhaus Niccy PnP ONLY WORKS AS A MODULE ! | ||
300 | 24 Dr. Neuhaus Niccy PCI no parameter | ||
301 | 25 Teles S0Box pa=irq, pb=io (of the used lpt port) | ||
302 | 26 AVM A1 PCMCIA (Fritz!) pa=irq, pb=io (set with card manager) | ||
303 | 27 AVM PnP (Fritz!PnP) ONLY WORKS AS A MODULE ! | ||
304 | 27 AVM PCI (Fritz!PCI) no parameter | ||
305 | 28 Sedlbauer Speed Fax+ ONLY WORKS AS A MODULE ! | ||
306 | 29 Siemens I-Surf 1.0 ONLY WORKS AS A MODULE ! | ||
307 | 30 ACER P10 ONLY WORKS AS A MODULE ! | ||
308 | 31 HST Saphir pa=irq, pb=io | ||
309 | 32 Telekom A4T no parameter | ||
310 | 33 Scitel Quadro subcontroller (4*S0, subctrl 1...4) | ||
311 | 34 Gazel ISDN cards (ISA) pa=irq, pb=io | ||
312 | 34 Gazel ISDN cards (PCI) no parameter | ||
313 | 35 HFC 2BDS0 PCI no parameter | ||
314 | 36 W6692 based PCI cards none | ||
315 | 37 HFC 2BDS0 S+,SP/PCMCIA ONLY WORKS AS A MODULE ! | ||
316 | 38 NETspider U PCI card none | ||
317 | 39 HFC 2BDS0 SP/PCMCIA ONLY WORKS AS A MODULE ! | ||
318 | 40 hotplug interface ONLY WORKS AS A MODULE ! | ||
319 | 41 Formula-n enter:now PCI none | ||
320 | |||
321 | Running the driver | ||
322 | ------------------ | ||
323 | |||
324 | When you insmod isdn.o and hisax.o (or with the in-kernel version, during | ||
325 | boot time), a few lines should appear in your syslog. Look for something like: | ||
326 | |||
327 | Apr 13 21:01:59 kke01 kernel: HiSax: Driver for Siemens chip set ISDN cards | ||
328 | Apr 13 21:01:59 kke01 kernel: HiSax: Version 2.9 | ||
329 | Apr 13 21:01:59 kke01 kernel: HiSax: Revisions 1.14/1.9/1.10/1.25/1.8 | ||
330 | Apr 13 21:01:59 kke01 kernel: HiSax: Total 1 card defined | ||
331 | Apr 13 21:01:59 kke01 kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax1 (0) | ||
332 | Apr 13 21:01:59 kke01 kernel: HiSax: Elsa driver Rev. 1.13 | ||
333 | ... | ||
334 | Apr 13 21:01:59 kke01 kernel: Elsa: PCF-Pro found at 0x360 Rev.:C IRQ 10 | ||
335 | Apr 13 21:01:59 kke01 kernel: Elsa: timer OK; resetting card | ||
336 | Apr 13 21:01:59 kke01 kernel: Elsa: HSCX version A: V2.1 B: V2.1 | ||
337 | Apr 13 21:01:59 kke01 kernel: Elsa: ISAC 2086/2186 V1.1 | ||
338 | ... | ||
339 | Apr 13 21:01:59 kke01 kernel: HiSax: DSS1 Rev. 1.14 | ||
340 | Apr 13 21:01:59 kke01 kernel: HiSax: 2 channels added | ||
341 | |||
342 | This means that the card is ready for use. | ||
343 | Cabling problems or line-downs are not detected, and only some ELSA cards can | ||
344 | detect the S0 power. | ||
345 | |||
346 | Remember that, according to the new strategy for accessing low-level drivers | ||
347 | from within isdn4linux, you should also define a driver ID while doing | ||
348 | insmod: Simply append hisax_id=<SomeString> to the insmod command line. This | ||
349 | string MUST NOT start with a digit or a small 'x'! | ||
350 | |||
351 | At this point you can run a 'cat /dev/isdnctrl0' and view debugging messages. | ||
352 | |||
353 | At the moment, debugging messages are enabled with the hisaxctrl tool: | ||
354 | |||
355 | hisaxctrl <DriverId> DebugCmd <debugging_flags> | ||
356 | |||
357 | <DriverId> default is HiSax, if you didn't specify one. | ||
358 | |||
359 | DebugCmd is 1 for generic debugging | ||
360 | 11 for layer 1 development debugging | ||
361 | 13 for layer 3 development debugging | ||
362 | |||
363 | where <debugging_flags> is the integer sum of the following debugging | ||
364 | options you wish enabled: | ||
365 | |||
366 | With DebugCmd set to 1: | ||
367 | |||
368 | 0x0001 Link-level <--> hardware-level communication | ||
369 | 0x0002 Top state machine | ||
370 | 0x0004 D-Channel Frames for isdnlog | ||
371 | 0x0008 D-Channel Q.921 | ||
372 | 0x0010 B-Channel X.75 | ||
373 | 0x0020 D-Channel l2 | ||
374 | 0x0040 B-Channel l2 | ||
375 | 0x0080 D-Channel link state debugging | ||
376 | 0x0100 B-Channel link state debugging | ||
377 | 0x0200 TEI debug | ||
378 | 0x0400 LOCK debug in callc.c | ||
379 | 0x0800 More paranoid debug in callc.c (not for normal use) | ||
380 | 0x1000 D-Channel l1 state debugging | ||
381 | 0x2000 B-Channel l1 state debugging | ||
382 | |||
383 | With DebugCmd set to 11: | ||
384 | |||
385 | 0x0001 Warnings (default: on) | ||
386 | 0x0002 IRQ status | ||
387 | 0x0004 ISAC | ||
388 | 0x0008 ISAC FIFO | ||
389 | 0x0010 HSCX | ||
390 | 0x0020 HSCX FIFO (attention: full B-Channel output!) | ||
391 | 0x0040 D-Channel LAPD frame types | ||
392 | 0x0080 IPAC debug | ||
393 | 0x0100 HFC receive debug | ||
394 | 0x0200 ISAC monitor debug | ||
395 | 0x0400 D-Channel frames for isdnlog (set with 1 0x4 too) | ||
396 | 0x0800 D-Channel message verbose | ||
397 | |||
398 | With DebugCmd set to 13: | ||
399 | |||
400 | 1 Warnings (default: on) | ||
401 | 2 l3 protocol descriptor errors | ||
402 | 4 l3 state machine | ||
403 | 8 charge info debugging (1TR6) | ||
404 | |||
405 | For example, 'hisaxctrl HiSax 1 0x3ff' enables full generic debugging. | ||
406 | |||
407 | Because of some obscure problems with some switch equipment, the delay | ||
408 | between the CONNECT message and sending the first data on the B-channel is now | ||
409 | configurable with | ||
410 | |||
411 | hisaxctrl <DriverId> 2 <delay> | ||
412 | <delay> in ms Value between 50 and 800 ms is recommended. | ||
413 | |||
414 | Downloading Firmware | ||
415 | -------------------- | ||
416 | At the moment, the Sedlbauer speed fax+ is the only card, which | ||
417 | needs to download firmware. | ||
418 | The firmware is downloaded with the hisaxctrl tool: | ||
419 | |||
420 | hisaxctrl <DriverId> 9 <firmware_filename> | ||
421 | |||
422 | <DriverId> default is HiSax, if you didn't specify one, | ||
423 | |||
424 | where <firmware_filename> is the filename of the firmware file. | ||
425 | |||
426 | For example, 'hisaxctrl HiSax 9 ISAR.BIN' downloads the firmware for | ||
427 | ISAR based cards (like the Sedlbauer speed fax+). | ||
428 | |||
429 | Warning | ||
430 | ------- | ||
431 | HiSax is a work in progress and may crash your machine. | ||
432 | For certification look at HiSax.cert file. | ||
433 | |||
434 | Limitations | ||
435 | ----------- | ||
436 | At this time, HiSax only works on Euro ISDN lines and German 1TR6 lines. | ||
437 | For leased lines see appendix. | ||
438 | |||
439 | Bugs | ||
440 | ---- | ||
441 | If you find any, please let me know. | ||
442 | |||
443 | |||
444 | Thanks | ||
445 | ------ | ||
446 | Special thanks to: | ||
447 | |||
448 | Emil Stephan for the name HiSax which is a mix of HSCX and ISAC. | ||
449 | |||
450 | Fritz Elfert, Jan den Ouden, Michael Hipp, Michael Wein, | ||
451 | Andreas Kool, Pekka Sarnila, Sim Yskes, Johan Myrre'en, | ||
452 | Klaus-Peter Nischke (ITK AG), Christof Petig, Werner Fehn (ELSA GmbH), | ||
453 | Volker Schmidt | ||
454 | Edgar Toernig and Marcus Niemann for the Sedlbauer driver | ||
455 | Stephan von Krawczynski | ||
456 | Juergen Quade for the Leased Line part | ||
457 | Klaus Lichtenwalder (Klaus.Lichtenwalder@WebForum.DE), for ELSA PCMCIA support | ||
458 | Enrik Berkhan (enrik@starfleet.inka.de) for S0BOX specific stuff | ||
459 | Ton van Rosmalen for Teles PCI | ||
460 | Petr Novak <petr.novak@i.cz> for Winbond W6692 support | ||
461 | Werner Cornelius <werner@isdn4linux.de> for HFC-PCI, HFC-S(+/P) and supplementary services support | ||
462 | and more people who are hunting bugs. (If I forgot somebody, please | ||
463 | send me a mail). | ||
464 | |||
465 | Firma ELSA GmbH | ||
466 | Firma Eicon.Diehl GmbH | ||
467 | Firma Dynalink NL | ||
468 | Firma ASUSCOM NETWORK INC. Taiwan | ||
469 | Firma S.u.S.E | ||
470 | Firma ith Kommunikationstechnik GmbH | ||
471 | Firma Traverse Technologie Australia | ||
472 | Firma Medusa GmbH (www.medusa.de). | ||
473 | Firma Quant-X Austria for sponsoring a DEC Alpha board+CPU | ||
474 | Firma Cologne Chip Designs GmbH | ||
475 | |||
476 | My girl friend and partner in life Ute for her patience with me. | ||
477 | |||
478 | |||
479 | Enjoy, | ||
480 | |||
481 | Karsten Keil | ||
482 | keil@isdn4linux.de | ||
483 | |||
484 | |||
485 | Appendix: Teles PCMCIA driver | ||
486 | ----------------------------- | ||
487 | |||
488 | See | ||
489 | http://www.stud.uni-wuppertal.de/~ea0141/pcmcia.html | ||
490 | for instructions. | ||
491 | |||
492 | Appendix: Linux and ISDN-leased lines | ||
493 | ------------------------------------- | ||
494 | |||
495 | Original from Juergen Quade, new version KKe. | ||
496 | |||
497 | Attention NEW VERSION, the old leased line syntax won't work !!! | ||
498 | |||
499 | You can use HiSax to connect your Linux-Box via an ISDN leased line | ||
500 | to e.g. the Internet: | ||
501 | |||
502 | 1. Build a kernel which includes the HiSax driver either as a module | ||
503 | or as part of the kernel. | ||
504 | cd /usr/src/linux | ||
505 | make menuconfig | ||
506 | <ISDN subsystem - ISDN support -- HiSax> | ||
507 | make clean; make zImage; make modules; make modules_install | ||
508 | 2. Install the new kernel | ||
509 | cp /usr/src/linux/arch/i386/boot/zImage /etc/kernel/linux.isdn | ||
510 | vi /etc/lilo.conf | ||
511 | <add new kernel in the bootable image section> | ||
512 | lilo | ||
513 | 3. in case the hisax driver is a "fixed" part of the kernel, configure | ||
514 | the driver with lilo: | ||
515 | vi /etc/lilo.conf | ||
516 | <add HiSax driver parameter in the global section (see below)> | ||
517 | lilo | ||
518 | Your lilo.conf _might_ look like the following: | ||
519 | |||
520 | # LILO configuration-file | ||
521 | # global section | ||
522 | # teles 16.0 on IRQ=5, MEM=0xd8000, PORT=0xd80 | ||
523 | append="hisax=1,3,5,0xd8000,0xd80,HiSax" | ||
524 | # teles 16.3 (non pnp) on IRQ=15, PORT=0xd80 | ||
525 | # append="hisax=3,3,5,0xd8000,0xd80,HiSax" | ||
526 | boot=/dev/sda | ||
527 | compact # faster, but won't work on all systems. | ||
528 | linear | ||
529 | read-only | ||
530 | prompt | ||
531 | timeout=100 | ||
532 | vga = normal # force sane state | ||
533 | # Linux bootable partition config begins | ||
534 | image = /etc/kernel/linux.isdn | ||
535 | root = /dev/sda1 | ||
536 | label = linux.isdn | ||
537 | # | ||
538 | image = /etc/kernel/linux-2.0.30 | ||
539 | root = /dev/sda1 | ||
540 | label = linux.secure | ||
541 | |||
542 | In the line starting with "append" you have to adapt the parameters | ||
543 | according to your card (see above in this file) | ||
544 | |||
545 | 3. boot the new linux.isdn kernel | ||
546 | 4. start the ISDN subsystem: | ||
547 | a) load - if necessary - the modules (depends, whether you compiled | ||
548 | the ISDN driver as module or not) | ||
549 | According to the type of card you have to specify the necessary | ||
550 | driver parameter (irq, io, mem, type, protocol). | ||
551 | For the leased line the protocol is "3". See the table above for | ||
552 | the parameters, which you have to specify depending on your card. | ||
553 | b) configure i4l | ||
554 | /sbin/isdnctrl addif isdn0 | ||
555 | # EAZ 1 -- B1 channel 2 --B2 channel | ||
556 | /sbin/isdnctrl eaz isdn0 1 | ||
557 | /sbin/isdnctrl secure isdn0 on | ||
558 | /sbin/isdnctrl huptimeout isdn0 0 | ||
559 | /sbin/isdnctrl l2_prot isdn0 hdlc | ||
560 | # Attention you must not set an outgoing number !!! This won't work !!! | ||
561 | # The incoming number is LEASED0 for the first card, LEASED1 for the | ||
562 | # second and so on. | ||
563 | /sbin/isdnctrl addphone isdn0 in LEASED0 | ||
564 | # Here is no need to bind the channel. | ||
565 | c) in case the remote partner is a CISCO: | ||
566 | /sbin/isdnctrl encap isdn0 cisco-h | ||
567 | d) configure the interface | ||
568 | /sbin/ifconfig isdn0 ${LOCAL_IP} pointopoint ${REMOTE_IP} | ||
569 | e) set the routes | ||
570 | /sbin/route add -host ${REMOTE_IP} isdn0 | ||
571 | /sbin/route add default gw ${REMOTE_IP} | ||
572 | f) switch the card into leased mode for each used B-channel | ||
573 | /sbin/hisaxctrl HiSax 5 1 | ||
574 | |||
575 | Remarks: | ||
576 | a) Use state of the art isdn4k-utils | ||
577 | |||
578 | Here an example script: | ||
579 | #!/bin/sh | ||
580 | # Start/Stop ISDN leased line connection | ||
581 | |||
582 | I4L_AS_MODULE=yes | ||
583 | I4L_REMOTE_IS_CISCO=no | ||
584 | I4L_MODULE_PARAMS="type=16 io=0x268 irq=7 " | ||
585 | I4L_DEBUG=no | ||
586 | I4L_LEASED_128K=yes | ||
587 | LOCAL_IP=192.168.1.1 | ||
588 | REMOTE_IP=192.168.2.1 | ||
589 | |||
590 | case "$1" in | ||
591 | start) | ||
592 | echo "Starting ISDN ..." | ||
593 | if [ ${I4L_AS_MODULE} = "yes" ]; then | ||
594 | echo "loading modules..." | ||
595 | /sbin/modprobe hisax ${I4L_MODULE_PARAMS} | ||
596 | fi | ||
597 | # configure interface | ||
598 | /sbin/isdnctrl addif isdn0 | ||
599 | /sbin/isdnctrl secure isdn0 on | ||
600 | if [ ${I4L_DEBUG} = "yes" ]; then | ||
601 | /sbin/isdnctrl verbose 7 | ||
602 | /sbin/hisaxctrl HiSax 1 0xffff | ||
603 | /sbin/hisaxctrl HiSax 11 0xff | ||
604 | cat /dev/isdnctrl >/tmp/lea.log & | ||
605 | fi | ||
606 | if [ ${I4L_REMOTE_IS_CISCO} = "yes" ]; then | ||
607 | /sbin/isdnctrl encap isdn0 cisco-h | ||
608 | fi | ||
609 | /sbin/isdnctrl huptimeout isdn0 0 | ||
610 | # B-CHANNEL 1 | ||
611 | /sbin/isdnctrl eaz isdn0 1 | ||
612 | /sbin/isdnctrl l2_prot isdn0 hdlc | ||
613 | # 1. card | ||
614 | /sbin/isdnctrl addphone isdn0 in LEASED0 | ||
615 | if [ ${I4L_LEASED_128K} = "yes" ]; then | ||
616 | /sbin/isdnctrl addslave isdn0 isdn0s | ||
617 | /sbin/isdnctrl secure isdn0s on | ||
618 | /sbin/isdnctrl huptimeout isdn0s 0 | ||
619 | # B-CHANNEL 2 | ||
620 | /sbin/isdnctrl eaz isdn0s 2 | ||
621 | /sbin/isdnctrl l2_prot isdn0s hdlc | ||
622 | # 1. card | ||
623 | /sbin/isdnctrl addphone isdn0s in LEASED0 | ||
624 | if [ ${I4L_REMOTE_IS_CISCO} = "yes" ]; then | ||
625 | /sbin/isdnctrl encap isdn0s cisco-h | ||
626 | fi | ||
627 | fi | ||
628 | /sbin/isdnctrl dialmode isdn0 manual | ||
629 | # configure tcp/ip | ||
630 | /sbin/ifconfig isdn0 ${LOCAL_IP} pointopoint ${REMOTE_IP} | ||
631 | /sbin/route add -host ${REMOTE_IP} isdn0 | ||
632 | /sbin/route add default gw ${REMOTE_IP} | ||
633 | # switch to leased mode | ||
634 | # B-CHANNEL 1 | ||
635 | /sbin/hisaxctrl HiSax 5 1 | ||
636 | if [ ${I4L_LEASED_128K} = "yes" ]; then | ||
637 | # B-CHANNEL 2 | ||
638 | sleep 10; /* Wait for master */ | ||
639 | /sbin/hisaxctrl HiSax 5 2 | ||
640 | fi | ||
641 | ;; | ||
642 | stop) | ||
643 | /sbin/ifconfig isdn0 down | ||
644 | /sbin/isdnctrl delif isdn0 | ||
645 | if [ ${I4L_DEBUG} = "yes" ]; then | ||
646 | killall cat | ||
647 | fi | ||
648 | if [ ${I4L_AS_MODULE} = "yes" ]; then | ||
649 | /sbin/rmmod hisax | ||
650 | /sbin/rmmod isdn | ||
651 | /sbin/rmmod ppp | ||
652 | /sbin/rmmod slhc | ||
653 | fi | ||
654 | ;; | ||
655 | *) | ||
656 | echo "Usage: $0 {start|stop}" | ||
657 | exit 1 | ||
658 | esac | ||
659 | exit 0 | ||
diff --git a/Documentation/isdn/README.act2000 b/Documentation/isdn/README.act2000 new file mode 100644 index 000000000000..ce7115e7f4ce --- /dev/null +++ b/Documentation/isdn/README.act2000 | |||
@@ -0,0 +1,104 @@ | |||
1 | $Id: README.act2000,v 1.3 2000/08/06 09:22:51 armin Exp $ | ||
2 | |||
3 | This document describes the ACT2000 driver for the | ||
4 | IBM Active 2000 ISDN card. | ||
5 | |||
6 | There are 3 Types of this card available. A ISA-, MCA-, and PCMCIA-Bus | ||
7 | Version. Currently, only the ISA-Bus version of the card is supported. | ||
8 | However MCA and PCMCIA will follow soon. | ||
9 | |||
10 | The ISA-Bus Version uses 8 IO-ports. The base port address has to be set | ||
11 | manually using the DIP switches. | ||
12 | |||
13 | Setting up the DIP switches for the IBM Active 2000 ISDN card: | ||
14 | |||
15 | Note: S5 and S6 always set off! | ||
16 | |||
17 | S1 S2 S3 S4 Base-port | ||
18 | on on on on 0x0200 (Factory default) | ||
19 | off on on on 0x0240 | ||
20 | on off on on 0x0280 | ||
21 | off off on on 0x02c0 | ||
22 | on on off on 0x0300 | ||
23 | off on off on 0x0340 | ||
24 | on off off on 0x0380 | ||
25 | on on on off 0xcfe0 | ||
26 | off on on off 0xcfa0 | ||
27 | on off on off 0xcf60 | ||
28 | off off on off 0xcf20 | ||
29 | on on off off 0xcee0 | ||
30 | off on off off 0xcea0 | ||
31 | on off off off 0xce60 | ||
32 | off off off off Card disabled | ||
33 | |||
34 | IRQ is configured by software. Possible values are: | ||
35 | |||
36 | 3, 5, 7, 10, 11, 12, 15 and none (polled mode) | ||
37 | |||
38 | |||
39 | The ACT2000 driver may either be built into the kernel or as a module. | ||
40 | Initialization depends on how the driver is built: | ||
41 | |||
42 | Driver built into the kernel: | ||
43 | |||
44 | The ACT2000 driver can be configured using the commandline-feature while | ||
45 | loading the kernel with LILO or LOADLIN. It accepts the following syntax: | ||
46 | |||
47 | act2000=b,p,i[,idstring] | ||
48 | |||
49 | where | ||
50 | |||
51 | b = Bus-Type (1=ISA, 2=MCA, 3=PCMCIA) | ||
52 | p = portbase (-1 means autoprobe) | ||
53 | i = Interrupt (-1 means use next free IRQ, 0 means polled mode) | ||
54 | |||
55 | The idstring is an arbitrary string used for referencing the card | ||
56 | by the actctrl tool later. | ||
57 | |||
58 | Defaults used, when no parameters given at all: | ||
59 | |||
60 | 1,-1,-1,"" | ||
61 | |||
62 | which means: Autoprobe for an ISA card, use next free IRQ, let the | ||
63 | ISDN linklevel fill the IdString (usually "line0" for the first card). | ||
64 | |||
65 | If you like to use more than one card, you can use the program | ||
66 | "actctrl" from the utility-package to configure additional cards. | ||
67 | |||
68 | Using the "actctrl"-utility, portbase and irq can also be changed | ||
69 | during runtime. The D-channel protocol is configured by the "dproto" | ||
70 | option of the "actctrl"-utility after loading the firmware into the | ||
71 | card's memory using the "actctrl"-utility. | ||
72 | |||
73 | Driver built as module: | ||
74 | |||
75 | The module act2000.o can be configured during modprobe (insmod) by | ||
76 | appending its parameters to the modprobe resp. insmod commandline. | ||
77 | The following syntax is accepted: | ||
78 | |||
79 | act_bus=b act_port=p act_irq=i act_id=idstring | ||
80 | |||
81 | where b, p, i and idstring have the same meanings as the parameters | ||
82 | described for the builtin version above. | ||
83 | |||
84 | Using the "actctrl"-utility, the same features apply to the modularized | ||
85 | version as to the kernel-builtin one. (i.e. loading of firmware and | ||
86 | configuring the D-channel protocol) | ||
87 | |||
88 | Loading the firmware into the card: | ||
89 | |||
90 | The firmware is supplied together with the isdn4k-utils package. It | ||
91 | can be found in the subdirectory act2000/firmware/ | ||
92 | |||
93 | Assuming you have installed the utility-package correctly, the firmware | ||
94 | will be downloaded into the card using the following command: | ||
95 | |||
96 | actctrl -d idstring load /etc/isdn/bip11.btl | ||
97 | |||
98 | where idstring is the Name of the card, given during insmod-time or | ||
99 | (for kernel-builtin driver) on the kernel commandline. If only one | ||
100 | ISDN card is used, the -d isdstrin may be omitted. | ||
101 | |||
102 | For further documentation (adding more IBM Active 2000 cards), refer to | ||
103 | the manpage actctrl.8 which is included in the isdn4k-utils package. | ||
104 | |||
diff --git a/Documentation/isdn/README.audio b/Documentation/isdn/README.audio new file mode 100644 index 000000000000..8ebca19290d9 --- /dev/null +++ b/Documentation/isdn/README.audio | |||
@@ -0,0 +1,138 @@ | |||
1 | $Id: README.audio,v 1.8 1999/07/11 17:17:29 armin Exp $ | ||
2 | |||
3 | ISDN subsystem for Linux. | ||
4 | Description of audio mode. | ||
5 | |||
6 | When enabled during kernel configuration, the tty emulator of the ISDN | ||
7 | subsystem is capable of a reduced set of commands to support audio. | ||
8 | This document describes the commands supported and the format of | ||
9 | audio data. | ||
10 | |||
11 | Commands for enabling/disabling audio mode: | ||
12 | |||
13 | AT+FCLASS=8 Enable audio mode. | ||
14 | This affects the following registers: | ||
15 | S18: Bits 0 and 2 are set. | ||
16 | S16: Set to 48 and any further change to | ||
17 | larger values is blocked. | ||
18 | AT+FCLASS=0 Disable audio mode. | ||
19 | Register 18 is set to 4. | ||
20 | AT+FCLASS=? Show possible modes. | ||
21 | AT+FCLASS? Report current mode (0 or 8). | ||
22 | |||
23 | Commands supported in audio mode: | ||
24 | |||
25 | All audio mode commands have one of the following forms: | ||
26 | |||
27 | AT+Vxx? Show current setting. | ||
28 | AT+Vxx=? Show possible settings. | ||
29 | AT+Vxx=v Set simple parameter. | ||
30 | AT+Vxx=v,v ... Set complex parameter. | ||
31 | |||
32 | where xx is a two-character code and v are alphanumerical parameters. | ||
33 | The following commands are supported: | ||
34 | |||
35 | AT+VNH=x Auto hangup setting. NO EFFECT, supported | ||
36 | for compatibility only. | ||
37 | AT+VNH? Always reporting "1" | ||
38 | AT+VNH=? Always reporting "1" | ||
39 | |||
40 | AT+VIP Reset all audio parameters. | ||
41 | |||
42 | AT+VLS=x Line select. x is one of the following: | ||
43 | 0 = No device. | ||
44 | 2 = Phone line. | ||
45 | AT+VLS=? Always reporting "0,2" | ||
46 | AT+VLS? Show current line. | ||
47 | |||
48 | AT+VRX Start recording. Emulator responds with | ||
49 | CONNECT and starts sending audio data to | ||
50 | the application. See below for data format | ||
51 | |||
52 | AT+VSD=x,y Set silence-detection parameters. | ||
53 | Possible parameters: | ||
54 | x = 0 ... 31 sensitivity threshold level. | ||
55 | (default 0 , deactivated) | ||
56 | y = 0 ... 255 range of interval in units | ||
57 | of 0.1 second. (default 70) | ||
58 | AT+VSD=? Report possible parameters. | ||
59 | AT+VSD? Show current parameters. | ||
60 | |||
61 | AT+VDD=x,y Set DTMF-detection parameters. | ||
62 | Only possible if online and during this connection. | ||
63 | Possible parameters: | ||
64 | x = 0 ... 15 sensitivity threshold level. | ||
65 | (default 0 , I4L soft-decode) | ||
66 | (1-15 soft-decode off, hardware on) | ||
67 | y = 0 ... 255 tone duration in units of 5ms. | ||
68 | Not for I4L soft decode (default 8, 40ms) | ||
69 | AT+VDD=? Report possible parameters. | ||
70 | AT+VDD? Show current parameters. | ||
71 | |||
72 | AT+VSM=x Select audio data format. | ||
73 | Possible parameters: | ||
74 | 2 = ADPCM-2 | ||
75 | 3 = ADPCM-3 | ||
76 | 4 = ADPCM-4 | ||
77 | 5 = aLAW | ||
78 | 6 = uLAW | ||
79 | AT+VSM=? Show possible audio formats. | ||
80 | |||
81 | AT+VTX Start audio playback. Emulator responds | ||
82 | with CONNECT and starts sending audio data | ||
83 | received from the application via phone line. | ||
84 | General behavior and description of data formats/protocol. | ||
85 | when a connection is made: | ||
86 | |||
87 | On incoming calls, if the application responds to a RING | ||
88 | with ATA, depending on the calling service, the emulator | ||
89 | responds with either CONNECT (data call) or VCON (voice call). | ||
90 | |||
91 | On outgoing voice calls, the emulator responds with VCON | ||
92 | upon connection setup. | ||
93 | |||
94 | Audio recording. | ||
95 | |||
96 | When receiving audio data, a kind of bisync protocol is used. | ||
97 | Upon AT+VRX command, the emulator responds with CONNECT, and | ||
98 | starts sending audio data to the application. There are several | ||
99 | escape sequences defined, all using DLE (0x10) as Escape char: | ||
100 | |||
101 | <DLE><ETX> End of audio data. (i.e. caused by a | ||
102 | hangup of the remote side) Emulator stops | ||
103 | recording, responding with VCON. | ||
104 | <DLE><DC4> Abort recording, (send by appl.) Emulator | ||
105 | stops recording, sends DLE,ETX. | ||
106 | <DLE><DLE> Escape sequence for DLE in data stream. | ||
107 | <DLE>0 Touchtone "0" received. | ||
108 | ... | ||
109 | <DLE>9 Touchtone "9" received. | ||
110 | <DLE># Touchtone "#" received. | ||
111 | <DLE>* Touchtone "*" received. | ||
112 | <DLE>A Touchtone "A" received. | ||
113 | <DLE>B Touchtone "B" received. | ||
114 | <DLE>C Touchtone "C" received. | ||
115 | <DLE>D Touchtone "D" received. | ||
116 | |||
117 | <DLE>q quiet. Silence detected after non-silence. | ||
118 | <DLE>s silence. Silence detected from the | ||
119 | start of recording. | ||
120 | |||
121 | Currently unsupported DLE sequences: | ||
122 | |||
123 | <DLE>c FAX calling tone received. | ||
124 | <DLE>b busy tone received. | ||
125 | |||
126 | Audio playback. | ||
127 | |||
128 | When sending audio data, upon AT+VTX command, emulator responds with | ||
129 | CONNECT, and starts transferring data from application to the phone line. | ||
130 | The same DLE sequences apply to this mode. | ||
131 | |||
132 | Full-Duplex-Audio: | ||
133 | |||
134 | When _both_ commands for recording and playback are given in _one_ | ||
135 | AT-command-line (i.e.: "AT+VTX+VRX"), full-duplex-mode is selected. | ||
136 | In this mode, the only way to stop recording is sending <DLE><DC4> | ||
137 | and the only way to stop playback is to send <DLE><ETX>. | ||
138 | |||
diff --git a/Documentation/isdn/README.avmb1 b/Documentation/isdn/README.avmb1 new file mode 100644 index 000000000000..9e075484ef1e --- /dev/null +++ b/Documentation/isdn/README.avmb1 | |||
@@ -0,0 +1,187 @@ | |||
1 | Driver for active AVM Controller. | ||
2 | |||
3 | The driver provides a kernel capi2.0 Interface (kernelcapi) and | ||
4 | on top of this a User-Level-CAPI2.0-interface (capi) | ||
5 | and a driver to connect isdn4linux with CAPI2.0 (capidrv). | ||
6 | The lowlevel interface can be used to implement a CAPI2.0 | ||
7 | also for passive cards since July 1999. | ||
8 | |||
9 | The author can be reached at calle@calle.in-berlin.de. | ||
10 | The command avmcapictrl is part of the isdn4k-utils. | ||
11 | t4-files can be found at ftp://ftp.avm.de/cardware/b1/linux/firmware | ||
12 | |||
13 | Currently supported cards: | ||
14 | B1 ISA (all versions) | ||
15 | B1 PCI | ||
16 | T1/T1B (HEMA card) | ||
17 | M1 | ||
18 | M2 | ||
19 | B1 PCMCIA | ||
20 | |||
21 | Installing | ||
22 | ---------- | ||
23 | |||
24 | You need at least /dev/capi20 to load the firmware. | ||
25 | |||
26 | mknod /dev/capi20 c 68 0 | ||
27 | mknod /dev/capi20.00 c 68 1 | ||
28 | mknod /dev/capi20.01 c 68 2 | ||
29 | . | ||
30 | . | ||
31 | . | ||
32 | mknod /dev/capi20.19 c 68 20 | ||
33 | |||
34 | Running | ||
35 | ------- | ||
36 | |||
37 | To use the card you need the t4-files to download the firmware. | ||
38 | AVM GmbH provides several t4-files for the different D-channel | ||
39 | protocols (b1.t4 for Euro-ISDN). Install these file in /lib/isdn. | ||
40 | |||
41 | if you configure as modules load the modules this way: | ||
42 | |||
43 | insmod /lib/modules/current/misc/capiutil.o | ||
44 | insmod /lib/modules/current/misc/b1.o | ||
45 | insmod /lib/modules/current/misc/kernelcapi.o | ||
46 | insmod /lib/modules/current/misc/capidrv.o | ||
47 | insmod /lib/modules/current/misc/capi.o | ||
48 | |||
49 | if you have an B1-PCI card load the module b1pci.o | ||
50 | insmod /lib/modules/current/misc/b1pci.o | ||
51 | and load the firmware with | ||
52 | avmcapictrl load /lib/isdn/b1.t4 1 | ||
53 | |||
54 | if you have an B1-ISA card load the module b1isa.o | ||
55 | and add the card by calling | ||
56 | avmcapictrl add 0x150 15 | ||
57 | and load the firmware by calling | ||
58 | avmcapictrl load /lib/isdn/b1.t4 1 | ||
59 | |||
60 | if you have an T1-ISA card load the module t1isa.o | ||
61 | and add the card by calling | ||
62 | avmcapictrl add 0x450 15 T1 0 | ||
63 | and load the firmware by calling | ||
64 | avmcapictrl load /lib/isdn/t1.t4 1 | ||
65 | |||
66 | if you have an PCMCIA card (B1/M1/M2) load the module b1pcmcia.o | ||
67 | before you insert the card. | ||
68 | |||
69 | Leased Lines with B1 | ||
70 | -------------------- | ||
71 | Init card and load firmware. | ||
72 | For an D64S use "FV: 1" as phone number | ||
73 | For an D64S2 use "FV: 1" and "FV: 2" for multilink | ||
74 | or "FV: 1,2" to use CAPI channel bundling. | ||
75 | |||
76 | /proc-Interface | ||
77 | ----------------- | ||
78 | |||
79 | /proc/capi: | ||
80 | dr-xr-xr-x 2 root root 0 Jul 1 14:03 . | ||
81 | dr-xr-xr-x 82 root root 0 Jun 30 19:08 .. | ||
82 | -r--r--r-- 1 root root 0 Jul 1 14:03 applications | ||
83 | -r--r--r-- 1 root root 0 Jul 1 14:03 applstats | ||
84 | -r--r--r-- 1 root root 0 Jul 1 14:03 capi20 | ||
85 | -r--r--r-- 1 root root 0 Jul 1 14:03 capidrv | ||
86 | -r--r--r-- 1 root root 0 Jul 1 14:03 controller | ||
87 | -r--r--r-- 1 root root 0 Jul 1 14:03 contrstats | ||
88 | -r--r--r-- 1 root root 0 Jul 1 14:03 driver | ||
89 | -r--r--r-- 1 root root 0 Jul 1 14:03 ncci | ||
90 | -r--r--r-- 1 root root 0 Jul 1 14:03 users | ||
91 | |||
92 | /proc/capi/applications: | ||
93 | applid level3cnt datablkcnt datablklen ncci-cnt recvqueuelen | ||
94 | level3cnt: capi_register parameter | ||
95 | datablkcnt: capi_register parameter | ||
96 | ncci-cnt: current number of nccis (connections) | ||
97 | recvqueuelen: number of messages on receive queue | ||
98 | for example: | ||
99 | 1 -2 16 2048 1 0 | ||
100 | 2 2 7 2048 1 0 | ||
101 | |||
102 | /proc/capi/applstats: | ||
103 | applid recvctlmsg nrecvdatamsg nsentctlmsg nsentdatamsg | ||
104 | recvctlmsg: capi messages received without DATA_B3_IND | ||
105 | recvdatamsg: capi DATA_B3_IND received | ||
106 | sentctlmsg: capi messages sent without DATA_B3_REQ | ||
107 | sentdatamsg: capi DATA_B3_REQ sent | ||
108 | for example: | ||
109 | 1 2057 1699 1721 1699 | ||
110 | |||
111 | /proc/capi/capi20: statistics of capi.o (/dev/capi20) | ||
112 | minor nopen nrecvdropmsg nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg | ||
113 | minor: minor device number of capi device | ||
114 | nopen: number of calls to devices open | ||
115 | nrecvdropmsg: capi messages dropped (messages in recvqueue in close) | ||
116 | nrecvctlmsg: capi messages received without DATA_B3_IND | ||
117 | nrecvdatamsg: capi DATA_B3_IND received | ||
118 | nsentctlmsg: capi messages sent without DATA_B3_REQ | ||
119 | nsentdatamsg: capi DATA_B3_REQ sent | ||
120 | |||
121 | for example: | ||
122 | 1 2 18 0 16 2 | ||
123 | |||
124 | /proc/capi/capidrv: statistics of capidrv.o (capi messages) | ||
125 | nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg | ||
126 | nrecvctlmsg: capi messages received without DATA_B3_IND | ||
127 | nrecvdatamsg: capi DATA_B3_IND received | ||
128 | nsentctlmsg: capi messages sent without DATA_B3_REQ | ||
129 | nsentdatamsg: capi DATA_B3_REQ sent | ||
130 | for example: | ||
131 | 2780 2226 2256 2226 | ||
132 | |||
133 | /proc/capi/controller: | ||
134 | controller drivername state cardname controllerinfo | ||
135 | for example: | ||
136 | 1 b1pci running b1pci-e000 B1 3.07-01 0xe000 19 | ||
137 | 2 t1isa running t1isa-450 B1 3.07-01 0x450 11 0 | ||
138 | 3 b1pcmcia running m2-150 B1 3.07-01 0x150 5 | ||
139 | |||
140 | /proc/capi/contrstats: | ||
141 | controller nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg | ||
142 | nrecvctlmsg: capi messages received without DATA_B3_IND | ||
143 | nrecvdatamsg: capi DATA_B3_IND received | ||
144 | nsentctlmsg: capi messages sent without DATA_B3_REQ | ||
145 | nsentdatamsg: capi DATA_B3_REQ sent | ||
146 | for example: | ||
147 | 1 2845 2272 2310 2274 | ||
148 | 2 2 0 2 0 | ||
149 | 3 2 0 2 0 | ||
150 | |||
151 | /proc/capi/driver: | ||
152 | drivername ncontroller | ||
153 | for example: | ||
154 | b1pci 1 | ||
155 | t1isa 1 | ||
156 | b1pcmcia 1 | ||
157 | b1isa 0 | ||
158 | |||
159 | /proc/capi/ncci: | ||
160 | apllid ncci winsize sendwindow | ||
161 | for example: | ||
162 | 1 0x10101 8 0 | ||
163 | |||
164 | /proc/capi/users: kernelmodules that use the kernelcapi. | ||
165 | name | ||
166 | for example: | ||
167 | capidrv | ||
168 | capi20 | ||
169 | |||
170 | Questions | ||
171 | --------- | ||
172 | Check out the FAQ (ftp.isdn4linux.de) or subscribe to the | ||
173 | linux-avmb1@calle.in-berlin.de mailing list by sending | ||
174 | a mail to majordomo@calle.in-berlin.de with | ||
175 | subscribe linux-avmb1 | ||
176 | in the body. | ||
177 | |||
178 | German documentation and several scripts can be found at | ||
179 | ftp://ftp.avm.de/cardware/b1/linux/ | ||
180 | |||
181 | Bugs | ||
182 | ---- | ||
183 | If you find any please let me know. | ||
184 | |||
185 | Enjoy, | ||
186 | |||
187 | Carsten Paeth (calle@calle.in-berlin.de) | ||
diff --git a/Documentation/isdn/README.concap b/Documentation/isdn/README.concap new file mode 100644 index 000000000000..2f114babe4b6 --- /dev/null +++ b/Documentation/isdn/README.concap | |||
@@ -0,0 +1,259 @@ | |||
1 | Description of the "concap" encapsulation protocol interface | ||
2 | ============================================================ | ||
3 | |||
4 | The "concap" interface is intended to be used by network device | ||
5 | drivers that need to process an encapsulation protocol. | ||
6 | It is assumed that the protocol interacts with a linux network device by | ||
7 | - data transmission | ||
8 | - connection control (establish, release) | ||
9 | Thus, the mnemonic: "CONnection CONtrolling eNCAPsulation Protocol". | ||
10 | |||
11 | This is currently only used inside the isdn subsystem. But it might | ||
12 | also be useful to other kinds of network devices. Thus, if you want | ||
13 | to suggest changes that improve usability or performance of the | ||
14 | interface, please let me know. I'm willing to include them in future | ||
15 | releases (even if I needed to adapt the current isdn code to the | ||
16 | changed interface). | ||
17 | |||
18 | |||
19 | Why is this useful? | ||
20 | =================== | ||
21 | |||
22 | The encapsulation protocol used on top of WAN connections or permanent | ||
23 | point-to-point links are frequently chosen upon bilateral agreement. | ||
24 | Thus, a device driver for a certain type of hardware must support | ||
25 | several different encapsulation protocols at once. | ||
26 | |||
27 | The isdn device driver did already support several different | ||
28 | encapsulation protocols. The encapsulation protocol is configured by a | ||
29 | user space utility (isdnctrl). The isdn network interface code then | ||
30 | uses several case statements which select appropriate actions | ||
31 | depending on the currently configured encapsulation protocol. | ||
32 | |||
33 | In contrast, LAN network interfaces always used a single encapsulation | ||
34 | protocol which is unique to the hardware type of the interface. The LAN | ||
35 | encapsulation is usually done by just sticking a header on the data. Thus, | ||
36 | traditional linux network device drivers used to process the | ||
37 | encapsulation protocol directly (usually by just providing a hard_header() | ||
38 | method in the device structure) using some hardware type specific support | ||
39 | functions. This is simple, direct and efficient. But it doesn't fit all | ||
40 | the requirements for complex WAN encapsulations. | ||
41 | |||
42 | |||
43 | The configurability of the encapsulation protocol to be used | ||
44 | makes isdn network interfaces more flexible, but also much more | ||
45 | complex than traditional lan network interfaces. | ||
46 | |||
47 | |||
48 | Many Encapsulation protocols used on top of WAN connections will not just | ||
49 | stick a header on the data. They also might need to set up or release | ||
50 | the WAN connection. They also might want to send other data for their | ||
51 | private purpose over the wire, e.g. ppp does a lot of link level | ||
52 | negotiation before the first piece of user data can be transmitted. | ||
53 | Such encapsulation protocols for WAN devices are typically more complex | ||
54 | than encapsulation protocols for lan devices. Thus, network interface | ||
55 | code for typical WAN devices also tends to be more complex. | ||
56 | |||
57 | |||
58 | In order to support Linux' x25 PLP implementation on top of | ||
59 | isdn network interfaces I could have introduced yet another branch to | ||
60 | the various case statements inside drivers/isdn/isdn_net.c. | ||
61 | This eventually made isdn_net.c even more complex. In addition, it made | ||
62 | isdn_net.c harder to maintain. Thus, by identifying an abstract | ||
63 | interface between the network interface code and the encapsulation | ||
64 | protocol, complexity could be reduced and maintainability could be | ||
65 | increased. | ||
66 | |||
67 | |||
68 | Likewise, a similar encapsulation protocol will frequently be needed by | ||
69 | several different interfaces of even different hardware type, e.g. the | ||
70 | synchronous ppp implementation used by the isdn driver and the | ||
71 | asynchronous ppp implementation used by the ppp driver have a lot of | ||
72 | similar code in them. By cleanly separating the encapsulation protocol | ||
73 | from the hardware specific interface stuff such code could be shared | ||
74 | better in future. | ||
75 | |||
76 | |||
77 | When operating over dial-up-connections (e.g. telephone lines via modem, | ||
78 | non-permanent virtual circuits of wide area networks, ISDN) many | ||
79 | encapsulation protocols will need to control the connection. Therefore, | ||
80 | some basic connection control primitives are supported. The type and | ||
81 | semantics of the connection (i.e the ISO layer where connection service | ||
82 | is provided) is outside our scope and might be different depending on | ||
83 | the encapsulation protocol used, e.g. for a ppp module using our service | ||
84 | on top of a modem connection a connect_request will result in dialing | ||
85 | a (somewhere else configured) remote phone number. For an X25-interface | ||
86 | module (LAPB semantics, as defined in Documentation/networking/x25-iface.txt) | ||
87 | a connect_request will ask for establishing a reliable lapb | ||
88 | datalink connection. | ||
89 | |||
90 | |||
91 | The encapsulation protocol currently provides the following | ||
92 | service primitives to the network device. | ||
93 | |||
94 | - create a new encapsulation protocol instance | ||
95 | - delete encapsulation protocol instance and free all its resources | ||
96 | - initialize (open) the encapsulation protocol instance for use. | ||
97 | - deactivate (close) an encapsulation protocol instance. | ||
98 | - process (xmit) data handed down by upper protocol layer | ||
99 | - receive data from lower (hardware) layer | ||
100 | - process connect indication from lower (hardware) layer | ||
101 | - process disconnect indication from lower (hardware) layer | ||
102 | |||
103 | |||
104 | The network interface driver accesses those primitives via callbacks | ||
105 | provided by the encapsulation protocol instance within a | ||
106 | struct concap_proto_ops. | ||
107 | |||
108 | struct concap_proto_ops{ | ||
109 | |||
110 | /* create a new encapsulation protocol instance of same type */ | ||
111 | struct concap_proto * (*proto_new) (void); | ||
112 | |||
113 | /* delete encapsulation protocol instance and free all its resources. | ||
114 | cprot may no loger be referenced after calling this */ | ||
115 | void (*proto_del)(struct concap_proto *cprot); | ||
116 | |||
117 | /* initialize the protocol's data. To be called at interface startup | ||
118 | or when the device driver resets the interface. All services of the | ||
119 | encapsulation protocol may be used after this*/ | ||
120 | int (*restart)(struct concap_proto *cprot, | ||
121 | struct net_device *ndev, | ||
122 | struct concap_device_ops *dops); | ||
123 | |||
124 | /* deactivate an encapsulation protocol instance. The encapsulation | ||
125 | protocol may not call any *dops methods after this. */ | ||
126 | int (*close)(struct concap_proto *cprot); | ||
127 | |||
128 | /* process a frame handed down to us by upper layer */ | ||
129 | int (*encap_and_xmit)(struct concap_proto *cprot, struct sk_buff *skb); | ||
130 | |||
131 | /* to be called for each data entity received from lower layer*/ | ||
132 | int (*data_ind)(struct concap_proto *cprot, struct sk_buff *skb); | ||
133 | |||
134 | /* to be called when a connection was set up/down. | ||
135 | Protocols that don't process these primitives might fill in | ||
136 | dummy methods here */ | ||
137 | int (*connect_ind)(struct concap_proto *cprot); | ||
138 | int (*disconn_ind)(struct concap_proto *cprot); | ||
139 | }; | ||
140 | |||
141 | |||
142 | The data structures are defined in the header file include/linux/concap.h. | ||
143 | |||
144 | |||
145 | A Network interface using encapsulation protocols must also provide | ||
146 | some service primitives to the encapsulation protocol: | ||
147 | |||
148 | - request data being submitted by lower layer (device hardware) | ||
149 | - request a connection being set up by lower layer | ||
150 | - request a connection being released by lower layer | ||
151 | |||
152 | The encapsulation protocol accesses those primitives via callbacks | ||
153 | provided by the network interface within a struct concap_device_ops. | ||
154 | |||
155 | struct concap_device_ops{ | ||
156 | |||
157 | /* to request data be submitted by device */ | ||
158 | int (*data_req)(struct concap_proto *, struct sk_buff *); | ||
159 | |||
160 | /* Control methods must be set to NULL by devices which do not | ||
161 | support connection control. */ | ||
162 | /* to request a connection be set up */ | ||
163 | int (*connect_req)(struct concap_proto *); | ||
164 | |||
165 | /* to request a connection be released */ | ||
166 | int (*disconn_req)(struct concap_proto *); | ||
167 | }; | ||
168 | |||
169 | The network interface does not explicitly provide a receive service | ||
170 | because the encapsulation protocol directly calls netif_rx(). | ||
171 | |||
172 | |||
173 | |||
174 | |||
175 | An encapsulation protocol itself is actually the | ||
176 | struct concap_proto{ | ||
177 | struct net_device *net_dev; /* net device using our service */ | ||
178 | struct concap_device_ops *dops; /* callbacks provided by device */ | ||
179 | struct concap_proto_ops *pops; /* callbacks provided by us */ | ||
180 | int flags; | ||
181 | void *proto_data; /* protocol specific private data, to | ||
182 | be accessed via *pops methods only*/ | ||
183 | /* | ||
184 | : | ||
185 | whatever | ||
186 | : | ||
187 | */ | ||
188 | }; | ||
189 | |||
190 | Most of this is filled in when the device requests the protocol to | ||
191 | be reset (opend). The network interface must provide the net_dev and | ||
192 | dops pointers. Other concap_proto members should be considered private | ||
193 | data that are only accessed by the pops callback functions. Likewise, | ||
194 | a concap proto should access the network device's private data | ||
195 | only by means of the callbacks referred to by the dops pointer. | ||
196 | |||
197 | |||
198 | A possible extended device structure which uses the connection controlling | ||
199 | encapsulation services could look like this: | ||
200 | |||
201 | struct concap_device{ | ||
202 | struct net_device net_dev; | ||
203 | struct my_priv /* device->local stuff */ | ||
204 | /* the my_priv struct might contain a | ||
205 | struct concap_device_ops *dops; | ||
206 | to provide the device specific callbacks | ||
207 | */ | ||
208 | struct concap_proto *cprot; /* callbacks provided by protocol */ | ||
209 | }; | ||
210 | |||
211 | |||
212 | |||
213 | Misc Thoughts | ||
214 | ============= | ||
215 | |||
216 | The concept of the concap proto might help to reuse protocol code and | ||
217 | reduce the complexity of certain network interface implementations. | ||
218 | The trade off is that it introduces yet another procedure call layer | ||
219 | when processing the protocol. This has of course some impact on | ||
220 | performance. However, typically the concap interface will be used by | ||
221 | devices attached to slow lines (like telephone, isdn, leased synchronous | ||
222 | lines). For such slow lines, the overhead is probably negligible. | ||
223 | This might no longer hold for certain high speed WAN links (like | ||
224 | ATM). | ||
225 | |||
226 | |||
227 | If general linux network interfaces explicitly supported concap | ||
228 | protocols (e.g. by a member struct concap_proto* in struct net_device) | ||
229 | then the interface of the service function could be changed | ||
230 | by passing a pointer of type (struct net_device*) instead of | ||
231 | type (struct concap_proto*). Doing so would make many of the service | ||
232 | functions compatible to network device support functions. | ||
233 | |||
234 | e.g. instead of the concap protocol's service function | ||
235 | |||
236 | int (*encap_and_xmit)(struct concap_proto *cprot, struct sk_buff *skb); | ||
237 | |||
238 | we could have | ||
239 | |||
240 | int (*encap_and_xmit)(struct net_device *ndev, struct sk_buff *skb); | ||
241 | |||
242 | As this is compatible to the dev->hard_start_xmit() method, the device | ||
243 | driver could directly register the concap protocol's encap_and_xmit() | ||
244 | function as its hard_start_xmit() method. This would eliminate one | ||
245 | procedure call layer. | ||
246 | |||
247 | |||
248 | The device's data request function could also be defined as | ||
249 | |||
250 | int (*data_req)(struct net_device *ndev, struct sk_buff *skb); | ||
251 | |||
252 | This might even allow for some protocol stacking. And the network | ||
253 | interface might even register the same data_req() function directly | ||
254 | as its hard_start_xmit() method when a zero layer encapsulation | ||
255 | protocol is configured. Thus, eliminating the performance penalty | ||
256 | of the concap interface when a trivial concap protocol is used. | ||
257 | Nevertheless, the device remains able to support encapsulation | ||
258 | protocol configuration. | ||
259 | |||
diff --git a/Documentation/isdn/README.diversion b/Documentation/isdn/README.diversion new file mode 100644 index 000000000000..bddcd5fb86ff --- /dev/null +++ b/Documentation/isdn/README.diversion | |||
@@ -0,0 +1,127 @@ | |||
1 | The isdn diversion services are a supporting module working together with | ||
2 | the isdn4linux and the HiSax module for passive cards. | ||
3 | Active cards, TAs and cards using a own or other driver than the HiSax | ||
4 | module need to be adapted to the HL<->LL interface described in a separate | ||
5 | document. The diversion services may be used with all cards supported by | ||
6 | the HiSax driver. | ||
7 | The diversion kernel interface and controlling tool divertctrl were written | ||
8 | by Werner Cornelius (werner@isdn4linux.de or werner@titro.de) under the | ||
9 | GNU General Public License. | ||
10 | |||
11 | This program is free software; you can redistribute it and/or modify | ||
12 | it under the terms of the GNU General Public License as published by | ||
13 | the Free Software Foundation; either version 2 of the License, or | ||
14 | (at your option) any later version. | ||
15 | |||
16 | This program is distributed in the hope that it will be useful, | ||
17 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
18 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
19 | GNU General Public License for more details. | ||
20 | |||
21 | You should have received a copy of the GNU General Public License | ||
22 | along with this program; if not, write to the Free Software | ||
23 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
24 | |||
25 | Table of contents | ||
26 | ================= | ||
27 | |||
28 | 1. Features of the i4l diversion services | ||
29 | (Or what can the i4l diversion services do for me) | ||
30 | |||
31 | 2. Required hard- and software | ||
32 | |||
33 | 3. Compiling, installing and loading/unloading the module | ||
34 | Tracing calling and diversion information | ||
35 | |||
36 | 4. Tracing calling and diversion information | ||
37 | |||
38 | 5. Format of the divert device ASCII output | ||
39 | |||
40 | |||
41 | 1. Features of the i4l diversion services | ||
42 | (Or what can the i4l diversion services do for me) | ||
43 | |||
44 | The i4l diversion services offers call forwarding and logging normally | ||
45 | only supported by isdn phones. Incoming calls may be diverted | ||
46 | unconditionally (CFU), when not reachable (CFNR) or on busy condition | ||
47 | (CFB). | ||
48 | The diversions may be invoked statically in the providers exchange | ||
49 | as normally done by isdn phones. In this case all incoming calls | ||
50 | with a special (or all) service identifiers are forwarded if the | ||
51 | forwarding reason is met. Activated static services may also be | ||
52 | interrogated (queried). | ||
53 | The i4l diversion services additionally offers a dynamic version of | ||
54 | call forwarding which is not preprogrammed inside the providers exchange | ||
55 | but dynamically activated by i4l. | ||
56 | In this case all incoming calls are checked by rules that may be | ||
57 | compared to the mechanism of ipfwadm or ipchains. If a given rule matches | ||
58 | the checking process is finished and the rule matching will be applied | ||
59 | to the call. | ||
60 | The rules include primary and secondary service identifiers, called | ||
61 | number and subaddress, callers number and subaddress and whether the rule | ||
62 | matches to all filtered calls or only those when all B-channel resources | ||
63 | are exhausted. | ||
64 | Actions that may be invoked by a rule are ignore, proceed, reject, | ||
65 | direct divert or delayed divert of a call. | ||
66 | All incoming calls matching a rule except the ignore rule a reported and | ||
67 | logged as ASCII via the proc filesystem (/proc/net/isdn/divert). If proceed | ||
68 | is selected the call will be held in a proceeding state (without ringing) | ||
69 | for a certain amount of time to let an external program or client decide | ||
70 | how to handle the call. | ||
71 | |||
72 | |||
73 | 2. Required hard- and software | ||
74 | |||
75 | For using the i4l diversion services the isdn line must be of a EURO/DSS1 | ||
76 | type. Additionally the i4l services only work together with the HiSax | ||
77 | driver for passive isdn cards. All HiSax supported cards may be used for | ||
78 | the diversion purposes. | ||
79 | The static diversion services require the provider having static services | ||
80 | CFU, CFNR, CFB activated on an MSN-line. The static services may not be | ||
81 | used on a point-to-point connection. Further the static services are only | ||
82 | available in some countries (for example germany). Countries requiring the | ||
83 | keypad protocol for activating static diversions (like the netherlands) are | ||
84 | not supported but may use the tty devices for this purpose. | ||
85 | The dynamic diversion services may be used in all countries if the provider | ||
86 | enables the feature CF (call forwarding). This should work on both MSN- and | ||
87 | point-to-point lines. | ||
88 | To add and delete rules the additional divertctrl program is needed. This | ||
89 | program is part of the isdn4kutils package. | ||
90 | |||
91 | 3. Compiling, installing and loading/unloading the module | ||
92 | Tracing calling and diversion information | ||
93 | |||
94 | |||
95 | To compile the i4l code with diversion support you need to say yes to the | ||
96 | DSS1 diversion services when selecting the i4l options in the kernel | ||
97 | config (menuconfig or config). | ||
98 | After having properly activated a make modules and make modules_install all | ||
99 | required modules will be correctly installed in the needed modules dirs. | ||
100 | As the diversion services are currently not included in the scripts of most | ||
101 | standard distributions you will have to add a "insmod dss1_divert" after | ||
102 | having loaded the global isdn module. | ||
103 | The module can be loaded without any command line parameters. | ||
104 | If the module is actually loaded and active may be checked with a | ||
105 | "cat /proc/modules" or "ls /proc/net/isdn/divert". The divert file is | ||
106 | dynamically created by the diversion module and removed when the module is | ||
107 | unloaded. | ||
108 | |||
109 | |||
110 | 4. Tracing calling and diversion information | ||
111 | |||
112 | You also may put a "cat /proc/net/isdn/divert" in the background with the | ||
113 | output redirected to a file. Then all actions of the module are logged. | ||
114 | The divert file in the proc system may be opened more than once, so in | ||
115 | conjunction with inetd and a small remote client on other machines inside | ||
116 | your network incoming calls and reactions by the module may be shown on | ||
117 | every listening machine. | ||
118 | If a call is reported as proceeding an external program or client may | ||
119 | specify during a certain amount of time (normally 4 to 10 seconds) what | ||
120 | to do with that call. | ||
121 | To unload the module all open files to the device in the proc system must | ||
122 | be closed. Otherwise the module (and isdn.o) may not be unloaded. | ||
123 | |||
124 | 5. Format of the divert device ASCII output | ||
125 | |||
126 | To be done later | ||
127 | |||
diff --git a/Documentation/isdn/README.fax b/Documentation/isdn/README.fax new file mode 100644 index 000000000000..5314958a8a6e --- /dev/null +++ b/Documentation/isdn/README.fax | |||
@@ -0,0 +1,45 @@ | |||
1 | |||
2 | Fax with isdn4linux | ||
3 | =================== | ||
4 | |||
5 | When enabled during kernel configuration, the tty emulator | ||
6 | of the ISDN subsystem is capable of the Fax Class 2 commands. | ||
7 | |||
8 | This only makes sense under the following conditions : | ||
9 | |||
10 | - You need the commands as dummy, because you are using | ||
11 | hylafax (with patch) for AVM capi. | ||
12 | - You want to use the fax capabilities of your isdn-card. | ||
13 | (supported cards are listed below) | ||
14 | |||
15 | |||
16 | NOTE: This implementation does *not* support fax with passive | ||
17 | ISDN-cards (known as softfax). The low-level driver of | ||
18 | the ISDN-card and/or the card itself must support this. | ||
19 | |||
20 | |||
21 | Supported ISDN-Cards | ||
22 | -------------------- | ||
23 | |||
24 | Eicon DIVA Server BRI/PCI | ||
25 | - full support with both B-channels. | ||
26 | |||
27 | Eicon DIVA Server 4BRI/PCI | ||
28 | - full support with all B-channels. | ||
29 | |||
30 | Eicon DIVA Server PRI/PCI | ||
31 | - full support on amount of B-channels | ||
32 | depending on DSPs on board. | ||
33 | |||
34 | |||
35 | |||
36 | The command set is known as Class 2 (not Class 2.0) and | ||
37 | can be activated by AT+FCLASS=2 | ||
38 | |||
39 | |||
40 | The interface between the link-level-module and the hardware-level driver | ||
41 | is described in the files INTERFACE.fax and INTERFACE. | ||
42 | |||
43 | Armin | ||
44 | mac@melware.de | ||
45 | |||
diff --git a/Documentation/isdn/README.hfc-pci b/Documentation/isdn/README.hfc-pci new file mode 100644 index 000000000000..e8a4ef0226e8 --- /dev/null +++ b/Documentation/isdn/README.hfc-pci | |||
@@ -0,0 +1,41 @@ | |||
1 | The driver for the HFC-PCI and HFC-PCI-A chips from CCD may be used | ||
2 | for many OEM cards using this chips. | ||
3 | Additionally the driver has a special feature which makes it possible | ||
4 | to read the echo-channel of the isdn bus. So all frames in both directions | ||
5 | may be logged. | ||
6 | When the echo logging feature is used the number of available B-channels | ||
7 | for a HFC-PCI card is reduced to 1. Of course this is only relevant to | ||
8 | the card, not to the isdn line. | ||
9 | To activate the echo mode the following ioctls must be entered: | ||
10 | |||
11 | hisaxctrl <driver/cardname> 10 1 | ||
12 | |||
13 | This reduces the available channels to 1. There must not be open connections | ||
14 | through this card when entering the command. | ||
15 | And then: | ||
16 | |||
17 | hisaxctrl <driver/cardname> 12 1 | ||
18 | |||
19 | This enables the echo mode. If Hex logging is activated the isdnctrlx | ||
20 | devices show a output with a line beginning of HEX: for the providers | ||
21 | exchange and ECHO: for isdn devices sending to the provider. | ||
22 | |||
23 | If more than one HFC-PCI cards are installed, a specific card may be selected | ||
24 | at the hisax module load command line. Supply the load command with the desired | ||
25 | IO-address of the desired card. | ||
26 | Example: | ||
27 | There tree cards installed in your machine at IO-base addresses 0xd000, 0xd400 | ||
28 | and 0xdc00 | ||
29 | If you want to use the card at 0xd400 standalone you should supply the insmod | ||
30 | or depmod with type=35 io=0xd400. | ||
31 | If you want to use all three cards, but the order needs to be at 0xdc00,0xd400, | ||
32 | 0xd000 you may give the parameters type=35,35,35 io=0xdc00,0xd400,0xd00 | ||
33 | Then the desired card will be the initialised in the desired order. | ||
34 | If the io parameter is used the io addresses of all used cards should be | ||
35 | supplied else the parameter is assumed 0 and a auto search for a free card is | ||
36 | invoked which may not give the wanted result. | ||
37 | |||
38 | Comments and reports to werner@isdn4linux.de or werner@isdn-development.de | ||
39 | |||
40 | |||
41 | |||
diff --git a/Documentation/isdn/README.hysdn b/Documentation/isdn/README.hysdn new file mode 100644 index 000000000000..56cc59df1fb7 --- /dev/null +++ b/Documentation/isdn/README.hysdn | |||
@@ -0,0 +1,195 @@ | |||
1 | $Id: README.hysdn,v 1.3.6.1 2001/02/10 14:41:19 kai Exp $ | ||
2 | The hysdn driver has been written by | ||
3 | by Werner Cornelius (werner@isdn4linux.de or werner@titro.de) | ||
4 | for Hypercope GmbH Aachen Germany. Hypercope agreed to publish this driver | ||
5 | under the GNU General Public License. | ||
6 | |||
7 | The CAPI 2.0-support was added by Ulrich Albrecht (ualbrecht@hypercope.de) | ||
8 | for Hypercope GmbH Aachen, Germany. | ||
9 | |||
10 | |||
11 | This program is free software; you can redistribute it and/or modify | ||
12 | it under the terms of the GNU General Public License as published by | ||
13 | the Free Software Foundation; either version 2 of the License, or | ||
14 | (at your option) any later version. | ||
15 | |||
16 | This program is distributed in the hope that it will be useful, | ||
17 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
18 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
19 | GNU General Public License for more details. | ||
20 | |||
21 | You should have received a copy of the GNU General Public License | ||
22 | along with this program; if not, write to the Free Software | ||
23 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
24 | |||
25 | Table of contents | ||
26 | ================= | ||
27 | |||
28 | 1. About the driver | ||
29 | |||
30 | 2. Loading/Unloading the driver | ||
31 | |||
32 | 3. Entries in the /proc filesystem | ||
33 | |||
34 | 4. The /proc/net/hysdn/cardconfX file | ||
35 | |||
36 | 5. The /proc/net/hysdn/cardlogX file | ||
37 | |||
38 | 6. Where to get additional info and help | ||
39 | |||
40 | |||
41 | 1. About the driver | ||
42 | |||
43 | The drivers/isdn/hysdn subdir contains a driver for HYPERCOPEs active | ||
44 | PCI isdn cards Champ, Ergo and Metro. To enable support for this cards | ||
45 | enable ISDN support in the kernel config and support for HYSDN cards in | ||
46 | the active cards submenu. The driver may only be compiled and used if | ||
47 | support for loadable modules and the process filesystem have been enabled. | ||
48 | |||
49 | These cards provide two different interfaces to the kernel. Without the | ||
50 | optional CAPI 2.0 support, they register as ethernet card. IP-routing | ||
51 | to a ISDN-destination is performed on the card itself. All necessary | ||
52 | handlers for various protocols like ppp and others as well as config info | ||
53 | and firmware may be fetched from Hypercopes WWW-Site www.hypercope.de. | ||
54 | |||
55 | With CAPI 2.0 support enabled, the card can also be used as a CAPI 2.0 | ||
56 | compliant devices with either CAPI 2.0 applications | ||
57 | (check isdn4k-utils) or -using the capidrv module- as a regular | ||
58 | isdn4linux device. This is done via the same mechanism as with the | ||
59 | active AVM cards and in fact uses the same module. | ||
60 | |||
61 | |||
62 | 2. Loading/Unloading the driver | ||
63 | |||
64 | The module has no command line parameters and auto detects up to 10 cards | ||
65 | in the id-range 0-9. | ||
66 | If a loaded driver shall be unloaded all open files in the /proc/net/hysdn | ||
67 | subdir need to be closed and all ethernet interfaces allocated by this | ||
68 | driver must be shut down. Otherwise the module counter will avoid a module | ||
69 | unload. | ||
70 | |||
71 | If you are using the CAPI 2.0-interface, make sure to load/modprobe the | ||
72 | kernelcapi-module first. | ||
73 | |||
74 | If you plan to use the capidrv-link to isdn4linux, make sure to load | ||
75 | capidrv.o after all modules using this driver (i.e. after hysdn and | ||
76 | any avm-specific modules). | ||
77 | |||
78 | 3. Entries in the /proc filesystem | ||
79 | |||
80 | When the module has been loaded it adds the directory hysdn in the | ||
81 | /proc/net tree. This directory contains exactly 2 file entries for each | ||
82 | card. One is called cardconfX and the other cardlogX, where X is the | ||
83 | card id number from 0 to 9. | ||
84 | The cards are numbered in the order found in the PCI config data. | ||
85 | |||
86 | 4. The /proc/net/hysdn/cardconfX file | ||
87 | |||
88 | This file may be read to get by everyone to get info about the cards type, | ||
89 | actual state, available features and used resources. | ||
90 | The first 3 entries (id, bus and slot) are PCI info fields, the following | ||
91 | type field gives the information about the cards type: | ||
92 | |||
93 | 4 -> Ergo card (server card with 2 b-chans) | ||
94 | 5 -> Metro card (server card with 4 or 8 b-chans) | ||
95 | 6 -> Champ card (client card with 2 b-chans) | ||
96 | |||
97 | The following 3 fields show the hardware assignments for irq, iobase and the | ||
98 | dual ported memory (dp-mem). | ||
99 | The fields b-chans and fax-chans announce the available card resources of | ||
100 | this types for the user. | ||
101 | The state variable indicates the actual drivers state for this card with the | ||
102 | following assignments. | ||
103 | |||
104 | 0 -> card has not been booted since driver load | ||
105 | 1 -> card booting is actually in progess | ||
106 | 2 -> card is in an error state due to a previous boot failure | ||
107 | 3 -> card is booted and active | ||
108 | |||
109 | And the last field (device) shows the name of the ethernet device assigned | ||
110 | to this card. Up to the first successful boot this field only shows a - | ||
111 | to tell that no net device has been allocated up to now. Once a net device | ||
112 | has been allocated it remains assigned to this card, even if a card is | ||
113 | rebooted and an boot error occurs. | ||
114 | |||
115 | Writing to the cardconfX file boots the card or transfers config lines to | ||
116 | the cards firmware. The type of data is automatically detected when the | ||
117 | first data is written. Only root has write access to this file. | ||
118 | The firmware boot files are normally called hyclient.pof for client cards | ||
119 | and hyserver.pof for server cards. | ||
120 | After successfully writing the boot file, complete config files or single | ||
121 | config lines may be copied to this file. | ||
122 | If an error occurs the return value given to the writing process has the | ||
123 | following additional codes (decimal): | ||
124 | |||
125 | 1000 Another process is currently bootng the card | ||
126 | 1001 Invalid firmware header | ||
127 | 1002 Boards dual-port RAM test failed | ||
128 | 1003 Internal firmware handler error | ||
129 | 1004 Boot image size invalid | ||
130 | 1005 First boot stage (bootstrap loader) failed | ||
131 | 1006 Second boot stage failure | ||
132 | 1007 Timeout waiting for card ready during boot | ||
133 | 1008 Operation only allowed in booted state | ||
134 | 1009 Config line too long | ||
135 | 1010 Invalid channel number | ||
136 | 1011 Timeout sending config data | ||
137 | |||
138 | Additional info about error reasons may be fetched from the log output. | ||
139 | |||
140 | 5. The /proc/net/hysdn/cardlogX file | ||
141 | |||
142 | The cardlogX file entry may be opened multiple for reading by everyone to | ||
143 | get the cards and drivers log data. Card messages always start with the | ||
144 | keyword LOG. All other lines are output from the driver. | ||
145 | The driver log data may be redirected to the syslog by selecting the | ||
146 | appropriate bitmask. The cards log messages will always be send to this | ||
147 | interface but never to the syslog. | ||
148 | |||
149 | A root user may write a decimal or hex (with 0x) value t this file to select | ||
150 | desired output options. As mentioned above the cards log dat is always | ||
151 | written to the cardlog file independent of the following options only used | ||
152 | to check and debug the driver itself: | ||
153 | |||
154 | For example: | ||
155 | echo "0x34560078" > /proc/net/hysdn/cardlog0 | ||
156 | to output the hex log mask 34560078 for card 0. | ||
157 | |||
158 | The written value is regarded as an unsigned 32-Bit value, bit ored for | ||
159 | desired output. The following bits are already assigned: | ||
160 | |||
161 | 0x80000000 All driver log data is alternatively via syslog | ||
162 | 0x00000001 Log memory allocation errors | ||
163 | 0x00000010 Firmware load start and close are logged | ||
164 | 0x00000020 Log firmware record parser | ||
165 | 0x00000040 Log every firmware write actions | ||
166 | 0x00000080 Log all card related boot messages | ||
167 | 0x00000100 Output all config data sent for debugging purposes | ||
168 | 0x00000200 Only non comment config lines are shown wth channel | ||
169 | 0x00000400 Additional conf log output | ||
170 | 0x00001000 Log the asynchronous scheduler actions (config and log) | ||
171 | 0x00100000 Log all open and close actions to /proc/net/hysdn/card files | ||
172 | 0x00200000 Log all actions from /proc file entries | ||
173 | 0x00010000 Log network interface init and deinit | ||
174 | |||
175 | 6. Where to get additional info and help | ||
176 | |||
177 | If you have any problems concerning the driver or configuration contact | ||
178 | the Hypercope support team (support@hypercope.de) and or the authors | ||
179 | Werner Cornelius (werner@isdn4linux or cornelius@titro.de) or | ||
180 | Ulrich Albrecht (ualbrecht@hypercope.de). | ||
181 | |||
182 | |||
183 | |||
184 | |||
185 | |||
186 | |||
187 | |||
188 | |||
189 | |||
190 | |||
191 | |||
192 | |||
193 | |||
194 | |||
195 | |||
diff --git a/Documentation/isdn/README.icn b/Documentation/isdn/README.icn new file mode 100644 index 000000000000..a5f55eadb3ca --- /dev/null +++ b/Documentation/isdn/README.icn | |||
@@ -0,0 +1,148 @@ | |||
1 | $Id: README.icn,v 1.7 2000/08/06 09:22:51 armin Exp $ | ||
2 | |||
3 | You can get the ICN-ISDN-card from: | ||
4 | |||
5 | Thinking Objects Software GmbH | ||
6 | Versbacher Röthe 159 | ||
7 | 97078 Würzburg | ||
8 | Tel: +49 931 2877950 | ||
9 | Fax: +49 931 2877951 | ||
10 | |||
11 | email info@think.de | ||
12 | WWW http:/www.think.de | ||
13 | |||
14 | |||
15 | The card communicates with the PC by two interfaces: | ||
16 | 1. A range of 4 successive port-addresses, whose base address can be | ||
17 | configured with the switches. | ||
18 | 2. A memory window with 16KB-256KB size, which can be setup in 16k steps | ||
19 | over the whole range of 16MB. Isdn4linux only uses a 16k window. | ||
20 | The base address of the window can be configured when loading | ||
21 | the lowlevel-module (see README). If using more than one card, | ||
22 | all cards are mapped to the same window and activated as needed. | ||
23 | |||
24 | Setting up the IO-address dipswitches for the ICN-ISDN-card: | ||
25 | |||
26 | Two types of cards exist, one with dip-switches and one with | ||
27 | hook-switches. | ||
28 | |||
29 | 1. Setting for the card with hook-switches: | ||
30 | |||
31 | (0 = switch closed, 1 = switch open) | ||
32 | |||
33 | S3 S2 S1 Base-address | ||
34 | 0 0 0 0x300 | ||
35 | 0 0 1 0x310 | ||
36 | 0 1 0 0x320 (Default for isdn4linux) | ||
37 | 0 1 1 0x330 | ||
38 | 1 0 0 0x340 | ||
39 | 1 0 1 0x350 | ||
40 | 1 1 0 0x360 | ||
41 | 1 1 1 NOT ALLOWED! | ||
42 | |||
43 | 2. Setting for the card with dip-switches: | ||
44 | |||
45 | (0 = switch closed, 1 = switch open) | ||
46 | |||
47 | S1 S2 S3 S4 Base-Address | ||
48 | 0 0 0 0 0x300 | ||
49 | 0 0 0 1 0x310 | ||
50 | 0 0 1 0 0x320 (Default for isdn4linux) | ||
51 | 0 0 1 1 0x330 | ||
52 | 0 1 0 0 0x340 | ||
53 | 0 1 0 1 0x350 | ||
54 | 0 1 1 0 0x360 | ||
55 | 0 1 1 1 NOT ALLOWED! | ||
56 | 1 0 0 0 0x308 | ||
57 | 1 0 0 1 0x318 | ||
58 | 1 0 1 0 0x328 | ||
59 | 1 0 1 1 0x338 | ||
60 | 1 1 0 0 0x348 | ||
61 | 1 1 0 1 0x358 | ||
62 | 1 1 1 0 0x368 | ||
63 | 1 1 1 1 NOT ALLOWED! | ||
64 | |||
65 | The ICN driver may be built into the kernel or as a module. Initialization | ||
66 | depends on how the driver is built: | ||
67 | |||
68 | Driver built into the kernel: | ||
69 | |||
70 | The ICN driver can be configured using the commandline-feature while | ||
71 | loading the kernel with LILO or LOADLIN. It accepts the following syntax: | ||
72 | |||
73 | icn=p,m[,idstring1[,idstring2]] | ||
74 | |||
75 | where | ||
76 | |||
77 | p = portbase (default: 0x320) | ||
78 | m = shared memory (default: 0xd0000) | ||
79 | |||
80 | When using the ICN double card (4B), you MUST define TWO idstrings. | ||
81 | idstring must start with a character! There is no way for the driver | ||
82 | to distinguish between a 2B and 4B type card. Therefore, by supplying | ||
83 | TWO idstrings, you tell the driver that you have a 4B installed. | ||
84 | |||
85 | If you like to use more than one card, you can use the program | ||
86 | "icnctrl" from the utility-package to configure additional cards. | ||
87 | You need to configure shared memory only once, since the icn-driver | ||
88 | maps all cards into the same address-space. | ||
89 | |||
90 | Using the "icnctrl"-utility, portbase and shared memory can also be | ||
91 | changed during runtime. | ||
92 | |||
93 | The D-channel protocol is configured by loading different firmware | ||
94 | into the card's memory using the "icnctrl"-utility. | ||
95 | |||
96 | |||
97 | Driver built as module: | ||
98 | |||
99 | The module icn.o can be configured during "insmod'ing" it by | ||
100 | appending its parameters to the insmod-commandline. The following | ||
101 | syntax is accepted: | ||
102 | |||
103 | portbase=p membase=m icn_id=idstring [icn_id2=idstring2] | ||
104 | |||
105 | where p, m, idstring1 and idstring2 have the same meanings as the | ||
106 | parameters described for the kernel-version above. | ||
107 | |||
108 | When using the ICN double card (4B), you MUST define TWO idstrings. | ||
109 | idstring must start with a character! There is no way for the driver | ||
110 | to distinguish between a 2B and 4B type card. Therefore, by supplying | ||
111 | TWO idstrings, you tell the driver that you have a 4B installed. | ||
112 | |||
113 | Using the "icnctrl"-utility, the same features apply to the modularized | ||
114 | version like to the kernel-builtin one. | ||
115 | |||
116 | The D-channel protocol is configured by loading different firmware | ||
117 | into the card's memory using the "icnctrl"-utility. | ||
118 | |||
119 | Loading the firmware into the card: | ||
120 | |||
121 | The firmware is supplied together with the isdn4k-utils package. It | ||
122 | can be found in the subdirectory icnctrl/firmware/ | ||
123 | |||
124 | There are 3 files: | ||
125 | |||
126 | loadpg.bin - Image of the bootstrap loader. | ||
127 | pc_1t_ca.bin - Image of firmware for german 1TR6 protocol. | ||
128 | pc_eu_ca.bin - Image if firmware for EDSS1 (Euro-ISDN) protocol. | ||
129 | |||
130 | Assuming you have installed the utility-package correctly, the firmware | ||
131 | will be downloaded into the 2B-card using the following command: | ||
132 | |||
133 | icnctrl -d Idstring load /etc/isdn/loadpg.bin /etc/isdn/pc_XX_ca.bin | ||
134 | |||
135 | where XX is either "1t" or "eu", depending on the D-Channel protocol | ||
136 | used on your S0-bus and Idstring is the Name of the card, given during | ||
137 | insmod-time or (for kernel-builtin driver) on the kernel commandline. | ||
138 | |||
139 | To load a 4B-card, the same command is used, except a second firmware | ||
140 | file is appended to the commandline of icnctrl. | ||
141 | |||
142 | -> After downloading firmware, the two LEDs at the back cover of the card | ||
143 | (ICN-4B: 4 LEDs) must be blinking intermittently now. If a connection | ||
144 | is up, the corresponding led is lit continuously. | ||
145 | |||
146 | For further documentation (adding more ICN-cards), refer to the manpage | ||
147 | icnctrl.8 which is included in the isdn4k-utils package. | ||
148 | |||
diff --git a/Documentation/isdn/README.pcbit b/Documentation/isdn/README.pcbit new file mode 100644 index 000000000000..5125002282e5 --- /dev/null +++ b/Documentation/isdn/README.pcbit | |||
@@ -0,0 +1,40 @@ | |||
1 | ------------------------------------------------------------------------------ | ||
2 | README file for the PCBIT-D Device Driver. | ||
3 | ------------------------------------------------------------------------------ | ||
4 | |||
5 | The PCBIT is a Euro ISDN adapter manufactured in Portugal by Octal and | ||
6 | developed in cooperation with Portugal Telecom and Inesc. | ||
7 | The driver interfaces with the standard kernel isdn facilities | ||
8 | originally developed by Fritz Elfert in the isdn4linux project. | ||
9 | |||
10 | The common versions of the pcbit board require a firmware that is | ||
11 | distributed (and copyrighted) by the manufacturer. To load this | ||
12 | firmware you need "pcbitctl" available on the standard isdn4k-utils | ||
13 | package or in the pcbit package available in: | ||
14 | |||
15 | ftp://ftp.di.fc.ul.pt/pub/systems/Linux/isdn | ||
16 | |||
17 | Known Limitations: | ||
18 | |||
19 | - The board reset procedure is at the moment incorrect and will only | ||
20 | allow you to load the firmware after a hard reset. | ||
21 | |||
22 | - Only HDLC in B-channels is supported at the moment. There is no | ||
23 | current support for X.25 in B or D channels nor LAPD in B | ||
24 | channels. The main reason is that these two other protocol modes have, | ||
25 | to my knowledge, very little use. If you want to see them implemented | ||
26 | *do* send me a mail. | ||
27 | |||
28 | - The driver often triggers errors in the board that I and the | ||
29 | manufacturer believe to be caused by bugs in the firmware. The current | ||
30 | version includes several procedures for error recovery that should | ||
31 | allow normal operation. Plans for the future include cooperation with | ||
32 | the manufacturer in order to solve this problem. | ||
33 | |||
34 | Information/hints/help can be obtained in the linux isdn | ||
35 | mailing list (isdn4linux@listserv.isdn4linux.de) or directly from me. | ||
36 | |||
37 | regards, | ||
38 | Pedro. | ||
39 | |||
40 | <roque@di.fc.ul.pt> | ||
diff --git a/Documentation/isdn/README.sc b/Documentation/isdn/README.sc new file mode 100644 index 000000000000..1153cd926059 --- /dev/null +++ b/Documentation/isdn/README.sc | |||
@@ -0,0 +1,281 @@ | |||
1 | Welcome to Beta Release 2 of the combination ISDN driver for SpellCaster's | ||
2 | ISA ISDN adapters. Please note this release 2 includes support for the | ||
3 | DataCommute/BRI and TeleCommute/BRI adapters only and any other use is | ||
4 | guaranteed to fail. If you have a DataCommute/PRI installed in the test | ||
5 | computer, we recommend removing it as it will be detected but will not | ||
6 | be usable. To see what we have done to Beta Release 2, see section 3. | ||
7 | |||
8 | Speaking of guarantees, THIS IS BETA SOFTWARE and as such contains | ||
9 | bugs and defects either known or unknown. Use this software at your own | ||
10 | risk. There is NO SUPPORT for this software. Some help may be available | ||
11 | through the web site or the mailing list but such support is totally at | ||
12 | our own option and without warranty. If you choose to assume all and | ||
13 | total risk by using this driver, we encourage you to join the beta | ||
14 | mailing list. | ||
15 | |||
16 | To join the Linux beta mailing list, send a message to: | ||
17 | majordomo@spellcast.com with the words "subscribe linux-beta" as the only | ||
18 | contents of the message. Do not include a signature. If you choose to | ||
19 | remove yourself from this list at a later date, send another message to | ||
20 | the same address with the words "unsubscribe linux-beta" as its only | ||
21 | contents. | ||
22 | |||
23 | TABLE OF CONTENTS | ||
24 | ----------------- | ||
25 | 1. Introduction | ||
26 | 1.1 What is ISDN4Linux? | ||
27 | 1.2 What is different between this driver and previous drivers? | ||
28 | 1.3 How do I setup my system with the correct software to use | ||
29 | this driver release? | ||
30 | |||
31 | 2. Basic Operations | ||
32 | 2.1 Unpacking and installing the driver | ||
33 | 2.2 Read the man pages!!! | ||
34 | 2.3 Installing the driver | ||
35 | 2.4 Removing the driver | ||
36 | 2.5 What to do if it doesn't load | ||
37 | 2.6 How to setup ISDN4Linux with the driver | ||
38 | |||
39 | 3. Beta Change Summaries and Miscellaneous Notes | ||
40 | |||
41 | 1. Introduction | ||
42 | --------------- | ||
43 | |||
44 | The revision 2 Linux driver for SpellCaster ISA ISDN adapters is built | ||
45 | upon ISDN4Linux available separately or as included in Linux 2.0 and later. | ||
46 | The driver will support a maximum of 4 adapters in any one system of any | ||
47 | type including DataCommute/BRI, DataCommute/PRI and TeleCommute/BRI for a | ||
48 | maximum of 92 channels for host. The driver is supplied as a module in | ||
49 | source form and needs to be complied before it can be used. It has been | ||
50 | tested on Linux 2.0.20. | ||
51 | |||
52 | 1.1 What Is ISDN4Linux | ||
53 | |||
54 | ISDN4Linux is a driver and set of tools used to access and use ISDN devices | ||
55 | on a Linux platform in a common and standard way. It supports HDLC and PPP | ||
56 | protocols and offers channel bundling and MLPPP support. To use ISDN4Linux | ||
57 | you need to configure your kernel for ISDN support and get the ISDN4Linux | ||
58 | tool kit from our web site. | ||
59 | |||
60 | ISDN4Linux creates a channel pool from all of the available ISDN channels | ||
61 | and therefore can function across adapters. When an ISDN4Linux compliant | ||
62 | driver (such as ours) is loaded, all of the channels go into a pool and | ||
63 | are used on a first-come first-served basis. In addition, individual | ||
64 | channels can be specifically bound to particular interfaces. | ||
65 | |||
66 | 1.2 What is different between this driver and previous drivers? | ||
67 | |||
68 | The revision 2 driver besides adopting the ISDN4Linux architecture has many | ||
69 | subtle and not so subtle functional differences from previous releases. These | ||
70 | include: | ||
71 | - More efficient shared memory management combined with a simpler | ||
72 | configuration. All adapters now use only 16Kbytes of shared RAM | ||
73 | versus between 16K and 64K. New methods for using the shared RAM | ||
74 | allow us to utilize all of the available RAM on the adapter through | ||
75 | only one 16K page. | ||
76 | - Better detection of available upper memory. The probing routines | ||
77 | have been improved to better detect available shared RAM pages and | ||
78 | used pages are now locked. | ||
79 | - Decreased loading time and a wider range of I/O ports probed. | ||
80 | We have significantly reduced the amount of time it takes to load | ||
81 | the driver and at the same time doubled the number of I/O ports | ||
82 | probed increasing the likelihood of finding an adapter. | ||
83 | - We now support all ISA adapter models with a single driver instead | ||
84 | of separate drivers for each model. The revision 2 driver supports | ||
85 | the DataCommute/BRI, DataCommute/PRI and TeleCommute/BRI in any | ||
86 | combination up to a maximum of four adapters per system. | ||
87 | - On board PPP protocol support has been removed in favour of the | ||
88 | sync-PPP support used in ISDN4Linux. This means more control of | ||
89 | the protocol parameters, faster negotiation time and a more | ||
90 | familiar interface. | ||
91 | |||
92 | 1.3 How do I setup my system with the correct software to use | ||
93 | this driver release? | ||
94 | |||
95 | Before you can compile, install and use the SpellCaster ISA ISDN driver, you | ||
96 | must ensure that the following software is installed, configured and running: | ||
97 | |||
98 | - Linux kernel 2.0.20 or later with the required init and ps | ||
99 | versions. Please see your distribution vendor for the correct | ||
100 | utility packages. The latest kernel is available from | ||
101 | ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0/ | ||
102 | |||
103 | - The latest modules package (modules-2.0.0.tar.gz) from | ||
104 | ftp://sunsite.unc.edu/pub/Linux/kernel/modules-2.0.0.tar.gz | ||
105 | |||
106 | - The ISDN4Linux tools available from | ||
107 | ftp://ftp.franken.de/pub/isdn4linux/v2.0/isdn4k-utils-2.0.tar.gz | ||
108 | This package may fail to compile for you so you can alternatively | ||
109 | get a pre-compiled version from | ||
110 | ftp://ftp.spellcast.com/pub/drivers/isdn4linux/isdn4k-bin-2.0.tar.gz | ||
111 | |||
112 | |||
113 | 2. Basic Operations | ||
114 | ------------------- | ||
115 | |||
116 | 2.1 Unpacking and installing the driver | ||
117 | |||
118 | 1. As root, create a directory in a convenient place. We suggest | ||
119 | /usr/src/spellcaster. | ||
120 | |||
121 | 2. Unpack the archive with : | ||
122 | tar xzf sc-n.nn.tar.gz -C /usr/src/spellcaster | ||
123 | |||
124 | 3. Change directory to /usr/src/spellcaster | ||
125 | |||
126 | 4. Read the README and RELNOTES files. | ||
127 | |||
128 | 5. Run 'make' and if all goes well, run 'make install'. | ||
129 | |||
130 | 2.2 Read the man pages!!! | ||
131 | |||
132 | Make sure you read the scctrl(8) and sc(4) manual pages before continuing | ||
133 | any further. Type 'man 8 scctrl' and 'man 4 sc'. | ||
134 | |||
135 | 2.3 Installing the driver | ||
136 | |||
137 | To install the driver, type '/sbin/insmod sc' as root. sc(4) details options | ||
138 | you can specify but you shouldn't need to use any unless this doesn't work. | ||
139 | |||
140 | Make sure the driver loaded and detected all of the adapters by typing | ||
141 | 'dmesg'. | ||
142 | |||
143 | The driver can be configured so that it is loaded upon startup. To do this, | ||
144 | edit the file "/etc/modules/'uname -f'/'uname -v'" and insert the driver name | ||
145 | "sc" into this file. | ||
146 | |||
147 | 2.4 Removing the driver | ||
148 | |||
149 | To remove the driver, delete any interfaces that may exist (see isdnctrl(8) | ||
150 | for more on this) and then type '/sbin/rmmod sc'. | ||
151 | |||
152 | 2.5 What to do if it doesn't load | ||
153 | |||
154 | If, when you try to install the driver, you get a message mentioning | ||
155 | 'register_isdn' then you do not have the ISDN4Linux system installed. Please | ||
156 | make sure that ISDN support is configured in the kernel. | ||
157 | |||
158 | If you get a message that says 'initialization of sc failed', then the | ||
159 | driver failed to detect an adapter or failed to find resources needed such | ||
160 | as a free IRQ line or shared memory segment. If you are sure there are free | ||
161 | resources available, use the insmod options detailed in sc(4) to override | ||
162 | the probing function. | ||
163 | |||
164 | Upon testing, the following problem was noted, the driver would load without | ||
165 | problems, but the board would not respond beyond that point. When a check was | ||
166 | done with 'cat /proc/interrupts' the interrupt count for sc was 0. In the event | ||
167 | of this problem, change the BIOS settings so that the interrupts in question are | ||
168 | reserved for ISA use only. | ||
169 | |||
170 | |||
171 | 2.6 How to setup ISDN4Linux with the driver | ||
172 | |||
173 | There are three main configurations which you can use with the driver: | ||
174 | |||
175 | A) Basic HDLC connection | ||
176 | B) PPP connection | ||
177 | C) MLPPP connection | ||
178 | |||
179 | It should be mentioned here that you may also use a tty connection if you | ||
180 | desire. The Documentation directory of the isdn4linux subsystem offers good | ||
181 | documentation on this feature. | ||
182 | |||
183 | A) 10 steps to the establishment of a basic HDLC connection | ||
184 | ----------------------------------------------------------- | ||
185 | |||
186 | - please open the isdn-hdlc file in the examples directory and follow along... | ||
187 | |||
188 | This file is a script used to configure a BRI ISDN TA to establish a | ||
189 | basic HDLC connection between its two channels. Two network | ||
190 | interfaces are created and two routes added between the channels. | ||
191 | |||
192 | i) using the isdnctrl utility, add an interface with "addif" and | ||
193 | name it "isdn0" | ||
194 | ii) add the outgoing and inbound telephone numbers | ||
195 | iii) set the Layer 2 protocol to hdlc | ||
196 | iv) set the eaz of the interface to be the phone number of that | ||
197 | specific channel | ||
198 | v) to turn the callback features off, set the callback to "off" and | ||
199 | the callback delay (cbdelay) to 0. | ||
200 | vi) the hangup timeout can be set to a specified number of seconds | ||
201 | vii) the hangup upon incoming call can be set on or off | ||
202 | viii) use the ifconfig command to bring up the network interface with | ||
203 | a specific IP address and point to point address | ||
204 | ix) add a route to the IP address through the isdn0 interface | ||
205 | x) a ping should result in the establishment of the connection | ||
206 | |||
207 | |||
208 | B) Establishment of a PPP connection | ||
209 | ------------------------------------ | ||
210 | |||
211 | - please open the isdn-ppp file in the examples directory and follow along... | ||
212 | |||
213 | This file is a script used to configure a BRI ISDN TA to establish a | ||
214 | PPP connection between the two channels. The file is almost | ||
215 | identical to the HDLC connection example except that the packet | ||
216 | encapsulation type has to be set. | ||
217 | |||
218 | use the same procedure as in the HDLC connection from steps i) to | ||
219 | iii) then, after the Layer 2 protocol is set, set the encapsulation | ||
220 | "encap" to syncppp. With this done, the rest of the steps, iv) to x) | ||
221 | can be followed from above. | ||
222 | |||
223 | Then, the ipppd (ippp daemon) must be setup: | ||
224 | |||
225 | xi) use the ipppd function found in /sbin/ipppd to set the following: | ||
226 | xii) take out (minus) VJ compression and bsd compression | ||
227 | xiii) set the mru size to 2000 | ||
228 | xiv) link the two /dev interfaces to the daemon | ||
229 | |||
230 | NOTE: A "*" in the inbound telephone number specifies that a call can be | ||
231 | accepted on any number. | ||
232 | |||
233 | C) Establishment of a MLPPP connection | ||
234 | -------------------------------------- | ||
235 | |||
236 | - please open the isdn-mppp file in the examples directory and follow along... | ||
237 | |||
238 | This file is a script used to configure a BRI ISDN TA to accept a | ||
239 | Multi Link PPP connection. | ||
240 | |||
241 | i) using the isdnctrl utility, add an interface with "addif" and | ||
242 | name it "ippp0" | ||
243 | ii) add the inbound telephone number | ||
244 | iii) set the Layer 2 protocol to hdlc and the Layer 3 protocol to | ||
245 | trans (transparent) | ||
246 | iv) set the packet encapsulation to syncppp | ||
247 | v) set the eaz of the interface to be the phone number of that | ||
248 | specific channel | ||
249 | vi) to turn the callback features off, set the callback to "off" and | ||
250 | the callback delay (cbdelay) to 0. | ||
251 | vi) the hangup timeout can be set to a specified number of seconds | ||
252 | vii) the hangup upon incoming call can be set on or off | ||
253 | viii) add a slave interface and name it "ippp32" for example | ||
254 | ix) set the similar parameters for the ippp32 interface | ||
255 | x) use the ifconfig command to bring-up the ippp0 interface with a | ||
256 | specific IP address and point to point address | ||
257 | xi) add a route to the IP address through the ippp0 interface | ||
258 | xii) use the ipppd function found in /sbin/ipppd to set the following: | ||
259 | xiii) take out (minus) bsd compression | ||
260 | xiv) set the mru size to 2000 | ||
261 | xv) add (+) the multi-link function "+mp" | ||
262 | xvi) link the two /dev interfaces to the daemon | ||
263 | |||
264 | NOTE: To use the MLPPP connection to dial OUT to a MLPPP connection, change | ||
265 | the inbound telephone numbers to the outgoing telephone numbers of the MLPPP | ||
266 | host. | ||
267 | |||
268 | |||
269 | 3. Beta Change Summaries and Miscellaneous Notes | ||
270 | ------------------------------------------------ | ||
271 | When using the "scctrl" utility to upload firmware revisions on the board, | ||
272 | please note that the byte count displayed at the end of the operation may be | ||
273 | different from the total number of bytes in the "dcbfwn.nn.sr" file. Please | ||
274 | disregard the displayed byte count. | ||
275 | |||
276 | It was noted that in Beta Release 1, the module would fail to load and result | ||
277 | in a segmentation fault when 'insmod'ed. This problem was created when one of | ||
278 | the isdn4linux parameters, (isdn_ctrl, data field) was filled in. In some | ||
279 | cases, this data field was NULL, and was left unchecked, so when it was | ||
280 | referenced... segv. The bug has been fixed around line 63-68 of event.c. | ||
281 | |||
diff --git a/Documentation/isdn/README.syncppp b/Documentation/isdn/README.syncppp new file mode 100644 index 000000000000..27d260095cce --- /dev/null +++ b/Documentation/isdn/README.syncppp | |||
@@ -0,0 +1,58 @@ | |||
1 | Some additional information for setting up a syncPPP | ||
2 | connection using network interfaces. | ||
3 | --------------------------------------------------------------- | ||
4 | |||
5 | You need one thing beside the isdn4linux package: | ||
6 | |||
7 | a patched pppd .. (I called it ipppd to show the difference) | ||
8 | |||
9 | Compiling isdn4linux with sync PPP: | ||
10 | ----------------------------------- | ||
11 | To compile isdn4linux with the sync PPP part, you have | ||
12 | to answer the appropriate question when doing a "make config" | ||
13 | Don't forget to load the slhc.o | ||
14 | module before the isdn.o module, if VJ-compression support | ||
15 | is not compiled into your kernel. (e.g if you have no PPP or | ||
16 | CSLIP in the kernel) | ||
17 | |||
18 | Using isdn4linux with sync PPP: | ||
19 | ------------------------------- | ||
20 | Sync PPP is just another encapsulation for isdn4linux. The | ||
21 | name to enable sync PPP encapsulation is 'syncppp' .. e.g: | ||
22 | |||
23 | /sbin/isdnctrl encap ippp0 syncppp | ||
24 | |||
25 | The name of the interface is here 'ippp0'. You need | ||
26 | one interface with the name 'ippp0' to saturate the | ||
27 | ipppd, which checks the ppp version via this interface. | ||
28 | Currently, all devices must have the name ipppX where | ||
29 | 'X' is a decimal value. | ||
30 | |||
31 | To set up a PPP connection you need the ipppd .. You must start | ||
32 | the ipppd once after installing the modules. The ipppd | ||
33 | communicates with the isdn4linux link-level driver using the | ||
34 | /dev/ippp0 to /dev/ippp15 devices. One ipppd can handle | ||
35 | all devices at once. If you want to use two PPP connections | ||
36 | at the same time, you have to connect the ipppd to two | ||
37 | devices .. and so on. | ||
38 | I've implemented one additional option for the ipppd: | ||
39 | 'useifip' will get (if set to not 0.0.0.0) the IP address | ||
40 | for the negotiation from the attached network-interface. | ||
41 | (also: ipppd will try to negotiate pointopoint IP as remote IP) | ||
42 | You must disable BSD-compression, this implementation can't | ||
43 | handle compressed packets. | ||
44 | |||
45 | Check the etc/rc.isdn.syncppp in the isdn4kernel-util package | ||
46 | for an example setup script. | ||
47 | |||
48 | To use the MPPP stuff, you must configure a slave device | ||
49 | with isdn4linux. Now call the ipppd with the '+mp' option. | ||
50 | To increase the number of links, you must use the | ||
51 | 'addlink' option of the isdnctrl tool. (rc.isdn.syncppp.MPPP is | ||
52 | an example script) | ||
53 | |||
54 | enjoy it, | ||
55 | michael | ||
56 | |||
57 | |||
58 | |||
diff --git a/Documentation/isdn/README.x25 b/Documentation/isdn/README.x25 new file mode 100644 index 000000000000..e561a77c4e22 --- /dev/null +++ b/Documentation/isdn/README.x25 | |||
@@ -0,0 +1,184 @@ | |||
1 | |||
2 | X.25 support within isdn4linux | ||
3 | ============================== | ||
4 | |||
5 | This is alpha/beta test code. Use it completely at your own risk. | ||
6 | As new versions appear, the stuff described here might suddenly change | ||
7 | or become invalid without notice. | ||
8 | |||
9 | Keep in mind: | ||
10 | |||
11 | You are using several new parts of the 2.2.x kernel series which | ||
12 | have not been tested in a large scale. Therefore, you might encounter | ||
13 | more bugs as usual. | ||
14 | |||
15 | - If you connect to an X.25 neighbour not operated by yourself, ASK the | ||
16 | other side first. Be prepared that bugs in the protocol implementation | ||
17 | might result in problems. | ||
18 | |||
19 | - This implementation has never wiped out my whole hard disk yet. But as | ||
20 | this is experimental code, don't blame me if that happened to you. | ||
21 | Backing up important data will never harm. | ||
22 | |||
23 | - Monitor your isdn connections while using this software. This should | ||
24 | prevent you from undesired phone bills in case of driver problems. | ||
25 | |||
26 | |||
27 | |||
28 | |||
29 | How to configure the kernel | ||
30 | =========================== | ||
31 | |||
32 | The ITU-T (former CCITT) X.25 network protocol layer has been implemented | ||
33 | in the Linux source tree since version 2.1.16. The isdn subsystem might be | ||
34 | useful to run X.25 on top of ISDN. If you want to try it, select | ||
35 | |||
36 | "CCITT X.25 Packet Layer" | ||
37 | |||
38 | from the networking options as well as | ||
39 | |||
40 | "ISDN Support" and "X.25 PLP on Top of ISDN" | ||
41 | |||
42 | from the ISDN subsystem options when you configure your kernel for | ||
43 | compilation. You currently also need to enable | ||
44 | "Prompt for development and/or incomplete code/drivers" from the | ||
45 | "Code maturity level options" menu. For the x25trace utility to work | ||
46 | you also need to enable "Packet socket". | ||
47 | |||
48 | For local testing it is also recommended to enable the isdnloop driver | ||
49 | from the isdn subsystem's configuration menu. | ||
50 | |||
51 | For testing, it is recommended that all isdn drivers and the X.25 PLP | ||
52 | protocol are compiled as loadable modules. Like this, you can recover | ||
53 | from certain errors by simply unloading and reloading the modules. | ||
54 | |||
55 | |||
56 | |||
57 | What's it for? How to use it? | ||
58 | ============================= | ||
59 | |||
60 | X.25 on top of isdn might be useful with two different scenarios: | ||
61 | |||
62 | - You might want to access a public X.25 data network from your Linux box. | ||
63 | You can use i4l if you were physically connected to the X.25 switch | ||
64 | by an ISDN B-channel (leased line as well as dial up connection should | ||
65 | work). | ||
66 | |||
67 | This corresponds to ITU-T recommendation X.31 Case A (circuit-mode | ||
68 | access to PSPDN [packet switched public data network]). | ||
69 | |||
70 | NOTE: X.31 also covers a Case B (access to PSPDN via virtual | ||
71 | circuit / packet mode service). The latter mode (which in theory | ||
72 | also allows using the D-channel) is not supported by isdn4linux. | ||
73 | It should however be possible to establish such packet mode connections | ||
74 | with certain active isdn cards provided that the firmware supports X.31 | ||
75 | and the driver exports this functionality to the user. Currently, | ||
76 | the AVM B1 driver is the only driver which does so. (It should be | ||
77 | possible to access D-channel X.31 with active AVM cards using the | ||
78 | CAPI interface of the AVM-B1 driver). | ||
79 | |||
80 | - Or you might want to operate certain ISDN teleservices on your linux | ||
81 | box. A lot of those teleservices run on top of the ISO-8208 | ||
82 | (DTE-DTE mode) network layer protocol. ISO-8208 is essentially the | ||
83 | same as ITU-T X.25. | ||
84 | |||
85 | Popular candidates of such teleservices are EUROfile transfer or any | ||
86 | teleservice applying ITU-T recommendation T.90. | ||
87 | |||
88 | To use the X.25 protocol on top of isdn, just create an isdn network | ||
89 | interface as usual, configure your own and/or peer's ISDN numbers, | ||
90 | and choose x25iface encapsulation by | ||
91 | |||
92 | isdnctrl encap <iface-name> x25iface. | ||
93 | |||
94 | Once encap is set like this, the device can be used by the X.25 packet layer. | ||
95 | |||
96 | All the stuff needed for X.25 is implemented inside the isdn link | ||
97 | level (mainly isdn_net.c and some new source files). Thus, it should | ||
98 | work with every existing HL driver. I was able to successfully open X.25 | ||
99 | connections on top of the isdnloop driver and the hisax driver. | ||
100 | "x25iface"-encapsulation bypasses demand dialing. Dialing will be | ||
101 | initiated when the upper (X.25 packet) layer requests the lapb datalink to | ||
102 | be established. But hangup timeout is still active. Whenever a hangup | ||
103 | occurs, all existing X.25 connections on that link will be cleared | ||
104 | It is recommended to use sufficiently large hangup-timeouts for the | ||
105 | isdn interfaces. | ||
106 | |||
107 | |||
108 | In order to set up a conforming protocol stack you also need to | ||
109 | specify the proper l2_prot parameter: | ||
110 | |||
111 | To operate in ISO-8208 X.25 DTE-DTE mode, use | ||
112 | |||
113 | isdnctrl l2_prot <iface-name> x75i | ||
114 | |||
115 | To access an X.25 network switch via isdn (your linux box is the DTE), use | ||
116 | |||
117 | isdnctrl l2_prot <iface-name> x25dte | ||
118 | |||
119 | To mimic an X.25 network switch (DCE side of the connection), use | ||
120 | |||
121 | isdnctrl l2_prot <iface-name> x25dce | ||
122 | |||
123 | However, x25dte or x25dce is currently not supported by any real HL | ||
124 | level driver. The main difference between x75i and x25dte/dce is that | ||
125 | x25d[tc]e uses fixed lap_b addresses. With x75i, the side which | ||
126 | initiates the isdn connection uses the DTE's lap_b address while the | ||
127 | called side used the DCE's lap_b address. Thus, l2_prot x75i might | ||
128 | probably work if you access a public X.25 network as long as the | ||
129 | corresponding isdn connection is set up by you. At least one test | ||
130 | was successful to connect via isdn4linux to an X.25 switch using this | ||
131 | trick. At the switch side, a terminal adapter X.21 was used to connect | ||
132 | it to the isdn. | ||
133 | |||
134 | |||
135 | How to set up a test installation? | ||
136 | ================================== | ||
137 | |||
138 | To test X.25 on top of isdn, you need to get | ||
139 | |||
140 | - a recent version of the "isdnctrl" program that supports setting the new | ||
141 | X.25 specific parameters. | ||
142 | |||
143 | - the x25-utils-2.X package from | ||
144 | ftp://ftp.hes.iki.fi/pub/ham/linux/ax25/x25utils-* | ||
145 | (don't confuse the x25-utils with the ax25-utils) | ||
146 | |||
147 | - an application program that uses linux PF_X25 sockets (some are | ||
148 | contained in the x25-util package). | ||
149 | |||
150 | Before compiling the user level utilities make sure that the compiler/ | ||
151 | preprocessor will fetch the proper kernel header files of this kernel | ||
152 | source tree. Either make /usr/include/linux a symbolic link pointing to | ||
153 | this kernel's include/linux directory or set the appropriate compiler flags. | ||
154 | |||
155 | When all drivers and interfaces are loaded and configured you need to | ||
156 | ifconfig the network interfaces up and add X.25-routes to them. Use | ||
157 | the usual ifconfig tool. | ||
158 | |||
159 | ifconfig <iface-name> up | ||
160 | |||
161 | But a special x25route tool (distributed with the x25-util package) | ||
162 | is needed to set up X.25 routes. I.e. | ||
163 | |||
164 | x25route add 01 <iface-name> | ||
165 | |||
166 | will cause all x.25 connections to the destination X.25-address | ||
167 | "01" to be routed to your created isdn network interface. | ||
168 | |||
169 | There are currently no real X.25 applications available. However, for | ||
170 | tests, the x25-utils package contains a modified version of telnet | ||
171 | and telnetd that uses X.25 sockets instead of tcp/ip sockets. You can | ||
172 | use those for your first tests. Furthermore, you might check | ||
173 | ftp://ftp.hamburg.pop.de/pub/LOCAL/linux/i4l-eft/ which contains some | ||
174 | alpha-test implementation ("eftp4linux") of the EUROfile transfer | ||
175 | protocol. | ||
176 | |||
177 | The scripts distributed with the eftp4linux test releases might also | ||
178 | provide useful examples for setting up X.25 on top of isdn. | ||
179 | |||
180 | The x25-utility package also contains an x25trace tool that can be | ||
181 | used to monitor X.25 packets received by the network interfaces. | ||
182 | The /proc/net/x25* files also contain useful information. | ||
183 | |||
184 | - Henner | ||
diff --git a/Documentation/isdn/syncPPP.FAQ b/Documentation/isdn/syncPPP.FAQ new file mode 100644 index 000000000000..3257a4bc0786 --- /dev/null +++ b/Documentation/isdn/syncPPP.FAQ | |||
@@ -0,0 +1,224 @@ | |||
1 | simple isdn4linux PPP FAQ .. to be continued .. not 'debugged' | ||
2 | ------------------------------------------------------------------- | ||
3 | |||
4 | Q01: what's pppd, ipppd, syncPPP, asyncPPP ?? | ||
5 | Q02: error message "this system lacks PPP support" | ||
6 | Q03: strange information using 'ifconfig' | ||
7 | Q04: MPPP?? What's that and how can I use it ... | ||
8 | Q05: I tried MPPP but it doesn't work | ||
9 | Q06: can I use asynchronous PPP encapsulation with network devices | ||
10 | Q07: A SunISDN machine can't connect to my i4l system | ||
11 | Q08: I wanna talk to several machines, which need different configs | ||
12 | Q09: Starting the ipppd, I get only error messages from i4l | ||
13 | Q10: I wanna use dynamic IP address assignment | ||
14 | Q11: I can't connect. How can I check where the problem is. | ||
15 | Q12: How can I reduce login delay? | ||
16 | |||
17 | ------------------------------------------------------------------- | ||
18 | |||
19 | Q01: pppd, ipppd, syncPPP, asyncPPP .. what is that ? | ||
20 | what should I use? | ||
21 | A: The pppd is for asynchronous PPP .. asynchronous means | ||
22 | here, the framing is character based. (e.g when | ||
23 | using ttyI* or tty* devices) | ||
24 | |||
25 | The ipppd handles PPP packets coming in HDLC | ||
26 | frames (bit based protocol) ... The PPP driver | ||
27 | in isdn4linux pushes all IP packets direct | ||
28 | to the network layer and all PPP protocol | ||
29 | frames to the /dev/ippp* device. | ||
30 | So, the ipppd is a simple external network | ||
31 | protocol handler. | ||
32 | |||
33 | If you login into a remote machine using the | ||
34 | /dev/ttyI* devices and then enable PPP on the | ||
35 | remote terminal server -> use the 'old' pppd | ||
36 | |||
37 | If your remote side immediately starts to send | ||
38 | frames ... you probably connect to a | ||
39 | syncPPP machine .. use the network device part | ||
40 | of isdn4linux with the 'syncppp' encapsulation | ||
41 | and make sure, that the ipppd is running and | ||
42 | connected to at least one /dev/ippp*. Check the | ||
43 | isdn4linux manual on how to configure a network device. | ||
44 | |||
45 | -- | ||
46 | |||
47 | Q02: when I start the ipppd .. I only get the | ||
48 | error message "this system lacks PPP support" | ||
49 | A: check that at least the device 'ippp0' exists. | ||
50 | (you can check this e.g with the program 'ifconfig') | ||
51 | The ipppd NEEDS this device under THIS name .. | ||
52 | If this device doesn't exists, use: | ||
53 | isdnctrl addif ippp0 | ||
54 | isdnctrl encap ippp0 syncppp | ||
55 | ... (see isdn4linux doc for more) ... | ||
56 | A: Maybe you have compiled the ipppd with another | ||
57 | kernel source tree than the kernel you currently | ||
58 | run ... | ||
59 | |||
60 | -- | ||
61 | |||
62 | Q03: when I list the netdevices with ifconfig I see, that | ||
63 | my ISDN interface has a HWaddr and IRQ=0 and Base | ||
64 | address = 0 | ||
65 | A: The device is a fake ethernet device .. ignore IRQ and baseaddr | ||
66 | You need the HWaddr only for ethernet encapsulation. | ||
67 | |||
68 | -- | ||
69 | |||
70 | Q04: MPPP?? What's that and how can I use it ... | ||
71 | |||
72 | A: MPPP or MP or MPP (Warning: MP is also an | ||
73 | acronym for 'Multi Processor') stands for | ||
74 | Multi Point to Point and means bundling | ||
75 | of several channels to one logical stream. | ||
76 | To enable MPPP negotiation you must call the | ||
77 | ipppd with the '+mp' option. | ||
78 | You must also configure a slave device for | ||
79 | every additional channel. (see the i4l manual | ||
80 | for more) | ||
81 | To use channel bundling you must first activate | ||
82 | the 'master' or initial call. Now you can add | ||
83 | the slave channels with the command: | ||
84 | isdnctrl addlink <device> | ||
85 | e.g: | ||
86 | isdnctrl addlink ippp0 | ||
87 | This is different from other encapsulations of | ||
88 | isdn4linux! With syncPPP, there is no automatic | ||
89 | activation of slave devices. | ||
90 | |||
91 | -- | ||
92 | |||
93 | Q05: I tried MPPP but it doesn't work .. the ipppd | ||
94 | writes in the debug log something like: | ||
95 | .. rcvd [0][proto=0x3d] c0 00 00 00 80 fd 01 01 00 0a ... | ||
96 | .. sent [0][LCP ProtRej id=0x2 00 3d c0 00 00 00 80 fd 01 ... | ||
97 | |||
98 | A: you forgot to compile MPPP/RFC1717 support into the | ||
99 | ISDN Subsystem. Recompile with this option enabled. | ||
100 | |||
101 | -- | ||
102 | |||
103 | Q06: can I use asynchronous PPP encapsulation | ||
104 | over the network interface of isdn4linux .. | ||
105 | |||
106 | A: No .. that's not possible .. Use the standard | ||
107 | PPP package over the /dev/ttyI* devices. You | ||
108 | must not use the ipppd for this. | ||
109 | |||
110 | -- | ||
111 | |||
112 | Q07: A SunISDN machine tries to connect my i4l system, | ||
113 | which doesn't work. | ||
114 | Checking the debug log I just saw garbage like: | ||
115 | !![ ... fill in the line ... ]!! | ||
116 | |||
117 | A: The Sun tries to talk asynchronous PPP ... i4l | ||
118 | can't understand this ... try to use the ttyI* | ||
119 | devices with the standard PPP/pppd package | ||
120 | |||
121 | A: (from Alexanter Strauss: ) | ||
122 | !![ ... fill in mail ]!! | ||
123 | |||
124 | -- | ||
125 | |||
126 | Q08: I wanna talk to remote machines, which need | ||
127 | a different configuration. The only way | ||
128 | I found to do this is to kill the ipppd and | ||
129 | start a new one with another config to connect | ||
130 | to the second machine. | ||
131 | |||
132 | A: you must bind a network interface explicitly to | ||
133 | an ippp device, where you can connect a (for this | ||
134 | interface) individually configured ipppd. | ||
135 | |||
136 | -- | ||
137 | |||
138 | Q09: When I start the ipppd I only get error messages | ||
139 | from the i4l driver .. | ||
140 | |||
141 | A: When starting, the ipppd calls functions which may | ||
142 | trigger a network packet. (e.g gethostbyname()). | ||
143 | Without the ipppd (at this moment, it is not | ||
144 | fully started) we can't handle this network request. | ||
145 | Try to configure hostnames necessary for the ipppd | ||
146 | in your local /etc/hosts file or in a way, that | ||
147 | your system can resolve it without using an | ||
148 | isdn/ippp network-interface. | ||
149 | |||
150 | -- | ||
151 | |||
152 | Q10: I wanna use dynamic IP address assignment ... How | ||
153 | must I configure the network device. | ||
154 | |||
155 | A: At least you must have a route which forwards | ||
156 | a packet to the ippp network-interface to trigger | ||
157 | the dial-on-demand. | ||
158 | A default route to the ippp-interface will work. | ||
159 | Now you must choose a dummy IP address for your | ||
160 | interface. | ||
161 | If for some reason you can't set the default | ||
162 | route to the ippp interface, you may take any | ||
163 | address of the subnet from which you expect your | ||
164 | dynamic IP number and set a 'network route' for | ||
165 | this subnet to the ippp interface. | ||
166 | To allow overriding of the dummy address you | ||
167 | must call the ipppd with the 'ipcp-accept-local' option. | ||
168 | |||
169 | A: You must know, how the ipppd gets the addresses it wanna | ||
170 | configure. If you don't give any option, the ipppd | ||
171 | tries to negotiate the local host address! | ||
172 | With the option 'noipdefault' it requests an address | ||
173 | from the remote machine. With 'useifip' it gets the | ||
174 | addresses from the net interface. Or you set the address | ||
175 | on the option line with the <a.b.c.d:e.f.g.h> option. | ||
176 | Note: the IP address of the remote machine must be configured | ||
177 | locally or the remote machine must send it in an IPCP request. | ||
178 | If your side doesn't know the IP address after negotiation, it | ||
179 | closes the connection! | ||
180 | You must allow overriding of address with the 'ipcp-accept-*' | ||
181 | options, if you have set your own or the remote address | ||
182 | explicitly. | ||
183 | |||
184 | A: Maybe you try these options .. e.g: | ||
185 | |||
186 | /sbin/ipppd :$REMOTE noipdefault /dev/ippp0 | ||
187 | |||
188 | where REMOTE must be the address of the remote machine (the | ||
189 | machine, which gives you your address) | ||
190 | |||
191 | -- | ||
192 | |||
193 | Q11: I can't connect. How can I check where the problem is. | ||
194 | |||
195 | A: A good help log is the debug output from the ipppd... | ||
196 | Check whether you can find there: | ||
197 | - only a few LCP-conf-req SENT messages (less then 10) | ||
198 | and then a Term-REQ: | ||
199 | -> check whether your ISDN card is well configured | ||
200 | it seems, that your machine doesn't dial | ||
201 | (IRQ,IO,Proto, etc problems) | ||
202 | Configure your ISDN card to print debug messages and | ||
203 | check the /dev/isdnctrl output next time. There | ||
204 | you can see, whether there is activity on the card/line. | ||
205 | - there are at least a few RECV messages in the log: | ||
206 | -> fine: your card is dialing and your remote machine | ||
207 | tries to talk with you. Maybe only a missing | ||
208 | authentication. Check your ipppd configuration again. | ||
209 | - the ipppd exits for some reason: | ||
210 | -> not good ... check /var/adm/syslog and /var/adm/daemon. | ||
211 | Could be a bug in the ipppd. | ||
212 | |||
213 | -- | ||
214 | |||
215 | Q12: How can I reduce login delay? | ||
216 | |||
217 | A: Log a login session ('debug' log) and check which options | ||
218 | your remote side rejects. Next time configure your ipppd | ||
219 | to not negotiate these options. Another 'side effect' is, that | ||
220 | this increases redundancy. (e.g your remote side is buggy and | ||
221 | rejects options in a wrong way). | ||
222 | |||
223 | |||
224 | |||