QUAKE proxies

QUAKESPAN

quakespan is a program designed to make your Linux quake servers
accessible by DOS machines without the B&W TCP/IP stack.  It works by
listening at the IPX quake port and forwarding packets to the UDP
quake port on the specified server.  It can be the same machine
(i.e. run xquake and quakespan on the same machine), or it can be
different machines, but the quake server MUST support UDP (i.e. either
linux or DOS with B&W TCP/IP).

The UDP server can be somewhere else on the internet, and if run on a
firewall will serve as a proxy (IPX will point internally, UDP
externally).

Internally, it alters the connect message from the server (in UDP) to
say "connect to me via IPX" and spawns a subtask to forward packets in
both directions.  If no packets go across for 15 seconds, it
disconnects and the subtask dies, so don't worry about leaving
processes around.

In addition, if you have several IPX segments (that the broadcast
won't go across), quakespan implements an info UDP port that will
return the IPX address of the port to connect to for quakeredirect
automatically.

QUAKEMULTI

quakemulti allows ipx sessions to cross routers.  The network path
must support IPX packets and routing to where you want to reach (which
can be a quake server supporting IPX or quakespan).  If the remote
connect is a quakespan proxy, you just need to specify the host name
or IP (yes, IP, not IPX) address of the quakespan proxy and it will
automatically figure out the IPX address.

If you are using a DOS-IPX server you must use "-i Net:node:port"
which is the standard way of specifying Novell IPX addresses.  The
quake server and clients sometimes display this info.  Otherwise, ask
your net admin for the network, or use a packet sniffer (or cat
/proc/net/ipx/ipx_route on a linux box and look for Direct, or in
ipx_interface which will also give the network - use eth0 and not any
internal network).  The node is normally the 12 hexadecimal digit
ethernet address.  Port is normally 26000.

Since the connect packet will contain the proper (remote) IPX address,
this will consume no CPU time after the connection, only during the
search broadcasts and responses.

Only one -i can be used (this is a limitation of the quake client, it
checks the originating IPX node number, and discards duplicates, so
quakemulti can only proxy one such value).  In this mode, quakemulti
acts as a plug forwarding packets between the client and server.

Any number of -u udp addresses can be given.  Quakemulti sends a
"request from IPX N:n:p <packet>" message directly to quakespan, which
then converts it to UDP and forwards it - any response will be from
the quakespan program.

If run on a Linux box with a full internal ipx network, or multiple
interfaces (or "media types", e.g. 802.2, 802.3, SNAP) the -n
parameter must be given to specify which interface it should listen
for client request broadcasts on.  You can run one for each interface,
however it isn't useful to have it listen on the internal net.

quakemulti MUST BE RUN AFTER quakespan to work.

NOTE

I am releasing this under the Gnu Public License, and am usually busy
so don't expect a lot of support, but I will try to answer questions.

The IPX full internal net is similar to the localhost interface under
IP - a fake address used to connect internally.  It is preferable to
use this (quakespan will default to it) if you have multiple segments
since then quakemulti can be used (also can use localhost in this
case) to forward the local and remote servers.

"quakespan localhost" usually works (if on the same machine as xquake),
but try it with the real hostname or IP if it doesn't seem to work.

The most common problem is a misconfigured IPX on the Linux side.
Insure that you can connect to servers, etc. across the same routers
from the Linux box (and insure that IPX is enabled in the kernel, and
the ipx_configure and ipx_interface programs have been run).  Also
ipxd (or ipxripd) should be running if you don't manually configure
the routes.

IPX isn't stable even in 1.2.13 linux.  I have two boxes, both with
this kernel, and one works and the other doesn't.  They both send
ethernet packets which are identical in content (as viewed with a
packet sniffer), so I don't know what is going on, except that it
might have to do with patching for ncpfs support or other IPX
enhancement (getsockname doesn't work right in the one that fails).
This should be visible if verbose mode is used - the connects will
come from an IPX address with all zeros.

USAGE EXAMPLE 1:
----------------
(assumes IPX configured, no internal net)

Run xquake on a linux server.  Run "quakespan localhost" on the same
server (can be run first).  DOS clients should be able to connect.

On a segment across a router, run "quakemulti -u other.side" (use the
DNS hostname or ip address), and DOS clients on that segment should
now be able to connect to the server on the far side.

USAGE EXAMPLE 2:
----------------

IPX & LINUX & QUAKE is no longer two out of three

The best configuration is to enable a full ipx internal network.
This is ipxspeak for a localhost.

Then configure it:

	ipx_internal_net add 26026 1
	ipx_interface add eth0 802.3 <yourIPXNetnum>
	ipxd

The internal net will be the "primary interface" by default.  The
IPXNetnum is for the ethernet interface (see above - you may want to
try not using ipx_internal_net and using ipx_configure with
--auto_interface=on --auto_primary=on then look at /proc/net/ipx*)

Now run

	quakespan localhost &
	quakemulti -u localhost -n <yourIPXNetnum> &
	xquake -dedicated 16 +map test3 +hostname linuxquake ...

What happens is:

xquake
udp port 26000
 |
udp user port
quakespan     (internal.netnum)  (node) (port)     
udp port 26500 - ipx 26026:000000000001:26000
 |                     |
udp user port  - ipx user port
quakemulti 
ipx <yourIPXNetnum>:[node]:26000

------

xquake opens the udp port 26000 for network connections.

quakespan attaches to it and opens an IPX port 26000 on the internal
net (26026 in the example), and udp port 26500 for inquiries.

quakemulti sends a packet to udp port 26500 and recieves the IPX
full address (internalnet,node,port).  it then creates a user IPX
connection to quakespan, and then opens the 26000 port on the
ethernet side to forward broadcasts.

Eventually quakemulti will forward the broadcast requests to quakespan
which will respond using their address, so multiple servers can be
accessed.  (only one IPX forward will work per machine since the
quake client keeps track of the IPX network node number).