aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/isdn
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2019-04-18 16:43:36 -0400
committerArnd Bergmann <arnd@arndb.de>2019-05-31 05:13:10 -0400
commit9c3c0c2048149d946d7f3ebdcbe70e2946750bfb (patch)
treef970c07223bafd2bbd723bec1d8d9fdd1a56038a /Documentation/isdn
parent85993b8c9786fb24975dbcabebb1c75790d4fb6a (diff)
isdn: remove isdn4linux
With all isdn4linux hardware drivers gone, this is only a wrapper around CAPI to support old user space. However, from looking at the mailing list, it seems that the last time anyone asked about it was in 2014, when the upgrade from a linux-2.4 installation failed, and mISDN was suggested as a replacement. The largest public ISDN network (Deutsche Telekom) was supposed to be shut down 2018, which must have drastically reduced the number of legacy installations. When we last discussed removing i4l in 2016, Karsten Keil suggested revisiting this in 2018. I guess this is overdue. Link: http://listserv.isdn4linux.de/pipermail/isdn4linux/2014-October/006165.html Link: https://patchwork.kernel.org/patch/8484861/#17900371 Link: https://listserv.isdn4linux.de/pipermail/isdn4linux/2019-April/thread.html Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'Documentation/isdn')
-rw-r--r--Documentation/isdn/INTERFACE759
-rw-r--r--Documentation/isdn/INTERFACE.fax163
-rw-r--r--Documentation/isdn/README599
-rw-r--r--Documentation/isdn/README.FAQ26
-rw-r--r--Documentation/isdn/README.audio138
-rw-r--r--Documentation/isdn/README.concap259
-rw-r--r--Documentation/isdn/README.diversion127
-rw-r--r--Documentation/isdn/README.fax45
-rw-r--r--Documentation/isdn/README.hfc-pci41
-rw-r--r--Documentation/isdn/README.syncppp58
-rw-r--r--Documentation/isdn/README.x25184
-rw-r--r--Documentation/isdn/syncPPP.FAQ224
12 files changed, 0 insertions, 2623 deletions
diff --git a/Documentation/isdn/INTERFACE b/Documentation/isdn/INTERFACE
deleted file mode 100644
index 5df17e5b25c8..000000000000
--- a/Documentation/isdn/INTERFACE
+++ /dev/null
@@ -1,759 +0,0 @@
1$Id: INTERFACE,v 1.15.8.2 2001/03/13 16:17:07 kai Exp $
2
3Description 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
421. 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
2102. 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
4783. 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
deleted file mode 100644
index 9c8c6d914ec7..000000000000
--- a/Documentation/isdn/INTERFACE.fax
+++ /dev/null
@@ -1,163 +0,0 @@
1$Id: INTERFACE.fax,v 1.2 2000/08/06 09:22:50 armin Exp $
2
3
4Description 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
15Data 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
21Structure 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 parameters and use ISDN_STAT_FAXIND.
30 (Please refer to INTERFACE)
31
32Structure 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
161Armin
162mac@melware.de
163
diff --git a/Documentation/isdn/README b/Documentation/isdn/README
deleted file mode 100644
index 74bd2bdb455b..000000000000
--- a/Documentation/isdn/README
+++ /dev/null
@@ -1,599 +0,0 @@
1README for the ISDN-subsystem
2
31. 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 https://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 https://www.isdn4linux.de/faq/i4lfaq.html
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
3192 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
3273. 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
3324. Device-inodes
333
334 The major and minor numbers and their names are described in
335 Documentation/admin-guide/devices.rst. 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
3415. 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
4235. 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
5866. 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
596Have fun!
597
598 -Fritz
599
diff --git a/Documentation/isdn/README.FAQ b/Documentation/isdn/README.FAQ
deleted file mode 100644
index e5dd1addacdd..000000000000
--- a/Documentation/isdn/README.FAQ
+++ /dev/null
@@ -1,26 +0,0 @@
1
2The FAQ for isdn4linux
3======================
4
5Please note that there is a big FAQ available in the isdn4k-utils.
6You find it in:
7 isdn4k-utils/FAQ/i4lfaq.sgml
8
9In case you just want to see the FAQ online, or download the newest version,
10you can have a look at my website:
11https://www.mhessler.de/i4lfaq/ (view + download)
12or:
13https://www.isdn4linux.de/faq/4lfaq.html (view)
14
15As the extension tells, the FAQ is in SGML format, and you can convert it
16into text/html/... format by using the sgml2txt/sgml2html/... tools.
17Alternatively, you can also do a 'configure; make all' in the FAQ directory.
18
19
20Please have a look at the FAQ before posting anything in the Mailinglist,
21or the newsgroup!
22
23
24Matthias Hessler
25hessler@isdn4linux.de
26
diff --git a/Documentation/isdn/README.audio b/Documentation/isdn/README.audio
deleted file mode 100644
index 8ebca19290d9..000000000000
--- a/Documentation/isdn/README.audio
+++ /dev/null
@@ -1,138 +0,0 @@
1$Id: README.audio,v 1.8 1999/07/11 17:17:29 armin Exp $
2
3ISDN subsystem for Linux.
4 Description of audio mode.
5
6When enabled during kernel configuration, the tty emulator of the ISDN
7subsystem is capable of a reduced set of commands to support audio.
8This document describes the commands supported and the format of
9audio data.
10
11Commands 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
23Commands supported in audio mode:
24
25All 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
32where xx is a two-character code and v are alphanumerical parameters.
33The 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.
84General 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.concap b/Documentation/isdn/README.concap
deleted file mode 100644
index a76d74845a4c..000000000000
--- a/Documentation/isdn/README.concap
+++ /dev/null
@@ -1,259 +0,0 @@
1Description of the "concap" encapsulation protocol interface
2============================================================
3
4The "concap" interface is intended to be used by network device
5drivers that need to process an encapsulation protocol.
6It is assumed that the protocol interacts with a linux network device by
7- data transmission
8- connection control (establish, release)
9Thus, the mnemonic: "CONnection CONtrolling eNCAPsulation Protocol".
10
11This is currently only used inside the isdn subsystem. But it might
12also be useful to other kinds of network devices. Thus, if you want
13to suggest changes that improve usability or performance of the
14interface, please let me know. I'm willing to include them in future
15releases (even if I needed to adapt the current isdn code to the
16changed interface).
17
18
19Why is this useful?
20===================
21
22The encapsulation protocol used on top of WAN connections or permanent
23point-to-point links are frequently chosen upon bilateral agreement.
24Thus, a device driver for a certain type of hardware must support
25several different encapsulation protocols at once.
26
27The isdn device driver did already support several different
28encapsulation protocols. The encapsulation protocol is configured by a
29user space utility (isdnctrl). The isdn network interface code then
30uses several case statements which select appropriate actions
31depending on the currently configured encapsulation protocol.
32
33In contrast, LAN network interfaces always used a single encapsulation
34protocol which is unique to the hardware type of the interface. The LAN
35encapsulation is usually done by just sticking a header on the data. Thus,
36traditional linux network device drivers used to process the
37encapsulation protocol directly (usually by just providing a hard_header()
38method in the device structure) using some hardware type specific support
39functions. This is simple, direct and efficient. But it doesn't fit all
40the 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
48Many Encapsulation protocols used on top of WAN connections will not just
49stick a header on the data. They also might need to set up or release
50the WAN connection. They also might want to send other data for their
51private purpose over the wire, e.g. ppp does a lot of link level
52negotiation before the first piece of user data can be transmitted.
53Such encapsulation protocols for WAN devices are typically more complex
54than encapsulation protocols for lan devices. Thus, network interface
55code for typical WAN devices also tends to be more complex.
56
57
58In order to support Linux' x25 PLP implementation on top of
59isdn network interfaces I could have introduced yet another branch to
60the various case statements inside drivers/isdn/isdn_net.c.
61This eventually made isdn_net.c even more complex. In addition, it made
62isdn_net.c harder to maintain. Thus, by identifying an abstract
63interface between the network interface code and the encapsulation
64protocol, complexity could be reduced and maintainability could be
65increased.
66
67
68Likewise, a similar encapsulation protocol will frequently be needed by
69several different interfaces of even different hardware type, e.g. the
70synchronous ppp implementation used by the isdn driver and the
71asynchronous ppp implementation used by the ppp driver have a lot of
72similar code in them. By cleanly separating the encapsulation protocol
73from the hardware specific interface stuff such code could be shared
74better in future.
75
76
77When operating over dial-up-connections (e.g. telephone lines via modem,
78non-permanent virtual circuits of wide area networks, ISDN) many
79encapsulation protocols will need to control the connection. Therefore,
80some basic connection control primitives are supported. The type and
81semantics of the connection (i.e the ISO layer where connection service
82is provided) is outside our scope and might be different depending on
83the encapsulation protocol used, e.g. for a ppp module using our service
84on top of a modem connection a connect_request will result in dialing
85a (somewhere else configured) remote phone number. For an X25-interface
86module (LAPB semantics, as defined in Documentation/networking/x25-iface.txt)
87a connect_request will ask for establishing a reliable lapb
88datalink connection.
89
90
91The encapsulation protocol currently provides the following
92service 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
104The network interface driver accesses those primitives via callbacks
105provided by the encapsulation protocol instance within a
106struct concap_proto_ops.
107
108struct 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 longer 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
142The data structures are defined in the header file include/linux/concap.h.
143
144
145A Network interface using encapsulation protocols must also provide
146some 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
152The encapsulation protocol accesses those primitives via callbacks
153provided by the network interface within a struct concap_device_ops.
154
155struct 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
169The network interface does not explicitly provide a receive service
170because the encapsulation protocol directly calls netif_rx().
171
172
173
174
175An encapsulation protocol itself is actually the
176struct 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
190Most of this is filled in when the device requests the protocol to
191be reset (opend). The network interface must provide the net_dev and
192dops pointers. Other concap_proto members should be considered private
193data that are only accessed by the pops callback functions. Likewise,
194a concap proto should access the network device's private data
195only by means of the callbacks referred to by the dops pointer.
196
197
198A possible extended device structure which uses the connection controlling
199encapsulation services could look like this:
200
201struct 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
213Misc Thoughts
214=============
215
216The concept of the concap proto might help to reuse protocol code and
217reduce the complexity of certain network interface implementations.
218The trade off is that it introduces yet another procedure call layer
219when processing the protocol. This has of course some impact on
220performance. However, typically the concap interface will be used by
221devices attached to slow lines (like telephone, isdn, leased synchronous
222lines). For such slow lines, the overhead is probably negligible.
223This might no longer hold for certain high speed WAN links (like
224ATM).
225
226
227If general linux network interfaces explicitly supported concap
228protocols (e.g. by a member struct concap_proto* in struct net_device)
229then the interface of the service function could be changed
230by passing a pointer of type (struct net_device*) instead of
231type (struct concap_proto*). Doing so would make many of the service
232functions compatible to network device support functions.
233
234e.g. instead of the concap protocol's service function
235
236 int (*encap_and_xmit)(struct concap_proto *cprot, struct sk_buff *skb);
237
238we could have
239
240 int (*encap_and_xmit)(struct net_device *ndev, struct sk_buff *skb);
241
242As this is compatible to the dev->hard_start_xmit() method, the device
243driver could directly register the concap protocol's encap_and_xmit()
244function as its hard_start_xmit() method. This would eliminate one
245procedure call layer.
246
247
248The device's data request function could also be defined as
249
250 int (*data_req)(struct net_device *ndev, struct sk_buff *skb);
251
252This might even allow for some protocol stacking. And the network
253interface might even register the same data_req() function directly
254as its hard_start_xmit() method when a zero layer encapsulation
255protocol is configured. Thus, eliminating the performance penalty
256of the concap interface when a trivial concap protocol is used.
257Nevertheless, the device remains able to support encapsulation
258protocol configuration.
259
diff --git a/Documentation/isdn/README.diversion b/Documentation/isdn/README.diversion
deleted file mode 100644
index bddcd5fb86ff..000000000000
--- a/Documentation/isdn/README.diversion
+++ /dev/null
@@ -1,127 +0,0 @@
1The isdn diversion services are a supporting module working together with
2the isdn4linux and the HiSax module for passive cards.
3Active cards, TAs and cards using a own or other driver than the HiSax
4module need to be adapted to the HL<->LL interface described in a separate
5document. The diversion services may be used with all cards supported by
6the HiSax driver.
7The diversion kernel interface and controlling tool divertctrl were written
8by Werner Cornelius (werner@isdn4linux.de or werner@titro.de) under the
9GNU 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
25Table of contents
26=================
27
281. Features of the i4l diversion services
29 (Or what can the i4l diversion services do for me)
30
312. Required hard- and software
32
333. Compiling, installing and loading/unloading the module
34 Tracing calling and diversion information
35
364. Tracing calling and diversion information
37
385. Format of the divert device ASCII output
39
40
411. 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
732. 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
913. 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
1104. 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
1245. 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
deleted file mode 100644
index 5314958a8a6e..000000000000
--- a/Documentation/isdn/README.fax
+++ /dev/null
@@ -1,45 +0,0 @@
1
2Fax with isdn4linux
3===================
4
5When enabled during kernel configuration, the tty emulator
6of the ISDN subsystem is capable of the Fax Class 2 commands.
7
8This 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
16NOTE: 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
21Supported ISDN-Cards
22--------------------
23
24Eicon DIVA Server BRI/PCI
25 - full support with both B-channels.
26
27Eicon DIVA Server 4BRI/PCI
28 - full support with all B-channels.
29
30Eicon DIVA Server PRI/PCI
31 - full support on amount of B-channels
32 depending on DSPs on board.
33
34
35
36The command set is known as Class 2 (not Class 2.0) and
37can be activated by AT+FCLASS=2
38
39
40The interface between the link-level-module and the hardware-level driver
41is described in the files INTERFACE.fax and INTERFACE.
42
43Armin
44mac@melware.de
45
diff --git a/Documentation/isdn/README.hfc-pci b/Documentation/isdn/README.hfc-pci
deleted file mode 100644
index e8a4ef0226e8..000000000000
--- a/Documentation/isdn/README.hfc-pci
+++ /dev/null
@@ -1,41 +0,0 @@
1The driver for the HFC-PCI and HFC-PCI-A chips from CCD may be used
2for many OEM cards using this chips.
3Additionally the driver has a special feature which makes it possible
4to read the echo-channel of the isdn bus. So all frames in both directions
5may be logged.
6When the echo logging feature is used the number of available B-channels
7for a HFC-PCI card is reduced to 1. Of course this is only relevant to
8the card, not to the isdn line.
9To activate the echo mode the following ioctls must be entered:
10
11hisaxctrl <driver/cardname> 10 1
12
13This reduces the available channels to 1. There must not be open connections
14through this card when entering the command.
15And then:
16
17hisaxctrl <driver/cardname> 12 1
18
19This enables the echo mode. If Hex logging is activated the isdnctrlx
20devices show a output with a line beginning of HEX: for the providers
21exchange and ECHO: for isdn devices sending to the provider.
22
23If more than one HFC-PCI cards are installed, a specific card may be selected
24at the hisax module load command line. Supply the load command with the desired
25IO-address of the desired card.
26Example:
27There tree cards installed in your machine at IO-base addresses 0xd000, 0xd400
28and 0xdc00
29If you want to use the card at 0xd400 standalone you should supply the insmod
30or depmod with type=35 io=0xd400.
31If you want to use all three cards, but the order needs to be at 0xdc00,0xd400,
320xd000 you may give the parameters type=35,35,35 io=0xdc00,0xd400,0xd00
33Then the desired card will be the initialised in the desired order.
34If the io parameter is used the io addresses of all used cards should be
35supplied else the parameter is assumed 0 and a auto search for a free card is
36invoked which may not give the wanted result.
37
38Comments and reports to werner@isdn4linux.de or werner@isdn-development.de
39
40
41
diff --git a/Documentation/isdn/README.syncppp b/Documentation/isdn/README.syncppp
deleted file mode 100644
index 27d260095cce..000000000000
--- a/Documentation/isdn/README.syncppp
+++ /dev/null
@@ -1,58 +0,0 @@
1Some additional information for setting up a syncPPP
2connection using network interfaces.
3---------------------------------------------------------------
4
5You need one thing beside the isdn4linux package:
6
7 a patched pppd .. (I called it ipppd to show the difference)
8
9Compiling isdn4linux with sync PPP:
10-----------------------------------
11To compile isdn4linux with the sync PPP part, you have
12to answer the appropriate question when doing a "make config"
13Don't forget to load the slhc.o
14module before the isdn.o module, if VJ-compression support
15is not compiled into your kernel. (e.g if you have no PPP or
16CSLIP in the kernel)
17
18Using isdn4linux with sync PPP:
19-------------------------------
20Sync PPP is just another encapsulation for isdn4linux. The
21name to enable sync PPP encapsulation is 'syncppp' .. e.g:
22
23 /sbin/isdnctrl encap ippp0 syncppp
24
25The name of the interface is here 'ippp0'. You need
26one interface with the name 'ippp0' to saturate the
27ipppd, which checks the ppp version via this interface.
28Currently, all devices must have the name ipppX where
29'X' is a decimal value.
30
31To set up a PPP connection you need the ipppd .. You must start
32the ipppd once after installing the modules. The ipppd
33communicates with the isdn4linux link-level driver using the
34/dev/ippp0 to /dev/ippp15 devices. One ipppd can handle
35all devices at once. If you want to use two PPP connections
36at the same time, you have to connect the ipppd to two
37devices .. and so on.
38I'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)
42You must disable BSD-compression, this implementation can't
43handle compressed packets.
44
45Check the etc/rc.isdn.syncppp in the isdn4kernel-util package
46for an example setup script.
47
48To use the MPPP stuff, you must configure a slave device
49with isdn4linux. Now call the ipppd with the '+mp' option.
50To increase the number of links, you must use the
51'addlink' option of the isdnctrl tool. (rc.isdn.syncppp.MPPP is
52an example script)
53
54enjoy it,
55 michael
56
57
58
diff --git a/Documentation/isdn/README.x25 b/Documentation/isdn/README.x25
deleted file mode 100644
index e561a77c4e22..000000000000
--- a/Documentation/isdn/README.x25
+++ /dev/null
@@ -1,184 +0,0 @@
1
2X.25 support within isdn4linux
3==============================
4
5This is alpha/beta test code. Use it completely at your own risk.
6As new versions appear, the stuff described here might suddenly change
7or become invalid without notice.
8
9Keep in mind:
10
11You are using several new parts of the 2.2.x kernel series which
12have not been tested in a large scale. Therefore, you might encounter
13more 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
29How to configure the kernel
30===========================
31
32The ITU-T (former CCITT) X.25 network protocol layer has been implemented
33in the Linux source tree since version 2.1.16. The isdn subsystem might be
34useful to run X.25 on top of ISDN. If you want to try it, select
35
36 "CCITT X.25 Packet Layer"
37
38from the networking options as well as
39
40 "ISDN Support" and "X.25 PLP on Top of ISDN"
41
42from the ISDN subsystem options when you configure your kernel for
43compilation. 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
46you also need to enable "Packet socket".
47
48For local testing it is also recommended to enable the isdnloop driver
49from the isdn subsystem's configuration menu.
50
51For testing, it is recommended that all isdn drivers and the X.25 PLP
52protocol are compiled as loadable modules. Like this, you can recover
53from certain errors by simply unloading and reloading the modules.
54
55
56
57What's it for? How to use it?
58=============================
59
60X.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
88To use the X.25 protocol on top of isdn, just create an isdn network
89interface as usual, configure your own and/or peer's ISDN numbers,
90and choose x25iface encapsulation by
91
92 isdnctrl encap <iface-name> x25iface.
93
94Once encap is set like this, the device can be used by the X.25 packet layer.
95
96All the stuff needed for X.25 is implemented inside the isdn link
97level (mainly isdn_net.c and some new source files). Thus, it should
98work with every existing HL driver. I was able to successfully open X.25
99connections on top of the isdnloop driver and the hisax driver.
100"x25iface"-encapsulation bypasses demand dialing. Dialing will be
101initiated when the upper (X.25 packet) layer requests the lapb datalink to
102be established. But hangup timeout is still active. Whenever a hangup
103occurs, all existing X.25 connections on that link will be cleared
104It is recommended to use sufficiently large hangup-timeouts for the
105isdn interfaces.
106
107
108In order to set up a conforming protocol stack you also need to
109specify the proper l2_prot parameter:
110
111To operate in ISO-8208 X.25 DTE-DTE mode, use
112
113 isdnctrl l2_prot <iface-name> x75i
114
115To access an X.25 network switch via isdn (your linux box is the DTE), use
116
117 isdnctrl l2_prot <iface-name> x25dte
118
119To mimic an X.25 network switch (DCE side of the connection), use
120
121 isdnctrl l2_prot <iface-name> x25dce
122
123However, x25dte or x25dce is currently not supported by any real HL
124level driver. The main difference between x75i and x25dte/dce is that
125x25d[tc]e uses fixed lap_b addresses. With x75i, the side which
126initiates the isdn connection uses the DTE's lap_b address while the
127called side used the DCE's lap_b address. Thus, l2_prot x75i might
128probably work if you access a public X.25 network as long as the
129corresponding isdn connection is set up by you. At least one test
130was successful to connect via isdn4linux to an X.25 switch using this
131trick. At the switch side, a terminal adapter X.21 was used to connect
132it to the isdn.
133
134
135How to set up a test installation?
136==================================
137
138To 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
150Before compiling the user level utilities make sure that the compiler/
151preprocessor will fetch the proper kernel header files of this kernel
152source tree. Either make /usr/include/linux a symbolic link pointing to
153this kernel's include/linux directory or set the appropriate compiler flags.
154
155When all drivers and interfaces are loaded and configured you need to
156ifconfig the network interfaces up and add X.25-routes to them. Use
157the usual ifconfig tool.
158
159ifconfig <iface-name> up
160
161But a special x25route tool (distributed with the x25-util package)
162is needed to set up X.25 routes. I.e.
163
164x25route add 01 <iface-name>
165
166will cause all x.25 connections to the destination X.25-address
167"01" to be routed to your created isdn network interface.
168
169There are currently no real X.25 applications available. However, for
170tests, the x25-utils package contains a modified version of telnet
171and telnetd that uses X.25 sockets instead of tcp/ip sockets. You can
172use those for your first tests. Furthermore, you might check
173ftp://ftp.hamburg.pop.de/pub/LOCAL/linux/i4l-eft/ which contains some
174alpha-test implementation ("eftp4linux") of the EUROfile transfer
175protocol.
176
177The scripts distributed with the eftp4linux test releases might also
178provide useful examples for setting up X.25 on top of isdn.
179
180The x25-utility package also contains an x25trace tool that can be
181used to monitor X.25 packets received by the network interfaces.
182The /proc/net/x25* files also contain useful information.
183
184- Henner
diff --git a/Documentation/isdn/syncPPP.FAQ b/Documentation/isdn/syncPPP.FAQ
deleted file mode 100644
index 3257a4bc0786..000000000000
--- a/Documentation/isdn/syncPPP.FAQ
+++ /dev/null
@@ -1,224 +0,0 @@
1simple isdn4linux PPP FAQ .. to be continued .. not 'debugged'
2-------------------------------------------------------------------
3
4Q01: what's pppd, ipppd, syncPPP, asyncPPP ??
5Q02: error message "this system lacks PPP support"
6Q03: strange information using 'ifconfig'
7Q04: MPPP?? What's that and how can I use it ...
8Q05: I tried MPPP but it doesn't work
9Q06: can I use asynchronous PPP encapsulation with network devices
10Q07: A SunISDN machine can't connect to my i4l system
11Q08: I wanna talk to several machines, which need different configs
12Q09: Starting the ipppd, I get only error messages from i4l
13Q10: I wanna use dynamic IP address assignment
14Q11: I can't connect. How can I check where the problem is.
15Q12: How can I reduce login delay?
16
17-------------------------------------------------------------------
18
19Q01: pppd, ipppd, syncPPP, asyncPPP .. what is that ?
20 what should I use?
21A: 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
47Q02: when I start the ipppd .. I only get the
48 error message "this system lacks PPP support"
49A: 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) ...
56A: Maybe you have compiled the ipppd with another
57 kernel source tree than the kernel you currently
58 run ...
59
60--
61
62Q03: 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
65A: The device is a fake ethernet device .. ignore IRQ and baseaddr
66 You need the HWaddr only for ethernet encapsulation.
67
68--
69
70Q04: MPPP?? What's that and how can I use it ...
71
72A: 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
93Q05: 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
98A: you forgot to compile MPPP/RFC1717 support into the
99 ISDN Subsystem. Recompile with this option enabled.
100
101--
102
103Q06: can I use asynchronous PPP encapsulation
104 over the network interface of isdn4linux ..
105
106A: 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
112Q07: 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
117A: 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
121A: (from Alexanter Strauss: )
122!![ ... fill in mail ]!!
123
124--
125
126Q08: 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
132A: 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
138Q09: When I start the ipppd I only get error messages
139 from the i4l driver ..
140
141A: 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
152Q10: I wanna use dynamic IP address assignment ... How
153 must I configure the network device.
154
155A: 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
169A: 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
184A: 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
193Q11: I can't connect. How can I check where the problem is.
194
195A: 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
215Q12: How can I reduce login delay?
216
217A: 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
generated by cgit v1.2.2 (git 2.25.0) at 2025-09-03 07:36:03 -0400