.PL



                          XROUTER MULTI-PROTOCOL ROUTER
                          =============================


                                  SYSOP'S MANUAL
                                  ==============



                               by Paula Dowie G8PZT
                               --------------------


                          Revision 2.3 - 25th April 2004
                          ---------------------------------


      ---------------------------------------------------------------------

      PREFACE
      =======

      This manual is far from complete, and the information is probably not 
      in the most logical order.  However, I thought you'd rather have some 
      documentation than nothing at all!  Getting the document perfect would 
      have needlessly delayed the release of the software (and has in fact 
      already done so), so I have chosen to refine the documentation after 
      release.  You may have to search for what you want, and in some cases 
      you may not find it.

      The document's format is plain ascii text, which is fine for reading 
      off a computer screen with a simple text viewer.  I have not included 
      page breaks because your printer may not necessarily be using the same 
      settings as mine.  I will address this in later versions, and will 
      hopefully create HTML and PDF versions.

      Writing documentation is very time consuming, and prevents me from 
      programming, so I am trying to balance both activities.

      If you don't find what you want, or you think something could be 
      better explained or positioned, PLEASE let me know, don't leave it to 
      others - they are leaving it to others too!

      As a programmer, I am not the best person to write the documentation - 
      I have tried to include what I think you need to know, but with 
      intimate knowledge of the code I tend to make assumptions without 
      realising it.

















     

      Introduction


                             SECTION 1 - INTRODUCTION
                             ========================

      Xrouter is an AX25 and IP packet router for the amateur packet radio 
      network, using a standard PC and DOS.  It is intended to be a direct 
      alternative to G8BPQ's SWITCH.EXE program (*not* BPQCODE.EXE), and 
      looks very similar both to sysops and users, but provides a lot more 
      than BPQ.

      It is called a "router" rather than a "node" because its primary 
      purpose is to route data packets.  Node is a general purpose term 
      meaning "junction", and can be an end user.  This software simply 
      routes packets.  Whether those packets contain ax25, Netrom, IP, or 
      any other protocol is irrelevant.  It is not the job of a router to 
      provide FTP, SMTP, NNTP, or BBS facilities, so they aren't provided.

      The program was developed because G8BPQ node, although excellent, was 
      unreliable in certain situations, it didn't provide the required 
      facilities, and its author *appeared* to have lost interest in it.

      It was designed to be familiar to sysops who currently use BPQ, thus 
      allowing easy transition between the two programs.  It fixes some of 
      the BPQ problems (such as the unsafe command line parsing), properly 
      integrates IP routing into the system, and adds many facilities which 
      BPQ did not provide, such as an integral chat server, and the TCP 
      layer which allows TELNET, RLOGIN etc. (see below for full list of 
      features)

      The program is a long way from finished and has not been tested under 
      all conditions.  I am not claiming that it is *better* than BPQ.  It 
      is not intended to replace BPQ, merely to provide an alternative.

      Although some of the commands and configuration options may look 
      familiar to NOS users, this is largely coincidental, and you should 
      not expect NOS commands and options to work unreservedly.  Some NOS 
      commands were derived from UNIX, as were some of mine.  Sometimes 
      there is only one logical way to do things, and both NOS and Xrouter 
      chose the same way.  However, even if the commands look familiar, the 
      syntax may not necessarily be identical, reflecting the fact that this 
      system has different design criteria. 

      This program is not a variant of NOS and is not derived in any way 
      from NOS.  The latter has a reputation for being flaky, cumbersome and 
      un-intuitive.  This program is aimed at busy sysops who want to get 
      the job done, not play around with software.  It was designed from 
      scratch (the console display was the first component), not "cut down" 
      from someone else's software.

      Whereas NOS is a complete TCP/IP networking system with rudimentary 
      Netrom capability, Xrouter specialises in multi-protocol routing and 
      user access.  Although IP is one of the protocols, this is NOT a 
      "TCP/IP program".  It does not have, and never will have "hub" 
      facilities - if you want a hub, use NOS.

      This program is not a TSR, and there will probably never be a TSR 
      version because it would be too big to allow anything to run on top!








      XROUTER Sysop Manual Revision 2.3 (25/04/04)                Page  1

      Introduction


      It was designed as a standalone router running as the sole application 
      on a PC dedicated to that purpose.  I personally don't like the idea 
      of running part of the Packet network as a TSR underneath a BBS 
      program for the following reasons:

          a) The node gets a limited amount of processor time because it is 
          running on clock interrupts.  I have seen considerable delays in 
          traffic through such systems.

          b) The BBS gets less processor time because the node is stealing 
          it.  Every single byte that passes through the system generates an 
          interrupt, so a busy node steals a lot of processor time, and the 
          BBS runs more slowly.

          c) If the node crashes, the BBS is taken out of action too, and 
          the system has to be rebooted.  This may not be important in your 
          case, but my BBS can also be accessed via telephone, and wire 
          links, and I don't want it disrupted every time the AX25 side 
          crashes.

          d) If the BBS crashes (which some are particularly prone to!) the 
          Packet network is disrupted.  This also happens if the sysop keeps 
          taking the BBS off line to mess about with it.  A NetRom network 
          does not take kindly to outages, and the effects can last for 
          hours so nodes need to be left alone, not rebooted every few 
          hours.

      There didn't seem much point making a TSR version, since that would 
      remove most of the advanced features.  If you need a TSR node to run 
      under a BBS on a DOS system, you'll have to run BPQ.

      However, if you run Xrouter within a Windows or Desqview environment, 
      along with the PZTHOST TSR, you may run applications which conform to 
      G8BPQ's 16 bit HOST application interface spec.

      I make no apologies for creating yet another "old fashioned" DOS 
      program.  DOS is fast, compact, ultra-reliable, boots quickly, is 
      relatively uncomplicated, can run from floppy, and runs on the 
      humblest machine.  Therefore I believe it is still the best choice for 
      a standalone packet router, *especially* at a remote site.

      Linux devotees already have their LinuxNode, and Windows users have 
      BPQ32 and Digiplex. For DOS users however, apart from BPQ there are no 
      other English nodes.  Flexnet and the PC version of TheNet suffer the 
      usual problems with unfamiliar commands, translated documents etc., 
      and are not popular with either sysops or users in the UK.

      I am not ruling out the possibility of a 32 bit Windows version in the 
      future, but it is not high on my priority list because the Windows 
      market is already well catered for by BPQ32, with AGW being popular 
      for non-routing applications.













      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  2

      Features and Limitations


      FEATURES AND LIMITATIONS
      ========================

      The following is a list of some of the features and limitations of 
      Xrouter. It is by no means an exhaustive list, nor is it in any 
      logical order. (* = advantages relative to BPQ)


      Hardware / Software Compatibility
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      - Modest machine requirements: DOS, 640k, XT -> Pentium.
      - Can run under DOS, Windows, DesqView or Linux (using dosemu).
      - Configuration file familiar to BPQ sysops.
      - Compatible with BPQNODES recovery file for easy transition.
      - Supports any hardware drivers which use BPQ "external" interface. 
      - Supports BAYCOM USCC, RLC100, PC100/120 and DRSI scc cards.
      - Can use KISS and BPQKISS TNC's.
      - KISS modes: normal, polled, checksum, and bpq slave.
      * Directly supports YAM modems.
      * PA0HZP Opto-SCC card support.
      * ASYNC interface supports any speed up to 115,200 bauds.
      * ASYNC Protocols: KISS, "Netrom backend", SLIP, PPP, ASCII (TTY).
      * Ethernet driver allows connection with Windows, Linux, NOS and BPQ
      * Year 2000 compatible.
      * Supports BPQHOST compatible applications (in Windows/DesqView only)
      * PSTN modem support


      General Features
      ~~~~~~~~~~~~~~~~
      * Configurable software watchdog
      * Hardware watchdog driver.
      * External hardware control & monitoring.
      * Budlist and Validcalls lists for each port.
      - Digipeating on/off/UI-only from any port to any port.
      * Digicasting
      * Frame piping from port to port.
      * Proxy connections.
      * Cross-protocol bridging.
      * Very comprehensive stats to aid network maintenance.
      * MHeard list sizes can be customised for each channel.
      * MHeard includes date, time, callsign, frame count and frame type.
      * Integral multi-channel chat server available to all users.
      * Configurable mtu.
      - Can TX on a different port to RX.
      * Callsign validation in nodes broadcasts.
      - Ports may be "interlocked" so they don't transmit at the same time.
      - Can support 32 bit Windows applications such as UI-View, Winpack...
      * ID beacons may be configured independently for each port.
      * Netrom echo and route record facilities.
      * Modulo-128 capability, with frame resenqencing and selective reject.
      * Message-Of-The-Day facility.
      * Link parameters are self-adjusting.
      * Integral Personal Message System (PMS).
      * Can emulate a multi-port TNC2 for RS232 peripherals to use.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  3

      Features and Limitations


      APRS Features
      ~~~~~~~~~~~~~
      * MHeard can display APRS position, distance and heading.
      * APRS generic digipeating (RELAY, WIDE, TRACE, TRACEn-N and WIDEn-N)
      * Maintains APRS "Best DX" list.
      * Decodes MIC-E packets.
      * Integral APRS Packet <> Internet gateway.
      * Integral APRS messaging shell.
      * Integral APRS server.
      * APRS "digipeating" via Netrom.
      * Responds to APRS / UI-View queries.
      * ID may be beaconned via digipeaters.
      * Ports may be configured for "APRS-only" use.

      TCP/IP
      ~~~~~~
      * Built in IP router, with full ARP & ICMP implementations.
      * IP commands fully accessible on normal console, and to all users.
      * Built in TCP, giving TELNET, ECHO, DISCARD, FINGER, CHAT, RLOGIN, FTP
      * Domain name to ip address resolution.
      * Inbuilt DNS server, with proxy capability.
      - IP datagram, virtual circuit, netrom and encap modes.
      * AXIP, AXUDP, IPIP and IPUDP protocols, allowing links via Internet.
      * Additional IP addresses for each port.
      * DHCP client
      * Network and Port Address Translation
      * Dial Up Networking
      * RIP98 Routing Information Protocol
      * Telnet -> Telnet / AX25 / NetRom proxy
      * AX25 / NetRom -> TCP/IP / AX25 proxies.

      Command Interface
      ~~~~~~~~~~~~~~~~~
      - BPQ compatible user commands: bye, connect, info, help, links, mheard,
        nodes, ports, routes, stats, users.
      * Up to 16 command aliases can be defined (bpq=8).
      * Additional user commands: PING, ARP, TELNET, CHAT, J, ECHO, DX etc.
      * Built in syntax help for most commands.
      * Aliased commands can be "hidden".
      * Graduated help system gives help in a progressive way.
      * Extendible Info system for sysop to set up as s/he wishes.
      * Command scheduling by time / day / date.

      Console Interface
      ~~~~~~~~~~~~~~~~~
      * Screen saver - automatic and manual.
      * Shell to DOS facility.
      * Editable command line.
      * Fully configurable display colours.
      * Up to 5 independent "Virtual" consoles, fully multitasking.
      * Each virtual console has a configurable scrollback buffer
      * Each virtual console can display ANSI colour.
      * Each virtual console can run a separate session.
      * Each console may have its own colour scheme and callsign.
      * Configurable connect / disconnect and paging bells
      * Per-console command history.








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  4

      Features and Limitations


      Local And Remote Sysop
      ~~~~~~~~~~~~~~~~~~~~~~
      - Most parameters configurable while on line.
      * Tx for any port may be disabled/enabled by sysop command.
      * Time and date settable without rebooting.
      * Multitasking DOS commands: cd copy del dir mkdir, ren, rmdir, move type
      * Line editor allows any text file to be edited.
      * IP routing adjustable without reboot.
      * Transaction logging.
      * Simple programs, MSDOS commands or batch files run from command line.
      * Online sysop's manual.
      * Each protocol layer independently traceable.
      - Each port independently traceable.
      * Trace o/p can be captured to file.


      Additional Features For Remote System Maintenance
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      - Secure password system for remote sysops.
      - May be remotely restarted or rebooted.
      * Allows separate passwords for each sysop.
      * Remote operation via RS232 wired links. (dialup coming soon).
      * Secure FTP server, allowing remote upgrading
      * Trace display can be viewed by remote sysop.

      BPQ fixes
      ~~~~~~~~~
      * No need to pre-compile a binary config file.
      * Virtually unlimited nodes, routes, circuits and sessions.
      * No 511 character limit on CTEXT and INFOMSG.
      * No 256-character limit on callsign (e.g. VALIDCALLS) lists.
      * No 130 buffer limit, or running out of buffers.
      * No crashing on frames bigger than 256 bytes.
      * No crashing on "certain" command line characters.
      * No crashing due to "too many commands at once".
      * No "command can't be split across packets".
      * Proper session flow control.


      Limitations
      ~~~~~~~~~~~
      - Not a TSR, so applications are supported only under Windows or Desqview.
      - Xrouter is not a Windows program - it requires a DOS window.
      - A Linux version is intended, but not yet implemented.
      - Consoles limited to 25 lines, 80 columns, 16 (EGA) colours. 
      - Will not directly use expanded memory.
      - No SMTP / POP3 / BBS - it's a router/Network Access Point not a server!

















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  5

      Copying, Use and Distribution


      COPYING, USE AND DISTRIBUTION
      =============================

      You must read the following text carefully.  It is not designed to 
      take away your rights, but rather to protect mine.  The software took 
      a long time to write, at considerable cost to my health, and I don't 
      see why others should make a profit from my hard work.

      The terms "the code" and "the software" refer to Xrouter and all 
      components thereof, and all documentation relating to it.

      This software is "conscienceware".  You may freely use and share it 
      for any non-commercial purpose, and you are not compelled to pay a 
      registration fee.  You may however ease your conscience and aid the 
      continuing development and support of the software by sending a small 
      donation to the author if you wish (Cheques should be made payable 
      to Ms P J Dowie at the address below).

      You are not permitted to make any charge for, or gain any pecuniary 
      advantage directly or indirectly from, the copying, distribution or 
      use of this software, or any component thereof, or any driver or 
      utility written for use with the software, unless by prior written 
      agreement with the author.  For example, you may not place the 
      software on the Internet with the intention of attracting more 
      visitors to a site.

      You must not patch, decompile, disassemble, reverse engineer or in any 
      way modify the software, or cause a modified version or part thereof, 
      or any portion of the source code to be distributed.

      Legal action will be taken against anyone who breaks the terms 
      outlined above.
































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  6

      Copying, Use and Distribution


      SOURCE CODE

      After due consideration of the pros and cons of "open source" 
      projects, I have decided that the source code will not be made 
      available, and this is not negotiable.  All protocols and API's 
      developed by myself will however be published.


      FEEDBACK

      Because the terms and conditions outlined above prohibit patching, and 
      the source is not available, the only way the bugs will be fixed and 
      the software improved is for me to do it.  I am therefore relying on 
      you to report any bugs promptly, and to make known your ideas for 
      future improvements.  You are my beta testers.  I promise to correct 
      all reported bugs promptly where possible, and to carefully consider 
      all suggestions.

      Please also report any errors or omissions in the documentation.  If 
      you don't like the layout or feel something isn't properly explained, 
      tell me.  You can make a difference.

      If you want to send Packet bulletins regarding this software I suggest 
      the use of "XROUT" as the To field.  I strongly suggest you join the 
      Xrouter mailing list at YahooGroups.com - email 
      xrouter@yahoogroups.com.

      You can contact me personally by the following means:

      Packet: G8PZT@GB7PZT.#24.GBR.EU

      Email:  g8pzt@blueyonder.co.uk

      Snail:  Ms P J Dowie,
              19 Brooklands Drive,
              Wolverley Park,
              Kidderminster,
              Worcestershire.
              DY11 5EB

      I'm sorry I can't provide support by telephone, as it would take up 
      too much of my time.

      Although I endeavour to provide as much support as possible, I am 
      spending most of my time answering queries which are adequately 
      explained in the manual, or can be resolved by the use of common 
      sense.

      This prevents me from developing the software and, perhaps more 
      importantly, means the rest of my life suffers.  It was pointed out to 
      me that I am unemployed and losing the battle to keep the house and 
      car from falling apart, yet I am working hard supporting this program 
      for no financial reward, when I could be using my talents to earn 
      money.  It is therefore the people who make a financial contribution 
      who will receive priority, but I don't expect anyone to contribute 
      *before* they use the program, and I won't refuse (at the moment) to 
      support those who don't contribute.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  7

      Conventions


      CONVENTIONS USED IN THIS MANUAL
      ===============================

      Certain conventions are used in this document to avoid unnecessary 
      repetition.  They are as follows:

      |               ("or") Separates alternative options or arguments.
      <>              Encloses a mandatory argument
      []              Encloses one or more optional arguments.
      callsign        A valid amateur radio callsign, e.g. G8PZT
      dir             Directory
      dirname         Directory name
      file            
      filename        A unique file name without directory
      filespec        Specifies one or more files, with or without directory        
      he              Represents both "he" and "she"
      path            A fully qualified directory path            
      pathname        A full directory plus filename.
      string          A contiguous sequence of non-whitespace characters.
      text            One or more strings separated by whitespace.
      whitespace      Spaces, tabs or newlines

      Examples:  DIR [ filespec ]  - DIR command has one optional argument,                                
      which may be a file or file group                                
      description, with or without directory.


      In cases where a pathname is required, if only a filename is given, 
      the program's working directory is assumed.

      ======================== END OF SECTION 1 ============================
































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  8

      Installation


                     SECTION 2 - INSTALLATION & CONFIGURATION
                     ========================================

      I won't bother providing detailed instructions, since every 
      installation will be different and you won't read this anyway, unless 
      you're feeling really bored ;-)


      MACHINE REQUIREMENTS
      ~~~~~~~~~~~~~~~~~~~~
      There are no hard rules about this; it depends how many ports you 
      want, how heavily the system will be loaded, what facilities you 
      require etc.  I have tried to make it as flexible as possible.

      Xrouter *will* run on a 512k floppy drive XT with monochrome display, 
      but for best results anything above and including a 640k AT-class 
      machine with EGA colour display is ideal.  A hard drive isn't 
      essential, but is recommended.  My system happily runs 14 ports on a 
      12MHz '286 with 20Mb hard drive, but if you have lots of fast ports 
      (i.e. better than 9k6 *average* throughput) or HDLC cards you may need 
      something faster.  The use of 16550a-type COM ports is recommended.

      Processor:     8088/80x86/Pentium
      Clock:         4.77 and above
      Memory:        512k minimum.
      Video:         MONO/CGA/EGA/VGA 
      Drives:        At least a floppy. Hard drive recommended.
      Ports:         At least one COM port or Ethernet card is required.

      The program does not use expanded/extended memory, but you may wish to 
      use it for a ram drive if you don't have a hard drive.  This will 
      speed things up, because help, info, manual, and domain lookup files 
      are all accessed from disk.  You would arrange for autoexec to create 
      a ramdrive, copy all Xrouter's files to it, then run Xrouter from the 
      ramdrive.


      OPERATING SYSTEM
      ~~~~~~~~~~~~~~~~
      Xrouter requires MSDOS v3.2 or above.  It will also run on DRDOS, 
      and Linux (using DOSEMU).

      It will run in a Win95/98 DOS window, providing no other window uses 
      com ports sharing the same IRQ.  It has not been tested with later 
      versions of Windows.  If you wish to use the application interface, 
      you must run Xrouter within a Windows (or Desqview) environment.

      I realise that there is an ever increasing number of people who have 
      only ever used Windows and know nothing about DOS.  They may have 
      unwanted machines lying around with Windows installed, and may think 
      that they can't use them to run Xrouter, whereas in fact they can.  

      All they need to do is use a text editor such as Notepad to edit the 
      file C:\MSDOS.SYS, changing the line "BootGui=1", to "BootGui=0".  
      This file sometimes has the attributes "Hidden", "Read-only" and 
      "System", so it may be necessary to edit the file attributes first, to 
      allow Notepad to edit it.  The machine will subsequently boot to DOS 7 
      which is fine for Xrouter.






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  9

      Installation


      ALTERNATIVE MODELS
      ~~~~~~~~~~~~~~~~~~
      Because Xrouter is a complex program, occupying a large portion of the 
      640k DOS "base memory", there is not much free memory left to work 
      with.  This is an issue especially when the external Ethernet drivers 
      and application support interface are loaded.

      One solution would be to re-write the entire program to use Protected 
      Mode.  However, this is a huge undertaking and some of the low-level 
      interrupt handling code would be difficult to translate.  Some of this 
      code is hand-optimised because timimgs are really critical, and as 
      there are a lot more overheads involved in handling interrupts in 
      protected mode, performance may suffer.

      Another option is to use Expanded Memory.  Unfortunately, not much of 
      Xrouter's storage requirements can be handled this way due to the 
      limited memory page size and the need to page memory in and out.

      A further option is to migrate to Windows or Linux.  Whilst I do 
      intend to do this, I do not wish to stop supporting DOS.

      Since the rquirements of each sysop are very different, there are many 
      features that are useful to some sysops, but are just wasted space as 
      far as others are concerned.  For example, if you run an RF-only 
      system, you won't need Dial-Up-Networking.  If you don't use SCC 
      cards, then the large amount of SCC support code is just taking up 
      valuable space.

      I have therefore begun implementing alternative models, so that you 
      can choose the model which best suits your requirements.

      Model 1   - is the full version.

      Model 2   - omits Dial Up Networking.

      Model 3   - omits DUN and PPP.

      Model 4   - omits DUN, PPP, PMS, Applications, YAM and SCC support.

      Model 5   - omits DUN, PPP, PMS and SCC.


      Further models may be added later, to cater more specifically for 
      common configurations, e.g. BBS support, Hilltop router, APRS support, 
      etc.



















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  10

      Installation


      DIRECTORY STRUCTURE
      ~~~~~~~~~~~~~~~~~~~
      All files and directories required by the system are located within a 
      single directory which can be located anywhere and have any name.  For 
      the purposes of this document I will assume it is named XROUTER.

      The directory should contain at least XROUTER.EXE and XROUTER.CFG.  
      All other files are optional and the system will run without them.

      If you want to grant access to remote sysops you will need to add 
      PASSWORD.SYS.  If you want to store IP routing info, you will need 
      IPROUTE.SYS.  If you want domain lookup, add DOMAIN.SYS.  If you want 
      to control TCP/IP access, add ACCESS.SYS and USERPASS.SYS.

      If you want the full help system, create a sub-directory called HELP 
      and place all the .HLP files into it.  Note that the help for the CHAT 
      server goes in sub-directory HELP/CHAT, FTP server help goes in 
      HELP/FTP and the APRS messaging help goes in HELP/AMSG.

      If you want an INFO system, create the INFO directory.  I have 
      included some sample .INF files to give you some ideas.

      If you want the online manual, create the MAN directory and put the 
      *.MAN files into it.


      SETTING UP
      ~~~~~~~~~~
      The software will be supplied in ZIP format.  Within the zip file, the 
      docs, help, manual and http files will be in separate zip files to make 
      it easier for you to select the components you require.  You may create 
      the directory structure manually and unzip the components into it, or 
      you may use PKUNZIP -d to create the sub-directories.

      Once the required files are installed in the correct places, your next 
      job is to edit the configuration file XROUTER.CFG, to suit your 
      requirements.  The file is heavily commented, so it should be obvious 
      what needs changing, especially if you have previously used BPQ node.

      If you have installed PASSWORD.SYS, IPROUTE.SYS or DOMAIN.SYS they 
      will also need editing to suit your requirements.  Again, they are all 
      self-documenting, but are also detailed elsewhere in this document.





















     
       XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  11

      Running Xrouter


      RUNNING THE PROGRAM
      ~~~~~~~~~~~~~~~~~~~
      If you have defined any EXTERNAL type drivers in XROUTER.CFG, they 
      must be loaded first.  If you forget to load them, the machine will 
      crash, so it is advisable to start Xrouter from a batch file in this 
      case, to ensure things are loaded in the correct sequence.

      If you are using YAM modem(s), run YAMINIT to upload the FPGA 
      configuration(s) to the modem(s).

      Once the drivers are loaded, start XROUTER.EXE.

      The program will read its configuration from XROUTER.CFG, then look 
      for IP routing information from IPROUTE.SYS and saved nodes/routes 
      information from file XRNODES.  Finally it will read the commands in 
      BOOTCMDS.SYS if it is present.  If you've got everything correct you 
      should see the console display.  If not, please take note of the error 
      messages, especially the line number where the error occurred.

      Don't be too ambitious, especially if you don't understand what you're 
      doing.  It's no good hanging applications and pipes onto the system 
      until you've got it running properly!  It is best to start with one 
      interface and port, adding the rest as each previous one is proven.  

      Don't make too many changes at once - if things go wrong, you won't 
      have a clue where you made the error.


      STOPPING THE PROGRAM
      ~~~~~~~~~~~~~~~~~~~~
      Alt-X stops the program, saving the nodes and routes tables to file 
      XRNODES just before it exits back to DOS.  It is protected by an 
      irritating "are you sure" challenge. 































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  12

      Console Facilities


      CONSOLE DISPLAY
      ===============

      The screen will display a single "virtual console".  Each virtual 
      console has the following format:

      There is a single-line "status bar" at the top of the screen and a 
      single-line "menu bar" at the bottom.  Immediately above the menu bar 
      is a single "command entry" line.  The remaining 22 line central 
      section is where monitored and received information is displayed, and 
      this section is ANSI compatible.  

      The status bar shows the date and time, the virtual console number, 
      the console callsign, the version number, the router's callsign and 
      alias, and the amount of free memory.  The menu bar shows the most 
      important keys.

      The text and background colours of the various sections are fully 
      configurable.  Default settings are built into the program, and can be 
      overridden by entries in the global section of XROUTER.CFG.  The 
      defaults can be further modified for individual consoles by adding 
      console definition blocks.  

      You may specify a different callsign for each console (used when 
      making outgoing connections), or use the same callsign for each one.


      CONSOLE KEYS
      ~~~~~~~~~~~~
      Here's a summary of the keys - they are fully explained later.

      <F1>                Display console help window.
      <F2>                Toggle monitoring on/off.
      <F3>                Select port(s) to monitor. (MPORT)
      <F4>                Select monitored protocols. (MMASK)
      <F5>                Toggle disk capture on/off.
      <ESC>               Cancel operation / Disconnect.
      L/R arrow           Select previous / next console.
      U/D arrow           Scroll back/forward by one line.
      <PgUp>/<PgDn>       Scroll back/forward by one page.
      <End>               End scrollback.
      <Ctrl-LeftArrow>    Previous command.
      <Ctrl-rightArrow>   Next command.
      <Alt-F9>            DOS shell
      <Alt-B>             Invoke screen blanker
      <Alt-C>             Clear screen.
      <Alt-X>             Exit program.


      <F1> - Help
      ~~~~~~~~~~~
      Pressing <F1> pops up a window with the above information on it.  The 
      <ESC> key closes that window when you've finished with it.  The 
      contents of the window are context-sensitive, i.e. they will vary 
      according to what you were doing when you press the <F1> key.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  13

      Console Facilities


      <F2> - Monitoring
      ~~~~~~~~~~~~~~~~~
      The <F2> key provides a quick way to turn monitoring on and off, i.e. 
      it has the same function as BPQ's <F1> key.  Note that I didn't follow 
      BPQ here because *most* software uses <F1> for help.


      <F3> - Monitor port
      ~~~~~~~~~~~~~~~~~~~
      The F3 key selects the ports to be monitored.  At the moment only 
      ports numbered 1 to 32 can be monitored.  Upon pressing this key you 
      will be invited to enter a number or string of numbers representing 
      the combination of ports to monitor.  If you press <F1> at this point 
      a pop-up window will show you the following information:

      To select port(s) to monitor, add together the following hex values:
       
               Port  HEX    Port  HEX    Port    HEX    Port      HEX
                 1     1      9   100     17   10000     25   1000000
                 2     2     10   200     18   20000     26   2000000
                 3     4     11   400     19   40000     26   4000000
                 4     8     12   800     20   80000     28   8000000
                 5    10     13  1000     21  100000     29  10000000
                 6    20     14  2000     22  200000     30  20000000
                 7    40     15  4000     23  400000     31  40000000
                 8    80     16  8000     24  800000     32  80000000

               e.g. #12 will monitor ports 5 and 2.

      Alternatively you may enter a single decimal port number, or a 
      combination of ports separated by "+" e.g. "1+5+23".

      You may cancel the operation by pressing the <ESC> KEY.


      <F4> - Monitor Mask
      ~~~~~~~~~~~~~~~~~~~
      The <F4> key invites you to enter the monitor mask, i.e. the protocols 
      you wish to monitor.  Pressing <F1> at this point brings up the 
      following information:

      Add together the following HEX values:

         0001 - Incoming frames          0100 - TCP
         0002 - Outgoing frames          0200 - UDP
         0004 - Data Payload             0400 - KISS
         0008 - AX25 layer2 frames       0800 - SLIP/PPP
         0010 - Netrom                   1000 - Ethernet
         0020 - ARP                      2000 - Passall
         0040 - IP frames                4000 - HEX Dump
         0080 - ICMP

      E.g. 0101 will show incoming TCP frames only, while 0141 will show the 
      underlying IP frames as well.  The default setting is 03FF, which 
      shows all incoming and outgoing traffic from AX25 layer 2 upwards.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  14

      Console Facilities


      <F5> - Disk capture
      ~~~~~~~~~~~~~~~~~~~
      The <F5> key toggles disk capture on and off.  Captured text goes to 
      file CAPTURE.TXT.  When capture is on, everything which appears on the 
      central 22 line section of the console is sent to file.  You can make 
      it more specific using MMASK and MPORT.  (Note this is a completely 
      separate operation to the transaction logging enabled by setting LOG=1 
      in the configuration file.)  Make sure your disk is fast enough and 
      has enough space, otherwise Xrouter's performance will be impaired.

      <ESC> - Escape
      ~~~~~~~~~~~~~~
      The <ESC> key "backtracks" if you have pressed <F1>, <F3> or <F4>, or 
      disconnects a console session as in BPQ.

      Switching consoles
      ~~~~~~~~~~~~~~~~~~
      The left and right "arrow" keys will switch between the virtual 
      consoles if you have enabled more than one.  The console number is 
      shown on the top status bar.  Note that when you reach the last 
      console, you wrap back to the first and vice versa.

      Review mode
      ~~~~~~~~~~~
      The up and down "arrow" keys control scrollback, along with the 
      <PgUp>, <PgDn> and <End> keys.  You must enable the scrollback buffer 
      for this to have any effect.  Scrollback or "review" mode enables you 
      to look at something which went off the top of the screen.  The 
      console won't receive anything else until you exit review mode.

      <Alt-F9> - DOS shell
      ~~~~~~~~~~~~~~~~~~~~
      <Alt-F9> temporarily suspends the program and loads a DOS shell, 
      enabling you to do things without taking Xrouter off line with the 
      consequent loss of all links and tables.  For instance you may wish to 
      format a floppy or do something which you couldn't otherwise do using 
      Xrouter's built-in PZTDOS.  You shouldn't stay "shelled out" for too 
      long, otherwise any active links will time out, and you run the risk 
      of being rebooted by the watchdog.  You need at least 70k free memory 
      to load the shell, otherwise Xrouter will report an error.

      <Alt-B> - Screen Blanker
      ~~~~~~~~~~~~~~~~~~~~~~~~
      The SAVER keyword in XROUTER.CFG specifies the screen saver timeout, 
      i.e. how long the screen will remain visible after any keyboard 
      activity.  A zero value disables the screen saver, but you may use 
      <Alt-B> to blank the screen at any time.  Pressing any key will re-
      enable the screen.

      Command History
      ~~~~~~~~~~~~~~~
      Each console remembers the last 5 commands used on that console. These 
      can be selected using the <Ctrl-LeftArrow> and <Ctrl-RightArrow> keys, 
      and actioned by hitting <RETURN>










      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  15

      Miscellaneous Topics


                         SECTION 3 - MISCELLANEOUS TOPICS
                         ================================

      These are just random notes which I haven't yet had time to organise 
      properly....  One day I'll write a proper manual!!

      INDEX to Miscellaneous Topics

       1)  Ethernet Interfaces
       2)  Yam Modem Support
       3)  Internal Interface
       4)  AGW TCP/IP Host Interface
       5)  Node/Route Table Saving
       6)  Line Editor
       7)  Help System
       8)  Info System
       9)  IP Routing
      10)  TCP/IP Services
      11)  Modulo 128
      12)  Mheard
      13)  Watchdogs
      14)  Stats
      15)  Frame Pipes
      16)  Broadcasting
      17)  Proxy Connections
      18)  AX25/Netrom -> TCP Proxy
      19)  Netrom -> AX25 Proxy
      20)  Telnet Proxy
      21)  Chat Server
      22)  Application Interfaces
      23)  Using XROUTER with Deskview
      24)  PSTN Modem Support
      25)  Dial Up Networking
      26)  APRS
      27)  APRS Messaging
      28)  APRS Server
      29)  TNC2 Emulation
      30)  AXIP Tunnelling
      31)  AXUDP Tunnelling
      32)  IPUDP Tunnelling
      33)  Xpipe
      34)  FEC
      35)  Point to Point Protocol
      36)  Dynamic Host Configuration Protocol
      37)  Dynamic DNS Update Client
      38)  TCP/IP Access Control
      39)  Routing Information Protocol
      40)  Network Address Translation
      41)  TCP/IP Stealth Mode
      42)  Netrom Interlinking
      43)  Time Domain Routing
      44)  Netrom Quality Manipulation
      45)  Web Server 
     










      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  16

      Ethernet Interfaces


      ETHERNET INTERFACES
      ===================


      Using Ethernet, Xrouters can be linked with each other and with 
      other ethernet-capable systems such as Linux, xNOS, BPQ and Windows.

      There are two options, both of which use the TYPE=EXTERNAL interface, 
      but using different PROTOCOL= settings.  The first option detailed 
      below is somewhat limited in capability:


      Option 1 - Use BPQ's ODIDRV.EXE driver
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Xrouter will interface directly to BPQ's ODIDRV program, allowing 
      AX25-only links between any number of Xrouters, and between Xrouter 
      and BPQ systems.

      For this option, the interface should be specified as TYPE=EXTERNAL, 
      PROTOCOL=HDLC, INTNUM=125 (adjust this to suit your needs). The MTU 
      should be set at 256 since ODIDRV can only handle small frames. You 
      can attach one PORT to this interface.

      You will need to obtain BPQ's ODIDRV.EXE and the appropriate bits of 
      Novell Netware, and have a reasonable working knowledge of how to set 
      it all up!  Don't ask me, because I haven't a clue :-)

      Follow the instructions in BPQ's DRIVERS.DOC for setting up the ODI 
      system.  Xrouter currently uses a fixed PID of 0x8FF, which is the 
      default value for BPQ, and frames are addressed to the multicast 
      address FF:FF:FF:FF:FF:FF, so the only change you need to make to 
      BPQ's example is to change ETH_ADDR to that value.

      The load order is as follows:

              LSL.COM         (Part of Novell Netware)
              NE1000          (Ditto - adjust to suit your Ethernet card)
              ODIDRV 125      (BPQ program.  Number must match INTNUM)
              XROUTER

      If you wish to communicate with BPQ nodes via Ethernet, the PID and 
      multicast addresses must match.

      Because ODIDRV only supports HDLC protocol, you won't be able to use 
      TCP/IP on the link unless it is first encapsulated in AX25 frames.  
      This should happen automatically if you try to route IP via the 
      ethernet port, but obviously this *encapsulated* IP cannot talk 
      directly with real TCP/IP systems which don't understand AX25.


      Option 2 - Use PZT's ETHDRV.EXE driver
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      This option allows simultaneous connection between any number of 
      Xrouters, between PZT and BPQ, and between PZT and other systems 
      capable of TCP/IP over Ethernet.  It doesn't require any Netware 
      components, and is relatively easy to set up.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  17

      Ethernet Interfaces


      The software components you require are:  ETHDRV.EXE (supplied with 
      Xrouter), an Ethernet card driver to match your card e.g. NE1000.COM 
      (You can get these free from Simtelnet), and XROUTER.EXE itself.

      The interface should be set up as TYPE=EXTERNAL, PROTOCOL=ETHER, and 
      you may set MTU as high as 1500 if you wish. Set INTNUM to a spare 
      software interrupt in the range 60 - 127 (125 is used as an example).  
      You can attach one PORT to this interface.

      If you are not familiar with Ethernet card drivers (aka "packet" or 
      "Crynwyr" drivers), 3 arguments are usually specified when starting, 
      e.g...

              NE2000 0x60 5 0x300

      Where:  NE2000  is the driver matching your card.
              0x60    is the software interrupt used to talk to the card,
                      specified in hex (0x60 is decimal 96, 0x61 is 97 etc.)
              5       is the IRQ used by the card.
              0x300   is the I/O address of the card.

      The I/O address and IRQ are often settable by jumpers on the card, 
      especially on older cards, but some cards have fixed settings.

      0x60 is the default software interrupt used by ETHDRV.EXE to 
      communicate with the card driver.  If you specify an alternative 
      number (e.g. if you have several cards), you must specify that number 
      when starting ETHDRV.

      ETHDRV.EXE normally requires a single argument, namely the INTNUM 
      which should match the one specified in the INTERFACE block.  It 
      optionally takes a second argument, if you wish to use an interrupt 
      other than 0x60 to communicate with the card driver.

      e.g.    ETHDRV 125              (intnum=125, software int=0x60)
              ETHDRV 125 0x63         (Using a different card interrupt)
              ETHDRV  125 -U          (To unload the driver)


      My startup sequence is as follows:

              NE2000 0x60 5 0x300
              ETHDRV 125              (Interface intnum=125)
              XROUTER


      Ethernet Card Sharing
      ~~~~~~~~~~~~~~~~~~~~~
      Unfortunately the present version of ETHDRV will not share an ethernet 
      card with other applications (e.g. Windows), so if you are using it on 
      a Windows machine you will either have to disable Windows' use of the 
      Ethernet card, or simply install a second card.  I will address this 
      issue in due course.











      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  18

      YAM Modem Support


      YAM MODEM SUPPORT
      =================

      Xrouter includes support for the YAM modem, and the interface should 
      be defined in XROUTER.CFG as follows:

      INTERFACE=10            <--- Adjust to suit
              TYPE=YAM
              COM=1           <--- COM port to which YAM is connected
              MTU=256
              SPEED=1200      <--- Radio speed (not serial comms speed!)
              PROTOCOL=HDLC   <--- Only HDLC supported at present
      ENDINTERFACE

      For standard COM1 to COM4, you don't need to specify IOADDR and 
      INTNUM, but for COM5 to COM16 or non-standard COM1 to COM4 they must 
      be included.  It is permissible to omit the COM number if IOADDR and 
      INTNUM are both specified.

      SPEED is the *radio* baud rate and should match the modem's 
      configuration, otherwise TXDELAY and TXTAIL timings will be wrong.  
      You can omit speed and define RFBAUDS in the port instead.  
      Communication between between Xrouter and YAM always takes place at 
      19200 bauds.

      PROTOCOL *must* be HDLC.  No other protocols are supported at present.

      Each YAM interface supports only one port. You must use a separate 
      interface for each port / YAM board.

      Port Settings
      ~~~~~~~~~~~~~
      CHANNEL is ignored, but (I think) must be present.  FULLDUP can be 
      used - the YAM is capable of full duplex operation, but SOFTDCD is 
      ignored because it has no meaning for a YAM board.  YAM will INTERLOCK 
      with other YAM interfaces and with all types of SCC, but not with 
      TNC's since Xrouter cannot know when a TNC is transmitting.

      Notes
      ~~~~~
      The YAM modem does not require a 16550 UART.  It uses TXD, RXD, RTS, 
      CTS, DTR, DSR, RI and DCD so a full 8 wire plus ground cable is 
      required.  Some PC's either don't provide enough DC voltage/current to 
      supply the YAM board or the RS232 inputs sink too much current.  This 
      is a hardware problem, not an Xrouter problem - I used an external 
      supply to the YAM board to overcome it.

      Xrouter does not program the FPGA therefore YAM modems must be 
      initialised by running YAMINIT (supplied with the modem) before 
      starting xrouter.  It is probably best to do this in the startup batch 
      file, e.g. "YAMINIT yam12v11.mcs 1" will program the modem for COM1 
      with 1200 baud RF speed. The YAM is capable of 1200, 2400 or 9600 baud 
      simply by choosing the appropriate .MCS file.

      For further information you must refer to the YAM documentation - it's 
      not my job to teach you all about someone else's project.








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  19

      INTERNAL Interface


      INTERNAL INTERFACE
      ==================

      The INTERNAL interface type allows applications using the BPQ HOST 
      application interface (AI) to interconnect with Xrouter using HDLC, 
      as if via a wire link.

      Why is it necessary?
      ~~~~~~~~~~~~~~~~~~~~
      The BPQ HOST Application Interface, implemented in Xrouter, allows 
      applications (e.g. a BBS) running "above" Xrouter to "connect" to the 
      Xrouter's command interface and issue plain text commands.  It also 
      allows the applications to receive incoming connects from users.  And 
      lastly, it allows applications to directly access the radio ports 
      using raw HDLC.

      Unfortunately, BPQ's interface was designed for an AX25 system, and 
      does not specifically cater for TCP/IP.

      If an application (e.g. PZTBBS) has its own TCP/IP stack, it needs a 
      way of exchanging datagrams with Xrouter, to enable users to telnet 
      from BBS to router and vice versa, among other things.

      For example, if Xrouter has an Ethernet port, the application may need 
      to route datagrams via it, but the BPQ host AI only allows the 
      application to talk HDLC to AX25 ports.

      Unlike other interfaces, which connect Xrouter with the "outside" 
      world, the INTERNAL interface connects Xrouter with the "inside" 
      world, i.e. other applications on the machine.  It is similar in 
      function to a wired KISS link between two machines, except that it 
      runs raw HDLC not KISS.

      Anything sent by Xrouter, on the port attached to the INTERNAL 
      interface, is sent to the host interface, and that port effectively 
      receives from the host interface.  Thus, if port 15 is an INTERNAL 
      port, any application which wants to talk HDLC to Xrouter can do so by 
      interacting with the BPQ "raw" host AI, using "radio port" 15.

      The port number must be between 1 and 127 because BPQHOST application 
      interface only allows 7 bits for the port number.

      Setting Up An INTERNAL Interface
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The entries in XROUTER.CFG should be similar to this:

              ;
              INTERFACE=5     
                      TYPE=INTERNAL
                      PROTOCOL=HDLC
                      MTU=256
              ENDINTERFACE
              ;
              PORT=7
                      ID=Internal link with GB7PZT
                      INTERFACENUM=5
              ; etc...
              ENDPORT






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  20

      INTERNAL Interface


      The interface and port numbers are for illustration only, and you should
      use the ones appropriate for your system.

      The only PROTOCOL supported at present by INTERNAL interfaces is HDLC.
      Other protocols will be added if anyone needs them.

      Only one PORT may be attached to an INTERNAL interface, so the CHANNEL
      keyword is not necessary.

      In the above example, BBS application GB7PZT is configured to send its
      TCP/IP traffic, encapsulated in AX25, to "radio port 7" on the
      BPQHOST interface.  Xrouter receives it as if it came off-air, and
      sends replies back to port 7 whereupon they are received by GB7PZT.



















































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  21

      AGW TCP/IP Host Interface

      AGW TCP/IP HOST INTERFACE ON PORT 8000
      ======================================

      This allows those applications (e.g. AGWTERM, UI-View etc.) which
      are capable of using AGWPE's TCP/IP host interface, to use Xrouter
      instead of AGW "Packet Engine".

      Thus you may for example run your Xrouter 24/7 on any old DOS machine,
      Ethernet linked into your home LAN, whilst using modern Windows-based
      applications on another LAN machine to access the radios.
      
      Unfortunately, although Xrouter will run in a DOS window within Windows
      there is no known way, at present, of interfacing Xrouter directly
      (i.e. internally) to the Windows TCP/IP stack, so you cannot use the
      LOCALHOST address to communicate with the Xrouter's AGW host interface.
  
      I have personally tested it with AGWMON, AGWTERM and UI-View, and would
      appreciate reports from anyone who can test it with other AGW apps.



























      



















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  22

      Node/Route table saving
      
      Nodes/routes table saving
      =========================

      The Nodes & routes tables are saved to file XRNODES 1 minute after 
      starting the program, and at global NODESINTERVAL (usually 1 hour) 
      intervals thereafter.  The SAVENODES command dumps the node table at 
      any time, and the tables are automatically saved when you exit the 
      program using <ALT-X>.  Thus if you exit and restart you will not lose 
      the tables, only the active links.

      You can specify an alternative filename when using the SAVENODES 
      command.  For example, you might want to make a periodic backup of the 
      nodes table, from which things can be restored if the table gets empty. 
      (a radio failure will cause nodes to expire from the table, and you 
      may wish to get it restarted quickly after fixing the radio)

      The LOADNODES command enables the table to be loaded from any file, at 
      any time.

      Remote Tracing
      ~~~~~~~~~~~~~~
      Remote sysops may invoke tracing using the MONITOR command, but this 
      feature should be used with caution.  Tracing generates a lot of data, 
      and the link should be capable of handling it.  It is mainly intended 
      for use on TTY (wire) links, but can be used over any connection.

      A remote sysop is prevented from tracing any activity on the port upon 
      which he is uplinked.

      Only one remote sysop may receive tracing at any one time.


      ANSI
      ~~~~
      The console will respond to ANSI, so you can have full colour terminal 
      sessions with ANSI-capable systems such as PZT BBS.  ANSI sequences 
      are not (yet) generated from the keyboard.























      




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  23

      Line Editor


      LINE EDITOR
      ===========

      The line editor, invoked from DOS mode with the EDIT command, allows 
      any text file to be viewed and edited by local or remote sysops.

      There is no fixed limit on the size of file which can be edited - it 
      depends on available memory.

      When the line editor is invoked, the filename, size and number of 
      lines is displayed, followed by the editor prompt.  If the editor 
      fails to operate, you may be short of memory.  Lines of up to 255 
      characters in length may be accommodated.  Longer lines will be split 
      into separate 255 character sections.

      The file contents are viewed using the "List" command.  Each line 
      is numbered, so that you may use the Append, Insert, Delete, Move, and 
      Copy functions to manipulate the text.

      Because the file is loaded into, and edited in memory, you may abort 
      the edit at any time without affecting the original file.  The 
      modified text is only written to disk by a "save" or "write" command.  
      You may optionally specify a different filename to save into.

      All filenames are relative to the "current working directory" you were 
      logged into when the editor was invoked, but you may specify full 
      pathnames if you wish.

      Line editor commands are detailed in the command reference section.



































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  24

      Help & Info Systems

      HELP SYSTEM
      ===========

      Basic syntax help for most commands is built into Xrouter, and is 
      available using the query (?) command, e.g. "? N" will display the 
      syntax of the NODES command.

      More detailed help is implemented as separate files in the HELP 
      directory, allowing you to customise it and add extra help topics as 
      desired.  Each topic occupies a separate file, with the filename the 
      same as the topic name.  The "H *" command displays a sorted directory 
      of all the files ending in .HLP.

      Within the .hlp files, lines beginning with a semicolon ';' are not 
      displayed to users, so you can use them for comments, such as file 
      modification details.

      You may choose to omit some or all of the help files if you are 
      running a floppy-only system.

      In addition to the HELP system, sysops will find more information in 
      the online sysop manual using the MAN command.


      INFO SYSTEM
      ===========

      When the user issues the "I" command without any arguments, the text 
      defined by INFOMSG is sent to him.

      However, this command may also form the entry point for a much larger 
      and more comprehensive information system which the sysop may 
      implement how he wishes.  For example you may wish to include details 
      of the local packet network and clubs, and maybe a set of tutorials on 
      general packet topics...

      In order to do this, the INFO directory must exist and must contain 
      the desired info in the form of text files with the extension .INF.  
      The user will then, after using "I" by itself, be invited to enter "I 
      *" to list the available info topics.  If the user then enters that 
      command, the filenames (minus the .INF) will be displayed in 
      alphabetical order, and the user will be invited to read the files 
      using the "I <topic>" form of the command. 

      The filename should be relevant to the contents, within the 
      constraints of 8 DOS characters.  You should try to keep each file 
      concise in order to save air time, preferably breaking complex 
      subjects into a series of small files with "see also" references to 
      link them.  It is very frustrating for users to begin reading a file 
      only to discover it's not of interest, and then having to wait a long 
      time for it to finish!  You may use ANSI or HTML in the files, but not 
      pure binary. 

      Within the .INF files, lines beginning with a semicolon ';' are not
      displayed to users, so you can use them for comments, such as file
      modification details.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  25

      IP Routing


      IP ROUTING
      ==========

      IP routing is an integral part of Xrouter, and is fairly simple to 
      set up.  You may not see the point, but others will thank you for 
      doing so!

      In order to enable this function you must have an IP address.  If you 
      don't already have one, contact your local IP co-ordinator who should 
      be only to pleased to assign you one.  You should be able to find your 
      local co-ordinator via the UKIP web site or a packet message.

      Put your IP address in the IPADDRESS= line in XROUTER.CFG.

      Xrouter normally uses a single IP address for all ports, but if you 
      need different addresses on different ports you may specify an 
      additional address for any port, by including an IPADDRESS= line in 
      the port definition.

      Example: IPADDRESS=44.131.91.245

      The other thing you need to do is define the routing in IPROUTE.SYS -
      see the explanation in the section which relates to that file.  If you 
      don't know what routes to enter, your local co-ordinator should be 
      able to help.

      Having to enter a full IP address when using the PING and TELNET 
      commands is tedious, so you should put some entries in DOMAIN.SYS to 
      perform the translations between host names and IP addresses.  For 
      example, I have CNAME entries which translate the local node aliases 
      into IP addresses. (see later section on DOMAIN.SYS)

      If you have reasonably fast access (under 10 sec) to an external DNS 
      (Domain Name Server), you may enable its use by specifying its IP 
      address using the "DNS=" keyword in XROUTER.CFG.

      Example: DNS=162.31.224.1

      Finally, you should set Xrouter's host name for TCP operations, using 
      the "HOSTNAME=" keyword in XROUTER.CFG.  This is optional, and if you 
      omit it, it will default to "NODEALIAS:NODECALL".

      Example: HOSTNAME=g8pzt.ampr.org

      The "Domain Suffix" is currently fixed at ".ampr.org".  Commands such 
      as "telnet g8pzt" will be automatically extended to "telnet 
      gb7pzt.ampr.org", but "telnet fbb.org" will be left alone because the 
      address is already complete.
















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  26

      TCP/IP Services


      TCP/IP SERVICES
      ===============

      ECHO Server
      ~~~~~~~~~~~
      If a user TELNETs to TCP port 7, anything he sends will be echoed back 
      to him.  This is a useful tool for testing TCP/IP systems.  It 
      requires no setting up, other than the IP routing.


      DISCARD Server
      ~~~~~~~~~~~~~~
      This uses TCP port 9, and merely dumps anything sent to it.  It is 
      another useful tool when developing and testing TCP/IP systems.  It 
      requires no setting up other than the IP routing.


      FINGER Server
      ~~~~~~~~~~~~~
      This allows users to find information about other users.  It uses TCP 
      port 79 and reads text files for local users from the FINGER sub-
      directory.  It may also be accessed using the FINGER command at the 
      main prompt.  If the user isn't local, it attempts to establish 
      communication with the Finger server on the specified host.

      This server is only partly developed at present, and future versions 
      will give more information.  For the moment, if you wish to activate 
      this feature, create a FINGER sub-directory within the XROUTER 
      directory, then simply create a text file for each user, using the 
      user's callsign or any other preferred "hostname" as the filename.  
      The files can contain anything you like, typically the user's name, 
      location, station details, QSL information etc.

      For example the file finger/g8pzt might contain the text:

      Name: Paula
      Qth:  Kidderminster, Worc's IO82VJ
      Age:  (withheld ;-)
      Other: Sysop G8PZT:KIDDER router, Sysop GB7PZT BBS, Fourpak
             Secretary, Unemployed software author with special interest in
             comms software.  Author of: G8PZT AX25/IP BBS, Xrouter,
             Uk White pages system, PEARL Off-line reader for Packet 
             Radio...


      RLOGIN
      ~~~~~~
      The secure password challenge/response mechanism, using the "@" 
      command, is inconvenient for frequent use, and unnecessary in cases 
      where the remote sysop can access the router via a "secure" link such 
      as a wire link between two systems.  Therefore a plain text login 
      system is provided for these cases.  This uses a TELNET connection to 
      TCP port 513.  The user is prompted to enter his callsign, and is then 
      asked for his password.  If the two match with an entry in 
      PASSWORD.SYS, the user is granted access with sysop status.  Needless 
      to say, this facility should *NEVER* be used over a radio link, 
      otherwise someone will see the password.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  27

      TCP/IP Services


      FTP server
      ~~~~~~~~~~
      An FTP server is included within the program, allowing remote sysops to 
      upload, download, list, rename and delete files, create and remove 
      directories etc., which is useful when the router is located somewhere 
      inaccessible, such as a garage or remote hilltop.  For example, new 
      configuration and program files may be uploaded, and the system can 
      then be restarted to perform a remote upgrade.

      The FTP server is not available to non-sysops.  It is protected by a 
      password grid, and is only accessible to those who have a password 
      registered in PASSWORD.SYS.

      Access to all drives and directories is unrestricted, because the FTP 
      server is intended only for system maintenance, not as a public file 
      repository.

      The server uses standard FTP commands, with the exception of the USER 
      and PASS login sequence, which are necessarily tailored for use on a 
      publicly visible channel.  The password prompt presents the user with 
      a matrix of 5 lines of 5 numbers, and the response may be either a 
      string of characters, as with secure sysop login, or the full password 
      in plain text.  Needless to say you would only use the plain text 
      password on a secure channel.

      Although this is  DOS program, the server format is "Windows_NT" 
      because that is the format which gives the best results with the 
      widest variety of FTP clients.

      In order for the FTP server's HELP command to work, you must place the 
      ftp help files in the HELP/FTP directory.

      The FTP server commands are described in detail in the sysop command 
      reference section.


      Domain Name Server
      ~~~~~~~~~~~~~~~~~~
      A rudimentary DNS (Domain Name System) server is built into Xrouter, 
      which will answer DNS queries from other systems via the standard UDP 
      port 53.

      The server only responds to requests directed at the *main* IP 
      address, and will only answer one query per message. Only standard 
      queries for type A are currently answered.  Recursion is supported.  
      Other query types will be supported in a later version.

      The server will act as a DNS proxy, allowing Xrouter to function as an 
      Internet Connection Sharing router for a network of machines.  The 
      machines on the local intranet send their DNS queries to Xrouter, 
      which either resolves them using its own DNS lookup, querying an 
      external DNS if necessary.












      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  28

      Modulo-128


      MODULO-128
      ==========

      Modulo-128 is an extension to AX25, giving sequence numbers from 0 
      to 127 instead of the usual 0 to 7.  This allows a much bigger 
      MAXFRAME (up to 63) to be used, and is primarily of use on good links.

      On conventional (Modulo-8) ax25 links, much of the inter-node traffic 
      consists of short frames containing level 4 control information.  
      These frames are interspersed with data-bearing frames, which 
      themselves may be only partly full.  Thus a router may transmit 7 
      frames in one go, but the transmission may only be a few hundred bytes 
      in total.  This is inefficient, due to the delays associated with 
      channel access, txdelay, txtail, resptime etc.  On fast, error-free 
      links the data arrives in short bursts, separated by long gaps of 
      inactivity.

      With Modulo-128, many more frames can be packed into a single 
      transmission, so the channel overheads become less significant.  

      Because the largest allowed Maxframe value for Modulo-128 is 63, there 
      can never be any sequence number ambiguity, and this allows frame "re-
      sequencing".  With normal AX25, if the first frame of a multi-frame 
      set is lost, the whole set of frames has to be re-transmitted.  If 
      Modulo-128 is used however, the "good" frames are stored by the 
      recipient, and only the lost frame is re-sent.  Together with the 
      stored frames, this completes the set, and the whole set can be 
      acked.  This is a much more efficient strategy.

      Xrouter is capable of Modulo-128, and frame resequencing.  Modulo-128 
      frames are displayed on the trace screen as "EAX25" (Extended AX25) 
      instead of "AX25", and are initiated by a new frame type "SABME" (Set 
      Asynchronous Balanced Mode Extended).  You will notice the sequence 
      numbers being displayed as "<I R25 S32>"

      The method of activation isn't fully decided as yet.  If a caller 
      requests Modulo-128 (by sending an SABME frame), Xrouter will respond 
      with <UA> and go into Modulo-128 mode.  The strategy for outgoing 
      links is more complex.  If the port maxframe is greater than 7, *ALL* 
      level 2 downlinks on that port will be tried using Modulo-128 (i.e. 
      Xrouter will send <SABME> instead of <SABM>.  This is not recommended 
      on user ports, since hardly any users are EAX25 compatible.

      If the called system is Modulo-128 capable, the correct response to 
      <SABME> is <UA>, otherwise the correct response according to the AX25 
      protocol is either <DM> or <FRMR>, which will cause Xrouter to fall 
      back to normal Modulo-8 AX25.  Most systems do answer correctly, but 
      there may however be some systems which do not properly implement 
      AX25, for example by silently discarding <SABME> frames, and it will 
      not be possible to link to these systems if Maxframe is greater than 
      7.  I hope to address this in a future version.

      It is more likely that Modulo-128 would be used on inter-node links 
      with other Xrouters, Linux and PE1CHL boxes, so to activate it, 
      simply define a maxframe > 7 for those routes which require it. If the 
      port is dedicated to one link, you can set the port maxframe > 7 
      instead.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  29

      MHEARD


      MHEARD
      ======

      The MHEARD facility lists recently heard stations, and may be enabled 
      or disabled for any port.  It records callsigns in order of reception, 
      with the most recent at the top of the list, along with other useful 
      information, such as the date/time and the number of frames heard.

      This is useful for users to discover who else the router can hear, to 
      aid the search for suitable digipeaters, and to diagnose problems.  

      Even on linking-only ports, where there is only usually one partner, 
      it provides a useful indication when the frequency is being 
      encroached, either by deliberate squatting, unauthorised attempts to 
      link, or lift conditions.  I recommend that you enable MHEARD on all 
      ports.

      If you have included an APRS-style position report in your ID beacon, 
      Xrouter will know its own position and will display position, distance 
      and bearing for any stations which broadcast APRS positions.  This is 
      a great aid to network mapping, and it would be nice if everyone were 
      to make use of APRS.

      If the station was heard via a digipeater, the digipeater call is also 
      shown, and the letter "D" is shown in the "type" field.  If the heard 
      station is a node, the letter "N" is displayed, if it is sending 
      IP traffic, "I" is shown, and if it is sending ARP traffic, "A" is 
      shown.

      Within XROUTER.CFG, the MHEARD= keyword is used in each port 
      definition block to enable or disable the MHEARD facility and to set 
      the size of the list.  For example "MHEARD=50", enables it and sets 
      the table size to record a maximum of 50 callsigns.  If the keyword is 
      omitted, the default is 15 callsigns.

      You can control what sort of callsigns are recorded in the MH list 
      using the MHFLAGS= keyword.  The default is 255 (show everything), and 
      the number is formed by adding the following values:

           1    Show directly heard stations
           2    Show directly heard digipeaters
           4    Show digipeated stations


      For example "MHFLAGS=3" would show directly heard stations and 
      digipeaters, but not the stations heard via digipeaters.

      The MHEARD list is available to sysops and users alike, using the MH 
      command (see command reference section).

      A port's mheard list may be cleared by using the MHCLEAR <port> 
      command.  This would typically be used if the port was changed to 
      another frequency.  You may clear all MH lists by specifying port 0.
       










      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  30

      Watchdogs


      WATCHDOGS
      =========

      Xrouter has an inbuilt software watchdog.  If enabled, this will 
      attempt to reboot the computer if the code "locks up".

      A lock-up may be caused for example by faulty external driver or 
      third-party server software, by certain hardware errors, or by "soft" 
      errors due to RF break-through, supply spikes or ionising radiation.

      Additionally, a DOS "shell" session of excessive duration is treated 
      as a lock-up because the operator may have abandoned the console 
      without terminating the shell, and the shell may be running a process 
      which cannot be safely terminated.  Therefore a complete reboot is the 
      safest option.

      The software watchdog is enabled by entering a non-zero setting in the 
      "watchdog interval" parameter in INIT.SYS (see elsewhere).  You should 
      not use too low a setting, otherwise the system may reboot if an 
      external process takes too long to run, or if you shell out to DOS 
      using the F9 key.  120 sec (2 minutes) is a suggested figure.

      The software watchdog cannot work miracles, because sometimes the 
      crash is too severe, and sometimes the computer will not respond to a 
      "warm" reboot.  The use of an additional "hardware" watchdog is 
      recommended.

      Therefore, in addition to the software watchdog, the system will 
      supply pulses via a spare parallel port, to drive an external hardware 
      watchdog.  This would for example consist of an opto-isolator driving 
      a monostable circuit such that if the pulses ceased for more than 120 
      secs (must be longer than the boot-up time!) the mains supply would be 
      interrupted for long enough to cause a "cold" reboot (say 5 secs).

      The hardware watchdog pulses are enabled by specifying a suitable 
      parallel port address for the WATCHADDR parameter.  The D0 pin will be 
      toggled at 18 Hz, D1 at 9Hz, D2 at 4.5 Hz etc.  You can drive an 
      optoisolator from one of these pins.

      A hardware watchdog should detect the presence or absence of an AC 
      signal from the parallel port.  A sustained high or low value 
      indicates a fatal lock-up.  Your circuit should include a delay long 
      enough to allow the system to reboot, including all programs (e.g. 
      chkdsk) which are run at boot up.  This is to prevent it from 
      triggering again before the pulses are established, causing an endless 
      reboot cycle!

      Warning:  If you run Xrouter in a Windows95 environment, the frequency 
      of the hardware watchdog pulses will be greatly reduced (by a factor 
      of 9) if the window is backgrounded.  The software watchdog interval 
      is similarly inflated, so a 2 minute timeout will become 18 minutes.  
      I have yet to find a solution to this problem, which is due to Windows 
      not properly emulating certain BIOS functions.  However, I feel it is 
      unlikely that anyone would want to run a remote system (and thus 
      require watchdogs) on a Windows system, due to stability 
      considerations!








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  31

      Stats


      STATS
      =====

      The following section attempts to explain some of the figures produced 
      by the "stats" command.

      Entering S alone will produce a single page thus:

      G8PZT:KIDDER} Stats (69752):

      Time active (mins):              6791  (4 days 17 hours 11 min 50 sec)
      Warm restarts:                      0  (Last: 6714 mins ago)
      Memory: Max/Cur/Min/Out         72376     40216      1528         0
      Memory blocks: Min/Cur/Max        991      1014      1472
      Nodes: Cur/Max/Free/Poss          250       250         0       261
      Total bytes sent/rcvd:           218M      192M 
      Ccts/MaxCcts L2/L3/L4/TCP:      20/27      1/16     12/25      1/11
      HTTP Rqst/Srvd/Bytes/Prxyd:      1797      1535  13335437       121
      IP Heard/Reasm/Rcvd/Routed:   1381741         0   1374342         0
      IP Bad Hdr/Chksum/Version:          0         0         0
      IP Sent/Frag/Unsent/Total:    1403314         0      2059   1398698
      IP Bytes Hrd/Rcvd/Sent/Routed:   150M      148M      144M         0
      L4 Connects Tried/Made/Rcvd:     3431      2385      2869
      L4 total frames Sent/Rcvd:     187119    170030
      L4 Sent/Rcvd/Resent/Reseq:     119519     64069      2485        70
      L4 Chokes Sent/Rcvd:               22       167
      L4 Timeouts/Failures:            1562        33

      Use STATS * to display full stats



      "Time active" is the elapsed time since Xrouter was last restarted.

      "Warm restarts" shows how many times Xrouter was restarted using the 
      RESTART command, or by automatic restart.

      "Memory" displays Xrouter's RAM usage.  "Max" is the maximum available 
      free memory after the program is loaded, "Cur" is the current free 
      memory, "Min" is the minimum that has been reached during operation, 
      and "Out" is the number of times a memory request has failed.

      "Memory blocks" shows the minimum, maximum and current number of 
      allocated memory blocks.

      "Nodes" is the number of nodes heard about whose quality is greater 
      than the minqual setting.  (Current/Maximum)
      Added two new stats: Nodes free and possible.  The former shows how 
      full the table is, and the latter shows how much bigger the table 
      could be if uncapped

      "Total bytes sent/rcvd" are the total bytes sent and received by all 
      the ports.  They include all ax25 overhead.

      "Ccts/MaxCcts" shows the current and highest number of simultaneous 
      circuits that have been active at any time.  Separate figures are 
      shown for Ax25 levels 2,3 and 4, and TCP/IP.

      "IP Heard/Reasm/Rcvd/Routed" shows the total number of IP frames heard 
      (i.e. addressed to us and to others), reassembled from fragments, 
      received (i.e. addressed to us), and routed to others.



      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  32

      Stats


      "IP Bad Hdr/Chksum/Version" shows the number of IP frames ignored due 
      to corrupt IP headers (e.g. too short to be a legal IP frame), 
      checksum mismatch, and incompatible IP version.  

      "IP Sent" is the number of IP datagrams originated by Xrouter, i.e. 
      not routed from somewhere else.  "Frag" is the number of datagrams 
      which had to be fragmented to fit a link.  "Unsent" is (if I remember 
      correctly) the number of datagrams which couldn't be sent due to low 
      memory or no route, and "Total" is the total number of datagrams or 
      fragments thereof which were transmitted.

      "L4 Connects Tried/Made/Rcvd" shows the total number of outgoing and 
      incoming AX25 level 4 connections.  "Tried" is the number of requests 
      initiated, "Made" is the number which were successful, and "Rcvd" is 
      the number of incoming connects.

      "L4 total frames Sent/Rcvd" shows the total number of AX25 level 4 
      frames of all types sent and received by the router.

      "L4 Sent/Rcvd/Resent/Reseq" shows the totals for AX25 level 4 
      information-bearing frames.  "Sent" is the number of frames originated 
      by us.  "Rcvd" is the number addressed to us. "Resent" shows how many 
      were re-transmitted because no ack was received.  "Reseq" is the 
      number of frames that re-sequenced, i.e. were received out of sequence 
      and subsequently used when the missing frames arrived.

      "L4 Chokes Sent/Rcvd" counts the number of ax25 level 4 choke frames 
      sent and received by the router.  A sent choke indicates that we are 
      receiving L4 data faster than we can route it, and instructs the other 
      end to back off for a while.  A received choke indicates that we are 
      sending data too fast for the other end to handle.  Note that these 
      figures do not necessarily indicate that there is something wrong with 
      the router's links, as they apply to the "virtual circuit" from one 
      application to another, which may span many intervening nodes.

      "L4 Timeouts" shows the number of times the ax25 level 4 T1 timer 
      timed out while waiting for an ack, causing re-transmission of a 
      frame.  "Failures" shows the number of level 4 circuits which were 
      abandoned due to excessive retries. 

                          ------------------------------

      Entering s * will produce the above followed by:

                 Interface: 1      2      3
      Tx Bytes           125K   3567  5612K 
      Rx bytes          3456K    524  2345K
      RX Overruns:          0      0      0
      TX Underruns:         0      0      0
      CRC/Framing Errors:   0      0      0
      Break/Abort Errors:   0      0      0   
      Rx Overflow err:      0      0      0 
      Tx Overflow err:      0      0      0 
      Misc. errors:         0      0      0 

      L3 Frames Heard       0      0      0      0  12681      0  31364   6736
      L3 Frames Rcvd        0      0      0      0   3904      0  23721   1698
      L3 Frames Sent        0      0      0      0  13978      0  25438   7418
      L3 Frames Relayed     0      0      0      0   8036      0   7643   5038





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  33

      Stats


      L2 Frames heard    4896      0     21   2171  25594    440  42977  28402
      L2 Frames rcvd     2288      0      0    582  24816    378  42902  27976
      L2 Resequenced        0      0      0      0      0      0      0      0
      L2 Reassembled        0      0      0      0      0      0      0      0
      L2 Info Received    593      0      0    104      0     63      0      0
      L2 T1 Timeouts      134      0      0     18   1086     40   4453   3407
      L2 Digipeated         0      0      0      0      0      0      0      0
      L2 Info Sent       2301      0      0    755  15580    381  25436  12170
      L2 Info re-sent     362      0      0     20   1507     38      4   3426
      L2 Fragmented         0      0      0      0      0      0      0      0
      L2 Frames Sent     4100   1991    263   3096  32154   2051  52573  32568
      L2 REJ Received     177      0      0     10    732     27      0    691
      L2 Rx out of seq     31      0      0      3    247     12      0   2764
      L2 Frames Corrupt     2      0     56     13      0      2      0      0
      L2 FRMRs Sent         0      0      0      0      0      0      0      0
      L2 FRMRs Rcvd         0      0      0      0      0      0      0      3
      L2 Bytes Rcvd     44107  31204   7209 302045  4253K  22043  1235K  7634K
      L2 Bytes Sent    100133  10517   3112 317645  3105K  44132  1001K  6512K
      Poll Timeouts         3 246969      6      7      9      5      0      7

      The first section shows a set of counters for each interface.

      "TX Bytes" level 1 bytes sent.

      "RX Bytes" level 1 bytes received.

      "RX Overruns" counts the number of times a second byte was received 
      before a first was read by the CPU.  A high number indicates that the 
      PC is too slow for the selected serial port or HDLC card data rate.  A 
      16550-based serial card may help if the port doesn't already use one.  
      Failing that, you will have to reduce the baud rate.

      "TX Underruns" is used only by HDLC cards, and counts the number of 
      times the TX went empty while waiting for another frame byte to be 
      loaded.  A significant figure indicates the computer is too slow for 
      the baud rate.  Each underrun causes an aborted frame.

      "CRC/Framing Errors" counts either the number of bytes received 
      without proper stop bits (ASYNC interfaces), or the number of received 
      frames which corrupt (HDLC cards).  For ASYNC interfaces, a 
      significant count here can indicate a hardware problem, such as a 
      faulty line driver, serious RS232 line noise or distortion, or 
      significant baud rate mismatch.  For HDLC cards it indicates a level 1 
      problem, such as distortion in the TX/RX RF or audio paths, or simply 
      a lot of packet collisions.

      "Break/Abort Errors" counts the number of times a line "space" condition 
      longer than 1 word interval was received.  For serial ports this can 
      indicate a faulty line driver, a faulty diode matrix on a multikiss 
      system, or even (as recently happened to me) a malfunctioning TNC 
      eprom.  On HDLC cards it can result from insufficient audio drive from 
      the RX, a mismatched baud rate, squelch tails (I hope to prevent this 
      in a later version), or genuine ABORT sequences transmitted by the 
      other end of the link.  

      








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  34

      Stats

      "CRC Errors" shows the number of frames abandoned due to CRC or 
      checksum error.  For KISS interfaces this is only maintained if the 
      CHECKSUM kissoption is enabled.

      "Rx Overflow err" shows the number of times a frame was abandoned 
      because it was too large to fit into the receive buffer.

      "Tx Overflow err" counts the number of times that the TX couldn't 
      accept a character (serial devices) or a frame (block devices) because 
      the TX buffer was full.  If you persistently get a high value, it 
      indicates that the device is too slow for the data throughput.

      "Misc. errors" counts all sorts of miscellaneous errors and the 
      meaning is different for each type of interface.  For example, on KISS 
      interfaces it counts KISS framing errors.  It is mainly for my 
      benefit.

      Following the interface stats is the ax25 level 3 counters, one for 
      each port.  Note that on a system with more than 7 ports the display 
      may wrap.  I will be addressing this in a later version.

      "L3 Frames Heard" is the total number of ax25 level 3 frames heard, no 
      matter who they are addressed to.

      "L3 Frames Rcvd" is the number of ax25 level 3 frames which were 
      addressed to the router.

      "L3 Frames Sent" is the number of ax25 level 3 frames which originated 
      at the router.

      "L3 Frames Relayed" is the number of ax25 level 3 frames which were 
      routed through our system by other systems.

      After the level 3 stats, there are the ax25 level 2 counters, one per 
      port.

      "L2 Frames heard" is the total number of ax25 level 2 frames heard, 
      whether addressed to us or not.

      "L2 Frames rcvd" is the number of ax25 level 2 frames received, which 
      were addressed to the router.

      "L2 Resequenced" is the number of ax25 level 2 frames received out of 
      sequence and subsequently used when the missing frames arrived.

      "L2 Reassembled" is the number of ax25 level 2 frames successfully 
      reassembled from fragments.

      "L2 Info Received" is the number of ax25 level 2 information-bearing 
      frames received, i.e. addressed to the router.

      "L2 T1 Timeouts" counts the number of times that the ax25 level 2 T1 
      (frack) timer timed out, causing transmission of a poll frame.

      "L2 Digipeated" is the number of ax25 level 2 frames digipeated by the 
      port.  Note that if digiport isn't zero they may actually have been 
      re-transmitted by another port, but are recorded on the "receiving" 
      port only.

      "L2 Info Sent" is the total number of ax25 level 2 information frames 
      sent by the router.




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  35

      Stats

      "L2 Info re-sent" records how many ax25 level 2 information frames 
      were re-sent due to frame loss.  A high figure here, in proportion to 
      the "info sent" figure, indicates a problem with the RF link, the L2 
      settings, or the other end's system (e.g. desense, or running out of 
      buffers).

      "L2 Fragmented" is the number of ax25 level 2 information frames which 
      were fragmented to fit the outgoing link.

      "L2 Frames Sent" is the total number of ax25 level 2 frames, of any 
      type, sent by the router, i.e. it includes all info, supervisory, and 
      digipeated frames.

      "L2 REJ Received" is the number of ax25 level 2 "reject" frames 
      received, which indicate that the other end of the link didn't receive 
      some of our frames.  There are many possible reasons for this, some of 
      which are mentioned in the next paragraph.

      "L2 Rx out of seq" shows how many ax25 level 2 frames were received 
      out of sequence, and indicates that some incoming frames are getting 
      lost or trashed.  A few of the possible causes might be: signal too 
      weak, fading, other signals on channel, natural or man made 
      interference, desense or key clicks from adjacent transmitters, poor 
      rx audio response, low received audio, over-deviation, RF frequency 
      mismatch, badly aligned rx, TNC hardware problems, synthesised rig 
      taking too long to stabilise on RX after TX, other end's synthesised 
      rig taking too long to stabilise on TX, hum, noise, distortion or 
      disturbances on modulated audio... the list is endless.

      "L2 Frames Corrupt" is the number of frames which were dumped because 
      they were too short to be legal ax25 level 2 frames, or were in some 
      way invalid.  It is sometimes possible for a KISS TNC, especially if 
      running "open squelch", to send garbage to the router,  or the frame 
      may be trashed by bit errors on the serial link between TNC and 
      router, and in either case these frames are dumped if the error can be 
      detected.

      "L2 FRMRs Sent/rcvd" shows how many ax25 level 2 "Frame Reject" frames 
      were sent by the router, or received by it, indicating serious 
      protocol errors or deliberate interference.

      "L2 Bytes Sent" and "L2 Bytes Rcvd" simply provide a port by port 
      breakdown of the total bytes sent/rcvd figure.

      "Poll Timeouts" counts the number of times a BPQKISS TNC was polled 
      with no response being received from it.  A large figure might 
      indicate a crashed, disconnected or unpowered TNC, or data loss on the 
      serial link.

















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  36
     
      Frame Pipes


      FRAME PIPES
      ===========

      An optional facility allows frames received (and optionally sent) on 
      one port to be copied to another port.  A typical use would be to 
      allow a PMS connected to one port to see the traffic on another port, 
      e.g. UNPROTO headers from a local BBS.  Note that this is *not* the 
      same as digipeating.

      The facility is enabled by including the PIPE keyword within a port 
      definition, e.g. PIPE=4 would pipe frames to port 4.  If PIPE=0, or 
      the keyword is omitted altogether, no piping takes place.

      Pipes can be made selective, by adding a comma-delimited callsign 
      list, e.g. "PIPE=4 GB7PZT,KDRBBS".  This will reduce the loading on 
      the destination port, by piping only the frames with the specified 
      calls in the destination field.

      A pipe normally only allows traffic in one direction - in order to 
      have two way traffic you must either set up a reverse pipe on the 
      partner port, for example:

           (on port 3)    PIPE=4  ; Pipe frames to port 4
           (on port 4)    PIPE=3  ; Pipe frames to port 3

      Or you may configure the pipe to be bi-directional, by setting the 
      appropriate value in PIPEFLAG (see below)

      If a frame is piped on a bi-directional pipe, the source call is 
      remembered so that responses will be piped back to the sender.  This 
      is useful in cases where a BBS has a front end router.  Simply set up 
      bi-directional selective pipes from each user port to the BBS port.  
      The BBS will then allow direct connection and will respond to resync 
      requests.

      Bi-directional pipes are in reality only quasi-bi-directional, 
      because they can only send *responses* in the reverse direction.  In 
      the above BBS example, outgoing connects cannot be initiated to 
      callsigns which haven't already used the pipe.  The only way to have 
      truly unconditional two-way piping is to set up forward and reverse 
      pipes as detailed above.

      You may pipe several ports to a single destination port, but you can 
      at present only have one *outgoing* pipe from any port.

      Pipes are capable of generating an immense amount of traffic, so 
      use them with care - your target port MUST be capable of dealing with 
      the traffic load, and you should avoid setting up a network of pipes 
      which could cause an endless loop!















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  37

      Frame Pipes


      The types of frame to be piped can be controlled using the optional 
      PIPEFLAG keyword, which is ignored unless piping is active.

      If PIPEFLAG is not specified, the default value is 3.  The value is 
      made up by adding together the following numbers:

              1       - UI frames *not* addressed to nodecall/alias.
              2       - Non-UI frames *not* addressed to nodecall/alias.
              4       - UI frames addressed to nodecall/alias.
              8       - Non-UI frames addressed to nodecall/alias.
              16      - UI frames transmitted by the router.
              32      - Non-UI frames transmitted by the router.
              64      - Allow budlisted users to be piped.
              128     - Netrom frames
              256     - IP / ARP frames
              512     - Bi-directional piping

      e.g. PIPEFLAG=5 will pipe all received UI frames, but not those which 
      are originated by the router itself.

      You are *STRONGLY* recommended to use the default value unless you 
      specifically need to see additional traffic.










































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  38

      Broadcasting


      BROADCASTING
      ============

      Xrouter has the ability to "re-broadcast" a received frame on several 
      ports at once.  This can be thought of as a "one-to-many" pipe but 
      there are subtle differences.

      Whereas pipes conduct all frames of the selected type(s) virtually 
      regardless of source and destination addresses (unless they are 
      selective pipes), the broadcast function acts only upon UI frames, and 
      only if the source and destination addresses match those specified by 
      the sysop.

      Another difference is that frames may be broadcast to different groups 
      of ports depending on the destination address.  For example, FBB 
      unproto headers from a BBS may be rebroadcast on certain user-access 
      ports only, while mail beacons may be distributed to a different, 
      possibly overlapping, set of ports.

      You may alternatively use this feature as a "filtered pipe" between 
      two ports, allowing only UI frames with acceptable source and 
      destination calls to pass through.

      Note that this feature does not require a "connection" to the router, 
      it is purely an unconnected mode.  I devised it to allow BBS's to 
      distribute mail beacons and unproto mail headers.  You may use it (or 
      not) how you wish.

      You should be aware that broadcast traffic takes precedence over all 
      other frames, so an excessively high level of broadcast activity may 
      cause other outbound traffic on the destination port to be delayed.  
      However, it is unlikely that anyone will notice this effect unless 
      they are seriously overloading the channel.

      Broadcasting is controlled by two keywords in each PORT section of the 
      XROUTER.CFG file.  The first keyword is BCAST, and is used to specify  
      the destination addresses which will be broadcasted.

      For example, BCAST=MAIL,FBB will re-broadcast received non-digipeater 
      UI frames addressed either to FBB or MAIL.  The frames addressed to 
      FBB will be broadcast on all ports which have FBB in their BCAST list, 
      and those addressed to MAIL will be broadcast on all ports which have 
      MAIL in the BCAST list.  If no matching ports are found, the frame is 
      broadcast only on the port upon which it is received.  If you don't 
      need the broadcast function, simply omit (or comment out) the BCAST 
      keyword.

      The second keyword is BCFROM, which is used to specify a list of 
      callsigns from whom frames will be accepted for broadcast.  You may 
      use this to restrict the broadcast facility to certain senders only.  
      e.g. BCFROM=GB7PZT,GB7MAX says that only frames from GB7MAX and GB7PZT 
      will be accepted for broadcast.  If the keyword is omitted, the 
      broadcast facility is unrestricted.  BCFROM applies only to frames 
      *directly* received on the port for which it is specified.

      For both keywords, the list of calls should be separated by commas, 
      and should include no spaces.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  39

      Proxy Connections


      PROXY CONNECTIONS
      =================

      The PROXY facility allows ax25 level 2 callers to connect "direct" to 
      remote NET/ROM target callsigns, instead of having to connect first to 
      the router then issue a downlink connect request.

      I created this facility primarily for use in situations where a BBS or 
      PMS is wire-linked to a "front-end" router, thus allowing the BBS 
      callsign to be directly connectible on any port for which the proxy 
      call is defined.  You may find other uses....

      A bi-directional selective frame pipe would provide a similar effect, 
      but only for systems directly connected to the router, whereas PROXY 
      allows the target system to be located several hops away.  Pipes can 
      handle UI frames, whereas PROXY is for connected-mode operations only.

      Here's how it would be used on my set-up, which has two machines.  
      Only the router is connected to the radios, the BBS being wire-linked 
      to the router's port 7.

         -----------  (1)
        | Radio/TNC | ---.
         -----------     |
                         |     .--------------.            .----------.
         -----------  (2)|     | KIDDER:G8PZT | (7) KISS   |  GB7PZT  |
        | Radio/TNC |----|-----|              |------------|          |
         -----------     |     |   (router)   |  (rs232)   |   (BBS)  |
                         |     `--------------'            `----------'
         -----------  (3)|
        | Radio/TNC |----|
         -----------     |
                         V
                        etc.

      Without PROXY, level 2 users would have to connect to KIDDER:G8PZT, 
      then issue the command "C GB7PZT", or "BBS" to connect to the BBS.

      With the line "PROXY=GB7PZT" in port 1's definition (in XROUTER.CFG), 
      users on port 1's frequency (144.850) simply connect to "GB7PZT" - the 
      router sees the request and passes it via NET/ROM to GB7PZT, providing 
      GB7PZT has a NET/ROM facility of course (in my case it does because 
      GB7PZT runs on top of BPQ).

      If the target system (GB7PZT in this case) is not reachable via 
      Net/Rom level 4, the connect request is refused.

      If you wish to use this facility, you must add a 
      "PROXY=<call1>,<call2>,..." line to each user port concerned.  Ports 
      without the line will continue to function as normal.  You obviously 
      wouldn't enable it on your forwarding ports for example.  You will 
      notice that you can have several callsigns on the line, each separated 
      by a comma.

      Warning!  DO NOT enable proxy on any frequency which is shared by the 
      target system or you'll cause horrible problems (both the target and 
      the proxy will respond to connects at the same time).







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  40

      AX25/Netrom -> TCP proxy


      AX25 / NETROM -> TCP PROXY
      ==========================

      This is an extension of my PROXY concept, allowing a remote TCP/IP-
      only system to have Netrom and AX25 connectivity.

      In the previous example, GB7PZT BBS used G8BPQ node TSR underneath the 
      BBS to provide Netrom connectivity across the KISS link.  With the 
      extended proxy, BPQ can be removed altogether and the BBS can be run 
      in pure TCP/IP mode.  This saves memory, whilst improving speed and 
      reliability.  The BBS no longer has to support multiple protocols and 
      hardware types, that job being delegated to Xrouter.

      Instead of having to connect first to KIDDER (Xrouter) then issue the 
      awkward command "Telnet 44.131.91.2", users can simply connect 
      "directly" to the callsign GB7PZT on one of KIDDER's radio ports.  
      Xrouter converts that connection into a TCP/IP connection with the 
      BBS, and translates the data back and forth between AX25 and TCP/IP.

      Furthermore, the BBS callsign "GB7PZT" can be connected to directly 
      from Xrouter's command line, and also included in nodes broadcasts so 
      it can be reached from a remote node.

      This is achieved by putting an extended PROXY statement in the GLOBAL 
      section of XROUTER.CFG, using the following format:

           PROXY=<call> <alias> <qual> <ipaddr> <portnum> [passwrd]

      For example:

           PROXY=GB7PZT KDRBBS 150 192.168.0.4 8888 bloggs -a

      <call>    is the netrom and ax25 callsign for the proxied system.
      <alias>   is the netrom / ax25 alias for the proxied system.
      <qual>    is the netrom "quality" (0 - 255) controlling visibility.
      <ipaddr>  is the proxied system's IP address.
      <portnum> is the TCP service port number of the proxied system.
      <passwrd> is optional password sent to proxied system upon connect.
      -a optional switch opens an ascii connection for use with Dxspider

      AX25 and Netrom are pure binary channels, whereas standard telnet is 
      not. The proxied system must provide a pure binary service port in 
      order to make full use of this facility for compressed forwarding etc. 
      G8PZT's "XServ" BBS provides such a facility on port 8888.
      If you are a software author interested in adapting your software to 
      work with this proxy, the following information will be relevant:

      Upon connection to the proxied system Xrouter sends one line of text 
      ending in <CR><LF>, containing one or more space-delimited fields. The 
      first field is the callsign of the connectee in the form "G8PZT-7" 
      (ax25) or "G6YAK-2@GB7BM" (netrom).  The second field is an agreed  
      password which verifies the proxying system.  Thereafter, the link 
      switches to pure binary, and in accordance with AX25 practice both 
      systems must send line ends as <CR> alone.

      There is no limit to the number of proxies you may configure.








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  41

      NETROM -> AX25 Proxy


      NETROM -> AX25 PROXY
      ====================

      This is similar to the NetRom -> TCP proxy described above, but is 
      intended to allow an AX25-only system to have a NetRom presence.

      This is enabled by putting an extended PROXY statement in the GLOBAL 
      section of XROUTER.CFG, using the following format:

           PROXY=<call> <alias> <qual> <ax_call> <portnum>

      For example:

           PROXY=MB7UYL UYLBBS 150 G6KDR-3 7

      <call>    is the netrom and ax25 callsign for the proxied system.
      <alias>   is the netrom / ax25 alias for the proxied system.
      <qual>    is the netrom "quality" (0 - 255) controlling visibility.
      <ax_call> is the proxied system's AX25 L2 callsign.
      <portnum> is the radio port the proxied system is connected to.

      The above example creates a Netrom node whose callsign is "MB7UYL", 
      alias "UYLBBS", with quality 150.  Anyone who makes a connection to 
      either of these addresses will instead be connected to the AX25 system 
      "G6KDR-3", attached to Xrouter's port 7.

      Warning: Be *very* careful when mixing proxies and pipes, or you will 
      end up generating lots of FRMR's, and possibly crashing the system.  
      These are powerful tools and must be used carefully.



































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  42

      Telnet Proxy


      TELNET PROXY SERVER
      ===================

      The need may arise for a TCP/IP host on the LAN to connect first to 
      Xrouter, before making an ongoing connection from Xrouter to a target 
      host.  Using Xrouter's normal telnet port 23 for this purpose is not 
      always successful, especially if the link is required to carry binary 
      data, due to the internal end-of-line translations and Telnet command 
      sequences required by the Telnet protocol.

      The Telnet proxy on TCP port 2323 provides a solution to this problem, 
      allowing full binary connections not only to TCP/IP targets, but also 
      to Netrom and AX25 targets.

      Upon connection to port 2323, the caller may, or otherwise, be 
      required to answer a security challenge, according to the security 
      criteria specified in ACCESS.SYS.  The options are: no challenge, 
      callsign only, or callsign plus password, and all of these can be made 
      dependent on the caller's IP source address.

      After gaining entry, the user is presented with a short text 
      explaining the syntax for the outgoing connection, followed by a short 
      prompt ">".  This text is read from file TELPROXY.MSG, so you may 
      adjust it to your requirements.  The user may now issue a telnet, 
      netrom or ax25 downlink connect command.  Xrouter will respond with 
      "Trying ...".

      If the downlink is successfully made, connection is reported, then the 
      stream becomes pure binary for the duration of the session.

      If the downlink fails to connect, an error message is sent before the 
      uplink is terminated.

      GB7PZT BBS has been successfully using this proxy for some time, to 
      perform binary compressed forwarding with a variety of netrom, ax25 
      and TCP/IP targets.




























      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  43

      Chat Server


      CHAT SERVER
      ===========

      Xrouter has a built-in chat server, i.e. a device which allows groups 
      of users to hold live multi-way conversations without the usual 
      problems of having to manage several streams at once.  It is available 
      to all callers, and is accessed by using the CHAT command at the main 
      prompt, or by connecting directly to its callsign or alias.  TCP/IP 
      users can additionally reach it by TELNETting to port 3600.

      The Xrouter chat system has 32767 "channels", each of which can 
      support an unlimited number of users, so it is possible for groups to 
      have their own "private" channel, or to reserve certain channels for 
      specific topics.  Channel 1 (one) is the default at log-on and is used 
      as a  sort of "calling channel", from where users may QSY as required.  
      Users may "join" as many channels as they wish, so they may take part 
      in several separate conversations at once.

      Channels 1 to 255 are "local" to each chat server, and the remaining 
      channels 256-32767 are "global", i.e. they are linked with all other 
      Xrouter chat servers, providing the sysop sets up at least one link to 
      another server.

      In addition to the "positive" channel numbers, there are another 32768 
      channels numbered 0 to -32767.  These correspond to channels 0 to 
      32767 on the "Tampa Ping Pong" system.  Xrouter allows only limited 
      interconnection between the two systems, because the channel layouts 
      and topologies are completely incompatible.  Xrouter chat was 
      specifically designed for use on an anarchic, slow radio network, 
      whereas Ping-Pong requires a more planned network topology to avoid 
      loops, and is largely carried on Internet links.  The sheer volume of 
      chat in the Ping-Pong system would overwhelm radio links.

      Data received from Ping-pong is not propogated via the Xrouter chat 
      interlinks and vice versa.  In effect, Xrouter can be a stub Ping-Pong 
      host, but not part of the Ping-Pong network.  

      Users may listen on any number of positive and negative channels 
      simultaneously, but may only send on one channel at a time.  Once 
      logged onto a channel, anything sent by the user is copied to all 
      other users of that channel, except lines beginning with a forward 
      slash (/), which are interpreted as chat server commands.  The copied 
      text is preceded by the channel number and the sender's callsign and 
      name, to allow the recipients to identify who sent it.

      All chat server commands begin with a forward slash (/), and most may 
      be abbreviated to the initial letter.  The /? command will show the 
      available commands and syntax, while /HELP will give more details. 

      The /NAME command is used to enter the user's first name, and serves 
      as a "login".  Users are not permitted to join any channels until they 
      have supplied a name.  TCP/IP users must additionally supply a 
      callsign with the /USER command.

      /CHANNEL, /JOIN and /LEAVE are used to select the desired channel, 
      /WHO shows the active channels and who is using them, and /QUIT 
      terminates the chat session.  The full command set is shown in more 
      detail in the command reference section.






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  44

      Chat Server


      Users who log on to more than one chat server at once are treated as 
      separate entities, and must supply their name and callsign on each 
      log-in.

      If transaction logging has been enabled in XROUTER.CFG, chat server 
      activity will be logged in file CHATSERV.LOG.

      The chat server is fully automatic and requires minimal setting up. It 
      has its own callsign and alias defined in XROUTER.CFG, plus a list of 
      link partners.

      The alias (6 chars max) should preferably end with "CHT" and begin 
      with something geographically relevant, e.g. BHMCHT for Birmingham, 
      LDSCHT for Leeds etc., so they can be identified easily in node 
      tables.  The only other setting up required is to install the chat 
      help files in the directory help/chat.

      At present, only Netrom links are allowed between Xrouter chat peers 
      (so the peer must be in your node table), and only TCP/IP links are 
      allowed to Tampa Ping-Pong peers.  Peer links are specified using the 
      CHATLINKS keyword in XROUTER.CFG, or may be added and removed at any 
      time using the /LInks command.

      Links to Xrouter chat peers are specified thus:

           CHATLINKS=<netrom_call>,<netrom_call>,...
      e.g. CHATLINKS=GB7GH-7,GB7BM-8,N0LBA-8

      or at the chat command line:

           /LI ADD <netrom_call>
      e.g. /LI ADD GB7BX-9

      Unilateral linking is not allowed.  You *must* co-ordinate it with 
      your peers, such that you are in their CHATLINKS list and they are in 
      yours.

      Links to Tampa Ping-Pong converse servers are specified in Xrouter.cfg 
      as follows:

           CHATLINKS=<peername> <ip_address>:<tcp_port>
      e.g. CHATLINKS=brmcht 80.195.22.67:3601

      Alternatively, use the command "/LI ADD <peername> <ipaddr>:<port>", 
      e.g. "/LI ADD brmcht 80.195.22.67:3601"

      You should avoid linking to peer servers via slow links.  If the link 
      isn't up to the job, frames will be dumped.
















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  45

      Application Interface


      APPLICATION INTERFACE
      =====================

      Because XROUTER.EXE is not a TSR, you cannot run other applications 
      "on top" of Xrouter *unless* you run it in a Windows or Desqview 
      environment.

      This mode of operation is well outside my original requirement 
      specifications, because I personally feel it is not the job of a 
      *router* to directly support applications.  In my view, a router 
      should just be a box which sits in a dusty corner getting on with the 
      sole job of shunting packets around!

      However, it seems that Radio Amateurs are in the main unwilling to run 
      more than one machine, so I have included an application interface 
      with the caveat that I don't consider it a particularly important 
      feature and don't want to waste all my time supporting it.  There are 
      plenty of other programs (such as BPQ, FLEXNET and AGW) more suited to 
      directly supporting applications.

      In order to use the application interface, you must load an additional 
      component, PZTHOST.EXE, *before* you start Windows or Desqview. 
      PZTHOST is a TSR which occupies around 40k of base memory.  After 
      loading PZTHOST, start Windows or Desqview.  This process can be 
      automated by putting a call to PZTHOST.EXE in AUTOEXEC.BAT.  Once 
      Windows (or Desqview) has loaded, you may then run Xrouter in a window 
      and the applications in other windows.  You cannot run PZTHOST.EXE in 
      a window.

      The application interface conforms almost exactly to G8BPQ's interface 
      specification, detailed in BPQHOST.DOC, which is usually included with 
      the BPQ program. For the moment, you are referred to that document if 
      you require details of how to write programs for the interface.

      I say "almost" exactly, because the "BBS" application is not fixed as 
      the first application.  Thus in function 6, CX=0 uses the APPLICATION 
      callsign, not the "BBS" callsign, as there is no specific "BBSCALL" in 
      my program.

      The 8 bit application interface has been tested with DOS programs such 
      as PZT BBS, PAC4, Easyterm, PEARL and DOSFBB so far.  It doesn't seem 
      to work with NPFPMS.  If you find it works (or doesn't) with other 
      applications, please let me know.

      In a Windows environment, 16 bit programs such as WinFBB, UI-View and 
      Winpack can also use the application interface, via G8BPQ's BPQDLL.DLL 
      and BPQCODE.386 drivers, exactly as they would with BPQ itself.  These 
      drivers are included in BPQ node version 4.08 release.  They must be 
      placed in the C:\WINDOWS\SYSTEM directory.

      Some applications designed for use with the BPQHOST interface read 
      configuration parameters from BPQCFG.BIN, so you may need to configure 
      of copy of this file and put it where the application expects to find 
      it.  To configure the file, edit BPQCFG.TXT to your requirements, then 
      run BPQCFG.EXE to create BPQCFG.BIN.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  46

      Application Interface


      Defining Applications
      ~~~~~~~~~~~~~~~~~~~~~
      Applications must be specified in XROUTER.CFG, in the following 
      manner:

      Each application definition block must begin with APPL=<number> and 
      end with ENDAPPL.  There should be a separate block for each 
      application.  Applications which use more than one stream, need only a 
      single definition.  The application block should contain one or more 
      of the following keywords:

           APPLNAME       The name by which the application is accessed from                     
                          the router's command line. e.g. "PMS".  If a user                     
                          types this name, they will be connected to the                     
                          application.

           APPLCALL       Callsign which the application will use.
                          If a callsign is specified, the application will 
                          accept level 2 connects, subject to the setting of 
                          APPLMASK (see below).

           APPLALIAS      Alias for use by the application.
                          As APPLCALL.

           APPLQUAL       Netrom quality to broadcast.
                          If a non-zero value is specified here, the 
                          APPLCALL will be included in nodes broadcasts and 
                          the application will be connectible at level 4. 

           APPLFLAGS      1    Applications granted Sysop privileges 
                               (needs PZTHOST.EXE v1.60)
                          2    Allows guest users to type APPLNAME at  
                               command line
  
      The application number must be between 1 and 8, and corresponds to the 
      application's position on a BPQ "APPLICATIONS=" line.  Some 
      applications have fixed application numbers, e.g. BBS's and PMS's must 
      usually be the first application and Host programs such as PAC4 are 
      usually the second.

      All fields within an application definition block are optional - you 
      may have for instance choose to have an applname but no applcall, and 
      the application would only be reached by typing the applname at the 
      command line.  Or you could have an applcall but no applname, in which 
      case the application would be directly connectible, but wouldn't be 
      reachable from a command line shortcut.

      Example:
           APPL=1
                 APPLNAME=PMS
                 APPLCALL=G8PZT-2
                 APPLALIAS=PZTPMS
                 APPLQUAL=50
                 APPLFLAGS=1
           ENDAPPL









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  47

      Application Interface


      If you want an application to be directly connectible on a particular 
      port, it (the application) must have a callsign, an alias or both, and 
      the corresponding bit in that port's APPLMASK must be set.

      APPLMASK specifies which applications will be directly connectible on 
      a given port.  The default is 255, which allows all applications.  The 
      value is made up by adding together the following numbers:

                      1       - Enable Application 1
                      2       - Enable Application 2
                      4       - Enable Application 3
                      8       - Enable Application 4
                      16      - Enable Application 5
                      32      - Enable Application 6
                      64      - Enable Application 7
                      128     - Enable Application 8


      For example, if a port's definition contains "APPLMASK=9", it will 
      allow direct connections to applications 1 and 4 on that port, 
      providing those applications have either an APPLCALL or an APPLALIAS.


      Setting The Host Interrupt Number
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      In addition to the above, XROUTER.CFG must contain the HOSTINTERRUPT= 
      keyword, which specifies the software interrupt number the 
      applications will use to communicate with the router.  The value is in 
      decimal, and 127 is the value usually chosen.  The default, if you 
      omit the keyword, is 0 which disables the host interface.  Do NOT go 
      below 96, as the operating system may be using the interrupt.

      Note that some applications may specify the host interrupt in 
      Hexadecimal, e.g. 7F is 127 decimal.


      Disabling 16 bit support
      ~~~~~~~~~~~~~~~~~~~~~~~
      If you only wish to run DOS applications, such as DOSFBB or PAC4, in a 
      Windows environment and don't wish to run 16 bit applications, you 
      will not need BPQCODE.386 or BPQDLL.DLL.  With PZTHOST version 1.4 and 
      above, you can prevent Windows from attempting to load BPQCODE.386 by 
      including the "-8" switch when starting PZTHOST, e.g. "PZTHOST -8".





















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  48

      Application interface - PZTSOCK


      What is PZTSOCK ?
      ~~~~~~~~~~~~~~~~~
      PZTSOCK is a combined socket and BPQHOST interface, which isn't yet 
      properly tested.  I am not releasing details of the socket API until 
      I've made sure that there will be no further changes, as I want to 
      ensure backward compatibility in future.  So as far as you are 
      concerned, the only functional part of PZTSOCK is the "bpqhost" 
      interface.  You may currently use PZTSOCK and PZTHOST interchangeably, 
      but PZTSOCK uses more memory so there's no point.

      Why sockets?
      ~~~~~~~~~~~~
      The bpqhost API was designed a long time ago and does not support 
      TCP/IP and UDP applications, whereas the PZTSOCK API allows any 
      combination of TCP/IP, NETROM, and AX25 applications to interface with 
      the router in a variety of modes.

      For example, text-mode applications may interface directly with the 
      router's command line as if connected via a wire link.  AX25 
      applications can have complete dynamic control over their own 
      callsigns, and may use "stream" (connected) mode, "datagram" (UI 
      frames) mode, or "raw" mode (application encodes/decodes the frame).  
      Netrom applications can similarly use stream, datagram or raw mode.  

      TCP/IP and UDP/IP applications can use any IP address/port 
      independently of the router, and "raw" mode allows any application to 
      send/receive IP datagrams.  And of course bpqhost API is still 
      included.

      This will allow any application which uses a socket paradigm to be 
      easily ported for use with xrouter, as the interface provides BSD-
      style open(), bind(), accept(), send() recv() and close() calls.

      PZTSOCK requires a single numeric argument, which is the interrupt 
      number (in decimal) used for the socket calls.  You must supply this, 
      even though it isn't currently used.  e.g. "PZTSOCK 128" would specify 
      that software interrupt 128 will be used by socket-based applications 
      to talk to the router. BPQ host applications are supported through the 
      HOSTINTERRUPT defined in XROUTER.CFG.

      If you currently run applications using PZTHOST, and you wish you use 
      PZTSOCK instead (e.g. when I begin releasing socket-based 
      applications), simply substitute PZTSOCK in place of PZTHOST and 
      modify your batch file to supply a dummy interrupt as above.  Make 
      sure the dummy interrupt isn't used by something else, and don't make 
      it the same as HOSTINTERRUPT.  Values between 128 and 255 should be OK 
      if you have the usual HOSTINTERRUPT=127.

















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  49

      Using Xrouter With Desqview


      USING XROUTER WITH DESQVIEW
      ===========================

      As stated many times, xrouter is a FOREGROUND program, designed to be 
      the sole application on a dedicated machine.  However, even though 
      suitable PC's are now freely available, some people still want to run 
      everything on one machine.  This can be achieved within the 
      multitasking environment provided by Desqview, which in my view is a 
      more stable and suitable environment than Windows, with less stringent 
      hardware resource requirements.

      In the following text, it is assumed that you already have a copy of 
      Desqview properly installed on your machine, and are conversant with 
      its use.


      a) Configuring Xrouter to run in Desqview
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      STOP!   First of all, set up XROUTER.CFG to your requirements and make 
      sure the router runs properly in plain DOS.  If it doesn't work in 
      DOS, it won't work in Desqview!  If you intend to run applications, 
      configure the APPL sections and set HOSTINTERRUPT to your preferred 
      interrupt number.  You must set DESQVIEW=1 otherwise it won't work 
      properly in DesqView.

      Make sure that there are no conflicts between xrouter and other 
      applications for access to hardware such as COM ports, Ethernet or SCC 
      cards.

      The program writes directly to screen memory because the PC's BIOS 
      routines are not usually fast enough to support multi-port monitoring 
      at high data rates.  A consequence of this within Desqview is that the 
      console display may "bleed through" into any Desqview window which 
      overlays it.  I am told that this doesn't happen with more modern 
      versions of DV, although I can't confirm this.

      This may or may not be a problem to you, depending on the other 
      applications you are running alongside the router.  If you set 
      NUMCONSOLES=0 in XROUTER.CFG, the router will run without a screen 
      display, thus avoiding bleed-through, and saving some memory.  Of 
      course, in this mode you will only be able to control the router by 
      connecting to it, either from an application or via one of the ports, 
      much like the TSR version of BPQ.





















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  50

      Using Xrouter With Desqview


      b) Configuring Desqview For Xrouter
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Start Desqview and choose Open -> Add Program, then use the following 
      parameters as a guide....

      Program Name:                      XROUTER
      Keys to use on open menu:          XR
      Memory size in K:                  400 (see below)
      Program:                           XROUTER.EXE
      Parameters:
      Directory:                         C:\XROUTER

      Options
      -------
      Writes directly to screen:         Y
      Displays graphic information:      N
      Virtualise text/graphics:          N
      Uses serial ports:                 N
      Requires floppy diskette:          N

      Advanced Options
      ----------------
      System memory in K:                10
      Maximum program memory size:
      Script buffer size:                1000
      Max. expanded memory size:
      Text pages:                        2
      Graphics pages:                    0
      Initial mode:
      Interrupts:                        00 to FF
      Max height:                        25
      Max width:                         80
      Close on exit:                     Y
      Allow close window command:        N
      Uses own colours:                  Y
      Runs in background:                Y
      Uses math coprocessor:             Y
      Keyboard conflict:                 0 or 1
      Share CPU when foreground:         Y
      Share EGA when foreground:         Y
      Can be swapped out:                N
      Protection level:                  1


      You should preferably reserve enough memory to allow at least 30k of 
      free memory shown on the console top status bar (or use the Stats 
      command if you have console disabled), but the actual figure may 
      depend on how much Desqview will let you have, and how much you need 
      for other applications.  Optimising Desqview is beyond the scope of 
      this document.














      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  51

      Using Xrouter With Desqview


      Starting Xrouter within Desqview
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1)   If you wish to run BPQ-compatible applications, you must start 
           PZTSOCK before you start DesqView itself.  PZTSOCK.EXE should be 
           located in the same directory at XROUTER.EXE and XROUTER.CFG.  
           Simply change to the XROUTER directory and type "PZTSOCK", or 
           arrange for this to happen in your autoexec.bat. (Tip: if you 
           ever need to unload PZTSOCK you can do do using "PZTSOCK -U.")

      2)   Start DesqView.

      3)   Choose Open -> Start Program -> XROUTER or set up a startup 
           script to do so.  The router should now be running.  If not, and 
           assuming you made sure it ran OK in DOS, you may need to use a 
           higher value for "Memory Size".

      4)   Start your other applications.  


      Notes
      ~~~~~
      Some BPQ applications need to read configuration information (usually 
      HOSTINTERRUPT) from BPQCFG.BIN, so you may have to create a dummy 
      BPQCFG.BIN to keep them happy. 

      Because each program only gets a short interval of processor time, 
      interspersed with periods of inactivity, you may find that some of the 
      timings on SCC cards (e.g. TXDELAY and the CWID dot spacing) are a 
      little erratic.  You may need to "tune" the system to minimise the 
      jitter by setting the foreground and background time slices to 1 tick 
      each.

      Please inform me if you can improve on the suggested settings or offer 
      any other tips.






























      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  52

      PSTN Modem Support


      PSTN MODEM SUPPORT
      ==================

      Xrouter may be connected to one or more Public Switched Telephone 
      Network (PTSN) modems, for dial-in and dial-out operations.

      Dial-in would, for example, allow users and/or sysops to connect to 
      the router and operate it using a dumb terminal or a standard terminal 
      package such as Telix or Hyperterm.  Alternatively, after login, the 
      link may be switched into SLIP or PPP mode for TCP/IP operations, in 
      exactly the same way as a dial-up Internet Service Provider.

      Dial-out allows Xrouters to be linked with each other or with an 
      Internet service provider, for the purposes of on-demand wired 
      routing, or Internet Connection Sharing.

      A single modem may be used for both dial-in and dial-out operations on 
      the same port, although not at the same time of course!


      Suitable Modem Types
      ~~~~~~~~~~~~~~~~~~~~
      Almost any external modem is suitable, providing it can be initialised 
      by a single string of characters and can be configured to disconnect 
      when DTR is dropped.

      Internal modems should preferably be of the type where the COM number 
      IOADDR and IRQ can be preset by hardware jumpers.  I have no 
      experience of using other modem types.  The cheap "Winmodem" types 
      which require a Pentium processor are definitely not suitable.


      Hardware Configuration
      ~~~~~~~~~~~~~~~~~~~~~~
      External modems should be connected to a serial port using a cable 
      with at least 8 connections, namely TXD, RXD, RTS, CTS, DTR, DSR, DCD 
      and ground.  The RI (ring indicator) connection is not needed.

      Internal modems should be configured to use a spare COM number and 
      IRQ.


      Software Configuration
      ~~~~~~~~~~~~~~~~~~~~~~
      Each modem requires an ASYNC interface definition in XROUTER.CFG, with 
      COM (or IOADDR & IRQ if non-standard) configured for the appropriate 
      serial port or modem card.  You should use PROTOCOL=MODEM, and FLOW=1.  
      I would suggest setting MTU=576.

      To each "modem" interface should be attached a PORT with at least 
      INTERFACENUM and ID specified.  If the modem requires an 
      initialisation string, add INITSTR=<initstring>, e.g. to set the modem 
      into auto answer mode use "INITSTR=ATS0=1".  If you don't include the 
      INITSTR keyword, the modem configuration is not altered.

      If your modem does not, by default, hang up when the RS232 DTR signal 
      is dropped, you should configure it to do so by including "&D2" in the 
      initialisation string, for example: "INITSTR=ATM0S0=1&D2".






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  53

      PSTN Modem Support


      Example MODEM Interface and Port Configuration
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      In XROUTER.CFG:

      ;
      INTERFACE=5
              TYPE=ASYNC
              COM=3
              SPEED=57600
              PROTOCOL=MODEM
              FLOW=1
              MTU=576
      ENDINTERFACE
      ;
      PORT=2
              ID=PSTN Modem port
              INTERFACENUM=5
              INITSTR=ATS0=1
      ENDPORT
      ;

      If you will be allowing incoming calls, you must set up a callsign and 
      password entry for each user in USERPASS.SYS.


      Dial-in Operation
      ~~~~~~~~~~~~~~~~~
      If you have configured the modem for auto-answer, PSTN callers must 
      successfully complete a callsign and password challenge before they 
      are allowed to use the command line.

      The callsign must be a proper amateur radio callsign, i.e. not a 
      username.  If a proper callsign is not given, or if the callsign is 
      not found in USERPASS.SYS, or if an incorrect password is given, the 
      user is immediately disconnected.  If this sounds unforgiving, it's 
      meant to be!  It will cost hackers the price and time delay of a 
      separate phone call for each attack.

      If the callsign and password challenge is successfully completed, the 
      caller will be allowed to use the command shell exactly the same as a 
      radio caller.

      Xrouter will disconnect the caller after 15 minutes of inactivity.  
      You may initialise the modem to disconnect after a shorter interval if 
      necessary.


















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  54

      PSTN Modem Support


      The XLINK command
      ~~~~~~~~~~~~~~~~~
      If the caller (e.g. using NOS) wishes to establish a TCP/IP link with 
      your router, the XLINK command is used to switch the ASCII link into 
      SLIP ("XLINK SLIP") or PPP ("XLINK PPP") mode.  Xrouter will respond 
      with "Entering SLIP mode" or "Entering PPP mode", and thereafter will 
      no longer respond to ASCII commands.  SLIP or PPP mode may only be 
      terminated by disconnection.

      In order to use SLIP or PPP modes, Xrouter must have at least a global 
      IPADDRESS, and you must set up IP routing to the caller's IP address 
      on the modem port.  You could either allow each caller to use their 
      own IP address, and have one routing entry for each caller, or you may 
      choose to require all callers on a particular port to use the same IP 
      address (since only one may connect at any time) and set up a single 
      routing entry.

      For example, you could tell each of your SLIP/PPP callers to set their 
      IP address to 192.168.73.88, which is one of the "unregistered" 
      addresses anyone can use.  If your modem is on port 2, you would add 
      the following entry to IPROUTE.SYS:

           route add 192.168.73.88/32 * 2 d

      Which means "route datagrams for 192.168.73.88 directly on port 2 
      using datagram mode".

      No ARP entry is necessary for the caller, because SLIP and PPP do not 
      use "hardware addresses".


      XLINK PPP mode
      ~~~~~~~~~~~~~~
      XLINK SLIP mode requires no extra configuration, but PPP mode 
      optionally uses an extra file to configure the PPP system for receive 
      operations on the modem port.  For example, you may wish to use one IP 
      address when making outgoing connects and a different one when 
      receiving incoming connects.

      The optional file is named "PPPHOST.n" where n is the number of the 
      modem port, e.g. "PPPHOST.2".  You may have a separate file with a 
      different configuration for each modem port if required.  The file 
      should be located in the same directory as Xrouter itself and can 
      contain any PPP configuration command.

      See the description of PPP commands for details of how to configure 
      PPP.

      The PPP link inactivity timeout defaults to 5 mins, but can be 
      overridden by including the PPP IDLE command in the PPPHOST.n file.














      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  55

      Dial-up Networking


      DIAL UP NETWORKING
      ==================

      Dial-Up Networking (DUN) is a subsystem which allows Xrouter to 
      connect to other TCP/IP systems via a dial-up Public Switched 
      Telephone Network (PSTN) link.

      This could be used for example to connect with an Internet Service 
      Provider (ISP), enabling Xrouter to link to other systems via the 
      Internet.  Or (if you have unmetered telephone calls) it could be used 
      for linking one Xrouter directly with another via the PSTN on demand.

      DUN basically consists of:

              a) A script reader capable of configuring PPP, controlling a
                 modem and logging into a remote system.

              b) A system to invoke these scripts when required.

      CAUTION: Due to other commitments, DUN development was halted abruptly 
      before it had been properly finalised, debugged and documented.  I 
      haven't had chance to pick up the pieces and finish the work, so you 
      are urged to use this system with caution.  I was intending to leave 
      it un-documented to discourage its use.  But I have now decided that 
      the best way to find the bugs and get the project completed is to let 
      others experiment with it.


      Configuring DUN
      ~~~~~~~~~~~~~~~
      Please see the manual section entitled "PSTN modem support" for 
      details of how to configure Xrouter to use a modem.

      Assuming you have a port configured for modem use, DUN requires at 
      least one dialler script, to control the dial and login sequence.

      Dialler scripts are ordinary text files containing script commands as 
      detailed below, one per line.  Lines must not exceed 256 characters in 
      length.  The script file can be named as you wish, for example you 
      might like to name your AOL dial script "AOL.SCR".  You will need to 
      use this name later to identify the script, so it makes sense to call 
      it something meaningful, rather than "SCRIPT1.TXT".  Script files must 
      reside in the same director as XROUTER.EXE.

      Next you must set up DUN to invoke your script whenever a connection 
      is required.  This is done by using the DUN ADD command to record the 
      peer's IP address and the name of the script used to make the 
      connection to that peer.  If you don't know the IP address you may use 
      a "dummy" address, e.g. "1.1.1.1", because it is simply a handle used 
      to invoke the appropriate script.  You should use one DUN ADD command 
      for each script.

      Finally, you must add one or more entries to the IP routing table 
      whereby the "gateway" ip address is that of the peer (or the dummy 
      address as mentioned above).









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  56

      Dial-up Networking


      For example, suppose my ISP is aol.com, and I want to route all UK-
      bound IP traffic via them.  I have a modem connected to port 3, and I 
      have created a suitable connection script named AOL.SCR.

      a) I don't know the IP address of AOL's router, so I simply
         choose a dummy address of "192.168.1.1".

      b) I then issue the command "DUN ADD 192.168.1.1 AOL.SCR", or
         include it in IPROUTE.SYS or BOOTCMDS.SYS.

      c) Finally, I add a routing entry as follows:

         "IP ROUTE ADD 44.131.0.0/16  192.168.1.1  3  d"

         which means "route all 44.131.x.x (UK) traffic via (dummy)
         gateway 192.168.1.1 on port 3 (the modem port) using datagram
         mode.

      Whenever Xrouter receives a frame with a destination address in the 
      44.131 series, it will now invoke the dial script AOL.SCR.


      DUN Script Commands Overview
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

              CONTROL         Raise / lower RS232 DTR signal.
              MODE            Sets protocol to use upon successful login.
              PPP             PPP configuration commands.
              SEND            Send text.
              SLEEP           Temporary pause.
              WAIT            Wait for text in received data.


      DUN Script Commands In Detail
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      CONTROL - Raise / Lower RS232 DTR signal.

              Syntax: C[ontrol] <up | down>

              The CONTROL command is used to raise or lower the RS232 DTR 
              (Data Terminal Ready) line.  Most modems require the DTR 
              signal to be "up", and will disconnect or reset when it goes 
              down.  Those modems which do not do this by default can 
              usually be configured to do so by including "&D2" in the 
              initialisation string.


      MODE    - Set protocol to use upon successful login.

              Syntax:  M[ode] <kiss | ppp | slip>
              Example: MODE PPP

              MODE specifies the protocol to use after your system has 
              logged into the remote host, i.e. when the script ends without 
              error.  It must precede the dialling and login sequence, and 
              any protocol dependent commands, such as the PPP commands.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  57

      Dial-up Networking


      PPP     - PPP configuration commands.

              Syntax:  P[pp] <idle | ipcp | lcp | log | pap> [arg]
              Example: PPP IDLE 300

              PPP commands are used to configure the PPP subsystem for the 
              connection being established.  Note that within DUN scripts 
              the <port> argument is omitted because Xrouter knows which 
              port the script is running on.


      SEND    - Send a line of text.

              Syntax:  S[end] <text>
              Example: SEND ATDT01674302153

              The SEND command sends one line of text to the modem or the 
              remote host, for example modem initialisation and dial 
              commands, or login commands.  The <text> argument may contain 
              spaces, and the system will append a carriage return/line 
              feed.


      SLEEP   - Temporary pause.

              Syntax: SL[eep] <millisecs>
              Example: SLEEP 5000

              The SLEEP command causes the script to pause for the specified 
              interval.  For example, you would need a short delay after 
              issuing a modem reset command, before any more command would 
              be accepted by the modem.  When the pause is complete, script 
              execution continues on the next line.


      WAIT    - Wait for received text.

              Syntax: W[ait] <millisecs> <string> [exiterr]
              Example: WAIT 5000 Password: exiterr

              WAIT causes Xrouter to wait for specific responses from the 
              modem or remote host.  <millisecs> specifies the maximum wait 
              interval.  <string> specifies the string of characters (20 
              chars max, no spaces) to wait for.  When the string is seen in 
              the received data stream, the next script command is executed.

              If "exiterr" is present, the script will abort if the string 
              is not seen before the interval expires.  If not present, the 
              next script command will be executed upon timeout.


      Dial up networking may be administered "on the fly" using the DUN
      command , which is detailed in the sysop command reference section.  
      The DUN ADD and DUN LOG commands may also be used in IPROUTE.SYS
      and / or BOOTCMDS.SYS to set up the system at boot time.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  58

      Dial-up Networking


      Example DUN script
      ~~~~~~~~~~~~~~~~~~

      ; Xrouter DUN script for establishing PPP connection with my ISP
      ;
      ; Upon connection, the ISP sends some greetings text, then "Login:",
      ; and waits for login name.
      ; Upon receiving the login name it sends "Password:" and waits for
      ; the caller to send the password.
      ; When it receives the password, it sends "Entering PPP mode".
      ;
      ;
      ; Drop DTR to reset any modem error condition
      control down
      ;
      ; Wait for 1 sec
      sleep 1000
      ;
      ; Raise DTR to allow normal operation
      control up
      ;
      ; Specify the mode to use after link is established
      mode ppp
      ;
      ; ISP requires PAP authentication: username=gb7pzt password=bsfjflavs
      ppp pap user gb7pzt bsfjflavs
      ;
      ; Get the modem's attention
      send AT
      ;
      ; Wait for up to 5 secs for an "OK" response.  Abort if none
      wait 5000 OK exiterr
      ;
      ; Modem is awake.  Dial the ISP
      send ATDT01905643000
      ;
      ; Wait for up to 1 minute for the "user:" login prompt
      wait 60000 user exiterr
      ;
      ; Prompt obtained. Send username
      send gb7pzt
      ;
      ; Don't bother waiting for "password:" prompt, just send it after 1 sec.
      sleep 1000
      send bsfjflavs
      ;
      ; Wait for confirmation of entry to PPP mode
      wait 30000 PPP exiterr
      ;
      ; ISP is now in PPP mode.  XRouter will enter PPP mode when script ends
      ;













      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  59

      APRS - Automatic Packet Reporting System

      APRS
      ====

      In addition to NetRom and IP routing, frame piping, broadcasting and 
      normal digipeating, Xrouter supports 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 flags 
      in "digiflag" as follows:

               4      Enable RELAY generic APRS digipeating.
               8      Enable TRACE and TRACEn-N APRS digipeating.
               16     Enable WIDE and WIDEn-N (Well sited stations only!)

      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.
      In most areas, APRS tends to be on a separate frequency reserved for 
      "unconnected nets", and you may wish to prevent people from connecting 
      to the router or downlinking from it on your APRS-only ports.

      The CFLAGS keyword can be used in the PORT section of the CFG file to 
      control uplinking and downlinking as follows:

               0     Prevent uplinking and downlinking.
               1     allow uplinking only.
               2     allow downlinking only.
               3     allow both up and downlinking.

      You may choose to allow regular digipeating (i.e. using the router's 
      normal callsign or alias) on APRS ports, allow regular UI-only 
      digipeating, or disable regular digipeating altogether, by 
      manipulating bits 0 and 1 of DIGIFLAG.

      Whilst I urge all sysops to include an APRS position in their normal 
      IDTEXT, a dedicated APRS port may require a more detailed and cryptic 
      ID beacon, therefore you may define a different IDTEXT for each port 
      if necessary.  A "regular" port would include a position followed by 
      some human-readable text, whereas the APRS-only ports would include 
      additional data such as power / height / gain / direction, wind speed, 
      bowel movements etc., in encoded format.
      The IDTEXT may be sent via digipeaters by including the IDPATH keyword 
      in the relevant port configuration section of XROUTER.CFG.
      Xrouter checks for its own callsign or alias in previously-passed 
      digipeaters to prevent digi looping.  It will not digipeat frames it 
      originated, and will not digipeat the same frame within 9 seconds.

      The "DX [port]" command show the best received APRS DX. It only works 
      if the router's APRS position has been defined by including it
      in the ID beacon.
      The DXFLAGS keyword in the .CFG file controls whether or not the DX 
      list will contain callsigns heard via digipeaters.
      If bit 1 is set, Bits 3 - 14 specify the minimum distance which will
      be logged, from 4Km to 32764Km in 8Km steps, e.g. DXFLAGS=502 enables
      DX logging, with threshold of 500Km. If bit 1 is not set, bits 3-14
      are ignored.
      If DX logging is enabled, any received APRS positions which exceed the
      threshold distance are logged to LOG\DXLOG.TXT
      if bit 2 is set, the frame contents are logged too.





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  60

      APRS Queries


      APRS / UI-View queries
      ~~~~~~~~~~~~~~~~~~~~~~
      Xrouter responds to the following general queries:

          ?APRS?     All stations query. 

          ~\xFD~     UI-View general query.

          ?IGATE?    Igate query.

          The response to the first two is the ID beacon for the port, 
          which, if my recommendations were followed, should contain the 
          APRS position and station type.  The response to the ?IGATE? query 
          shows the message and local user counts.


      The following "directed" queries (directed at portcall) are supported:

          ?APRSD     Directly heard stations list.

                     Responds with a list of stations heard directly on the 
                     receiving port (i.e. not via digipeaters or via 3rd 
                     party networks)

          ?APRSM     Un-delivered messages query.

                     If there are any un-delivered or expired messages 
                     addressed to the sender of the query, they are re-
                     activated and transmitted on the port which received 
                     the query.

          ?APRSP     Station Position.

                     If the sysop has defined the router's position, it is 
                     sent in response to this query.

          ?APRSS     Station status.

                     The response consists of the software type and version, 
                     plus a list of the enabled generic digipeater calls.

          ?PING?
          ?APRST     Trace Route.

                     Both of these return the route by which the query was 
                     received.

          ~\xFE~n    UI-View "ping".

                     The response to this query is a UI-View ack for the 
                     ping id.

          ~\FC~n     UI-View "DX" query.

                     Responds with a UI-View ack, followed by details of the 
                     best DX heard directly by the router (digipeated 
                     packets are NOT dx as far as I'm concerned!)







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  61

      APRS Messaging


      APRS MESSAGING
      ==============

      Xrouter contains an APRS messaging shell, which allows NON-APRS users 
      to exchange messages with APRS / UI-View users, and also to send and 
      read bulletins and announcements.

      Messaging mode is initiated by from the main command prompt by 
      entering the command "AMSG <port>", where <port> is number of the 
      radio port on which messages will be sent and received.

      Within messaging mode, all commands begin with a forward slash (/), 
      and anything else is treated as message text for transmission.  The 
      commands are as follows:

               /A[nnouncements]    Show announcements
               /B[ulletins]        Show bulletins
               /C[ancel] [#]       List / cancel unacked message(s)
               /D[irects]          Show directly heard stations
               /H[elp] [cmd]       Display command help
               /Monitor [on|off]   Query / set traffic Monitor mode
               /Q[uit]             Quit (exit)
               /T[arget] [call]    Query / set target for msg
               /U[iview] [on|off]  Query / set UI-View mode
               /V[ia] [digis]      Query / set digipeater path
               /X                  Exit

      Only the first letter of each command needs to be supplied.  A few are 
      worthy of further explanation....

      The /D command shows a list of all the stations heard directly, i.e. 
      not via digipeaters or 3rd party networks.

      Before any type of message or query can be sent, the user must 
      specify a "target" address, using "/T [call]".  For messages, the 
      target will be a callsign.  For bulletins the target should be BLN#*, 
      where "#" represents a single digit, and "*" represents the bulletin 
      category of up to 5 characters.  Announcements use the same format as 
      bulletins, except that "#" represents a non-digit.  Attempting to send 
      a message without first defining a target will result in an error 
      response.  The target remains in force until a new target is 
      specified.  The current target can be displayed by entering "/T" 
      alone, or cleared by entering an invalid target, e.g. "/T .".

      Outgoing messages and bulletins are re-transmitted at intervals until 
      either an acknowledgement is received, or too many retries have taken 
      place.  Bulletins are re-transmitted every 20 minutes for 4 hours, 
      whilst announcements are re-transmitted every hour for 4 days. 
      Messages are initially re-transmitted after 10 seconds, then the 
      interval doubles with each re-send.  When the interval exceeds 
      approximately 1.5 hours, the message is expired and re-transmission 
      ceases.  The "cancel" command allows the re-transmission of outgoing 
      messages and bulletins to be cancelled at any time before expiry.

      The /M (Monitor) command allows other APRS and UI-View message traffic 
      on the channel to be watched.  The default is "off". Entering /M by 
      itself shows the current state.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  62

      APRS Messaging


      The /U (Ui-View mode) command sets the type of outgoing message to be 
      used.  The default is "off", which means that all outgoing messages 
      will be in APRS format.  If turned "on", outgoing messages will be in 
      "UI-View" format.  In either mode, both types of message can be 
      received.  UI-View messages will display with a tilde (~) between the 
      message and its ID, whereas APRS-format messages will display with a 
      curly opening bracket ({) if a message ID was supplied.  In UI-View 
      mode, "\<decimal>" will send a UIVIEW message whose text portion 
      contains a single byte of value <decimal>, e.g. "\254" will send a 
      PING request.

      /Q (quit) and /X (exit) are identical in function, exiting message 
      mode and returning the user to the router's main command prompt.

      The /V (via) command sets the digipeater path for outgoing messages, 
      or if used by itself displays the currently set path.  The path 
      defaults to the port APRSPATH specified in XROUTER.CFG.  In APRS mode, 
      the destination call is fixed at APZ###, where ### is the 3 digit 
      Xrouter version number, whereas in UI-View mode the destination call is 
      set by the /Target command.

      The /H (help) command is used to display help for the messaging 
      commands.  If no argument is supplied, a very brief (low bandwidth) 
      command resume is displayed.  If the help files are installed, "/H *" 
      will list the help available, and "/H <cmd>" can be used to obtain 
      more detailed help for <cmd>, e.g. "/H /V". Note that the leading 
      slash of the argument is ignored, so "/H V" is equally valid.

      Messaging notes
      ~~~~~~~~~~~~~~~
      If Xrouter receives an APRS message whose target address is a user 
      currently logged into the APRS messaging shell, the message is 
      delivered to the user and, if there was a message ID, an 
      acknowledgement is sent.  Each re-send of the message is acknowledged, 
      because a re-send probably indicates that the sender didn't receive 
      the previous ack.

      If the same message is received twice within 30 seconds, the second 
      copy is ignored.  This helps to eliminate duplicates received via 
      different digipeater routes.

      Expired messages are retained for 1 day before being deleted.  During 
      this interval they will be reactivated if a "?APRSM" query is received 
      from the target station.  Outgoing bulletins and announcements are not 
      retained after expiry.  Incoming bulletins are retained for 4 hours 
      after last received, and incoming announcements are retained for 4 
      days after last received.

      The APRS spec limits the maximum message length to 67 characters. 
      Because a message ID of up to 6 characters is appended to the message, 
      Xrouter splits messages longer than 61 characters into separate 
      messages no longer than 61 characters (excluding ID) each.

      All APRS facilities are an ongoing experiment and may be liable to 
      change as development continues.  The so-called "APRS Protocol 
      Reference" is rather fuzzy in places!








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  63

      APRS Internet Gateway


      APRS Internet Gateway (IGATE)
      =============================

      Xrouter has an inbuilt APRS Igate, which allows received APRS packets 
      to be gated to an Internet APRS server, and packets from the server to 
      be gated to RF.  You will need an APRS port and an internet connection 
      to take advantage of this.

      Igate operation is controlled mainly by configuration settings in file 
      IGATE.CFG.  If the file isn't present, the igate daemon can be 
      started, but nothing will happen.  The file includes keywords which 
      specify the Internet APRS server addresses, various timers controlling 
      connections, the filtering rules for gating packets, and the logging 
      options.  In addition to the settings in IGATE.CFG there are a few in 
      XROUTER.CFG, which control whether or not the Igate daemon starts at 
      boot-up, and which ports may send to and receive from the Internet.

      Choosing and specifying Internet Servers
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The choice of server, and the TCP port to use on that server, depends 
      on where in the world you are located, and what sort of data you're 
      interested in. There are several types of server, and the services 
      they provide aren't always comparable.

      Some servers provide a "raw" data feed containing APRS activity from 
      all over the world, which can amount to a considerable volume.  Some 
      also provide "filtered" or "local" feeds, e.g. Ohio-only or messages-
      only.  There's no point in connecting to a "raw" feed if there is a 
      "local" feed available, as you will merely be wasting CPU time and 
      internet bandwidth downloading data you are going to discard.  APRS 
      message-only feeds tend to be on port 1314, whereas "raw" feeds tend 
      to be on port 10151, or 2023 if it's a Ahub server.

      Using a browser to connect to http://server_address:14501 sometimes 
      produces a status page containing useful server addresses. You could 
      start your search at "first.aprs.net".  There are various web sites 
      which may assist your search, e.g. "www.dididahdahdidit.com/" (what a 
      difficult and error-prone address to type!).   I suggest you ask 
      questions on the APRS newsgroups if you are unsure, but if you're 
      reading this file you probably know more than me about APRS anyway :-)

      In IGATE.CFG you may specify as many servers as you wish, each on a 
      separate line with the following format:

               SERVER <address/hostname>:<port>

               e.g. SERVER 128.196.58.1:1314

      The port number must be separated from the IP addressor hostname 
      by a colon so that the combined address:port forms a contiguous 
      string of characters with no spaces.













      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  64

      APRS Internet Gateway


      The servers are tried in rotation, starting with the first on the 
      list. If a connection attempt fails, or the link subsequently closes, 
      the next server is tried.  When the end of the list is reached it 
      starts all over again at the first one.  This is probably a 
      crummy algorithm, whose only merit is that it distributes the load 
      across various servers, and I may have revised it by the time you read 
      this!  The behaviour is modified by various timer settings - see 
      below.

      You may find out which server is currently in use by using the "TCP 
      STATUS" command.


      Connection Timers
      ~~~~~~~~~~~~~~~~~
      There are various keywords which may be used in IGATE.CFG to control 
      the timings associated with connections to the Internet servers, and 
      they are as follows:

          WAIT <secs> -- Time to wait for connection establishment.

          Specifies the number of seconds to wait for connection after 
          sending a connect request.  If not specified, the default is 60.  
          If you have a permanent Internet connection, you may wish to set a 
          lower value, but if you're using dialup you may wish to make it 
          longer, e.g. 90 secs to allow time for dialling and modem 
          negotiation.  If no response is received from the server within 
          the WAIT interval, the next server in the SERVER list will be 
          tried.

          PAUSE <secs> -- Interval between successive tries.

          Specifies the number of seconds to wait between successive 
          connection attempts to the same server.  Default is 60 secs.  If a 
          server goes down or fails to respond, there's no point in 
          aggressively trying to connect. For one thing, if you have 
          connection logging enabled you will build a big logfile! This 
          timer is mainly of use when you have only one server in you 
          SERVERS list, or when several servers go down.

          MAXTRIES <n> -- No. of failed connect attempts allowed.

          If a server consistently fails to respond to connect attempts, 
          there's a good chance it has gone temporarily or permanently off 
          line.  The MAXTRIES value specifies the maximum number of failed 
          connect attempts allowed before a server is ignored, and the 
          default is 10.  If the limit is reached, that particular server 
          will not be retried until the SKIP interval (see below) expires.

          SKIP <secs> -- "Blacklist" interval.

          Specifies the amount of time for which a server will not be tried 
          after MAXTRIES failed connect attempts.  This effectively removes 
          a server from the list for the SKIP interval, after which it is 
          placed back on the list. Default is 3600 secs (1 hour).









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  65

      APRS Internet Gateway


      Packet Filtering
      ~~~~~~~~~~~~~~~~
      It is unlikely that you will find an internet server which 
      provides a feed tailored exactly to your needs, so the Igate 
      contains powerful packet filters, which can be applied to traffic 
      gated in both directions.  The filtering rules are specified in 
      IGATE.CFG using IFILTER (internet to packet) and PFILTER (Packet to 
      internet) statements, the general form of which are as follows:

               xFILTER <from_call> <to_call> <text>

      Each field may include the following wildcards:

               *     Matches zero or more characters.
               ?     Matches any single character.
               #     Matches a single digit.
               @     Matches a single alphabetic character.
               \     Escape - interpret next character literally.

               The '*' character may only be used at the end of a field.

      For example:  "IFILTER G#@@@*  *  :*" will accept from the internet 
      feed only those packets sent by valid G0 to G9 + 3 letter callsigns, 
      addressed to anyone, which contain APRS messages.

      The '\' (escape) character causes the next character to be interpreted 
      literally, instead of as a wildcard, e.g. "\*" will match '*' and "\\" 
      will match '\'.  A caret '^' at the start of any field will invert the 
      sense of the whole test, causing matching packets to be REJECTED, e.g. 

               IFILTER ^M7ABC  *    *
               IFILTER *       ^APZ244*   !*

      The first statement will reject all packets from M7ABC, and the second 
      will reject all static position reports sent to the destination APZ244 
      (e.g. if they can't be trusted).  Rejection statements MUST be placed 
      at the beginning of the filter rules, before any catch-alls.

      The maximum length of each field (pattern) is currently 10 characters.  
      If you feel this isn't enough, let me know.  There is no limit to the 
      number of xFILTER statements you may specify.  If no rules are 
      specified, nothing will be gated.

      All valid APRS and UI-View packets (except 3rd party packets, and 
      those with NOGATE or RFONLY somewhere in the digi path) received 
      by the router are offered to the PFILTER, providing the appropriate 
      DIGIFLAGS are set (see below). Mic-E packets are decoded to text 
      before being offered to the Internet servers because they may contain 
      characters which won't pass through the servers.  This decoding takes 
      place before filtering.

      You should be VERY careful when designing your filter rules, as you 
      could quite easily overload the RF channel by attempting to gate too 
      much data to it.  There is little point in gating non-local data.

      To reduce unnecessary traffic, APRS "messages" are only gated to RF if 
      the recipient has been seen locally on RF within the last hour.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  66

      APRS Internet Gateway


      Radius of Interest
      ~~~~~~~~~~~~~~~~~~
      In IGATE.CFG the statement "RADIUS <km>" sets a radius in Kilometres 
      from Xrouter's position.  Position reports from within this radius 
      will be gated to RF, providing they pass the IFILTER rules.  The 
      default radius is 100Km.  Setting "RADIUS 0" allows unlimited gating 
      of positions.


      Controlling gating direction / port(s)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Regardless of any other settings, an Xrouter port will not broadcast 
      packets received from the Internet, or offer received packets to the 
      internet, unless the appropriate bits are set in the port DIGIFLAG.  
      You should add the following values:

                64   Enable gating from Packet to Internet.
               128   Enable gating from Internet to Packet.

      Packets accepted (i.e. passing IFILTER) from the Internet will be 
      broadcast on ALL ports which have bit 7 of DIGIFLAG set, so be 
      careful not to lazily set a value of 255!


      Activity logging
      ~~~~~~~~~~~~~~~~
      Igate activity can be recorded in the file ./LOG/IGATE.LOG by 
      including a LOG keyword with non zero argument in IGATE.CFG. The 
      argument is a number made up as follows:

               1     Record Igate daemon start and stop events.
               2     Record Inet server connections / disconnections.
               4     Record frames sent from Internet to Packet.
               8     Record frames sent from Packet to Internet.

      The "record frames" options can generate a lot of data, so they're 
      intended mainly for testing purposes, e.g. making sure your filters 
      are correctly set.  If the logfile grows too big, DOS may take an 
      appreciable time to perform the disk writes if you aren't running a 
      write cache.  This might affect router performance, so you are advised 
      to periodically rename or otherwise remove the logfile, allowing a 
      fresh one to start.


      Starting and stopping the Igate daemon
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The daemon may be started and stopped at any time with the commands 
      "START IGATE" and "STOP IGATE".  If the daemon is already running, 
      attempting to restart it will simply produce an error message, as will 
      trying to stop it if already stopped.

      The IGATE.CFG file is re-read each time the daemon is started, so the 
      configuration can be changed simply by editing the file using the 
      PZTDOS line editor, then re-starting the daemon.  Editing can take 
      place while the daemon is running.

      The daemon may be started automatically when Xrouter boots, by 
      including IGATE=1 in the "global" section of XROUTER.CFG.






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  67

      APRS Internet Gateway


      Getting an Internet Connection
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      None of the above is of any use if you haven't got some means of 
      getting a connection to an Internet APRS server.  You therefore need 
      to set up dial-up-networking (see elsewhere) with a PSTN modem, or use 
      a cable modem, or use an external router or Internet Connection 
      Sharing (ICS) machine, such as one running Windows 98.

      I chose to use Windows 98 with a dial-up connection, since the machine 
      was already in use for my email and web activities.  Your Windows 
      machine and your Xrouter machine will need to be interconnected, 
      either by SLIP or PPP null modem link, or by Ethernet.  If Xrouter is 
      located on the Windows machine, you will need two Ethernet cards in 
      that machine, as it can't share a card - sorry :-(

      You will also need to install (if not already installed) Windows 
      "Internet Connection Sharing" (ICS).  A wizard will guide you 
      painlessly through the process of screwing up your machine :-) No, 
      seriously I think my troubles arose because I already had several IP 
      addresses in use on that machine and was unsure what I was doing.  If 
      you know anything about ICS, please share your wisdom to make this 
      document more useful! (I know next to nothing about Windows)

      Basically, ICS configures your windows machine's Ethernet port with 
      the "private" IP address 192.168.0.1, and you simply configure other 
      computers on the Ethernet LAN to use any address between 192.168.0.2 
      and 192.168.0.255. You should choose the option to use a static IP 
      address not a "server assigned" address.

      On the Xrouter machine you need to install a suitable Ethernet card 
      driver plus ETHDRV.EXE, and set up an Ethernet port (see XROUTER.DOC 
      for details).  The port should be configured to use one of the 
      "private" IP addresses other than 192.168.0.1 - you may do this by 
      setting the "global" IP address and overriding it on the radio ports, 
      or by setting only the Ethernet port to use the private address.

      Finally, you need to set up IP routing to and from the Windows 
      machine.  If the wizard has done its job properly, Windows 98 will 
      automatically route all "private" IP packets to the ethernet port, and 
      all you have to do is tell Xrouter how to route stuff to Windows.  I 
      can't be precise on this, since your requirements will be different to 
      mine. Basically you must arrange to route Internet-bound packets 
      towards 192.168.0.1 on the Ethernet port.  You can either do this 
      using a ROUTE DEFAULT or using ROUTE ADD's for specific addresses.

      In my case I have ROUTE ADD statements which route radio-reachable 44-
      land datagrams out on the appropriate radio port.  I then have a 
      "ROUTE ADD 192.168.0.0/24 * 14 d" which allows Xrouter to send 
      datagrams directly to my other machines on port 14 (the ethernet LAN), 
      a "ROUTE ADD 44.0.0.0/8 x x" which routes the rest of 44-land to my 
      neighbour, and finally a "ROUTE DEFAULT 14 192.168.0.1 d" which routes 
      everything else to the Windows machine for sending to the Internet.

      Remember: The software is well proven. If it doesn't work, you haven't 
      configured it correctly!









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  68

      APRS Server


      APRS SERVER
      ===========

      Xrouter includes a rudimentary APRS server, which enables suitable 
      APRS clients, such as UI-View, to connect to it on your LAN and 
      exchange APRS traffic. The number of simultaneous clients is not 
      limited.


      TCP Port Number
      ~~~~~~~~~~~~~~~
      The server listens for incoming connections on TCP port 1448.  There 
      is a tradition of choosing port numbers which represent the 
      frequencies used by APRS, so I chose that port number because many 
      European countries use 144.800 MHz, hence it is easy for me to 
      remember (sorry USA :-).


      Overview Of Server
      ~~~~~~~~~~~~~~~~~~
      The following APRS packets are sent to clients:

       - APRS traffic heard on any of Xrouter's radio ports.

       - Traffic sent by other clients.

       - Traffic sent by users of Xrouter's APRS messaging shell.

        - Filtered traffic from Internet APRS servers (if Xrouter's IGATE is
         connected to an internet APRS server)


      APRS packets from clients are distributed as follows:

       - To other clients, excluding the sender.

       - To Xrouter's APRS messaging shell.

       - To radio ports (only if client is fully registered)

       - To Internet APRS servers via IGATE (if IGATE is running).























      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  69

      APRS Server


      Registration and Login
      ~~~~~~~~~~~~~~~~~~~~~~
      Registration of clients is necessary to prevent unauthorised use of 
      radio frequencies by unlicensed people.

      This may seem overly restrictive if your system is only used on a 
      private LAN, but if you are connected to the Internet, it is 
      essential.  For example, if an unlicensed user connects to your server 
      via the Internet, he must be prevented from sending traffic to your 
      local RF ports.  He must also be prevented from sending traffic via 
      your IGATE (if it is enabled) into the Internet system, and thence to 
      other people's RF ports.

      Therefore, clients are required to complete a log-in process before 
      they are allowed to send any traffic.  Log-in is not required for 
      receive-only operations.

      The server accepts two different types of login.  When a user 
      registers an APRS client program such as UI-View, he receives a 
      "validation number" which Xrouter will use in combination with the 
      callsign to verify the user.  A verified user may send traffic to 
      local RF ports, or if IGATE is active, via other IGATES.

      If the user has not registered his copy, the default validation number 
      of "-1" allows him to send traffic to other clients and to the 
      Internet, but that traffic will not be gated locally to RF, and is 
      marked in such a way that it will not be gated to RF by other IGATES. 
      This allows unregistered clients to communicate with each other via 
      the Internet, but not via RF.  The client may only send APRS packets 
      whose source callsign matches the login callsign.

      The alternative login system allows clients to verify themselves by 
      supplying their callsign and a password which has been agreed with the 
      sysop.  The password replaces the validation number in a login string.

      The login string is the only "command" accepted by the server, and 
      must take the form: "user <callsign> pass <password>", where 
      <password> could be either a validation number or a text string, for 
      example, "user g8pzt pass beanzmeanzheinz", or "user g7zzz pass 
      32751". Login is not acknowledged.


      The Client Connection
      ~~~~~~~~~~~~~~~~~~~~~
      There is no time-out on client connections, therefore there is no need 
      for the client to send "keep-alive" signals.

      If the client connection is too slow to cope with the incoming data 
      rate, packets to the client may be discarded.















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  70

      APRS Server


      Local <> Internet Server Gating
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      If IGATE is not running, no packets will be gated to or from the 
      Internet.

      Packets received from the Internet are not gated to clients unless they 
      satisfy the IFILTER filtering rules in IGATE.CFG.  Likewise, packets 
      received from clients are not gated to the internet unless they 
      satisfy the PFILTER rules.

      Packets in "third party" format, packets which do not include the 
      network identifier "TCPIP" in the digi path, and packets which include 
      the dummy callsigns NOGATE or RFONLY in the digi path, are not gated 
      to the Internet.


      Using UI-View as a Client
      ~~~~~~~~~~~~~~~~~~~~~~~~~
      Select Setup/APRS Server Setup.

      In the box marked "Select A Server", enter the hostname and port 
      number of Xrouter's APRS server, e.g. "myserver:1448" or 
      "192.168.0.2:1448".  (On my Windows98 system, neither form would work 
      until I added a suitable entry into the HOSTS file in the WINDOWS 
      directory.)

      Check the boxes marked "Open the gateway" and "Gate local messages".

      If you have a registered version of UI-View, check the box marked 
      "APRServe log on required", and enter your validation number.

      If your copy is unregistered, you will be able to log on with the 
      default validation number of -1, but your packets will not be gated to 
      RF.

      To obtain full privileges using an unregistered copy, you must have a 
      password, which must be registered with your callsign in Xrouter's 
      USERPASS.SYS file.  The callsign must not include the SSID, e.g. if 
      UI-View's callsign is "G8PZT-11", the entry in USERPASS.SYS should 
      simply be "G8PZT".  Un-check the "APRServe log on required" box, and 
      in the box marked "Text to send upon connection" enter UI-View's 
      callsign (with SSID) and your password in the following form:

              user g8pzt-11 pass virago




















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  71

      TNC2 Emulator


      TNC2 EMULATOR
      =============

      This is a feature which allows RS232 devices such as weather stations, 
      dumb terminals, GPS and telemetry devices to send and receive packets 
      as if connected to a real TNC2.

      For example, imagine you have a weather station which is designed to 
      be connected to a TNC via an RS232 cable.  Now imagine that you 
      already have an APRS port on your Xrouter.  How would you get you 
      weather station on air?  You could use an additional TNC, radio and 
      antenna, but that would be a pointless duplication of equipment.  Far 
      better to set up Xrouter to emulate a TNC so that it can interface 
      directly to the weather station, allowing the weather station to send 
      to, and receive from, the existing APRS port.

      Or you may have a dumb terminal connected to Xrouter via an RS232 
      cable, and use it to monitor any port, make connections with other 
      stations etc.  This is completely independent of Xrouter's command 
      interface, and does not reuire a session with the node.

      Perhaps you wish to keep an eye on the channel with a data logging 
      program, or send the channel activity to a serial printer?  The 
      possibilities are limited by your imagination.

      The emulator is configured by defining an INTERFACE with TYPE=ASYNC 
      and PROTOCOL=TNC2.  Choose SPEED to suit the peripherals, and MTU=256.  
      You don't attach a port to this interface.

      Example:

           INTERFACE=5
                TYPE=ASYNC
                COM=1
                SPEED=19200
                PROTOCOL=TNC2
                MTU=256
           ENDINTERFACE

      Standard TNC2 commands recognised are Ctrl-C, AUTOLF, CONNECT, 
      CONVERSE, DISCONNECT, ECHO, FLOW, HEADERLINE, K, MCON, MONITOR, 
      MYCALL, PORT, and UNPROTO.  If you need any others I will be happy 
      to add them.
      You may set the TNC's callsign (using MYCALL) completely independently 
      of Xrouter's callsign, and select any port with the PORT command.

      You can have as many TNC emulators as you wish, providing you have an 
      RS232 port for each one.  You should preferably use a different MYCALL 
      or SSID for each one if there is any chance of more than one TNC being 
      used on the same radio port.

      All settings are saved to the file TNCn.CFG where 'n' is the interface 
      number.  This file is created if it doesn't already exist, and is read 
      at start up, so the TNC always returns to its previous configuration.  
      The file contains binary data, so you must not attempt to edit it.

      Note: The emulator does not accept incoming connections - I can't see 
      the point, but if anyone really wants that facility I will add it.






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  72

      AXIP Tunnelling


      AXIP TUNNELLING
      ===============

      AXIP is AX25 "encapsulated" within (i.e. carried in the payload 
      section of) IP datagrams.  It enables AX25 systems to communicate with 
      each other via any TCP/IP network such as the Internet.  The AX25 
      links thus created can in turn support Netrom and amateur TCP/IP.

      Assuming you have a prospective AXIP partner, you would set up an 
      AXIP wormhole as follows:

      1)  Configure and test IP routing between you and your partner.
          If you don't have reliable IP routing there's no point in 
          proceeding!

          If you are linking via the Internet, it makes sense to use the 
          Internet IP addresses for this purpose, rather than the amateur 
          ones, because the routing is more reliable and the throughput 
          faster.

      2)  If you wish to use your partner's hostname (e.g. g8pzt.ath.cx) 
          instead of the IP address (e.g. if the partner has a dynamic IP 
          address), your system needs access to a Domain Name Server (DNS).

          If Xrouter is connected directly to the internet via a relatively 
          dumb device such as a telephone or cable modem, it can obtain the 
          address of a suitable DNS via PPP or DHCP negotiations.

          If it is connected indirectly, via a more sophisticated device such 
          as a firewall, an Internet Connection Sharing system (Windows98 
          ICS) or a good quality xDSL modem, it is likely that such a device 
          will have an inbuilt "DNS proxy server", which will answer DNS 
          requests on behalf of the LAN.  If the device is DHCP-capable, 
          and you have configured Xrouter to use DHCP, Xrouter will 
          automatically know the address of the DNS proxy.

          If you are not using DHCP or PPP you must include a valid 
          "DNS=..." statement in XROUTER.CFG, e.g. "DNS=88.23.207.1". Note 
          that you must supply the IP address of the DNS, not its hostname.  

          Verify that "PING <hostname>" resolves the address properly.


      3)  Add an AXIP interface to XROUTER.CFG as follows:


          INTERFACE=7
              TYPE=AXIP
              MTU=256
          ENDINTERFACE

          (Choose the interface number to suit yourself).

          This interface can support an unlimited number of AXIP ports. 
          You may define more than one AXIP interface if your ports need 
          differing MTU's.

          Only TYPE=AXIP and MTU= are required, all other parameters will be 
          ignored (at present).





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  73

      AXIP Tunnelling



      4) For each AXIP partner, add an AXIP port similar to this:

          PORT=5
              ID=AXIP link with WA3DXX
              INTERFACENUM=7
              IPADDRESS=44.131.91.245
              IPLINK=55.73.88.69
          ENDPORT

          You must specify at least ID, INTERFACENUM, and IPLINK.  

          IPLINK is the remote host's IP address or hostname.  It is more 
          efficient to use IP addresses, if you are able to do so, because 
          it removes the need to resolve the hostnames.  The "protocol 
          number" for AXIP is fixed at 93 (decimal).

          IPADDRESS is only required if you wish to encapsulate IP traffic 
          within the AXIP frames, and then only if it differs from Xrouter's 
          main IP address.

          MAC parameters such as TXDELAY, TXTAIL, SLOTTIME, PERSIST, 
          FULLDUP, SOFTDCD etc. are meaningless for AXIP, but FRACK, 
          RESPTIME, PACLEN, MAXFRAME, QUALITY etc. operate as normal.  
          
          On fast internet links you may wish to use a much lower FRACK, say 
          2000ms, than on radio.  I would not recommend reducing it below 
          1000ms, as it needs to be *at least* twice the worst round-trip 
          time plus the other end's RESPTIME.
        
          RESPTIME is probably the one which will have most effect on the 
          responsiveness of the system, because it controls the time delay 
          between receiving a packet and sending an ACK.  It should be just 
          a little more than the time it takes to receive a maximum length 
          packet.  For example, at a data rate of 56Kbits/sec, a 256 byte 
          packet lasts less than 50msec, so RESPTIME=50 would be adequate.


      5)  If Xrouter is indirectly connected to the internet via an
          intermediate router, that router will probably be using some form 
          of NAT (Network Address Translation) to share one "public" IP 
          address between several systems on your LAN.  The "front end" 
          router will probably route outgoing AXIP without problem, but it 
          will not know to which machine to send incoming AXIP unless 
          explicitly configured.

          Configuring such a router for AXIP usually involves specifying a 
          protocol number (93), and the LAN IP address of a machine to which 
          it should be routed, i.e. Xrouter's LAN IP address.

          You are advised that not all front end routers can be configured 
          to route incoming AXIP as it is not a commercially recognised 
          protocol.  Some routers will only allow TCP and UDP port 
          redirection, with no provision for any other protocol.  Windows 98 
          ICS will not route incoming AXIP, but there are (at a price) non-
          Microsoft programs which will do so.

          If you are lumbered with such a router, you may need to consider 
          AXUDP instead - see later.





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  74

      AXUDP Tunnelling


      AXUDP TUNNELLING
      ================

      AXUDP is AX25 "encapsulated" within UDP datagrams.  This enables AX25 
      systems to communicate with each other via TCP/IP networks such as the 
      Internet.  It is slightly less efficient than AXIP, because there is 
      an extra 8 byte UDP header between the IP and AX25 headers in the 
      frame, but the difference is not significant.  The major advantage of 
      AXUDP over AXIP is that it can usually be handled by front end routers 
      such as Windows 98 ICS without much problem.

      The procedure for setting up an AXUDP wormhole is very similar to that 
      for setting up AXIP, and you should first read the AXIP section 
      elsewhere in this manual.

      The differences are as follows:

      1)  Instead of (or in addition to) the AXIP interface, add an AXUDP
          interface to XROUTER.CFG as follows:

          INTERFACE=9
              TYPE=AXUDP
              MTU=256
          ENDINTERFACE

          As with AXIP, this interface can support an unlimited number of 
          AXUDP ports.  Multiple AXUDP interfaces are allowed.


      2) For each AXUDP partner, add an AXUDP port similar to this:

          PORT=8
              ID=AXUDP link with VK1UDP
              INTERFACENUM=9
              IPADDRESS=44.131.91.245
              UDPLOCAL=93
              IPLINK=27.69.88.73
              UDPREMOTE=93
          ENDPORT

          See the AXIP section for a discussion of the required parameters.

          UDPLOCAL and UDPREMOTE are the UDP "service port" numbers for each 
          end of the link, and if omitted they default to 93.  Don't confuse 
          these with *protocol number* 93, which is AXIP.


      3)  If you are using a front end router, xDSL modem etc. you will need
          to "open" UDP port 93 (or your UDPLOCAL number if it differs from 
          the default), to allow incoming UDP frames to be directed to 
          Xrouter's IP address.  For Windows 98, a very useful program 
          called ICSCFG can be obtained from the internet for this purpose.  

          Some routers don't have the facility to open specific UDP ports, 
          but at the very least should allow you to direct all UDP traffic 
          to a specified IP address.








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  75

      IPUDP Tunnelling


      IPUDP TUNELLING
      ===============

      IPUDP is IP encapsulated in UDP/IP.  It allows amateur IP to be 
      transported across other TCP/IP networks such as the Internet, to form 
      "Virtual Private Networks" (VPN's).

      Whereas IPIP (commonly called Encap) transports the private (e.g. 
      amateur) IP directly inside the payload portion of a public (e.g. 
      Internet) IP datagram, IPUDP transports the private datagram in the 
      payload portion of a UDP frame, which is itself transported as payload in 
      a public IP datagram.  This requires 8 bytes more overhead than IPIP, 
      but it is far more flexible.

      IPIP is a "portless" protocol, and it is therefore difficult (in come 
      cases impossible) to get it to pass through some types of NAT / PAT 
      router which rely on translating TCP and UDP service port numbers in 
      order to share a public IP address among several LAN hosts.

      IPUDP overcomes this limitation because it transports the data using 
      a well known protocol (UDP) which NAT / PAT routers can understand, 
      thus it can get through where IPIP cannot.  For example, it is easy to 
      configure Windows 98 Internet Connection Sharing (ICS) to route 
      incoming IPUDP to a specific machine on the LAN, but it is not 
      possible to do this with IPIP.

      IPUDP currently uses UDP service port 94, simply because I found it 
      easy to remember, and there seemed to be no other significant 
      protocols using this number.  As originator of this protocol, if 
      difficulties are encountered with port 94, please tell me (G8PZT).

      In order to establish an IPUDP link, you and your link partner must 
      first set up and test IP routing between your public IP addresses.  
      If you are using a "front end" router between Xrouter and the 
      Internet, you must "open" UDP port 94 to direct incoming traffic to 
      Xrouter.  Finally you must add an extra IP route entry as follows:

           IP ROUTE ADD 44.131.91.0/24   62.31.206.176  5    u

           (Omit the "IP" if the entry is used in IPROUTE.SYS)

      The first IP address is the amateur IP address, or range thereof, to 
      be routed via this IPUDP link.  If you don't fully understand this 
      format, see the manual sections detailing IPROUTE.SYS and the IP ROUTE 
      ADD command.

      The second address is the IP address or hostname of the link partner 
      to whom the first address(es) will be routed.  It is more efficient to 
      use an IP address if possible.  Your system MUST be told how to reach 
      that partner, so you will need an existing routing entry which applies 
      to it.

      The "5" is the number of the port on which the datagrams will be 
      transmitted.  This port obviously needs a public IP address, or one 
      which will be translated to a public address by a front end router.

      Mode "u" signifies IPUDP encapsulation.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  76
   
      Xpipe


      USING XPIPE to provide a SLIP link EXTERNAL interface
      =====================================================
  
      XPIPE v1.0 by Paula Dowie G8PZT

      Full Duplex SLIP Pipe for Xrouter / Xserv EXTERNAL Interface


      XPIPE is a small TSR which allows two XROUTERs, two XSERVs, or one of
      each, located on a single Windows machine, to route TCP/IP traffic to
      each other.


      Why was Xpipe written?

      If you wish to run XServ as a BPQ-style "application", with XRouter
      providing the AX25, Netrom and TCP/IP communication layers, the
      PZTHOST.EXE TSR already meets the requirement.  PZTHOST can support
      many applications of different types simultaneously.  There is however
      a big disadvantage inherent in the BPQ Host API, namely the fact that
      if XRouter is re-started, certain types of application (which is the
      majority of them) *must* be re-started too.

      If XServ is the *only* application being supported by XRouter, a far
      better method is to forget about the outdated BPQ API.  XServ
      has a complete TCP/IP stack of its own, thus you can use TCP/IP
      to interconnect XRouter and XServ, using a pair of Ethernet cards or
      two COM ports and a null modem.  By using proxies, XRouter can still
      provide all the AX25 and NetRom services for XServ, via the TCP/IP
      link.  The big advantage with this method is that if either program
      is re-started, the other one is not affected.  It saves the memory
      which PZTHOST would have occupied, but the Ethernet drivers require
      memory.

      You may however be unable or unwilling to fit 3 Ethernet cards in 
      your machine (one for XRouter, one for XServ and one for Windows), 
      or to reserve two COM ports for the purpose, so this is where 
      XPipe provides the solution.

      XPipe provides the software equivalent of a pair of linked Ethernet
      cards and all their drivers.  Like ETHDRV.EXE it is interfaced to
      XRouter and XServ using the EXTERNAL interface type, but the PROTOCOL
      is set to "SLIP" instead of HDLC or ETHERNET.  Since there are only
      two hosts using the pipe, there is no need for "hardware addresses",
      hence the overhead of ISO Layer 2 (AX25 / Ethernet) is not required.
      XPipe is full duplex, and can buffer up to 20 frames of 335 bytes.
      This should be more than adequate for most purposes, but I am willing
      to review the buffer sizes and queue lengths in future.  I have not
      managed to overload it yet, and the odd lost frame is of no 
      consequence anyhow.


      Using XPipe 
      With XRouter:

      XRouter and XServ communicate with XPipe using software interrupts,
      in exactly the same way as they do with ETHDRV.  XPipe responds to
      two consecutive software interrupts, one for each end of the pipe,
      e.g. interrupts 99 and 100 or 120 and 121.  The pipe is completely
      symmetrical, so it doesn't matter which host uses which end of the
      pipe.



      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  77

      Xpipe      

      As with ETHDRV or PZTHOST, XPIPE *must* be loaded before Windows is
      started, preferably by putting it in AUTOEXEC.BAT.  The program
      takes one argument, namely the lower of the two software interrupts
      in decimal. For example, "XPIPE 120" loads XPipe onto interrupts 120
      and 121.  The argument must be between 96 and 254 inclusive.  The
      
     

      XPIPE.COM version occupies around 6k of memory, most of which is
      buffer space, whilst XPIPE.EXE occupies 15k.  I can see no advantage
      in using the .EXE version.

      To use XPipe, XRouter needs an INTERFACE with TYPE=EXTERNAL,
      PROTOCOL=SLIP, MTU=256 (335 max.), and INTNUM set to one of the two
      software interrupts which XPipe has been configured to use.
 
        INTERFACE=1
        TYPE=EXTERNAL
        INTNUM=120
        PROTOCOL=SLIP
        MTU=256
        ENDINTERFACE

      A PORT attached to this interface will support TCP/IP.  However, if
      you are linking two XRouters, you also have the option of using HDLC
      protocol instead of SLIP, allowing them to talk AX25 to each other.
      Either way, the interface will support AX25, Netrom and TCP/IP. If
      you choose SLIP as the link protocol, AX25 can be supported by
      encapsulating it as AXIP or AXUDP.  If you choose HDLC as the link
      protocol, TCP/IP can be supported by encasulating it in AX25.


      With XServ:

      To use XPipe with XServ, the corresponding statement in PORTS.SYS is
      similar to this:

      #IFACE EXTERNAL <intnum> <mode> <mtu> <label>
      #--------------------------------------------
      iface  external   121     slip   256   slip1
   

      Note that XServ is basically a TCP/IP *server*, and does not 
      therefore include AX25 functionality.  Thus you cannot use 
      HDLC mode with XServ.


      Notes:

      XPipe may be unloaded from memory by adding the second argument 'U' 
      to the interrupt number, e.g. "XPIPE 120 U" will unload an XPIPE 
      which was previously installed on interrupts 120 and 121.

      You may run several copies of XPipe, providing all the interrupt 
      numbers are different.
      
      XPipe and this document are copyright (c) Paula Dowie G8PZT 2003



      




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  78

       Fec

       Forward Error correction between XROUTERS

      
      Added Forward Error Correction (FEC) for AX25 inter-node radio links.
      This can only be used with SCC cards, YAM modems, or specially modified
      multidrop KISS Eproms.  It will correct several errors per packet,
      allowing a marginal link to perform much better, or an acceptable link
      to use larger paclens, which in either case should improve throughput.
      FEC will only work if *both* ends of a link are using it, and the
      transmissions are *NOT* compatible with normal AX25.  I stress again
      that this is intended for *inter-node* links, not on user access
      channels.  There is no other software capable of using FEC, so it can
      only be used between two Xrouters.  There is no point in using it on
      AXUDP links, because those links do not suffer bit errors.
      FEC is enabled on a port by including FEC=1 in the PORT configuration.

      The file KISSFEC.BIN, included in this archive, is a binary image for a
      multidrop polled KISS eprom suitable for use with FEC.  It is not
      suitable for normal AX25 operations.  In usual BPQKISS style, the byte
      at offset 20h should be changed to suit the KISS channel number.  The
      supplied image defaults to channel A.












































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  79

      Point to Point Protocol


      POINT TO POINT PROTOCOL
      =======================

      Point to Point Protocol (PPP) is a protocol suite intended for use 
      over simple links which transport packets between two peers, such as
      an RS232 link.

      Unlike SLIP, it includes facilities for link control (e.g. management 
      of a dial up link), user authentication, negotiation of IP addresses, 
      and the multiplexing of several protocols across a common link.

      It is designed to be self configuring.  Most of the options have 
      standard default values, and peers negotiate anything which differs 
      from the default.

      Xrouter currently implements the most common PPP sub-protocols:

              - Link Control Protocol (LCP)
              - Password Authentication Protocol (PAP)
              - IP Control Protocol (IPCP)

      Most sysops will have no need to remember these protocol names and 
      acronyms.  However, for those who wish to experiment, each protocol 
      has its own set of commands.

      PPP has largely replaced SLIP for dial-up Internet access, and the 
      interconnection of peers via RS232.

      If you want to know more about the internal workings of PPP, it is 
      specified in RFC1661.


      Configuring Xrouter for PPP
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      There are three ways in which PPP may be used:

              - Wired links.
              - Dial-in.
              - Dial-out.

      The first case requires an interface to be configured to use PPP, but 
      the other two cases temporarily establish a PPP link on a MODEM 
      interface.  Each case is described in more detail below:


      Using PPP on Wire Links
      ~~~~~~~~~~~~~~~~~~~~~~~
      In XROUTER.CFG, define an interface with TYPE=ASYNC and PROTOCOL=PPP.
      For example:

      INTERFACE=1
              TYPE=ASYNC
              COM=1                   ; 1-4 or specify INTNUM/IOADDR
              SPEED=19200             ; Adjust as necessary
              PROTOCOL=PPP
              MTU=1600
      ENDINTERFACE







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  80

      Point to Point Protocol


      Now "bind" a port to that interface thus:

      PORT=1
              ID=PPP link to Win98    ; Text to identify port
              INTERFACENUM=1          ; Bind to PPP interface
              IPADDRESS=192.168.0.4   ; Optional (see below)
      ENDPORT


      The use of IPADDRESS is optional.  If the keyword is omitted, 
      Xrouter's "global" IP address will be used on that port.  If the 
      address is specified as 0.0.0.0, it signifies that a "dynamic" IP 
      address should be obtained from the peer, otherwise the specified 
      address will be used.

      The port is now ready for PPP using the standard PPP defaults, but if 
      it requires any further configuration you may include the relevant PPP 
      configuration commands in the file BOOTCMDS.SYS, which is read by 
      Xrouter after it has finished executing XROUTER.CFG.


      Using PPP on Dial-in links
      ~~~~~~~~~~~~~~~~~~~~~~~~~~
      The interface and port should be configured for PROTOCOL=MODEM as 
      described in the manual section "PSTN Modem Support".

      When a logged-in caller issues the command XLINK PPP, Xrouter will 
      automatically re-configure the port to support PPP.  It will then look 
      for the file "PPPHOST.n", where n is the port number, and if found, 
      the PPP configuration commands within the file will be executed.  The 
      file may optionally contain NAT configuration commands if required. 
      The PPPHOST file is optional.  If not present, PPP will be initialised 
      to the standard defaults.

      When the hardware link disconnects (e.g. user says goodbye or hangs 
      up, link times out, or sysop kills it), the port is re-configured to 
      its original MODEM protocol.


      Using PPP on Dial-out links
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The interface and port should be configured for PROTOCOL=MODEM as 
      described in the section about PSTN modems.  The local IP address 
      follows the same rules as the wire-link case above, but may be 
      overridden temporarily by IPCP commands.

      The dialler script (see DUN section) must contain the command "MODE 
      PPP" plus any required PPP configuration commands.  Here is an extract 
      from a typical connection script:

          ; Link will use PPP
          mode ppp
          ;
          ; Configure my authentication username and password
          ppp pap user gb7pzt bsfjflavs
          ;
          ; Set inactivity timeout to 2 minutes
          ppp idle 120
          ;
          ; Enable ppp state logging




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  81

      Point to Point Protocol


          ppp log 1
          ;
          ; Set my (static) IP address for the duration of this call
          ppp ipcp local address 194.123.110.4
          ;
          ; Now dial the host
          send ATDT07979654234
          ;
          etc...

      The PPP configuration will persist until the call terminates, then the 
      port will revert back to MODEM protocol to await the next incoming or 
      outgoing call.


      PPP Configuration Commands
      ~~~~~~~~~~~~~~~~~~~~~~~~~~
      All PPP configuration commands start with "PPP", and are described in 
      the sysop command reference section.   When used from the command 
      line, or with a BOOTCMDS.SYS file, the first argument must be a port 
      number.  However, PPP commands used within PPPHOST and dialler scripts 
      *do not* include a port number, because Xrouter knows which port is 
      executing the script.

      e.g. at the command line: PPP 3 IDLE 300
           in a dialler script: PPP IDLE 300


      IP Routing with PPP
      ~~~~~~~~~~~~~~~~~~~
      When a PPP link opens, a route to the peer is automatically added to 
      Xrouter's IP routing table.  If the peer indicates that it knows the 
      addresses of a primary and secondary DNS, those are added to Xrouter's 
      DNS list.


      PPP Logging
      ~~~~~~~~~~~
      PPP system activity can be recorded in file PPPLOG.TXT for diagnostic 
      purposes.  The amount of detail is controlled by number specified in 
      the "PPP <port> LOG n" command as follows:

              0       No logging
              1       PPP start / stop / timeout events
              2       As 1, plus layer up / down events
              3       As 2, plus layer start / stop events
              4       as 3, plus option accept / reject events
              5       as 4, plus hexdump of configuration packets

      You are advised against using the higher levels other than on a 
      temporary basis because they can create very large logfiles.  On a 
      slow machine, the disk writes might take so long that configuration 
      timeouts could occur, with consequent retries and failure.

      If logging is in use, you should regularly remove the logfiles to 
      prevent them growing too large.








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  82

      Dynamic Host Configuration Protocol


      DHCP
      ====

      DHCP stands for Dynamic Host Configuration Protocol.  This is a 
      client-server based protocol which allows clients on a TCP/IP network 
      to obtain their configuration parameters from a server.  The protocol 
      supports the transfer of a wide range of configuration parameters, 
      such as the client's IP address, netmask, DNS and gateway addresses, 
      plus TCP/IP parameters such as MSS, but is most commonly used to 
      allocate dynamic IP addresses to clients.

      IP addresses are "leased" to clients for a period of time, after which 
      the client must renew the lease.  Servers generally attempt to re-
      assign the same IP address to a given client.


      DHCP in Xrouter
      ~~~~~~~~~~~~~~~
      Xrouter includes a DHCP client, and a DHCP server will be included in 
      future.  The full range of configuration options is not supported, 
      since in most Xrouter application scenarios they are not required.  
      The options currently supported are client's IP address and lease 
      time, DNS and gateway IP addresses.

      The DHCP client is used only on Ethernet interfaces.  Lease 
      negotiation and renewal are completely automatic, and the sysop need 
      not be concerned with the process.


      Do you need DHCP?
      ~~~~~~~~~~~~~~~~~
      If you wish to connect Xrouter to an ISP via a cable modem e.g. to use 
      it as an Internet Connection Sharing router, you will probably need 
      DHCP if your ISP uses dynamic IP addressing.  If your ISP assigns you 
      a static IP address you won't need DHCP.

      You will not need DHCP if your connection to the ISP is via dial-up 
      PPP, because dynamic IP addresses are assigned as part of the PPP log-
      in process.  You will not need DHCP for normal Ethernet or amateur 
      radio operations.


      Enabling DHCP
      ~~~~~~~~~~~~~
      In XROUTER.CFG, put "DHCP=1" in the appropriate port definition block.  
      There is no need to specify a port IPADDRESS because one will be 
      assigned by the DHCP server.  If however, a port IPADDRESS is 
      specified (or it is not specified but a global IP address is 
      specified), that address will be used for non-DHCP traffic until DHCP 
      succeeds in leasing a (possibly different) address.  If the global 
      IPADDRESS is 0.0.0.0 or not specified, it will be assigned by the 
      first client which obtains a lease.

      To disable DHCP, put "DHCP=0" in the PORT definition block, or simply 
      omit the keyword altogether.

      The DHCP command displays DHCP status information.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  83

      Dynamic DNS update

      DYNAMIC DNS UPDATE CLIENT
      =========================

      More and more people these days have dynamic IP addresses, i.e. IP
      addresses which are assigned by their Internet Service Provider and
      which may be different each time they log on.  Broadband users are
      permanently connected to the internet, but even their IP addresses
      may be changed at any time by the ISP, unless they pay extra for a
      static address.

      For the normal internet user this is not a problem, because no-one
      else needs to know their IP address. However, if you want other 
      people to be able to connect to your system, e.g. if you are 
      running a web server, they need to know your current IP address. 
      This is where the dynamic DNS providers come in.

      There are many organisations providing dynamic DNS services, one of
      whom is DYNDNS.ORG. It is easy, and free, to set up an account with
      dyndns.org, and after doing so you may choose one or more hostnames
      for your system. For example, the hostname for my router is
      "g8pzt.ath.cx". All you then have to do is keep dyndns.org informed
      of your current IP address, either manually or using an automatic
      update client. Whenever someone asks their system to connect to
      "g8pzt.ath.cx", they will be given my current IP address.

      From version 184a, Xrouter has an integral client for automatically
      maintaining dynamic DNS entries at dyndns.org, thus obviating the
      need to run an external client or perform manual updates.  If the
      client is enabled, and your IP address changes, it will update one
      or more hostname entries on the dyndns.org DNS server.  If you do not
      use dynamic dns, you need read no further.

      The client is enabled by including the directive DYNDNS=1 in relevant
      PORT configuration block in XROUTER.CFG, i.e. the port which is
      connected to the Internet. DYNDNS=0 disables the client, as does
      omitting the directive altogether. Note: you must only use this
      directive on ONE port, and you may crash Xrouter if you try to use it
      on more than one.

      The client requires a configuration file, DYNDNS.CFG, and it creates
      a data file DYNDNS.BIN. The configuration file contains plenty of
      comments, so it should be self-explanatory.

      If your Xrouter is *directly* connected to the Internet, i.e. via a
      PSTN modem or non-routing cable modem, the client simply monitors
      the port IP address (which is assigned by the ISP using IPCP or DHCP),
      and tells dyndns.org when it changes. This mode is selected by putting
      "NO" on the "Use external IP detection service" configuration line in
      DYNDNS.CFG.
      However, if your connection to the Internet is via a NAT router such
      as an ADSL modem/router or Windows ICS, the port IP address will be
      a "private" one which no-one else could access. In this case, the
      client can be configured to query an external IP address detection
      service at regular intervals, updating dyndns.org if a change is
      detected. This mode is selected by putting "YES" on the "Use external
      IP detection service" configuration line.
      Free accounts on dyndns.org are removed if they haven't been updated
      for 35 days. Thus, if your IP address hasn't changed for 30 days, the
      client automatically sends an update to keep the account refreshed.
      You may have more than one hostname associated with your IP address,
      but that's not a problem. In the "hostname(s) to be updated" line,
      simply list the hostname, separated by commas. Be careful not to
      include any spaces or mistakes in the line.


      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  84

      TCP/IP Access Control


      TCP/IP Access Control
      =====================

      This section is only of concern if your system is directly connected 
      to the Internet.

      Some of the users who access your system via the internet may be 
      genuine Radio Amateurs, who may legitimately downlink on radio 
      frequencies, while other users may not. And different countries may 
      have different rules governing the interconnection of radio and non-
      radio networks.

      Therefore some form of configurable access control is required, and 
      this is provided by the entries in ACCESS.SYS, which specifies the 
      login requirements appropriate to the caller's IP address.

      If ACCESS.SYS is not present, the default action is for logins to 
      require a valid callsign only.

      The entries in ACCESS.SYS allow various levels of access control, e.g.
      username only, valid amateur radio callsign only, username plus 
      password, and valid callsign plus password.

      If an entry in ACCESS.SYS specifies that a login password is 
      required, it should be located in file USERPASS.SYS.

      Failure to meet the access requirements results in immediate
      disconnection of the caller.

      Sysop access using the "@" command, RLOGIN (tcp port 513) and FTP are 
      all controlled by entries in PASSWORD.SYS.  The "@" command, which is 
      normally performed on publicly-visible radio links, uses the 
      password to send a grid of numbers, from which the caller must select 
      one line and send the matching characters from the password.  RLOGIN 
      must only be used on secure wired networks because the caller must 
      send the password itself.  FTP uses the password grid method, but can 
      be configured to use use plain password (secure wired links only) if 
      SYSOP=1 has been included in the appropriate PORT configuration.

      Access to the APRS server is normally controlled by the "Validation 
      number" which the user obtains from the author of his APRS client 
      program upon registration.  However, if the user has not registered 
      his client, he may be granted access to the server by including his 
      callsign and a password in USERPASS.SYS.

      For further information you are referred to the sections detailing 
      the ACCESS.SYS, PASSWORD.SYS and USERPASS.SYS files.

















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  85

      Routing Information Protocol


      ROUTING INFORMATION PROTOCOL
      ============================

      Routing Information Protocol (RIP) allows routers to learn about each 
      other's routing, similar to the way Netrom exchanges nodes broadcasts.

      There are various versions of RIP, and Xrouter implements only RIP98, 
      which was developed by G8BPQ specifically for radio-based routers.  If 
      there is a need for older versions of RIP, I may include them at a 
      later date.

      RIP98 works by sending its routing table to nominated peers at regular 
      intervals, and accepting routing information from peers.  The routes 
      learned by this means are added as temporary entries to the IP routing 
      table.  These entries have a finite lifetime, and if not updated for a 
      while they will drop out of the routing table.


      Configuring Xrouter to use RIP98
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The following configuration commands are available:

              RIP ACCEPT      Remove a peer from the refuse list.
              RIP ADD         Add a peer to the broadcast list. (*)
              RIP DROP        Remove a peer from the broadcast list.
              RIP LEARN       Allow / disallow route learning. (*)
              RIP REFUSE      Ignore broadcasts from a peer. (*)
              RIP STATUS      Show status of RIP.
              RIP TIMEOUT     Specify lifetime of learned routes. (*)

      Commands marked (*) may be used in BOOTCMDS.SYS or IPROUTE.SYS to 
      configure the system automatically.

      By default, RIP98 route learning is OFF, so you need to include at 
      least a "RIP LEARN ON" command, to enable your system to learn routes 
      from others.  Your neighbours will also need to add your IP address to 
      their RIP broadcast lists.

      If you wish to inform your neighbours of your existence and your 
      routing capabilities, you need some RIP ADD commands, one for each 
      neighbour to who you wish to send RIP updates.

      If you have LEARN enabled, and there is a neighbour who is sending 
      unwanted RIP updates to you, you may ignore them using RIP REFUSE.

      The RIP commands are explained in more detail in the sysop command 
      reference section later in this manual.

















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  86
    
  Network Address Translation


      NETWORK ADDRESS TRANSLATION
      ===========================

      Section 1 - About Network Address Translation
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      In order for a computer (sometimes called a "host") to communicate 
      with other computers using TCP/IP it must have an IP address.  This is 
      a 32 bit number unique to that machine, and it is composed of four 8 
      bit fields which hosts use to make routing decisions.

      Theoretically, there could be 2**32 unique addresses (just over 4000 
      million), but in practice the figure is a lot lower because some of 
      the addresses are not used.  This is due to the way addresses are 
      separated into classes and assigned to networks.

      For example, the "class A" address series 44.x.x.x is assigned to the 
      amateur radio network and contains 2**24 (16.7 million) addresses.  
      Within this series, the series 44.131.x.x is assigned to the UK, and 
      contains 2**16 (65536) addresses.

      Taking this further, the series 44.131.91.x is assigned to north 
      Worcestershire and contains 2*8 (256) addresses, yet there are only a 
      couple of IP stations in north Worcestershire.  So the remaining IP 
      addresses are "wasted".  A similar wastage occurs in every county in 
      the UK and every country in the world.

      Although there are only a couple of registered IP stations in the 
      44.131.91.x series, each station may be running more than one 
      computer.  For instance, at any one time, my station may be running 
      between 2 and 6 machines, linked via Ethernet.

      Some of these machines are nothing to do with amateur radio and 
      therefore are not entitled to a 44.x.x.x series IP address.  In 
      addition, registering IP addresses is a lengthy procedure which is 
      impractical for dealing with a home network in which computers are 
      rearranged frequently.

      In order to cater for these private and experimental networks, a 
      number of address ranges were set aside for "unregistered" use.  One 
      such series is 192.168.0.x which can cater for up to 256 hosts.  Any 
      one of these addresses may be used in millions of private networks at 
      once, thus alleviating the shortage of IP addresses.

      A problem arises if an "unregistered" host on a private network needs 
      to communicate with a host on the "registered" network.  Packets from 
      the unregistered (local) host can be routed normally to the registered 
      (global) host, but since the local host is unregistered, and the same 
      address is used many places at once, the network has no way of knowing 
      how to route the replies.

      This is where Network Address Translation (NAT) comes to the rescue.  
      NAT operates on each datagram, substituting one IP address with 
      another.

      For instance a local address such as 192.168.0.2 can be translated to 
      a globally recognised one, such as 44.131.91.2, allowing a host on a 
      LAN to access, and be visible to, the global network.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  87

      Network Address Translation


      Consider this example:

              Registered IP           Unregistered IP
              44.131.91.2             192.168.0.2
              44.131.91.3             192.168.0.16

      Packets arriving from the global network addressed to 44.131.91.2 are 
      re-addressed to 192.168.0.2 and routed to the appropriate machine on 
      the local network, while those addressed to 44.131.91.3 are 
      re-addressed to 192.168.0.16 and routed to that machine.

      In the reverse direction, packets originating from host 192.168.0.2 on 
      the LAN, destined for the global network, have their source address 
      changed to the globally recognised 44.131.91.2, and 192.168.0.16 is 
      translated to 44.131.91.3.

      This one to one mapping of one address to another is called STATIC 
      NAT, (also known as RFC1631 NAT) and is implemented in Xrouter.


      Port Address Translation
      ~~~~~~~~~~~~~~~~~~~~~~~~
      With Static NAT, if you have more than one local host which need to be 
      visible on the global network, you must own more than one registered 
      IP address.  A refinement of NAT, called Port Address Translation 
      (PAT) allows one registered IP address to be shared by many 
      unregistered hosts, by manipulating the "service port" numbers in TCP 
      and UDP packet headers.

      For example, consider the following mappings:

              Global address  Port            Local address   Port
              --------------  ----            -------------   ----
              44.131.91.2     777             192.168.0.1     1024
              44.131.91.2     778             192.168.0.2     1024
              44.131.91.2     779             192.168.0.5     1631


      TCP segments originating from port 1024 on local host 192.168.0.1, and 
      bound for the global network, are re-addressed to look like they 
      originated from port 777 on globally-recognised host 44.131.91.3.  
      Likewise, segments from port 1631 on local host 192.168.0.5 are made 
      to look like they originated from port 779 on global host 44.131.91.2.  
      The translations are reversed for incoming segments.

      PAT can be static or dynamic.  With static PAT, the sysop must set up 
      the translation table as in the example above.  Dynamic PAT builds the 
      table automatically, and the entries are removed when they're finished 
      with.  This makes the two systems behave very differently, as 
      discussed below.














      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  88

      Network Address Translation


      Static PAT
      ~~~~~~~~~~
      This form of PAT consistently translates a global address/port pair to 
      an equivalent local address/port pair and vice versa. Since the 
      mappings are permanent and predictable, the designated ports on the 
      local hosts are visible to the global network.  This is ideal for 
      making local servers (e.g. SMTP, HTTP, POP3) globally visible.

      Static PAT can be used to multiplex several hosts onto one IP address, 
      or it can simply be used to manipulate port numbers, for example to 
      create "virtual hosts" as shown below:

              Global address  Port            Local Address   Port
              44.131.91.2     80              192.168.0.1     8000
              44.131.91.3     80              192.168.0.1     8001
              44.131.91.4     80              192.168.0.1     8002

      The outside world sees 3 web servers (port 80 is the HTTP port), with 
      the IP addresses 44.131.91.2, 91.3 and 91.4, yet in reality there are 
      3 separate web server processes (ports 8001, 8002, 8003) running on 
      one host.

      There is a problem with static PAT however.  TCP/IP server processes 
      use predictable port numbers.  For instance, HTTP servers usually use 
      port 80 (although they can often be re-configured for a different 
      port), which means that incoming TCP segments addressed to port 80 
      will always go to the web server, and the server will reply using the 
      same port as the source.  TCP/IP *clients* on the other hand tend to 
      use unpredictable port numbers.  For example, the first Telnet client 
      session on a freshly booted Windows98 system will use port 1024, the 
      next session will use port 1025 and so on.  With static PAT, set up to 
      translate port 1024 to an outside world address/port pair, the first 
      Telnet session will succeed, but the second and subsequent ones will 
      fail.

      Therefore as a general rule, static PAT is useful for making local 
      SERVERS globally visible, but not for accessing the global network 
      using local CLIENTS.  It's a one way street.  This effect can be 
      exploited to prevent LAN users from accessing the global network.


      Dynamic PAT
      ~~~~~~~~~~~
      Dynamic PAT is commonly used to multiplex several hosts onto one IP 
      address a process called "Overloading", and it tends to act as a one 
      way street in the opposite direction to static PAT.

      Translation entries are created when a local host originates a 
      connection to the global network, and are removed when that connection 
      is closed.  Thus dynamic PAT cannot generally be used to make local 
      servers globally visible, but outgoing connections can be made without 
      hindrance.

      This creates a simple "firewall", preventing your local hosts from 
      attacks from the global network.

      Both static and overloaded PAT are implemented in Xrouter.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  89

      Network Address Translation


      Limitations of NAT / PAT
      ~~~~~~~~~~~~~~~~~~~~~~~~
      Unfortunately, NAT and PAT are not completely transparent to the user, 
      and there are certain situations which they cannot handle.

      IP, ICMP, TCP and UDP packet headers each contain a "checksum", and the 
      IP addresses and service port numbers are included in the calculation.  
      This means that any change to the address or port numbers requires all 
      the checksums to be recalculated and re-inserted.

      In most cases it is sufficient to manipulate the packet headers alone, 
      but some protocols convey IP address and TCP port numbers in the data 
      portion of the packet, and these present more of a problem.

      ICMP error reports return part of the faulty datagram, and that part 
      must be re-translated and the checksums recalculated if the process is 
      to remain completely invisible to the user.

      Certain FTP transactions convey an IP address and port number, 
      expressed in ASCII, in the data.  NAT must look for these and change 
      them.  Besides being a non-trivial operation, the problem with this is 
      that the translated addresses may occupy a different amount of space 
      when expressed in ASCII, so NAT must build a new packet, and must 
      adjust the TCP sequence numbers on every subsequent packet.

      There are other applications which similarly embed addressing 
      information in the data portion of the packet, and strictly speaking, 
      the TCP/IP layers must remain unaware of this information as it is of 
      a higher layer.  In this respect NAT breaks normal layering rules.

      PAT achieves multiplexing by translating service port numbers, but 
      some protocols do not use service port numbers at all, so these can 
      not pass through PAT.  For example, ICMP, IPIP and AXIP can only pass 
      through static NAT, whereas AXUDP and IPUDP can pass through PAT.

      The following protocols and traffic will pass through NAT:

           Protocol  Supported Traffic / Applications
           -------------------------------------------------
           RIP ?
           ICMP       Ping, Traceroute etc.
           AXIP       Ax25 tunnelling
           IPIP       IP tunnelling.
           UDP        AXUDP, IPUDP, DNS, TFTP
           TCP        Telnet, HTTP, SMTP, NNTP, POP, Finger, Rlogin
                      Plus any other traffic which does not use
                      TCP/IP addresses in the application data.


      Only the following protocols and traffic will pass through PAT:

           Protocol  Supported Traffic / Applications
           -------------------------------------------------
           UDP       AXUDP, IPUDP, DNS, TFTP
           TCP       Telnet, HTTP, SMTP, NNTP, POP, Finger, Rlogin
                     Plus any other traffic which does not use
                     TCP/IP addresses in the application data.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  90

      Network Address Translation


      Section 2 - Configuring NAT / PAT on Xrouter
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      The "NAT" commands are used for configuring both NAT and PAT on the 
      fly. They can also be embedded in the IPROUTE.SYS or BOOTCMDS.SYS 
      files to configure the system at startup.

      The following commands are available:

           NAT ADD     Adds entries to the translation table.
           NAT DROP    Deletes entries from the translation table.
           NAT LIST    Displays the translation table.

      Syntax is as follows:

      NAT ADD STATIC <localaddr>[:port] <globaladdr>[:port] [tcp | udp]
      NAT ADD OVERLOAD <localaddr> <globaladdr> <subnet_mask>

      The first form adds static NAT and PAT entries, and the second form is 
      used only for adding overloaded dynamic PAT entries.

      In each case <localaddr> represents the "private" or "unregistered" IP 
      address of a host on the stub network, and <globaladdr> represents a 
      globally recognised or "registered" address.

      In the STATIC case, if port numbers are specified, TCP and UDP traffic 
      matching the specified IP addresses will be translated ONLY if it also 
      matches the specified ports.  If ports are not specified, all traffic 
      is translated.  If the optional protocol is specified, only traffic of 
      that protocol will be translated by that entry.

      The OVERLOAD case does not accept port numbers, and it requires a 
      subnet mask to be specified.  The mask is used in combination with the 
      local address to form a range of addresses which will be accepted for 
      translation.  For example, if the local address is 192.168.0.0 and the 
      netmask is 255.255.255.240, addresses 192.168.0.0 to 192.168.0.15 
      inclusive will be translated.


      NAT DROP <local>[:port] [tcp | udp]

      Simple entries, i.e. those in which the protocol shows "ALL" and the 
      port numbers are zero, can be removed by the form:
           "NAT DROP <localaddr>" e.g. "NAT DROP 192.168.0.2".

      If the translation table entry includes port numbers, the form:
           "NAT DROP <local_address>[:port]" is required, e.g.
           "NAT DROP 192.168.0.2:23".

      If the translation entry is protocol-specific, the protocol must be 
      specified when removing the entry, e.g.:
           "NAT DROP 192.168.0.2 TCP".


      NAT LIST

      This command currently requires no arguments.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  91

      Network Address Translation


      Order of Entries in NAT table
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The order of entries within the translation table is important, 
      because Xrouter will translate upon the first matching entry.  This 
      gives you maximum flexibility to cater for your particular needs.  As 
      a general rule, port-specific and protocol-specific entries should be 
      declared before non-specific "catch-all" entries.  Overload entries 
      can be declared anywhere, providing they don't inadvertently "hide" a 
      static translation for the same address.

      Consider this example:

      NAT ADD STATIC    192.168.0.2:87  44.131.91.2:23  TCP
      NAT ADD STATIC    192.168.0.2     44.131.91.2
      NAT ADD OVERLOAD  192.168.0.0     44.131.91.3     255.255.255.240

      In the above example, TCP frames originating from port 87 on local 
      host 192.168.0.2 will be translated by the first entry, to look like 
      they originated from port 23 on global host 44.131.91.2.

      UDP and all other TCP frames from that host will be translated by the 
      second entry, which leaves the port numbers alone.  This entry also 
      translates "portless" protocols such as AXIP, ICMP, IPIP etc.

      The third entry translates any TCP or UDP frame originating from local 
      hosts 192.168.0.0 to 192.168.0.15, excluding 192.168.0.2, to look as 
      if it originated at 44.131.91.3.

      If the second entry had been placed before the first, it would never 
      have been executed, because the non-specific static entry would have 
      intercepted *every" frame from 192.168.0.2.  If the overload entry had 
      been placed first, it would have intercepted every TCP and UDP frame 
      from local hosts 0 to 15, so the port specific static would never have 
      been executed.


      Routing Table Requirements
      ~~~~~~~~~~~~~~~~~~~~~~~~~~
      In addition to the translation table entries, you must ensure that IP 
      routing to the target system is correctly configured.

      Network Address Translation is applied *before* the packet is routed.  
      This means that for "outbound" packets, i.e. those originating on the 
      "private" subnet, routing to the "public" net should be defined.  For 
      "inbound" packets, i.e. those originating on the public net, addressed 
      to one of the global NAT addresses, the should be a routing entry 
      which will route the translated address to the *private* subnet.   
      This is best illustrated with an example:

      In IPROUTE.SYS....

      ROUTE ADD 44.0.0.0/8         44.131.90.6     11      d
      ROUTE ADD 192.168.0.1/32     *               14      d

      NAT ADD STATIC 192.168.0.1   44.131.91.3









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  92

      Network Address Translation


      The first entry routes all outbound 44-net packets to peer 44.131.90.6 
      on port 11.

      The second entry routes packets addressed to 192.168.0.1 onto port 14
      which is the Ethernet LAN.

      The third entry translates destination address 44.131.91.3 on incoming 
      packets into 192.168.0.1 before sending the packet on the LAN as 
      dictated by the second entry.


      Internet Connection Sharing
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      If one of Xrouter's ports is connected to the Internet (e.g. by dialup 
      or cable modem), you may use dynamic PAT to allow other computers on a 
      LAN to share the connection.  Assuming the computers on your LAN use 
      addresses in the range 192.168.0.1 to 192.168.0.255 (this is the range 
      normally used by Windows), the NAT entry should look like this:

      NAT ADD OVERLOAD 192.168.0.0   0.0.0.0   255.255.255.0

      Note the special 0.0.0.0 entry, which tells Xrouter to translate the 
      source address on outgoing frames to the address of the port on which 
      they are sent.  This is required if your internet connection uses a 
      dynamic IP address, but if your address is static you may insert it in 
      place of the 0.0.0.0.

      If you don't have a DNS server on your LAN, you will need to set up 
      the LAN computers to use Xrouter as their DNS.  You will also need to 
      tell Xrouter the address of at least one external DNS, either by 
      including a "DNS=<ipaddr>" statement in xrouter.cfg, or by using a 
      "DNS ADD <ipaddr>" command.  Xrouter will then act as proxy DNS for 
      the computers on the LAN.

      Summary
      ~~~~~~~
      a)      Use NAT ADD... in IPROUTE.SYS to define translations.
      b)      Add IP routing for the *global* NAT addresses.
      c)      Use NAT... commands to display / adjust NAT on the fly.
      d)      Report problems to me.


      References:
      ~~~~~~~~~~~
      RFC791  - Internet Protocol
      RFC792  - Internet Control Message protocol
      RFC793  - Transmission Control Protocol
      RFC1631 - The IP Network Address Translator
      RFC1700 - Assigned Numbers
      RFC1918 - Address Allocation for Private Intranets














      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  93

      TCP/IP Stealth Mode


      TCP/IP STEALTH MODE
      ===================

      The experimental command IP QUIET [n] controls whether or not ICMP 
      error messages are generated.  The command may be used at the command 
      prompt, in BOOTCMDS.SYS, or (without the "IP") in IROUTE.SYS.  I am 
      not convinced it is a good idea, and I may remove the command or 
      modify its action as experience is gained.

      Hackers use automated software to "probe" the network, looking for 
      unprotected TCP or UDP services and "back doors" such as NetBios.  If 
      found, they will usually exploit known bugs, such as buffer overflow 
      problems, to crash the machine or gain access to sensitive areas.

      Xrouter has only a handful of standard TCP / UDP services, none of 
      which pose much of a security risk if configured correctly, so the 
      probes are more of a bandwidth-wasting nuisance than a real threat.

      Issuing the command "IP QUIET n", where n is a number between 1 and 
      255 puts Xrouter into "stealth mode", the level of which depends on 
      the number n, which is the sum of the following values:

              1       Suppress ICMP echo replies.
              2       Suppress ICMP "Unknown Protocol" messages
              4       Suppress TCP resets
              8       Suppress all other ICMP error messages.

      A value of 0 disables stealth mode and lets TCP/IP operate normally.

      Suppressing ICMP messages, may reduce the bandwidth wasted and slow up 
      the rate of probing.  But it won't confer any extra security, and will 
      certainly have a detrimental effect on normal TCP/IP operations.

      ICMP error messages are an integral part of TCP/IP, and are used to 
      inform a sender of network problems such as un-routable frames, 
      unsupported protocols, processing errors etc.  They are also used for 
      diagnostic purposes, by applications such as "Ping" and "TraceRoute".

      Using stealth mode therefore prevents the use of diagnostics and the 
      detection of network problems, and may under some conditions make 
      everything run more slowly, or fail completely.

      If you suppress ICMP echo replies, Xrouter will not respond to 
      "pings".  This may be temporarily useful if you are being attacked 
      with echo requests, but is anti-social because you would also be 
      denying others the use of a valuable network diagnostic tool. It will 
      not *prevent* a pingstorm attack, but it will halve the traffic by 
      suppressing the replies.

      If you suppress ICMP "unknown protocol" messages, it will reduce the 
      bandwidth wasted by protocol scans, i.e. those in which the protocol 
      number is incremented with each probe.

      "Suppressing TCP resets" causes the TCP layer to ignore connect 
      requests aimed at non-existent TCP services, instead of refusing them.
      This may be useful in slowing up the action of "port scanners".

      I do not recommend the "Suppress all ICMP error messages" option.
      It is provided for experimentation only.





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  94

      Netrom Interlinks


      NETROM INTERLINKS
      =================

      Unlike BPQ, which closes AX25 level 2 links with neighbouring nodes 
      after a period of inactivity, Xrouter attempts to maintain a 
      permanently open link, and you may find this disconcerting.

      There are a number of reasons for this strategy.  Most importantly, it 
      is able to detect a common and disruptive problem, namely the "one way 
      link".  These occur when a transmitter, receiver, antenna, or TNC 
      malfunctions, leaving one peer hearing the other but not vice versa.

      When a one-way link occurs, one peer can hear the other's nodes 
      broadcasts, but no connected-mode traffic can be transferred.  Thus 
      one peer thinks it has a route via its peer, but that route is 
      unusable, and all nodes advertised by the peer are unreachable.

      Xrouter solves this problem by detecting when the link cannot accept 
      traffic, and marking all nodes advertised by the peer as unusable, so 
      that alternative routes are used.

      Another good reason for keeping links open is to enable continuous 
      measurement of route quality and round trip time, used in making 
      routing decisions.

      A further reason is to remove the L2 link setup time when L3 frames 
      arrive infrequently.

      The "R" commands will show a ">" in the left-most column if the 
      interlink is fully open, a "~" if it is opening or closing, or an 
      x if the link can't be opened.  This provides a handy way of 
      detecting link problems which might otherwise go un-noticed.

      If port quality and nodesinterval are both non-zero, as soon as 
      Xrouter hears a nodes broadcast from a previously unknown neighbour, 
      it will attempt to connect to it.  If the path is marginal, the 
      attempts may fail, and you can prevent it from re-trying by locking in 
      the neighbour with a zero quality.

      If MAXTT for the route is set to 65535 then the neighbour interlinks
      will not be held open and XROUTER will revert to operating like
      an old BPQ/X1J system.






















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  95

      Time Domain Routing


      TIME DOMAIN ROUTING
      ===================

      Conventional NetRom makes routing decisions based on a fairly 
      arbitrary metric, i.e. the "route quality", which is assigned by 
      sysops, and disseminated in nodes broadcasts.  There is no standard 
      for assigning quality, and not only will each sysop have a different 
      notion of the quality of his links relative to others, but he will 
      probably wrongly assign the qualities of those links relative to each 
      other.  This leads to inconsistency and distorted routing.

      Xrouter includes two systems which attempt to alleviate this problem, 
      namely automatic Route Quality Measurement" (Autoqual) and "Time 
      Domain Routing" (TDR).  Both systems rely on a slightly different 
      understanding of the "goodness" of a link.

      In the better-managed parts of the NetRom network, route qualities 
      tend to be assigned according to the baud rate of the link, with 
      adjustments for retry rates, duplex / simplex and shared channels (in 
      the worst-managed parts, route qualities are simply assigned to 192 
      regardless of how good or bad the link is).  The quality is fixed at a 
      compromise value.

      But the actual "goodness" of a link may continually change with 
      atmospheric conditions, data throughput, other channel activity, QRM 
      etc.  At certain times of day for example, it may be better to use an 
      alternative link.

      A more accurate notion of "goodness" is simply the "Round Trip 
      Time" (RTT) for the link, i.e. the time taken to send a packet and 
      get a reply.  After all, this is what *really* matters to users.  A 
      link which responds quickly (i.e. with a low RTT) is perceived by 
      users to be better than a link which responds slowly.  The RTT will 
      track changes in retry rate, channel loading etc.

      The RTT can be easily and consistently measured by software on a 
      continuous basis, thus the "quality" of the link is accurately known 
      at all times, and all routers of the same type will give comparable 
      values independently of the sysop's notions of quality.

      Xrouter continually measures RTT and uses it to calculate route 
      quality.  This quality is displayed by the "R Q" command, and can 
      either be used as a guide to allow the sysop to fix the RQ at a 
      sensible value, or Xrouter can use it dynamically, by setting the 
      route to use Autoqual.  (Autoqual is engaged by setting an RQ between 
      256 and 511).  The RTT to quality conversion is tailored to the 
      British notion of quality, which gives somewhat lower but more 
      meaningful qualities.

      Autoqual is merely a simple tool to aid sysops, and the route 
      qualities are still under sysop control, and thus open to distortion.  
      However, by simply broadcasting RTT values instead of qualities, the 
      influence of the sysop is removed, and a network based on indisputable 
      *times* rather than arbitrary *quality* can be created.  This is a 
      network which has its routing metric in the time domain, hence the 
      name "Time Domain Routing".  It may to some extent overlap the 
      quality-domain network, but the boundaries may be different, and the 
      two schemes are not compatible.






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  96

      Time Domain Routing


      Xrouter implements both time-domain and quality-domain routing 
      schemes, and will consider information from both domains when making 
      routing decisions.  The same node table is used for both schemes, 
      since only the metric is different.  In some cases a node may have 
      both quality and time metrics.

      As sysop, you have several tools at your disposal for determining the 
      size and balance of the two domains.  For the quality domain you have, 
      QUALITY which defines the "goodness" of the links to your neighbours 
      and the "de-rating" of the qualities which they send to you, MINQUAL, 
      which determines which nodes get into the table and which are 
      excluded, MINTXQUAL, which determines how much information you send to 
      your neighbour nodes, and MAXNODES which determines the maximum number 
      of nodes visible to you.

      For the time domain, you have MAXTT, which defines the furthest node 
      in "Trip Time" (i.e. RTT/2) terms, MAXHOPS which defines the furthest 
      node as a function of the number of intervening nodes, and MAXNODES as 
      above.

      You may adjust these parameters to favour one domain over the other, 
      to exclude one domain altogether, or to strike a balance between the 
      number of nodes which exist solely in one domain or the other.  For 
      example, setting MAXTT or MAXHOPS to 0 will exclude all time-domain 
      information, and Xrouter will behave as a pure NetRom router.  Or you 
      may set MINQUAL to 255, excluding all quality-domain information (e.g. 
      if there is a nearby node distorting the netrom qualities), providing 
      of course you have neighbours which are cabable of time-domain 
      routing.  Or you may wish to limit the visibility of a subnet from one 
      port (e.g. to a foreign network) by setting a low MAXHOPS or MAXTT on 
      that port only.  This gives you control which was not possible by 
      quality alone.

      Xrouter currently (but see compatibility issues) uses the INP3 
      protocol to disseminate time-domain routing information.  Unlike 
      NetRom, which uses unconnected-mode "broadcasts" to all neighbours 
      simultaneously, INP3 sends data to each neighbour individually, using 
      connected-mode.  Whilst it is usual to make NetRom nodes broadcasts at 
      1 hour intervals, INP3 updates are sent every 10 minutes, with 
      additional updates whenever changes occur.

      The time-domain network thus responds much more rapidly to changes 
      than NetRom, but if the network is unreliable (i.e. frequent outages 
      and variable RTT's), a lot of updates are generated.  Although INP3 
      updates are more compact than NetRom nodes broadcasts, some sysops may 
      feel that the amount of routing information is too much for a poor 
      quality RF link.  If so, you may disable INP3 completely by setting 
      the route MAXTT to 0, or you can agree a low MAXTT with your neighbour 
      node, which will reduce the volume of data.

      You may notice that nodes which are learned solely via INP3 are all 
      stored with a Netrom quality of 1, which is probably below MINQUAL.  
      This is deliberate, because these nodes have no presence in the 
      quality domain.  They should have a quality of 0, and I will probably 
      correct that in a later version.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  97

      Time Domain Routing


      Compatibility issues:

      Although this is a router manual, not a treatise on advanced 
      networking, I must stress that time-domain and quality-domain routing 
      information are incompatible, and information from one domain must 
      *never* be "translated" to the other.  Xrouter measures, uses and 
      disseminates both time and quality, but always keeps them separate.

      Unfortunately, *some* software (which I shall call "Brand-X") does 
      translate information between the domains, and you should be aware 
      that this may cause you problems if they are within the horizon of 
      either domain.

      For example, in the diagram below, imagine that Xrouter (Xr) measures 
      the trip time (TT) to one of its neighbour nodes (A) as 1.5 seconds, 
      and the Netrom quality of that route to 180.

                     180
                   A ---- Xr ---- B
                           \     /
                             \ /
                              C ---- D


      Xrouter then broadcast both pieces of information to neighbour node 
      (B) which is using "Brand-X" software.  That software will 
      ignore the 180 and will instead manufacture a quality of 253 from the 
      trip time.  By itself this isn't a problem, until the "Brand-X" 
      software broadcasts it to node (C) which is Netrom-only.  Now the 
      Netrom node thinks it has a higher quality to (A) via (B) than via 
      (Xr).  What's worse, it will tell (Xr) that it knows a better route to 
      (A), and the network will decend into chaos.

      A fully interconnected network is very robust, yet the "Brand-X" 
      sysops seem remarkably reluctant to implement links which result in 
      network "triangles".  I wonder why? :-)

      Another problem occurs when the "Brand-X" software translates a Netrom 
      quality, which is a potentially unreliable piece of information, into 
      a trip time and hop count.  A node which exists only in the 
      untrustworthy quality domain, and may have been beyond our horizon in 
      that domain, now exists in the more trusted time domain where it can 
      bypass the Netrom de-rating process.  The information could 
      subsequently pass back into the Netrom network with a higher "quality" 
      than it would have when received via a more direct pure netrom route.

      Early versions of Xrouter used a proprietary protocol to exchange RTT, 
      hops, IP routing, position and other information between themselves.  
      The INP3 protocol used by other node software was remarkably similar, 
      so I later decided to adapt my code for INP3 compatibility, believing 
      that it would be a good idea to interconnect my time domain scheme 
      with theirs.  I now realise this was a big mistake, and I firmly 
      believe that, unless the "Brand-X" software authors correct the 
      errors, Xrouter and the Netrom network should not be connected to any 
      other network which includes "Brand-X" nodes.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  98

      Netrom Quality Manipulation


      NETROM QUALITY MANIPULATION
      ===========================

      This section describes a feature which allows you to reduce the 
      quality of "foreign" nodes on your system, or to exclude certain nodes 
      or groups of nodes altogether.  I do not necessarily condone its use.

      With ever-increasing connectivity via the Internet, the NetRom network 
      is crossing traditional boundaries, and this is causing problems.  
      Because Internet qualities are much higher than radio qualities, there 
      are far more nodes in the tables.
        
      There is a limit to the size of tables, and more importantly there is 
      a limit to the number of nodes that can be broadcast on a low 
      bandwidth RF channel.  In addition, with too many nodes in the table, 
      the "N" commands become useless because the response becomes too large 
      for the user to download on a limited bandwidth channel.  Even if 
      there is sufficient bandwidth, the response may occupy several pages 
      and the user may not be able to review anything which has scrolled off 
      the screen.  Experience has shown that 150 nodes is roughly the 
      maximum comfortable table size.

      But how do you decide *which* 150 nodes to include?  How do you 
      achieve the balance between slow, unreliable, radio-routed nodes and 
      fast, reliable, Internet-routed ones?  Some people advocate setting 
      low route qualities for the Internet links, but unless everyone agrees 
      on the qualities, this can lead to traffic being routed via slow, 
      unreliable links when faster and more direct routes exist!  And do you 
      want your table full of high quality foreign nodes, to the exclusion 
      of your local nodes?  Can your users find the nodes they want?

      Quality de-rating by callsign can help with this management issue.  It 
      allows you to de-rate the Netrom quality of a node or group of nodes 
      based on the netrom callsign, instead of the route on which they were 
      received.  Thus, no matter what relative route qualities you use, you 
      can change the relative qualities to favour your local nodes, or those 
      which share the same language.  These are more relevant.

      This feature uses the global QUALADJUST keyword as follows:

           QUALADJUST <call | "default"> <0-255>

      e.g.    QUALADJUST default 120
              QUALADJUST G* 255
              QUALADJUST ZL* 200

      The "default" argument sets the default value which will be used to 
      de-rate all nodes not matched by any other qualadjust statement.  The 
      normal netrom de-rate algorithm is used, so 255 gives no de-rate and 0 
      gives full de-rate (i.e. lock out a call or group of calls). If there 
      are no qualadjust statements the default is 255.

      Qualadjust is applied to neighbour nodes and all nodes learned from 
      netrom broadcasts.  It is not applied to nodes learned by INP3 because 
      they have no quality to de-rate, and is not applied to nodes entered 
      by a NODE ADD command or an entry in the XRNODES file.
       







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  99

      Web Server

      THE XROUTER WEB SERVER
      ======================

      Added very rudimentary HTTP server / user interface.  This will serve
      files off disk, and also provides a means to run certain node commands
      and view the output as web pages.  It includes tunnelling and proxy
      tunnelling support, with egress control.  The HTTP server is located
      on port 80.

      When servicing a request which does not include a filename in the URL,
      (e.g. "http://g8pzt.ath.cx/") the web server looks in the HTTP root
      directory for a file called INDEX.HTM.  If that file is not present, it
      will look for DEFAULT.HTM.  I have supplied a simple example INDEX.HTM,
      for your guidance.  It is by no means a perfect web page, just 
      something thrown together to test a concept. You may alter it to suit 
      your own preferences if you have some HTML skill.  You may need to 
      alter the address in the "Connect" link to suit your own IP address/
      hostname.

      INDEX.HTM is meant as a default entry point for your Xrouter-hosted web
      site.  Although Xrouter's primary purpose is a router not a server,
      and the primary purpose of Xrouter's HTTP server is to provide a web
      interface to the system, you may choose to create a complex web site,
      of which the command interface is but a small part.  You may prefer to
      use index.htm as a splash or menu page for your site, putting the
      command interface on one or more linked sub-pages.  Or you may choose
      the opposite approach, putting all the commands on the main page along
      with links to other sites.  I leave the creativity to you...

      The web server root directory is specified using the HTTPROOT directive
      in Xrouter.cfg, e.g. "HTTPROOT=C:\WEB".  If you omit this directive,
      the default will be a directory called "HTTP" within the xrouter
      directory.  For security reasons it is important that you don't use the
      Xrouter directory as the HTTP root!

      A new HTTP.ACL file holds the egress control rules for the proxy/tunnel,
      and should preferably be located on a ramdisk configured as drive R: 
      for best results. If a ramdisk is not used, locate the file in the same
      directory as Xrouter.  If the file not present, all egress is blocked.

      Added "template" file for HTTP command interface.
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      In my usual haste to release v180 I forgot to include this feature,
      but I didn't realise my mistake because the inbuilt template used
      the same colours as my main menu page!

      Once again, I am giving you an unfinished feature to play with,
      because I've had to rush v181 to you :-(  If you wish to override the
      inbuilt html template for the URLs which begin with "/exec", edit the
      enclosed file EXEC.HTM and put it either in the same directory as
      Xrouter, or preferably on a Ramdisk configured as drive "R:". When
      the server encounters a URL beginning with "/exec?cmd=", it will
      serve the EXEC.HTM file, replacing the <TEXT> tag with the result of
      the executed command.

      The main purpose of this package is to "officially" release the Java
      applet which can be used to access Xrouter from a web page.  

      For instance, with v0.12 you can change the applet colours and font,
      the number of rows and columns displayed, and the connection mode 
      (normal or http tunneled).




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  100

      Web Server

      I have included the new XWEB.CLA file, plus 3 rudimentary .HTM pages
      for you to examine or experiment with.  CONNECT.HTM is the menu page 
      for 3 types of connection, and would typically be accessed via a 
      "connect" link on the main page.  You may however wish to put the 3 
      connect options directly on the main page, it's up to you.  
      CONN23.HTM uses the Java applet to perform a normal telnet connect 
      to port 23.  The port number is configurable (see below), so you 
      could clone the page for use with your chat server.  CONN80.HTM 
      uses the Java applet to perform a "tunnelled" connection, which 
      can be used via corporate firewalls.

      The parameters which can be used with the applet are as follows:

       Param name     Default      Description
       ----------------------------------------------------------------
       rows           22           No. of rows in text window
       cols           80           No. of columns in text window
       bgcolor        Dark grey    Applet background colour.
       borderColor	  Light grey   Applet framework colour.
       textBackground Black        Background for text window and cmd line.
       textColor      White        Colour of sent / rcvd text.
       font           Times        Font style used for sent / rcvd text
       port           9999         TCP port number for connections.
       mode           Normal       Connection mode (normal / proxy).

      The only mandatory parameter (unless you happen to use port 9999 for
      telnet :-) is "port".  This should normall be 23 for a normal telnet
      connect or 80 for an http-tunnelled connect, but you may use other
      values if you have mapped your TCP ports.

      Colours should be specified as a 24 bit hexadecimal number in 'C' 
      style, e.g. 0xEECCFF, where the first 2 digits represent the RED 
      value, the second two digits represent the GREEN value and the 
      last two digits represent the BLUE value.  Some browsers can 
      only display 216 discrete colours, so you should prefarably use 
      the "browser-safe" values, which are all formed from combinations 
      of 00, 33, 66, 99, CC and FF.

      The default font is quite small, and the characters are not of a
      constant width, which means tables sent by Xrouter will not line up
      correctly.  You may use the "font" parameter to override the default.
      The recommended font is "Courier", which is slightly larger and uses
      constant width.  Note: if the chosen font is not found on the client's
      computer, the default will be used, so stick to the common ones.

      You may need to reduce the number of rows or columns displayed by the
      applet if you find it won't fit on a 640*480 screen (I haven't tested
      it on 640*480 but the applet is smaller than those limits.  It fits
      nicely on 800*600, but you may wish to optimise it for another screen
      size, or even offer users the choice.

      If you change the font, rows or cols, you may need to tweak the WIDTH
      and HEIGHT attributes in the APPLET tag to prevent parts of the applet
      from being obscured.

      Don't forget, although the Java applet is called XWEB.CLA (because DOS
      can't display long file extensions), it must be called "xweb.class" in
      any link, otherwise the browser will not recognise it as an applet.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  101

      Configuration Files: ACCESS.SYS


                             SECTION 4 - FILE FORMATS
                             ========================

      All configuration files are commented to aid setting up, but I will 
      document them in more detail here too, just in case you damage a file 
      or wish to study a paper copy in the garden!  They are presented in 
      alphabetical order....


      ACCESS.SYS
      ~~~~~~~~~~
      This optional file specifies TCP/IP access requirements according to 
      the caller's IP address.  If not present, the default action is for 
      logins to require a valid callsign only.

      The entries in ACCESS.SYS are of the form:

              <subnet>[/bits] <access_flags>

              e.g. "44.0.0.0/8 1"

      The <subnet> and [bits] parameters defines a range of IP addresses 
      from whom Telnet connects will be accepted, and <access_flags> defines 
      the login requirements for that subnet.

      The [bits] parameter specifies how many bits, from left to right, of 
      the source address should be matched against the corresponding 
      <subnet> address.  For example, 44.131.0.0/16 will test the incoming 
      IP address against the left-most 16 bits of 44.131.0.0, i.e. it will 
      match any source address beginning with 44.131. And 0.0.0.0/0 will 
      match any IP address, which is useful for specifying the default. The 
      chosen match will be the one with the highest [bits] value. If [bits] 
      is not specified, it defaults to 32, i.e. an exact match is required.

      The <access_flags> parameter is the sum of these flag values.

              1       Valid callsigns only
              2       Password required
              4       Allow guest
      A value of 0 means any "callsign" longer than 1 character will be 
      accepted, and no password is required.  In this context, "callsign" 
      could be a user name.  This is a zero security option, for use only 
      for the sysop's convenience on physically secure subnets.

      A value of 1 requires the user to enter a valid amateur radio 
      callsign, i.e. a string containing alphanumeric characters in the 
      correct format, but no password is required.  This is a low security 
      configuration with minimal inconvenience, and is suitable for use 
      within amateur radio subnets which are not connected to the Internet. 
      This configuration is recommended for callers who have 44.x.x.x source 
      address, as they must have entered the network via radio, or via a 
      password-protected gateway.

      A value of 2 will cause Xrouter to accept any "username" longer than 
      one character, providing a valid password is given.  This is a medium 
      security configuration, suitable for use on private wire subnets where 
      amateur radio callsigns are not used.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  102


      Configuration Files: ACCESS.SYS


      A value of 3 requires both a valid amateur radio callsign and a 
      matching password to be supplied. This configuration is recommended 
      for use at the Internet-to-Amprnet interface, i.e. for all source IP 
      addresses other than 44.x.x.x
      
      Added another flag to ACCESS.SYS: 4 = allow guest access.  This flag
      works in conjunction with the "password_required" flag (2) in the
      following way:
      If neither flag is set (i.e. access_flags is decimal 0 or 1), no
      password is required and no password challenge is made.  Users have
      unrestricted access.
      If "password required" is set, but "allow guest" is not set (i.e.
      decimal 2 or 3), a password is required and no guest option is allowed.
      No password = no access. Valid password = full user access.

      If "allow guest" is set, but "password required" is not set (i.e.
      decimal 4 or 5), a password is not required, and is not requested.
      All users have guest access, i.e. they cannot downlink.

      if both flags are set (i.e. decimal 6 or 7), a password challenge is
      made, but the option to use "guest" is available.  If the user gives
      a valid password she gets full access, but if she answers with "guest"
      she only gets guest access.

      Guests are prevented from using the SEND, CHAT and CONNECT commands,
      and from sending APRS messages using the APRS messaging shell.  For
      TELNET they are restricted by the rules in new file TELGUEST.ACL, which
      uses the same format as TELPROXY.ACL.  If the former file is not
      present, guests cannot use the TELNET command at all.

      If passwords are required for user access, they should be located in 
      file USERPASS.SYS (see below).  Do not confuse this with PASSWORD.SYS, 
      which is used for AX25 logins, Rlogin and FTP.  USERPASS.SYS is used 
      for "normal" telnet (port 23) logins.
      Each entry in ACCESS.SYS must begin on a new line.
      Note:   This is a prototype access control method, and may be subject
              to change if the need arises.  I will probably add other flags
              to control access to other services such as the APRS server.

      Example ACCESS.SYS file:
      ~~~~~~~~~~~~~~~~~~~~~~~~
      # File:         ACCESS.SYS
      # Purpose:      Xrouter access control for incoming Telnet port 23
      #               connections.
      #               Defines access control flags for given source IP address.
      #
      # Fields: <subnet>[/len] <flags>
      #
      # Flags - add together (default=1):
      #
      #       1       Valid callsign required.
      #       2       Password required.
      #       4       Allow guest access
      #
      # Subnet/bits           Flags
      # =============================
        0.0.0.0/0             3
        44.0.0.0/8            1
        192.168.0.0/16        0
      #



      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  103

      Configuration Files: BOOTCMDS.SYS


      BOOTCMDS.SYS
      ~~~~~~~~~~~~
      This optional file is read by Xrouter at boot time, after XROUTER.CFG 
      and IPROUTE.SYS.  It may contain certain configuration commands which 
      would otherwise have to be typed in at the command line.

      For example, if a PPP port required any special configuration to 
      override the defaults, the appropriate PPP commands could be included.

      Commands currently accepted in BOOTCMDS.SYS are:

          ARP        <add | publish | learn | timeout | wait | maxq | cmd>
          BELL       <times>
          DUN        <add | log>
          IP         <quiet | route | ttl>
          NAT        <add>
          NODE       <add>
          PPP        <port> <idle | ipcp | lcp | log | pap>
          RIP        <add | learn |refuse | timeout>
          ROUTE      <add>

      It ignores all other commands, and those which normally produce a 
      display, such as ARP LIST.

      Note that IP, ARP, RIP, and DUN commands can also be used in 
      IPROUTE.SYS.






































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  104

      Configuration Files: CRONTAB.SYS


      CRONTAB.SYS
      ~~~~~~~~~~~
      This optional file allows commands to be executed at certain times of 
      the day, week, month or year.

      A few of the possible uses would be:

      - Additional AX25 beacons.
      - Beaconning APRS objects, status, bulletins and announcememnts.
      - Adjusting Netrom / IP routing to account for part-time neighbours.
      - Enabling / disabling transmitters.
      - Controlling peripherals via the CTRL port.
      - Adjusting parameters to cope with diurnal propogation changes.
      - Enabling / disabling IGATE at certain times of day / week.
      - Automatic reboots / restarts / exits for batch file processing etc.

      In the current version, all responses from the command processor are 
      discarded.

      An example of the file layout follows:

      # CRONTAB.SYS - Xrouter v186 event control file.
      #
      # <command> will be executed if <min> <hour> and <month> match current time,
      # and either the date (day of month) or day (of week) match.
      #
      # Fields must be separated by one or more spaces or tabs.
      #
      # Dates / times may be specified as single numbers, multiple numbers,
      # ranges, or a mixture thereof, e.g. "0-5,7,9,15-22".  Note there must
      # be no spaces within the string of characters.
      #
      # Use '*' in any of the first 5 fields to signify "all".
      # 
      # <min> <hour> <date> <month> <day> <command> [args]
      # 0-59   0-23   1-31   1-12    0-6   
      #
      # Trivial examples:
      #
      # Every 20 mins, advertise the BBS using an APRS symbol on port 13
      # 0,20,40  *  *  *  *  send 13 APZ186 v WIDE !5224.00N/00215.00WB GB7PZT BBS 
      #
      # Every Thursday at 03:05 save nodes table to an archive
      # 5 3 * * 4 SAVENODES XRNODES.ACV
      #



















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  105

      Configuration Files: DOMAIN.SYS


      DOMAIN.SYS
      ~~~~~~~~~~
      This optional file is used by Xrouter to resolve host names such as 
      "g8jvm.ampr.org" and aliases such as "lgsbbs" into their corresponding 
      IP addresses.  If not present, and an external DNS is not specified, 
      you will have to enter the full IP address of any target host when 
      using the PING, TELNET, TTY, and FINGER commands.  It is read every 
      time an address needs resolving, so any changes you make will take 
      effect immediately.

      Although DOMAIN.SYS was originally designed to be simpler than the 
      more standard DOMAIN.TXT format, Xrouter is capable of understanding 
      both formats, so you may use an existing DOMAIN.TXT simply by renaming 
      it to DOMAIN.SYS.

      Name resolution using an external DNS (Domain Name Server), if 
      enabled, takes a finite time so you should add entries to this file 
      for frequently contacted hosts whose addresses are stable.  Externally 
      resolved names are added automatically to DOMAIN.SYS at regular 
      intervals, and expired entries are purged.

      Each host is listed on a separate line.  Each field should be 
      separated by one or more spaces or tabs.  Comments, spaces, tabs and 
      blank lines are permissible to aid clarity.  The records are case-
      insensitive, but most people use lower case for hostnames.  The format 
      of each record is as follows:

             <hostname> [ttl] IN A <ip-address>

             <alias>    [ttl] IN CNAME <hostname>
             
             <hostname> [ttl] IN MX [pref] <hostname>

      The first form maps a hostname to an IP address, and the second and 
      third forms map an alternative hostname to a host already defined.  

      For example, the IP address for the GB7PZT mailbox is 44.131.91.2 so 
      it would have an Internet Address (IN A) record like so:

             gb7pzt  IN   A    44.131.91.2

      But gb7pzt is also known locally as "pztbbs", and "kdrbbs".  While 
      there is nothing to stop you adding further "IN A" records for gb7pzt, 
      one for each alias, but you could instead use the second form shown 
      above, the CNAME or "Canonical Name" record like so:

             pztbbs. IN CNAME  gb7pzt
             kdrbbs. IN CNAME  gb7pzt
















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  106

      Configuration Files: DOMAIN.SYS


      Thus if the user types "TEL pztbbs" or "TEL kdrbbs", the 
      gb7pzt record is used.  This removes the need to keep repeating the IP 
      address in multiple "A" records, and makes it easier if the IP address 
      is changed.

      The MX or "Mail Exchange" records are usually used for defining 
      alternate names for mail servers, but as Xrouter is not concerned 
      with mail you can use them in the same way as CNAME entries, although 
      there would be no point in doing so. The format of the additional 
      records would be:

             pztbbs.   IN   MX   gb7pzt
             kdrbbs.   IN   MX   gb7pzt

      The optional "preference" field of MX records is ignored.  The DNS 
      server doesn't currently respond to MX queries, but will eventually do 
      so.

      The optional [ttl] field in all types of entry is the "time to live" 
      of the entry in seconds, used to expire records whose addresses are 
      liable to change.  If omitted or set to zero, the record has an 
      unlimited lifetime. 

      In order to simplify the file, the ".ampr.org" is usually omitted from 
      the records, and appended automatically when the file is read.  
      However, hostnames which contain or end with a dot will not be 
      extended in this manner.  Thus "gb7pzt" will be extended to 
      "gb7pzt.ampr.org", whereas "lgs." and "ns.cyberphile.co.uk" will be 
      left alone.



































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  107

      Configuration Files: ENCAP.TXT


      ENCAP.TXT
      ~~~~~~~~~
      This is *not* an Xrouter configuration file, but I was asked to make 
      Xrouter capable of reading it.

      Encap.txt is a closely guarded secret, available only to a selected 
      few overlords, but is simply a text file which contains a huge list of 
      amateur IP routes and the encap (IPIP) gateways which handle them.  If 
      this file is present when Xrouter boots up, it will read the routes 
      into its routing table.

      If you are not routing IP, or have set up your own encap routes in 
      IPROUTE.SYS you do not need this file.

      If you're interested, the format of routing entries is as follows:

           route addprivate 44.131.91.0/24 encap 62.31.206.176

      The "addprivate" signifies that the route should not be visible to 
      users, because these people are paranoid about revealing their non-
      amateur IP addresses and routing secrets.

      The "encap" simply tells the router to use IPIP encapsulation, i.e. it 
      is the same as Xrouter routing mode "e".

      ENCAP.TXT contains over 500 entries, and will use over 50Kb of memory 
      if you load it.  It will also make your IP routing slower, because all 
      those routes must be searched recursively for every single datagram 
      routed by your system.  With a fast computer or low data rate you 
      probably wouldn't notice the difference in speed, but at least I've 
      warned you.

      You are also warned that ENCAP.TXT is subject to frequent modification 
      so you will need to obtain updated copies from time to time, and 
      restart Xrouter to load them.





























      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  108

      Configuration Files: IGATE.CFG


      IGATE.CFG
      ~~~~~~~~~
      This file is required only by the IGATE daemon, therefore you do not 
      need it if you are not using IGATE.  It is a plain text file read each 
      time the daemon is started.  The following keywords are accepted:

           IFILTER   <from> <to> <text>  Filter rules for Internet->Packet
           LOG       <0-255>             Activity logging level
           MAXTRIES  <n>                 Max. server connect attempts.
           PAUSE     <seconds>           Min. interval to try same server.
           PFILTER   <from> <to> <text>  Filter rules for Packet->Internet
           SERVER    <ipaddr/hostname:port>       Specifies Internet server to use
           SKIP      <seconds>           Blacklist interval after failure
           WAIT      <seconds>           Time to wait for connection

      These are fully documented in the section relating to IGATE.

      Abbreviated example file:

      ; APRS IGATE Configuration file for Xrouter version 177
      ;
      ; You can list as many servers as you like. They are tried in rotation.
      SERVER 213.180.75.122:2023
      ;
      ; Wait up to 60 secs for connection before trying next server
      WAIT 60
      ;
      ; Wait 60 secs between successive attempts to same server
      PAUSE 60
      ;
      ; Max connect attempts before blacklisting the server
      MAXTRIES 10
      ;
      ; If blacklisted, don't try the server for 1 hour
      SKIP 3600
      ;
      ; IFILTER controls gating from internet to packet:
      ;
      ; IFILTER       From    To      Text
      ; -------------------------------------
        IFILTER       G#*     *       *
      ;
      ; PFILTER statements control gating from packet to internet:
      ;
      ; PFILTER       From    To      Text
      ; ------------------------------------
        PFILTER       G*      AP*     *
        PFILTER       MB7*    AP*     *
      ;
      ; Radius of Interest
      ;
      RADIUS 150
      ;
      ; Activity logging
      ;
      LOG     255








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  109

      Configuration Files: IPROUTE.SYS


      IPROUTE.SYS
      ~~~~~~~~~~~
      This optional file defines how IP datagrams should be routed, and is 
      not required if you don't intend to route IP traffic.  It is read only 
      at boot-up, or by an "IP ROUTE LOAD" command so if you make changes to 
      it, they won't have any effect until you reboot or use that command.  

      If iproute.sys is present, it saves you having to enter the IP routing 
      manually.  To reduce the number of files, this file also contains 
      the permanent ARP (Address Resolution Protocol) entries.

      If you are familiar with IP you can skip the next 4 paragraphs....

      All IP addresses consist of a 32 bit binary number, which is composed 
      of four 8 bit binary numbers.  For clarity they are usually expressed 
      as four decimal numbers separated by dots, the so called "dotted quad" 
      form, for example 44.131.91.2 is the address for gb7pzt.

      Each of the numbers which make up the quad can range from 0 to 255, 
      i.e. 256 numbers in total.  The numbers 0, 128 and 255 are usually 
      reserved for special purposes.

      The most significant number identifies the "network" within the whole 
      Internet.  44 is allocated to Amateur Packet Radio, or "ampr.org".   
      Within ampr, the second number identifies the country, and in our 
      example 131 is the code for UK.  The third number identifies the 
      "region", and in our example region 91 is North Worcestershire.  The 
      last number identifies up to 256 separate users within the region.   
      The addresses within a region are sometimes allocated on a first come 
      first served" basis, or sometimes in groups to allow further 
      subdivision of a region.

      Unlike NetRom, IP routing has to be explicitly defined by the sysop, 
      in our case using entries in IPROUTE.SYS.

      Each entry should be on a separate line, and there should be one or 
      more spaces or tabs between each field.  Entries are not case 
      sensitive.  Comments are allowed in the file, providing they are on a 
      line beginning with a semicolon.

      All IP routing entries begin with the word "route", and there are two 
      types.  A "Route default" entry defines how datagrams should be routed 
      if no other route can be found.  "Route add" entries add routes to the 
      table (what a surprise! ;-)

      The general form of a route default entry is:

            IP ROUTE DEFAULT <portnum> [<gateway> [d|v|n|e|u|r|s] ]

      <portnum>  is the port number on which to route the datagram.

      <gateway>  is the IP address or hostname of the neighbouring router
                 to whom datagrams should be routed if there is no other 
                 applicable route.  If this address is not specified, the 
                 destination will be tried directly on the default port.









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  110

      Configuration Files: IPROUTE.SYS


                 It is more efficient to use an IP address here, but you 
                 might need to use a hostname if the gateway has a dynamic 
                 IP address for example.  In order to use hostnames, your 
                 system must have access to a DNS, and must be configured to 
                 use it.

      <d|v|n|e|u|r|s> is the mode: (d)atagram, (v)irtual circuit, (n)etrom,
                 (e)ncap, ip(u)dp, (r)eject or (s)ilent discard.

                 If omitted, the default is "Datagram", which transmits 
                 datagrams "raw" inside SLIP, PPP or AX25 UI frames, 
                 according to protocol used on the the destination port. 

                 There is no error correction at the link layer, so datagram 
                 mode should only be used on wire links, or RF links with 
                 low loss rates.

                 Better performance can be obtained on lossy RF links by 
                 using Virtual Circuit mode, which transports the IP 
                 datagrams inside AX25 <I> frames, detecting and correcting 
                 errors at the link layer.

                 Netrom mode is less efficient, but can "tunnel" datagrams 
                 across non-ip parts of the network by wrapping them in 
                 Netrom layer 3 frames.

                 Encap mode is used for IP/IP encapsulation, i.e. sending 
                 44-net datagrams across the internet by "wrapping" them in 
                 datagrams with internet addresses.

                 IPUDP mode is similar to Encap, except that the datagrams 
                 are first wrapped in UDP before being transported in IP.
       
                 The advantage is that UDP is usually able to pass through 
                 routers which don't support IPIP, and can be selectively 
                 routed according to the UDP service port numbers.

                 Datagrams matching a "reject" entry are rejected by 
                 returning an ICMP "destination unreachable" report to the 
                 sender.  The "gateway" ip address should be 0.0.0.0 andd 
                 the port number is ignored.  This type of entry is used to 
                 reject traffic destined for systems which don't exist, or 
                 are not reachable via any port.  If simply routed on the 
                 default port, such datagrams would waste resources and 
                 would probably end up looping back to us.

                 Datagrams matching a "silent discard" entry are simply 
                 dropped without sending an ICMP error report.  This is more 
                 suitable for suppressing malicious network probes.

      At least a port number is required. A typical entry would look like:

             route default 11 44.131.90.6 d

      which means "route all unknown destinations via neighbouring router 
      44.131.90.6, on port 11, using datagram mode".








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  111

      Configuration Files: IPROUTE.SYS


      The general form of the route add entry is:

             IP ROUTE ADD <host/bits> <gateway> <portnum> <d|v|n|e|u|r|s>

      <host>     is the target host IP address in dotted quad form.

      <bits>     is the number of bits to be matched (subnet mask)

      If the <gateway> address is 0.0.0.0 or just "*", the destination will 
      be tried direct on the specified port.

      When making routing decisions, only the specified number of bits (0-
      32) of the address are compared, starting at the most significant 
      (leftmost) bit, the remainder being ignored.  This allows a group of IP 
      addresses to be matched by a single entry.

      For example, a setting of 24 would cause only the most significant 24 
      bits of the address to be compared, allowing a whole region (256 
      addresses) to be routed to a single gateway.  Important - You must not 
      omit the subnet mask!

      A typical routing entry would look like this:

             ip route add 44.131.93.0/24   44.131.93.240   5  d

      which would route all region 93 traffic (44.131.93.0 - 44.131.93.255) 
      to the gateway 44.131.93.240 on port 5 using datagram mode.

      You may specify more than one route to the same group of addresses 
      using different bit masks.  For each address within the group, Xrouter 
      will choose the route with the highest number of matching bits.


      ARP Entries

      ARP entries are responsible for mapping gateway IP addresses to 
      "hardware" (i.e. AX25 or Ethernet) addresses.

      In order to send an IP datagram over an AX25 or Ethernet network, it 
      must be "wrapped" in an AX25, Ethernet, or Netrom packet, and that 
      packet will need a destination address appropriate to that network.  
      For example, if I want to route a datagram to 44.131.91.2 it must be 
      wrapped in an AX25 packet addressed to GB7PZT-5.

      The system *will* sometimes work without any ARP entries, due to the 
      process of "ARP resolution", whereby a router can make a broadcast 
      asking adjacent systems if they know the hardware address for a given 
      IP address, but this process takes time and the adjacent routers may 
      not know the answer.  Thus it is advisable at least to have one ARP 
      entry for each of your direct RF neighbours.  The general form of an 
      ARP entry is:

         ARP ADD <host> <ax25 | ether | netrom> <callsign | ether_address>

         or

         ARP PUBLISH <host> <ax25 | ether | netrom> <callsign | ethaddr>







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  112

      Configuration Files: IPROUTE.SYS


      Example ARP entries:

      This one causes datagrams bound for 44.131.90.6 to be wrapped in AX25 
      packets addressed to GB7IPT-9:

             arp add 44.131.90.6  ax25  GB7IPT-9

      Whereas the following will send datagrams bound for 44.131.95.7 to the 
      G7GHP-5 system via the GB7DIG digipeater.  Up to 8 digipeaters may be 
      used in a single comma-delimited string:

             arp add 44.131.95.7  ax25  G7GHP-5,GB7DIG

      And this one will wrap datagrams destined for 44.131.24.1 in Netrom 
      packets addressed to a distant system GB7CX:

             arp add 44.131.24.1  netrom  GB7CX

      The following will wrap the datagrams in ethernet packets.
             arp add 44.131.91.9  ether  00:00:1B:2C:04:81

      ARP PUBLISH is used in cases where one system is "hidden" behind 
      another, and allows other systems to discover the correct hardware 
      address to use.

      For example, my 44.131.91.127 system is only reachable via my main 
      router 44.131.91.245.  Unless all the local systems were specifically 
      configured to route to 91.127 via 91.245, they wouldn't know how to do 
      it.

      Including the entry: "arp publish 44.131.91.127 ax25 g8pzt" on 
      the 91.245 (g8pzt) router causes it to respond to anyone who asks for 
      the hardware address for 91.127, giving its own ax25 address.

      A new command ARP CMD [0-255] to control who can see/ what can be 
      seen of the ARP table 

  
      Flags are currently:

	   1 = Command is available to secure sysops (e.g. wire links)
	   2 = Command available to non-secure sysops (e.g. rf links)
	   4 = Command is available to users
	   8 = Private addr's visible to secure sysops
	   16 = Private addr's visible to non-secure sysops
	   32 = Private addresses visible to all users

	   default is 255. Command can also be used at the command prompt
      or in BOOTCMDS.SYS















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  113

      Configuration Files: PASSWORD.SYS


      PASSWORD.SYS
      ~~~~~~~~~~~~
      This optional file contains the passwords for AX25 remote sysop 
      access, RLOGIN and FTP.  If the file is not present, these forms of 
      access will not be possible.

      There should be one entry for each remote sysop.  Each entry should be 
      on a separate line and consists of two fields separated by one or more 
      spaces or tabs.  The first field is the remote sysop's callsign 
      (without an SSID) and the second field is the corresponding password 
      string.  For example:

             G8PZT   thisispaulaspassword
             G1LOA   thisisrobertspassword

      The fields are not case sensitive, and the passwords can be anything 
      you like, with a couple of limitations, namely PASSWORDS MUST NOT 
      CONTAIN SPACES, and the TOTAL LINE LENGTH MUST NOT EXCEED 80 
      CHARACTERS.  You should try to choose a password that you can easily 
      remember, but that others would find hard to guess.  It should 
      preferably be longer than 5 characters, to reduce the chances of 
      someone guessing it.  The longer you make it, the more secure it will 
      be.  A random string is the most secure, because even if someone works 
      out part of it, they won't be able to guess the remainder.

      You may have a different password for each sysop, or you might choose 
      to give everyone the same password.  Obviously the former is the most 
      secure, but it's completely up to you.




































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  114

      Configuration Files: PPPHOST.n


      PPPHOST.n
      =========

      This optional file is required only if a PSTN modem is connected to 
      Xrouter and auto-answer is enabled.

      It is read only when a modem caller issues the command "XLINK PPP", 
      and may contain PPP commands to override the default PPP configuration 
      for the duration of the call.  The default configuration is probably 
      OK for most purposes, but you may for example wish to change the 
      inactivity timeout or the IP address.

      There may be several of these files, one for each modem port. The "n" 
      represents the port number on which the caller has accessed Xrouter.


















































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  115

      Configuration Files: XRNODES


      XRNODES
      ~~~~~~~~
      This file is identical in format and function to the BPQNODES file 
      used by BPQ for node & route table saving and recovery.

      The nodes and routes tables are saved to this file every 
      NODESINTERVAL, at close-down, and whenever the SAVENODES command is 
      used (unless a different filename is specified).

      The ROUTE entries are first, and have the following format:

      ROUTE ADD <call> <port> <quality> [!] [VIA call call ...]  [options]

      Where <call> is the callsign of the neighbour node, <port> is the port 
      upon which it is reached, and <quality> is a figure between 0 and 255 
      indicating how "good" the route is.  "!" indicates a locked route 
      (i.e. one which will not expire).  If the neighbour is reached via 
      digipeaters, the next field should start with "VIA" and each digi call 
      should be separated by exactly ONE space, with the end marked by 
      exactly TWO spaces.

      The [options] fields are "non-standard" parameters which can override 
      the port defaults for that route as follows:

           [maxframe [frack [paclen [maxtt [maxhops]]]]]

      For example:

           ROUTE ADD W7XCV 1 100
           ROUTE ADD G8UYL 2 240 ! 5 7000 120
           ROUTE ADD G7DIG 5 ! VIA M7FRT M3RED  2 

      The first line shows unlocked neighbour W7XCV on port 1 with quality 
      of 100.  The second line shows neighbour G8UYL locked in on port 2 
      with a quality of 240, maxframe of 3, frack of 7000, and paclen 120.  
      The third line shows neighbour G7DIG locked in using a digipeated path 
      via M7FRT and M3RED, with maxframe of 2.


      Following the ROUTE entries, the remainder of the file consists of 
      NODE entries, one per line. The format is as follows:

      NODE ADD <alias:call> <route1> <port1> <qual1> [!] [<route2> ... ]

      Where <alias:call> is the alias and callsign of the distant node, 
      <route1> is the callsign of the primary route to that node, for which 
      there must be a route entry, <port1> is the port used to reach that 
      neighbour and <qual1> is the quality of that route. "!" indicates a 
      locked route.  There can be up to 3 different routes listed for each 
      node.

      For example:

      NODE ADD #TLFRD:GB7IPT-7 G8PZT 1 142 ! G8UYL 2 139
      NODE ADD BRUM:GB7BM G8PZT 1 94 G8UYL 2 92
      NODE ADD BUXTON:GB7DAD-8 G8PZT 1 22 G8UYL 2 21


      Time domain routing information is now also stored in XRNODES to
      allow routing to settle more quickly after a reboot.




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  116

      Configuration Files: TELPROXY.MSG


      TELPROXY.MSG
      ============

      This optional file is only required if you are using the Telnet Proxy 
      feature.  It contains text which is sent to the user upon uplink 
      connection to the proxy.

      If the file is not present, the following default text is displayed:

           Use: Tel[net] <ipaddr> [port] 
           Ready
           >

       
      --------------------- example follows --------------

      To connect to another system, enter "TEL[net] <ipaddr> [port]"

      e.g. Tel 44.131.91.2 7777

      Type HELP for any other help

      ---------------------- example ends -----------------









































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  117

      Configuration Files: USERPASS.SYS


      USERPASS.SYS
      ============

      The entries in this optional file are used, if dictated by entries in 
      ACCESS.SYS, to control normal Telnet (port 23) logins, and APRS server 
      (port 1448) logins  They are not used for sysop logins, Rlogin or FTP.

      Each line consists of two fields, i.e. the same format as 
      PASSWORD.SYS.  The first field is a user callsign, without SSID, and 
      the second is the user's password.  For extra security, it is 
      advisable for sysops to use different passwords for telnet and rlogin.


      Example USERPASS.SYS file:
      ~~~~~~~~~~~~~~~~~~~~~~~~~~
      ; USERPASS.SYS for Xrouter
      ;
      ; This file contains passwords for Telnet and Modem logins.
      ;
      ; Fields are: <callsign> <password>
      ; Callsigns should not include SSID
      ;
      G8PZT amazon
      G7CXZ drvxcdfre
      ;





































   

      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  118

   Configuration Files: TELPROXY.ACL

      TELPROXY.ACL
      ~~~~~~~~~~~~
      Added new file TELPROXY.ACL to provide TCP/IP egress control for the
      Telnet proxy server.  This should preferably be located on a ramdisk
      configured as drive R: for best results. If a ramdisk is not used,
      locate the file in the same directory as Xrouter.  If the file not
      present, all egress is blocked.
   
      Example file: TELPROXY.ACL
 
      # TELPROXY.ACL	Egress control rules for Xrouter Telnet proxy
      #
      # Fields:<action> <source_ip>[/mask] <dest_ip>[/mask]<dest_port(s)>
      #   
      # <action>      PERMIT  Allow egress
      #               DENY    Prevent egress
      # <source_ip>   IP address of uplinked user
      # <dest_ip>     IP address of target system
      # <mask>        Either: No. of bits (0-32) to match from left to right
      #               Or:     Subnet mask in form n.n.n.n
      # <port(s)>     One or more TCP service numbers (0-65535).  Allowed
      #               formats are "n", "n,n,n", "n-n" or combination thereof.
      #
      ;    
      ; Allow LAN users to connect to anyone
      permit	44.0.0.0/8		0.0.0.0/0	0-65535
      ;






































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  119

      Configuration Files:TELGUEST.ACL

      TELGUEST.ACL
      ~~~~~~~~~~~~

 

      Guests are prevented from using the SEND, CHAT and CONNECT 
      commands, and from sending APRS messages using the APRS 
      messaging shell.  For TELNET they are restricted by the 
      rules in new file TELGUEST.ACL, which uses the same format 
      as TELPROXY.ACL.  If the former file is not present, 
      guests cannot use the TELNET command at all.
 
      Example file: TELGUEST.ACL

      # TELGUEST.ACL	Egress control rules for Xrouter Telnet guest use
      #
      # Fields <action> <source_ip>[/mask] <dest_ip>[/mask]<dest_port(s)>
      #
      # <action>     PERMIT  Allow egress
      #              DENY    Prevent egress
      # <source_ip>  IP address of uplinked user
      # <dest_ip>    IP address of target system
      # <mask>       Either: No. of bits (0-32) to match from left to right
      #              Or:     Subnet mask in form n.n.n.n
      # <port(s)>    One or more TCP service numbers (0-65535).  Allowed
      #              formats are "n", "n,n,n", "n-n" or combination thereof.
      #
      ;
      ; Allow LAN users to connect to anyone
      permit	44.0.0.0/8		0.0.0.0/0	0-65535
      ;


































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  120

     Configuration Files:HTTP.ACL

      HTTP.ACL
      ~~~~~~~~

      A new HTTP.ACL file holds the egress control rules for the 
      proxy/tunnel, and should preferably be located on a ramdisk 
      configured as drive R: for best results. If a ramdisk is not 
      used, locate the file in the same directory as Xrouter.  
      If the file not present, all egress is blocked.


      Example file: HTTP.ACL

    # HTTP.ACL	Egress control rules for Xrouter HTTP Proxy / Tunnel
    #
    # Fields:<action> <source_ip>[/mask]<dest_ip>[/mask]<dest_port(s)>
    #
    # <action>     PERMIT  Allow egress
    #              DENY    Prevent egress
    # <source_ip>  IP address of uplinked user
    # <dest_ip>    IP address of target system
    # <mask>       Either: No. of bits (0-32) to match from left to right
    #              Or:     Subnet mask in form n.n.n.n
    # <port(s)>    One or more TCP service numbers (0-65535).  Allowed
    #              formats are "n", "n,n,n", "n-n" or combination thereof.
    #
    ; Allow LAN users to tunnel to anyone
    permit     44.0.0.0/8    0.0.0.0/0	0-65535
    ;
    ; Allow Internet users to tunnel only to certain ports on xrouter
    ;permit    0.0.0.0/0    192.168.0.245   23,87,1448,3600
    ;


































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  121

     Configuration Files:HTTP.SYS
    
      HTTP.SYS
      ~~~~~~~~

      This allows invisible proxying of external http servers, and is
      controlled by REWRITE entries in a new HTTP.SYS file.

      For example, if you only have one public ip address, but you have 
      more than one HTTP server on your LAN which you wish to make 
      visible to the outside world, you could use non-standard port 
      numbers, e.g. http://g8pzt.atx.cx:8081, but that is messy.  You 
      can't expect people to remember the port numbers, and no-one can 
      be bothered to type them in!

      This is where Xrouter can come to the rescue, using the URL rewriting
      facility plus the http proxy to redirect requests to any number of
      alternate servers based upon the first part of the URL.  For example,
      on my system, the standard HTTP port 80 is directed to Xrouter, and
      Xrouter proxies the web server on my separate Xserv machine.

      The syntax of entries in HTTP.SYS is 
      "REWRITE <oldstring> <newstring>",
      where <oldstring> is a partial URL, always starting at the beginning
      of the URL, and <newstring> is a string of characters which will be
      substituted in that URL.  Entries are case-insensitive.

      For example: "REWRITE /bbs http://192.168.0.4" would replace "/bbs" 
      at the start of a URL with "http://192.168.0.4", so that a url like:
      "/bbs/cgi-bin/menu.pz" becomes: "http://192.168.0.4/cgi-bin/menu.pz".
      The resulting url then treated as if it was a proxy request, and is
      directed to the approriate server.

      When using the rewrite feature to proxy another web server, the
      resultant url *must* start with "http://<address>[:port]" where
      <address> can be either a hostname or ip address.  Use an IP
      address or local machine nickname for machines on your LAN.

      The rewrite feature can also be used to create pseudo directories
      which are not where they appear to be, e.g.
      "rewrite  /bbs  /systems/gb7pzt".

      There are no validity checks, so you *must* be careful not to
      inadvertently remove "/" characters from the rewritten string, e.g.
      the entry "rewrite /bbs/  http://192.168.0.4" would cause
      "/bbs/index.htm" to be rewriten as "http://192.168.0.4index.htm",
      which will clearly fail.

      Added capability for http proxy to pass traffic to a downstream 
      proxy. This is enabled by putting the following line in HTTP.SYS:

      proxy <ipaddr> <port> <subnet_mask>

      e.g. "proxy 44.131.91.245  80  255.0.0.0"

      <ipaddr> and <port> are those of the next proxy, while <subnet_mask>
      when combined with the proxy address specifies the range of addresses
      which are on the same subnet as the proxy.  These addressess will 
      bypass the proxy, i.e. our proxy will connect directly to them 
      instead of via the next proxy.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  122

     Configuration Files:HTTP.SYS

      This is all a quick bodge to enable amprnet systems to use a further
      proxy to gain a commercial ip address when contacting non-amprnet
      websites. It was necessary because amprnet routing is useless, i.e.
      if a 44-land browser tries to directly use google, the reply probably
      won't get routed back. 
  
      For example, consider a browser (using Internet Explorer) whose IP
      address is 192.168.0.5, ethernet-linked to an Xrouter, whose ethernet
     
      IP address is 192.168.0.3, and radio IP address is 44.131.91.3. This
      station is radio linked to the KIDDER network access point. KIDDER is
      linked to the Internet, and via radio to other amprnet systems.

      The browser has been set up to use Xrouter's HTTP proxy, which means
      all outgoing http traffic now originates from 44.131.91.3.  This
      traffic will work fine on amprnet websites, but is unlikely to work 
      on commercial internet sites.  But if the Xrouter has been set up 
      with the above configuration, the amprnet (44.x.x.x) sites will 
      be routed directly by the proxy, whilst the non-44 sites will be 
      passed to KIDDER's http proxy, where they will gain a 62.31.206.176 
      source address, which is reliably routable and doesn't rely on the
      co-operation of others in the ampr net.

      The obvious question is, why not use KIDDER's proxy directly, using 
      NAT to translate the 192.168.0.5 to 44.131.91.3?  The answer is 
      that Win95's TCP/IP settings are really useless for packet radio, 
      so the intermediate proxy makes it radio-friendly.  Also, it would 
      not otherwise have been possible to use the 44 address for selectively 
      working ampr web sites.

      Added another directive to HTTP.SYS:
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      proxytimeout 30 

      Specifies the maximum wait interval for a connection in seconds.  
      If a proxy connection takes longer than this to establish, an error 
      is returned. Default is 30 secs, which was the previous fixed value.  
      It probably needs > 60 sec on a radio channel, and it probably needs 
      to vary according to the destination address, e.g. 30 secs for 
      internet and 180 sec for amprnet
  
      Example file: HTTP.SYS

      # HTTP.SYS HTTP URL rewrite rules for XRouter 186
      #
      # Format is REWRITE <old_string> <new_string>
      #
      ;rewrite /bbs http://192.168.0.4
      #
      #
      # Added capability for http proxy to pass traffic to a downstream proxy.
      # This is enabled by the following line
      #
      #      proxy <ipaddr> <port> <subnet_mask>
      ;
      ;proxy 44.131.91.245  80  255.0.0.0
      #
      # A timemout can be set for proxy connections the default is 30 secs
      # but may be increased for slower radio links
      ; proxytimeout 60 





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  123

      Configuration Files:HTTPBAN.SYS

      HTTPBAN.SYS File
      ================


      Internet-connected HTTP servers tend to get hit with malicious HTTP
      requests from hackers and various worms such as "Code Red".  Xrouter
      is not vulverable to these attacks but they make me angry so I have
      added the facility to block them.  This uses a new file HTTPBAN.SYS,
      which is a simple text file located in the Xrouter directory. It can
      contain URL templates which are used in a case-independent sliding
      match with a requested URL.  Each template can be up to 127 bytes long.
      The match must occur within the first 256 bytes of the requested URL.
      If any part of the requested URL matches the template, the sender's
      IP address is entered into a ban list and all further IP from that
      host is ignored until xrouter is restarted. Up to 20 hosts can be
      banned simultaneously.  If there is a need for more, I can adjust
      this later.  You can find out which are the common hacks by examining
      your daily logfiles, looking for the "HR ... " (HttpRequest) lines.
      Common ones are "/default.ida" and "/scripts"
 
 

      HTTP banning now checks all requests, and checks the whole request
      instead of the URL alone. By default it is now case sensitive, but can
      be made to perform a case-independent test by preceding the template
      with the keyword "anycase". e.g. "anycase connect" will ban CONNECT,
      connect, CoNnEcT etc.







      Example file: HTTPBAN.SYS

      ;/scripts
      ;/default.ida



























      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  124

      Configuration Files:DYNDNS.CFG

      DYNDNS.CFG
      ~~~~~~~~~~


      ; DYNDNS.CFG: Configuration file for XRouter Dynamic DNS update client
      ; Do not delete or change the order of entries.
      ;
      ; Update server name
      members.dyndns.org
      ;
      ; IP detection server
      checkip.dyndns.org
      ;
      ; Account Name (put your own account name here)
      test
      ;
      ; Account Password (Put your password here)
      test
      ;
      ; System (dyndns, statdns or custom)
      ; (The latter two are only available on subscription.)
      dyndns
      ;
      ; Use external IP detection? (yes / no)
      ; This should be set to NO if Xrouter is directly connected to the
      ; Internet or YES if the internet connection is via another router.
      NO
      ;
      ; Wildcard (ON / OFF)
      ; If this is set to ON, *.host.domain will be aliased to host.domain
      ON
      ;
      ; Hostname(s) to be updated, separated by commas. No spaces.
      ; (put your own hostname(s) here)
      test.ath.cx,test.dyndns.org,test.dnsalias.net
      ;





























      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  125

      Configuration Files: XROUTER.CFG


      XROUTER.CFG
      ~~~~~~~~~~~
      This file is mandatory, and contains most of the configuration info 
      for Xrouter.  It is read only when the program starts.

      It consists of entries of the general form <keyword>=<value>, each on 
      a separate line.  Keywords are not case sensitive, and in general they 
      may be in any order, but interfaces MUST be defined before ports.  
      Blank lines are allowed, and comment lines must begin with a semicolon 
      (;) in the leftmost column.  Lines must not exceed 255 characters.
       
      Note that some timings are in millisecs, some are secs.

      Global Keywords
      ~~~~~~~~~~~~~~~
      The following keywords are accepted in the "global" section of 
      XROUTER.CFG, i.e. outside CONSOLE, INTERFACE, PORT, APPL and ROUTES 
      definition blocks. (* = mandatory)


      APPL

              Marks the start of an APPL definition block.  The application 
              number must be between 1 and 8, and corresponds to the 
              application's position on a BPQ "APPLICATIONS=" line.

              Some applications have fixed application numbers, e.g. BBS's 
              and PMS's are usually hardwired as the first application, 
              while Host programs such as PAC4 are usually the second.

              Example: APPL=3


      APPLQUAL

              Default NetRom quality to broadcast for BPQHOST and socket 
              applications. Default = 150.  See APPL section.


      APRSCALL      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page

              Callsign used by the Igate to identify itself in beacons and 
              third party messages.  If omitted, it defaults to Nodecall.

              Example: APRSCALL=MB7UXX


      BOTWINBGCOLOR

              See CONSOLE definition section.


      BOTWINTXTCOLOR

              See CONSOLE definition section.

      CHATALIAS *

              Alias for chat server (6 chars max).





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  126

      Configuration Files: XROUTER.CFG


              I suggest this should end with "CHT" and begin with something 
              geographically relevant, e.g. BHMCHT for Birmingham, LDSCHT 
              for Leeds etc., so it can be easily identified in node tables. 

              If you make CHATALIAS the same as NODEALIAS or not specify the
              CHATALIAS, the chat server will not be directly connectible.

              Example: CHATALIAS=KDRCHT


      CHATCALL *

              Chat server callsign. This may be the same as the NODECALL, 
              but must use a different SSID, otherwise the chat server will 
              not be directly connectible.

              Note - the chat server is an integral part of the system and 
              cannot be disabled. You may prevent it from being directly 
              connectible by setting CHATCALL and CHATALIAS the same as 
              NODECALL and NODEALIAS or by simply omitting the keywords of 
              CHATCALL and CHATALIAS, but it will still be available to all 
              users via the "chat" command.

              Example: CHATCALL=G8PZT-8


      CHATLINKS

              List of chat servers to which this server will link.  For 
              netrom links you must supply the *callsigns* not the aliases.  
              You may use multiple CHATLINKS lines if required.

              Unilateral links are not allowed - each partner in this list 
              must place your CHATCALL in their CHATLINKS list.  You may 
              only use partners who are in your node tables.

              Xrouter allows only limited interconnection with "Ping-Pong 
              Converse" servers, because the two systems are completely 
              different (Ping Pong doesn't have local channels for 
              instance).

              At present, links to Xrouter peers must use Nterom, and links 
              to Ping-Pong peers must use TCP/IP.

              Don't link with distant servers - if the links are too slow 
              your users will get poor service. You may disable all outgoing 
              and incoming linking by omitting this keyword.

              Examples: CHATLINKS=G9XOT-8,G7DTY-8
                        CHATLINKS=brmcht 80.185.22.37:3601


      CHATQUAL

              Chatcall quality to broadcast (0-255, default=255).

              This can be used to limit the visibility of your server to a 
              reasonable geographical area, and discourage chat server 
              "dxing".





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  127

      Configuration Files: XROUTER.CFG


              Example: CHATQUAL=150


      CMDWINBGCOLOR

              See CONSOLE definition section.


      CMDWINTXTCOLOR

              See CONSOLE definition section.


      COMMAND

              Creates a custom command.

              Up to 16 single-word commands can be created, allowing the 
              sysop to automate frequently used command strings.  For 
              example you might wish to set up BBS, CONV and DXCLUSTER to 
              point to local systems.

              Each command is defined using a separate "COMMAND=" string, 
              and the arguments are <cmd_name> <real_cmd>.
              e.g. "COMMAND=BBS C 7 GB7PZT" means "create a new command 
              called BBS, which translates to the sequence C 7 GB7PZT"


      CONSOLE

              Begins a CONSOLE definition block.  The argument can be 
              between 1 and NUMCONSOLES.

              A console definition block is used to override the default 
              console settings for one console.  Only the values which 
              differ from the globals need be specified.  Alternatively you 
              may omit the global console settings altogether and fully 
              define each console.

              Example: CONSOLE=3


      CONSOLECALL

              See CONSOLE definition section.


      CTEXT

              Connect text.  Specifies one or more lines of text which is 
              sent to an incoming caller upon connection.  CTFLAGS controls 
              which callers receive the text.

              There is no limit on the number of lines of text you can 
              specify, but no line must exceed 255 characters.  The end of 
              text is marked by *** on a line by itself.








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  128

      Configuration Files: XROUTER.CFG


              Example:
              CTEXT
              Kidderminster spur AX25/IP Router.
              Type ? for list of commands.
              ***


      CTFLAGS

              Connect Text Flags.  These flags control which incoming 
              connects will receive CTEXT.  The value is the sum of the 
              required flags from the following list:

                 1    Send ctext if connect is to Node/port alias
                 2    Send ctext if call is to Node/port call
                 4    Send ctext on L4 connects.
                 8    Send ctext to TCP (TELNET) callers.

              The default is 9 (Alias and TCP only).

              Example: CTFLAGS=1


      CTRLADDR
              This is the address (in hexadecimal) of the parallel port (if 
              any) used for controlling / monitoring external hardware.

              If this is the same as WATCHADDR, only the most significant 7 
              bits will be available for control if the hardware watchdog is 
              enabled.

              Example: CTRLADDR=378

      DCACHE
              Limits the cache size for dynamic hostnames        default=10 

      DESQVIEW
              Specifies whether or not Xrouter is running within a Desqview 
              environment.

              If Desqview is used, this must be set to 1, otherwise Desqview 
              may not function properly.  If Desqview is not in use set the 
              argument to 0 (default) or omit the keyword altogether.

              Example: DESQVIEW=1


      DNS
              Specifies the IP address of a Domain Name Server, which will 
              be consulted when trying to resolve hostnames which aren't in 
              DOMAIN.SYS. 
              You may use this keyword more than once to specify several DNS 
              servers if necessary, which will be consulted in the order they 
              are specified.  If no DNS servers are specified, resolution 
              will use DOMAIN.SYS only. An optional domain may be specified
              so that only addresses in that domain will be sent to that DNS

              Example: DNS=62.31.176.115 
                       DNS=44.131.244.1 .ampr.org.





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  129

      Configuration Files: XROUTER.CFG

      DOMAIN
              Other domains may be specified than the default .ampr.org.

      DXFLAGS
              If bit 1 is set, Bits 3 - 14 specify the minimum distance which will
              be logged, from 4Km to 32764Km in 8Km steps, e.g. DXFLAGS=502 enables
              DX logging, with threshold of 500Km. If bit 1 is not set, bits 3-14
              are ignored.
              If DX logging is enabled, any received APRS positions which exceed the
              threshold distance are logged to LOG\DXLOG.TXT
              if bit 2 is set, the frame contents are logged too.

              Example: DXFLAGS=0

      ECHOCOLOR
              See CONSOLE definition section.


      ENABLE_LINKED

              Specifies who, if anyone, may use the "*** LINKED AS" command.
              The default is "N" and the possible values are:

                     Y    Available to everyone.
                     A    Usable by applications only.    
                     N    Disabled entirely.

              Example: ENABLE_LINKED=A


      HIDENODES
              If this is set to 1, nodes whose alias begins with "#" will 
              not be displayed.

              Example: HIDENODES=1


      HOSTINTERRUPT
              Interrupt number to use for the BPQ-compatible host interface 

              The host interface may only be used in a Windows 95/98 or 
              Desqview environment. To use it you must load PZTHOST.EXE 
              before Windows then run XROUTER.EXE and each application 
              within separate dos windows.

              If you are not using host interface, comment this parameter 
              out, or set it to 0.

              Example: HOSTINTERRUPT=127


      HOSTNAME

              Host name for TCP (optional).  If you omit this, it will 
              default to "NODEALIAS:NODECALL".










      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  130

      Configuration Files: XROUTER.CFG


              Example: HOSTNAME=g8pzt.ampr.org

      HTTPPORT
              Allows HTTP port to be configured to any TCP port number

              Example: HTTPPORT=80

      HTTPROOT
              Allows the directory to be specified for HTTP server

              Example: HTTPROOT=C:\HTTP 

      IDINTERVAL
              The interval in minutes between broadcasts of IDTEXT.  Set to 
              0 to disable ID broadcasts.  Default is 15 minutes.

              Example: IDINTERVAL=29

      IDLETIME

              Idle link shutdown time in seconds (default=900).  A Netrom 
              link will be closed after this period of inactivity.

              Example: IDLETIME=300

      IDTEXT
              Specifies a one-line ID message to be sent every IDINTERVAL.

              If your APRS-format static position code is included, starting 
              within the first 40 characters, you will be visible on APRS 
              maps and the MHeard function will record distances to heard 
              stations.
              The format is "!ddmm.mmN/dddmm.mmE#" where dd represents 
              degrees of latitude/longitude and mm.mm represents minutes to 
              two decimal places. "N" and "E" may be replaced by "S" and "W" 
              as appropriate.  The end of text is marked by *** on a line by 
              itself.

              Example:
              IDTEXT
              !5224.00N/00215.00W# Kidderminster Router (KDRMIN)
              ***


      IGATE

              Controls whether or not the APRS Packet<>internet gateway is 
              started at boot-up.
              A zero value (default) doesn't start the IGATE (but it can be 
              started anytime using "start igate"), and a non-zero value 
              starts it immediately.  Leave this commented out, or set to 
              zero if you aren't running a gateway.

              Example: IGATE=1

      INFOTEXT

              Specifies one or more lines of text to be sent in response to 
              the plain 'I' command.  The end of text is marked by *** on a 
              line by itself.




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  131

      Configuration Files: XROUTER.CFG


              Note that you may create info "topics" which the user can 
              access using the "I <topic>" command.  Each topic should 
              occupy a separate, appropriately named file in a directory 
              named "INFO", and the filenames must have the extension ".INF"

              Example:
              INFOTEXT
              You are connected to part of the Kidderminster Packet Radio 
              Network, run on behalf of Fourpak by Paula G8PZT.

              For information on Fourpak, contact G4FPV @ GB7GLO, or see the 
              website at www.g8pzt.pwp.blueyonder.co.uk/fourpak/index.htm
              ***


      INTERFACE

              Begins an INTERFACE definition block.  The argument is a 
              number between 1 and 255 which identifies the interface in 
              subsequent PORT blocks.

              Example: INTERFACE=2


      IPADDRESS

              Specifies the router's IP address.  If you aren't routing IP, 
              comment this out or set it to 0.0.0.0

              The router normally uses a single IP address for all ports, 
              but you may specify additional addresses for each port.

              Example: IPADDRESS=44.131.91.4


      IPTTL

              IP "Time To Live" for datagrams originated by Xrouter.

              IPTTL overrides the default "Time To Live" (TTL) of 255.  This 
              is the maximum number of hops an IP datagram can make before 
              it is killed.

              A low value ensures that datagrams stuck in routing loops will 
              die quickly, but be aware that internet-routed packets may 
              easily make 20 or 30 hops, so don't set it too low.  Ignore 
              this if you haven't enabled IP routing.

              Example: IPTTL=100


      L3TTL

              Layer 3 "Time To Live" for NetRom packets originated by 
              Xrouter.

              This is the maximum number of NetRom systems a packet will 
              traverse before it is killed, and prevents packets from being 
              stuck in routing loops for ever.  Default is 25.





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  132

      Configuration Files: XROUTER.CFG


              Example: L3TTL=30


      L4DELAY

              NetRom Layer 4 delay.  This is the number of seconds to delay 
              a L4 ack in case further frames arrive (default = 3).

              10 secs is probably OK on normal AX25 networks, but is 
              excessive on wire links.  However, the system will attempt to 
              adjust this this value to cope with prevailing conditions.

              Example: L4DELAY=10


      L4RETRIES

              Netrom layer 4 retries (default = 3). 

              This is the number of consecutive L4 connect/disconnect or 
              re-transmission attempts which are allowed before the link is 
              abandoned.

              Example: L4RETRIES=3


      L4TIMEOUT

              Netrom layer 4 timeout.  This is the interval in seconds 
              between L4 retries and L4 connect/disconnect attempts.  

              Default is 120, and you are advised against setting this much 
              lower.

              Example: L4TIMEOUT=90


      L4WINDOW

              NetRom layer 4 window.  This is the number of unacknowledged 
              L4 frames allowed before we must stop to await an ack.  The 
              default is 10.

              Example: L4WINDOW=4


      LOG

              Controls activity logging.  Setting LOG to any number 1-255
              will log all connects, disconnects, user-entered commands and 
              chat server activity. 
              Setting LOG=0 (default) disables logging.

              Make sure you have enough disk space.  Not recommended for 
              long term use on floppy-based machines.  Can be overridden by 
              LOG command at the command line.

              Example: LOG=0






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  133

      Configuration Files: XROUTER.CFG


      LOWMEM
              Minimum free memory below which an automatic RESTART will take 
              place.  Default is 5000 bytes.  Use LOWMEM=0 to disable the 
              automatic restart.

      MAXARP
              Limits no. of stored ARP entries static and dynamic default 20

      MAXCIRCUITS

              Limits maximum permissable simultaneous circuits    default 20

      MAXSESSIONS

              Limits concurrent number of session of any type     default 20

      MAXROUTES

              Limits maximum number of netrom neighbours          default 30

      MAXTCP
              Limits maximum number of TCP/IP concurrent sessions default 20

      MAXHOPS
              Specifies the maximum acceptable hop count for nodes, as 
              another means of limiting the Time Domain network horizon (see 
              s)  It can be overridden for individual ports by using 
              MAXHOPS in the PORT definition block, or for individual routes 
              by using ROUTE ADD.  Default is 30 hops.

      MAXLINKS

              Maximum simultaneous AX25 level 2 links (default=30).  The 
              higher the value you specify, the less free memory will be 
              available.

      MAXNODES

              Maximum no. of nodes allowed in Netrom nodes table.  Default 
              is 200.  An excessive number of nodes has many disadvantages, 
              so you should be very careful if you choose to exceed this.

      MAXTT

              Specifies the maximum accepted trip time for nodes, to define 
              the Time Domain network horizon, like MINQUAL does for Quality 
              Domain.  It can be overridden for individual ports by using 
              MAXTT in the PORT definition, or for individual routes using 
              ROUTE ADD.  Default is 5000 (50 seconds).
              If set to 65535 it prevent the sending of of RTT measurement
              frames and allows the neighbour interlinks to time out.
 
      MIDWINBGCOLOR

              See CONSOLE definition section.

      MIDWINTXTCOLOR

              See CONSOLE definition section.





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  134

      Configuration Files: XROUTER.CFG

      MINQUAL

              Minimum node quality to add to node table (default = 10).
              This is the global value which will apply to all ports unless 
              overridden by a port minqual.

              Example: MINQUAL=10

      NODEALIAS *

              Node alias (6 characters max.).
              Aliases beginning with "#" are not displayed in node lists, 
              and are typically used for "linking only" nodes.

              You should preferably choose an alias which is geographically 
              relevant beyond your own local area, for example BRSTOL, 
              LEEDS, or BRUM are good, because users can recognise them in 
              node tables, whereas GAB1 and WBA are bad - where on earth are 
              they?

              Example: NODEALIAS=KDRMIN


      NODECALL *

              Node callsign. Up to 6 chars plus optional SSID between 1 and 
              15.

              This is the callsign used for all L3/4 operations, and the 
              default for L2 operations on each port.

              Example: NODECALL=G8PZT-6

      NODESINTERVAL

              Interval, in minutes, between NetRom nodes broadcasts.  
              Default is 60 mins.

              Example: NODESINTERVAL=30

      NUMCONSOLES

              Number of consoles (default = 3).

              You may have up to 5 "virtual" consoles, upon which the sysop 
              may conduct independent sessions.  

              Consoles are selected by using Alt-1 through alt-5, or the 
              left and right arrow keys.  Setting this to 0 disables all 
              console activity, saving memory and preventing the direct 
              screen writes which upset Desqview.

              Example: NUMCONSOLES=4

      OBSINIT

              NetRom obsolescence counter initial value (default = 5).

              The obsolescence counter is maintained for each neighbour in 
              the routes table, and is reset to the OBSINIT value whenever a 
              nodes broadcast is heard from the neighbour.




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  135

      Configuration Files: XROUTER.CFG


              Example: OBSINIT=5


      OBSMIN

              NetRom obsolescence count minimum to broadcast (default = 3).

              The obsolescence count (see above) for each NetRom neighbour 
              is decremented every NODESINTERVAL, and if it drops below 
              OBSMIN, the route is considered obsolete, and nodes learned 
              via that neighbour are no longer included in nodes broadcasts.

              Example: OBSMIN=3


      PACLEN

              Sets global default Paclen, i.e. the maximum length of the 
              information-bearing portion of an AX25 packet.

              The maximum is 256, and default is 120.  This may be 
              overridden on a port by port basis by PORT paclens.

              The choice of paclen depends on many factors such as the link 
              data rate, transmission and addressing overheads, link 
              contention and error rate etc.

              Small packets are less likely to be corrupted by errors or 
              QRM, but are inefficient when addressing or transmission 
              overheads (e.g. txdelay) are large.  Big packets are more 
              efficient, but are more likely to be lost if the link has 
              errors or QRM, and the re-transmissions will take longer.

              Example: PACLEN=180


      PMSALIAS

              Ax25/Netrom alias for integral PMS (Personal Message System).  

              This is required if the PMS is to be visible via NetRom.  It 
              must not be the same as any other alias or callsign used on 
              the system.

              Example: PMSALIAS=PZTPMS


      PMSCALL

              AX25 / NetRom callsign for integral PMS.

              This is required if the PMS is to be connectible via AX25 or 
              NetRom.  It must not be the same as any other callsign or 
              alias used on the system.

              Example: PMSCALL=G8PZT-2








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  136

      Configuration Files: XROUTER.CFG


      PMSQUAL

              PMS quality to include in Netrom nodes broadcast.

              Set this to 0 (default) to suppress L4 visibility.  You may 
              only use a non-zero value, if both PMSCALL and PMSALIAS are 
              defined.

              Example: PMSQUAL=50


      PORT

              Begins a PORT definition block.  The argument is the port 
              number, which must be between 1 and 32767 and not used by any 
              other port.

              Example: PORT=3


      QTH

              Station location. 32 characters maximum.

              Example: QTH=Kidderminster, Worcs.


      QUALADJUST

              Adjusts the quality of node entries according to callsign.

              Syntax: QUALADJUST <call | "default> <0-255>

              Examples:   QUALADJUST default 120
                          QUALADJUST G* 255

              See section entitled "Netrom Quality Manipulation".

          

























      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  137

      Configuration Files: XROUTER.CFG


              

      RXCOLOR

              See CONSOLE definition section.


      SAVER

              Screen saver interval in seconds. (0 = default = disable 
              screen saver)

              Example: SAVER=300


      SESSLIMIT

              Overall limit on no. of concurrent sessions per user, across 
              all ports.  You might like to restrict "troublesome" users 
              this way! Max setting = default = 255

              Example: SESSLIMIT=10


      T3

              Ax25 level 2 T3 timer (link check interval) in seconds. 
              (default = 180).  This is the period of inactivity after which 
              a poll frame is sent to test if the link is still open.

              Example: T3=150


      TOPWINBGCOLOR

              See CONSOLE definition section.


      TOPWINTXTCOLOR

              See CONSOLE definition section.


      TXCOLOR

              See CONSOLE definition section.


















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  138

      Configuration Files: XROUTER.CFG


      WATCHADDR

              Address (hex) of parallel port used to drive hardware 
              watchdog.

              If you set a valid parallel port address here, the least 
              significant data bit of the port will be toggled several times 
              per second if the router is working correctly.

              You can use external circuitry to detect if the output stops 
              toggling for more than a few seconds, and use it to reboot the 
              computer.  Note that your circuit must look for an AC signal, 
              because the output could lock up high or low if the computer 
              crashes.

              Example: WATCHADDR=378


      WATCHDOG

              Software Watchdog timeout in seconds.

              If you set a non-zero value here, the router will attempt to 
              reboot if the code goes into an endless loop.

              Note: the watchdog keeps running if you shell to DOS using 
              Alt-F9, so keep shell sessions short or the router will think 
              you've forgotten to return and will reboot!

              Example: WATCHDOG=120


































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  139

      Configuration Files: XROUTER.CFG


      Console Definition Keywords
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The following keywords can be used within a CONSOLE definition block 
      (* = mandatory):

      BOTWINBGCOLOR

              Background colour for the bottom window, i.e. the menu bar. 
              Default = CYAN. 

              Example: BOTWINBGCOLOR=GREEN


      BOTWINTXTCOLOR

              Text colour for the bottom window, i.e. the menu bar.  Default 
              is BLACK.


      CMDWINBGCOLOR

              Background colour for the command line, i.e. where the console 
              commands are entered.  Default is BLUE.


      CMDWINTXTCOLOR

              Text colour for the command line.  Default is YELLOW.


      CONSOLECALL

              Callsign for console operations.  You can set this 
              independently of NODECALL or you may set them the same.  You 
              may at any time override this callsign using the "linked as" 
              command.

              Example: CONSOLECALL=G8PZT


      ECHOCOLOR

              Colour used for echoing sysop's commands to main window.  
              Default is YELLOW.


      ENDCONSOLE *

              Ends a console definition block.  Mandatory.


      MIDWINBGCOLOR

              Background colour for the main window.  Default is BLACK.










      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  140

      Configuration Files: XROUTER.CFG


      MIDWINTXTCOLOR

              Text colour for the main window.  Default is WHITE.


      MPORTS

              Default ports to monitor on this console.  See MPORT command 
              in sysop command section for details of the argument format.


      MMASK

              Default monitor (trace) mask for this port.  See sysop command 
              section for more details.


      RXCOLOR

              Text colour for displaying received data.  Default is GREEN.


      TOPWINBGCOLOR

              Background colour for the top window, i.e. the status bar.  
              Default is CYAN.


      TOPWINTXTCOLOR

              Text colour for the top window, i.e. the status bar.  Default 
              is BLACK.


      TXCOLOR

              Text colour for displaying transmitted data.  Default is RED.


      Console Text / Background Colours
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Permissible TEXT Colours are:

              BLACK, NAVY, GREEN, CYAN,     RED, MAGENTA, BROWN, SILVER,
              GREY,  BLUE, LIME, TURQUOISE, PINK, CERISE, YELLOW, WHITE

      Permissible BACKGROUND colours are:

              BLACK, NAVY, GREEN, CYAN, RED, MAGENTA, BROWN, SILVER















      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  141

      Configuration Files: XROUTER.CFG


      Interface Definition Keywords
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The following keywords may be used within INTERFACE definition 
      blocks (* = mandatory):

      CHANNEL

              Used for SCC cards only.  This is the physical channel or port 
              on the card (A, B, C or D).  You may use CHANNEL=A etc. or 
              COM=1 etc. but not both.


      COM

              Com number (1 - 16), used by ASYNC, YAM and SCC types only. 

              COM is mandatory for ASYNC interfaces.  Mandatory for YAM 
              interfaces only if IOADDR and INTNUM are not specified.  For 
              SCC cards, you may use COM=1 etc. instead of CHANNEL=A etc.


      ENDINTERFACE *

              Marks the end of the INTERFACE definition block. Subsequent 
              keywords will be treated as GLOBAL.


      ETHADDR

              Ethernet address in form xx:xx:xx:xx:xx:xx, used only for 
              Ethernet interfaces.  You shouldn't need this because Xrouter 
              will read the address from the card.


      FLOW

              Flow control options (ASYNC interfaces only):

                     0 = No flow control
                     1 = Hardware (RTS/CTS) flow control
                     2 = Software (XON/XOFF) flow control (TTY link only)
                     3 = Hardware AND software flow control

              If not specified, flow control defaults to NONE.
              Don't use Xon/Xoff with KISS.


      INTNUM

              Hardware or software interrupt number in decimal.
              For ASYNC interfaces, intnum is optional for com 1 - 4.
              For SCC cards, use same INTNUM for all channels on card.












      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  142

      Configuration Files: XROUTER.CFG


      IOADDR

              Hardware device I/O address in hex, e.g. UART base register 
              address.
              For ASYNC interfaces, IOADDR is optional for com 1 - 4.
              For SCC cards, use same IOADDR for all channels on card.


      KISSOPTIONS

              Options for KISS interfaces only:

                NONE     - Plain KISS (most TNC's use this) (default)
                POLLED   - For TNCs which send only when polled.
                CHECKSUM - Packets protected by checksum.  You can
                           only use this option if your TNC supports it.
                ACKMODE  - For TNC's which inform the router when a
                           frame has been transmitted on air.
                SLAVE    - Router will act like a polled KISS TNC,
                           sending only when commanded to do so.

              Polled and slave are mutually exclusive.
              BPQKISS eproms require POLLED and CHECKSUM, and
              their use of ackmode is optional.


      MTU *

              Maximum Transmission Unit.  This specifies the maximum size of 
              the data portion of an IP packet.

              Setting MTU over 256 will crash most BPQ nodes, or at the 
              very least cause the packet to be lost.  Xrouter can handle 
              frames up to 1500 bytes, but BPQKISS TNC's are limited by 340 
              byte buffers.  Received IP datagrams larger than MTU are 
              fragmented to suit the outgoing link MTU.


      PROTOCOL

              Protocol to use on the interface:

                     NONE     - Use this with type=loopback
                     ASCII    - Remote consoles (TTY) via ASYNC ports
                     SLIP     - For TCP/IP over RS232 or EXTERNAL interface
                     PPP      - For TCP/IP over RS232
                     KISS     - For driving KISS TNCs or wired links.
                     MODEM    - Hayes compatible PSTN modem.
                     NETROM   - Netrom backend serial link.
                     ETHER    - Ethernet (requires ETHDRV.EXE)
                     TNC2     - TNC2 emulation.
                     HDLC     - For use with SCC cards, YAM modem,
                                INTERNAL interfaces, and some EXTERNAL
                                drivers.










      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  143

      Configuration Files: XROUTER.CFG


      SPEED

              The serial port baud rate for ASYNC interfaces, or the radio 
              baud rate for HDLC cards.  50-115200 bauds (Decimal). Don't 
              include a comma.  If set to zero (HDLC cards only), the modem 
              must supply a x1 clock (TXC on RTXC pin, RXC on TRXC pin).


      TYPE *

              Interface type as follows:

                     ASYNC          Serial port
                     LOOPBACK       For test purposes
                     EXTERNAL       User supplied driver (as BPQ)
                     BAYCOM         Baycom USCC card.
                     RLC100         Thorcom RLC100 scc card.
                     DRSI           DRSI scc card
                     PC100          Pac-comm PC100/120 scc card
                     PC120          4 port PC100 scc card.
                     PA0HZP         PA0HZP opto-scc card
                     AXIP           For AX25 over IP wormhole
                     AXUDP          For AX25 over UDP wormhole
                     INTERNAL       For HDLC applications.
                     ITACARD        Yet another SCC card.
                     YAM            YAM 1200/2400/9600 modem






































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  144

      Configuration Files: XROUTER.CFG


      Port Definition Keywords
      ~~~~~~~~~~~~~~~~~~~~~~~~
      The following keywords are used within PORT definition blocks (* = 
      mandatory):

      APPLMASK

              The APPLMASK parameter is used only if you are running 
              applications via the host interface.  It specifies which 
              applications will be directly connectible on this port.

              The default is 255, which allows all applications.  The value 
              is made up by adding together the following numbers:

                   1    - Enable Application 1
                   2    - Enable Application 2
                   4    - Enable Application 3
                   8    - Enable Application 4
                   16   - Enable Application 5
                   32   - Enable Application 6
                   64   - Enable Application 7
                   128  - Enable Application 8

              If you want an application to be directly connectible on a 
              port, it must have a callsign, an alias or both, and the 
              corresponding bit in that port's applmask must be set.

              Example: APPLMASK=5   (enable applications 1 and 3)


      APRSPATH

              APRSPATH specifies the default digipeater path for APRS frames 
              originated by APRS messaging shell and Igate.  If you omit 
              this, the frames will be sent without any digipeaters.  
              Messaging shell users may override this path.

              Example: APRSPATH=RELAY


      BCAST

              BCAST specifies a list of destinations for "broadcasting".  
              Received non-digipeater UI frames, addressed to one of these 
              destinations, will be re-broadcasted on all ports which have a 
              matching address in their BCAST list, e.g. to broadcast mail 
              beacons from a BBS on one port onto several other ports.

              The callsigns must be separated by commas and there should be 
              no spaces in the list.

              Example: BCAST=MAIL,ALL


      BCFROM

              BCFROM is used to specify a list of callsigns who may use the 
              broadcast facility (see BCAST).






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  145

      Configuration Files: XROUTER.CFG


              If you wish to restrict the broadcast facility to certain 
              senders only, list the callsigns here.  If no calls are 
              specified, the facility is unrestricted.  Separate the calls 
              by commas, and don't include any spaces in the list.

              Example: BCFROM=GB7PZT,GB7MAX


      CFLAGS

              CFLAGS allows level 2 uplinking and/or downlinking to be 
              prevented, e.g. on APRS-only ports.  Use VERY carefully! 
              Default is 3.  Sysop can always downlink.  Add together the 
              desired options from this list:

                     1   - Allow incoming connections (uplinks)
                     2   - Allow outgoing connections (downlinks)
                     4   - Allows applications to downlink unconditionally
                     8   - Prevents L3RTT frames from being sent (stops INP3)
                     16  - Allows Level2 fragmentation  


      CHANNEL

              Specifies which channel (A to P) on the interface will be used 
              by this port.  The default is "A".

              Example: CHANNEL=C


      CWID

              CWID is used only by SCC ports.  It specifies a callsign (8 
              characters max.) which will be sent every 30 minutes using 
              Morse code.  If omitted, no cwid is sent.

              Example: CWID=G8PZT


      DHCP

              The DHCP keyword specifies whether or not the port IP address
              will be obtained dynamically using DHCP (DHCP=1) or specified
              statically (DHCP=0).  Default is 0.


      DIGIFLAG

              Digipeater control flag.  0=no digipeat.  Default=7
              Add together required options from this list:

                   1    Digipeat UI frames
                   2    Digipeat non-UI frames
                   4    Enable RELAY generic APRS digipeating
                   8    Enable TRACE and TRACEn-N APRS digipeating.
                   16   Enable WIDE and WIDEn-N (Well sited stations only!)
                   32   Enable L4 APRS tunnelling
                   64   Enable frames from RF to Igate
                   128  Enable frames from Igate to RF





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  146

      Configuration Files: XROUTER.CFG


              Example: DIGIFLAG=5        ; all UI + RELAY generic.


      DIGIPORT

              Specifies the port on which digipeated frames will be 
              transmitted.  Default is 0, i.e. this port.

              Example: DIGIPORT=3   ; Digipeat onto port 3


      ENDPORT *

              Marks the end of the PORT definition block. Subsequent 
              keywords will be interpreted as GLOBAL.


      EXCLUDE

              EXCLUDE specifies a list of one or more callsigns from whom 
              AX25 L2 frames will be ignored.

              It would typically be used on a user-access port to prevent 
              connections from trouble-makers and pirates.  Separate 
              callsigns with commas, and don't include any spaces.

              Example: EXCLUDE=NOCALL,P1RAT     ; Ignore these users


      FRACK

              AX25 "T1" timer, i.e. frame acknowledgement time, in 
              milliseconds.  Default is 7000.

              After sending an AX25 packet, this is the amount of time 
              Xrouter will wait for an "ack" before considering the packet 
              to be lost.

              The T1 timer starts when the link layer dispatches the packet 
              to the MAC (Media Access Control) layer, so you must allow 
              at least enough time for (MAXFRAME * PACLEN) packets to be 
              sent, plus an ack packet to be received, plus the other end's 
              RESPTIME, plus both end's TXDELAYs, plus a generous allowance 
              for channel congestion.

              I strongly recommend a frack no less than 7000 millisecs for 
              average 1200 baud links.

              Example: FRACK=7000     ; 7 seconds


      FULLDUP

              If you set FULLDUP=1, Xrouter will transmit whenever it needs 
              to, without waiting for the other end to stop.

              Used only by hardware which is capable of simultaneous 
              transmission and reception, such as full duplex radio or wire 
              links.  Default is 0 (simplex / half duplex).





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  147

      Configuration Files: XROUTER.CFG


              Example: FULLDUP=1    ; Full duplex


      ID *

              Mandatory text string to identify port on "PORTS" display.  
              May contain spaces.  Please make it informative.

              Example: ID=144.825 MHz 9k6 TCP/IP users


      IDPATH

              Specifies the destination and digipeater path for ID beacons.

              The default AX25 destination and path is "ID" with no 
              digipeaters.  You may wish to modify this, for example on APRS 
              ports, to digipeat your beacon.

              Example: IDPATH=APRS,RELAY,WIDE


      IDTEXT

              Optional ID text to use, instead of global IDTEXT, on this 
              port only (e.g. for APRS ports).

              Only one line of text (248 characters max.) may be specified.

              Example: IDTEXT=!5224.00N/00215.00W# (Kidder)


      INITSTR

              Modem initialisation string (MODEM ports only).  This is a 
              string of characters which will be sent to the modem when 
              Xrouter is started.

              Example: INITSTR=ATM0


      INTERFACENUM *

              Number of the interface this port is attached to.


      INTERLOCK

              Interlock is only used by SCC cards, because KISS TNC's make 
              their own decisions about when to transmit, and Xrouter has no 
              control over that process.

              If a non-zero INTERLOCK value is specified, no two ports with 
              the same value will transmit at the same time.  Default=0.

              Example: INTERLOCK=4








 148      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  148

      Configuration Files: XROUTER.CFG


      IPADDRESS

              IP address for use on this port.  If this is specified, it 
              will be used instead of the global IP address for all TCP/IP 
              operations on this port.

              Example: IPADDRESS=44.131.91.5


      IPLINK

              IP address of AXIP or AXUDP link partner (AXIP and AXUDP ports 
              only).

              Example: IPLINK=44.33.22.11

      MAXFRAME

              Specifies the maximum number of frames Xrouter will send 
              to an AX25 partner before it must wait for an ack.

              Normal AX25 allows up to maxframe=7, but if you set a value 
              between 8 and 63 Xrouter will attempt to use Modulo-128 
              (Extended AX25) on outgoing links.

              If the port PACLEN is set to 0, Xrouter will dynamically adapt 
              MAXFRAME (and PACLEN) to the link conditions, to maximise 
              throughput.

              The default value of MAXFRAME is 3.


      MAXHOPS

              Specifies the default maximum hops for all neighbour 
              routes learned on this port.  It can be overridden for 
              individual routes by 'locking in' the route in 
              BOOTCMDS.SYS or by a ROUTE ADD command in the XRNODES 
              file or at the command prompt.
  
              Defaults to global MAXHOPS.



      MAXTT

              Specifies the default maximum trip time for all neighbour 
              routes learned on this port.  It can be overridden for 
              individual routes by "locking-in" the route in 
              BOOTCMDS.SYS, or by a ROUTE ADD command in the XRNODES 
              file or at the command prompt. 
 
              If set to 65535 will stop level 2 interlinks between 
              netrom neighbours being held open.
 
              Defaults to global MAXTT.








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  149

      Configuration Files: XROUTER.CFG


      MHEARD

              Enable/disable the MHEARD function on this port.

              The number specifies how many callsigns to maintain in the 
              list. Set to 0 to disable MHEARD.  Default is 15 calls.

              Example: MHEARD=10    ; Mheard enabled, 10 calls


      MHFLAGS

              MHFLAGS controls which callsigns are recorded in the MH list, 
              and defaults to 255 (show everything).

              The argument is the sum of the required options from this 
              list:

                     1    Show directly heard stations
                     2    Show directly heard digipeaters
                     4    Show digipeated stations

              Example: MHFLAGS=1      ; show directly heard stations only


      MINQUAL

              Minimum quality to add to node table for nodes received via 
              this port.  Defaults to global MINQUAL.

              If specified, this overrides the global minqual, and can be 
              used to exclude unreachable and marginal nodes.

              Example: MINQUAL=10


      MINTXQUAL

              Minimum node quality to include in broadcasts on this port.  
              Range 0 to 255, Default is 0. 
              This is used to limit the size of nodes broadcasts on ports 
              which are low bandwidth, low quality, or where the neighbours 
              have limited nodes table capacity.



      NODESINTERVAL

              Interval, in minutes, between NetRom nodes broadcasts on this 
              port only.  Defaults to global NODESINTERVAL.

              Whilst the Netrom network usually works on a 60 minute 
              broadcast cycle, some types of software insist on a much 
              smaller broadcast interval.

              It would be harmful to the established network if sysops tried 
              to accommodate these neighbours by setting the global 
              NODESINTERVAL to a smaller value, but using this keyword on a 
              per-port basis you can keep these neighbours happy without 
              disrupting the rest of the Netrom network.




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  150

      Configuration Files: XROUTER.CFG



              If you set NODESINTERVAL=0, Xrouter will ignore received nodes 
              broadcasts on this port, but will allow L3/L4 activity if 
              QUALITY is non-zero.

              Example: NODESINTERVAL=10


      PACLEN

              Specifies the maximum length of the information-bearing 
              portion of ax25 packets transmitted on this port only.

              If not specified, it defaults to the global PACLEN.  See 
              global paclen for more details.

              If the port PACLEN is set to 0, Xrouter will dynamically adapt 
              PACLEN (and MAXFRAME) to the link conditions, to maximise 
              throughput.

              Example: PACLEN=160   ; Allow 160 byte packets on this port


      PERSIST

              PERSIST is the AX25 "Probability to transmit" in a given time 
              slot (see SLOTTIME), used to minimise media contention.

              Persist should be set to (255 / (no. of users on channel)), 
              e.g. for a channel with an average of 10 users on at any one 
              time you would set Persist to 25. Default is 64.

              Example: PERSIST=85     ; Average 3 users 


      PIPE

              PIPE allows frames received (and optionally sent) on this port 
              to be copied to another port, e.g. to allow a PMS on one port 
              to see the traffic on another port.

              Unless the "bi-directional" option (see below) is specified, 
              pipes are one way.  In order to have two way traffic using a 
              uni-directional pipe, you must set up a reverse pipe on the 
              opposite port.

              You may pipe several ports to a single destination port, but 
              you can only have one *outgoing* pipe from any port.

              Pipes are capable of generating an immense amount of traffic, 
              so use them with care - your target port MUST be capable of 
              handling the traffic load.

              Pipes can be made "selective", by adding a comma-delimited 
              callsign list, e.g. "PIPE=4 GB7PZT,KDRBBS".  This will reduce 
              the loading on the target port, by piping only the frames with 
              the specified calls in the destination field.







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  151

      Configuration Files: XROUTER.CFG


              Pipes can be made "bi-directional" by adding 512 to the 
              PIPEFLAG value (see below: suggested value = 515).  If a frame 
              is piped on a bi-directional pipe, the source call is 
              remembered so that responses will be piped back to the sender.  
              Thus a reverse pipe is not needed.

              Bi-directional pipes are useful where a BBS has a front end 
              router - simply set up bi-directional selective pipes from 
              each user port to the BBS port, and set up the BCAST option so 
              that the UI mail headers are broadcast on each user port.  The 
              BBS will then allow direct connect and will respond to resync 
              requests.

              To disable piping, set PIPE=0 or just omit the command.

              Example: PIPE=2       ; Pipe frames from this port to port 2


      PIPEFLAG

              PIPEFLAG is only used when piping is active, and controls 
              which frames are piped.  The default is 3.  

              The argument is the sum of the required options as follows:

              1    - UI frames *not* addressed to nodecall/alias.
              2    - Non-UI frames *not* addressed to nodecall/alias.
              4    - UI frames addressed to nodecall/alias.
              8    - Non-UI frames addressed to nodecall/alias.
              16   - UI frames transmitted by us.
              32   - Non-UI frames transmitted by us.
              64   - Allow budlisted users to be piped.
              128  - Netrom frames
              256  - IP / ARP frames
              512  - Bi-directional piping

              Example: PIPEFLAG=5   ; Pipe received UI frames only


      PORTALIAS

              Specifies an AX25 alias for this port, to be used in addition 
              to the NODEALIAS.

              Example:  PORTALIAS=KDRMIN


      PORTALIAS2

              Yet another PORTALIAS (see above).


      PORTCALL

              Specifies an AX25 callsign to use on this port, in addition to 
              the NODECALL.

              Example: PORTCALL=G8PZT-1






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  152

      Configuration Files: XROUTER.CFG


      PROXY

              Remote NET/ROM systems to whom we will tunnel L2 frames.
              (See PROXY section of manual for full explanation)

              Example: PROXY=GB7PZT,GB7BBS


      QUALADJUST

              Qualadjust is accepted, but doesn't do anything.  I may remove 
              it at some time in future.


      QUALITY

              Default quality for nodes whose broadcasts are received on 
              this port (default=10).  Setting this to 0 disables all L3/4 
              activity on this port.

              Example: QUALITY=30


      RESPTIME

              AX25 "T2" (delayed ack) timer in milliseconds, i.e. the time 
              to wait after receiving a frame before sending an ack.

              This allows multi-frame transmissions to be acknowledged with 
              a single ack, increasing link efficiency.

              Resptime should be long enough for a link partner to transmit 
              a full-sized information frame, i.e. approximately
              ((their_paclen * 10000) / RFbauds) millisecs, otherwise you 
              will send unnecessary ack frames.

              1500 (default) is OK for 1200 bauds with paclen=120, but 
              2200 would be more appropriate if their paclen was 256.

              Example: RESPTIME=2000          ; 2 seconds


      RETRIES

              AX25 maximum consecutive connect / disconnect / resend 
              attempts before giving up (default = 10).

              I can't see any point in setting retries more than 10, other 
              than for test purposes.  If you need so many retries it's a 
              useless link and you're just wasting everyone else's airtime.  
              The higher you set this value, the longer users will have to 
              wait to get a "failure with" for a non-contactable 
              destination.

              Example: RETRIES=5









      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  153

      Configuration Files: XROUTER.CFG


      RFBAUDS

              RF baud rate (default = 1200).

              This parameter is used with "real" tnc's and YAM modems 
              attached via RS232, because the RF baud rate is usually 
              different to the RS232 baud rate.  It simply helps Xrouter 
              make timing decisions (such as nodes broadcast inter-packet 
              timing and TCP window) and report certain stats correctly.

              Example: RFBAUDS=2400


      SESSLIMIT

              Sesslimit specifies the maximum simultaneous connects each 
              user is allowed on this port.  Default is 255.

              Example: SESSLIMIT=5


      SLOTTIME

              CSMA interval timer (millisecs), used with PERSIST to make 
              channel access decisions (default=100).

              If the channel is clear, the TNC (or SCC/YAM card) will 
              generate a random number which is then compared with the 
              PERSIST value.  If it is less than PERSIST, the TNC will wait 
              for the SLOTTIME interval, then repeat the action, otherwise 
              it will transmit immediately.

              This improves throughput by ensuring that everyone doesn't 
              transmit as soon as the channel is clear, which would cause 
              collisions and retries.

              Example: SLOTTIME=100


      SOFTDCD

              Softdcd is used only by SCC cards and defaults to 0.

              If SOFTDCD=1 the real dcd will be ignored, and the SCC driver 
              will use the presence of HDLC data as a DCD indication.

              Using SOFTDCD=1 with an open squelch generates a *huge* 
              interrupt loading, which may cause degradation of performance, 
              depending on the PC type, so I don't recommend it.

              Example: SOFTDCD=0


      SYSOP

              If you set SYSOP=1, all users who connect on this port will 
              get full sysop status without answering a password challenge.  







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  154

      Configuration Files: XROUTER.CFG


              This is intended ONLY FOR USE ON SECURE LINKS, such as RS232 
              or Ethernet, and the default is zero.


      TXDELAY

              Transmit keyup delay in milliseconds (default=300).

              After keying the transmitter, the TNC (or SCC /  YAM card) 
              will wait for this interval before sending HDLC data.  This 
              allows the TX to stabilise and the partner's squelch to open.

              Example: TXDELAY=500       ; Synthesiser is slow to lock


      TXPORT

              Port to transmit on (default = 0 = this port).

              You would typically use this when several ports share a single 
              transmitter, with separate receivers.

              Example: TXPORT=5     ; Transmit on port 5


      TXTAIL

              TX keydown delay in milliseconds (default = 30).

              This is the interval, after sending a frame, for which the 
              transmitter remains active.  It is intended to allow CRC and 
              closing flags to be sent.

              Due to PC timing inaccuracies, you should set this no lower 
              than 100 for SCC cards!

              Example: TXTAIL=100


      UDPLOCAL

              UDPLOCAL is the UDP port number for the local end of an AXUDP 
              link.  Used only by AXUDP ports.  Default is 93

              Example: UDPLOCAL=7388


      UDPREMOTE

              UDPREMOTE is the UDP port number for the remote end of an 
              AXUDP link.  Used only by AXUDP ports. Default is 93.


      UNPROTO

              Destination callsign and optional digipeater string used for 
              unproto broadcasts from applications on this port.  Separate 
              the callsigns with commas.

              Example: UNPROTO=CQ,G6YAK




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  155

      Configuration Files: XROUTER.CFG




      USERS

              Maximum no. of simultaneous users on this port. Default is 255 
              which means "no limit".

              Example: USERS=9


      VALIDCALLS

              Validcalls allows AX25 frames only from the specified 
              callsigns (opposite of BUDLIST), and is typically used to 
              prevent users from connecting to link-only ports.

              Example: VALIDCALLS=G6YAK,G6AMU ; Accept only these users















































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  156

      Configuration Files: XROUTER.CFG


      Application Configuration Keywords
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The following keywords can be used within APPL definition blocks (* = 
      mandatory):


      APPLALIAS

              Specifies an ax25 and NetRom alias for the application.  It 
              is required if the application is to be visible to Netrom.
              AX25 connects are allowed subject to the port APPLMASK 
              parameter (see PORT keyword section).

              Example: APPLALIAS=PZTBBS

      APPLCALL

              Specifies callsign for the application, allowing ax25/NetRom 
              callers to connect directly to it.

              AX25 connects are allowed subject to the port APPLMASK 
              parameter (see PORT keyword section).  APPLCALL is required if 
              the application is to be NetRom visible.

              Example: APPLCALL=GB7PZT
       
      APPLFLAGS
              
              1    Applications granted Sysop privileges 
                   (needs PZTHOST.EXE v1.60)
              2    Allows guest users to type APPLNAME at command line

      APPLNAME

              The name by which the application is accessed from the 
              router's command line. e.g. "BBS".  If a user types this name, 
              they will be connected to the application.

              Example: APPLNAME=BBS

      APPLQUAL

              Netrom quality to broadcast (0-255) for this application.  
              Default is global APPLQUAL.
              If a non-zero value is specified, and *both* APPLCALL and 
              APPLALIAS are defined, they will be included in nodes 
              broadcasts and the application will be connectible at level 4.

              Example: APPLQUAL=150

      ENDAPPL *

              Marks the end of the APPL definition block. Subsequent 
              keywords will be treated as GLOBAL.










      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  157

      Configuration Files: XROUTER.CFG


      ; XROUTER.CFG  Configuration file for Xrouter version 1.86
      ; ========================================================
      ;
      ; The XROUTER.EXE program reads this file only when it starts.
      ;
      ; Keywords can be in almost any order, but interfaces MUST be defined
      ; before ports.
      ;
      ; Note some timings are in millisecs, some are secs.
      ;
      ; Blank lines are allowed.  Comment lines must begin with semicolon in
      ; the leftmost column.  Lines must not exceed 255 characters in length.
      ;
      ; This is a sample, to illustrate all the options and typical settings.
      ; You *must* edit it to your requirements!  I suggest you de-activate
      ; the bits you don't need by putting semicolons at the beginning of
      ; the lines.
      ;-------------------------------------------------------------------
      ;
      ;	Interrupt number to use for the BPQ-compatible host interface.
      ;	The host interface may only be used in a Windows 95/98 or Desqview
      ;	environment. To use it you must load PZTHOST.EXE before Windows
      ;	then run XROUTER.EXE and each application within separate dos
      ;	windows.
      ;	If you are not using host interface, comment this parameter out,
      ;	or set it to 0.
      ;
      ;HOSTINTERRUPT=127
      ;
      ;	DESQVIEW specifies whether or not Xrouter is running in a
      ;	Desqview environment, and must be set to 1 if Desqview is used.
      ;	The default is 0.
      ;
      ;DESQVIEW=1
      ;
      ;	LOWMEM specifies a minimum free memory, below which Xrouter will
      ;	automatically restart.  Default is 0 (auto-restart disabled)
      ;
      ;LOWMEM=5000
      ;
      ;	Station Identification:
      ;	~~~~~~~~~~~~~~~~~~~~~~~
      ;
      ;	Node callsign: Up to 6 chars plus optional SSID between 1 and 15
      ;	This is the callsign used for all L3/4 operations, and the default
      ;	for L2 operations on each port.
      ;
      ;NODECALL=G8PZT-2
      ;
      ;	Node alias: Up to 6 characters.
      ;	Aliases beginning with "#" are not displayed in node lists, and
      ;	are typically used for "linking only" nodes.
      ;	You should preferably choose an alias which is geographically
      ;	relevant beyond your own local area, for example BRSTOL, LEEDS,
      ;	or BRUM are good, because users can recognise them in node tables,
      ;	whereas GAB1 and WBA are bad - where on earth are they?
      ;
      ;NODEALIAS=KDRMIN
      ;





      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  158

      Configuration Files: XROUTER.CFG

      ;	Callsign for APRS IGATE (optional).
      ;	This callsign is used by the Igate to identify itself in beacons
      ;	and third party messages.  If omitted, it defaults to Nodecall.
      ;
      ;APRSCALL=MB7Uxx
      ;
      ;	Callsign for console operations.  You can set this independantly
      ;	of NODECALL or you may set them the same.  You may at any time
      ;	override this callsign using the "linked as" command.
      ;
      ;CONSOLECALL=G8PZT
      ;
      ;	IP address for IP routing.  Your local IP co-ordinator should
      ;	be able to assign you one.  If you aren't routing IP (shame on
      ;	you!) comment this out or set it to 0.0.0.0
      ;	The router normally uses a single IP address for all ports, but
      ;	you may specify additional addresses for each port.
      ;	(If you are routing, remember to define routes and hostnames in
      ;	IPROUTE.SYS and DOMAIN.SYS respectively)
      ;
      ;IPADDRESS=44.131.91.4
      ;
      ; 	IP address of primary Domain Name Server, which will be consulted
      ;	when trying to resolve hostnames which aren't in DOMAIN.SYS
      ;	If not specified, resolution will use DOMAIN.SYS only.
      ;	domain may additionally be specified to allow different domains
      ;	to be resolved by different DNS
      ;
      ;DNS=62.31.176.115 ampr.org
      ;
      ;	Allow different DOMAIN suffix to be specified       ;	defaults to 
      ;	ampr.org (last dot important)
      ;
      ;DOMAIN=ampr.org.
      ;
      ;	The web server root directory is specified using the HTTPROOT 
      ;	directive in Xrouter.cfg, e.g. "HTTPROOT=C:\WEB".  If you omit 
      ;	this directive, the default will be a directory called "HTTP" 
      ;	within the xrouter directory.  For security reasons it is important 
      ;	that you don't use the Xrouter directory as the HTTP root!
      ;
      ;HTTPROOT=C:\HTTP
      ;
      ;	The HTTP port can be configured to be on any TCP port number
      ;
      ;HTTPPORT=80
      ;
      ;	Host name for TCP (optional).  If you omit this, it will default
      ;	to "NODEALIAS:NODECALL".
      ;
      ;HOSTNAME=g8pzt.ampr.org
      ;
      ;
      ;	Chat server callsign. This may be the same as the nodecall, but
      ;	must use a different SSID, otherwise the chat server will not
      ;	be directly connectable.
      ;
      ;CHATCALL=G8PZT-8
      ;






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  159

      Configuration Files: XROUTER.CFG

      ;	Alias for chat server (6 chars max).  I suggest this should end
      ;	with "CHT" and begin with something geographically relevant,
      ;	e.g. BHMCHT for Birmingham, LDSCHT for Leeds etc., so it can be
      ;	easily identified in node tables. If you specify the NODEALIAS
      ;	here, the chat server will not be directly connectible.
      ;
      ;CHATALIAS=KDRCHT
      ;
      ;	List of chat servers to which this server will link.  You must
      ;	supply the *callsigns* not the aliases.  Unilateral links are not
      ;	allowed - each partner in this list must place your CHATCALL in
      ;	their CHATLINKS list.  You may only use partners who are in your
      ;	node tables.  PZT chat servers may be interconnected with each
      ;	other, but *NOT* with "Ping-Pong Converse" servers.  Don't link
      ;	with distant servers - if the links are too slow your users will
      ;	get poor service. You may disable all outgoing and incoming
      ;	linking by omitting this line (or commenting it out).
      ;
      ;CHATLINKS=G9XOT-8,G7DTY-8
      ;
      ;	Chatcall quality to broadcast.  This can be used to limit the
      ;	visibility of your server to a reasonable geographical area,
      ;	and discourage chat server "dxing". Default is 255, i.e. chat
      ;	call is visible over same distance as nodecall.
      ;
      ;CHATQUAL=150
      ;
      ;	Callsign and alias of integral PMS.  If you define neither, the
      ;	PMS will only be accessible using the "PMS" command.
      ;
      ;PMSCALL=G8PZT-2
      ;
      ;PMSALIAS=PZTPMS
      ;
      ;	PMS quality to include in Netrom nodes broadcast.
      ;	Set this to 0 to suppress L4 visibility.
      ;	You may only use a non-zero value, if both PMSCALL and PMSALIAS
      ;	are defined.
      ;
      ;PMSQUAL=50
      ;
      ;	Station location (32 chars max).
      ;
      ;QTH=Kidderminster, Worc's
      ;
      ;	IGATE controls whether or not the APRS Packet<>internet gateway
      ;	is started at boot-up. A zero value (default) doesn't start the
      ;	igate (but it can be started anytime using "start igate"), and
      ;	a non-zero value starts it immediately.
      ;	Leave this commented out, or set to zero if you aren't running
      ;	a gateway.
      ;
      ;IGATE=1
      ;











      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  160

      Configuration Files: XROUTER.CFG

      ;	Optional Software Watchdog.  If you set a non-zero value here,
      ;	the router will attempt to reboot if the code goes into an
      ;	endless loop.  The value is in seconds.  Note: the watchdog
      ;	keeps running if you shell to DOS using Alt-F9, so keep shell
      ;	sessions short or the router will think you've forgotten to
      ;	return and will reboot!
      ;
      ;WATCHDOG=120
      ;
      ;	Address (hex) of parallel port used to drive hardware watchdog.
      ;	If you set a valid address here, the least significant data bit
      ;	of the port will be toggled several times per second if the router
      ;	is working correctly.  You can use external circuitry to detect
      ;	if the output stops toggling for more than a few seconds, and use
      ;	it to reboot the computer.  Note that your circuit must look for
      ;	an AC signal, because the output could lock up high or low if
      ;	the computer crashes.
      ;
      ;WATCHADDR=378
      ;
      ;	Address (hex) of parallel port used for controlling / monitoring
      ;	external hardware.  If this is the same as WATCHADDR, only the
      ;	most significant 7 bits will be available for control if the
      ;	hardware watchdog is enabled.
      ;
      ;CTRLADDR=378
      ;
      ;	IPTTL overrides the default "Time To Live" (TTL) of 255.  This
      ;	is the maximum number of hops an IP datagram can make before it
      ;	is killed.  A low value ensures that datgrams stuck in routing
      ;	loops will die quickly, but be aware that internet-routed packets
      ;	may easily make 20 or 30 hops, so don't set it too low.  Ignore
      ;	this if you haven't enabled IP routing.
      ;
      ;IPTTL=100
      ;





























      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  161

      Configuration Files: XROUTER.CFG

      ;	Colour Settings:
      ;
      ;	Note the defaults have been chosen for their relative luminances
      ;	and contrast, and you may find certain combinations may not be
      ;	visible.
      ;
      ;	Permissible TEXT Colours are:
      ;
      ;	BLACK, NAVY, GREEN, CYAN,     RED, MAGENTA, BROWN, SILVER,
      ;	GREY,  BLUE, LIME, TURQUOISE, PINK, CERISE, YELLOW, WHITE
      ;
      ;	Permissible BACKGROUND colours are:
      ;
      ;	BLACK, NAVY, GREEN, CYAN, RED, MAGENTA, BROWN, SILVER
      ;
      ;
      ;	Top status bar background colour
      ;
      TopWinBgColor=CYAN
      ;
      ;	Top status bar text colour
      ;
      TopWinTxtColor=BLACK
      ;
      ;	Main window background colour
      ;
      MidWinBgColor=BLACK
      ;
      ;	Main window text colour
      ;
      MidWinTxtColor=WHITE
      ;
      ;	Command line background colour
      ;
      CmdWinBgColor=NAVY
      ;
      ;	Command line text colour
      ;
      CmdWinTxtColor=YELLOW
      ;
      ;	Bottom menu bar background colour
      ;
      BotWinBgColor=CYAN
      ;
      ;	Bottom menu bar text colour
      ;
      BotWinTxtColor=BLACK
      ;
      ;	Colour for displaying outgoing (transmitted) data
      ;
      TxColor=RED
      ;
      ;	Colour for displaying incoming (received) data
      ;
      RxColor=GREEN
      ;
      ;	Colour used for echoing Sysop's commands to main window.
      ;
      EchoColor=YELLOW
      ;
      ;




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  162

      Configuration Files: XROUTER.CFG

      ;	The default console settings may be overridden on a per-console
      ;	basis by using an optional console definition block as shown
      ;	in the example below.  Only the values which differ from the
      ;	globals defined above need be specified. (You may note that I
      ;	have omitted some values from the gaudy example below).
      ;	Alternatively you may omit the globals and fully specify each
      ;	console.
      ;	Note the optional use of MMASK and MPORTS to specify the default
      ;	monitoring options for this console.
      ;
      ;CONSOLE=3
      ;	TOPWINBGCOLOR=SILVER
      ;	MIDWINBGCOLOR=NAVY
      ;	MIDWINTXTCOLOR=WHITE
      ;	CMDWINBGCOLOR=GREEN
      ;	BOTWINBGCOLOR=SILVER
      ;	CONSOLECALL=G8PZT-4
      ;	TXCOLOR=PINK
      ;	RXCOLOR=LIME
      ;	MPORTS=1+5
      ;	MMASK=03FE
      ;ENDCONSOLE
      ;
      ;	Screen saver interval in seconds. (0 = disable screen saver)
      ;
      ;SAVER=300
      ;
      ;	In the following section there is no limit on the number of
      ;	lines of text you can specify, but no line must exceed 255
      ;	characters.  The end of text is marked by *** on a line by itself.
      ;
      ;	This text is sent to an incoming caller.  CTFLAGS controls which
      ;	callers receive the text.
      ;
      ;CTEXT
      ;Kidderminster spur AX25/IP Router.
      ;Type ? for list of commands.
      ;***
      ;
      ;	This text is the response to the plain 'I' command.
      ;	Note that you may create info "topics" which the user can access
      ;	using the "I <topic>" command.  Each topic should occupy a
      ;	seperate, appropriately named file in a directory named "INFO",
      ;	and the filenames must have the extension ".INF"
      ;
      ;INFOTEXT
      ;
      ;You are connected to part of the Kidderminster Packet Radio Network,
      ;run on behalf of Fourpak by Paula G8PZT.
      ;
      ;For information on Fourpak, contact G4FPV @ GB7GLO, or see the website at
      ;www.g8pzt.pwp.blueyonder.co.uk/fourpak/index.htm
      ;
      ;IP = 44.131.91.4 CHAT = G8PZT-8:KDRCHT or telnet port 3600
      ;
      ;This system runs G8PZT's Xrouter software - Type ? for list of commands.
      ;
      ;***
      ;






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  163

      Configuration Files: XROUTER.CFG

      ;	This ID message is sent every IDINTERVAL.
      ;	Only the first line is sent.
      ;	If your APRS-format static position code is included, starting
      ;	within the first 40 characters, you will be visible on APRS maps
      ;	and the MHeard function will record distances to heard stations.
      ;	The format is "!ddmm.mmN/dddmm.mmE#" where dd represents degrees
      ;	of latitude/longitude and mm.mm represents minutes to two decimal
      ;	places. "N" and "E" may be replaced by "S" and "W" as appropriate.
      ;
      ;IDTEXT
      ;!5224.00N/00215.00W# Kidderminster Router (KDRMIN) 44.131.91.4, Chat=KDRCHT:G8PZT-8
      ;***
      ;
      ;	CTFLAGS controls which connects receive CTEXT.
      ;	Add together the following numbers:
      ;
      ;		1	Send ctext if connect is to Node/port alias
      ;		2	Send ctext if call is to Node/port call
      ;		4	Send ctext on L4 connects.
      ;		8	Send ctext to TCP (TELNET) callers.
      ;
      ;	Default is 9 (Alias and TCP only).
      ;
      ;CTFLAGS=1
      ;
      ;	You may have up to 5 "virtual" consoles, upon which the sysop
      ;	may conduct independent sessions.  Consoles are selected by
      ;	using Alt-1 through alt-5, or the left and right arrow keys.
      ;	Setting this to 0 disables all console activity, saving memory
      ;	and preventing the direct screen writes which upset Desqview.
      ;
      ;NUMCONSOLES=3		      ; No. of virtual consoles (max=5)
      ;
      ;	Usage Log:
      ;	Setting LOG=1 will log all connects, disconnects, user-entered
      ;	commands and chat server activity. LOG=0 disables this function.
      ;	Make sure you have enough disk space.  Not recommended for long
      ;	term use on floppy-based machines.  Can be overridden by LOG
      ;	command at the command line.
      ;
      ;LOG=0
      ;
      ;	Overall limit on no. of concurrent sessions per user, across
      ;	all ports.  You might like to restrict "troublesome" users
      ;	this way! Max setting = default = 255
      ;
      ;SESSLIMIT=255
      ;
      ;	Optional flags to control the DX heard display (default=0)
      ;	Add together:
      ;
      ;		0	Show directly heard stations
      ;		1	Show digipeated stations
      ;











      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  164

      Configuration Files: XROUTER.CFG

      ; 	Added APRS DX logging, enabled by setting bit 1 in DXFLAGS.
      ;  	If bit 1 is set, Bits 3 - 14 specify the minimum distance which will
      ;  	be logged, from 4Km to 32764Km in 8Km steps, e.g. DXFLAGS=502 enables
      ;  	DX logging, with threshold of 500Km. If bit 1 is not set, bits 3-14
      ;  	are ignored.
      ;  	If DX logging is enabled, any received APRS positions which exceed the
      ;  	threshold distance are logged to LOG\DXLOG.TXT
      ;  	if bit 2 is set, the frame contents are logged too.
      ;
      ;DXFLAGS=0
      ;
      ;	Enable_linked controls who, if anyone, may use the "*** LINKED AS"
      ;	command.  The default is "N", and the possible values are:
      ;
      ;		Y	Command is unrestricted.
      ;		A	Only applications may use the command.
      ;		N	No-one may use the command.
      ;
      ;ENABLE_LINKED=A
      ;
      ;	L4 PARAMETERS
      ;	=============
      ;
      ;	(Don't adjust these unles you *really* understand all the
      ;	implications.  I've set them the same as BPQ)
      ;
      ;	No. of seconds between L4 retries and L4 connect/disconnect
      ;	attempts.
      ;
      ;L4TIMEOUT=90
      ;
      ;	No. of seconds to delay a L4 ack in case further frames arrive.
      ;	10 secs is probably OK on normal AX25 links, but is excessive
      ;	on wire links.  However, the system will attempt to adjust this
      ;	this value to cope with prevailing conditions.
      ;
      ;L4DELAY=10
      ;
      ;	No. of unacked L4 frames allowed before we stop to await an
      ;	ack.
      ;
      ;L4WINDOW=4
      ;
      ;	No. of L4 connect/disconnect or retransmission attempts before
      ;	link is abandoned.
      ;
      ;L4RETRIES=3
      ;
      ;	L3 PARAMETERS
      ;	=============
      ;
      ;	Obsolescence counter initial value
      ;
      ;OBSINIT=5
      ;
      ;	Obsolescence counter minimum to broadcast
      ;
      ;OBSMIN=3
      ;
      ;NODESINTERVAL=60	      ; Mins between nodes b/casts. (0 = disable)
      ;L3TTL=25		      ; Max L3 hops
      ;



      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  165

      Configuration Files: XROUTER.CFG

      ;	If this is set to 1, nodes whose alias begins with "#" will
      ;	not be displayed.
      ;
      ;HIDENODES=1
      ;
      ;	Minimum quality to add to node table.  This is the global value
      ;	which will apply to all ports unless overridden by a port minqual.
      ;	If not specified, the default is 10.
      ;
      ;MINQUAL=10
      ;
      ;	Netrom quality derating by callsign.  Allows you to reduce the
      ;	quality of "foreign" nodes on your system.
      ;	Syntax: QUALADJUST <call | "default"> <0-255>
      ;
      ;QUALADJUST default 120
      ;QUALADJUST G* 255
      ;QUALADJUST ZL* 200
      ;
      ;	Maximum nodes to include in table (default=200)
      ;
      ;MAXNODES=200
      ;
      ; 	Maximum acceptable trip time.  May be overridden by port maxtt.
      ;	Default is 5000 (50 seconds)
      ;
      ;MAXTT=5000
      ;
      ;	Maximum acceptable hops.  May be overridden by port maxhops.
      ;	Default is 30
      ;
      ;MAXHOPS=30
      ;
      ;	Maximum circuits specifies the maximum allowed number of 
      ;	concurrent Netrom L4 circuits. (Default is 20)
      ;
      ;MAXCIRCUITS=20
      ; 
      ;	Maximum sessions specifies the maximum allowable concurrent
      ;	sessions of any type. (Default is 20)
      ;
      ;MAXSESSIONS=20
      ;
      ;	Maximum routes specifies the maximum number of netrom neighbours
      ;	(Default is 30)
      ;
      ;MAXROUTES=30
      ;
      ;	Maximum number of concurrent TCP circuits (Defaults to 20)
      ;
      ;MAXTCP=20
      ;
      ;	Maxarp limits the number of ARP entries that may be stored
      ;	Make sure you have enough space for both static entries and 
      ;	dynamic entries learned from other systems
      ;
      ;MAXARP=20
      ;
      ;	Limits the amount of memory used for caching arp entries
      ;	Default is 10 which takes around 3Kbytes
      ;
      ;DCACHE=10



      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  166

      Configuration Files: XROUTER.CFG
      ; 
      ; =======================================================================
      ;	Ax25 Level 2 Global Parameters
      ; =======================================================================
      ;
      ;T3=180			      ; Link check interval in secs (180).
      ;IDLETIME=900		      ; Idle link shutdown timer in secs (900)
      ;IDINTERVAL=15		      ; Minutes between ID broadcasts (0=disable)
      ;PACLEN=120		      ; Global paclen (default=120)
      ;MAXLINKS=20		      ; Max. simultaneous L2 links (default=30)
      ;
      ; =======================================================================
      ; Interface definitions - These MUST come before any port definitions
      ; =======================================================================
      ;
      ;	Unlike BPQ, you first define the interfaces with the outside world,
      ;	then you define the ports that use those interfaces.  This is
      ;	because some interfaces (e.g. ASYNC) can support several channels
      ;	by use of the appropriate protocol (e.g. KISS).
      ;	Each interface has a number by which the ports identify it.  With
      ;	this method you may easily switch a whole group of ports onto a
      ;	different com port if you get a hardware breakdown for example.
      ;
      ;	TYPE:		ASYNC		      ; Serial port
      ;			LOOPBACK	      ; For test purposes
      ;			EXTERNAL	      ; User supplied driver (as BPQ)
      ;			BAYCOM		      ; Baycom USCC card.
      ;			RLC100		      ; Thorcom RLC100 scc card.
      ;			DRSI		      ; DRSI scc card
      ;			PC100		      ; Pac-comm PC100/120 scc card
      ;			PC120		      ; 4 port PC100 scc card.
      ;			PA0HZP		      ; PA0HZP opto-scc card
      ;			AXIP		      ; For AX25 over IP wormhole
      ;			AXUDP		      ; For AX25 over UDP wormhole
      ;			INTERNAL	      ; For HDLC applications.
      ;			ITACARD		      ; Yet another SCC card.
      ;			YAM		      ; YAM 1200/2400/9600 modem
      ;
      ;	COM:		For ASYNC interfaces, this is the Com number (1 - 16)
      ;			For SCC cards, you may use COM=1 etc. instead of
      ;			CHANNEL=A etc.
      ;
      ;	CHANNEL		For SCC cards only!  This is the physical channel
      ;			or port on the card (A, B, C or D).  You may use
      ;			CHANNEL=A etc. or COM=1 etc. but not both.
      ;
      ;	(For ASYNC interfaces, ioaddr and intnum are optional for com 1 - 4)
      ;	(For SCC cards, use same IOADDR and INTNUM for all channels on card)
      ;	IOADDR		IO device address (hex)
      ;	INTNUM		Interrupt number (decimal)
      ;
      ;	SPEED		The serial port baud rate for ASYNC interfaces, or
      ;			the radio baud rate for HDLC cards.
      ;			50-115200 bauds (Decimal). Don't include a comma.
      ;			If set to zero (HDLC cards only), the modem must
      ;			supply a x1 clock (TXC on RTXC pin, RXC on TRXC pin).
      ;
      ;








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  167
     
 Configuration Files: XROUTER.CFG

      ;	PROTOCOL:       Protocol to use on the interface:
      ;			NONE	- Use this with type=loopback
      ;			ASCII	- Remote consoles (TTY) via ASYNC ports
      ;			SLIP	- For TCP/IP over RS232
      ;			PPP	- For TCP/IP over RS232
      ;			KISS	- For driving KISS TNCs or wired links.
      ;			MODEM	- Hayes compatible PSTN modem.
      ;			NETROM	- Netrom backend serial link.
      ;			ETHER	- Ethernet (requires ETHDRV.EXE)
      ;			TNC2	- TNC2 Emulation.
      ;			HDLC	- For use with SCC cards, YAM modem,
      ;                                 INTERNAL interfaces, and some EXTERNAL
      ;                                 drivers.
      ;
      ;	KISSOPTIONS:	Options for KISS interfaces only...
      ;			NONE	- Plain KISS (most TNC's use this) (default)
      ;			POLLED	- For TNCs which send only when polled.
      ;			CHECKSUM - Packets protected by checksum.  You can
      ;				   only use this option if your TNC supports it.
      ;                       ACKMODE	- For TNC's which inform the router when a
      ;				  frame has been transmitted on air.
      ;			SLAVE	- Router will act like a polled KISS TNC,
      ;				  sending only when commanded to do so.
      ;			    	  (Polled and slave are mutually exclusive)
      ;			(BPQKISS eproms require POLLED and CHECKSUM, and
      ;			their use of ackmode is optional)
      ;
      ;	FLOW:		Flow control options (ASYNC interfaces only):
      ;			0 = No flow control
      ;			1 = Hardware (RTS/CTS) flow control
      ;			2 = Software (XON/XOFF) flow control (TTY link only)
      ;			3 = Hardware AND software flow control
      ;			If not specified, flow control defaults to NONE.
      ;			Don't use any flow control with KISS.
      ;
      ;	MTU:		Specifies largest IP packet.  Setting this over 256
      ;			will crash most BPQ nodes, or at the very least cause
      ;			the packet to be lost.
      ;			The router can handle single frames up to 1500 bytes,
      ;			but BPQKISS TNC's are limited by 340 byte buffers.
      ;			Received IP datagrams larger than MTU are
      ;			fragmented to suit the outgoing link MTU.
      ;
      ;	Each interface definition starts with INTERFACE= and ends with
      ;	ENDINTERFACE.  The number following INTERFACE= is merely a label
      ;	allowing ports to refer to the interface.  It must be specified,
      ;	but the numbers themselves, and the order in which they're defined
      ;	are not important.
      ;
      ;INTERFACE=1
      ;	TYPE=ASYNC
      ;	COM=1
      ;	IOADDR=3F8
      ;	INTNUM=4
      ;	SPEED=9600
      ;	PROTOCOL=KISS
      ;	KISSOPTIONS=CHECKSUM
      ;	MTU=256
      ;ENDINTERFACE
      ;
      ;




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  168

      Configuration Files: XROUTER.CFG

      ;INTERFACE=2
      ;	TYPE=ASYNC
      ;	COM=2
      ;	SPEED=4800
      ;	PROTOCOL=KISS
      ;	KISSOPTIONS=CHECKSUM
      ;	MTU=256
      ;ENDINTERFACE
      ;
      ;
      ;	Example "loopback" interface, allowing self-connects without going
      ;	via an external system
      ;
      INTERFACE=3
	   TYPE=LOOPBACK
	   PROTOCOL=KISS
	   MTU=576
      ENDINTERFACE
      ;
      ;	Example interface for drivers conforming to BPQ's "external"
      ;	spec such as baycom modem driver or ODIDRV ethernet driver.
      ;
      ;INTERFACE=4
      ;	TYPE=EXTERNAL		      ; BPQ-compatible "External" driver
      ;	PROTOCOL=HDLC
      ;	INTNUM=96
      ;ENDINTERFACE
      ;
      ;	Example of an interface for TTY (remote console).  You would
      ;	connect the com port via a null modem to a dumb terminal or
      ;	computer running a terminal emulator program, such as TELIX.
      ;
      ;INTERFACE=5
      ;	TYPE=ASYNC
      ;	COM=1
      ;	SPEED=19200
      ;	MTU=256
      ;	PROTOCOL=ASCII
      ;	Flow control is optional. Be VERY careful if you are monitoring
      ;	over a flow controlled link, because if you pause the display for
      ;	a long time, the data will back-up in the router until it becomes
      ;	strangled.
      ;	FLOW=2		      ; Xon/xoff flow control
      ;ENDINTERFACE
      ;
      ;	Example of an interface for SCC card - in this case BAYCOM USCC.
      ;	You require one interface per channel on the card.
      ;	Use the same base address for all channels.
      ;
      ;INTERFACE=6
      ;	TYPE=BAYCOM
      ;	COM=2		      ; Channel B
      ;	IOADDR=300	      ; Card base address=300H
      ;	INTNUM=5	      ; Card IRQ=5
      ;	SPEED=0		      ; DF9IC 1200/9600 NRZ modem
      ;	PROTOCOL=HDLC	      ; Only HDLC supported at present
      ;	MTU=256
      ;ENDINTERFACE
      ;






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  169

      Configuration Files: XROUTER.CFG

      ;	Example AXIP pseudo-interface. Only TYPE=AXIP and MTU required,
      ;	all other parameters will be ignored (at present).
      ;	At least one AXIP interface is needed if you intend to do AX over IP.
      ;       Each AXIP interface supports an unlimited number of AXIP ports.
      ;	You can have multiple AXIP interfaces if you need different MTU's.
      ;
      ;INTERFACE=7
      ;	TYPE=AXIP
      ;	MTU=256
      ;ENDINTERFACE
      ;
      ;	Example multi-protocol Ethernet interface using PZT's ETHDRV.EXE
      ;	driver. You must first load the appropriate driver for your
      ;	ethernet card (such as NE2000.COM), then ETHDRV.EXE, before
      ;	starting XROUTER.  See documentation for further details.
      ;	This interface will directly support IP, ARP and AX25.
      ;
      ;INTERFACE=8
      ;	TYPE=EXTERNAL
      ;	PROTOCOL=ETHER
      ;	MTU=1600
      ;	INTNUM=125
      ;ENDINTERFACE
      ;
      ;	Example AXUDP pseudo-interface. Apart from "TYPE=AXUDP" see the
      ;	comments relating to AXIP interface.
      ;
      ;INTERFACE=9
      ;	TYPE=AXUDP
      ;	MTU=256
      ;ENDINTERFACE
      ;
      ;	Example YAM interface. One of these required for each YAM port.
      ;	Modem must be initialised with YAMINIT.EXE before starting Xrouter.
      ;
      ;INTERFACE=10
      ;	TYPE=YAM
      ;	COM=1		      ; 1-4 or specify IOADDR/INTNUM instead
      ;	MTU=256
      ;	SPEED=1200	      ; Radio speed
      ;	PROTOCOL=HDLC	      ; Only HDLC supported at present
      ;ENDINTERFACE
      ;
      ; =====================================================================
      ; Port definitions. Each one begins with PORT=n and ends with ENDPORT
      ; =====================================================================
      ;
      ;	The number following PORT= is the port number as displayed by
      ;	the P[orts] command. They do not need to be sequential, you
      ;	may use any number, but you must define them in the order in
      ;	which they are to appear in the list.
      ;
      ;PORT=1
      ;
      ;	Text string to identify port on "PORTS" display
      ;
      ;	ID=Link to KIDDER
      ;







      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  170

      Configuration Files: XROUTER.CFG

      ;	Interfacenum specifies which interface this port should use.
      ;
      ;	INTERFACENUM=1
      ;
      ;	The rest of these are optional, since there are defaults
      ;	built into the program.
      ;
      ;	PORTCALL=G8PZT-1	      ; Additional L2 callsign for port
      ;	PORTALIAS=PZT1		      ; Additional L2 alias for this port
      ;	PORTALIAS2=RELAY	      ; Yet another alias, for APRS
      ;	CHANNEL=A		      ; Channel to use on interface (A - P)
      ;	PACLEN=160		      ; Overrides global paclen for this port
      ;				      ; If set to 0, paclen will be adaptive.
      ;	MAXFRAME=2		      ; Only 1-7 at present.
      ;	TXDELAY=300		      ; Tx keyup delay (millisecs)
      ;	TXTAIL=100		      ; TX keydown delay (millisecs)
      ;				      ; Don't go less than 100 for SCC cards!
      ;	SLOTTIME=100		      ; (millisecs)
      ;
      ;	I strongly recommend frack=7000 for 1200 bauds. (see manual)
      ;
      ;	FRACK=7000		      ; L2 T1 time (millisecs)
      ;
      ;	Resptime should be *at least* ((paclen * 10000) / RFbauds) millisecs,
      ;	where "paclen" is the other end's paclen, otherwise you will send
      ;	unnecessary poll frames. 1500 is OK for 1200 bauds with paclen=120
      ;
      ;	RESPTIME=1500		      ; L2 delayed ack T2 (millisecs)
      ;
      ;	Persist should be set to (255 / (no. of users on frequency)).
      ;	e.g. for a frequency with an average of 10 users on at any one
      ;	time you'd set it to 25. Default is 64.
      ;
      ;	PERSIST=64		      ; Probability to transmit (0-255)
      ;
      ;	I can't see any point in setting retries more than 10, other than
      ;	for test purposes.  If you need so many retries it's a useless
      ;	link and you're just wasting everyone elses airtime.  The higher
      ;	you set this value, the longer users will have to wait to get
      ;	a "failure with" for a non-contactable destination.
      ;
      ;	RETRIES=10
      ;
      ;	If you set fulldup=1, the router will transmit whenever it needs
      ;	to, without waiting for the other end to stop.  Used only for
      ;	hardware which is capable of simultaneous transmission and
      ;	reception, such as full duplex radio or wire links.
      ;
      ;	FULLDUP=0		      ; 1 = Full duplex, 0 = simplex/half duplex
      ;
      ;	Activate FEC between XROUTERS (only works with SCC, YAM modems or
      ;	TNCs with KISSFEC.BIN Eprom. Under development)
      ; 
      ;	FEC=1
      ;










      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  171

      Configuration Files: XROUTER.CFG

      ;	Softdcd is used only by SCC cards.  If set to non-zero, the real
      ;	dcd will be ignored, and the driver will use the presence of
      ;	hdlc data as a DCD indication.  Using SOFTDCD with an open squelch
      ;	generates a *huge* interrupt loading on the PC, which may cause
      ;	degradation of performance, depending on the PC type, so I don't
      ;	recommend it.
      ;
      ;	SOFTDCD=0
      ;
      ;	Rfbauds defaults to 1200 if not specified.  It is intended for use
      ;	with "real" tnc's attached via RS232, because the RF baud rate is
      ;	usually different to the serial baud rate.  It simply helps the
      ;	router make timing decisions mainly affecting Nodes Broadcasts
      ;	and TCP window.
      ;
      ;	RFBAUDS=2400
      ;
      ;
      ;	Enable/disable the MHEARD function on this port. The number
      ;	specifies how many callsigns to maintain in the list. Set to 0
      ;	to disable MHEARD.
      ;
      ;	MHEARD=10		      ; Mheard enabled, 10 calls
      ;
      ;	MHFLAGS controls which callsigns are recorded in the MH list,
      ;	and defaults to 255 (show everything).
      ;	The number is formed by adding the following values:
      ;
      ;		1	Show directly heard stations
      ;		2	Show directly heard digipeaters
      ;		4	Show digipeated stations
      ;
      ;	MHFLAGS=1	      ; show directly heard stations only
      ;
      ;	Digipeat flag for this port.  0 = no digipeat.  Default=7
      ;	Add together:
      ;
      ;		1	Digipeat UI frames
      ;		2	Digipeat non-UI frames
      ;		4	Enable RELAY generic APRS digipeating
      ;		8	Enable TRACE and TRACEn-N APRS digipeating.
      ;		16	Enable WIDE and WIDEn-N (Well sited stations only!)
      ;		32	Enable L4 APRS tunnelling
      ;		64	Enable frames from RF to Igate
      ;		128	Enable frames from Igate to RF
      ;
      ;	DIGIFLAG=7		      ; Normal digi + RELAY.
      ;
      ;	DIGIPORT=0		      ; Port to relay digipeated frames on
      ;			      ; (0=this port)
      ;
      ;	List of destinations for "broadcasting".
      ;	Received non-digipeater UI frames, addressed to one of these
      ;	destinations, will be re-broadcasted on all ports which have a
      ;	matching address in their BCAST list.  This would for example be
      ;	used to broadcast mail beacons from a BBS onto several frequencies.
      ;
      ;	BCAST=MAIL,ALL
      ;






      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  172

      Configuration Files: XROUTER.CFG

      ;	List of approved broadcasters.
      ;	If you wish to restrict the broadcast facility to certain senders
      ;	only, list the callsigns here.  If no calls are specified, the
      ;	facility is unrestricted.  Separate the calls by commas, and don't
      ;	include any spaces in the list.
      ;
      ;	BCFROM=GB7PZT,GB7MAX
      ;
      ;	Default quality for nodes whose broadcasts are received on this
      ;	port. Set to 0 to disable all L3/4 activity on this port.  A value
      ;	between 256 and 511 enables automatic quality starting at qual-256.
      ;
      ;	QUALITY=10
      ;
      ;	Minimum quality to add to node table for nodes received via this
      ;	port.  If specified, this overrides the global minqual, and can
      ;	be used to exclude unreachable and marginal nodes.
      ;
      ;	MINQUAL=10
      ;
      ;	Minimum node quality to include in broadcasts on this port.  You
      ;	would typically use this to limit the number of nodes broadcast
      ;	to a neighbour with limited storage capability.
      ;
      ;	MINTXQUAL=120
      ;
      ;	Default maximum trip time for all neighbour routes learned on this
      ;	port. Can be overridden by locked in route.
      ;	If not specified, defaults to global MAXTT.
      ;
      ;	MAXTT=5000
      ;
      ;	Default hop limit for all neighbours learned on this port.  Can
      ;	be overridden by locked in route.  Defaults to global MAXHOPS.
      ;
      ;	MAXHOPS=3
      ;
      ;	Port to transmit on. 0=this port.  You would typically use this
      ;	where a single transmitter is used in conjunction with several
      ;	receivers
      ;
      ;	TXPORT=0
      ;
      ;	Interlock is only used by SCC cards - KISS TNC's make their own
      ;	decisions when to transmit, and the router has no control over
      ;	that process.  If a non-zero value is specified, no two ports
      ;	with the same value will transmit at the same time.
      ;
      ;	INTERLOCK=4
      ;
      ;	TXOK uses the following values
      ;	0 = RX ok,no TX
      ;	1 = RX and TX ok
      ;	2 = No TX or RX
      ;	3 = TX ok no RX
      ; 
      ;	TXOK=1








      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  173

      Configuration Files: XROUTER.CFG

      ;	Maximum no. of simultaneous users on this port. Default is 255
      ;	which means "no limit".
      ;
      ;
      ;	USERS=255
      ;
      ;	Sesslimit specifies the maximum simultaneous connects each user
      ;	is allowed.  You may wish to set a low value if you are a
      ;	control freak.
      ;
      ;	SESSLIMIT=5
      ;
      ; 	The following two commands are mutually exclusive... Use one or
      ;	the other, but not both!
      ;	Callsigns should be seperated by commas or spaces, and there is no
      ;	limit to the number of calls. You can have multiple validcalls= or
      ;	exclude= lines, but you should be aware that, depending on your
      ;	hardware, there may be a performance penalty if you use long lists.
      ;
      ;	Validcalls allows L2 frames only from the specified users, and is
      ;	typically used to keep users from connecting to link-only ports.
      ;
      ;	VALIDCALLS=G6YAK,G6AMU	      ; Accept only these users
      ;
      ;	Exclude allows L2 frames from everyone EXCEPT specified users,
      ;	and would typically be used on a user-access port to prevent
      ;	connections from trouble-makers and pirates.  Just because I
      ;	provide this command it doesn't mean I condone its use.
      ;
      ;	EXCLUDE=NOCALL,P1RAT         ; Ignore these users
      ;
      ;	CWID=G8PZT		      ; Used only by SCC cards.
      ;			      ; Callsign is sent every 30 mins.
      ;
      ;	PIPE allows frames received (and optionally sent) on this port to
      ;	be copied to another port, e.g. to allow a PMS on one port to see
      ;	the traffic on another port.  Unless the "bi-directional" option
      ;	is specified, pipes are one way.  In order to have two way traffic
      ;	using a uni-directional pipe, you must set up a reverse pipe on the
      ;	opposite port.  You may pipe several ports to a single destination
      ;	port, but you can only have one *outgoing* pipe from any port.
      ;	Pipes are capable of generating an immense amount of traffic, so
      ;	use them with care - your target port MUST be capable of handling
      ;	the traffic load.
      ;	Pipes can be made "selective", by adding a comma-delimited callsign
      ;	list, e.g. "PIPE=4 GB7PZT,KDRBBS".  This will reduce the loading on
      ;	the target port, by piping only the frames with the specified calls
      ;	in the destination field.
      ;	Pipes can be made "bi-directional" by adding 512 to the PIPEFLAG
      ;	value (see below: suggested value = 515).  If a frame is piped on
      ;	a birectional pipe, the source call is remembered so that responses
      ;	will be piped back to the sender.  Thus a reverse pipe is not needed.
      ;	This is useful in cases where a BBS has a front end router - simply
      ;	set up bidrectional selective pipes from each user port to the BBS
      ;	port, and set up the BCAST option so that the UI mail headers are
      ;	broadcast on each user port.  The BBS will then allow direct
      ;	connect and will respond to resync requests.
      ;	To disable piping, set PIPE=0 or just omit the command.
      ;
      ;	PIPE=2			      ; Pipe frames from this port to port 2
      ;




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  174

      Configuration Files: XROUTER.CFG

      ;	PIPEFLAG is only used when piping is active, and controls which
      ;	frames are piped.  The default if not specified is 3.  The value
      ;	is made up by adding together the following numbers:
      ;
      ;		1	- UI frames *not* addressed to nodecall/alias.
      ;		2	- Non-UI frames *not* addressed to nodecall/alias.
      ;		4	- UI frames addressed to nodecall/alias.
      ;		8	- Non-UI frames addressed to nodecall/alias.
      ;		16	- UI frames transmitted by us.
      ;		32	- Non-UI frames transmitted by us.
      ;		64	- Allow budlisted users to be piped.
      ;		128	- Netrom frames
      ;		256	- IP / ARP frames
      ;		512	- Bi-directional piping
      ;
      ;	PIPEFLAG=5		      ; Pipe all rcvd UI frames only
      ;
      ;	UNPROTO=CQ,G6YAK
      ;
      ;	Optional alternative IP address for use on this port.  If this
      ;	is specified, it will be used instead of the global IP address
      ;	for this port only.
      ;
      ;	IPADDRESS=44.131.91.5
      ;
      ;	The DHCP keyword specifies whether or not the port IP address
      ;	will be obtained dynamically using DHCP (DHCP=1) or specified
      ;	statically (DHCP=0).  Default is 0.
      ;
      ;	DHCP=0
      ;
      ;	If you set SYSOP=1, all users who connect on this port will get
      ;	full sysop status without answering a password challenge.  This
      ;	is intended ONLY FOR USE ON SECURE LINKS, such as RS232 or
      ;	Ethernet.  Be aware that, if the remote system is capable of
      ;	gatewaying or digipeating, users could downlink via the remote
      ;	system back into this port, thus gaining sysop status.  The default
      ;	for this parameter is of course zero!!
      ;
      ;	SYSOP=0
      ;
      ;	The APPLMASK parameter is used only if you are running applications
      ;	via the host interface.  It specifies which applications will be
      ;	directly connectible on this port.  Default is 255, which allows
      ;	all applications.  The value is made up by adding together the
      ;	following numbers:
      ;
      ;		1	- Enable Application 1
      ;		2	- Enable Application 2
      ;		4	- Enable Application 3
      ;		8	- Enable Application 4
      ;		16	- Enable Application 5
      ;		32	- Enable Application 6
      ;		64	- Enable Application 7
      ;		128	- Enable Application 8
      ;
      ;	If you want an application to be directly connectible on a port,
      ;	it must have a callsign, an alias or both, and the corresponding
      ;	bit in that port's applmask must be set.
      ;
      ;	APPLMASK=3
      ;



      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  175

      Configuration Files: XROUTER.CFG

      ;	Optional port-specific ID text, sent every IDINTERVAL in place of
      ;	the global IDTEXT (e.g. for APRS-only ports).  Only one line may
      ;	be sent.
      ;
      ;	IDTEXT=!5224.00N/00215.00W# (Kidder)
      ;
      ;	CFLAGS allows level 2 uplinking and/or downlinking to be prevented,
      ;	e.g. on digipeat-only ports. Use VERY carefully! Default is 3.
      ;	Sysop can always downlink.  Add together:
      ;
      ;		1	Allow incoming connections (uplinks)
      ;		2	Allow outgoing connections (downlinks)
      ;		4	Applications may downlink unconditionally
      ;		8	Prevent L3RTT frames being sent (will stop inp3)
      ;		16      Allow L2 Fragmentation
      ;
      ;	CFLAGS=3
      ;
      ;	Remote NET/ROM systems to whom we will tunnel L2 frames.
      ;	(See manual or PROXY.TXT for full explanation)
      ;
      ;	PROXY=GB7PZT,GB7BBS
      ;
      ;	Modem Initialisation string (Modem interfaces only)
      ;
      ;	INITSTR=ATM0
      ;
      ;ENDPORT
      ;
      ; ---------------------------------------------------
      ;PORT=2
      ;	ID=Link to BRUM
      ;	INTERFACENUM=2
      ;	CHANNEL=M
      ;	FRACK=7000
      ;	RESPTIME=1500
      ;	MHEARD=10
      ;	QUALITY=100
      ;	TXDELAY=500	      ; Synthesiser is slow to lock!
      ;ENDPORT
      ;
      ; ---------------------------------------------------
      PORT=3
	   ID=Internal Loopback
      INTERFACENUM=3
      ENDPORT
      ;
      ; ---------------------------------------------------
      ;PORT=4
      ;	ID=External loopback
      ;	INTERFACENUM=4
      ;ENDPORT
      ;
      ; ---------------------------------------------------











      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  176

      Configuration Files: XROUTER.CFG

      ;	Example AXIP (AX25 over IP wormhole) port.
      ;	You need one of these for each axip link
      ;	At least ID, INTERFACENUM, and IPLINK must be specified.
      ;	The IPLINK address is the remost host's IP address or hostname.
      ;	It is more efficient to use an IP address than a hostname.
      ;	Parameters such as TXDELAY, TXTAIL, SLOTTIME, PERSIST, FULLDUP,
      ;	SOFTDCD etc. are meaningless for AXIP, but FRACK, RESPTIME, PACLEN,
      ;	MAXFRAME, QUALITY etc. operate as normal.
      ;
      ;
      ;PORT=5
      ;	ID=AXIP link with WA3DXX
      ;	INTERFACENUM=7
      ;	IPLINK=44.73.88.69
      ;	RFBAUDS=56000
      ;	FRACK=2000
      ;	RESPTIME=100
      ;ENDPORT
      ;
      ; -----------------------------------------
      ;	Example Ethernet port, supporting IP, ARP and AX25.
      ;	Note the reduced timings (only used for ax25 connections), as
      ;	the defaults are a bit too relaxed for ethernet.
      ;
      ;PORT=6
      ;	ID=Ethernet LAN
      ;	INTERFACENUM=8
      ;	CHANNEL=A		      ; Ignored
      ;	FRACK=1000
      ;	RESPTIME=200
      ;	MAXFRAME=7
      ;	PACLEN=240
      ;ENDPORT
      ;
      ; -------------------------------------
      ;	Example APRS-only port.
      ;	Note the use of an alternate IDTEXT, and the use of CFLAGS to
      ;	disable connected mode operations, thus MAXFRAME,FRACK,PACLEN
      ;	etc are not needed.
      ;
      ;PORT=7
      ;	ID=144.800 MHz 1200 baud APRS
      ;	INTERFACENUM=2
      ;	CHANNEL=B
      ;	CFLAGS=0		      ; Prevent up/downlinks on this port
      ;	DIGIFLAG=5		      ; Digi only UI frames addressed via RELAY
      ;	MHEARD=22		      ; Nice big MH list
      ;	IDTEXT=!5224.00N/00215.00W#PHG3021 Kidderminster APRS digi
      ;
      ;	Override the default destination & path for ID beacons
      ;
      ;	IDPATH=APRS,RELAY,WIDE
      ;
      ;	Default digipeater path for APRS frames originated by APRS
      ;	messaging shell and Igate. If you omit this, the frames will
      ;	be sent without any digipeaters. Messaging shell users may
      ;	override this path.
      ;
      ;	APRSPATH=RELAY
      ;
      ;ENDPORT




      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  177

      Configuration Files: XROUTER.CFG

      ;
      ; ---------------------------------------------------
      ;	Example AXUDP (AX25 over UDP wormhole) port.
      ;	You need one of these for each axudp link
      ;	At least ID, INTERFACENUM and IPLINK must be specified.
      ;	The IPLINK address is the remost host's IP address or hostname.
      ;	(Note: It is more efficient to use an IP address than hostname).
      ;	UDPLOCAL and UDPREMOTE are the UDP port numbers for each end of
      ;	the link, and if omitted they default to 93
      ;	Parameters such as TXDELAY, TXTAIL, SLOTTIME, PERSIST, FULLDUP,
      ;	SOFTDCD etc. are meaningless for AXUDP, but FRACK, RESPTIME, PACLEN,
      ;	MAXFRAME, QUALITY etc. operate as normal.
      ;
      ;PORT=8
      ;	ID=AXUDP link with VK1UDP
      ;	INTERFACENUM=9
      ;	UDPLOCAL=93
      ;	IPLINK=44.69.88.73
      ;	UDPREMOTE=93
      ;	RFBAUDS=56000
      ;	FRACK=2000
      ;	RESPTIME=100
      ;ENDPORT
      ;
      ; ====================================================================
      ;	Applications. Each must begin with APPL= and end with ENDAPPL
      ;	Application number must be between 1 and 8.
      ;	Most BBS/PMS applications have to use appl=1, and HOST (e.g. PAC4,
      ;	TERM4) must use APPL=2
      ;	If APPLFLAGS=1, the application gets sysop privileges. Requires 
      ;	PZTHOST.EXE version 1.6.
      ;	Added another flag (bit 1) to APPLFLAGS. If set, it allows guest users
      ; 	to access the application by typing APPLNAME at the command prompt.
      ;	Default is to deny access. Previous versions allowed guests to access
      ;	the applications by name, which was a security hole.
      ;
      ;	Each field is optional - you may have an applname without a call
      ;APPL=1
      ;	APPLNAME=PBBS
      ;	APPLCALL=G8PZT-3
      ;	APPLALIAS=PZTBBS
      ;	APPLFLAGS=0
      ;	APPLQUAL=50		      ; Netrom quality to broadcast
      ;ENDAPPL
      ;
      ;	In this example, the application has no callsigns or quality, so
      ;	it can only be reached by issuing the command "HOST" during a
      ;	command session.
      ;APPL=2
      ;	APPLNAME=HOST
      ;ENDAPPL
      ;













      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  178

      Configuration Files: XROUTER.CFG

      ; ===================================================================
      ; Routes are no longer read from XROUTER.CFG use BOOTCMDS.SYS file
      ; ===================================================================
      ;
      ;	Sysop-defined commands:
      ;
      ;	Up to 8 commands can be defined, allowing the sysop to set up
      ;	single-word aliases for frequently used command strings.  For
      ;	example you might wish to set up BBS, CONV and DXCLUSTER to
      ;	point to local systems.
      ;
      ;	Each command is defined using a seperate "COMMAND=" string,
      ;	and the arguments are <alias> <real_cmd>.
      ;	e.g. "COMMAND=BBS C 7 GB7PZT" means "create a new command
      ;	called BBS, which translates to the sequence C 7 GB7PZT"
      ;
      ;COMMAND=BBS C 1 GB7PZT
      ;COMMAND=CONV TELNET 44.131.90.1 3600
      ;COMMAND=DXCLUSTER C GB7DXC
      ;      













































      XROUTER Sysop Manual Revision 2.3 (25/04/04           Page  179      
