224 lines
8.3 KiB
Plaintext
224 lines
8.3 KiB
Plaintext
|
|
|
|
Expert start
|
|
============
|
|
|
|
This is an older setup procedure kept for compatibility and expert
|
|
users who want to do more with x25 on top of isdn4linux.
|
|
(this is no longer supported but as you are an expert user, you might
|
|
want to edit the scripts such that it works with this release again).
|
|
|
|
Even if you don't use isdn, this might be useful for testing PF_X25
|
|
network applications. The test distribution supports
|
|
setting up X.25 connections on top of the isdnloop driver. This allows
|
|
you to set up X25 connections between a client and a server application
|
|
running on the same machine. There is no physical x25 network
|
|
interface needed. This is similar to setting up tcp/ip connections
|
|
to the "localhost" IP address. (Using the isdn subsystem for this
|
|
might be overkill, but there is currently no other x25 loop device
|
|
driver at all).
|
|
|
|
A script "ix25test" is provided inside the scripts
|
|
directory. That script does all the necessary setups needed for
|
|
testing x.25 on top of isdn4linux. You need to edit the script to
|
|
account for your local configuration (i.e. your MSN, ISDN-numbers
|
|
of your peer, location of utility binaries and kernel sources/modules,
|
|
configuration of your isdn HL driver, ...).
|
|
You should unload all isdn drivers modules and the x25 module before
|
|
calling this script.
|
|
|
|
When done, you can just call "ix25test start". However, read the
|
|
comments in the script file as well as the remaining part of this
|
|
README file and the PROBLEMS.* files before using it.
|
|
|
|
|
|
Now the really cool stuff in detail:
|
|
|
|
1. Boot your (patched) kernel (see remarks below)
|
|
|
|
2. log in as root
|
|
|
|
3. Make sure that all isdn and x25 related modules are unloaded. I also
|
|
prefer to switch to runlevel 1 (using the command "init 1") when doing
|
|
my tests, this will usually unload all isdn drivers as well.
|
|
|
|
Call the configuration script:
|
|
|
|
ix25test start telnetd 01
|
|
|
|
(In case of problems, issue the command "ix25test stop", fix
|
|
the script, and repeat)
|
|
|
|
4. switch to another virtual terminal, log in (not as root), and
|
|
start the x25 based telnet client. Assuming your x25 based telnet
|
|
client resides in x25bin/telnet enter the command
|
|
|
|
x25bin/telnet 00 01
|
|
|
|
This will open an x25-based telnet session on top of isdn4linux
|
|
to your own machine. The isdnloop HL driver is used for this, thus
|
|
no real isdn line is occupied (and no phone bill will result from
|
|
this). If it works you should be able to log in, issue some commands
|
|
and log out again.
|
|
|
|
5. After exiting from the telnet session, switch back to the other
|
|
virtual console (where you started the ix25test script) and type
|
|
^C. This should kill the telnetd and shut down the test
|
|
configuration again.
|
|
|
|
|
|
If this worked well you can try x.25 connections on top of real isdn
|
|
connections to your own computer. Similar procedure as above, but
|
|
slightly different command arguments:
|
|
|
|
|
|
3. ix25test start telnetd 03
|
|
|
|
4. x25bin/telnet 00 03
|
|
|
|
This will establish a real isdn connection on top of hisax to yourself
|
|
(your PTT will probably charge you). Please monitor (i.e by watching
|
|
syslog messages) the isdn connections during and after your tests.
|
|
(Verify that connections are properly released after your tests and
|
|
no power dialing or other expensive actions happen during your tests.)
|
|
|
|
|
|
If this worked you might try a connection to a remote computer. Find a
|
|
partner operates an EUROFILE server and agrees that you connect to it
|
|
with this experimental software.
|
|
|
|
1. boot the test configuration as above. Alternatively, as you don't need
|
|
an x.25 based server on your own machine, "ix25test start" is
|
|
sufficient.
|
|
|
|
2. Assuming your user name on the eft server is "myname" and your
|
|
password is "mypass", switch to the non-root virtual console and type
|
|
|
|
eftp 05 myname/mypass
|
|
|
|
from the shell's prompt. This will try to connect to the remote
|
|
eft server.
|
|
|
|
3. type
|
|
|
|
dir *
|
|
|
|
from the "eftp>" prompt to list the directory of the eft server.
|
|
|
|
4. type
|
|
|
|
get <filename> [<local filename>]
|
|
|
|
from the "eftp>" prompt, where <filename> denotes a file name
|
|
present on the remote server (such as listed by the previously
|
|
issued "dir"-command). This will download that file.
|
|
|
|
5. type
|
|
|
|
put <filename> [<remote filename>]
|
|
|
|
to upload a file to the remote server. (This is known not to inter-work
|
|
with certain remote eftp servers when used with an unpatched 2.1.92
|
|
kernel).
|
|
|
|
6. type
|
|
|
|
quit
|
|
|
|
to exit from the eft session.
|
|
|
|
7. switch to the root shell's virtual console and type
|
|
|
|
ix25test stop
|
|
|
|
(or just ^C, if a server has been started) to shut down the test
|
|
configuration. The eftp program doesn't hangup the isdn line after
|
|
the eft connection is closed. (This is currently impossible
|
|
because the x25 socket interface does not provide for this
|
|
functionality). Therefor, it is recommended that you manually
|
|
hang up the isdn line (using "isdnctrl hangup" or shutting down
|
|
the test configuration). Your eft peer might close the isdn
|
|
connection after the eft session is finished, but you should not
|
|
rely on that.
|
|
|
|
|
|
|
|
You can also try to connect with your eftp client locally to the tdu.echod
|
|
server by
|
|
|
|
ix25test start tdu.echod 01
|
|
|
|
and then
|
|
|
|
eftp 01 myname/mypass.
|
|
|
|
However, as tdu.echod is not an eft server implementation, you will
|
|
only be able connect and disconnect. Any attempt to transfer files will
|
|
only trigger error events of the EUROFILE protocol implementation.
|
|
|
|
|
|
PLEASE, keep in mind that the eftp client (OVER-)writes local files.
|
|
In case of bugs, the file overwritten might be different from the file
|
|
which you specified in the target parameter of the "get" command.
|
|
|
|
|
|
If it doesn't work, what to do?
|
|
===============================
|
|
|
|
Well, this is alpha-test software and you should be able to assist
|
|
me in troubleshooting. To make this task more convenient, the ix25test
|
|
script provides some debugging support.
|
|
|
|
If you use the script and it fails before any B-channel connection got
|
|
set up you probably did not edit the script successfully. Check it.
|
|
|
|
If your syslog / isdnctrl messages indicate that the isdn b-channel
|
|
was successfully set up but no further data seems to be transferred,
|
|
there might be an inter-working problem of the X.25 PLP implementations.
|
|
Uncomment the line in the ix25test script where the x25trace program
|
|
is started and try again. This will leave a protocol trace in /tmp
|
|
which might be helpful in tracking down the problem. If you cannot
|
|
resolve such a problem yourself, please include that trace output in
|
|
your bug report.
|
|
|
|
If the x.25 connections set up successfully, but eft doesn't work, the
|
|
eft error messages reported by eftp program might reveal the problem.
|
|
The eft protocol implementation is incomplete. Thus, failures are not
|
|
not unlikely to occur.
|
|
|
|
If the standard error messages don't contain
|
|
enough information, you can make the eft programmes a lot more noisy
|
|
if you locate the line in eftp.c where the variable tdu_stderr_mask
|
|
is set. Change this to
|
|
|
|
tdu_stderr_mask = -1
|
|
|
|
and recompile. A lot of debugging output (protocol and call trace)
|
|
will appear on your terminal while the eftp program is running now.
|
|
|
|
|
|
Problems with the kernel part might also be present. Please refer to
|
|
the appropriate PROBLEMS-* file available from the same site as this
|
|
test distribution. But I consider the kernel stuff (x25 on top of
|
|
isdn4linux extensions), which I've used since end of May 1997 now with
|
|
only marginal modifications, to be much more stable than the user
|
|
level eft implementation. However, if you faced a serious kernel bug
|
|
(usually indicated by an oops messages in the syslog output) please
|
|
report it to me. The oops message will only be meaningful to me if
|
|
the addresses are reported in symbolic form. Thus, if you faced a
|
|
kernel oops, compile the ksymoops program present in your kernel
|
|
sources "script" directory, i.e (assuming kernel source is in
|
|
/home/kernel/linux-ix25):
|
|
|
|
cd /home/kernel/linux-ix25/scripts
|
|
g++ ksymoops.cc -o ksymoops
|
|
|
|
The ix25test script leaves a System.map file in the /tmp directory
|
|
which contains all symbolic address mappings of the resident
|
|
kernel as well as all isdn and x25 related modules. You can use this
|
|
file with your ksymoops program. For your convenience, ix25test also
|
|
leaves a script "oops_decode" left in /tmp. Type "/tmp/oops_decode"
|
|
after the oops happened, this will fetch the oops message from your
|
|
/var/log/messages syslog protocol file and decode it to stdout.
|
|
|