NEWS FLASH May 2000:
====================

I am astonished that I still get mail concerning ipxtunnel, after nearly
5 years of inactivity. Most of you were asking why ipxtunnel does not
compile anymore with newer kernels, so I renamed an internal structure
whose name conflicted with the new socket API and added a missing include.
I removed the obscure frame compression code and changed nothing else,
although I know that there are new kernel interfaces, new coding styles and
the like.

I dont play DOS games anymore, so I did not test my changes apart from
compiling it with 2.2.13 and 2.2.15. If ipxtunnel works for you, please
drop me a really short note.

You may also test newer packages like ipxbridge or ipxtund whose
authors are probably more responsive and up-to-date.

Thanks for your comments over the last years.
Andreas

Now, see the original README from 1995:

README for ipxtunnel (for Linux 1.2.*)
======================================

This software is supplied without any warranty. Use at your own risk.
Copyright 1995 Andreas Godzina. This software is free, but you must
not sell it for money. :-)

0. What is it?
==============
This program should allow users on different LANs to use IPX-based
software (you know what I mean...:-) together.

To do so, each LAN must have a Linux-box which can send UDP-packets to
every other Linux-box, for example over SLIP, Ethernet or the Internet.
(But I have no idea if fast networkgames will work across continents.)

The idea behind ipxtunnel is to catch IPX-Frames from the local
Ethernet and to send them to other ipxtunnel-processes, where the
frames will be put onto the ethernet, without any modification. As far
as I know, this should work, because IPX uses hardware adresses.

My understanding of IPX-networking is nearly zero, so maybe I re-invented
the wheel or made some silly mistakes.

This program was written using Linux 1.2.5 and 1.2.13, but I think it should
work under 1.3 also.


2. An example
=============
I have two PCs, one runnig Linux, the other running DOS (Doom OS). The
Linux-box is called agsc.han.de. My friend has the same configuration,
his Linux is called rubikon.han.de.

If we want to play Doom, we connect our Linux-boxes using ISDN, and start
the ipxtunnel program. My config file contains the single line
"remote rubikon.han.de", and his the line "remote agsc.han.de".

Now, if we start Doom in IPX-network-mode, the IPX-Frames from the
local ethernet will be caught, sent to the other Linux-box and put
onto the remote ethernet, where the remote Doom will see them. Nice.


3. Installation
===============
should be easy. Edit Makefile to choose the right CFLAGS, type
"make" and edit ipxtunnel.conf. You can start ipxtunnel giving it the
name of an alternate config file, like "ipxtunnel -f peter.conf".


4. Running
==========
You may start ipxtunnel with different debbuging levels using the -d
switch. -d 2 seems to be most interesting.

Pay attention that both sides use the same version of the program.


5. But...
=========
At the moment, the program is not very well tested. :-)
The compression is not very efficient, playing Doom with 3 persons is
too slow.

The bridging part is not tested. Communication with more than one
remote ipxtunnel is not tested. The program does not understand IPX
routing information.

We have tested it with an ISDN-Link with 40 ms RTT; I dont know what
will happen with higher RTTs.

I dont know if you can use it in a real Novell Netware LAN, we used
Netware Lite for testing.

I dont know who or what is using these strange different frame types
like 802.2, 802.3, IPX over DIX (???) or SNAP. I dont like IPX.

If the program dumps core, try to figure out where and why.


6. And...
=========
Thanks to Amitay Isaac (amitay@aero.iitb.ernet.in) and Vinod G.
Kulkarni (vinod@cse.iitb.ernet.in) for ipxbridge. I have used
the source for ipxbridge to write this program.

If you have ideas, patches or flames, please send me (ag@agsc.han.de)
a mail (and expect me to react slowly).

Dont waste your time playing games.


Andreas Godzina <ag@agsc.han.de>

With help from:
Peter Cleve <toad@rubikon.han.de>
Gerald Schlueter
Martin Pajak
