summaryrefslogtreecommitdiffstats
path: root/Documentation/isdn
diff options
context:
space:
mode:
authorRalf Baechle <ralf@linux-mips.org>1998-05-07 02:55:41 +0000
committerRalf Baechle <ralf@linux-mips.org>1998-05-07 02:55:41 +0000
commitdcec8a13bf565e47942a1751a9cec21bec5648fe (patch)
tree548b69625b18cc2e88c3e68d0923be546c9ebb03 /Documentation/isdn
parent2e0f55e79c49509b7ff70ff1a10e1e9e90a3dfd4 (diff)
o Merge with Linux 2.1.99.
o Fix ancient bug in the ELF loader making ldd crash. o Fix ancient bug in the keyboard code for SGI, SNI and Jazz.
Diffstat (limited to 'Documentation/isdn')
-rw-r--r--Documentation/isdn/00-INDEX10
-rw-r--r--Documentation/isdn/CREDITS19
-rw-r--r--Documentation/isdn/INTERFACE102
-rw-r--r--Documentation/isdn/README77
-rw-r--r--Documentation/isdn/README.HiSax275
-rw-r--r--Documentation/isdn/README.act2000104
-rw-r--r--Documentation/isdn/README.audio6
-rw-r--r--Documentation/isdn/README.avmb12
-rw-r--r--Documentation/isdn/README.concap258
-rw-r--r--Documentation/isdn/README.icn10
-rw-r--r--Documentation/isdn/README.pcbit14
-rw-r--r--Documentation/isdn/README.sc111
-rw-r--r--Documentation/isdn/README.x25217
-rw-r--r--Documentation/isdn/syncPPP.FAQ16
14 files changed, 1041 insertions, 180 deletions
diff --git a/Documentation/isdn/00-INDEX b/Documentation/isdn/00-INDEX
index 401697921..919af9057 100644
--- a/Documentation/isdn/00-INDEX
+++ b/Documentation/isdn/00-INDEX
@@ -19,4 +19,12 @@ README.syncppp
syncPPP.FAQ
- frequently asked questions about running PPP over ISDN.
README.avmb1
- - info on driver for AVM-B1 ISDN card
+ - info on driver for AVM-B1 ISDN card.
+README.act2000
+ - info on driver for IBM ACT-2000 card.
+README.concap
+ - info on "CONCAP" ecapsulation protocol interface used for X.25.
+README.sc
+ - info on driver for Spellcaster cards.
+README.x25
+ _ info for running X.25 over ISDN.
diff --git a/Documentation/isdn/CREDITS b/Documentation/isdn/CREDITS
index 44e6554a7..6fd4c9ed5 100644
--- a/Documentation/isdn/CREDITS
+++ b/Documentation/isdn/CREDITS
@@ -8,6 +8,9 @@ Thomas Bogendörfer (tsbogend@bigbug.franken.de)
Alan Cox (alan@cymru.net)
For help getting into standard-kernel.
+Henner Eisen (eis@baty.hanse.de)
+ For X.25 implementation.
+
Volker Götz (volker@oops.franken.de)
For contribution of man-pages, the imontty-tool and a perfect
maintaining of the mailing-list at hub-wue.
@@ -37,18 +40,24 @@ Pedro Roque Marques (roque@di.fc.ul.pt)
Eberhard Moenkeberg (emoenke@gwdg.de)
For testing and help to get into kernel.
+Thomas Neumann (tn@ruhr.de)
+ For help with Cisco-SLARP and keepalive
+
Jan den Ouden (denouden@groovin.xs4all.nl)
- For contribution of the teles-driver
+ For contribution of the original teles-driver
+
+Carsten Paeth (calle@calle.in-berlin.de)
+ For the AVM-B1-CAPI2.0 driver
+
+Thomas Pfeiffer (pfeiffer@pds.de)
+ For V.110, extended T.70 and Hylafax extensions in isdn_tty.c
Max Riegel (riegel@max.franken.de)
For making the ICN hardware-documentation and test-equipment available.
-Gerhard 'Fido' Schneider (fido@wuff.franken.de)
+Gerhard 'Fido' Schneider (fido@wuff.mayn.de)
For heavy-duty-beta-testing with his BBS ;)
Thomas Uhl (uhl@think.de)
For distributing the cards.
For pushing me to work ;-)
-
-Carsten Paeth (calle@calle.in-berlin.de)
- For the AVM-B1-CAPI2.0 driver
diff --git a/Documentation/isdn/INTERFACE b/Documentation/isdn/INTERFACE
index 81dddb081..cf938f67f 100644
--- a/Documentation/isdn/INTERFACE
+++ b/Documentation/isdn/INTERFACE
@@ -1,4 +1,4 @@
-$Id: INTERFACE,v 1.6 1997/02/10 22:40:57 fritz Exp $
+$Id: INTERFACE,v 1.8 1998/02/20 17:38:20 fritz Exp $
Description of the Interface between Linklevel and Hardwarelevel
of isdn4linux:
@@ -22,7 +22,7 @@ Description of the Interface between Linklevel and Hardwarelevel
got a separate version number. These numbers are shown at initialization,
separated by slashes:
- c.c/t.t/n.n/p.p/a.a
+ c.c/t.t/n.n/p.p/a.a/v.v
where
@@ -31,11 +31,13 @@ Description of the Interface between Linklevel and Hardwarelevel
n.n is the revision of the network related code.
p.p is the revision of the ppp related code.
a.a is the revision of the audio related code.
+ v.v is the revision of the V.110 related code.
Changes in this document are marked with '***CHANGEx' where x representing
the version number. If that number starts with 0, it refers to the old,
separately distributed package. If it starts with one of the letters
above, it refers to the revision of the corresponding module.
+ ***CHANGEIx refers to the revision number of the isdnif.h
1. Description of the fields of isdn_if:
@@ -51,7 +53,7 @@ Description of the Interface between Linklevel and Hardwarelevel
***CHANGE0.6: New since this version.
Also to be preset by the HL-driver. With this value the HL-driver
- tells to the LL the maximum size of a data-packet it will accept.
+ tells the LL the maximum size of a data-packet it will accept.
unsigned long features;
@@ -65,32 +67,16 @@ Description of the Interface between Linklevel and Hardwarelevel
unsigned short hl_hdrlen;
- ***CHANGED.7.4: New field.
+ ***CHANGE0.7.4: New field.
To be preset by the HL-driver, if it supports sk_buff's. The driver
- should put here the amount of additional space needed in sk-buff's for
- its internal purposes. Drivers not supporting sk_buff's should put
+ should put here the amount of additional space needed in sk_buff's for
+ its internal purposes. Drivers not supporting sk_buff's should
initialize this field to 0.
- void (*rcvcallb)(int, int, u_char*, int);
-
- ***CHANGEc1.14: Declared obsolete. Do NOT use this field/function
- anymore, since it will be removed when all current
- LL drivers have been changed accordingly. Use
- rcvcallb_skb instead.
-
- This field will be set by LL. The HL-driver delivers received data-
- packets by calling this function.
-
- Parameter:
- int driver-Id
- int Channel-number locally to the driver. (starting with 0)
- u_char Pointer to received data. (in kernel-space)
- int length of data-packet.
-
void (*rcvcallb_skb)(int, int, struct sk_buff *)
- ***CHANGED.7.4: New field.
+ ***CHANGE0.7.4: New field.
This field will be set by LL. The HL-driver delivers received data-
packets by calling this function. Upon calling, the HL-driver must
@@ -138,41 +124,22 @@ Description of the Interface between Linklevel and Hardwarelevel
Returnvalue:
>=0 on success, else error-code (-ENODEV etc.)
- int (*writebuf)(int, int, u_char*, int, int);
+ int (*writebuf_skb)(int, int, int, struct sk_buff *)
- ***CHANGED1.14: Declared obsolete. Do NOT use this field/function
- anymore, since it will be removed when all current
- LL drivers have been changed accordingly. Set this
- field to NULL and use writebuf_skb instead.
-
- This field has to be preset by the HL-driver. The given function will
- be called by the LL for delivering data to be send via B-Channel.
-
- Parameter:
- int driver-Id ***CHANGE.7.4: New parameter.
- int channel-number locally to the HL-driver. (starts with 0)
- u_char* pointer to data.
- int length of data-packet.
- int flag: 0 = call from within kernel-space. (HL-driver must use
- memcpy, may NOT use schedule())
- 1 = call from user-space. (HL-driver must use
- memcpy_fromfs, use of schedule() allowed)
-
- Returnvalue:
- Length of data accepted on success, else error-code (-EINVAL on
- oversized packets etc.)
-
- int (*writebuf_skb)(int, int, struct sk_buff *)
-
- ***CHANGED.7.4: New field.
+ ***CHANGE0.7.4: New field.
+ ***CHANGEI.1.21: New field.
This field has to be preset by the HL-driver. The given function will
be called by the LL for delivering data to be send via B-Channel.
Parameter:
- int driver-Id ***CHANGE.7.4: New parameter.
+ int driver-Id ***CHANGE0.7.4: New parameter.
int channel-number locally to the HL-driver. (starts with 0)
+ int ack ***ChangeI1.21: New parameter
+ If this is !0, the driver has to signal the delivery
+ by sending an ISDN_STAT_BSENT. If this is 0, the driver
+ MUST NOT send an ISDN_STAT_BSENT.
struct sk_buff * Pointer to sk_buff containing data to be send via
B-channel.
@@ -199,7 +166,7 @@ Description of the Interface between Linklevel and Hardwarelevel
int driver-Id.
int channel-number locally to the HL-driver. (starts with 0)
-***CHANGED1.14: The driver-Id and channel-number are new since this revision.
+***CHANGEI1.14: The driver-Id and channel-number are new since this revision.
Returnvalue:
Length of data accepted on success, else error-code (-EINVAL etc.)
@@ -223,7 +190,7 @@ Description of the Interface between Linklevel and Hardwarelevel
int driver-Id.
int channel-number locally to the HL-driver. (starts with 0)
-***CHANGED1.14: The driver-Id and channel-number are new since this revision.
+***CHANGEI1.14: The driver-Id and channel-number are new since this revision.
Returnvalue:
Length of data on success, else error-code (-EINVAL etc.)
@@ -244,12 +211,12 @@ Description of the Interface between Linklevel and Hardwarelevel
All commands will be performed by calling the function command() described
above from within the LL. The field command of the struct-parameter will
- contain the desired command, the field driver always is set to the
+ contain the desired command, the field driver is always set to the
appropriate driver-Id.
Until now, the following commands are defined:
-***CHANGED1.34: The parameter "num" has been replaced by a union "para" containing
+***CHANGEI1.34: The parameter "num" has been replaced by a union "para" containing
the old "num" and a new setup_type struct used for ISDN_CMD_DIAL
and ISDN_STAT_ICALL callback.
@@ -469,7 +436,7 @@ Description of the Interface between Linklevel and Hardwarelevel
arg = unused.
para = unused.
-3. Description of the events to be signaled by the HL-driver to th LL.
+3. Description of the events to be signaled by the HL-driver to the LL.
All status-changes are signaled via calling the previously described
function statcallb(). The field command of the struct isdn_cmd has
@@ -552,6 +519,9 @@ Description of the Interface between Linklevel and Hardwarelevel
a B-Channel-connection. (Response to ISDN_CMD_ACCEPTB or because the
remote-station has initiated establishment)
+ The HL driver should call this when the logical l2/l3 protocol
+ connection on top of the physical B-channel is established.
+
Parameter:
driver = driver-Id
command = ISDN_STAT_BCONN
@@ -577,6 +547,9 @@ Description of the Interface between Linklevel and Hardwarelevel
B-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP,
or caused by a remote-hangup.
+ The HL driver should call this as soon as the logical l2/l3 protocol
+ connection on top of the physical B-channel is released.
+
Parameter:
driver = driver-Id
command = ISDN_STAT_BHUP
@@ -617,7 +590,9 @@ Description of the Interface between Linklevel and Hardwarelevel
driver = driver-Id
command = ISDN_STAT_BSENT
arg = channel-number, locally to the driver. (starting with 0)
- para = unused.
+ para.length = ***CHANGEI.1.21: New field.
+ the driver has to set this to the original length
+ of the skb at the time of receiving it from the linklevel.
ISDN_STAT_NODCH:
@@ -649,7 +624,7 @@ Description of the Interface between Linklevel and Hardwarelevel
With this call, the HL-driver delivers CAUSE-messages to the LL.
Currently the LL does not use this messages. Their contents is simply
logged via kernel-messages. Therefore, currently the format of the
- messages is currently completely free. However they should be printable.
+ messages is completely free. However they should be printable.
Parameter:
driver = driver-Id
@@ -657,3 +632,16 @@ Description of the Interface between Linklevel and Hardwarelevel
arg = channel-number, locally to the driver. (starting with 0)
para.num = ASCII string containing CAUSE-message.
+ ISDN_STAT_L1ERR:
+
+ ***CHANGEI1.21 new status message.
+ A signal can be sent to the linklevel if an Layer1-error results in
+ packet-loss on receive or send. The field errcode of the cmd.parm
+ union describes the error more precisely.
+
+ Parameter:
+ driver = driver-Id
+ command = ISDN_STAT_L1ERR
+ arg = channel-number, locally to the driver. (starting with 0)
+ para.errcode= ISDN_STAT_L1ERR_SEND: Packet lost while sending.
+ ISDN_STAT_L1ERR_RECV: Packet lost while receiving.
diff --git a/Documentation/isdn/README b/Documentation/isdn/README
index 48dec2d83..cfe4beae4 100644
--- a/Documentation/isdn/README
+++ b/Documentation/isdn/README
@@ -62,7 +62,7 @@ README for the ISDN-subsystem
read: raw D-channel-messages (format: depends on driver).
ioctl: depends on driver, i.e. for the ICN-driver, the base-address of
the ports and the shared memory on the card can be set and read
- also the boot-code an the protocol software can be loaded into
+ also the boot-code and the protocol software can be loaded into
the card.
O N L Y !!! for debugging (no locking against other devices):
@@ -74,7 +74,7 @@ README for the ISDN-subsystem
128 tty-devices (64 cuix and 64 ttyIx) with integrated modem-emulator:
The functionality is almost the same as that of a serial device
- (the line-discs are handled by the kernel, which lets you run
+ (the line-discs are handled by the kernel), which lets you run
SLIP, CSLIP and asynchronous PPP through the devices. We have tested
Seyon, minicom, CSLIP (uri-dip) PPP and mgetty (compiled with NO_FAX),
XCept.
@@ -96,7 +96,7 @@ README for the ISDN-subsystem
ATI Return "ISDN for Linux...".
ATI0 "
ATI1 "
- ATI2 Report of last connection.
+ ATI2 Report of last connection.
ATO On line (data mode).
ATQ0 Enable result codes (default).
ATQ1 Disable result codes (default).
@@ -107,9 +107,9 @@ README for the ISDN-subsystem
ATZ Load registers and EAZ/MSN from Profile.
AT&Bx Set Send-Packet-size to x (max. 4000)
The real packet-size may be limited by the
- low-level-driver used. i.e.: the HiSax-Module-
+ low-level-driver used. e.g. the HiSax-Module-
limit is 2000. You will get NO Error-Message,
- if you set it to higher Values, because at the
+ if you set it to higher values, because at the
time of giving this command the corresponding
driver may not be selected (see "Automatic
Assignment") however the size of outgoing packets
@@ -120,12 +120,35 @@ README for the ISDN-subsystem
AT&D3 Same as AT&D2 but also resets all registers.
AT&Ex Set the EAZ/MSN for this channel to x.
AT&F Reset all registers and profile to "factory-defaults"
+ AT&Rx Select V.110 bitrate adaption.
+ This command enables V.110 protocol with 9600 baud
+ (x=9600), 19200 baud (x=19200) or 38400 baud
+ (x=38400). A value of x=0 disables V.110 switching
+ back to default X.75. This command sets the following
+ Registers:
+ Reg 14 (Layer-2 protocol):
+ x = 0: 0
+ x = 9600: 7
+ x = 19200: 8
+ x = 38400: 9
+ Reg 18.2 = 1
+ Reg 19 (Additional Service Indicator):
+ x = 0: 0
+ x = 9600: 197
+ x = 19200: 199
+ x = 38400: 198
+ Note on value in Reg 19:
+ There is _NO_ common convention for 38400 baud.
+ The value 198 is choosen arbitrarily. Users
+ _MUST_ negotiate this value before establishing
+ a connection.
AT&Sx Set window-size (x = 1..8) (not yet implemented)
AT&V Show all settings.
AT&W0 Write registers and EAZ/MSN to profile. See also
iprofd (5.c in this README).
- AT&X0 BTX-mode off (default)
- AT&X1 BTX-mode on. (S13.1=1, S14=0, S16=7, S18=7, S19=0)
+ AT&X0 BTX-mode and T.70-mode off (default)
+ AT&X1 BTX-mode on. (S13.1=1, S13.5=0 S14=0, S16=7, S18=7, S19=0)
+ AT&X2 T.70-mode on. (S13.1=1, S13.5=1, S14=0, S16=7, S18=7, S19=0)
For voice-mode commands refer to README.audio
@@ -184,12 +207,23 @@ README for the ISDN-subsystem
1 = Extended response messages
Bit 4: 0 = CALLER NUMBER before every RING.
1 = CALLER NUMBER after first RING.
+ Bit 5: 0 = T.70 extended protocol off
+ 1 = T.70 extended protocol on
+ Bit 6: 0 = Special RUNG Message off
+ 1 = Special RUNG Message on
+ "RUNG" is delivered on a ttyI, if
+ an incoming call happened (RING) and
+ the remote party hung up before any
+ local ATA was given.
14 0 Layer-2 protocol:
0 = X75/LAPB with I-frames
1 = X75/LAPB with UI-frames
2 = X75/LAPB with BUI-frames
3 = HDLC
4 = Transparent (audio)
+ 7 = V.110, 9600 baud
+ 8 = V.110, 19200 baud
+ 9 = V.110, 38400 baud
15 0 Layer-3 protocol: (at the moment always 0)
0 = transparent
16 250 Send-Packet-size/16
@@ -211,7 +245,7 @@ README for the ISDN-subsystem
19 0 Service-Octet-2
20 0 Bit coded register (readonly)
Service-Octet-1 of last call.
- Bit mapping is the same like register 18
+ Bit mapping is the same as register 18
21 0 Bit coded register (readonly)
Set on incoming call (during RING) to
octet 3 of calling party number IE (Numbering plan)
@@ -229,17 +263,17 @@ README for the ISDN-subsystem
All inactive physical lines are listening to all EAZs for incoming
calls and are NOT assigned to a specific tty or network interface.
When an incoming call is detected, the driver looks first for a network
- interfaces and then for an opened tty which:
+ interface and then for an opened tty which:
1. is configured for the same EAZ.
2. has the same protocol settings for the B-channel.
3. (only for network interfaces if the security flag is set)
contains the caller number in its access list.
4. Either the channel is not bound exclusively to another Net-interface, or
- it is bound AND the other checks apply to exact this Interface.
+ it is bound AND the other checks apply to exactly this Interface.
(For usage of the bind-features, refer to the isdnctrl-man-page)
- Only when a matching interface or tty is found, the call is accepted
+ Only when a matching interface or tty is found is the call accepted
and the "connection" between the low-level-layer and the link-level-layer
is established and kept until the end of the connection.
In all other cases no connection is established. Isdn4linux can be
@@ -275,7 +309,7 @@ README for the ISDN-subsystem
4. Device-inodes
- The major and minor-numbers and its names are described in
+ The major and minor numbers and their names are described in
Documentation/devices.txt. The major-numbers are:
43 for the ISDN-tty's.
@@ -323,7 +357,7 @@ README for the ISDN-subsystem
i) Setup the interface with ifconfig as usual, and set a route to it.
- j) (optional) If you run X11 and have Tcl/Tk-wish Version4.0, you can use
+ j) (optional) If you run X11 and have Tcl/Tk-wish Version 4.0, you can use
the script tools/tcltk/isdnmon. You can add actions for line-status
changes. See the comments at the beginning of the script for how to
do that. There are other tty-based tools in the tools-subdirectory
@@ -365,7 +399,7 @@ README for the ISDN-subsystem
"isdnctrl secure <InterfaceName> off"
- Switch of secure operation (default).
+ Switch off secure operation (default).
"isdnctrl ihup <InterfaceName> [on|off]"
Switch the hang-up-timer for incoming calls on or off.
@@ -400,12 +434,15 @@ README for the ISDN-subsystem
Selects the type of packet-encapsulation. The encapsulation can be changed
only while an interface is down.
- At the moment th following Values are supported:
+ At the moment the following values are supported:
rawip (Default) Selects raw-IP-encapsulation. This means, MAC-headers
are stripped off.
ip IP with type-field. Same as IP but the type-field of the MAC-header
is preserved.
+ x25iface X.25 interface encapsulation (first byte semantics as defined in
+ ../networking/x25-iface.txt). Use this for running the linux
+ X.25 network protocol stack (AF_X25 sockets) on top of isdn.
cisco-h A special-mode for communicating with a Cisco, which is configured
to do "hdlc"
ethernet No stripping. Packets are sent with full MAC-header.
@@ -415,6 +452,11 @@ README for the ISDN-subsystem
uihdlc HDLC with UI-frame-header (for use with DOS ISPA, option -h1)
+
+ NOTE: x25iface encapsulation is currently experimental. Please
+ read README.x25 for further details
+
+
Watching packets, using standard-tcpdump will fail for all encapsulations
except ethernet because tcpdump does not know how to handle packets
without MAC-header. A patch for tcpdump is included in the utility-package
@@ -423,7 +465,8 @@ README for the ISDN-subsystem
"isdnctrl l2_prot <InterfaceName> <L2-ProtocolName>"
Selects a layer-2-protocol.
(With the ICN-driver and the HiSax-driver, "x75i" and "hdlc" is available.
- With other drivers, "x75ui", "x75bui" may be possible too.)
+ With other drivers, "x75ui", "x75bui", "x25dte", "x25dce" may be
+ possible too. See README.x25 for x25 related l2 protocols.)
isdnctrl l3_prot <InterfaceName> <L3-ProtocolName>
The same for layer-3. (At the moment only "trans" is allowed)
@@ -440,7 +483,7 @@ README for the ISDN-subsystem
dial out using a specific Card or even preserve a specific Channel for
Dialout of a specific net-interface. This can be done with the above
command. Replace <DriverId> by whatever you assigned while loading the
- module. The <ChannelNumber> is counting from zero. the upper Limit
+ module. The <ChannelNumber> is counting from zero. The upper Limit
depends on the card used. At the Moment no card supports more than
2 Channels, so the upper limit is one.
diff --git a/Documentation/isdn/README.HiSax b/Documentation/isdn/README.HiSax
index 20b578d83..4b49e0939 100644
--- a/Documentation/isdn/README.HiSax
+++ b/Documentation/isdn/README.HiSax
@@ -23,24 +23,39 @@ Supported cards
---------------
Teles 8.0/16.0/16.3 and compatible ones
+Teles 16.3c
Teles S0/PCMCIA
Creatix PnP S0
-AVM A1 (Fritz)
+Compaq ISDN S0 ISA card
+AVM A1 (Fritz, Teledat 150)
ELSA Microlink PCC-16, PCF, PCF-Pro, PCC-8
ELSA Quickstep 1000
+ELSA Quickstep 1000PCI
+ELSA Quickstep 3000 (same settings as QS1000)
ELSA PCMCIA
ITK ix1-micro Rev.2
+Eicon.Diehl Diva 2.0 ISA and PCI (S0 and U interface, no PRO version)
+Eicon.Diehl Diva Piccola
+ASUSCOM NETWORK INC. ISDNLink 128K PC adapter (order code I-IN100-ST-D)
+Dynalink IS64PH (OEM version of ASUSCOM NETWORK INC. ISDNLink 128K adapter)
+HFC-2BS0 based cards (TeleInt SA1)
+Sedlbauer Speed Card (Speed Win, Teledat 100)
+Sedlbauer Speed Star (PCMCIA)
+USR Sportster internal TA (compatible Stollmann tina-pp V3)
+ith Kommunikationstechnik GmbH MIC 16 ISA card
+Traverse Technologie NETjet PCI S0 card
+Dr. Neuhaus Niccy PnP/PCI
Note: PCF, PCF-Pro: up to now, only the ISDN part is supported
PCC-8: not tested yet
Teles PCMCIA is EXPERIMENTAL
+ Teles 16.3c is EXPERIMENTAL
+ Eicon.Diehl Diva U interface not tested
If you know other passive cards with the Siemens chipset, please let me know.
To use the PNP cards you need the isapnptools.
You can combine any card, if there is no conflict between the ressources
-(io, mem, irq), with one exception: The ELSA PCMCIA cannot work with an other
-non PCMCIA ELSA card at the same time. You cannot select ELSA ISA and ELSA
-PCMCIA support at the same time during kernel config.
+(io, mem, irq).
Configuring the driver
@@ -51,7 +66,7 @@ It can be configured using the command line feature while loading the kernel
with LILO or LOADLIN or, if built as a module, using insmod/modprobe with
parameters.
There is also some config needed before you compile the kernel and/or
-modules. It is enclose in the normal "make [menu]config" target at the
+modules. It is included in the normal "make [menu]config" target at the
kernel. Don't forget it, especially to select the right D-channel protocol.
Please note: All PnP cards need to be configured with isapnp and will work
@@ -113,15 +128,31 @@ Card types:
6 ELSA PCC/PCF cards io or nothing for autodetect (the iobase is
required only if you have more than one ELSA
card in your PC)
- 7 ELSA Quickstep 1000 irq, io (from isapnp setup)
- 7 ELSA PCMCIA irq, io (set with card manager)
+ 7 ELSA Quickstep 1000 irq, io (from isapnp setup)
8 Teles 16.3 PCMCIA irq, io
9 ITK ix1-micro Rev.2 irq, io
+ 10 ELSA PCMCIA irq, io (set with card manager)
+ 11 Eicon.Diehl Diva ISA PnP irq, io
+ 11 Eicon.Diehl Diva PCI no parameter
+ 12 ASUS COM ISDNLink irq, io (from isapnp setup)
+ 13 HFC-2BS0 based cards irq, io
+ 14 Teles 16.3c PnP irq, io
+ 15 Sedlbauer Speed Card irq, io
+ 16 USR Sportster internal irq, io
+ 17 MIC card irq, io
+ 18 ELSA Quickstep 1000PCI no parameter
+ 19 Compaq ISDN S0 ISA card irq, io0, io1, io (from isapnp setup io=IO2)
+ 20 NETjet PCI card no parameter
+ 22 Sedlbauer Speed Star (PCMCIA) irq, io (set with card manager)
+ 24 Dr. Neuhaus Niccy PnP irq, io0, io1 (from isapnp setup)
+ 24 Dr. Neuhaus Niccy PCI no parameter
+
+
At the moment IRQ sharing is not possible. Please make sure that your IRQ
is free and enabled for ISA use.
Note: For using the ELSA PCMCIA you need the cardmanager under MSDOS for
-enabling in the moment, then boot linux with loadlin.
+enabling at the moment, then boot linux with loadlin.
Examples for module loading
@@ -181,17 +212,28 @@ where
Card types:
type
- 1 Teles 16.0 pa=irq pb=membase pc=iobase
- 2 Teles 8.0 pa=irq pb=membase
- 3 Teles 16.3 pa=irq pb=iobase
+ 1 Teles 16.0 pa=irq pb=membase pc=iobase
+ 2 Teles 8.0 pa=irq pb=membase
+ 3 Teles 16.3 pa=irq pb=iobase
4 Creatix/Teles PNP ONLY WORKS AS A MODULE !
- 5 AVM A1 (Fritz) pa=irq pb=iobase
+ 5 AVM A1 (Fritz) pa=irq pb=iobase
6 ELSA PCC/PCF cards pa=iobase or nothing for autodetect
- 7 ELSA Quickstep 1000 ONLY WORKS AS A MODULE !
- 7 ELSA PCMCIA irq, io (set with card manager)
- 8 Teles S0 PCMCIA pa=irq pb=iobase
+ 7 ELSA Quickstep 1000 ONLY WORKS AS A MODULE !
+ 8 Teles S0 PCMCIA pa=irq pb=iobase
9 ITK ix1-micro Rev.2 pa=irq pb=iobase
-
+ 10 ELSA PCMCIA pa=irq, pb=io (set with card manager)
+ 11 Eicon.Diehl Diva ISAPnP ONLY WORKS AS A MODULE !
+ 11 Eicon.Diehl Diva PCI no parameter
+ 12 ASUS COM ISDNLink ONLY WORKS AS A MODULE !
+ 13 HFC-2BS0 based cards pa=irq pb=io
+ 14 Teles 16.3c PnP ONLY WORKS AS A MODULE !
+ 15 Sedlbauer Speed Card pa=irq pb=io (Speed Win only as module !)
+ 16 USR Sportster internal pa=irq pb=io
+ 17 MIC card pa=irq pb=io
+ 18 ELSA Quickstep 1000PCI no parameter
+ 19 Compaq ISDN S0 ISA card ONLY WORKS AS A MODULE !
+ 20 NETjet PCI card no parameter
+ 21 Sedlbauer Speed Star (PCMCIA) pa=irq, pb=io (set with card manager)
Running the driver
------------------
@@ -215,8 +257,8 @@ Apr 13 21:01:59 kke01 kernel: HiSax: DSS1 Rev. 1.14
Apr 13 21:01:59 kke01 kernel: HiSax: 2 channels added
This means that the card is ready for use.
-Cabling problems or line-downs are not detected, and only ELSA cards can detect
-the S0 power.
+Cabling problems or line-downs are not detected, and only some ELSA cards can
+detect the S0 power.
Remember that, according to the new strategy for accessing low-level drivers
from within isdn4linux, you should also define a driver ID while doing
@@ -226,11 +268,11 @@ string MUST NOT start with a digit or a small 'x'!
At this point you can run a 'cat /dev/isdnctrl0' and view debugging
messages.
-At the moment, debugging messages are enabled with the telesctrl tool:
+At the moment, debugging messages are enabled with the hisaxctrl tool:
- telesctrl <DriverId> DebugCmd <debugging_flags>
+ hisaxctrl <DriverId> DebugCmd <debugging_flags>
-<DriverId> default is HiSax, if you didn't specified one.
+<DriverId> default is HiSax, if you didn't specify one.
DebugCmd is 1 for generic debugging
11 for layer 1 development debugging
@@ -267,11 +309,18 @@ With DebugCmd set to 11:
With DebugCmd set to 13:
1 Warnings (default: on)
- 2 l3 protocol discriptor errors
+ 2 l3 protocol descriptor errors
4 l3 state machine
8 charge info debugging (1TR6)
-For example, 'telesctrl HiSax 1 0x3ff' enables full generic debugging.
+For example, 'hisaxctrl HiSax 1 0x3ff' enables full generic debugging.
+
+Because of some obscure problems with some switch equipment, the delay
+between the CONNECT message and sending the first data on the B-channel is now
+configurable with
+
+hisaxctrl <DriverId> 2 <delay>
+<delay> in ms Value between 50 and 800 ms is recommended.
Warning
@@ -284,7 +333,7 @@ illegal.
Limitations
-----------
At this time, HiSax only works on Euro ISDN lines and German 1TR6 lines.
-
+For leased lines see appendix.
Bugs
----
@@ -301,10 +350,20 @@ Special thanks to:
Andreas Kool, Pekka Sarnila, Sim Yskes, Johan Myrre'en,
Klaus-Peter Nischke (ITK AG), Christof Petig, Werner Fehn (ELSA GmbH),
Volker Schmidt
+ Edgar Toernig and Marcus Niemann for the Sedlbauer driver
+ Stephan von Krawczynski
+ Juergen Quade for the Leased Line part
+ Klaus Lichtenwalder (Klaus.Lichtenwalder@WebForum.DE), for ELSA PCMCIA support
and more people who are hunting bugs. (If I forgot somebody, please
send me a mail).
Firma ELSA GmbH
+ Firma Eicon.Diehl GmbH
+ Firma Dynalink NL
+ Firma ASUSCOM NETWORK INC. Taiwan
+ Firma S.u.S.E
+ Firma ith Kommunikationstechnik GmbH
+ Firma Traverse Technologie Australia
My girl friend and partner in life Ute for her patience with me.
@@ -321,3 +380,171 @@ Appendix: Teles PCMCIA driver
See
http://www.stud.uni-wuppertal.de/~ea0141/pcmcia.html
for instructions.
+
+Appendix: Linux and ISDN-leased lines
+-------------------------------------
+
+Original from Juergen Quade, new version KKe.
+
+Attention NEW VERSION, the old leased line syntax won't work !!!
+
+You can use HiSax to connect your Linux-Box via an ISDN leased line
+to e.g. the Internet:
+
+1. Build a kernel which includes the HiSax driver either as a module
+ or as part of the kernel.
+ cd /usr/src/linux
+ make menuconfig
+ <ISDN subsystem - ISDN support -- HiSax>
+ make clean; make dep; make zImage; make modules; make modules_install
+2. Install the new kernel
+ cp /usr/src/linux/arch/i386/boot/zImage /etc/kernel/linux.isdn
+ vi /etc/lilo.conf
+ <add new kernel in the bootable image section>
+ lilo
+3. in case the hisax driver is a "fixed" part of the kernel, configure
+ the driver with lilo:
+ vi /etc/lilo.conf
+ <add HiSax driver parameter in the global section (see below)>
+ lilo
+ Your lilo.conf _might_ look like the following:
+
+ # LILO configuration-file
+ # global section
+ # teles 16.0 on IRQ=5, MEM=0xd8000, PORT=0xd80
+ append="hisax=1,3,5,0xd8000,0xd80,HiSax"
+ # teles 16.3 (non pnp) on IRQ=15, PORT=0xd80
+ # append="hisax=3,3,5,0xd8000,0xd80,HiSax"
+ boot=/dev/sda
+ compact # faster, but won't work on all systems.
+ linear
+ read-only
+ prompt
+ timeout=100
+ vga = normal # force sane state
+ # Linux bootable partition config begins
+ image = /etc/kernel/linux.isdn
+ root = /dev/sda1
+ label = linux.isdn
+ #
+ image = /etc/kernel/linux-2.0.30
+ root = /dev/sda1
+ label = linux.secure
+
+ In the line starting with "append" you have to adapt the parameters
+ according to your card (see above in this file)
+
+3. boot the new linux.isdn kernel
+4. start the ISDN subsystem:
+ a) load - if necessary - the modules (depends, whether you compiled
+ the ISDN driver as module or not)
+ According to the type of card you have to specify the necessary
+ driver parameter (irq, io, mem, type, protocol).
+ For the leased line the protocol is "3". See the table above for
+ the parameters, which you have to specify depending on your card.
+ b) configure i4l
+ /sbin/isdnctrl addif isdn0
+ # EAZ 1 -- B1 channel 2 --B2 channel
+ /sbin/isdnctrl eaz isdn0 1
+ /sbin/isdnctrl secure isdn0 on
+ /sbin/isdnctrl huptimeout isdn0 0
+ /sbin/isdnctrl l2_prot isdn0 hdlc
+ # Attention you must not set an outgoing number !!! This won't work !!!
+ # The incomming number is LEASED0 for the first card, LEASED1 for the
+ # second and so on.
+ /sbin/isdnctrl addphone isdn0 in LEASED0
+ # Here is no need to bind the channel.
+ c) in case the remote partner is a CISCO:
+ /sbin/isdnctrl encap isdn0 cisco-h
+ d) configure the interface
+ /sbin/ifconfig isdn0 ${LOCAL_IP} pointopoint ${REMOTE_IP}
+ e) set the routes
+ /sbin/route add -host ${REMOTE_IP} isdn0
+ /sbin/route add default gw ${REMOTE_IP}
+ f) switch the card into leased mode for each used B-channel
+ /sbin/hisaxctrl HiSax 5 1
+
+Remarks:
+a) If you have a CISCO don't forget to switch off the KEEP ALIVE option!
+
+Here an example script:
+#!/bin/sh
+# Start/Stop ISDN lesaed line connection
+
+I4L_AS_MODULE=yes
+I4L_REMOTE_IS_CISCO=no
+I4L_MODULE_PARAMS="type=16 io=0x268 irq=7 "
+I4L_DEBUG=no
+I4L_LEASED_128K=yes
+LOCAL_IP=192.168.1.1
+REMOTE_IP=192.168.2.1
+
+case "$1" in
+ start)
+ echo "Starting ISDN ..."
+ if [ ${I4L_AS_MODULE} = "yes" ]; then
+ echo "loading modules..."
+ /sbin/modprobe hisax ${I4L_MODULE_PARAMS}
+ fi
+ # configure interface
+ /sbin/isdnctrl addif isdn0
+ /sbin/isdnctrl secure isdn0 on
+ if [ ${I4L_DEBUG} = "yes" ]; then
+ /sbin/isdnctrl verbose 7
+ /sbin/hisaxctrl HiSax 1 0xffff
+ /sbin/hisaxctrl HiSax 11 0xff
+ cat /dev/isdnctrl >/tmp/lea.log &
+ fi
+ if [ ${I4L_REMOTE_IS_CISCO} = "yes" ]; then
+ /sbin/isdnctrl encap isdn0 cisco-h
+ fi
+ /sbin/isdnctrl huptimeout isdn0 0
+ # B-CHANNEL 1
+ /sbin/isdnctrl eaz isdn0 1
+ /sbin/isdnctrl l2_prot isdn0 hdlc
+ # 1. card
+ /sbin/isdnctrl addphone isdn0 in LEASED0
+ if [ ${I4L_LEASED_128K} = "yes" ]; then
+ /sbin/isdnctrl addslave isdn0 isdn0s
+ /sbin/isdnctrl secure isdn0s on
+ /sbin/isdnctrl huptimeout isdn0s 0
+ # B-CHANNEL 2
+ /sbin/isdnctrl eaz isdn0s 2
+ /sbin/isdnctrl l2_prot isdn0s hdlc
+ # 1. card
+ /sbin/isdnctrl addphone isdn0s in LEASED0
+ if [ ${I4L_REMOTE_IS_CISCO} = "yes" ]; then
+ /sbin/isdnctrl encap isdn0s cisco-h
+ fi
+ fi
+ # configure tcp/ip
+ /sbin/ifconfig isdn0 ${LOCAL_IP} pointopoint ${REMOTE_IP}
+ /sbin/route add -host ${REMOTE_IP} isdn0
+ /sbin/route add default gw ${REMOTE_IP}
+ # switch to leased mode
+ # B-CHANNEL 1
+ /sbin/hisaxctrl HiSax 5 1
+ if [ ${I4L_LEASED_128K} = "yes" ]; then
+ # B-CHANNEL 2
+ /sbin/hisaxctrl HiSax 5 2
+ fi
+ ;;
+ stop)
+ /sbin/ifconfig isdn0 down
+ /sbin/isdnctrl delif isdn0
+ if [ ${I4L_DEBUG} = "yes" ]; then
+ killall cat
+ fi
+ if [ ${I4L_AS_MODULE} = "yes" ]; then
+ /sbin/rmmod hisax
+ /sbin/rmmod isdn
+ /sbin/rmmod ppp
+ /sbin/rmmod slhc
+ fi
+ ;;
+ *)
+ echo "Usage: $0 {start|stop}"
+ exit 1
+esac
+exit 0
+
diff --git a/Documentation/isdn/README.act2000 b/Documentation/isdn/README.act2000
new file mode 100644
index 000000000..155095db1
--- /dev/null
+++ b/Documentation/isdn/README.act2000
@@ -0,0 +1,104 @@
+$Id: README.act2000,v 1.1 1997/09/24 23:50:16 fritz Exp $
+
+This document describes the ACT2000 driver for the
+IBM Active 2000 ISDN card.
+
+There are 3 Types of this card available. A ISA-, MCA-, and PCMCIA-Bus
+Version. Currently, only the ISA-Bus version of the card is supported.
+However MCA and PCMCIA will follow soon.
+
+The ISA-Bus Version uses 8 IO-ports. The base port adress has to be set
+manually using the DIP switches.
+
+Setting up the DIP switches for the IBM Active 2000 ISDN card:
+
+ Note: S5 and S6 always set off!
+
+ S1 S2 S3 S4 Base-port
+ on on on on 0x0200 (Factory default)
+ off on on on 0x0240
+ on off on on 0x0280
+ off off on on 0x02c0
+ on on off on 0x0300
+ off on off on 0x0340
+ on off off on 0x0380
+ on on on off 0xcfe0
+ off on on off 0xcfa0
+ on off on off 0xcf60
+ off off on off 0xcf20
+ on on off off 0xcee0
+ off on off off 0xcea0
+ on off off off 0xce60
+ off off off off Card disabled
+
+IRQ is configured by software. Possible values are:
+
+ 3, 5, 7, 10, 11, 12, 15 and none (polled mode)
+
+
+The ACT2000 driver may either be built into the kernel or as a module.
+Initialization depends on how the driver is built:
+
+Driver built into the kernel:
+
+ The ACT2000 driver can be configured using the commandline-feature while
+ loading the kernel with LILO or LOADLIN. It accepts the following syntax:
+
+ act2000=b,p,i[,idstring]
+
+ where
+
+ b = Bus-Type (1=ISA, 2=MCA, 3=PCMCIA)
+ p = portbase (-1 means autoprobe)
+ i = Interrupt (-1 means use next free IRQ, 0 means polled mode)
+
+ The idstring is an arbitrary string used for referencing the card
+ by the actctrl tool later.
+
+ Defaults used, when no parameters given at all:
+
+ 1,-1,-1,""
+
+ which means: Autoprobe for an ISA card, use next free IRQ, let the
+ ISDN linklevel fill the IdString (usually "line0" for the first card).
+
+ If you like to use more than one card, you can use the program
+ "actctrl" from the utility-package to configure additional cards.
+
+ Using the "actctrl"-utility, portbase and irq can also be changed
+ during runtime. The D-channel protocol is configured by the "dproto"
+ option of the "actctrl"-utility after loading the firmware into the
+ card's memory using the "actctrl"-utility.
+
+Driver built as module:
+
+ The module act2000.o can be configured during modprobe (insmod) by
+ appending its parameters to the modprobe resp. insmod commandline.
+ The following syntax is accepted:
+
+ act_bus=b act_port=p act_irq=i act_id=idstring
+
+ where b, p, i and idstring have the same meanings as the parameters
+ described for the builtin version above.
+
+ Using the "actctrl"-utility, the same features apply to the modularized
+ version as to the kernel-builtin one. (i.e. loading of firmware and
+ configuring the D-channel protocol)
+
+Loading the firmware into the card:
+
+ The firmware is supplied together with the isdn4k-utils package. It
+ can be found in the subdirectory act2000/firmware/
+
+ Assuming you have installed the utility-package correctly, the firmware
+ will be downloaded into the card using the following command:
+
+ actctrl -d idstring load /etc/isdn/bip11.btl
+
+ where idstring is the Name of the card, given during insmod-time or
+ (for kernel-builtin driver) on the kernel commandline. If only one
+ ISDN card is used, the -d isdstrin may be omitted.
+
+ For further documentation (adding more IBM Active 2000 cards), refer to
+ the manpage actctrl.8 which is included in the isdn4k-utils package.
+
diff --git a/Documentation/isdn/README.audio b/Documentation/isdn/README.audio
index c01a116bc..d7b845162 100644
--- a/Documentation/isdn/README.audio
+++ b/Documentation/isdn/README.audio
@@ -22,7 +22,7 @@ Commands for enabling/disabling audio mode:
Commands supported in audio mode:
-All audio mode commands have the one of the following form:
+All audio mode commands have one of the following forms:
AT+Vxx? Show current setting.
AT+Vxx=? Show possible settings.
@@ -89,8 +89,8 @@ General behavior and description of data formats/protocol.
<DLE><ETX> End of audio data. (i.e. caused by a
hangup of the remote side) Emulator stops
recording, responding with VCON.
- <DLE><DC4> Abort recording, (send by appl.) Emulator
- stops recording, sends DLE,ETX.
+ <DLE><DC4> Abort recording, (send by appl.) Emulator
+ stops recording, sends DLE,ETX.
<DLE><DLE> Escape sequence for DLE in data stream.
<DLE>0 Touchtone "0" received.
...
diff --git a/Documentation/isdn/README.avmb1 b/Documentation/isdn/README.avmb1
index 68bdf0985..342532786 100644
--- a/Documentation/isdn/README.avmb1
+++ b/Documentation/isdn/README.avmb1
@@ -26,7 +26,7 @@ To use the card you need the t4-files to download the firmware.
AVM GmbH provides several t4-files for the different D-channel
protocols (b1.t4 for Euro-ISDN). Install these file in /lib/isdn.
-If you not compile the driver as modules, you have to add the
+If you do not compile the driver as modules, you have to add the
card(s) and load them after booting:
avmcapictrl add 0x150 15
diff --git a/Documentation/isdn/README.concap b/Documentation/isdn/README.concap
new file mode 100644
index 000000000..1e46096ca
--- /dev/null
+++ b/Documentation/isdn/README.concap
@@ -0,0 +1,258 @@
+Description of the "concap" encapsulation protocol interface
+============================================================
+
+The "concap" interface is intended to be used by network device
+drivers that need to process an encapsulation protocol.
+It is assumed that the protocol interacts with a linux network device by
+- data transmission
+- connection control (establish, release)
+Thus, the mnemonic: "CONnection CONtrolling eNCAPsulation Protocol".
+
+This is currently only used inside the isdn subsystem. But it might
+also be useful to other kinds of network devices. Thus, if you want
+to suggest changes that improve usability or performance of the
+interface, please let me know. I'm willing to include them in future
+releases (even if I needed to adapt the current isdn code to the
+changed interface).
+
+
+Why is this useful?
+===================
+
+The encapsulation protocol used on top of WAN connections or permanent
+point-to-point links are frequently chosen upon bilateral agreement.
+Thus, a device driver for a certain type of hardware must support
+several different encapsulation protocols at once.
+
+The isdn device driver did already support several different
+encapsulation protocols. The encapsulation protocol is configured by a
+user space utility (isdnctrl). The isdn network interface code then
+uses several case statements which select appropriate actions
+depending on the currently configured encapsulation protocol.
+
+In contrast, LAN network interfaces always used a single encapsulation
+protocol which is unique to the hardware type of the interface. The LAN
+encapsulation is usually done by just sticking a header on the data. Thus,
+traditional linux network device drivers used to process the
+encapsulation protocol directly (usually by just providing a hard_header()
+method in the device structure) using some hardware type specific support
+functions. This is simple, direct and efficient. But it doesn't fit all
+the requirements for complex WAN encapsulations.
+
+
+ The configurability of the encapsulation protocol to be used
+ makes isdn network interfaces more flexible, but also much more
+ complex than traditional lan network interfaces.
+
+
+Many Encapsulation protocols used on top of WAN connections will not just
+stick a header on the data. They also might need to set up or release
+the WAN connection. They also might want to send other data for their
+private purpose over the wire, e.g. ppp does a lot of link level
+negotiation before the first piece of user data can be transmitted.
+Such encapsulation protocols for WAN devices are typically more complex
+than encapsulation protocols for lan devices. Thus, network interface
+code for typical WAN devices also tends to be more complex.
+
+
+In order to support Linux' x25 PLP implementation on top of
+isdn network interfaces I could have introduced yet another branch to
+the various case statements inside drivers/isdn/isdn_net.c.
+This eventually made isdn_net.c even more complex. In addition, it made
+isdn_net.c harder to maintain. Thus, by identifying an abstract
+interface between the network interface code and the encapsulation
+protocol, complexity could be reduced and maintainability could be
+increased.
+
+
+Likewise, a similar encapsulation protocol will frequently be needed by
+several different interfaces of even different hardware type, e.g. the
+synchronous ppp implementation used by the isdn driver and the
+asyncronous ppp implementation used by the ppp driver have a lot of
+similar code in them. By cleanly separating the encapsulation protocol
+from the hardware specific interface stuff such code could be shared
+better in future.
+
+
+When operating over dial-up-connections (e.g. telephone lines via modem,
+non-permanent virtual circuits of wide area networks, ISDN) many
+encapsulation protocols will need to control the connection. Therefore,
+some basic connection control primitives are supported. The type and
+semantics of the connection (i.e the ISO layer where connection service
+is provided) is outside our scope and might be different depending on
+the encapsulation protocol used, e.g. for a ppp module using our service
+on top of a modem connection a connect_request will result in dialing
+a (somewhere else configured) remote phone number. For an X25-interface
+module (LAPB semantics, as defined in Documentation/networking/x25-iface.txt)
+a connect_request will ask for establishing a reliable lapb
+datalink connection.
+
+
+The encapsulation protocol currently provides the following
+service primitives to the network device.
+
+- create a new encapsulation protocol instance
+- delete encapsulation protocol instance and free all its resources
+- initialize (open) the encapsulation protocol instance for use.
+- deactivate (close) an encapsulation protocol instance.
+- process (xmit) data handed down by upper protocol layer
+- receive data from lower (hardware) layer
+- process connect indication from lower (hardware) layer
+- process disconnect indication from lower (hardware) layer
+
+
+The network interface driver accesses those primitives via callbacks
+provided by the encapsulation protocol instance within a
+struct concap_proto_ops.
+
+struct concap_proto_ops{
+
+ /* create a new encapsulation protocol instance of same type */
+ struct concap_proto * (*proto_new) (void);
+
+ /* delete encapsulation protocol instance and free all its resources.
+ cprot may no loger be referenced after calling this */
+ void (*proto_del)(struct concap_proto *cprot);
+
+ /* initialize the protocol's data. To be called at interface startup
+ or when the device driver resets the interface. All services of the
+ encapsulation protocol may be used after this*/
+ int (*restart)(struct concap_proto *cprot,
+ struct device *ndev,
+ struct concap_device_ops *dops);
+
+ /* deactivate an encapsulation protocol instance. The encapsulation
+ protocol may not call any *dops methods after this. */
+ int (*close)(struct concap_proto *cprot);
+
+ /* process a frame handed down to us by upper layer */
+ int (*encap_and_xmit)(struct concap_proto *cprot, struct sk_buff *skb);
+
+ /* to be called for each data entity received from lower layer*/
+ int (*data_ind)(struct concap_proto *cprot, struct sk_buff *skb);
+
+ /* to be called when a connection was set up/down.
+ Protocols that don't process these primitives might fill in
+ dummy methods here */
+ int (*connect_ind)(struct concap_proto *cprot);
+ int (*disconn_ind)(struct concap_proto *cprot);
+};
+
+
+The data structures are defined in the header file include/linux/concap.h.
+
+
+A Network interface using encapsulation protocols must also provide
+some service primitives to the encapsulation protocol:
+
+- request data being submitted by lower layer (device hardware)
+- request a connection being set up by lower layer
+- request a connection being released by lower layer
+
+The encapsulation protocol accesses those primitives via callbacks
+provided by the network interface within a struct concap_device_ops.
+
+struct concap_device_ops{
+
+ /* to request data be submitted by device */
+ int (*data_req)(struct concap_proto *, struct sk_buff *);
+
+ /* Control methods must be set to NULL by devices which do not
+ support connection control. */
+ /* to request a connection be set up */
+ int (*connect_req)(struct concap_proto *);
+
+ /* to request a connection be released */
+ int (*disconn_req)(struct concap_proto *);
+};
+
+The network interface does not explicitly provide a receive service
+because the encapsulation protocol directly calls netif_rx().
+
+
+
+
+An encapsulation protocol itself is actually the
+struct concap_proto{
+ struct device *net_dev; /* net device using our service */
+ struct concap_device_ops *dops; /* callbacks provided by device */
+ struct concap_proto_ops *pops; /* callbacks provided by us */
+ int flags;
+ void *proto_data; /* protocol specific private data, to
+ be accessed via *pops methods only*/
+ /*
+ :
+ whatever
+ :
+ */
+};
+
+Most of this is filled in when the device requests the protocol to
+be reset (opend). The network interface must provide the net_dev and
+dops pointers. Other concap_proto members should be considered private
+data that are only accessed by the pops callback functions. Likewise,
+a concap proto should access the network device's private data
+only by means of the callbacks referred to by the dops pointer.
+
+
+A possible extended device structure which uses the connection controlling
+encapsulation services could look like this:
+
+struct concap_device{
+ struct device net_dev;
+ struct my_priv /* device->local stuff */
+ /* the my_priv struct might contain a
+ struct concap_device_ops *dops;
+ to provide the device specific callbacks
+ */
+ struct concap_proto *cprot; /* callbacks provided by protocol */
+};
+
+
+
+Misc Thoughts
+=============
+
+The concept of the concap proto might help to reuse protocol code and
+reduce the complexity of certain network interface implementations.
+The trade off is that it introduces yet another procedure call layer
+when processing the protocol. This has of course some impact on
+performance. However, typically the concap interface will be used by
+devices attached to slow lines (like telephone, isdn, leased synchronous
+lines). For such slow lines, the overhead is probably negligible.
+This might no longer hold for certain high speed WAN links (like
+ATM).
+
+
+If general linux network interfaces explicitly supported concap
+protocols (e.g. by a member struct concap_proto* in struct device)
+then the interface of the service function could be changed
+by passing a pointer of type (struct device*) instead of
+type (struct concap_proto*). Doing so would make many of the service
+functions compatible to network device support fuctions.
+
+e.g. instead of the concap protocol's service function
+
+ int (*encap_and_xmit)(struct concap_proto *cprot, struct sk_buff *skb);
+
+we could have
+
+ int (*encap_and_xmit)(struct device *ndev, struct sk_buff *skb);
+
+As this is compatible to the dev->hard_start_xmit() method, the device
+driver could directly register the concap protocol's encap_and_xmit()
+fuction as its hard_start_xmit() method. This would eliminate one
+procedure call layer.
+
+
+The device's data request function could also be defined as
+
+ int (*data_req)(struct device *ndev, struct sk_buff *skb);
+
+This might even allow for some protocol stacking. And the network
+interface might even register the same data_req() function directly
+as its hard_start_xmit() method when a zero layer encapsulation
+protocol is configured. Thus, eliminating the performance penalty
+of the concap interface when a trivial concap protocol is used.
+Nevertheless, the device remains able to support encapsulation
+protocol configuration.
diff --git a/Documentation/isdn/README.icn b/Documentation/isdn/README.icn
index cb8908d58..155e87457 100644
--- a/Documentation/isdn/README.icn
+++ b/Documentation/isdn/README.icn
@@ -62,8 +62,8 @@ Setting up the IO-address dipswitches for the ICN-ISDN-card:
1 1 1 0 0x368
1 1 1 1 NOT ALLOWED!
-The ICN driver either may be build into kernel or as a module. Initialization
-depends on how the drive is built:
+The ICN driver may be built into the kernel or as a module. Initialization
+depends on how the driver is built:
Driver built into the kernel:
@@ -102,7 +102,7 @@ Driver built as module:
portbase=p membase=m icn_id=idstring [icn_id2=idstring2]
- where p, m, idstring1 and idstring2 have the same meanings like
+ where p, m, idstring1 and idstring2 have the same meanings as the
parameters described for the kernel-version above.
When using the ICN double card (4B), you MUST define TWO idstrings.
@@ -127,12 +127,12 @@ Loading the firmware into the card:
pc_1t_ca.bin - Image of firmware for german 1TR6 protocol.
pc_eu_ca.bin - Image if firmware for EDSS1 (Euro-ISDN) protocol.
- Assumed you have installed the utility-package correctly, the firmware
+ Assuming you have installed the utility-package correctly, the firmware
will be downloaded into the 2B-card using the following command:
icnctrl -d Idstring load /etc/isdn/loadpg.bin /etc/isdn/pc_XX_ca.bin
- where XX is either "1t" or "eu", depending of the D-Channel protocol
+ where XX is either "1t" or "eu", depending on the D-Channel protocol
used on your S0-bus and Idstring is the Name of the card, given during
insmod-time or (for kernel-builtin driver) on the kernel commandline.
diff --git a/Documentation/isdn/README.pcbit b/Documentation/isdn/README.pcbit
index e93562b2c..fb696422f 100644
--- a/Documentation/isdn/README.pcbit
+++ b/Documentation/isdn/README.pcbit
@@ -16,20 +16,20 @@ ftp://ftp.di.fc.ul.pt/pub/systems/Linux/isdn
Known Limitations:
-- The board reset proceeding is at the moment incorrect and will only
+- The board reset procedure is at the moment incorrect and will only
allow you to load the firmware after a hard reset.
-- Only HDLC in B-channels is supported at the moment. There is now
-current support to X.25 in B or D channels nor LAPD in B
-channels. The main reason is that this two other protocol modes have,
+- Only HDLC in B-channels is supported at the moment. There is no
+current support for X.25 in B or D channels nor LAPD in B
+channels. The main reason is that these two other protocol modes have,
to my knowledge, very little use. If you want to see them implemented
*do* send me a mail.
-- The driver often triggers errors in the board that i and the
+- The driver often triggers errors in the board that I and the
manufacturer believe to be caused by bugs in the firmware. The current
-version includes several proceedings for error recovery that should
+version includes several procedures for error recovery that should
allow normal operation. Plans for the future include cooperation with
-the manufacturer in order to solve this problems.
+the manufacturer in order to solve this problem.
Information/hints/help can be obtained in the linux isdn
mailing list (isdn4linux@hub-wue.franken.de) or directly from me.
diff --git a/Documentation/isdn/README.sc b/Documentation/isdn/README.sc
index 0ea8ca165..b70db7a63 100644
--- a/Documentation/isdn/README.sc
+++ b/Documentation/isdn/README.sc
@@ -9,7 +9,7 @@ Speaking of guarantees, THIS IS BETA SOFTWARE and as such contains
bugs and defects either known or unknown. Use this software at your own
risk. There is NO SUPPORT for this software. Some help may be available
through the web site or the mailing list but such support is totally at
-our own option and without warrantee. If you choose to assume all and
+our own option and without warranty. If you choose to assume all and
total risk by using this driver, we encourage you to join the beta
mailing list.
@@ -17,7 +17,7 @@ To join the Linux beta mailing list, send a message to:
majordomo@spellcast.com with the words "subscribe linux-beta" as the only
contents of the message. Do not include a signature. If you choose to
remove yourself from this list at a later date, send another message to
-the same address with the words "unsubscribe linux-beta" as it's only
+the same address with the words "unsubscribe linux-beta" as its only
contents.
TABLE OF CONTENTS
@@ -42,7 +42,7 @@ TABLE OF CONTENTS
---------------
The revision 2 Linux driver for SpellCaster ISA ISDN adapters is built
-upon ISDN4Linux available seperately or as included in Linux 2.0 and later.
+upon ISDN4Linux available separately or as included in Linux 2.0 and later.
The driver will support a maximum of 4 adapters in any one system of any
type including DataCommute/BRI, DataCommute/PRI and TeleCommute/BRI for a
maximum of 92 channels for host. The driver is supplied as a module in
@@ -74,14 +74,14 @@ include:
allow us to utilize all of the available RAM on the adapter through
only one 16K page.
- Better detection of available upper memory. The probing routines
- have been improved to better detect avaialble shared RAM pages and
+ have been improved to better detect available shared RAM pages and
used pages are now locked.
- Decreased loading time and a wider range of I/O ports probed.
We have significantly reduced the amount of time it takes to load
the driver and at the same time doubled the number of I/O ports
- probed increasing the likelyhood of finding an adapter.
+ probed increasing the likelihood of finding an adapter.
- We now support all ISA adapter models with a single driver instead
- of seperate drivers for each model. The revision 2 driver supports
+ of separate drivers for each model. The revision 2 driver supports
the DataCommute/BRI, DataCommute/PRI and TeleCommute/BRI in any
combination up to a maximum of four adapters per system.
- On board PPP protocol support has been removed in favour of the
@@ -115,7 +115,7 @@ must ensure that the following software is installed, configuraed and running:
2.1 Unpacking and installing the driver
- 1. As root, create a directory in a convienient place. We suggest
+ 1. As root, create a directory in a convenient place. We suggest
/usr/src/spellcaster.
2. Unpack the archive with :
@@ -170,36 +170,38 @@ reserved for ISA use only.
2.6 How to setup ISDN4Linux with the driver
-There are two main configurations which you can use with the driver:
+There are three main configurations which you can use with the driver:
A) Basic HDLC connection
B) PPP connection
C) MLPPP connection
-It should be mentioned here that you may also use a tty connection if you desire.
-The Documentation directory of the isdn4linux subsystem offers a good documentation
-on this feature.
+It should be mentioned here that you may also use a tty connection if you
+desire. The Documentation directory of the isdn4linux subsystem offers good
+documentation on this feature.
A) 10 steps to the establishment of a basic HDLC connection
-----------------------------------------------------------
- please open the isdn-hdlc file in the examples directory and follow along...
- This file is a script used to configure a BRI ISDN TA to establish a basic HDLC
- connection between its two channels. There two network interfaces which are
- created and two routes added between the channels.
+ This file is a script used to configure a BRI ISDN TA to establish a
+ basic HDLC connection between its two channels. Two network
+ interfaces are created and two routes added between the channels.
- i) using the isdnctrl utitity, add an interface with "addif" and name it "isdn0"
+ i) using the isdnctrl utitity, add an interface with "addif" and
+ name it "isdn0"
ii) add the outgoing and inbound telephone numbers
iii) set the Layer 2 protocol to hdlc
- iv) set the eaz of the interface to be the phone number of that specific channel
+ iv) set the eaz of the interface to be the phone number of that
+ specific channel
v) to turn the callback features off, set the callback to "off" and
the callback delay (cbdelay) to 0.
vi) the hangup timeout can be set to a specified number of seconds
- vii) the hangup upon incomming call can be set on or off
- viii) use the ifconfig command to bring-up the network interface with a specific
- IP address and point to point address
- viv) add a route to the IP address through the isdn0 interface
+ vii) the hangup upon incoming call can be set on or off
+ viii) use the ifconfig command to bring up the network interface with
+ a specific IP address and point to point address
+ ix) add a route to the IP address through the isdn0 interface
x) a ping should result in the establishment of the connection
@@ -208,13 +210,15 @@ B) Establishment of a PPP connection
- please open the isdn-ppp file in the examples directory and follow along...
- This file is a script used to configure a BRI ISDN TA to establish a PPP connection
- between the two channels. The file is almost identical to the HDLC connection
- example except that the packet ecapsulation type has to be set.
+ This file is a script used to configure a BRI ISDN TA to establish a
+ PPP connection between the two channels. The file is almost
+ identical to the HDLC connection example except that the packet
+ ecapsulation type has to be set.
- use the same procedure as in the HDLC connection from steps i) to iii) then,
- after the Layer 2 protocol is set, set the encapsulation "encap" to syncppp.
- With this done, the rest of the steps, iv) to x) can be followed from above.
+ use the same procedure as in the HDLC connection from steps i) to
+ iii) then, after the Layer 2 protocol is set, set the encapsulation
+ "encap" to syncppp. With this done, the rest of the steps, iv) to x)
+ can be followed from above.
Then, the ipppd (ippp daemon) must be setup:
@@ -223,52 +227,55 @@ B) Establishment of a PPP connection
xiii) set the mru size to 2000
xiv) link the two /dev interfaces to the daemon
-NOTE: A "*" in the inbound telephone number specifies that a call can be accepted
- on any number.
+NOTE: A "*" in the inbound telephone number specifies that a call can be
+accepted on any number.
C) Establishment of a MLPPP connection
--------------------------------------
- please open the isdn-mppp file in the examples directory and follow along...
- This file is a script used to configure a BRI ISDN TA to accept a Multi Link PPP
- connection.
+ This file is a script used to configure a BRI ISDN TA to accept a
+ Multi Link PPP connection.
- i) using the isdnctrl utitity, add an interface with "addif" and name it "ippp0"
+ i) using the isdnctrl utitity, add an interface with "addif" and
+ name it "ippp0"
ii) add the inbound telephone number
- iii) set the Layer 2 protocol to hdlc and the Layer 3 protocol to trans (transparent)
+ iii) set the Layer 2 protocol to hdlc and the Layer 3 protocol to
+ trans (transparent)
iv) set the packet encapsulation to syncppp
- v) set the eaz of the interface to be the phone number of that specific channel
- vi) to turn the callback features off, set the callback to "off" and
+ v) set the eaz of the interface to be the phone number of that
+ specific channel
+ vi) to turn the callback features off, set the callback to "off" and
the callback delay (cbdelay) to 0.
vi) the hangup timeout can be set to a specified number of seconds
- vii) the hangup upon incomming call can be set on or off
+ vii) the hangup upon incoming call can be set on or off
viii) add a slave interface and name it "ippp32" for example
- viv) set the similar parameters for the ippp32 interface
- x) use the ifconfig command to bring-up the ippp0 interface with a specific
- IP address and point to point address
+ ix) set the similar parameters for the ippp32 interface
+ x) use the ifconfig command to bring-up the ippp0 interface with a
+ specific IP address and point to point address
xi) add a route to the IP address through the ippp0 interface
xii) use the ipppd function found in /sbin/ipppd to set the following:
xiii) take out (minus) bsd compression
xiv) set the mru size to 2000
xv) add (+) the multi-link function "+mp"
- xv) link the two /dev interfaces to the daemon
+ xvi) link the two /dev interfaces to the daemon
-NOTE: To use the MLPPP connection to dial OUT to a MLPPP connection, change the
- inbound telephone numbers to the outgoing telephone numbers of the MLPPP
- host.
+NOTE: To use the MLPPP connection to dial OUT to a MLPPP connection, change
+the inbound telephone numbers to the outgoing telephone numbers of the MLPPP
+host.
3. Beta Change Summaries and Miscellaneous Notes
------------------------------------------------
-When using the "scctrl" utility to upload firmware revisions on the board, please
-note that the byte count displayed at the end of the operation may be different
-than the total number of bytes in the "dcbfwn.nn.sr" file. Please disregard the
-displayed byte count.
-
-It was noted that in Beta Release 1, the module would fail to load and result in a
-segmentation fault when insmod"ed". This problem was created when one of the
-isdn4linux parameters, (isdn_ctrl, data field) was filled in. In some cases, this
-data field was NULL, and was left unchecked, so when it was referenced.. segv.
-The bug has been fixed around line 63-68 of event.c.
+When using the "scctrl" utility to upload firmware revisions on the board,
+please note that the byte count displayed at the end of the operation may be
+different from the total number of bytes in the "dcbfwn.nn.sr" file. Please
+disregard the displayed byte count.
+
+It was noted that in Beta Release 1, the module would fail to load and result
+in a segmentation fault when 'insmod'ed. This problem was created when one of
+the isdn4linux parameters, (isdn_ctrl, data field) was filled in. In some
+cases, this data field was NULL, and was left unchecked, so when it was
+referenced... segv. The bug has been fixed around line 63-68 of event.c.
diff --git a/Documentation/isdn/README.x25 b/Documentation/isdn/README.x25
new file mode 100644
index 000000000..cc1b70120
--- /dev/null
+++ b/Documentation/isdn/README.x25
@@ -0,0 +1,217 @@
+
+X25 support within isdn4linux
+
+
+This is experimental code and should be used with linux version 2.1.72.
+or later. Use it completely at your own risk.
+
+
+As new versions appear, the stuff described here might suddenly change
+or become invalid without notice.
+
+Keep in mind:
+
+You are using an experimental kernel (2.1.x series) with an experimental
+x25 protocol implementation and experimental x25-on-top-of-isdn extensions.
+Thus, be prepared to face problems related therefrom.
+
+- If you connect to an x25 neighbour not operated by yourself, ASK the
+ other side first. Be prepared that bugs in the protocol implementation
+ might result in problems (even crashing the peer, however such ugly events
+ should only happen if your peer's protocol implementation has serious bugs).
+
+- This implementation has never wiped out my whole hard disk yet. But as
+ this is experimental code, don't blame me if that happened to you. Take
+ appropriate actions (such as backing up important data) before
+ trying this code.
+
+- Monitor your isdn connections while using this software. This should
+ prevent you from undesired phone bills in case of driver problems.
+
+
+
+
+How to configure the kernel
+
+
+The ITU-T (former CCITT) X.25 network protocol layer has been implemented
+in the Linux source tree since version 2.1.16. The isdn subsystem might be
+useful to run X.25 on top of ISDN. If you want to try it, select
+
+ "CCITT X.25 Packet Layer"
+
+from the networking options as well as
+
+ "ISDN Support" and "X.25 PLP on Top of ISDN"
+
+from the ISDN subsystem options when you configure your kernel for
+compilation. You currently also need to enable
+"Prompt for development and/or incomplete code/drivers" from the
+"Code maturity level options" menu. For the x25trace utility to work
+you also need to enable "Packet socket" (I recommend to choose "y",
+not "m" for testing) from the networking options.
+
+
+For testing you should also select the isdnloop driver from the
+isdn subsystem's configuration menu.
+
+
+
+What's it for? How to use it?
+
+
+X25 on top of isdn might be useful with two different scenarios:
+
+- You might want to access a public X.25 data network from your Linux box.
+ You can use i4l if you were physically connected to the X.25 switch
+ by an ISDN line (leased line as well as dial up connection should work,
+ but connecting to x.25 network switches is currently untested. Testing
+ needs to be done by somebody with access to such a switch.)
+
+- Or you might want to operate certain ISDN teleservices on
+ your linux box. A lot of those teleservices run on top of the ISO-8208
+ network layer protocol. ISO-8208 is essentially the same as ITU-T X.25.
+
+ Popular candidates of such teleservices are EUROFILE transfer or any
+ teleservice applying ITU-T recommendation T.90 (i.e., AFAIK, G4 Fax).
+
+To use the X.25 protocol on top of isdn, just create an isdn network
+interface as usual, configure your own and/or peer's ISDN numbers,
+and choose x25iface encapsulation by
+
+ isdnctrl encap <iface-name> x25iface.
+
+Once encap is set like this, the device can be used by the x25 packet layer.
+
+All the stuff needed for x25 is implemented inside the isdn link
+level (mainly isdn_net.c and some new source files). Thus, it should
+work with every existing HL driver. I was able to successfully open x25
+connections on top of the isdnloop driver and the hisax driver.
+"x25iface"-encapsulation bypasses demand dialing. Dialing will be
+initiated when the upper (x25 packet) layer requests the lapb datalink to
+be established. But hangup timeout is still active. The connection
+will not automatically be re-established by the isdn_net module
+itself when new data arrives after the hangup timeout. But
+the x25 network code will re-establish the datalink connection
+(resulting in re-dialing and an x25 protocol reset) when new data is
+to be transmitted. (This currently does not work properly with the
+isdnloop driver, see "known problems" below)
+
+
+In order to set up a conforming protocol stack you also need to
+specify the proper l2_prot parameter:
+
+To operate in ISO-8208 X.25 DTE-DTE mode, use
+
+ isdnctrl l2_prot <iface-name> x75i
+
+To access an X.25 network switch via isdn (your linux box is the DTE), use
+
+ isdnctrl l2_prot <iface-name> x25dte
+
+To mimic an X.25 network switch (DCE side of the connection), use
+
+ isdnctrl l2_prot <iface-name> x25dce
+
+However, x25dte or x25dce is currently not supported by any real HL
+level driver. The main difference between x75 and x25dte/dce is that
+x25d[tc]e uses fixed lap_b addresses. With x75i, the side which
+initiates the isdn connection uses the DTE's lap_b address while the
+called side used the DCE's lap_b address. Thus, l2_prot x75i will
+probably work if you access a public x25 network as long as the
+corresponding isdn connection is set up by you. However, I've never
+tested this.
+
+
+
+How to use the test installation?
+
+
+To test x25 on top of isdn, you need to get
+
+- a patched version of the "isdnctrl" program that supports setting the new
+ x25 specific parameters.
+
+- the x25-utils-2.1.x package from ftp.pspt.fi/pub/ham/linux/ax25
+ or any mirror site (i.e. ftp://ftp.gwdg.de/pub/linux/misc/ax25/).
+
+- a kernel patch that enhances isdn4linux to provide x25 network
+ interface support. (This file is part of that kernel patch).
+
+- an application that uses linux AF_X25 sockets program.
+
+Before compiling the user level utilities make sure that the compiler/
+preprocessor will fetch the proper (patched) kernel header files. Either make
+/usr/include/linux a symbolic link pointing to your developer kernel's
+include/linux directory or set the appropriate compiler flags.
+
+It is recommended that all isdn drivers and the x25 PLP protocol
+are compiled as loadable modules. Like this, you can recover
+from certain errors by simply unloading and reloading the modules.
+
+When all drivers and interfaces are loaded and configured you need to
+ifconfig the network interfaces up and add x25-routes to them. Use
+the usual ifconfig tool.
+
+ifconfig <iface-name> up
+
+But a special x25route tool (distributed with the x25-util package)
+is needed to set up x25 routes. I.e.
+
+x25route add 01 <iface-name>
+
+will cause all x.25 connections to the destination x.25-address
+"01" to be routed to your created isdn network interface.
+
+
+There are currently no real x25 applications available. However, for
+tests, the x25-utils package contains a modified version of telnet
+and telnetd that uses x25 sockets instead of tcp/ip sockets. Use
+this for your first tests. Furthermore, there is an x25.echod and a client
+named "eftp" (which contains some experimental code to download files
+from a remote eft server using the EUROfile transfer protocol).
+It available at ftp://ftp.hamburg.pop.de/pub/LOCAL/linux/i4l-eft/eftp4linux-*
+
+The x25-utility package also contains an x25trace tool that can be
+used to monitor x25 packets received by the network interfaces.
+The /proc/net/x25* files also contain useful information.
+
+The eftp4linux test release also contains an "ix25test" script that can
+be used for testing x25 on top of isdn4linux. Edit
+this script according to your local needs and then call it as
+
+ix25test start
+
+This will set up a sample configuration using the isdnloop and hisax
+driver and create some isdn network interfaces.
+It is recommended that all other isdn drivers and the
+x25 module are unloaded before calling this script.
+
+
+
+Known problems and deficiencies:
+
+The isdnloop HL driver apparently has problems to re-establish a
+connection that has been hung up from the outgoing device. You have to
+unload the isdnloop driver after the faked isdn-connection is closed
+and insmod it again. With the Hisax driver, this problem is not present.
+
+Sometimes the x25 module cannot be unloaded (decrementation of its use
+count seems to get lost occasionally).
+
+Using the x25 based telnet and telnetd programm to establish connection
+from your own to your own computer repeatedly sometimes totally locked
+up my system. However, this kernel patch also modifies
+net/x25/af_x25.c to include a workaround. With this workaround
+enabled, my system is stable. (If you want to disable the
+workaround, just undefine ISDN_X25_FIXES in af_x25.c).
+
+The latter problem could be reproduced by using hisax as well as the
+isdnloop driver. It seems that it is not caused by the isdn code.
+Somehow, the inode of a socket is freed while a process still refers
+the socket's wait queue. This causes problems when the process tries to
+remove itself from the wait queue (refered by the dangling
+sock->sleep pointer) before returning from a select() system call.
+
+- Henner
+
diff --git a/Documentation/isdn/syncPPP.FAQ b/Documentation/isdn/syncPPP.FAQ
index 6813818e0..3257a4bc0 100644
--- a/Documentation/isdn/syncPPP.FAQ
+++ b/Documentation/isdn/syncPPP.FAQ
@@ -1,8 +1,8 @@
simple isdn4linux PPP FAQ .. to be continued .. not 'debugged'
-------------------------------------------------------------------
-Q01: what's pppd,ipppd, syncPPP , asyncPPP ??
-Q02: error message "this systems lacks PPP support"
+Q01: what's pppd, ipppd, syncPPP, asyncPPP ??
+Q02: error message "this system lacks PPP support"
Q03: strange information using 'ifconfig'
Q04: MPPP?? What's that and how can I use it ...
Q05: I tried MPPP but it doesn't work
@@ -16,7 +16,7 @@ Q12: How can I reduce login delay?
-------------------------------------------------------------------
-Q01: pppd,ipppd, syncPPP , asyncPPP .. what is that ?
+Q01: pppd, ipppd, syncPPP, asyncPPP .. what is that ?
what should I use?
A: The pppd is for asynchronous PPP .. asynchronous means
here, the framing is character based. (e.g when
@@ -45,7 +45,7 @@ A: The pppd is for asynchronous PPP .. asynchronous means
--
Q02: when I start the ipppd .. I only get the
- error message "this systems lacks PPP support"
+ error message "this system lacks PPP support"
A: check that at least the device 'ippp0' exists.
(you can check this e.g with the program 'ifconfig')
The ipppd NEEDS this device under THIS name ..
@@ -123,7 +123,7 @@ A: (from Alexanter Strauss: )
--
-Q08: A wanna talk to remote machines, which need
+Q08: I wanna talk to remote machines, which need
a different configuration. The only way
I found to do this is to kill the ipppd and
start a new one with another config to connect
@@ -152,14 +152,14 @@ A: When starting, the ipppd calls functions which may
Q10: I wanna use dynamic IP address assignment ... How
must I configure the network device.
-A: At least you must have a routing, which forwards
+A: At least you must have a route which forwards
a packet to the ippp network-interface to trigger
the dial-on-demand.
- A default routing to the ippp-interface will work.
+ A default route to the ippp-interface will work.
Now you must choose a dummy IP address for your
interface.
If for some reason you can't set the default
- routing to the ippp interface, you may take any
+ route to the ippp interface, you may take any
address of the subnet from which you expect your
dynamic IP number and set a 'network route' for
this subnet to the ippp interface.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 22:37:50 +0000