retronetworking
/
isdn4linux
13
0
Fork 0
Code Pull Requests Releases Activity

Merged pre-2.1.99-2 Documentation/isdn changes (spelling errors) 

Minor README.x25 changes.
This commit is contained in:
Henner Eisen 1998-04-29 19:49:10 +00:00
parent 975e78f1fe
commit fc13108ff9
11 changed files with 119 additions and 119 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
Documentation/isdn/INTERFACE
View File

@ -53,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;
@ -70,8 +70,8 @@ Description of the Interface between Linklevel and Hardwarelevel
***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_skb)(int, int, struct sk_buff *)
@ -211,7 +211,7 @@ 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:
@ -436,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
@ -520,7 +520,7 @@ Description of the Interface between Linklevel and Hardwarelevel
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 esatblished .
connection on top of the physical B-channel is established.
Parameter:
driver = driver-Id
@ -624,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

32
Documentation/isdn/README
View File

@ -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
@ -245,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)
@ -263,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
@ -309,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.
@ -357,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
@ -399,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.
@ -434,15 +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 x25 interface encapsulation (first byte semantics as defined in
x25iface X.25 interface encapsulation (first byte semantics as defined in
../networking/x25-iface.txt). Use this for running the linux
x25 network protocol stack (AF_X25 sockets) on top of isdn.
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.
@ -483,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.

20
Documentation/isdn/README.HiSax
View File

@ -72,7 +72,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
@ -159,7 +159,7 @@ Card types:
At the moment IRQ sharing is only possible with PCI cards. 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
@ -283,7 +283,7 @@ At the moment, debugging messages are enabled with the hisaxctrl tool:
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
@ -320,18 +320,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, 'hisaxctrl HiSax 1 0x3ff' enables full generic debugging.
Because of some obscure problems with some switch equipment, the delay
between CONNECT message and sending the first data on th B-channel is now
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 an 800 ms are recommended.
<delay> in ms Value between 50 and 800 ms is recommended.
Warning
@ -402,7 +402,7 @@ 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 i.e. the internet:
to e.g. the Internet:
1. Build a kernel which includes the HiSax driver either as a module
or as part of the kernel.
@ -420,7 +420,7 @@ to i.e. the internet:
vi /etc/lilo.conf
<add HiSax driver parameter in the global section (see below)>
lilo
Your lilo.conf _might_ look as the following:
Your lilo.conf _might_ look like the following:
# LILO configuration-file
# global section
@ -462,7 +462,7 @@ to i.e. the internet:
/sbin/isdnctrl secure isdn0 on
/sbin/isdnctrl huptimeout isdn0 0
/sbin/isdnctrl l2_prot isdn0 hdlc
# Attention you must not set a outgoing number !!! This won't work !!!
# 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
@ -478,7 +478,7 @@ to i.e. the internet:
/sbin/hisaxctrl HiSax 5 1
Remarks:
a) If you have a CISCO don´t forget to switch off the KEEP ALIVE option!
a) If you have a CISCO don't forget to switch off the KEEP ALIVE option!
Here an example script:
#!/bin/sh

8
Documentation/isdn/README.act2000
View File

