.TH IPXTUND 7 .SH Name ipxtund \- a tunnel for IPX .SH Syntax .B ipxtund [-d n] [-f config] [-l log] [-c level] [-m maxage] [-s sender] [-v] .SH Description IPXTUND connects several Ethernet based IPX networks by tunneling. The IPX packets are collected from LAN by a router, 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 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). A router is build by running IPXTUND on a host which is connected to the IPX network directly and able to exchange IP packets with the other routers. .SH Command Line Options .IP -d\ n Trace level \fBn\fR. The higher the level, the verboser, any level includes all messages of lower levels. Default is 0. \fB0\fR: Configuration, errormessages and statistics. Establishing and closing of TCP connections. \fB1\fR: Peer registration (i.e. IPX clients sending IPX frames). \fB2\fR: Packet flow. \fB3\fR: Packet header. \fB3\fR: Packet data. .IP -f\ path Path to the configuration file. IPXTUND needs one configuration file, which is explained later. Default is "./ipxtund.conf". .IP -l\ path Path to the log file. The current configuration, trace information and some statistics are written to this file. If the file already exists, it will be truncated first. Default is "./ipxtund.log". .IP -c\ n Level \fBn\fR of compression. IPXTUND uses ZLIB for data compression, which allows differnet compression levels, from 0 (no compression) to 9 (maximum). Default is 6. .IP -m\ maxage Identic packtes received by Ethernet while \fBmaxage\fR time (milisecs) are discarded. This often originated from resending caused by an acknowledging timeout due to a too latency connection. Default is 1000 (1 sec). .IP -s\ sender Path to the sender file. This file contain a list of MACs (e.g. [0:a0:c9:e6:bf:d3]) from all IPX clients allowed to use IPXTUND. Any IPX packet from a client not listed in this file will be dropped. Default is no sender file, i.e. all clients are recognized. .IP -v Be verbose. This option let IPXTUND print some statistics at stderr. .SH Usage: Run IPXTUND as root and finish it by pressing ctrl-c (or sending SIGINT, SIGHUP, SIGQUIT). If one IPXTUND exits (e.g. crashes) it may be started again without restarting all remote IPXTUNDs. The IPX clients should just continue in this case, until they have a timeout. .SH Configuration IPXTUND is controlled by a configuration file (command line option -f). It is build by lines, starting with a keyword followed by arguments. If in the following an argument is imbedded by braces, the braces are mandatory. Comments are possible, starting with a hash symbol (like a shell script). Order doesnt matter, but some keywords may appear just once, other may appear repeated. .IP \fIport\fR\ udp\ udp-ctrl\ tcp Port-numbers for UDP (IPX data), UDP (control data), TCP (IPX data). The local host will receive IPX data from remote routers at port \fBudp\fR, control data at port \fBudp-ctrl\fR, and TCP connect-requests at port \fBtcp\fR. If \fBtcp\fR is set to 0, no TCP connection will be enabled (this disables header compression, too). \fIport\fR is optional, default values are defined in "ipxtund.h". .IP \fIrouter\fR\ hostname\ (frametype)\ udp\ udp-ctrl\ tcp The IPX data will be forwarded to router \fBhostname\fR. \fBhostname\fR have to be a DNS-resolvable name or an IP address. \fBudp\fR, \fBudp-ctrl\fR, and \fBtcp\fR are the ports for data sending. If router "R1" has a \fIport\fR line "port a b c", all other routers want a \fIrouter\fR line "router R1 a b c" (with an optional additional (frametype)). If \fBtcp\fR is set to 0, no TCP connection will be enabled (this disables header compression, too). \fB(frametype)\fR may be \fB(n)\fR, \fB(t)\fR, determining the Ethernet frametype for sending towards router. \fB(n)\fR: don't sent Ethernet headers (recommended). \fB(t)\fR: sent Ethernet header (same type as received at Ethernet) Each remote router gets one \fIrouter\fR line, \fB(frametype)\fR and port numbers are optional, defaults are \fB(n)\fR and the default values from \fIport\fR above. .IP \fIinterface\fR\ if\ [MAC]\ (frametype) The IPX data will be receiced and transmitted by Ethernet interface \fBif\fR. \fB[MAC]\fR is the Ethernet address (may be retrieved by UNIX program "arp") in braces. \fB(frametype)\fR may be \fB(a)\fR, \fB(802.2)\fR, \fB(802.3)\fR, \fB(snap)\fR, or \fB(ii)\fR, determining Ethernet frametype for sending towards Ethernet. Ethernet frametypes for reading from Ethernet are determined by \fIframetype\fR as described later. \fB(a)\fR: automatic frametype recognition, i.e. the type of least received Ethernet frame at the interface determines the type for sendings at the interface. \fB(802.2)\fR, \fB(802.3)\fR, \fB(ii)\fR, \fB(snap)\fR: use type 802.2, etc. for sending. Each Ethernet interface get one \fIinterface\fR line, \fB[MAC]\fR and \fB(frametype)\fR are optional, defaults are \fB[0:0:0:0:0:0]\fR and \fB(a)\fR. .IP \fIframetype\fR\ (frametype) Determines all recognized Ethernet frametypes for reading from Ethernet. \fB(frametype)\fR may be \fB(802.2)\fR, \fB(802.3)\fR, \fB(ii)\fR, \fB(snap)\fR. Each frametype wants one \fIframetype\fR line. .IP \fIserver\fR\ servername\ myid If one or more of the routers have no known IP address (e.g. because it uses a different IP number each time it connects to Internet), one of the routers with a known IP number may act as server for IP number negotiation. All routers with unknown IP addresses get a \fIrouter\fR line with an id instead of a hostname, the id has a \fB?\fR in front, e.g. "router ?joe (n)". The router "joe" itself has an entry "server servername joe". At startup, all routers with a \fIserver\fR line sends the id \fBmyid\fR to the server \fBservername\fR, which collects them. If all \fB?id\fR at server are resolved, the server sends this resolving to all routers back. .SH Limitations Routers using an id instead of a hostname (see \fIserver\fR) cannot restart IPXTUND without restarting all remote IPXTUNDs. Some applications have a too tight IPX timing for IP connections using phone lines with modems. .SH Acknowledgements IPXTUND was written by Hinrich Eilts. If you have bug reports, suggestions, questions, e-mail them to eilts@tor.muc.de.