IPXTUND V 1.3.0

Purpose:
Connection of several Ethernet based IPX networks by IP connected routers.
The IPX packets are collected from LAN, encapsulated into IP packets which
can be transportet over e.g. Internet, received by another router, decapsulated
and put into their LAN. This happens in a quite transparent matter, i.e.
all IPX hosts should not be aware if their peers are at the same LAN or not
(besides speed, of course).

Features:
* Ethernet-IPX frametype conversion
* bundling of several small frames to one big packet for IP transfer
* compression of packets before IP transfer
* IP transfer by TCP with automatic link recovery
* background link control for TCP connections
* automatic address resolution (for routers with often changing IP numbers)
* multiple Ethernet interfaces and routers possible
* no-router configuration possible for bridging
* runs with FreeBSD and Linux at least.

Bugs:
Please report bugs or problems to eilts@tor.muc.de

Be warned: Its impossible to test anything in any possible configuration,
especially I don't have enought computers. Therefore, I need your bug reports
and proposals for further improvements.

Problems:
If you get many error messages "ipx_length x differ from packet_len y",
you may try activation of the BROKEN_INTERFACE switch in "ipxtund.h".
The background is: Any received IPX-Ethernet frame is composed by an Ethernet
Header (14 bytes) and an IPX packet (>= 30 bytes). The Ethernet checksum is cut
off by network card already. Because any Ethernet frame have to have
length >= 60, there data field is padded to 46 bytes for IPX packets shorter
46 bytes. This happens for my Ethernet cards, at last.
The program checks this by
if
IPX-length + 14 == Ethernet-length -> ok
else if
Ethernet-length == 46 + 14 -> ok
else
-> discard packet
Activation of the BROKEN_INTERFACE switch disable this check.

In Windows 95, IPX-Ethernet frametypes 802.2, 802.3, II, and "auto" are
selectable (in Network->SPX/IPX Protocol, I have a German version and cannot
tell the exact names). Default is "auto", which does not mean automatic but
802.2, at last for the games I tried with. If the frametype of the local
router (the host running ipxtund) and the LAN connected PCs differ, it will
not work.

If ipxtund is configured to determine the frametype automatically (option (a) 
at interface in ipxtund.conf, this is the default, too), it will send with
the frametype it received last at LAN. Therefore, it have to receive a frame
before it can send one. This is no problem, because most application sends
before receiving (broadcasts for servers, other gamers, etc.) but leads to
some error messages in log file. In general, some lost IPX frames should
never make problems, because IPX is a unreliable protocol (as IP, too).
If a Windows 95 PC boots, it sends some IPX frames of different frametypes.
This results in changing frametypes by ipxtund.
If you have problems with this, nail ipxtund and all clients to the same
frametype, 802.2 is a good choice for W95 (because Windows "auto" is like
802.2).

IPX resend blow-off:
Some applications send an IPX packet and expect an acknowlwdgement.
The timing may be designed for LAN with a very small round-trip time, compared
to usual WAN round-trip times, leading to frequent timeouts. In case of
timeout, the packet will be resend -> more traffic -> more delay -> more
traffic -> ... breakdown. The option -m maxage may be used to avoid this:
Each packet received at an Ethernet interface will be discarded if it is equal
to an older packet not older than maxage (in milliseconds).
If ipxtund builds up a TCP connection, it periodically send a small packet
to the other routers which reply to it ("TCP ping"). The reported time is
usually much bigger than the well-known (ICMP) "ping", due to queuing. A first
value for maxage may be 2 * TCP-ping-time (data connections are quite reliable
nowadays, therefore a real packet loss is unlikely, and some applications like
Warcraft, Starcraft, DOOM, etc. resend for hours without breakdown).

Novell Netware:
I tested one Win95 client with one Netware Server (4.1). It works for me,
albait a bit slow. The option -m should be set to 0.
By default, Netware server and client accept several different IPX-Ethernet
frame types, therefore the above mentioned "auto" problem has no effect.

FreeBSD:
The BPF implementation is a bit broken. In case of a data burst (typically
for Netware applications), it corrupts packets leading to a connection
breakdown. For lower and contiuous data rates (typically for games) this is
not a big problem.

Linux:
Sometimes, Linux sockets do not send data but wait for further packets.
Because this behaviour leads to NCP handshake delays of several secounds,
Netware performance suffer dramatically (lower than 10 kB/s over Ethernet).
Ipxtund uses a workaround by sending dummy packets (now 100..500 kB/s over
Ethernet). This is controlled by MAX_SEND_DELAY and DUMMY_COUNT: If there
was no data send (by TCP or UDP) for MAX_SEND_DELAY (in millisecounds), a
dummy packet is send instead. This will be repeated DUMMY_COUNT times. Each
data packet resets this procedure.
Maybe a Linux guru can tell me how to handle this problem directly.

IPX checksums:
Have to be disabled.

MAC and IPX addresses:
Ipxtund assumes MAC ("Ethernet address") == IPX address. The only exception
is IPX address "1" denoting a Novell Netware server (no comment to this idea).

Relations to other programs:
The intention for this program was to port "ipxtunnel" (written by Andreas
Godzina) to FreeBSD. Some additional features like TCP transfer and zlib based
compression broke compatibility to it, but many ideas originated from Andreas.

Experiences:
Some games (Warcraft 2, Doom) I tried are limited not by data volume but by
response time (round-trip time): If an IPX packet is emitted, its receiver
have to respond (or acknowledge) fast enougth, else it will be resent.
Therefore, the round-trip time have to be small, e.g. < 200 msec for Warcraft2.
Warcraft 2 behavior can be tweaked a bit using the "pkt:4" option (the game
initiator have to start Warcraft by "war2.exe pkt:4").
The additional delay caused by ipxtund may be ignored.
Please, send tips for improved IPX behaviour to me.

Thanks:
For testing and problem reporting I want to be grateful to
Mal Woods
Sergey Rosenfeld
Vitaly Belekhov