RESTRICTED - XR32 Alpha Test Team Only STATUS: This document is emphatically not for publication. It contains provisional information for use by XR32 alpha testers only. Paula G8PZT reserves the right to change the XR32 program and any specifications, instructions and supporting documentation without notice. For reasons of quality control and consistency, this document is not permitted to be shared outside the XR32 alpha test team. This is not (yet) a sysop manual. It is a random collection of notes which may help you understand the software. This document is best viewed using Notepad. XR32 Notes ########## Revision 1.0, 9th August 2011 Introduction ============ XR32 is a Windows 32 bit version of the DOS-based XRouter Amateur Radio packet networking software. It is a "Console Application", intended as an interim version between DOS XRouter and the full GUI version (to be released later), and therefore to have the same look and feel as the DOS version. This should allow DOS XRouter users to upgrade to more modern operating systems and hardware with minimal effort. Bearing the above in mind, XR32 is not GUI-aware, and probably never will be. It is the old familiar XRouter, just sitting on a new platform. This will be the optimum product for unattended systems, where a GUI is pointless. For the purposes of this interim documentation, it is assumed that you are familiar with DOS XRouter. If you are new to XRouter, you may need to refer to the XRouter sysop manual. An online (albeit rather out of date) version can be found at: http://zl2tze.ath.cx/hamradio/offlinecopy/zl2arn.ath.cx/xrouter/docs1.htm You are also recommended to read Rod's installation instructions at http://vk2dot.dyndns.org/XR32/XR32.htm Supported Operating Systems =========================== XR32 has been tested on Windows 2000 and XP. It is not known at this stage whether it will work fully on earlier or later operating systems. It appears to load but hang on Windows 98. This will be investigated if there is any demand for Win98 suport. The NdisXpkt driver, which allows XR32 to share the Ethernet NIC and have its own IP address, is only available for Windows 2000 and XP. However XR32 version 200 *should* work without it. The only difference being that for LAN operations, XR32 will share the Windows IP address. Installation Folder =================== You can install and run XR32 anywhere you like, even on a USB stick. For a number of reasons however, it is strongly recommended that you don't install XR32 under "Windows", "Documents and settings" or "Program Files". Firstly, if your motherboard dies, and/or you attempt to transfer the HD on another machine, the NTFS security will prevent you from accessing anything within those folders. Secondly, it is believed that on Vista/Windows7, programs are not allowed to write data within the "program files" tree. To install XR32, create a folder in your chosen location and copy XR32.EXE and XROUTER.CFG into it. Edit XROUTER.CFG as required. You may need to install other files, e.g. IPROUTE.SYS, depending on your configuration. Please refer to the DOS XRouter sysop manual for more information. XR32 will create any required subfolders when it runs. It does not write anything outside its own folder tree, and does not use the Windows registry. Therefore you may move the working folder around without problem. To remove XR32 from your system, simply delete the folder containing it. Windows Console Settings ======================== At this stage, XR32 uses a Windows console 80 characters wide and 25 lines high. These dimensions are not yet adjustable, but this will be addressed in the near future. If your default Windows console settings are anything other than 80x25, XR32 will resize its own window to 80x25, but will not affect the default settings for subsequent consoles. The choice of font is left to the sysop, but the recommended font is 8x12 "raster fonts". This provides the best clarity and the most familiar aspect ratio, and allows XR32 to be run in "full screen" mode by hitting Alt-Return. To set the font, right click on the console's title bar. Select "properties", then under "Fonts", select "size: 8x12" and "font: raster fonts". It should then say "selected font: Terminal". Click Apply. Operation with any font other than the recommended one is not guaranteed. Serial Ports ============ XR32 can be used with any serial port which is recognised by Windows. This includes "real" ports, USB-to-serial adaptors, and "virtual com ports" provided by external programs. If you are upgrading from DOS XRouter, your XROUTER.CFG file might need slight modification... Serial ports only need "COM=1" etc. they don't use IOADDR and INTNUM now. For example: ; USB to Serial adaptor INTERFACE=5 ID=COM8 serial TYPE=ASYNC COM=8 PROTOCOL=KISS KISSOPTIONS=POLLED SPEED=1200 MTU=256 ENDINTERFACE SCC Cards ========= Multi-port TNC cards (DRSI, BAYCOM, RLC100, PC100, PA0HZP, PC120, ITACARD and ARKTILL) based on 8530 SCC chips are not yet supported in XR32. They will be supported in due course. YAM Modem Support ================= This *should* have survived the move from DOS to Windows, but is still untested at present. Reports would be appreciated. Sound Cards =========== These are not directly supported, but XR32 can use them via AGW Packet Engine. See "AGWPE Interface" below. NDISXPKT Interface ================== NdisXpkt is an optional kernal-mode driver which allows XR32 to share an Ethernet NIC with Windows, and to have its own completely independent IP address. Note: This driver can only be used with Windows 2000 or XP. The NdisXpkt driver is only required if you wish to share an Ethernet NIC with Windows. XR32 will work without it, but you will not be able to trace any IP activity. If you don't need any Ethernet / Internet networking (e.g. if you're only doing AX25/Netrom/IP over radio, or using KISS/SLIP links), you won't need NdisXpkt. Before you can use NdisXpkt, it must be installed and started. Please follow the installation instructions in the install.htm document of the NdisXpkt package. To start the driver, open a command window and type: net start NdisXpkt Note the driver name is case sensitive and must be typed EXACTLY as above. If you type it any other way, the driver will start but will not be available to XR32. NdisXpkt only needs to be started once per session. You only need to start it again if you restart the operating system. It is hoped to automate the startup in future versions of XR32, but in the meantime Rod VK2DOT recommends the use of "Total Commander" to automate the startup of NdisXpkt and XR32 (see his website). XR32 interfaces to NdisXpkt driver via an EXTERNAL interface, which is declared in XROUTER.CFG as follows: INTERFACE=1 TYPE=EXTERNAL ; External device driver ID=Ethernet LAN PROTOCOL=ETHER MTU=1064 ETHADDR=00:07:95:fa:d9:3b ENDINTERFACE Note that the ETHADDR is mandatory and must match the MAC address used by the chosen NIC. To find your NIC's MAC address, open a command window and type IPCONFIG /ALL then look for "Physical address", e.g. Ethernet adapter Local Area Connection: Physical Address. . . : 00-07-95-FA-D9-3B Alternatively, type "ROUTE PRINT" and look for the name of the NIC in the list, e.g. Interface List 0x1 ....................... MS TCP Loopback interface 0x2 ...00 07 95 fa d9 3b .. SiS 900 PCI Fast Ethernet As you can see, there are several different ways of depicting a MAC / physical / Ethernet address. XR32 requires the use of colons ':' between the 6 pairs of characters. The Ethernet port is declared like this: PORT=1 ID=Ethernet INTERFACENUM=1 IPADDRESS=192.168.0.2 NETMASK=255.255.255.0 etc... Make sure you choose a different IP address to the one Windows is using! Note: The use of interface type EXTERNAL for NdisXpkt is a temporary measure, liable to change in fuure. AGWPE Interface =============== You can use AGW Packet Engine "underneath" XR32 to manage the hardware, and to provide access to hardware not directly supported by itself (e.g. soundcards). (Don't confuse this with XR32's AGW emulation feature, which is there to support apps which expect to see AGW) Here's how to specify an AGWPE interface: INTERFACE=1 TYPE=AGW ; IP addr of AGWPE. Default is localhost IOADDR=192.168.0.76 ; AGWPE port. Default is 8000 INTNUM=8001 MTU=256 CONFIG=MyAgwPassword ; Password for AGWPE ENDINTERFACE Note that IOADDR, INTNUM and CONFIG are all optional, and are only needed if you want to change the defaults. If you don't specify IOADDR, it defaults to 127.0.0.1, which is the same computer as XR32 is on. If AGWPE is on a different computer to XR32, you need to enter its IP address here. If you don't specify INTNUM, it defaults to 8000, which is the normal AGWPE port. If you don't specify CONFIG, XR32 won't "authorise" with AGW. Authorisation is not usually needed if you're using XR32 and AGWPE on the same computer. You can adjust the requirement for authorisation in AGWPE. When CONFIG is used, the "username" sent to AGWPE is the NODECALL and the "password" is the string specified by CONFIG. The AGWPE interface can support 16 PORTs, which are declared in the usual way, each PORT using a different CHANNEL on the INTERFACE - for example: PORT=1 ID=AGW Port 1 INTERFACENUM=1 CHANNEL=A ENDPORT PORT=2 ID=Agw Port 2 INTERFACENUM=1 CHANNEL=B ENDPORT Starting XR32 ============= Firstly, if you are using the NdisXpkt interface, start NdisXpkt if not started already. Then double click the XR32 icon. The program should start. If the window appears briefly, then disappears again, there is a configuration error. There may be some clues in LOG/BOOTLOG.TXT, but error logging there is still quite rudimentary. Your best option is to open a command window, navigate to the XR32 folder and type "xr32" to start the program. When it bombs out, it should print an error message to the window. If you start more than one copy of XR32, make sure there is no competition for resources. e.g. if one copy uses COM1, no other copy may use COM1. Similarly, NdisXpkt cannot be shared (yet). If you attempt to run 2 copies without one of them using NdisXpkt, the second copy will bomb out because it can't open the same TCP/IP server ports on Windows. The solution is simple: use the TCP service port override keywords (described below) to reassign or disable the ports. Use Alt-X (preferred) or Ctrl-C (last resort) to exit the program. AGW Application Support ======================= XR32 provides an AGW TCP host mode interface on TCP port 8000, allowing apps which would normally use AGWPE to use XR32 instead. The AGW emulation port can be changed using the AGWPORT keyword in the GLOBAL section of XROUTER.CFG. You might need to do this if you are running AGW on the same machine. e.g. AGWPORT=8001 Whether or not XR32 requires the applications to send a password is controlled by entries in ACCESS.SYS. The following entry allows computers on the LAN to access XR32 without a password: 192.168.0.0/24 1 For further information on ACCESS.SYS see: http://zl2tze.ath.cx/hamradio/offlinecopy/zl2arn.ath.cx/xrouter/doc95.htm AGW host support has so far been tested with: - UIView - AGWTerminal TCP/IP Stacks ============= XR32 has its own TCP/IP "stack" that is completely independent of Windows. This stack is "multihomed", i.e. it can exist on several networks at the same time, with different IP addresses on each network. If you use the NdisXpkt driver, XR32's TCP/IP stack can share the network card (NIC) used by Windows, whilst using its own IP address. Alternatively it could use any other NIC installed in the PC. If you don't use the NdisXpkt driver (e.g. because you are using 64-bit Windows), XR32's TCP/IP stack is available only via the serial ports, using SLIP, PPP, dialup or KISS TNC's (IP over radio). However, in addition to its own TCP/IP stack, XR32 can also use the one built into Windows. So even without NdisXpkt you can still use almost the full range of TCP/IP services, via Windows. The only difference is that traffic via XR32's stack is fully traceable, whereas traffic via Windows is not. And XR32 shares the Windows IP address for such operation. The choice of how your TCP/IP packets are routed and which stack they use is entirely under your control (it could have been automated, but that would have deprived you of choice). By default, all TCP/IP traffic is routed via XR32's own stack. This would be inappropriate if for example the only interface with the outside world was via TNC's and you wanted to route traffic other than amprnet (44.x.x.x). But perfectly valid if you were using NdisXpkt to access the Internet via Ethernet etc. The way to force traffic via the Windows stack is by means of IP ROUTE entries with mode "w" instead of "d". Anything not caught by a "w" entry will be routed via XR32. TCP Service Ports ================= TCP "service ports" (not to be confused with radio ports), are standard or "well known" numbers between 0 and 65535 which are used in combination with an IP address to access a particular process (usually a server) on a system. Default service port numbers and configuration keywords used in XR32 are as follows: ECHOPORT 7 Echo server DISCARDPORT 9 Discard server FTPPORT 21 FTP server TELNETPORT 23 Telnet server FINGERPORT 79 Finger server HTTPPORT 80 HTTP server TTYLINKPORT 87 Raw TTY link RLOGINPORT 513 Remote login SOCKSPORT 1080 Socks proxy server APRSPORT 1448 APRS server TELPROXYPORT 2323 Telnet proxy server CHATPORT 3600 Chat server AGWPORT 8000 AGW TCP host API RHPPORT 9000 XRouter host API Overriding Default TCP Service Ports ==================================== By default, all services are enabled, using the above ports. If you are using the NdisXpkt driver to share the Ethernet card, these services will use XR32's IP addresses, as specified in XROUTER.CFG. If you are not using NdisXpkt, these services will use Windows' IP address. But they will also be available on XR32's IP address (if one is specified), allowing them to be used by TCP/IP over radio, TCP/IP over SLIP/PPP etc.. Use one or more of the above configuration keywords in the GLOBAL section of XROUTER.CFG to override the default configuration. If you use the keyword without an argument, or with an argument of zero, that service is disabled. If you use the keyword with a single argument, that value is used for both IP stacks. If you supply TWO arguments, the first applies to XR32's stack and the second to the Windows stack. You may supply different numbers for each stack, or disable one and not the other. The numbers must be seperated by whitespace NOT commas. Examples: ~~~~~~~~~ The following formats disable the Telnet server on both XR32 and Windows TCP/IP addresses: TELNETPORT= TELNETPORT=0 This enables the Telnet server, using port 88 on both TCP/IP stacks: TELNETPORT=88 This specifies port 88 on XR32's TCP/IP stack, and port 89 on Windows: TELNETPORT=88 89 This one disables the Telnet server on XR32's TCP/IP stack, while enabling it for port 88 on Windows: TELNETPORT=0 88 Finally, this example disables the Telnet server on XR32's TCP/IP stack, whilst enabling it on port 88 of Windows: TELNETPORT=88 0 MPORT Command ============= There have been some changes since v187. Two new subcommands are ALL and NONE, which should be self explanatory. For example, "MPORT ALL" monitors all the ports at once, and "MPORT NONE" disables all tracing, a function which used to be accomplished using "MPORT 0". Port zero is now a "pseudo-port" used to trace traffic coming and going via Windows' TCP/IP stack. So "MPORT 0" now traces port 0, instead of disabling tracing. The binary MPORT flags have been moved up to accomodate port 0, so bit 0 now represents port 0 instead of port 1, and so on. So "MPORT #06" (binary 110) will trace ports 1 and 2, but not port 0. APRS Generic Digipeating ======================== XR32 has inbuilt support for APRS (Automatic Packet Reporting System) generic digipeating for RELAY, WIDE, TRACE, TRACEn-N and WIDEn-N aliases. Generic digipeating is configured on a port by port basis, using thw following flags in "DIGIFLAG": 4 Enable RELAY generic digipeating. 8 Enable TRACE generic digipeating. 16 Enable WIDE (Well sited stations only!) 256 Enable UITRACE digipeating 512 Enable UIFLOOD digipeating Add the appropriate numbers together to enable your desired combination of services. UITRACE and UIFLOOD are two special addresses that are suffixed with pseudo-SSID's, e.g. "TRACE4-4" and "WIDE2-2". These addresses can digipeat several times. The first digit specifies the maximum number of hops, and the second is the hop counter, which is decremented each time the frame is digipeated. These two addresses behave slightly differently however. When a frame is digipeated on the address specified by UITRACE, each digipeater inserts its own callsign in the digipeater list and decrements the "SSID". Frames digipeated on the UIFLOOD address have their SSIDs decremented, but the digi doesn't insert its own callsign. For the sake of consistency with UI-View, UITRACE defaults to "TRACE", giving TRACEn-n digipeating, and UIFLOOD defaults to WIDE, giving WIDEn-n digipeating. However, according to the APRS "New Paradigm", RELAY, TRACE and WIDE are deprecated, UITRACE should be set to "WIDE", and UIFLOOD should be set to a "state" code (e.g. "GBR" for the UK). One of the main reasons for the new paradigm was the fact that some of the older digipeaters would repeat the same packets over and over. This does not happen with XRouter however. Not everyone agrees with the "New Paradigm, so the choice of which features to enable is left you you. In quiet areas, you may wish to mix APRS and normal connected-mode operations on the same port, and that is the default if you enable any of the above flags. AXIP and AXUDP ============== By default, AXIP and AXUDP use XR32's TCP/IP stack, so your Internet router should be set up to "port forward" incoming UDP and/or IP protocol 93 to XR32's LAN IP address. However, if your XR32 configuration doesn't include an Ethernet port, you must port forward to the Windows' IP address instead. Even if you are using NdisXpkt, you can override XR32's IP stack and "force" XR32 to use Windows' IP address on a port by port basis, by setting a PORT's IPADDRESS to 127.0.0.1 DNS === XR32 may still use an external domain server, just like its DOS predecessor. But you may prefer to use the Windows DNS instead. To do this, just remove (or comment out) any "DNS=x.x.x.x" statements in XROUTER.CFG. Nodes Command ============= The new "N C" command lists the nodes sorted in callsign alphabetical order, instead of sorted by alias. Don't forget that you can still have the nodes table sorted by callsign by default, by putting "SORTBYCALL=1" into XROUTER.CFG. RESTRICTED