@ -36,7 +36,7 @@ IRQ is configured by software. Possible values are:
3, 5, 7, 10, 11, 12, 15 and none (polled mode)
The ACT2000 driver either may be build into kernel or as a module.
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:
@ -78,11 +78,11 @@ Driver built as module:
act_bus=b act_port=p act_irq=i act_id=idstring
where b, p, i and idstring have the same meanings like parameters
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 like to the kernel-builtin one. (i.e. loading of firmware and
version as to the kernel-builtin one. (i.e. loading of firmware and
configuring the D-channel protocol)
Loading the firmware into the card:
@ -90,7 +90,7 @@ 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/
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 card using the following command:
actctrl -d idstring load /etc/isdn/bip11.btl

6
Documentation/isdn/README.audio
View File

@ -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.
...

2
Documentation/isdn/README.avmb1
View File

@ -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

68
Documentation/isdn/README.concap
View File

@ -10,7 +10,7 @@ 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 performace of the
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).
@ -25,14 +25,14 @@ 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 configuered by a
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 configuered encapsulation protocol.
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 at the data. Thus,
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
@ -46,13 +46,13 @@ the requirements for complex WAN encapsulations.
Many Encapsulation protocols used on top of WAN connections will not just
stick a header at the data. They also might need to set up or release
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. I.e. ppp does a lot of link level
negotiation before the first peace of user data can be transmitted.
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 interfaces
code for typical WAN devices also tends to be more 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
@ -65,22 +65,22 @@ protocol, complexity could be reduced and maintainability could be
increased.
Likewise, a same encapsulation protocol will frequently be needed by
several different interfaces of even different hardware type. I.e. the
synchronous ppp implementaion used by the isdn driver and the
asyncronous ppp implemntation used by the ppp driver have a lot of
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 (i.e. telephone lines via modem,
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. Therfore,
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. I.e. for a ppp module using our service
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)
@ -88,7 +88,7 @@ a connect_request will ask for establishing a reliable lapb
datalink connection.
The encapsulation protocol currently provides the follwing
The encapsulation protocol currently provides the following
service primitives to the network device.
- create a new encapsulation protocol instance
@ -121,7 +121,7 @@ struct concap_proto_ops{
struct device *ndev,
struct concap_device_ops *dops);
/* inactivate an encapsulation protocol instance. The encapsulation
/* deactivate an encapsulation protocol instance. The encapsulation
protocol may not call any *dops methods after this. */
int (*close)(struct concap_proto *cprot);
@ -145,24 +145,24 @@ 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 beeing submitted by lower layer (device hardware)
- request a connection beeing set up by lower layer
- request a connection beeing released by lower layer
- 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 encapsulations protocol accesses those primitives via callbacks
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 is submitted by device*/
/* 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 is set up */
support connection control. */
/* to request a connection be set up */
int (*connect_req)(struct concap_proto *);
/* to request a connection is released */
/* to request a connection be released */
int (*disconn_req)(struct concap_proto *);
};
@ -172,7 +172,7 @@ because the encapsulation protocol directly calls netif_rx().
An encapsulation protocol itsself is actually the
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 */
@ -189,7 +189,7 @@ struct concap_proto{
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 considerd private
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.
@ -217,21 +217,21 @@ 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
performace. However, typically the concap interface will be used by
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 neglectable.
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 (i.e. by a member struct concap_proto* in struct device)
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. i.e.
functions compatible to network device support fuctions.
i.e. instead of the concap protocol's service function
e.g. instead of the concap protocol's service function
int (*encap_and_xmit)(struct concap_proto *cprot, struct sk_buff *skb);
@ -252,7 +252,7 @@ The device's data request function could also be defined as
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 performace penalty
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.

10
Documentation/isdn/README.icn
View File

@ -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.

14
Documentation/isdn/README.pcbit
View File

@ -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.

48
Documentation/isdn/README.x25
View File

@ -1,18 +1,18 @@
X25 support within isdn4linux
=============================
X.25 support within isdn4linux
==============================
This is experimental code. Use it completely on your own risk.
This is experimental code. 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.
X.25 protocol implementation and experimental X.25-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
- If you connect to an X.25 neighbour not operated by yourself, ASK the
other side first. Be prepared that bugs in the protocol implementation
might result in problems.
@ -48,7 +48,7 @@ you also need to enable "Packet socket".
For local testing it is also recommended to enable the isdnloop driver
from the isdn subsystem's configuration menu.
For testing, it is recommended that all isdn drivers and the x25 PLP
For testing, it is recommended that all isdn drivers and the X.25 PLP
protocol are compiled as loadable modules. Like this, you can recover
from certain errors by simply unloading and reloading the modules.
@ -57,7 +57,7 @@ from certain errors by simply unloading and reloading the modules.
What's it for? How to use it?
=============================
X25 on top of isdn might be useful with two different scenarios:
X.25 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
@ -71,7 +71,7 @@ X25 on top of isdn might be useful with two different scenarios:
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).
teleservice applying ITU-T recommendation T.90.
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,
@ -79,23 +79,23 @@ 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.
Once encap is set like this, the device can be used by the X.25 packet layer.
All the stuff needed for x25 is implemented inside the isdn link
All the stuff needed for X.25 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
work with every existing HL driver. I was able to successfully open X.25
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
initiated when the upper (X.25 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
the X.25 network code will re-establish the datalink connection
(resulting in re-dialing and an X.25 protocol reset) when new data is
to be transmitted. (This currently does not work properly with the
isdnloop driver, see "known problems" below). It is recommended to
use large hangup-timeouts as most application probably can't deal
with such N-reset events.
use sufficiently large hangup-timeouts as most application probably
can't deal with such N-reset events.
In order to set up a conforming protocol stack you also need to
@ -118,7 +118,7 @@ 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 might
probably work if you access a public x25 network as long as the
probably work if you access a public X.25 network as long as the
corresponding isdn connection is set up by you. However, I've never
tested this.
@ -127,10 +127,10 @@ tested this.
How to set up a test installation?
==================================
To test x25 on top of isdn, you need to get
To test X.25 on top of isdn, you need to get
- a recent version of the "isdnctrl" program that supports setting the new
x25 specific parameters.
X.25 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/).
@ -150,17 +150,17 @@ 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.
is needed to set up X.25 routes. I.e.
x25route add 01 <iface-name>
will cause all x.25 connections to the destination x.25-address
"01" being routed to your created isdn network interface.
"01" to be routed to your created isdn network interface.
There are currently no real x25 applications available. However, for
There are currently no real X.25 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. You can
and telnetd that uses X.25 sockets instead of tcp/ip sockets. You can
use those for your first tests. Furthermore, you might check
ftp://ftp.hamburg.pop.de/pub/LOCAL/linux/i4l-eft/ which contains some
experimental implementation ("eftp4linux") of the EUROfile transfer
@ -174,7 +174,7 @@ hints to work around some of them.
The x25-utility package also contains an x25trace tool that can be
used to monitor x25 packets received by the network interfaces.
used to monitor X.25 packets received by the network interfaces.
The /proc/net/x25* files also contain useful information.
- Henner

16
Documentation/isdn/syncPPP.FAQ
View File

@ -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.