.PL





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


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



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


                          Revision 2.1 - 27th July 2002
                          -----------------------------


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

      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 doing the same!

      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.













                                        1
      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.1 (27/7/02)             Page 2
      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 PZTSOCK 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.  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.1 (27/7/02)             Page 3
      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 within DOS, Windows95 or DesqView environment.
      - 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 conection 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.
      - 32 bit Windows application support coming soon...
      * 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).








      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 4
      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 beaconed 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 and IPIP tunnelling 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

      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.

      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 sceme and callsign.











      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 5
      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.
      - Will not (yet) support Windows applications such as Winpack or UI-View.
      - 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.1 (27/7/02)             Page 6
      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.1 (27/7/02)             Page 7
      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.1 (27/7/02)             Page 8
      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.1 (27/7/02)             Page 9
      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.

      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.1 (27/7/02)             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 to import existing nodes and routes information from a BPQ 
      system, place a copy of the BPQNODES file (produced by BPQ's SAVENODES 
      command) in the directory and rename it PZTNODES.

      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 
      system, help and manual 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.1 (27/7/02)             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 PZTNODES.  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 
      PZTNODES just before it exits back to DOS.  It is protected by an 
      irritating "are you sure" challenge. 































      XROUTER Sysop Manual Revision 2.1 (27/7/02)             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.
      <Alt-F9>            DOS shell
      <Alt-B>             Invoke screen blanker
      <Alt-C>             Clear screen.
      <Alt-X>             Exit program.

















      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 13
      Console Facilities


      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.


      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.


      Monitor port
      ~~~~~~~~~~~~
      The F3 key selects the ports to be monitored.  At the moment only the 
      first 16 ports can be monitored.  Upon pressing this key you will be 
      invited to enter a hexadecimal number 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 = 0001       5 = 0010       9 = 0100      13 = 1000
                2 = 0002       6 = 0020      10 = 0200      14 = 2000
                3 = 0004       7 = 0040      11 = 0400      15 = 4000
                4 = 0008       8 = 0080      12 = 0800      16 = 8000

         Example: 004F = monitor ports 1, 2, 3, 4 and 7.

      This is (I think) identical to BPQ.  You may cancel the operation by 
      pressing the <ESC> KEY.


      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 - ICMP
         0002 - Outgoing frames          0200 - TCP
         0004 - AX25 layer 2             0400 - KISS
         0008 - AX25 info frames         0800 - SLIP
         0010 - AX25 layer 3             1000 - PASSALL
         0020 - AX25 layer 4             2000 - Hex Dump
         0040 - IP frames
         0080 - ARP frames

      E.g. 0201 will show incoming TCP frames only, while 0241 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.1 (27/7/02)             Page 14
      Console Facilities


      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.


      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.


      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.

      On some machines, use of the dos shell *may* cause the system to crash 
      - I think I've fixed this, but would appreciate any reports.  If it 
      does crash, it may bear some relationship to the order in which 
      certain programs are loaded.


      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.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 15
      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.1 (27/7/02)             Page 16
      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.1 (27/7/02)             Page 17
      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 protcols 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.1 (27/7/02)             Page 18
      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 aplication 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.1 (27/7/02)             Page 19
      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.1 (27/7/02)             Page 20
      Miscellaneous Topics


                               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!!


      Nodes/routes table saving
      ~~~~~~~~~~~~~~~~~~~~~~~~~
      The Nodes & routes tables are saved to file PZTNODES 1 minute after 
      starting the program, and at 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.1 (27/7/02)             Page 21
      Miscellaneous Topics



      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 accomodated.  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 modifed 
      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.1 (27/7/02)             Page 22
      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.1 (27/7/02)             Page 23
      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.1 (27/7/02)             Page 24
      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.1 (27/7/02)             Page 25
      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 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.  FTP clients which perform automatic logon, 
      such as WS_FTP, CuteFTP etc., cannot use the system in this mode.  
      However, If the user is on a port which has the SYSOP=1 option 
      (usually reserved for secure links) normal plain text passwords may be 
      used, and automated FTP clients will work.

      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.1 (27/7/02)             Page 26
      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.1 (27/7/02)             Page 27
      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.1 (27/7/02)             Page 28
      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.1 (27/7/02)             Page 29
      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:

      Time active (mins):              3940
      Memory: Max/Cur/Min/Out        309832    278056    273720         0
      Known nodes:                      139
      Total bytes sent/rcvd:       12685081   9695736
      Max ccts L2/L3/L4/TCP:             10        22        12         0

      IP Heard/Reasm/Rcvd/Routed:         7         0         5         2
      IP Bad Hdr/Chksum/Version:          0         0         0
      IP Sent/Frag/Unsent/Total:         11         0         0        13

      L4 Connects Tried/Made/Rcvd:      683       667       728
      L4 total frames Sent/Rcvd:      43347     41880
      L4 Sent/Rcvd/Resent/Reseq:      28431     23972       895      1831
      L4 Chokes Sent/Rcvd:             1750       168
      L4 Timeouts/Failures:             857        26

      Use STATS * to display full stats


      "Time active" is the number of minutes since Xrouter was last 
      restarted.

      "Memory" shows various stats about the program'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.

      "Known nodes" is the number of nodes heard about whose quality is 
      greater than the minqual setting.

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

      "Max ccts" shows the 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.

      "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.  







      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 30
      Stats


      "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
      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.1 (27/7/02)             Page 31
      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.

      "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.  

      "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.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 32
      Stats


      "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.1 (27/7/02)             Page 33
      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.1 (27/7/02)             Page 34
      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 birectional 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 
      bidrectional 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.1 (27/7/02)             Page 35
      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.1 (27/7/02)             Page 36
      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.1 (27/7/02)             Page 37
      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 bidirectional 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 setup, 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.1 (27/7/02)             Page 38
      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 chat server has 32768 "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 0 (zero) 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 0 to 255 are "local" to each chat server, and the remaining 
      channels 256-32767 are "global", i.e. they are linked with all other 
      servers, providing the sysop sets up at least one link to another 
      server.  Only Netrom links are allowed at present, so the partner must 
      be in your node table.

      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.

      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.

      As with *all* chat servers, you should be aware that the throughput on 
      each channel is determined by the slowest link on that channel, 
      therefore "dxing" into distant chat servers is not encouraged.  The 
      same applies to partner servers - if the link to your partner isn't up 
      to the job the throughput for everyone will be compromised




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 39
      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.1 (27/7/02)             Page 40
      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.

      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
           ENDAPPL













      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 41
      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 suport
      ~~~~~~~~~~~~~~~~~~~~~~~
      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.1 (27/7/02)             Page 42
      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.1 (27/7/02)             Page 43
      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.1 (27/7/02)             Page 44
      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:                  300 (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.1 (27/7/02)             Page 45
      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.1 (27/7/02)             Page 46
      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.1 (27/7/02)             Page 47
      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 
      sucessfully 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 sucessfully 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.1 (27/7/02)             Page 48
      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.1 (27/7/02)             Page 49
      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.1 (27/7/02)             Page 50
      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 sucessful 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 sucessful 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 preceed the dialling and login sequence, and 
              any protocol dependant commands, such as the PPP commands.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 51
      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 adminstered "on the fly" using the DUN
      command , which is detailed in the sysop command referece 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.1 (27/7/02)             Page 52
      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.1 (27/7/02)             Page 53
      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.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 54
      APRS Queries


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

          ?APRS?     All stations query. 

          ~\xFD~     UI-View general query.

          The response to both of these is the ID beacon for the port, 
          which, if my recommendations were followed, should contain the 
          APRS position and station type.


      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.1 (27/7/02)             Page 55
      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.1 (27/7/02)             Page 56
      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.1 (27/7/02)             Page 57
      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 stuff 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>:<port>

               e.g. SERVER 128.196.58.1:1314

      The current version doesn't support name resolution, so you MUST 
      supply the IP address not the domain name. The port number must be 
      separated from the IP address by a colon so that the combined 
      address:port forms a contiguous string of characters with no spaces.










      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 58
      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 behavious 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 sucessive tries.

          Specifies the number of seconds to wait between sucessive 
          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.1 (27/7/02)             Page 59
      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.  It's debateable 
      whether or not this ought to happen - if you know better, let me know.  
      This decoding takes place before filtering.

      You should be VERY careful when designing your fiter 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 
      RF, so I suggest as a start you include only traffic FROM your 
      compatriots, and TO them (to include UI-VIEW messages).





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 60
      APRS Internet Gateway


      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 it 
      is simple to change the configuration simply by editing the file using 
      the PZTDOS line editor, then re-starting the daemon.  Editing can take 
      place while the daemon is running because the file is only read at 
      start up.

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











      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 61
      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.  For the moment, you 
      have no choice but to use an external router to make the actual 
      connection, unless you are fortunate enough to have an "always-on" net 
      connection with a spare static IP address.  Windows 98 (and presumably 
      Linux) can be configured to "share" an internet connection, be it of 
      the "dial-up" or "always-on" type.

      I chose to use Windows 98 with a dial-up connection, since the machine 
      was already in use for my email and web activities.  You will need an 
      Ethernet connection between your Windows machine and your Xrouter 
      machine (unless win98 supports non-dialup SLIP ??).  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 Iteret-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.

      If it doesn't work, it's because you haven't configured it correctly!






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 62
      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.1 (27/7/02)             Page 63
      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.1 (27/7/02)             Page 64
      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.1 (27/7/02)             Page 65
      AXIP Tunnelling


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

      AXIP is AX25 "encapsulated" within IP datagrams.  This enables AX25 
      systems to communicate with each other via TCP/IP networks such as the 
      Internet.  At present you may only do this if you and your AXIP peers 
      have STATIC IP addresses.  It will not work via firewalls or internet 
      connection sharing systems which use dynamic address translation.

      In order to set up an AXIP wormhole you need to do the following:

      1)  Find yourself one or more AXIP partners with STATIC ip addresses.

      2)  Set up and test IP routing between you and your partners.
          If you dont have reliable IP routing there's no point in 
          proceeding!

      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 up to 16 AXIP ports, or 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).

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

          PORT=5
              ID=AXIP link with WA3DXX
              INTERFACENUM=7
              CHANNEL=A
              IPADDRESS=63.31.194.21
              IPLINK=55.73.88.69
          ENDPORT

          You must specify at least ID, INTERFACENUM, CHANNEL and IPLINK.  
          IPADDRESS is the IP address you want to use at your end of the 
          link, if different from the router's main address, and IPLINK is 
          the remost host's IP address.  The IP "protocol number" is fixed 
          at 93 (decimal).

          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.

      5)  Have fun!








      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 66
      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.  At present you may only do this if you and your AXUDP peers 
      have STATIC IP addresses.  It will not work via firewalls or internet 
      connection sharing systems which use dynamic address translation.
        
      AXUDP is less efficient than AXIP, as there is an extra protocol 
      overhead due to the UDP layer between the IP and the AX25, and I don't 
      really see any advantage - but I was asked to support it!

      In order to set up an AXUDP wormhole you need to do the following:

      1)  Find yourself one or more AXUDP partners with STATIC ip addresses.

      2)  Set up and test IP routing between you and your partners.
          If you dont have reliable IP routing there's no point in 
          proceeding!

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

          INTERFACE=9
              TYPE=AXUDP
              MTU=256
          ENDINTERFACE

          (Choose the interface number to suit yourself).

          This interface can support up to 16 AXUDP ports.

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

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

          You must specify at least ID, INTERFACENUM, CHANNEL and IPLINK.  
          IPADDRESS is the IP address you want to use at your end of the 
          link, if different from the router's main address, and IPLINK is 
          the remost host's IP address.

          UDPLOCAL and UDPREMOTE are the UDP port numbers for each end of 
          the link, and if omitted they default to 93.

          MAC parameters such as TXDELAY, TXTAIL, SLOTTIME, PERSIST, 
          FULLDUP, SOFTDCD etc. are meaningless for AXUDP, but FRACK, 
          RESPTIME, PACLEN, MAXFRAME, QUALITY etc. operate as normal.

      5)  Try it!





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 67
      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.1 (27/7/02)             Page 68
      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 reconfigured 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.1 (27/7/02)             Page 69
      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.1 (27/7/02)             Page 70
      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 asigned 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.1 (27/7/02)             Page 71
      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.1 (27/7/02)             Page 72
      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.1 (27/7/02)             Page 73
      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 proceedure 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.1 (27/7/02)             Page 74
      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 
      readdressed to 192.168.0.2 and routed to the appropriate machine on 
      the local network, while those addressed to 44.131.91.3 are 
      readdressed 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 readdressed 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.1 (27/7/02)             Page 75
      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 reconfigured 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 
      hinderance.

      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.1 (27/7/02)             Page 76
      Network Address Translation


      Limitations of NAT / PAT
      ~~~~~~~~~~~~~~~~~~~~~~~~
      Unfortunately, NAT and PAT are not completely transparent to the user, 
      and there are certain situtations which it 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 
      there are some protocols which do not use service port numbers at all, 
      so these can not pass through PAT.  For example, ICMP and AXIP can 
      only pass through static NAT, whereas AXUDP 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 tunneling.
           UDP       AXUDP, 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, 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.1 (27/7/02)             Page 77
      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.1 (27/7/02)             Page 78
      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 excuted, 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.1 (27/7/02)             Page 79
      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.1 (27/7/02)             Page 80
      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 unroutable 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.1 (27/7/02)             Page 81
      Configuration Files: ACCESS.SYS


                                   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

      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.1 (27/7/02)             Page 82
      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

      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.
      #
      #
      # 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.1 (27/7/02)             Page 83
      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.

      The file currently processes most ARP, DUN, IP, PPP and RIP commands.  
      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.1 (27/7/02)             Page 84
      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.1 (27/7/02)             Page 85
      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 ebntry 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.1 (27/7/02)             Page 86
      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, so if you make changes to it, they won't have any effect 
      until the next reboot.  If present, it saves you having to enter all 
      the IP routing by hand.  In order to keep the number of files down, 
      this file also contains the permanent ARP (Address Resolution 
      Protocol) entries.

      If you are familiar with IP you can skip this paragraph....  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 in 
      all.  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 record should be on a separate line, and there should be one or 
      more spaces or tabs between each field.  Records are not case 
      sensitive.  Comments are allowed in the file, providing they are on a 
      line beginning with a semicolon.

      All IP routing records 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:

             ROUTE DEFAULT <portnum> [<gateway> [<d|v|n|e>] ]

      <portnum>  is the port number on which to route the datagram.

      <gateway>  is the IP address 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.

      <d|v|n|e>  Mode: (d)atagram, (v)irtual circuit, (n)etrom or (e)ncap.
                 If omitted, the default is "Datagram".  Datagram mode 
                 should be used on links with low loss rates.  Better 
                 performance can be obtained on lossy links by using Virtual 
                 Circuit mode.  Netrom mode is inefficient, but can "tunnel" 
                 datagrams across non-ip parts of the network.  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.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 87
      Configuration Files: IPROUTE.SYS



      At least a port number must be specified. 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".

      The general form of the route add entry is:

             ROUTE ADD <host/bits> <gateway> <portnum> <d|v|n|e>

      <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, the remainder being ignored.  This 
      allows a group of IP addresses to be matched by a single entry.  For 
      instance, 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:

             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 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:







      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 88
      Configuration Files: IPROUTE.SYS


         ARP ADD <host> <ax25 | ether | netrom> <callsign | ether_address>

         or

         ARP PUBLISH <host> <ax25 | ether | netrom> <callsign | ethaddr>

      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.























      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 89
      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.1 (27/7/02)             Page 90
      Configuration Files: PPPHOST.n / USERPASS.SYS


      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 accesed Xrouter.



      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.1 (27/7/02)             Page 91
      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 folowing 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

              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.


      BOTWINTXCOLOR

              See CONSOLE definition section.

      CHATALIAS *

              Alias for chat server (6 chars max).



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 92
      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, 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 conectible.

              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, 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.  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.

              Xrouter chat servers may be interconnected with each other, 
              but *NOT* with "Ping-Pong Converse" servers, because the two 
              systems are completely different (Ping Pong doesn't have local 
              channels for instance).

              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.

              Example: CHATLINKS=G9XOT-8,G7DTY-8


      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".

              Example: CHATQUAL=150







      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 93
      Configuration Files: XROUTER.CFG


      CMDWINBGCOLOR

              See CONSOLE definition section.


      CMDWINTXCOLOR

              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 seperate "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.1 (27/7/02)             Page 94
      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


      DESQVIEW

              Specifies whether or not Xrouter is running within a Deqview 
              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.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 95
      Configuration Files: XROUTER.CFG


              Example: DNS=62.31.176.115


      DXFLAGS

              Optional flags to control the DX heard display (default = 0). 
              Add together required options:

                0   Show directly heard stations
                1   Show digipeated stations

              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.1 (27/7/02)             Page 96
      Configuration Files: XROUTER.CFG


              Example: HOSTNAME=g8pzt.ampr.org


      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.1 (27/7/02)             Page 97
      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 seperate, 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.1 (27/7/02)             Page 98
      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 
              retransmission 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=1 will log all 
              connects, disconnects, user-entered commands and chat server 
              activity. 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.1 (27/7/02)             Page 99
      Configuration Files: XROUTER.CFG


      MIDWINBGCOLOR

              See CONSOLE definition section.


      MIDWINTXCOLOR

              See CONSOLE definition section.


      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).




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 100
      Configuration Files: XROUTER.CFG


              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.

              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 retransmissions will take longer.

              Example: PACLEN=180


      PMSALIAS

              Ax25/Netrom alias for integral PMS (Personal Message System).  




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 101
      Configuration Files: XROUTER.CFG


              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


      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.


      ROUTES

              Specifies one or more NetRom routes to lock in - Syntax is as 
              follows:

              <callsign> <port> <quality> [! [maxframe [frack [paclen]]]]

              You must specify at least Callsign, port and quality.  If you 
              include the lock flag ( ! ) the route will be locked in, and 
              will only be changed by a replacement entry with the lock flag 
              set.

              If you don't include the lock flag, the route will eventually 
              expire if not confirmed by the reception of nodes broadcasts.  



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 102
      Configuration Files: XROUTER.CFG


              In either case, if the file PZTNODES is present, its contents 
              will override the entries here, subject to the locking rules 
              above, and the sysop may also edit routes while the router is 
              running.

              Maxframe, frack and paclen are optional.  If specified they 
              override port defaults for that route.  Note FRACK is 
              expressed in millisecs, e.g. 7000 = 7 secs.  Maxframe > 7 will 
              cause Modulo-128 to be attempted on that route.  The 
              section ends with *** on a blank line.

              Example: Lock in a link to g6yak on port 1 with quality 100 
              and maxframe 32 :-
              ROUTES
              g6yak 1 100 ! 32
              ***


      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.


      TOPWINTXCOLOR

              See CONSOLE definition section.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 103
      Configuration Files: XROUTER.CFG


      TXCOLOR

              See CONSOLE definition section.


      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.1 (27/7/02)             Page 104
      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


      BOTWINTXCOLOR

              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.


      CMDWINTXCOLOR

              Text colour for the command line.  Default is YELLOW.


      CONSOLECALL

              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.

              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.1 (27/7/02)             Page 105
      Configuration Files: XROUTER.CFG


      MIDWINTXCOLOR

              Text colour for the main window.  Default is WHITE.


      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.


      TOPWINTXCOLOR

              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.1 (27/7/02)             Page 106
      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.1 (27/7/02)             Page 107
      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
                     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)
                     HDLC     - For use with SCC cards, YAM modem,
                                INTERNAL interfaces, and some EXTERNAL
                                drivers.









      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 108
      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.1 (27/7/02)             Page 109
      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 separeted 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.1 (27/7/02)             Page 110
      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)

              Example: CFLAGS=2        ; (allow downlinks only)  


      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.1 (27/7/02)             Page 111
      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 
              millseconds.  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.1 (27/7/02)             Page 112
      Configuration Files: XROUTER.CFG


              Example: FULLDUP=1    ; Full duplex


      ID *

              Mandatory text string (30 characters maximum) 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





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 113
      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


      L3ONLY

              L3ONLY=1 prevents users from making AX25 level 2 downlinks on 
              the port, whilst allowing L3/4 (Netrom) operation.

              The default is 0 (L2 and L3/4 allowed).


      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.


      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:




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 114
      Configuration Files: XROUTER.CFG


                     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


      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.




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 115
      Configuration Files: XROUTER.CFG


              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.

              Bi-directional pipes are useful where a BBS has a front end 
              router - simply set up bi-drectional 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 requred 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








      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 116
      Configuration Files: XROUTER.CFG


      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


      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. aproximately
              ((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).



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 117
      Configuration Files: XROUTER.CFG


              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.

              Example: RETRIES=5


      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 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 mumber 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.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 118
      Configuration Files: XROUTER.CFG


              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.  

              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.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 119
      Configuration Files: XROUTER.CFG



      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


      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.1 (27/7/02)             Page 120
      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


      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.1 (27/7/02)             Page 121
      Configuration Files: XROUTER.CFG


      Example XROUTER.CFG file
      ~~~~~~~~~~~~~~~~~~~~~~~~
      The following example is for illustration purposes only, and I have 
      "borrowed" a few callsigns for use in the EXCLUDE, ROUTES and 
      VALIDCALLS fields.  This does not represent my setup.

      ; XROUTER.CFG  Configuration file for Xrouter version 1.76
      ; ========================================================
      ;
      ; 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 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
      ;
      ;       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-6
      ;
      ;       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.1 (27/7/02)             Page 122
      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.
      ;
      ; DNS=62.31.176.115
      ;
      ;       Host name for TCP (optional).  If you omit this, it will default
      ;       to "NODEALIAS:NODECALL".
      ;
      HOSTNAME=g8pzt.ampr.org
      ;
      ;       Chat Server parameters:
      ;       ~~~~~~~~~~~~~~~~~~~~~~~
      ;       Note - the chat server is an integral part of the system and
      ;       cannot be disabled.  You may prevent it from being directly
      ;       connectible (if you wish to deprive users of facilities) by
      ;       setting CHATCALL and CHATALIAS the same as NODECALL and
      ;       NODEALIAS, but it will still be available to all users via
      ;       the "chat" command.
      ;
      ;       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 conectible.
      ;
      CHATCALL=G8PZT-8
      ;
      ;       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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 123
      Configuration Files: XROUTER.CFG


      ;       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
      ;
      ;       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.
      ;


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 124
      Configuration Files: XROUTER.CFG


      ; 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
      ;
      ;       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
      ;


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 125
      Configuration Files: XROUTER.CFG


      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
      ;
      ;
      ;       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.
      ;
      CONSOLE=3
              TOPWINBGCOLOR=SILVER
              MIDWINBGCOLOR=NAVY
              MIDWINTXTCOLOR=WHITE
              CMDWINBGCOLOR=GREEN
              BOTWINBGCOLOR=SILVER
              CONSOLECALL=G8PZT-4
              TXCOLOR=PINK
              RXCOLOR=LIME
      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"
      ;


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 126
      Configuration Files: XROUTER.CFG


      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.

      ***
      ;
      ;       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
      ;


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 127
      Configuration Files: XROUTER.CFG


      SESSLIMIT=255
      ;
      ;       Optional flags to control the DX heard display (default=0)
      ;       Add together:
      ;
      ;               0       Show directly heard stations
      ;               1       Show digipeated stations
      ;
      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.1 (27/7/02)             Page 128
      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
      ;
      ; =======================================================================
      ;       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)
      ;
      ; =======================================================================
      ; 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)


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 129
      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).
      ;
      ;
      ;       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)
      ;                       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 Xon/Xoff 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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 130
      Configuration Files: XROUTER.CFG


      ;       INTNUM=4
              SPEED=9600
              PROTOCOL=KISS
              KISSOPTIONS=CHECKSUM
              MTU=256
      ENDINTERFACE
      ;
      ;
      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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 131
      Configuration Files: XROUTER.CFG


      ;       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
      ;
      ;       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.
      ;       You can attach up to 16 ports to one AXIP interface, or you can
      ;       use separate 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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 132
      Configuration Files: XROUTER.CFG


      ;
      ;       Text string to identify port on "PORTS" display
      ;
              ID=Link to KIDDER
      ;
      ;       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
      ;
      ;       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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 133
      Configuration Files: XROUTER.CFG


      ;       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.
      ;
      ;       RFBAUDS=2400
      ;
      ;       L3ONLY=0                ; 1 = Ban L2 downlinks on this port.
      ;
      ;       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
      ;
      ;       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.
      ;


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 134
      Configuration Files: XROUTER.CFG


      ;       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.
      ;
              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
      ;
      ;       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
      ;
      ;       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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 135
      Configuration Files: XROUTER.CFG


      ;       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
      ;
      ;       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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 136
      Configuration Files: XROUTER.CFG


      ;       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
      ;
      ;       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)
      ;
      ;       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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 137
      Configuration Files: XROUTER.CFG


              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
      ;
      ; ---------------------------------------------------
      ;       Example AXIP (AX25 over IP wormhole) port.
      ;       You need one of these for each axip link
      ;       At least ID, INTERFACENUM, CHANNEL and IPLINK must be specified.
      ;       The IPLINK address is the remost host's IP address.
      ;       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
      ;       CHANNEL=A
      ;       IPLINK=44.73.88.69
      ;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


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 138
      Configuration Files: XROUTER.CFG


      ;       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
      ;
      ; ---------------------------------------------------
      ;       Example AXUDP (AX25 over UDP wormhole) port.
      ;       You need one of these for each axudp link
      ;       At least ID, INTERFACENUM, CHANNEL and IPLINK must be specified.
      ;       The IPLINK address is the remost host's IP address.
      ;       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
      ;       CHANNEL=A
      ;       IPADDRESS=44.131.91.77
      ;       UDPLOCAL=93
      ;       IPLINK=44.69.88.73
      ;       UDPREMOTE=93
      ;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
      ;       Each field is optional - you may have an applname without a call
      APPL=1
              APPLNAME=PBBS
              APPLCALL=G8PZT-3
              APPLALIAS=PZTBBS
              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.1 (27/7/02)             Page 139
      Configuration Files: XROUTER.CFG


      ROUTES
      ;
      ;       Routes to lock in - Syntax is as follows:
      ;
      ;       <callsign> <port> <quality> [! [maxframe [frack [paclen]]]]
      ;
      ;       You must specify at least Callsign, port and quality.  If you
      ;       include the lock flag ( ! ) the route will be locked in, and
      ;       will only be changed by a replacement entry with the lock flag
      ;       set. If you don't include the lock flag, the route will
      ;       eventually expire if not confirmed by the reception of nodes
      ;       broadcasts.  In either case, if the file PZTNODES is present,
      ;       its contents will override the entries here, subject to the
      ;       locking rules above, and the sysop may also edit routes while
      ;       the router is running.
      ;       Maxframe, frack and paclen are optional.  If specified they
      ;       override port defaults for that route.
      ;       Note FRACK is expressed in millisecs, e.g. 7000 = 7 secs.
      ;       Maxframe > 7 will cause Modulo-128 to be attempted on that route.
      ;
      ;       End the section with *** as usual.
      ;
      ; Lock in a link to g6yak on port 1 with quality 100 and maxframe 32 :-
      ;
      g6yak 1 100 ! 32
      ***
      ;
      ;       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.1 (27/7/02)             Page 140
      Configuration Files: PZTNODES


      PZTNODES
      ~~~~~~~~
      This file is identical in format and function to the BPQNODES file 
      used by BPQ for node & route table saving and recovery, except that it 
      doesn't allow digipeaters in ROUTE entries.

      The nodes and routes tables are saved to this file every 
      NODESINTERVAL, at closedown, 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> [!] [<maxframe> <frack> <paclen>]

      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. The remaining parameters are 
      optional.  "!" indicates a locked route (i.e. one which will not 
      expire), and the rest are "non-standard" values which can override the 
      port defaults for that route.

      For example:

      ROUTE ADD G8UZV 1 240 ! 5 7000 120 shows that 
      neighbour node G8UZV is locked in on port 1 with a quality of 240, and 
      will use maxframe=3, frack=7000, paclen=120.


      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 ! G8UZV 1 139
      NODE ADD BRUM:GB7BM G8PZT 1 94 G8UZV 1 92
      NODE ADD BUXTON:GB7DAD-8 G8PZT 1 22 G8UZV 1 21
















      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 141
      Command Reference - User Commands


                          SECTION 3 - COMMAND REFERENCE
                          =============================


      COMMANDS AVAILABLE TO EVERYONE
      ==============================

      The following user commands are available on Xrouter:

      @        ?         AMsg      Arp       Bye       CHat      Connect
      Dx       Echo      Finger    Help      Host      Info      IProutes
      J        Links     MHeard    Nodes     NPing     NRr       Ports
      PIng     Quit      Routes    Stats     Send      Telnet    TTylink
      Users    Version

      Commands are not case-sensitive, and only the portion shown in UPPER-
      CASE is required.


      @        Request sysop status

               Syntax:    @ [string]

               In order to gain access to sensitive commands, remote sysops 
               must first complete a password challenge.  Firstly, the 
               remote sysop enters "@" alone, and the system replies with a 
               matrix consisting of 5 lines of 5 numbers thus:

                     4 1 6 3 7
                     3 5 2 6 3
                     7 1 9 2 4
                     2 7 1 4 6
                     3 5 2 6 1

               The remote sysop must then choose ONE of the lines, and send 
               the "@" command again, followed by the 5 characters from the 
               password string which correspond to the 5 numbers on the 
               chosen line.  There must be a space after the "@" but no 
               spaces between the characters.  The first character of the 
               password string is numbered zero.

               If the challenge is correctly answered, the system replies 
               with "Ok", and the user has remote sysop status.

               If the user does not have a password registered in 
               PASSWORD.SYS, the response to this command will be "Bad 
               command".

               Note:  Console sysops already have full access and don't need 
               to use this command.


      ?        Obtain command list or syntax help

               Syntax:    ? [cmd]

               If used without arguments, this command sends a list of the 
               basic commands available to the user.




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 142
      Command Reference - User Commands


               If the argument is an asterisk (e.g. "? *") it lists all the 
               available commands.

               Using the form "? cmd" shows the syntax for "cmd".


      AMSG     Enter APRS Messaging mode.

               Syntax:  AM[sg] <portnum>

               The AMSG command switches the user's session into APRS 
               messaging mode, enabling him to exchange messages and 
               bulletins with APRS and UI-View users.

               The <portnum> argument specifies the radio port
               upon which traffic will be sent and received. e.g. "AM 13" 
               will use port 13.

               APRS Messaging mode has it's own commands, detailed elsewhere 
               in this document.



      ARP      Display Address Resolution Protocol table

               Syntax:    ARP [ LIST ]

               The ARP command is used to display the Address Resolution 
               Table, which is responsible for mapping IP addresses to 
               callsigns.

               The LIST subcommand is available to everyone, and has the 
               same effect as using ARP by itself.  Other subcommands are 
               available to sysops only (see sysop command section).  The 
               response may look like this:

               G8PZT:KIDDER}
               Host             type        Hw Address
               44.131.74.131    AX25        GB7WV-12
               44.131.90.6      AX25        GB7IPT-9
               44.131.95.240    AX25        GB7GH
               (End of list)

               <host> is the neighbour's IP address, <type> is either "ax25" 
               or "ether" (Ethernet) and <hw_address> is the hardware 
               address or callsign of the neighbour.

               In order for this command to have any meaning, the router 
               must have an IP address and be connected to an IP-capable 
               network.  


      BYE      Disconnect from the router.

               The BYE command forces a disconnection, and is useful when 
               the user does not have easy access to a TNC's "command mode", 
               or when the uplink is from another node with the "stay" 
               option enabled.




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 143
      Command Reference - User Commands


               Disconnection of an uplink terminates all dependent sessions.


      CHAT     Connect to the chat server.

               Syntax: CH[AT]

               The CHAT command connects the user to the integral chat 
               server, which has its own set of commands detailed in a 
               separate section.

               The chat server may also be reached directly by telnetting to 
               the router's TCP port 3600.


      CONNECT  -- Make an outgoing AX25 connection

               Syntax: C[ONNECT] [port] <call> [V[ia] digi[,digi...]] [S]

               The CONNECT command, which may be abbreviated to "C", 
               instructs the router to make an outgoing (downlink) AX25 
               level 2 or 4 connection with another system.

               If the target is a known node (i.e. one which is in the nodes 
               table) a port number is not required, and will be ignored if 
               supplied.  The router will attempt to make a level 4 
               connection with the target, using information from the 
               routing tables.  However, a level 2 connection with an 
               immediately adjacent node may be forced by using the target's 
               alias with an arbitrary SSID, specifying a port number if 
               required (e.g. C 4 MLVN-1)

               If the target is not a known node, the router will attempt to 
               make a level 2 connection.  On multi-port systems, a port 
               number must be specified.

               The "V" (via) parameter allows up to 7 digipeaters to be 
               specified, e.g.:  "C 3 G6YAK V G8NTU G8EPR"

               The "S" (stay) parameter, e.g. "C <nodecall> S" causes the 
               uplink session to stay connected when the downlink session to 
               the target node is terminated.

               See also:  TELNET (nake TCP connections)


      DX       Show best APRS DX

               Syntax: DX [port]

               Providing the router's position is defined, APRS position 
               reports heard by the router will be logged in the DX list, in 
               order of distance.  The sysop may set this up to show only 
               the directly heard stations, or may choose to include those 
               heard via digipeaters.  The response to the DX command looks 
               like this:






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 144
      Command Reference - User Commands


          G8PZT:KIDDER} Dx list:
          Port Callsign  Dist  Dir  Date  Time  Frames      Position       Via
           9   GB7GH     62Km  170  22/08 10:59     72 5151.20N 00205.80W
           4   G6GUH     21Km  325  22/08 05:41      1 5233.38N 00225.80W
           1   G3KFD     13Km   36  21/08 17:38      5 5229.65N 00208.28W
          (End of list)


      DISCARD  Start a sink session.

               Syntax: DI[scard]

               The DISCARD command starts a "sink" session, whereby the 
               router ignores (discards) everything subsequently sent to it.  
               This is useful for testing TNC's, link throughputs etc.

               A DISCARD session can only be ended by disconnection.


      ECHO     Starts an echo session.

               Syntax: ECHO

               After issuing the ECHO command the router will echo back to 
               you anything you send to it, which is useful for link testing 
               etc.  The session is terminated only by disconnection.


      FINGER -- Display information about users.

               Syntax:    FINGER <user | user@host | @host>

               If the command is of the form "FINGER <user>", the router 
               searches the FINGER sub-directory for a text file which 
               matches "user", and sends the contents of that file if it 
               exists.  The file may contain anything you like, and "user" 
               may be a callsign, nickname or other form of hostname 
               consisting of up to 8 legal DOS characters

               If the form "user@host" or "@host" is used, the router will 
               attempt to resolve "host" into an IP address and establish a 
               TCP/IP contact with the finger server on that host.

               Examples:  FINGER g8pzt        Info on local user g8pzt
                          FINGER g8jvm@iptlfd

               Limitations:  This feature is very rudimentary at present, 
                             requiring the user account files to be created 
                             by the sysop.


      HELP      Displays help for commands and other topics

               Syntax:    H[ELP] [cmd | topic]

               If no arguments are given, a short text gives directions on 
               how to access help.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 145
      Command Reference - User Commands


               If the argument is a topic or a command name, the contents of 
               the appropriate file in the HELP sub-directory are displayed.

               The argument "*" will list all the help topics available.

               Example:   H PING    will give help for the PING command.

               Limitations:  The command or topic name must at present be
                             given in full, thus "H NODES" is acceptable, 
                             but "H N" is not (unless you duplicate the 
                             NODES.HLP file to N.HLP).  Future versions will 
                             search for the closest match.

               Note: The help available using the HELP command is intended 
                     to be of use to both sysops and users alike, and is 
                     kept brief in order to avoid wasting airtime.  The MAN 
                     system gives more detailed information for sysops.

                     The sysop may customise the help files, or add his/her 
                     own help topics to the HELP directory as required.  The 
                     HELP directory is located beneath the router's working 
                     directory, and the files are simply plain text files 
                     with the .HLP extension.  Files without the .HLP 
                     extension will not be listed or accessible.

               See also:  ?, MAN, INFO


      HOST     Display information about a TCP/IP host

               Syntax:  HO[st] <hostname> | <ip address>

               Example: ho kidder

               G8PZT:KIDDER} Host name information for kidder:
               Hostname: kidder.ampr.org.
               Address:  44.131.91.245


      INFO     Displays information about the router and other topics.

               Syntax:    INFO [topic]

               If no arguments are given, the INFOMSG text is sent to the 
               user.

               If the sysop has created other INFO topics, the user will 
               then be prompted to enter "INFO *" to display the list of 
               topics.

               If [topic] is specified, the contents of the appropriate .INF 
               file, if it exists, are sent to the user.

               Example:   I FOURPAK      Displays fourpak.inf file.

               Note: The sysop may create INFO topics as required, and
                     there is no need to restart in order to activate them.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 146
      Command Reference - User Commands


                     Each topic should be created as a plain text file with 
                     the .INF extension and should be placed in the INFO 
                     sub-directory located immediately under the router's 
                     working directory.

                     Files without the .INF extension will not be listed or 
                     accessible.

               Limitations:  Topic names must consist of a maximum of 8
                             legal DOS characters.

               See also:  ?,  HELP,  MAN


      IPROUTE -- Display IP routing table.

               Syntax: IPR[OUTE]

               The IPROUTE command, which may be abbreviated to IPR, 
               displays the contents of the table responsible for routing of 
               IP datagrams.

               This table is initialised from file IPROUTE.SYS when the 
               router is started, and may contain other entries "learned" by 
               the system, or entered by the sysop.  It is not required in 
               any way for normal AX25 and NETROM activities.

               For each route it displays the IP address, the subnet mask, 
               the gateway address, the port and the mode (Datagram, VC or 
               Netrom).

               The command "IP ROUTES" produces an identical result.


      J        Displays recently connected stations.

               Syntax: J

               The J command lists the callsigns of the last 20 stations who 
               have connected to the router since it was booted.  The 
               display looks like this:

          G8PZT:KIDDER} Recent users:
          Typ  Usercall               Logoff-time  Mins    From-bytes-To
          L4   G1WXA-6@GB7BHM         22/08 11:06  1          8     1674
          L2   GB7COV-14              22/08 11:06  1        696       93
          L4   GB7PZT@GB7PZT          22/08 10:57  0       1370      236
          L2   G4YUD                  22/08 10:54  2         13      765
          (End of list)

               The "Typ" field shows the type of uplink (L2, L4, TCP, 
               CONsole, TTY etc)

               The "Usercall" field shows the user's callsign.  If it was a 
               Netrom level 4 connection, the user's node is also shown, in 
               the form <user>@<node>.

               The "Logoff-time" field shows the date and time when the user 
               logged off.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 147
      Command Reference - User Commands


               The "Mins" field shows how ling the user was connected in 
               minutes.

               The "Bytes from/to" fields show how many information (i.e. 
               layer 7) bytes were received from, and sent to the user.


      LINKS -- Displays the currently active level 2 sessions.

               The LINKS command lists level 2 user up/downlinks and inter-
               node links.  It is mainly of interest to sysops, and shows 
               the callsigns being used at both ends of the link plus some 
               other data, for example:

               G8PZT:KIDDER} Links:
                Remote Local  Prt Sta Ver Try  T3   Pac  Max  T/o  Txq Rxq Asm
                G4FPV  G8PZT   5   5   2   0   177  160   1   904    0   0   0
                GB7PZT G8PZT   7   5   2   0   181  240   7   908    0   0   0
                GB7GH  G8PZT   9   5   2   0   176  120   1   903    3   1   0
               (End of list)

               Remote and Local are the L2 callsigns in use at either end of 
               the link.

               Prt   - Port number
               Sta   - Link state (2 = connecting, 4 = disconnecting,                      
               5 = connected)
               Ver   - AX25 version number
               Try   - Retry count
               T3    - Current state of the LAPB T3 countdown
               Pac   - Paclen
               Max   - Maxframe
               T/o   - Timeout
               Txq   - No. of L2 frames queued for transmission
               Rxq   - No. of L2 frames on receive queue
               Asm   - No. of frame fragments awaiting reassembly

               Note: The exact format of this response may differ in future 
               versions.


      MHEARD -- List recently heard stations.

               Syntax:    MH[EARD] <portnum>

               If the facility is enabled on the specified port, the MHEARD 
               command lists the most recently heard stations on that port, 
               along with the date / time of reception, 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.






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 148
      Command Reference - User Commands


               If you have included an APRS-style position report in your ID 
               beacon, the router will know its own position and will 
               display position, distance and bearing for any stations 
               which broadcast APRS positions.

               The command may be abbreviated to "MH".

               Example: MH 3 gives a heard list for port 3....

      G8PZT:KIDDER} Heard list for port 3:
      Callsign   Date  Time Frames   Via   Type  Position         Dist Dir
      G1LOA-10   09/06 13:42   309         N
      G3TQG-2    09/06 13:19   599 GB7WV
      GB7PZT-15  09/06 13:18   708
      G3KFD      21/07 23:58   332             5229.65N 00208.28W 13Km 36
      (End of list)

               An entry in the "Via" column indicates a digipeated signal, 
               otherwise the station was heard direct. 
               The "Type" column indicates the type of sender, i.e. whether 
               it is a (D)igipeater, or (N)etrom node, or has (I)P or (A)RP 
               capabilities.

               The "Position" field shows the latitude and longitude of the 
               heard stations (if known), in APRS-style.  5229.65N means 52 
               degrees, 29.65 minutes North of the Equator. 00208.28W means 
               2 degrees and 8.28 minutes West of the Greenwich meridian.

               The "Dir" field shows the direction of the heard station (if 
               known) in degrees clockwise from true North.


               Note: For each port, the MH facility can be enabled /
                     disabled and the maximum length of the list specified 
                     by appropriate entries in the .CFG file.  


      NODES -- Display contents of the Nodes table.

               Syntax:  N[odes] [call | * | F | H | P | Q | R | T | V call]

               When used without arguments, this command lists all the 
               NetRom nodes (but not KA nodes) known to the router, except 
               the "hidden" nodes whose alias begins with the hash (#) 
               character.

               If the argument is an asterisk (*), all nodes, including 
               "hidden" nodes will be displayed.

               If the argument is a known node call or alias, the preferred 
               route to the specified node, and up to two alternative routes 
               will be displayed.  Example: N MLVN  The response looks like 
               this:

               G8PZT:KIDDER} Routes to: MLVN:G4FPV  RTT=28  FR=3538  Q=0
               > 150  5  5 G4FPV
                 110  5  9 GB7GH
                   0  4  2 G1DKI-7




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 149
      Command Reference - User Commands


               RTT stands for Round Trip Time and is a running average of 
               the time taken to get a response from that node.

               FR indicates the number of level 3 frames sent to that node.

               Q is the number of Level 3 frames currently queued for that 
               destination.

               A chevron ">" in the left-most column indicates the currently 
               active route.

               The first number shows the overall path quality to the target 
               node, the second is the "obsolescence count", and the third 
               number is the port designator.
               The obsolescence count is a measure of how recently the route 
               was heard about or used.  It is usually reset to 5 upon 
               hearing a nodes broadcast from the neighbour node, and 
               decrements by one every time this router makes a node 
               broadcast (typically once per hour). If it drops below 4 the 
               route is considered to be obsolete.

               If the requested nodecall or alias is not in the table, an 
               error message results.

               The "N T" command will list the round trip times and frame 
               counts for all nodes which have non-zero figures, producing a 
               display like this:

               G8PZT:KIDDER} Nodes:
                WV12:GB7WV-12     RTT=20  FR=255
                WV13:GB7WV-13     RTT=14  FR=26  Q=2
                WV22:GB7WV-2      RTT=14  FR=31

               The "N F" (frames) variation lists only the nodes to whom one 
               or more frames have been sent.

               The "N H" (hops) command lists only the nodes for whom a "hop 
               count" is known, i.e. the number of nodes a frame must pass 
               through to reach that destination.  It is not always possible 
               to measure the hops via old netrom systems.

               The "N P" (position) command lists only the nodes whose APRS 
               position is known.  This will include immediate neighbours of 
               any software type, and distant Xrouters, providing in each 
               case that their sysops have included their APRS position 
               details in a beacon.

               The "N Q" (queue) command lists only the nodes for whom 
               frames are currently queued.  Since it is a "snapshot" of the 
               state at the time the command was issued, it is likely to 
               produce different results each time, but it allows problems 
               to be identified.

               The "N R" (rtt) command lists only the nodes for whom a Round 
               Trip Time is known.  The RTT is only available for those 
               nodes with whom traffic has been exchanged.






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 150
      Command Reference - User Commands


               The "N V <call>" (via) command lists only the nodes head via 
               the immediate neighbour whose callsign or alias is specified 
               by <call>.

               Examples:
               N           - List nodes except those beginning with #
               N *         - List nodes including those beginning with #
               N MLVN      - Display routes to MLVN node
               N F         - List nodes to whom frames have been sent
               N H         - List the nodes for whom a hop count is known
               N P         - List all nodes whose APRS position is known
               N Q         - List the nodes for whom data is queued
               N R         - List the nodes for whom an RTT is known
               N T         - List all nodes with any non-zero counts
               N V MLVN    - List nodes routed via MLVN node.


      NPING    Send a Netrom echo request

               Syntax: NP[ing] <nodecall | nodealias> [bytes [secs]]

               The NPING command sends an NCMP (Network Control Message 
               Protocol) echo request to the specified target system.  If 
               the target understands NCMP, a reply will be returned, 
               allowing the round-trip-time and number of hops to be 
               determined.  It is intended mainly as a network diagnostic.

               NCMP is under development and is currently implemented only 
               in PZT systems, so you can only NPING another Xrouter.

               The command allows the user to specify an additional data 
               payload, and an interval between pings.  This can be used to 
               assess the consistency of link performance.

               Examples:

               nping gb7gc

               G8PZT:KIDDER} NPING: hit <RETURN> to quit...

               Pinging gb7gc with 0 bytes of data:

               GB7GC: echo reply - rtt 17985 msec, 3 hop(s)

               nping  gb7gc 10 20

               G8PZT:KIDDER} NPING: hit <RETURN> to quit...

               Pinging gb7gc with 10 bytes of data:

               Target             Interval   Sent   Rcvd   %  Ave Rtt
               GB7GC                 20020      1      1  100 5170
               GB7GC                 20020      2      2  100 6930
               GB7GC                 20020      3      3  100 6765


      NRR      Netrom Record Route

               Syntax:  NRR <nodecall | nodealias>



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 151
      Command Reference - User Commands


               This command sends a "record route" packet to the specified 
               netrom target system.  It the target is NRR-capable (e.g. 
               Xrouter, Xnet, Flexnet?), the packet is returned otherwise 
               the packet is ignored by the target.

               Each NRR-capable router along the path inserts its own 
               callsign into the packet, and these are displayed when the 
               reply is received.  Non-capable systems are shown by a 
               question mark "?".  The target is marked by a "*" and both 
               the outgoing and return routes are displayed because they may 
               differ.

               Example: nrr gb7gc

               G8PZT:KIDDER} Request sent
               Route reply:  G8PZT ? GB7GC* ? G8PZT


      PING -- Send ICMP echo request(s).

               Syntax:  PING <hostname | ipaddr> [length [interval]]

               The PING command sends ICMP echo request(s) to the specified 
               IP address or hostname for the purposes of route testing.

               An optional data portion of "length" bytes may be specified, 
               and the echo request may optionally be repeated every 
               "interval" seconds.

               If there is a reply it will be displayed.  For repeating 
               pings the system displays the number sent/rcvd, the average 
               round trip time in milliseconds, and the success rate.  The 
               "wait for reply" process may be cancelled at any time by 
               entering <CR> by itself.

               If you specify a hostname (e.g. gb7pzt.ampr.org) instead of a 
               numeric IP address the request may take longer to action if 
               the hostname isn't found in DOMAIN.SYS, because the name will 
               have to be resolved by sending a DNS request.

               Examples:
                  PING 44.131.91.2           Single ping of minimum size
                  PING 44.131.91.2 50        Single ping with 50 bytes data
                  PING gb7pzt                Uses DNS to resolve host.
                  PING 44.131.91.2 512 10    Ping 512 bytes every 10 secs

               The response for a single ping looks like this:

                  G8PZT:KIDDER} PING: Pinging 44.131.91.2: hit <RETURN> to    
               quit...

                  44.131.91.2: echo reply - rtt 495 msec










      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 152
      Command Reference - User Commands


               And for a repeating ping it looks like this:

               G8PZT:KIDDER} PING:
                 Target             Interval   Sent   Rcvd   %  Ave Rtt
                 44.131.91.2            9955      1      1  100  880
                 44.131.91.2            9955      2      2  100  880
                 44.131.91.2            9955      3      3  100  880

               Limitations: The ROUTER must have an IP address and have IP
                            routing defined for this command to work.  
                            Unrealistic ping rates are prevented.

               Availability: The PING command is currently available to all
                             users, but due to the potential for abuse the 
                             repeating ping option may be made sysop-only in 
                             future versions.


      PMS -- Access the integral PMS

               Syntax:  PMS

               The PMS command connects the user to Xrouter's integral PMS 
               (Personal Message System).  This is a no-frills message 
               storage and retrieval system which can be used to exchange 
               messages between users and sysops.

               If the sysop has defined PMSCALL in XROUTER.SYS, users may 
               perform an AX25 level 2 connect directly to the PMSCALL 
               instead of using the PMS command.  (PMSCALL must not not be 
               the same as NODECALL)

               If PMSALIAS and a suitable PMSQUAL are also defined, users 
               may connect directly to the PMS from another node, using 
               NetRom.

               The PMS has its own simple commands as follows:

               B[ye]           Disconnect from the PMS.
               H[elp]          Display list of commands.
               K[ill] <n>      Kill message number n.
               L[ist]          List messages.
               Q[uit]          Disconnect from the PMS
               R[ead] <n>      Read message number n.
               S[end]          Send a message to sysop.

               If the user accessed the PMS using the "PMS" command, he will 
               be returned to Xrouter's main command prompt upon exit, 
               otherwise he will be disconnected.

               There is no limit to the number of messages or the size of a 
               message.  If no disk is available, messages are stored in RAM 
               and therefore will be lost if the machine is restarted.  If a 
               disk is available, messages are stored on the disk and will 
               persist until killed.







      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 153
      Command Reference - User Commands


      PORTS -- List the available ports.

               Syntax:  P[ORTS]

               Displays the router's port numbers along with their brief 
               descriptions as specified by the PORTID fields in the CFG 
               file.

               The command may be abbreviated to "P".


      QUIT     Disconnect from the router.

               Syntax:  Q[uit]

               The QUIT command performs the same function as BYE, namely to 
               terminate your session with the router.  The disconnection 
               will occur only when all outstanding data has been sent to 
               you.


      ROUTES -- List neighbouring nodes which can be heard directly.  

               Syntax:  R[OUTES] [R <port> | * | X]

               The ROUTES command, which may be abbreviated to "R", lists 
               the immediately adjacent NetRom nodes, i.e. those who can be 
               heard directly, providing those nodes are making NetRom nodes 
               broadcasts.

               For each neighbour node the display shows the port number, 
               the neighbour's callsign, the route quality, and the number 
               of nodes accessible through that neighbour.

               A chevron (>) in the left-most column indicates a route which 
               is in use, and an exclamation mark (!) in the right-most 
               column indicates that the data has been "locked in" by the 
               sysop. See example...

               If any argument is supplied, it will give additional 
               information mainly of interest to sysops.  The additional 
               fields are the current MAXFRAME, FRACK and PACLEN settings, 
               the number of information frames sent, the number of 
               information frames re-sent, the retry rate, which is the 
               ratio of the two preceding figures (or * if both are zero), 
               and the time a nodes broadcast was last heard from the 
               neighbour.

               Examples:
               If no arguments are supplied, the output looks like this:












      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 154
      Command Reference - User Commands


               G8PZT:KIDDER} Routes:
               Port Callsign  Qty Nod
               >  5 G4FPV     150  70!
               >  7 GB7PZT    250   1!
               >  8 GB7WV-12  100  32!
               >  9 GB7GH     150 104!
                 10 GB7CL     150   1!
               > 11 GB7IPT-7  150   3!
                 12 G1LOA-10  150   2!

               The R R form produces an output similar to this:

              G8PZT:KIDDER} Routes:
              Port Callsign Qty Nod Max Frack Pac  Sent Resent Rty%  Last Heard
              >  5 G4FPV    150  70! 5   7000 160 15550   1507   9% 09/06 13:46
              >  7 GB7PZT   250   1! 7   5000 240 25387      4   0% 09/06 13:47
              >  8 GB7WV-12 100  32! 1   4000 120 12170   3426  28% 09/06 13:35
              >  9 GB7GH    150 104! 4   7000 120  7442   1335  17% 09/06 13:47
                10 GB7CL    150   1! 3   7000 240   330      1   0% 09/06 13:23
              > 11 GB7IPT-7 150   3! 2   7000 120 19401   2928  15% 09/06 13:47
                12 G1LOA-10 150   2! 4   7000 120 10745   3379  31% 09/06 13:39

               The "R R 2" form will display only the routes which use port 
               2.

               The "R X" form shows the long term average retry rate (Rty%), 
               plus a "running average" (Now%).  It also records the peak 
               value of the running average (Max%) and the date/time when it 
               occurred.  For example:

      G8PZT:KIDDER} Routes:
      Port Callsign  Qty Nod    Sent  Resent  Rty%  Now%   Max% @dd/mm hh:mm
      >  7 GB7PZT    250   1!  10067       0    0%   0.0    0.0  
      >  9 GB7GH     150  93!    333      17    5%   5.3    5.6  26/08 20:26
      > 12 G1WXA-1   150   2    1231      83    6%   1.6   24.4  26/08 12:37
      (End of list)


      SEND     Send unproto text

               Syntax: SE[nd] <port> <destcall> [V digi,digi,..] <text>

               Sends an unproto (UI) packet on the specified port.  The 
               destination address and up to 8 digis may be specified.  This 
               command is included to facilitate tests.

               Example:  Send 7 CQ V G8EPR,G8AKX Meet me on 144.800!


      STATS -- Display router statistics.

               Syntax:    S[TATS] [L1 | L2 | L3 | *]

               Displays information about the performance of the router, 
               such as the uptime, the no. of packets routed, error rates 
               etc.  See elsewhere in this manual for a detailed explanation 
               of the output.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 155
      Command Reference - User Commands


               Entering S by itself will give a single page synopsis, 
               whereas "S *" will produce the full stats.  "S L1" will show 
               the layer 1 (interface) stats, such as hardware errors.

               Note: On multi-port systems the display may wrap, and on busy
                     systems some of the fields may run together.  The exact 
                     format of the display is not yet finalised and the 
                     problems will be addressed in future versions.


      TELNET -- Establish a TCP "connection".

               Syntax:    TEL[NET] <hostname | ipaddress> [port]

               The TELNET command allows users to "connect" to other TCP/IP 
               systems, using a "shell" account, i.e. the user does not need 
               to be running TCP/IP as the router does all the TCP/IP <> 
               AX25 translation.

               The optional <port> parameter specifies the desired service 
               on the target host.  If not supplied, the default is 23, i.e. 
               the Telnet (remote login) port.  Common port numbers are 21 
               (FTP), 23 (Rlogin), 25 (SMTP), and 87 (TTYLINK).

               Examples:  TEL 44.131.90.6  21  - Connect to gb7ipt FTP.
                          TEL gb7lgs.ampr.org  - Remote login to gb7lgs
                          TEL gb7pzt 25        - Connect to gb7pzt SMTP 

               Limitations: This command will only work if the router has an
                            IP address and IP routing has been defined.  It 
                            should be obvious that the router also needs to 
                            be connected to an IP-capable network!

               Notes: Specifying target hosts by their IP addresses will
                      often result in faster connection if the hostname is 
                      not in domain.sys, as it will not have to wait for DNS 
                      resolution.

               See also: PING


      TTYLINK -- Chat directly to another TCP/IP station

               Syntax:  TT[YLINK] <hostname | ipaddress> [port]

               The TTYLINK command allows users of any type (i.e. AX25, 
               console, wire link, TCP/IP) to chat directly to TCP/IP users.

               This is similar to TELNET, except that the default port 
               number is 87, which is reserved for keyboard to keyboard 
               chat.  Other port numbers may be specified.

               Examples:  TTY 44.131.91.4
                          TTY g8pzt

               Limitations: In order for this command to work, the router
                             must have an IP address and have IP routing 
                             defined.




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 156
      Command Reference - User Commands


               Note: If the target hostname is not known to the router, it
                     will be more efficient to specify the target as an IP 
                     address, since this will not require DNS resolution.

               See also:  TELNET


      USERS Shows who is using the router.

               Syntax: U[SERS]

               The USERS command displays the circuits which originate or 
               terminate at the router.  "Through" connections are not 
               shown.

               No arguments are required, and a typical response is as 
               follows:

               G8PZT:KIDDER} Users:
               Session Start time  S Uplink type/user
                 807  09/06 13:25  1 L4  (G8PZT@GB7PZT) <--> (G6YAK-1) L2

               UPLINK is an incoming connection, and DOWNLINK is an outgoing 
               connection.  The type may be L2 (ax25 level 2), L4 (ax25 
               level 4), TCP (TCP/IP), CON (console i.e. sysop), TTY 
               (Teletype, i.e. an ASCII wire link), or HST (Host 
               application). 

               Established circuits are shown by <-->  and circuits being 
               set up are shown thus:  <~~>.

               SESSION is a unique session number for the circuit.

               For TCP/IP connections the IP address and TCP port number are 
               displayed in place of callsign - this may be subject to 
               future review if I decide to make TCP users supply a callsign 
               at login.

               Unlike the equivalent BPQ command, this does not show the 
               version number - use the VERSION command for that, or buffer 
               count (this system does not use fixed buffers).


      VERSION  Display software version.

               Syntax: V[ERSION]

               The VERSION command displays the router version, author and 
               compilation date.  You should quote the version number when 
               reporting any bugs.


      XLINK -- Establish a temporary interlink.

               Syntax: XLINK <slip | ppp>

               The XLINK command switches a dialled-in connection into the 
               specified mode, allowing TCP/IP operations to be conducted 
               between the caller and Xrouter.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 157
      Command Reference - User Commands


               .cp3
               The temporary interlink persists until the line is 
               disconnected or, in the case of PPP, an inactivity timeout.

               The command is only accepted on MODEM (dial-in) ports.

               Temporary SLIP interlinks require no configuration. Temporary 
               PPP interlinks may optionally be configured by including PPP 
               commands in a PPPHOST.n file, where n is the port number.

               Example: XLINK PPP - Establish PPP interlink.



















































      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 158
      Command Reference - APRS Messaging


      APRS MESSAGING COMMANDS
      =======================

      The APRS messaging system accepts the following commands:

               /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

      All commands and arguments are case-insensitive, and only the first
      letter of the command needs to be given, thus "/H" and "/help" are
      equally valid.

      APRS Messaging Commands In Detail
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      /A       Show Announcements

               Syntax:  /A 

               The /A command lists the APRS announcements received by the 
               router.  They are listed in alphabetical order by sender.

               Announcements have a destination address of the form 
               BLNxCCCCC where x represents a single non-digit and CCCCC 
               represents the category (up to 5 characters). They are 
               transmitted once per hour for 4 days, and incoming 
               announcements are retained for 4 days after last reception.

      /B       Show Bulletins

               Syntax:  /B

               The /B command lists the APRS bulletins received by the 
               router.  They are listed in alphabetical order by sender.

               Bulletins have a destination address of the form BLN#CCCCC 
               where # represents a single digit (0-9) and CCCCC represents 
               the category (up to 5 characters).  They are transmitted 
               every 20 minutes for 4 hours, and incoming bulletins are 
               retained for 4 hours after last reception.

      /C       List / Cancel Undelivered Message(s)

               Syntax:  /C [message #]

               The /C (Cancel) command is used to cancel re-transmission of 
               outgoing messages originated by the user, e.g. "/C 12345" 
               will cancel message number 12345.  Entering /C by itself will 
               list the messages which may be cancelled.




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 159
      Command Reference - APRS Messaging


      /D       List directly heard stations.

               Syntax:  /D

               The /D command gives a brief list of the stations 
               heard directly.


      /H       Obtain help.

               Syntax:  /H [cmd]

               Entering /H alone produces a brief list of the commands and 
               their syntax.

               More detailed help on any of these commands is available by 
               using the "/H <command>" form, e.g. "/H /T" will display 
               help for the /T command.

               The form "H *" will list all the commands and aprs messaging 
               topics for which help is available.


      /M       Query or set traffic monitor mode.

               Syntax:  /M [on | off]

               The /M (Monitor) command controls message traffic monitoring.

               If monitoring is ON, all APRS messages will be displayed.  If 
               monitoring is OFF, only the messages addressed to the user 
               will be displayed.  The default is OFF, and the current state 
               is reported by using /M alone.


      /Q       Quit messaging mode.

               The /Q command quits the APRS messaging session and returns 
               you to the router's main prompt. The /x (exit) command 
               performs the same function.


      /T       Query / Set message target.

               Syntax:  /T [call]

               The /T command displays the current message target or sets a 
               new one.  Messaging is not possible until a target has been 
               set. The target remains in force until cleared or a new one 
               is set.

               The argument can take the following forms:

               CALLSIGN      "message" mode will be used.
               BLN#xxxxx   (# = 0-9) "bulletin" mode, category xxxxx
               BLN@xxxxx   (@ = non-digit) "announcement" category  xxxxx
               .           Any punctuation character clears target.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 160
      Command Reference - APRS Messaging


      /U       Query / Set UI-View messaging mode.

               Syntax:  /U [on | off]

               The /U (UI-View) command displays and sets "UI-View" 
               messaging mode.  If no argument is given, the current mode is 
               reported.  If UI-View mode is on, outgoing msgs use UI-View 
               format, and if UI-View mode is of, outgoing msgs use APRS 
               format.

               The default mode is "off".  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.


      /V       Query / Set digipeater (via) path.

               Syntax:  /V [digi,digi,...]

               The /V (Via) command queries or sets the digipeater path for 
               outgoing messages as follows:

                  /V               Display current path
                  /V RELAY,WIDE    Set path to RELAY,WIDE
                  /V .             Clear path (no digipeaters)

               The path remains in force until cleared or a new path is 
               specified.


      /X       Exit messaging mode.

               Syntax:  /X

               The /X command quits the APRS messaging session and returns 
               the user to the router's main prompt. The /q (quit) command 
               performs the same function.























      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 161
      Command Reference - Chat Server


      CHAT SERVER COMMANDS
      ====================

      The following commands are available within the chat server only.

      /?       /BYE      /CHANNEL  /EXIT   /HELP     /JOIN     /LEAVE
      /LINKS   /MSG      /NAME     /PERSONAL /QUIT   /TOPIC    /USER
      /WHO     /VERSION


      CHAT SERVER COMMANDS IN DETAIL
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Note that the server is still experimental, and the syntax of these 
      commands may be changed in future versions.  Additional commands will 
      be added as required.


      /?       Display commands / syntax help.

               Syntax: /? [cmd]

               When used without arguments, the /? command lists the 
               available commands.  The syntax for any of the commands thus 
               listed may be shown by specifying the command as an argument 
               to the /? command.

               Examples:  /?          List available commands.
                          /? /who     Display syntax for the /WHO command.



      /BYE    Exit the chat server.

               Syntax: /B[ye]

               The /BYE command, which may be shortened to /B, disconnects 
               the user from the chat server, and informs everyone that he's 
               left.  There is no need for the user to /leave any logged 
               channels before issuing this command.

               If the user accessed the server via the router's CHAT 
               command, he will be returned to the router's main command 
               prompt, otherwise he will be completely disconnected.

               The /EXIT and /QUIT commands also perform this function.


      /CHANNEL  Display / Change logged channel(s).

               Syntax: /C[hannel] [number]

               The /CHANNEL command displays / changes the channel(s) the 
               user is logged to.  When no argument is supplied, the logged 
               channel(s) is / are displayed.  If a valid numeric argument 
               is supplied, the user is logged to the specified channel.

               Examples: /C        Displays current logged channel(s)
                         /C 22     Change to channel 22




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 162
      Command Reference - Chat Server


               When a new channel is selected, the user remains logged to 
               any previous channels, (so he can "monitor" several channels 
               at once) but any subsequent text he sends will go to the new 
               channel (unless targeted otherwise).

               Note: Channels 0 to 255 are "local" to each chat server, and 
               channels 256-32767 are "global", i.e. they are linked with 
               all other servers. 

               The /JOIN command has a similar function, and /LEAVE is used 
               to de-select unwanted channels.


      /EXIT    Exit the chat server.

               Syntax: /E[xit]

               The /EXIT command, which may be shortened to /E, disconnects 
               the user from the chat server, and informs everyone that he's 
               left.  There is no need for the user to /leave any logged 
               channels before issuing this command.

               If the user accessed the server via the router's CHAT 
               command, he will be returned to the router's main command 
               prompt, otherwise he will be completely disconnected.

               The /BYE and /QUIT commands also perform this function.


      /HELP    Obtain help.

               Syntax: /HELP [topic]

               When used without arguments, the /HELP command gives brief 
               instruction on how to access various levels of help.

               If a topic is specified, detailed help for that topic (if 
               available) is displayed.  The topic may be a command name, or 
               any other chat server related topic.  A list of the available 
               help topics can be obtained by specifying "*" as a topic.

               Examples:  /H          Display general instructions.
                          /H *        List available help topics.
                          /H /who     Display help for /WHO command.

               Note:  When using /H to display help for a command, the         
               leading slash for that command may be omitted.  Thus         
               "/H /who" and "/H who" are equally permissible.


      /JOIN    Join (log onto) a channel.

               Syntax: /J[oin] <channel>

               The /JOIN command logs the user to a channel, and performs a 
               similar function to the /CHANNEL command.






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 163
      Command Reference - Chat Server


               When a new channel is selected, the user remains logged to 
               any previous channels, (so he can "monitor" several channels 
               at once) but any subsequent text he sends will go to the new 
               channel (unless targeted otherwise).  (Unwanted channels may 
               be de-selected using the complementary /LEAVE command.)

               Example:  /J 22   Join channel 22

               Note: Channels 0 to 255 are "local" to each chat server, and 
               channels 256-32767 are "global", i.e. they are linked with 
               all other servers. 


      /LEAVE   Leave (log off) a channel.

               Syntax: /L[eave] <channel>

               The /LEAVE command logs the user off the specified channel.  
               When a user joins a channel, he remains logged to any 
               previous channels, so this command allows him to de-select 
               unwanted channels.

               Example:  /L 22   - Leave channel 22


      /MSG     Send a short message to a channel or a single user.

               Syntax: /M[sg] <channel | callsign> <text>

               The /Msg command is used to send a short message (70 chars 
               max.) to any specified channel or single user.  You may for 
               example use this command to direct a message to a channel you 
               are monitoring, but not actually logged to.

               If you direct a message to a specific user, he may be on this 
               or any other chat server.  The private nature of the message 
               will be indicated to the recipient by asterisks around the 
               sender's call, e.g. <*g8pzt@kdchat*> (Paula): Meet me on 
               channel 69.

               Examples: /M 32 Hello People
                         /M g6yak Meet me on channel 69

               The first form sends "Hello People" to all the users of 
               channel 32, and the second form sends a private msg to g6yak 
               only. Providing G6YAK is logged on to any chat server, the 
               message will find him.

               Note: As with all things Packet, the term "private" is 
               relative, as nothing is truly private when it is broadcast!


      /NAME    Set name.

               Syntax:  /N[ame] <your name> [channel]

               The /NAME command sets the user's name, which will be 
               displayed on the user list and prefixed to everything he 
               sends to others.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 164
      Command Reference - Chat Server


               Users are not allowed to join any channels until they have 
               supplied a name (12 chars max), so it acts as a "log on" 
               command.  The name need be supplied only at the initial 
               logon, and may be changed as the user wishes.

               On the first use of this command, the user may optionally 
               specify a channel to join instead of the default (channel 0).

               TCP/IP users must first use the /USER command (see below) to 
               enter their callsign.

               Examples: /N Paula       Set name to "Paula"
                         /N Paula 23    Set name and join channel 23


      /PERSONAL  Display / change personal description.

               Syntax: /P[ersonal] [text | @]

               The /PERSONAL command is used to display or change the user's 
               personal description.  This is a short text of up to 32 
               characters, which is displayed on the user list.  It may 
               typically contain the user's home town and "brag" 
               information.  If the user logs onto any "public" channels 
               (i.e. those above channel 255), this information will appear 
               on the user lists of all other chat servers.

               If used without arguments, the /PERSONAL command displays the 
               user's current text.  

               If the argument is "@", the existing text is removed.

               Examples: /P                        - Displays current text
                         /P Kidderminster, sysop   - Set new text.
                         /P @                      - Clear previous text.


      /QUIT    Exit the chat server.

               Syntax: /Q[uit]

               The /QUIT command, which may be shortened to /Q, disconnects 
               the user from the chat server, and informs everyone that he's 
               left.  There is no need for the user to /leave any logged 
               channels before issuing this command.

               If the user accessed the server via the router's CHAT 
               command, he will be returned to the router's main command 
               prompt, otherwise he will be completely disconnected.

               The /BYE and /EXIT commands also perform this function.


      /TOPIC   Display / Change channel topic.

               Syntax: /T[opic] [channel] [text | @]






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 165
      Command Reference - Chat Server


               Every channel has an optional topic, and the /TOPIC command 
               can be used to display the existing topic or change it.  The 
               topic can be up to 12 characters, and is displayed on the 
               /Who list.

               Examples: /T                        - Show current ch. topic
                         /T 32                     - Show channel 32 topic
                         /T 32 TCP/IP discussion   - Set topic for ch. 32
                         /T @                      - Clear topic.


      /USER    TCP/IP logon.

               Syntax:  /U[ser] <callsign> [name]

               The /USER command is available only to TCP/IP users.  It sets 
               the user's callsign (and optionally his name), which will be 
               displayed on the user list and prefixed to everything he 
               sends to others.

               The user will not be able to join the conference without 
               supplying both callsign (9 chars max) and name (12 chars 
               max), but if the name is omitted from this command he may 
               enter it in the normal way with the /Name command.

               Examples: /U g8pzt          - Set callsign to "g8pzt".
                         /U g8pzt Paula    - Set callsign and name.


      /VERSION  Display chat server version.

               Syntax: /V[ersion]

               The /VERSION command displays the chat server version, author 
               and compilation date.  Please quote it if reporting bugs.


      /WHO     List channels and users.

               Syntax: /W[ho] [*]

               The /WHO command lists who is logged onto the chat server, 
               and what channels they are on.

               If no arguments are supplied, the active channels are listed, 
               along with the callsigns of their users.

               If an asterisk is supplied as the argument, each user is 
               displayed in more detail.  The display would typically show 
               the user's callsign, name, personal text and logon date/time.

               Examples:  /W     Lists channels & users in brief format
                          /W *   Lists users in detail









      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 166
      Command Reference - Sysop-only Commands


      SYSOP-ONLY COMMANDS
      ===================

      The following commands are available only to sysops.  Some of them, 
      e.g. ARP are repeated from above, but with extra facilities.


      ARP -- Display / Edit the ARP table.

               Syntax: ARP [ADD <host> <hwtype> <addr>]
                       ARP [DROP <host> <hwtype>]
                       ARP [LIST] 

               The ARP command is used to display and edit the Address 
               Resolution Table, responsible for mapping IP datagrams to 
               callsigns.

               If no arguments are supplied, the table is listed.

               ADD        adds an entry to the table. 
               DROP       deletes an entry.
               LIST       lists the table.
               FLUSH      Removes temporary (learned) entries
               PUBLISH    Adds an entry on behalf of a hidden system

               <host> is an IP address in dotted quad form.

               <hwtype> is the hardware address type, i.e. "ax25", "ether", 
               or "netrom".

               <addr> is the hardware address, i.e. callsign or ethernet 
               address.  It is possible to route IP through digipeaters, by 
               including the digipeaters callsigns as part of the ax25 
               address.  The ax25 destination and digis must form a single 
               comma-delimited string. 

               The PUBLISH option is typically used in cases where one 
               system is "hidden" (i.e. only routable via) a "front end" 
               router, and instructs the front end router to respond to ARP 
               requests for the hidden system's address.  In this case 
               <host> is the IP address of the hidden system, and <addr> is 
               the hardware address of the front end router.

               Examples:
               ARP ADD 44.131.91.2 ax25 gb7pzt-5         Add ax25 entry
               ARP ADD 44.131.91.66 ax25 g8bkl,g6yak     Use digis
               ARP DROP 44.131.91.7 ax25                 Delete ax25 entry
               ARP PUB 44.131.91.77 ax25 g8pzt-7         Publish 91.77
               ARP LIST                                  List the table
               ARP                                       List the table


               Availability:
               The LIST subcommand is available to everyone, but ADD and 
               DROP are sysop-only.







      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 167
      Command Reference - Sysop-only Commands


               Note: 
               In order for this command to have any meaning, the router 
               must have an IP address and be connected to an IP-capable 
               network.


      AXROUTES -- Display AX25 level 2 circuits

               Syntax: AX[ROUTES]

               The AXROUTES command displays information about active and 
               recently active AX25 level 2 connections, allowing the sysop 
               to monitor the performance of the links between the router 
               and its users.

               Entries are purged 24 hours after they were last active, 
               unless they are "locked" (indicated by "!" after the 
               callsign), i.e. in use by level 3.

               A typical display looks like this:

      Por Callsign   M Pac  F RTT   Sent Resent  Rty   Rcvd   Lost  Rol Date/Time
      >5  G4FPV    ! 5 160  7   5  24217   1265   5%  24010    984   4% 28/01 09:46
      >7  GB7PZT   ! 7 240  5   1 100884      0   0% 129788      0   0% 28/01 09:46
      >8  GB7WV-12 ! 1 120  4   2  14456   3348  23%  14218    753   5% 28/01 09:46
      >9  GB7GH    ! 4 120  7   3  16591    511   3%  14965      4   0% 28/01 09:43
       10 GB7CL    ! 3 240  7   2   1122     55   4%   1009      5   0% 27/01 23:32
      >11 GB7IPT-7 ! 2 120  7   5 104483  15436  14%  46589   8344  17% 28/01 09:46
       12 GB7BM    ! 4 120  7   4  13562   1598  11%   5626     57   1% 28/01 09:36
       8  WV12-1     1 120  7   2   3362    999  29%    918     38   4% 28/01 08:07
       12 BRUM-1     4 120  7   5  10730    593   5%   1503     52   3% 28/01 09:45
       1  G1ZRN      2 160  7   2   3693    164   4%    949     14   1% 28/01 02:24
       4  G3MRC      2 120  7   5   4937    160   3%     35      0   0% 27/01 23:38
       1  G0NXB      2 160  7   3   1485     89   5%     96      0   0% 27/01 19:37
       1  G6YAK-2    2 160  7   3     26      2   7%     23      0   0% 27/01 22:46
       1  G0EWH      2 160  7   4   1687    325  19%    213      2   0% 27/01 16:46
       1  G4SPZ      2 160  7   2    222     10   4%     83      8   9% 27/01 20:43
       1  G4MTG-2    2 160  7   3     10      0   0%      5      0   0% 27/01 11:17
       1  G0HTF      2 160  7   4    332     13   3%     63     11  17% 28/01 09:45
       6  G3PWJ      2 160  7   3     18      0   0%      3      0   0% 27/01 23:56
       1  G7UBX      2 160  7   2     27      1   3%      6      0   0% 28/01 08:46
       1  M0ALH      2 160  7   4      8      1  12%      5      2  40% 28/01 09:24
      (End of list)

               The display shows the port number and callsign, with a 
               chevron ">" in the leftmost column in the link is currently 
               active. "M", "Pac" and  "F" are the Maxframe, Paclen and 
               Frack last used on that link.  They may be the same as the 
               port or global defaults, or they may have been modified by 
               the router to suit link conditions

               "RTT" is the Round Trip Time in seconds, i.e the average time 
               from sending a packet to receiving an ack for that packet.  
               This is dependant on many variables, such as the packet size, 
               the quality of the link, the data rate, the amount of queued 
               data, the TXdelay and Resptime intervals at each end etc...






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 168
      Command Reference - Sysop-only Commands


               "Sent" is the total no. of L2 frames sent to that staion, and 
               "Resent" is the number of frames which had to be retried. 
               "RTY%" is the ratio of these expressed as a percentage.

               "Rcvd" is the total no. of L2 frames received from that 
               station and "Lost" is the number which were lost and had to 
               be re-sent from the other end.  "Rol" is "Rate Of Loss", 
               which is effectively the retry rate which would be seen by 
               the other station.

               Finally, Date/Time shows when the station was last heard.


      CAPTURE -- Enable / disable tracing to disk file.

               Syntax:  CAP[TURE] [on | off]

               The CAPTURE command is used to enable or disable the tracing 
               to disk of incoming and outgoing traffic. 

               When capture is enabled, anything which is displayed in the 
               central 22 line window is written also to disk.  This 
               includes session activity and TRACE'd data.  Whereas the 
               screen display is filtered to prevent it being garbled by 
               binary data, the capture is pure binary, so it is useful for 
               diagnostics.

               The optional argument may be "ON" or "OFF".  If no argument 
               is supplied, the current setting is reported.

               This command overrides the <F5> (toggle capture) key.

               The console may override a remote sysop's settings.

               Example:  CAP ON  -  Enables capture.

               Note: You are advised not to enable long-term capture on a 
               floppy based system otherwise performance will be 
               compromised.

               See also:  MONITOR


      CTRL     Read / Write remote hardware control port.

               Syntax: CTRL [0-255]

               The CTRL command reads from and writes to the CTRL port 
               defined in the CFG file (e.g. CTRL=0378 to use LPT1).  This 
               is used for controlling external hardware devices via logic, 
               and reading status from them, for example transmitter 
               bank switching or temperature alarm monitoring.

               "CTRL" by itself reads the port, and "CTRL <value>" writes 
               it.  The read value is the OR of last written value and 
               external levels, so a bit must be written to 0 in order to use 
               it as an input.  If written to 1, a bit will always return 1.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 169
      Command Reference - Sysop-only Commands


      DATE -- Enquire / set system date

               Syntax:  DATE [dd/mm/yy[yy]]

               If no argument is supplied, the existing system date is 
               shown.

               If the user is a sysop, and the argument is a valid date of 
               form dd/mm/yy or dd/mm/yyyy the system date is set to the new 
               value.

               Example:  DATE 24/2/99

               See also: TIME


      DHCP -- Display DHCP-obtained IP configuration parameters.

               Syntax:  DHCP <port>

               For ports on which the DHCP Dynamic Host Configuration 
               Protocol) client is enabled, the DHCP command displays the IP 
               configuration parameters which have been obtained via DHCP.

               Parameters displayed include: IP address, DHCP server 
               address, gateway IP address, primary DNS address, lease 
               expiry time, and DHCP state.

               DHCP is enabled by including the "DHCP=1" directive in the 
               relevant PORT block within XROUTER.CFG.


      DIAL -- Dial a PSTN connection.

               Syntax:  DIA[l] <port> <script>

               The DIAL command invokes the named Dial Up Networking (DUN) 
               script on the specified port.

               This command will have no effect unless the port is connected 
               to a PSTN modem, the interface protocol is defined as 
               MODEM, and the script file exists.

               Example: DIAL 1 AOL.SCR

               See also:  DUN - dial up networking


      DIGIFLAG -- Display / Set digipeat options.

               Syntax: DIGIFLAG <port> [0-255]

               The DIGIFLAG command is used to display and/or set the 
               digipeat options for a port.

               New settings override those read from the CFG file, and 
               remain in force until changed, or the system is restarted.

               The digipeat options value is the sum of the following:



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 170
      Command Reference - Sysop-only Commands


                     0        No digipeating on this port
                     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
                     64       Enable gating from Packet to Internet.
                     128      Enable gating from Internet to Packet.

               The minimum abbreviation of this command is DIGIF.

               Examples: DIGIF 3        - Enquire setting for port 3
                         DIGIF 3 255    - Set port 3 digiflag to 255

               See also: DIGIPORT - Set port to digipeat on


      DIGIPORT -- Display / Set port to digipeat on.

               Syntax:  DIGIPORT <port> [destport]

               Displays or specifies the port upon which digipeated frames 
               should be transmitted.

               If "destport" is not specified, the current setting is 
               displayed.

               If "destport" is zero, frames are transmitted on the port 
               upon which they are received, otherwise they are transmitted 
               on the port specified.

               The minimum abbreviation of this command is DIGIP.

               Example: DIGIP 3 5   - Digipeat from port 3 to port 5

               Limitations:  Frames may currently be digipeated only to one
                             port.  In order for a BBS on one port to 
                             broadcast unproto headers to several ports at 
                             once, the BCAST option must be used instead.

               See also:  DIGIFLAG - Control type of frames digipeated


      DNS -- Domain Name Server commands.

               Syntax: DNS <<add | drop> <ipaddr>> | <list>

               The DNS commands are used to add and delete Domain Name 
               Servers from the DNS list, and to display the list.

               Domain Name Servers are external TCP/IP hosts which are used 
               to resolve host names, for example "bbc.co.uk", into IP 
               addresses, when the information is not found locally in 
               DOMAIN.SYS.








      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 171
      Command Reference - Sysop-only Commands


               In order for Xrouter to use this process, it needs to know 
               the IP addresses of suitable DNS's.  These can be specified 
               at boot time by including one or mode commands "DNS=<ipaddr>" 
               in XROUTER.CFG.  Alternatively, the DNS ADD command may be 
               used at any time.

               The "DNS DROP" comand is used to delete a nameserver from the 
               list, and "DNS LIST" displays the list.

               Examples: DNS ADD 62.31.117.22
                         DNS DROP 44.131.88.73


      DOS -- Enter PZTDOS command mode.

               Syntax: DOS

               The DOS command switches the command interpreter into "DOS 
               mode", allowing local and remote sysops to use familiar DOS 
               commands to maintain the system without taking it off line.

               In this mode, the normal command prompt is replaced by a DOS-
               style $P$G prompt showing the current drive and directory, 
               and only the PZTDOS commands are understood.

               The operator must use the EXIT command to return to normal 
               command mode.

               Sessions automatically return to command mode upon 
               disconnection. 

               PZTDOS accepts both the MSDOS backslash (\) and the UNIX 
               forward slash (/) pathname separator characters, and they may 
               be freely mixed.  For the sake of clarity however, the prompt 
               always displays the path using the MSDOS convention, as this 
               is familiar to the most users.

               As in MSDOS and UNIX, when specifying pathnames, a single dot 
               (.) represents the current directory, and a double dot 
               represents the parent directory.  Thus a command such as "CD 
               ../FRED" would change to directory FRED, which is located off 
               the current directory's parent.

               Unlike MSDOS, PZTDOS does not maintain a separate "current 
               directory" on each drive, and you will be logged to the root 
               when changing drives.  The normal A: B: etc. commands can be 
               used to change drive, and the CD (change directory) command 
               can also accept a drive letter.

               Notes:
               PZTDOS is fully multitasking, i.e. normal router operation 
               continues while PZTDOS mode is operating.

               Console sysops may also invoke a conventional dos "shell" 
               using the <F9> key, for running commands and programs not 
               available within PZTDOS.






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 172
      Command Reference - Sysop-only Commands


               This mode is NOT multitasking and normal router operation is 
               suspended for the duration of the shell.  The operator must 
               limit the duration of the shell session otherwise the 
               software watchdog (if enabled) will reboot the system.
               TSR's and programs which interfere with the timer or serial 
               ports should not be invoked from a shell as they may lock up 
               the router or affect its performance.  Shell sessions are 
               ended with the EXIT command.


      DUN -- Dial Up Networking configuration commands.

               Syntax: DUN A[dd] <callsign | ip_address> <script>
                       DUN D[rop] <callsign | ip_address>
                       DUN L[ist]
                       DUN LO[g] [0-255]

               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.  The DUN commands are 
               used to configure this subsystem.

               DUN ADD creates an association between a callsign (for KISS 
               links) or gateway IP address (for PPP or SLIP links) and a 
               DUN script.

               DUN DROP removes a previously created association between a 
               callsign or gateway IP address and a DUN script.

               DUN LIST lists the peers to whom a dial-up connection may be 
               established, and the names of the scripts used to make the 
               connections.

               DUN LOG sets the level of logging, for diagnostic purposes.  
               The argument is a flag field, comprising the sum of the 
               following values:

                      1       Log starts, stops and errors.
                      2       Log all script lines.
                      4       Log responses from modem or host.

               A value of 0 disables all logging.  If no arguments are 
               supplied, the current logging level is reported.

               Examples: DUN ADD gb7tyr  gb7tyr.scr
                         DUN ADD 62.31.176.22  pipex.scr
                         DUN DROP 62.31.176.22
                         DUN LOG 3

               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.


      FRACK -- Display / Set FRACK for a port.

               Syntax:  FRACK <port> [msec]





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 173
      Command Reference - Sysop-only Commands


               Displays the current FRACK (AX25 level 2 T1 timer) setting 
               for the specified port, or allows it to be changed.

               If the second argument is omitted, the current value is 
               displayed, otherwise the value in milliseconds is used.

               The new setting overrides the value specified in the CFG 
               file, and remains in force until changed or the next restart.

               Examples:  FRACK 2          - Display port 2 frack setting
                          FRACK 2 6000     - Set port 2 frack to 6 seconds

               Note: A typical FRACK setting for 1200 baud is 7000 (7 secs),
                     and specifies how long AX25 will wait for a level 2 ack 
                     before requesting confirmation.  Setting this figure 
                     too low is antisocial, achieves nothing, and could 
                     result in the link retrying out.


      FULLDUP -- Display / Set full duplex mode.

               Syntax:  FULLDUP <port> [0 | 1]

               Displays the current duplex setting for a port, and allows it 
               to be changed without restarting the system.  If port is 
               operating in full duplex mode, DCD is ignored and the port 
               will transmit whenever it has anything to send.

               If two numeric arguments are supplied, the duplex flag is set 
               to the second argument, otherwise the current setting for the 
               specified port is displayed.  Values are: 0 - simplex, 1 - 
               full duplex.

               Modified settings remain in force until changed or system is 
               restarted.

               Example:  FULLDUP 3    - Display current setting for port 3
                         FULLDUP 3 1  - Set port 3 into full duplex mode

               Note: On KISS ports, allow up to 5 minutes for modified
                     settings to reach the TNC.


      IP -- Display / Change IP parameters and routing table.

               Syntax:
               IP ROUTES
               IP ROUTE ADD <host>[/len] <gateway> <port>
               IP ROUTE DROP <host> <len>
               IP ROUTE DEFAULT <port> [gateway [d|v|n]]
               IP ROUTE LOOKUP <host>
               IP TTL [1-255]
               IP QUIET [0-255]
               The IP commands are used to display and alter IP parameters, 
               and the IP routing table.

               The IP route table contains a series of entries which are 
               checked whenever a datagram is routed.  The entry which 
               matches the destination address and mask with the highest 
               number of bits is the one which will route the datagram.


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 174
      Command Reference - Sysop-only Commands



               The IP ROUTE command arguments are as follows:

               <host>      Target host IP address in dotted quad form.
               <len>       No. of bits to be matched (from left) 0-32
               <gateway>   Destination gateway IP address in dotted quad. 
               <port>      Port number on which to route the datagram.
               <d|v|n|e>   Mode: (d)atagram, (v)irtual circuit, (n)etrom
                           (e)ncapsulated

               The IP ROUTE DEFAULT command sets up a default route which is 
               used when no other route is found.  If no gateway is 
               specified, the target will be assumed to be a direct 
               neighbour.  If not specified, the mode defaults to datagram.

               The IP ROUTE ADD command adds an entry to the routing table.  
               The first argument is the target host IP address, with 
               optional mask. e.g. 44.131.90.1/32 means "match all 32 bits", 
               whereas 44.131.90.0/24 means "match the most significant 24 
               bits", and would route all 256 addresses from 44.131.90.0 to 
               44.131.90.255.

               The second argument is the "gateway" address, i.e. the 
               address of the system which can handle the datagram.  Use the 
               special entry "*" if the target host is reached direct, i.e. 
               not via another router.

               The third argument is the port to route the datagram on, and 
               the last argument is the mode.

               Datagram mode should be used on links with low loss rates.  
               Better performance can be obtained on lossy links by using 
               Virtual Circuit mode.  Netrom mode is inefficient, but can 
               "tunnel" datagrams across non-ip-capable parts of the ax25 
               network.  Encap mode (IP/IP) is for tunnelling amateur IP 
               across non-amateur IP networks.

               The IP ROUTE DROP command removes an entry from the table.  
               Both the target host and the mask must match.

               The IP ROUTE LOOKUP command is used to checks if there is a 
               known route to a specified host.

               The IP ROUTE LOAD command deletes all routes and re-loads the 
               information from the IPROUTE.SYS file.

               The IP TTL command displays or sets the "Time To Live" for IP 
               datagrams, overriding the value specified in the .CFG file.

               The IP QUIET command is used to display or set the "stealth" 
               level.  The default value of 0 causes TCP/IP to operate 
               normally.  A non-zero value disables various ICMP and TCP 
               error responses, and should be used with caution.  Please 
               refer to the manual entry STEALTH for more information.








      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 175
      Command Reference - Sysop-only Commands


               Examples:
               IP ROUTE DEFAULT 3 44.131.90.6 v
               IP ROUTE ADD 44.131.95.0/24 44.131.95.240 9 d
               IP ROUTE DROP 44.131.97.1 32
               IP ROUTE LOOKUP 62.31.87.22
               IP TTL 127
               IP QUIET 2

               Availability: The only command available to non-sysops is "IP 
                             ROUTES".

               Note: The IP routing table is necessary only for IP, and does
                     not take any part in normal ax25 and Netrom activities.  
                     See elsewhere for details on how to set up the IP 
                     system.

               See also: IPROUTE, ARP.


      KILL -- Terminate any session

               Syntax:  KILL <session>

               KILL immediately terminates the specified session, 
               disconnecting any links involved.  Useful for disconnecting 
               troublemakers or failed sessions.

               Session numbers are shown by the U(sers) command.

               Example:  K 301  - Terminate session numbered 301

               Limitations:  You cannot kill your own session.


      LOADNODES -- Load the nodes and routes tables from a disk file.

               Syntax:  LO[ADNODES] [filename]

               The LOADNODES command loads the nodes and routes tables from 
               a "recovery" file.  If a filename isn't specified, PZTNODES 
               is the default.  It can be used to reconstruct the tables 
               without having to wait for nodes broadcasts to be received.

               This occurs automatically when the router is started, but if 
               the PZTNODES file was empty, you may wish to quick start from 
               a daily or weekly backup file which you previously created 
               with SAVENODES.


      LOG -- Enable / disable activity logging.

               Syntax:  LOG [on | off]

               The LOG command is used to enable or disable the logging of 
               router activity, such as connections, disconnections, errors, 
               user commands etc.  It overrides the default setting 
               specified in XROUTER.CFG.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 176
      Command Reference - Sysop-only Commands


               The optional argument may be "ON" or "OFF".  The former 
               enables logging, and the latter disables it.  If no argument 
               is supplied, the current setting is reported.

               The console may override a remote sysop's settings.

               Examples:  LOG ON  -  Enables logging.
                          LOG OFF -  Disables logging.

               Note: Do not enable long-term logging if you are running a 
               floppy based system, as you will seriously compromise system 
               performance.


      MAN -- Display Online Sysop's Manual pages.

               Syntax:  MAN [command | topic]

               The MAN command is used to access the online sysop's manual, 
               which is a collection of pages, each covering a different 
               command or topic.

               The MAN pages are designed for sysop use, and usually give 
               more detail than the corresponding HELP pages.

               Entering MAN alone displays a list of available pages.

               To read a specific page enter MAN followed by the command or 
               topic for which you require help.

               The manual is divided into several sections.  Section 1 is 
               the command reference section.

               Example:  MAN ARP      Display manual page for ARP command.

               The following conventions are used in MAN pages:

               < >   Command argument - These braces and the text enclosed
                     within them represent any piece of text typed after the 
                     command.  The <> do not form part of the argument.

               [ ]   Optional argument - These braces enclose anything
                     which is not always present. If used within a command 
                     name (e.g. N[ODES]), it indicates that the command may 
                     be abbreviated to a minimum form while remaining 
                     unique.

               Availability: Although this command is currently available to
                             all users, it is not shown in the list of 
                             normal commands because it generates a lot of 
                             output, some of which is not relevant to non-
                             sysops.  Its use by non-sysops may be withdrawn 
                             at a later date if it proves to be a problem.

               Limitations: Although most commands may be abbreviated, it is
                            not currently possible for the MAN command to 
                            correctly identify the required page from an 
                            abbreviated argument.  Thus "MAN NODES" is 
                            acceptable, whereas "MAN NO" is not.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 177
      Command Reference - Sysop-only Commands


                            This problem will be addressed in a later 
                            version, but a temporary work-around might be to 
                            make several copies of each MAN file for all 
                            permutations of the command.  Beware though, 
                            this may make the list very confusing!

               Note: Due to its size it is difficult to ensure that everyone
                     has a completely up to date sysop document, but the MAN 
                     pages will always contain the latest information.  They 
                     will be kept updated by distributing new pages as 
                     required.

               See also:  H -- General help system.


      MAXFRAME -- Display / Set port MAXFRAME value.

               Syntax: MAX[FRAME] <port> [n]

               The MAXFRAME command is used to display and set the AX25 L2 
               MAXFRAME (window) value for the specified port.  This is the 
               maximum number of unacknowledged frames allowed before the 
               link must stop and wait for an ack.  The normal range is 
               between 1 and 7, although maxframes of up to 127 are allowed 
               in Modulo-128 links.

              If port maxframe > 7 is specified, all level 2 downlinks on 
              that port will attempt to use Modulo-128, falling back to 
              modulo-8 if the target doesn't support Mod-128.

              If the port PACLEN is set to zero (dynamic mode), both 
              MAXFRAME and PACLEN will adapt to link conditions. MAXFRAME 
              starts at the port's maxframe, reducing when there are 
              excessive retries, and increasing when there are no retries.

              If the second argument to the MAXFRAME command is ommitted, 
              the current value is displayed.

               If the setting is changed, the new setting remains in force 
               until it is changed again, or until the router is restarted, 
               in which case it returns to the default value specified in 
               the port entry in the CFG file.

               Examples: MAX 2     - Display current setting for port 2
                         MAX 2 6   - Set maxframe for port 2 to 6.


      MHCLEAR  Clear MHeard list

               Syntax:  MHC[lear] <portnum>

               The MHCLEAR command clears the MH list for the specified 
               port, and would typically be used if the radio had been 
               changed from one frequency to another.  If <portnum> is zero, 
               all MH lists are cleared.







      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 178
      Command Reference - Sysop-only Commands


      MINQUAL  Display / Set port minimum quality

               Syntax: MIN[qual] <port> [n]

               The MINQUAL command is used to display and set the Net/rom 
               minqual value for the specified port.  Within nodes 
               broadcasts received on that port, any node whose quality is 
               less than the minqual will not be accepted into the nodes 
               table.

               If the second argument is omitted, the current value is 
               displayed.

               If the setting is changed, the new setting remains in force 
               until it is changed again, or until the router is restarted, 
               in which case it returns to the default value specified in 
               the port entry in the CFG file.

               Examples: MIN 2      - Display current setting for port 2
                         MIN 2 30   - Set minqual for port 2 to 30.


      MMASK -- Select which protocol(s) to monitor (trace)

               Syntax:  MM[ASK] [0 - FFFFh]

               The MMASK command selects which protocol layers will be 
               monitored when traffic tracing is enabled.

               The optional argument is a HEX number between 0000h and 
               FFFFh, which is calculated by adding together the desired 
               values from this table:

                  0001 - Incoming frames          0100 - ICMP
                  0002 - Outgoing frames          0200 - TCP
                  0004 - AX25 layer 2             0400 - KISS
                  0008 - AX25 info frames         0800 - SLIP
                  0010 - AX25 layer 3             1000 - PASSALL
                  0020 - AX25 layer 4             2000 - Hex Dump
                  0040 - IP frames
                  0080 - ARP frames

               If no argument is supplied, the current setting is reported.

               The default setting for the first console is 03FF, which 
               displays all incoming and outgoing traffic from AX25 layer 2 
               upwards.

               This command duplicates the function of the <F4> key.

               The console can override a remote sysop's settings.

               The PASSALL option enables frames which fail the validity 
               checks at one layer (e.g. KISS checksum) to be passed to the 
               next layer above for tracing.

               Examples:  MMASK 0201  -  display incoming TCP frames only 
                          MMASK 0242  -  display outgoing TCP and IP




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 179
      Command Reference - Sysop-only Commands


               Note: Don't try to trace too much detail via a remote link -
               see warning in MONITOR below.

               See also:  MONITOR  -  Enable / disable monitoring.
                          MPORT    -  Select port(s) to monitor.


      MONITOR -- Enable / disable traffic monitoring (tracing)

               Syntax: MON[ITOR] [on | off]

               The MONITOR command is used to enable or disable the display 
               of incoming and outgoing traffic.

               The optional argument may be "ON" or "OFF".  The former 
               enables the display, and the latter disables it.  If no 
               argument is supplied, the current setting is reported.

               If used at the console, this command enables and disables 
               tracing to the console window, and works in conjunction with 
               the <F2> (monitor toggle) key.

               If used by a remote sysop, monitored frames are sent to him 
               instead of the console window.  In order to avoid overloading 
               the link, the MPORT setting is cleared every time monitoring 
               is enabled, so the sysop must then issue the MPORT command to 
               select which port(s) to monitor.

               The console may override a remote sysop's settings.

               Examples:  MON ON  -  Enables tracing.
                          MON OFF -  Disables tracing.

               Only one sysop may receive the trace display at any one time.

               Note:  Remote sysops must ensure that their link with the 
               router is capable of carrying the large volume of traffic 
               resulting from tracing.  Attempting to trace too many ports / 
               too much detail on a slow link may result in poor 
               performance.  You have been warned!

               See Also:  MPORT  -  Select port(s) to monitor.
                          MMASK  -  Select type of activity to monitor.


      MOTD  -- Maintain "Message Of The Day"

               Syntax:  "MOTD [<days> <text>] | [ @ ]"

               The MOTD command displays, sets or clears the "Message Of The 
               day", which is a single line of text sent only after L2 ctext.
               If Ctext isn't sent, Motd isn't sent.

               The <days> count is decremented at midnight, and the message 
               stops being displayed when it reaches 0.  It is meant for 
               displaying urgent notifications, rally adverts etc.  Anything 
               more permanent should go in ctext.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 180
      Command Reference - Sysop-only Commands


               If no arguments are supplied, the current motd (if any) is 
               displayed.

               If the first argument is "@", the current motd (if any) is 
               cleared.

               If two arguments are supplied, the first one should be the 
               number of days to display the message, and the second should 
               be the message itself, which can be up to 80 characters and 
               may include spaces.  A "days" count of 1 will display the 
               motd until midnight.

               Examples:

               MOTD 3 WyrePak Meeting Tues 21/8 8pm Sutton Arms
               MOTD @


      MPORT -- Select which port(s) to monitor (trace)

               Syntax:  MP[ORT] [0 - FFFFh]

               The MPORT command selects which ports will be monitored when 
               traffic tracing is enabled.

               The optional argument is a HEX number between 0000h and 
               FFFFh, which is calculated by adding together the desired 
               values from this table:

               Port  HEX    Port  HEX    Port  HEX     Port  HEX
                1   0001      5  0010      9  0100      13   1000
                2   0002      6  0020     10  0200      14   2000
                3   0004      7  0040     11  0400      15   4000
                4   0008      8  0080     12  0800      16   8000

              If no argument is supplied, the current setting is reported.

              This command duplicates the function of the <F3> key.

              If used by a remote sysop, monitored frames are sent to him 
              instead of the console window.  In order to avoid overloading 
              the link, the MPORT setting is cleared every time monitoring 
              is enabled, so the sysop must then issue the MPORT command to 
              select which port(s) to monitor.

              The console can override a remote sysop's settings.

               Examples:  MPORT 800  -  Trace port 12.
                          MPORT 1803 -  Trace ports 13, 12, 2 and 1.
          
               Note:  Remote sysops cannot trace activity on the port on 
               which they are uplinked

               See also:  MONITOR  -  Enable / disable monitoring.
                          MMASK    -  Select type of activity to monitor.







      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 181
      Command Reference - Sysop-only Commands


      NAT -- Network Address Translation commands.

               Syntax:
               NAT ADD STATIC <local>[:port] <global>[:port] [tcp | udp]
               NAT ADD OVERLOAD <local> <global> <subnet_mask>
               NAT DROP <local>[:port] [tcp | udp]
               NAT LIST

               The NAT commands controls Network Address Translation, i.e. 
               the process whereby the IP addresses contained in datagrams 
               are manipulated to allow hosts on one network to communicate 
               with hosts on a different network.

               For example, hosts on a private intranet using unregistered 
               192.168.0.x addresses cannot communicate with hosts on the 
               wider Internet because no-one would know where to route the 
               return datagrams.  NAT basically translates the unregistered 
               addresses into registered ones and vice versa.

               PAT (Port Address Translation) manipulates TCP and UDP 
               service port numbers, for example to allow several hosts to 
               share one IP address.  The NAT commands are also used to 
               configure PAT.

               The arguments for NAT commands are as follows:

               <local>          Local private (unregistered) IP address.
               <global>         Globally recognised IP address.
               <port>           TCP or UDP service port number.
               <subnet_mask>    Bit pattern used for matching addresses.
                                e.g. 255.255.255.0

               NAT ADD adds an entry to the NAT table.  There are two forms: 
               STATIC and OVERLOAD.  STATIC is used to add static NAT and 
               PAT entries, i.e. those where there is a one-to-one mapping 
               between private and public IP addresses.  OVERLOAD is used 
               only for dynamic PAT, where several hosts share one public IP 
               address.

               NAT DROP removes an entry from the NAT table.

               NAT LIST lists the NAT table entries.

               Examples:
               NAT ADD STATIC 192.168.0.2:87 44.131.91.2:23 tcp
               NAT ADD OVERLOAD 192.168.0.0 44.131.91.3 255.255.255.240
               NAT DROP 192.168.0.5:23 tcp

               Note:  The NAT ADD command can also be used in IPROUTE.SYS or 
               BOOTCMDS.SYS.


      PACLEN -- Display / Set global or port paclen values.

               Syntax: PACLEN <port> [value]

               The PACLEN command allows the global and port-specific PACLEN 
               settings to be displayed and changed.  Paclen is the maximum 
               data field length within a packet.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 182
      Command Reference - Sysop-only Commands


               The global PACLEN is specified in the L2 global parameters 
               section of the config file, and is the default value, used 
               where not overridden by a port-specific paclen.  

               All frames originating at the router use the global or port 
               paclens specified, but Netrom frames originating at other 
               systems can not be fragmented, so we have no control over 
               them, and they may be larger than our paclen.

               If a single numeric argument is supplied, and its value is 
               greater than 0, the current paclen for that port number is 
               displayed.  If the argument is 0 the global paclen is 
               displayed instead.

               If two numeric arguments are supplied, the first specifies a 
               port number and the second specifies a new paclen value for 
               that port.  Port 0 sets the global paclen.

               Setting the port PACLEN to 0 enables "adaptive link 
               parameters", which means PACLEN (and MAXFRAME) will vary 
               according to the link quality.  This will tend to maximise 
               link throughput dynamically.

               Examples:  PACLEN 0          - Display global default paclen
                          PACLEN 0 120      - Set default paclen to 120
                          PACLEN 10        - Display paclen for port 10
                          PACLEN 10 160    - Set port 10 paclen to 160


      PERSIST -- Display / Set the persist value for a port.

               Syntax:  PER[SIST] <port> [0-255]

               The PERSIST command is used to display and set the PERSIST 
               value for a port.  This is the "probability to transmit", 
               used as part of the CSMA channel access procedure.  A low 
               value is used when there are several stations sharing the 
               channel, giving each a fair chance to transmit.  A high value 
               is used when the channel isn't shared.  The optimum setting 
               is 256/n where n is the number of station sharing the 
               channel.

               If the command is used with a single numeric argument, the 
               current setting for that port number is displayed.

               If two arguments are supplied, the PERSIST value for the port 
               specified by the first is set to the value of the second.  
               The new setting remains in force until changed again or until 
               the router is restarted, in which case the value specified in 
               the CFG file will apply.

               Examples:  PERSIST 5        - Display value for port 5
                          PERSIST 5 64     - Set port 5 PERSIST to 64

               Note: On KISS ports, you should allow up to 5 minutes for a
                     new setting to become active.

               See also:  SLOTTIME -- CSMA interval timer




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 183
      Command Reference - Sysop-only Commands


      PPP -- Point to Point Protocol Configuration commands.

               Syntax:

               PPP <port> IDLE [secs]
               PPP <port> IPCP <LOCAL | REMOTE> <ADDRESS | DNS> [ipaddr]
               PPP <port> LCP <LOCAL | REMOTE> AUTH [PAP]
               PPP <port> LCP <LOCAL | REMOTE> DEFAULT
               PPP <port> LCP <LOCAL | REMOTE> MRU [mru]
               PPP <port> LOG [0-255]
               PPP <port> PAP <USER> [username password]

               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.  The PPP commands are used to 
               configure the system.

               The IDLE subcommand is used to display or set the PPP link 
               inactivity timer, which disconnects the link after a period 
               of inactivity.  The argument is in seconds.

               The IPCP subcommands control the IPCP (IP Control Protocol) 
               parameters for each end of the link.  ADDRESS specifies the 
               IP addresses used for the link, and DNS specifies the IP 
               addresses of the Domain Name Server.  

               The LCP subcommands control the LCP (Link Control Protocol) 
               parameters for each end of the link.  AUTH specifies the 
               authentication protocol (if any) which the link will use.  
               The only authentication protocol currently supported is PAP.  
               The MRU command specifies the Maximum Receive Unit, i.e. the 
               largest datagram the host is prepared to accept.  The limits 
               are 128 and 4096. DEFAULT restores the default LCP parameters 
               which all hosts understand. 

               The LOG subcommand displays or sets the PPP logging level, 
               which controls how much diagnostic detail is recorded in the 
               PPLOG.TXT file.  The argument is 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

               The PAP subcommand displays or sets PAP (Password 
               Authentication Protocol) parameters.  At present the only 
               parameter is USER, which specifies the username and password 
               for PAP login.

               Examples: PPP 1 IDLE 300
               PPP 1 IPCP LOCAL ADDRESS 62.31.45.67
               PPP 3 LCP LOCAL AUTH PAP
               PPP 3 LCP LOCAL DEFAULT
               PPP 3 LCP LOCAL MRU 1500
               PPP 3 LOG 3
               PPP 1 PAP USER g8pzt zedfrgc




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 184
      Command Reference - Sysop-only Commands


               Notes:
               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

               You are advised against using the higher PPP LOG 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.

               See also: DUN -- Dial-up Networking
                         SCRIPT -- Dialler script commands


      QUALITY -- Display / Set default quality value for a port.

               Syntax: QUA[LITY] <port> [0-255]

               Displays or sets the default quality for nodes heard on the 
               specified port.  It should be set to zero to suppress all 
               level 3/4 activity on a port, e.g. on user access 
               frequencies.

               If a single numeric argument is supplied, the current quality 
               for that port number is displayed.

               If two numeric arguments are supplied, the quality for the 
               port specified by the first is set to the value of the 
               second.  The new setting remains in force until changed, or 
               until the router is restarted, in which case the setting 
               reverts to that specified in the config file.

               Example:  QUALITY 3      - Display quality for port 3
                         QUALITY 3 40   - Set port 3 default quality to 40


      REBOOT -- Reboot the computer.

               Syntax: RE[BOOT]

               Reboots the machine immediately and un-gracefully.

               It is typically used by remote sysops to restart the machine 
               after editing autoexec.bat/config.sys, installing a new 
               version of the software, or to recover from potentially 
               dangerous situations such as a corrupt hard drive.

               Console sysops can use the "Vulcan Nerve Pinch" (Ctrl-alt-
               del) or interrupt the power instead.

               Notes:  Remote sysops should only use this command if the
                       router program has been started from AUTOEXEC.BAT, 
                       otherwise it won't restart.



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 185
      Command Reference - Sysop-only Commands


                       It is recommended that you include an automatic disk 
                       check and repair utility within AUTOEXEC.BAT to 
                       remove any problems which resulted in the REBOOT 
                       command being used.

                       See also:  RESTART - restart without reboot


      RESPTIME -- Display / Set L2 delayed ack timer for port.

               Syntax: RESPTIME <port> [millisecs]

               The RESPTIME command allows the value of the AX25 T2 (delayed 
               ack) timer for a port to be displayed or altered.

               If a single numeric argument is supplied, the current value 
               for that port number is displayed.

               If two numeric arguments are supplied, the first specifies 
               the port number, and the second specifies the new value for 
               the parameter.  The new setting remains in force until 
               changed, or until the router is restarted, in which case the 
               value specified in the CFG file is re-applied.

               Example:  RESPTIME 3       - Display resptime for port 3
                         RESPTIME 3 150   - Set port 3 resptime to 1500 ms

               Notes:
               The RESPTIME parameter specifies how long the router will 
               wait, after receiving a frame, before sending an ack for that 
               frame.  It helps to improve the efficiency by cutting out 
               unnecessary acks.  It allows a single ack to be sent when a 
               transmission contains several frames, instead of acking each 
               frame in turn.

               The value must therefore be at least the length of time it 
               takes to transmit a single packet.  At 1200 bauds (120 
               bytes/sec) a 120 byte packet lasts 1 second, a 180 byte 
               packet lasts 1500 millisecs and a 256 byte packet lasts just 
               over 2 secs.  Therefore resptime should reflect the paclen 
               used by the sender.
               1500 millisecs is a good compromise, but if the other end 
               regularly uses high paclens, 2000 or 2500 ms would be more 
               appropriate.  At 9600 baud, 200 millisecs is probably 
               adequate.

               Too high a value will cause the link to be too "relaxed", 
               whereas too low a value will cause too many acks.  Both 
               extremes reduce the link efficiency.

               See also:  FRACK, SLOTTIME


      RESTART -- Restart the program.

               Syntax:  RES[tart]






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 186
      Command Reference - Sysop-only Commands


               The RESTART command re-starts the router without rebooting 
               the machine.  It would typically be used by remote sysops to 
               start a new version or read a modified .cfg file.

               Each restart results in the loss of a couple of hundred bytes 
               of memory, so once in a while you should do a reboot to 
               reclaim it.

               See also: REBOOT


      RETRIES -- Display / Set the retries parameter for a port.

               Syntax: RETRIES <port> [value]

               The RETRIES command allows the value of the level 2 maximum 
               retry value for a port to be displayed or altered, i.e. the 
               maximum no. of attempts at sending a frame without a reply 
               being received.  The usual setting is 10.  A setting of 0 
               means "try forever", and should be avoided except for 
               testing.

               If a single numeric argument is supplied, the current value 
               for that port number is displayed.

               If two numeric arguments are supplied, the first specifies 
               the port number, and the second specifies the new value for 
               the parameter.  The new setting remains in force until 
               changed, or until the router is restarted, in which case the 
               value specified in the CFG file is re-applied.

               Example:  RETRIES 3       - Display setting for port 3
                         RETRIES 3 15    - Set port 3 max retries to 15


      RIP -- Routing Interface Protocol configuration commands.

               Syntax: RIP AC[cept] <ip_address>
                       RIP A[dd] <ip_address> <secs>
                       RIP D[rop] <ip_address>
                       RIP L[earn] [ON | OFF]
                       RIP R[efuse] <ip_address>
                       RIP S[tatus]
                       RIP T[imeout] [secs]

               RIP allows routers to learn of each other's routing, in a 
               similar fashion to NetRom.  Xrouter implements RIP98, which 
               is a form optimised for radio, and the RIP commands are used 
               to configure the system.

               Peers which have been added to the refuse list using the RIP 
               REFUSE command can be removed using RIP ACCEPT, allowing the 
               router to learn information from them.  <ip_address> is the 
               IP address of the peer.








      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 187
      Command Reference - Sysop-only Commands


               RIP ADD adds a peer to the list of those who will receive RIP 
               transmissions from us.  The <secs> parameter specifies the 
               interval between transmissions, and should be chosen in 
               agreement with the peer, so that <secs> is approximately one   
               quarter of the lifetime of their RIP entries.  This allows up 
               to 4 transmissions to be lost before the route is purged.

               RIP DROP removes a peer from the list of those who will 
               receive RIP transmissions from us.

               RIP LEARN turns route learning on or off.  By default, RIP98 
               route learning is OFF.  If no arguments are given, the 
               current status is reported.  "ON" allows Xrouter to learn 
               routes from its RIP98 peers, and "OFF" prevents it.  I 
               recommend enabling LEARN mode.

               RIP REFUSE is the opposite of ACCEPT.  It adds a peer to the 
               refuse list so broadcasts from that peer will be ignored.  I 
               have provided this command in case you need to exclude a peer 
               which is advertising faulty routes.

               RIP STATUS displays various RIP98 parameters such as the list 
               of peers who receive broadcasts from us, the list of peers we 
               are ignoring, the timeout value, and the setting of learn 
               mode.

               RIP TIMEOUT is used to display and set the lifetime of 
               learned routes.  Routes learned from peers have a finite 
               lifetime.  If the route entry is not refreshed within this 
               lifetime, it is removed from the routes table.  The timeout 
               should preferably be 4 times the interval between broadcasts 
               from peers, and the default is currently 4 hours.

               The RIP ADD, LEARN, REFUSE and TIMEOUT commands may be used 
               within IPROUTE.SYS or BOOTCMDS.SYS.


      SAVENODES -- Save the nodes and routes tables to disk.

               Syntax:  SAVENODES [filename]

               The SAVENODES command dumps the nodes and routes tables to 
               a file.  If a filename isn't specified, PZTNODES is the 
               default.  This file is read by the router at start up, and 
               used to reconstruct the tables without having to wait for 
               nodes broadcasts to be received.

               Table dumping occurs automatically every hour, and when the 
               router is closed down using Alt-x, but this command allows 
               you to dump and examine the tables at any time, without 
               taking the router off line.

               Note: The PZTNODES file is identical to the BPQNODES file
                     used with BPQ node, and may be used to "quick start" 
                     when changing between the two systems.







      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 188
      Command Reference - Sysop-only Commands


      SHELL -- Run a command or program in a DOS shell.

               Syntax:  SHELL <cmd> [args...]

               The SHELL command is used for running DOS commands and simple 
               programs in a temporary DOS shell which terminates upon 
               completion of the program or command.

               Example:  SHELL DIR /W

               Limitations:  Trying to run interactive commands or programs
                             via this means may fail, and may crash the 
                             router.

                             At least 60k of free memory is required for the 
                             DOS shell itself in addition to any program 
                             loaded above it.

               Notes:  This command is not yet functional.

                       Console users may use the F9 key to invoke a DOS 
                       shell which persists until closed.


      SLOTTIME -- Display / Set the slottime parameter for a port.

               Syntax: SLOTTIME <port> [millisecs]

               The SLOTTIME command allows the value of the CSMA interval 
               timer for a port to be displayed or altered.  The usual 
               setting is 100 milliseconds.

               If a single numeric argument is supplied, the slottime value 
               for that port number is displayed.

               If two numeric arguments are supplied, the first specifies 
               the port number, and the second specifies the new value for 
               the parameter.  The new setting remains in force until 
               changed, or until the router is restarted, in which case the 
               value specified in the CFG file is re-applied.

               Example:  SLOTTIME 3       - Display slottime for port 3
                         SLOTTIME 3 150   - Set port 3 slottime to 150

               See also:  PERSIST


      START -- Start a daemon process

               Syntax: ST[art] <process_name>

               The START command is used to start daemons, which are 
               processes which run in background independently of any user 
               session.  For example the IGATE and dialler processes are 
               daemons.  Attempting to start a process which is already 
               running will have no harmful effect.

               Example:  START IGATE

               See also: STOP -- Stop a daemon.


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 189
      Command Reference - Sysop-only Commands




      STOP -- Stop a daemon process / List active daemons.

               Syntax: STO[p] [process_name]

               The STOP command is used to stop a daemon process whose name 
               name is specified as the argument.
          
               If the command is used without arguments, a list of the 
               active processes is displayed.

               Attempting to stop a process which is not running will simply 
               produce an error message.

               Example:  STOP IGATE

               See also: START -- start a daemon.


      TCP  -- TCP status / configuration commands.

               Syntax:  TCP S[TATUS] [sock#]

               The TCP command will eventually be used to display and 
               dynamically configure various parameters of the TCP module. 
               It currently accepts only the STATUS sub-command, which 
               displays the status of the TCP sockets.

               If [sock#] is not supplied, all the active sockets are 
               displayed, otherwise only the matching socket is displayed.

               The display shows the socket number, the remote and local 
               addresses, the state, and the amount of queued data in bytes. 
               The states are as follows (see RFC793):

                     0    Closed              6    FINWAIT2
                     1    Listen              7    Close wait
                     2    SYN sent            8    Closing
                     3    SYN Received        9    Last ACK
                     4    Established         10   Time Wait
                     5    FINWAIT1


      TIME -- Display / set system time.

               Syntax:  TIME [hh:mm]

               If no argument is supplied, this command displays the current 
               setting of the DOS clock.

               If an argument of the form HH:MM is used, it sets the DOS 
               clock to the specified time. (24 hour format)

               Example:  TIME        - Display current time.
                         TIME 23:06  - Sets DOS time to 23:06

               See also:  DATE -- set system date




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 190
      Command Reference - Sysop-only Commands


      TXDELAY -- Display / Set the transmit keyup delay for a port.

               Syntax:  TXD[ELAY] <port> [millisecs]

               The TXDELAY command allows the value of the transmit keyup 
               delay for a port to be displayed or altered.

               If a single numeric argument is supplied, the current value 
               for that port number is displayed.

               If two numeric arguments are supplied, the first specifies 
               the port number, and the second specifies the new value for 
               the parameter in milliseconds.  The new setting remains in 
               force until changed, or until the router is restarted, in 
               which case the value specified in the CFG file is re-applied.

               Example: TXDELAY 3       - Display txdelay for port 3
                        TXDELAY 3 300   - Set port 3 txdelay to 300 ms

               Notes:
               TXDELAY is the interval between the transmitter being keyed 
               up and the start of a transmitted packet.  It allows time for 
               the RF to reach its full value, and for the TX audio circuits 
               to stabilise.
               Some synthesised rigs require a large txdelay (500 or more) 
               to allow the synthesiser to swing between RX and TX 
               frequencies, and many rigs have audio stages which take 100 
               ms to stabilise while oversized electrolytics charge up.

               One factor which is often overlooked is the other end's 
               receiver.  It takes a finite time for the squelch to open, 
               and if the rig has just been transmitting it may take a while 
               to stabilise back to receiving, especially with synthesised 
               rigs.  If your txd is too short, you will be sending replies 
               before the other end is ready to hear you, and unnecessary 
               retries will result.

               On KISS TNC's, you should allow up to 5 minutes for any new 
               setting to take effect.

               See also:  TXTAIL


      TXOK -- Display / Set "ok to tx" for a port.

               Syntax:  TXO[k] <port> [0 | 1]

               The TXOK command displays the current txok flag setting for a 
               port, and allows it to be changed.  This flag controls 
               whether or not the transmitter is allowed to key up.  If set 
               to zero, nothing will be sent on the port (see notes).  By 
               default, all ports have this flag set to a non-zero value.

               If two numeric arguments are supplied, the txok flag is set 
               to the second argument, otherwise the current setting for the 
               specified port is displayed.  Values are: 0=don't transmit, 
               anything else=ok to transmit.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 191
      Command Reference - Sysop-only Commands


               Modified settings remain in force until changed or system is 
               restarted.

               Examples: TXOK 3        - Display current setting for port 3
                         TXOK 3 0      - Stop port 3 transmissions.

               Notes:
                       Setting TXOK=0 does not actually disable the 
                       transmitter itself, it merely prevents any frames 
                       being sent to the TNC, so if the latter has a built-
                       in CWID, it will still key up the TX so send the 
                       CWID.

                       It should be obvious, but if you set TXOK=0 for the 
                       port you are using to send commands, you will lose 
                       control of the router!


      TXTAIL -- Display / Set the transmit keyup delay.

               Syntax:  TXT[AIL] <port> [millisecs]

               The TXTAIL command allows the value of the transmit keyup 
               delay for a port to be displayed or altered.  This is a 
               parameter used only by KISS TNC's and SCC cards, and it 
               controls the length of time the TX is held on after the last 
               character has been sent to the SIO / SCC shift register.
               It allows time for the last character plus two CRC bytes and 
               a closing flag to be sent, and should therefore be set no 
               lower than the time required to send 4 bytes.  Due to the 
               granularity of PC timing, for SCC cards it should be at least 
               60 ms.

               If a single numeric argument is supplied, the current value 
               for that port number is displayed.

               If two numeric arguments are supplied, the first specifies 
               the port number, and the second specifies the new value for 
               the parameter in milliseconds.  The new setting remains in 
               force until changed, or until the router is restarted, in 
               which case the value specified in the CFG file is re-applied.

               Example:  TXTAIL 3       - Display txtail for port 3
                         TXTAIL 3 100   - Set port 3 txtail to 100 ms

               Note: After modifying this value, you may have to wait up to
                     5 minutes for it to take effect.

               See also:  TXDELAY


      UDP   -- UDP status and configuration commands.

               Syntax:  UDP S[tatus]

               The UDP command currently accepts only the STATUS sub-
               command, which displays the active UDP sockets and their 
               status.

               The display looks like this:


      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 192
      Command Reference - Sysop-only Commands



               G8PZT:KIDDER} UDP Status:

               Sent=55  Rcvd=5123  RcvBdcasts=0  ChksumErr=0  NoSocket=56

               UDP Sockets:
                  Sock#  Local_address        Rxq
               73fb0008  0.0.0.0 53             0
               (End of list)

               "Sent" is the number of UDP frames sent by Xrouter.

               "Rcvd" is the number of UDP frames received.

               "RcvdBdcasts" is the number of UDP frames received on the 
               subnet broadcast address.

               "ChecksumErr" is the number of UDP frames received with 
               checksum errors.

               "NoSocket" is the number of UDP frames received for which 
               there was no receive socket.

               "Sock#" is the unique socket identifier.

               "Local_address" shows the local IP address and UDP service 
               port number of the socket.

               "Rxq" shows the number of received frames waiting to be 
               processed.
































      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 193
      Command Reference - PZTDOS


      PZTDOS COMMANDS
      ===============

      The following commands are available only within PZTDOS mode, i.e. 
      after issuing the "DOS" command.

               CD    -- Change Working Directory
               COPY  -- Copy file(s).
               DEL   -- Delete one or more files
               DIR   -- Obtain a directory listing.
               EDIT  -- Edit a text file.
               EXIT  -- Leave PZTDOS mode
               MD    -- Make Directory.
               MOVE  -- Move file(s).
               REN   -- Rename file(s).
               RMDIR -- Remove Directory.
               TYPE  -- Display a text file.

      Each command is discussed in more detail in the following section:


      PZTDOS COMMANDS IN DETAIL
      ~~~~~~~~~~~~~~~~~~~~~~~~~

      CD -- Change Working Directory.

               Syntax: CD <[drive:]<dir>

               The CD command changes the "working directory" to the one 
               specified by <dir>.  It is available only within PZTDOS.

               If <dir> is an absolute pathname, beginning with \ or /, it 
               is used as specified, otherwise it is interpreted relative to 
               the current working directory.  The command recognises "." 
               and "..", and both forward and reverse slashes may be freely 
               mixed.

               Unlike the MSDOS command of the same name, if <dir> is 
               preceded by a drive spec the PZTDOS version will also change 
               the current drive.

               Examples: CD ../FRED    CD C:\WINDOWS\SYSTEM


      COPY -- Copy file(s).

               Syntax: COPY <source> [dest]

               The COPY command copies the file(s) specified by the pathname 
               <source> into the file(s) or directory specified by [dest].

               <source> may be a directory, a single file, or multiple files 
               specified using wildcards, and may contain a drive and path 
               spec.  If <source> is a directory, all the files in that 
               directory will be copied.  If <source> contains wildcards, 
               all matching files will be copied.






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 194
      Command Reference - PZTDOS


               [dest] may be a directory, a single file, or blank.  If 
               [dest] is a directory, the source file(s) are copied into it 
               as separate files.  If [dest] is a single file, the source 
               file(s) are concatenated into it.  If [dest] is not 
               specified, the file is copied into the working directory and 
               retains the original filename.

               Examples:  COPY C:\MYPROG.EXE  A:TESTPROG.EXE  
                          COPY A:FWD.SYS                      
                          COPY WHAT.SYS  A:                   
                          COPY C:\TMP1 D:\TMP2
                          COPY *.HLP HELP.DOC

               Portability:  Normal dos syntax is followed, except that
                             concatenation using the "+" operator is not 
                             supported.

               Note:  Overwrites destination files without warning.


      DEL -- Delete one or more files.

               Syntax:  DEL <filespec>

               If <filespec> describes one or more files, they are deleted. 
               The number of files deleted is reported upon completion.

               Examples:  DEL FRED.TXT
                          DEL \TMP\LOG??98.*


      DF -- Display free space on drive.

               Syntax:  DF [drive]

               The DF command displays the free and total space in bytes on 
               the specified drive, plus sector and cluster size 
               information.

               If no drive is specified, the current drive is assumed.

               The drive letter need not include the colon.

               Examples:  DF
                          DF E:


      DIR -- Obtain a directory listing.

               Syntax:  DIR [drive:][path\][mask]

               The DIR command lists the contents of the specified directory 
               using the optional specified mask.

               If a drive is not specified, the "current drive" is assumed.

               If a path is not specified, the "current working directory" 
               is assumed. 




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 195
      Command Reference - PZTDOS


               If mask is not specified, "*.*" is assumed.  If only the 
               filename part is specified, the extension ".*" is assumed.

               Examples:  DIR MSGHDR??.*
                          DIR \LOGS\
                          DIR E:\PUB\DOCS\*.TXT

               Limitations:  Does not at present accept pipes, redirection 
                             or switches.


      EDIT -- Edit a Text File

               Syntax: E[DIT] [drive:][path\]<filename>

               Invokes the text editor, allowing text files to be viewed or 
               edited.

               See separate section detailing Line Editor commands.


      EXIT -- Leave PZTDOS mode

               Syntax:  EXIT

               Closes a PZTDOS session and returns to normal command mode.

               The complementary command is "DOS", which causes entry to 
               PZTDOS mode.


      MD -- Make Directory.

               Syntax: MD [drive:][path\]<dirname>

               MD creates a directory with the specified pathname.  It is 
               identical to the MSDOS version.

               If drive or path are not specified, the current working drive 
               and/or path are assumed.

               The specified path may be absolute, or relative to the 
               current directory.

               Examples:  MD fred                    
                          MD d:\usr\pub\packet

               See also:  RMDIR -- Remove Directory.


      MOVE -- Move file(s).

               Syntax: MOVE [drive:][path\]<filename1> 
                            [drive:][path\][filename2]

               Moves the file(s) specified by the first argument (source) to 
               the new location and/or name(s) specified by the second 
               argument (target).  Both filenames may contain wildcards.




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 196
      Command Reference - PZTDOS


               "source" must not be a directory.  If it doesn't contain a 
               path, the current working directory is assumed.

               "target" may be a directory.  If a filename is not specified, 
               the original name(s) are used.  If target is a single file, 
               the source must also be a single file.

               If source and target filenames are different the file(s) will 
               be renamed at the same time.

               Examples:  MOVE fred.bat test.bat            - Rename only.
                          MOVE test.bat c:\                 - Move only.
                          MOVE c:\test.bat d:\tmp\fred.bat  - Move & rename.

               Portability: This command follows normal MSDOS v 7 syntax, 
                            apart from the ability to rename a directory, 
                            which is not implemented.

               See also: COPY, REN


      REN -- Rename file(s).

               Syntax: REN [drive:][path\]<oldname> [drive:][path\]<newname>

               Renames one or more file(s) from <oldname> to <newname>.

               If the source path is not specified, the current working 
               directory is assumed.

               If the destination path is not specified, the renamed file(s) 
               remain(s) in the source directory.

               If you specify two different paths, this command will move 
               the file to the new path, providing it is on the same drive.

               The filenames may contain wildcards.

               Examples:  REN FWD.SYS  FWD.OLD
                          REN  C:\AUTOEXEC.BAT  AUTOEXEC.BAK
                          REN  C:\TMP\FRED.DOC  \JUNK\JILL.DOC
                          REN  *.SAV *.19

               Limitations: Source and destination pathnames must be on the
                            same drive.  (Use the MOVE command for renaming 
                            to a different drive)

               Portability: This command follows normal dos syntax.

               See also: MOVE -- Move a file with optional rename.


      RMDIR -- Remove Directory.

               Syntax:  RMDIR [drive:][path\]<dirname>

               RMDIR deletes a directory with the specified pathname, if it 
               exists.




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 197
      Command Reference - PZTDOS


               If drive or path are not specified, the current working drive 
               and/or path are assumed.

               The specified path may be absolute, or relative to the 
               current directory.

               Examples:  RMDIR fred             Delete sub-directory FRED
                          RMDIR c:\windows       Improve your system!!

               See also:  MD -- Make Directory.


      TYPE -- displays a text file.

               Syntax: TYPE [path/]<filename>

               The TYPE command displays the specified text file without 
               pagination.

               Example: TYPE ../DOCS/FRED.DOC

               Limitations:  For use with text files only.
                             There are no limitations on the size of file 
                             which can be displayed.  The command does not 
                             (yet) allow concatenation of files, and the 
                             output may not (yet) be redirected to a file.
                             Wildcards are not accepted.



































      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 198
      Command Reference - Line Editor


      LINE EDITOR COMMANDS
      ====================

      In this section, n1, n2 and n3 refer to line numbers, which must be 
      greater than zero, and within the range of line numbers used in the 
      file.  The space between the command and the first number may be 
      omitted, and the numbers can be separated by spaces, commas, colons, 
      tabs etc.   Parameters in square brackets [] are optional.  When 
      copying, moving or inserting lines, the "source" text is inserted at 
      the "destination" line, i.e. "in front of" the original text.

      ?              Displays a brief list of commands.

      A <text>       Append line <text> to the file.  The editor ignores
                     exactly one space between the A and the text to be 
                     inserted, so if you want to enter a line with leading 
                     spaces, add one extra.

      C n1 n2 [n3]   Copy line(s).  If n3 is omitted, line n1 is copied into
                     line n2, otherwise the block n1 to n2 inclusive will be 
                     copied into the position beginning at n3.
                     Note: n3 must not be within the block being copied.

      D n1 [n2]      Delete line(s).  If both n1 and n2 are specified, the 
                     block of lines between and including n1 and n2 will be 
                     deleted.  If n2 is omitted, or is the same as n1, only 
                     n1 will be deleted.
                    
      I n1 <text>    Insert <text> into line n1.

      L n1 [n2]      List (display) line(s).  If n2 is specified, lines n1 
                     to n2 inclusive will be displayed, otherwise it will 
                     display 10 lines beginning at n1.  If n1 is omitted, 
                     the first 10 lines of the text will be displayed.

      M n1 n2 [n3]   Move line(s).  If n3 is specified, the block of lines 
                     n1 to n2 inclusive will be moved to the position 
                     beginning at n3, otherwise the single line n1 will be 
                     moved to the n2 position.

      Q              Quit.  The text is abandoned and the original file is
                     left intact, providing you hadn't used the W command.

      S              Save the text.  Syntax and function identical to W.

      W [<file>]     Write (save) file being edited to disk.  If <file> is
                     specified, the work is written there instead of the 
                     original name, but will not overwrite an existing file.

      W! <file>      Write the text being edited to <file>, overwriting any
                     existing file of that name.

      WQ             Write the modified text back to the original file and
                     quit editor. (Same as ZZ)

      ZZ             Same as WQ (see above)






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 199
      Command Reference - FTP Server


      FTP SERVER COMMANDS
      ====================

      The router's inbuilt FTP server accepts the following commands:


              ABOR    CDUP    CWD     DELE    HELP    LIST    MKD     MODE
              NLST    NOOP    PASS    PORT    PWD     QUIT    RETR    RMD
              RNFR    RNTO    STOR    STRU    SYST    TYPE    USER


      All commands and arguments are case-insensitive, thus "cwd", "CWD" and
      "cWd" are equally valid.

      Both UNIX style (e.g. /pub/fred) and DOS style (e.g. \pub\fred) 
      pathname conventions are accepted.

      Unlike DOS, the server does not maintain separate "working 
      directories" for each drive, so pathnames which include a drive letter 
      must start at the root of that drive.  e.g. "c:mydir\fred.txt" is not 
      valid, whereas "c:\mydir\fred.txt" is.

      The FTP commands are described in detail below:


      ABOR -- Abort data connection.

               Syntax: ABOR

               The ABOR command tells the server to abort any data transfer
               currently in progress and close the data connection.  The 
               control connection is not closed.

               If the data connection is not open, this command has no 
               effect.


      CDUP -- Change Directory Up By One Level

               Syntax:  CDUP

               The CDUP command changes the current working directory up one 
               level to the parent directory, i.e. it performs the function 
               of "CWD .."

               This command has no arguments, and if already at the root it 
               has no effect.

               See also: CWD -- Change Working Directory


      CWD -- Change Working Directory

               Syntax:  CWD [drive:\]<path>

               The CWD command changes the current working directory (and 
               drive if necessary) for the FTP session.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 200
      Command Reference - FTP Server


               Examples:

               CWD FRED        Change to subdirectory FRED.
               CWD ..          Change up one level to parent directory
               CWD /           Change to root directory
               CWD /FRED/JIM   Change to JIM subdirectory of FRED directory.

               See also:  CDUP -- Change up one directory;


      DELE -- Delete file(s).

               Syntax:  DELE [drive:\][dir\]<mask>

               Examples:

               DELE JIM.TXT         Delete JIM.TXT from current directory.
               DELE /FRED/DOG.EXE   Delete DOG.EXE from directory /FRED
               DELE *.BAT           Delete all files with .BAT extension.

               Notes:  Wildcards '*' and '?' are accepted.


      HELP -- Display help for FTP server commands.

               Syntax:  HELP [command]

               Examples:  HELP        Displays basic info and list of cmds.
                          HELP CWD    Gives help for the CWD command.

               Notes:
               Some FTP clients may intercept the HELP command to give help 
               on client commands.  In this case, the REMOTEHELP command, if 
               it is implemented should translate to a server HELP command.  
               If not, the client may have a command which passes commands 
               "RAW" to the server.  If all else fails, TELNET to port 21 
               and the HELP command will work.


      LIST -- lists FTP server directory contents.

               Syntax:  LIST [drive:\][dir\][mask]

               The LIST command causes a directory listing to be sent from 
               the FTP server to the client over the data connection.  If 
               the data connection cannot be established, the command will 
               fail.

               The optional argument consists of a directory path and 
               filename mask.  If no path is specified, the current 
               directory is assumed.  If no mask is specified, "*" (all 
               files) is assumed.  Wildcards '*' and '?' are accepted. 

               Examples:
               LIST              Displays all files in current directory
               LIST C:\PUB       Lists all files in PUB subdir of drive C:
               LIST /USR/*.EXE   Lists all .exe files in /USR directory





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 201
      Command Reference - FTP Server


               See also:  NLST -- List names only


      MKD -- Make new directory.

               Syntax:  MKD [drive:\]<pathname>

               The MKD command creates a new directory of the specified 
               name.  If pathname is not fully qualified, the new directory 
               is created within the current working directory.

               Examples:  MKD FRED
                          MKD C:/JIM/BILL

               See also:  RMD -- Remove directory


      MODE -- Specifies the data transfer mode.

               Syntax:  MODE <mode_code>

               MODE specifies how the data is to be formatted and 
               transferred via the data connection.  Mode codes are as 
               follows:

               B - Block         Data is sent in blocks
               C - Compressed    Data is compressed
               S - Stream        Data sent as stream of characters

               The default transfer mode, which is the only one currently 
               implemented, is Stream.  The command is included to prevent 
               unnecessary error replies.

               Examples:  MODE S   Sets (S)tream transfer mode.


      NLST -- (Name List) lists directory contents in short form.

               Syntax:  NLST [<filespec>]

               The NLST command causes a directory listing to be sent from 
               the FTP server to the client over the data connection.  If 
               the data connection cannot be established, the command will 
               fail.

               The optional argument consists of a directory path and 
               filename mask.  If no path is specified, the current 
               directory is assumed.  If no mask is specified, "*" (all 
               files) is assumed.  Wildcards '*' and '?' are accepted. 

               The listing consists of filenames only, without size, date 
               and other supplementary information.

               Examples:  NLST
                          NLST K:\PUB
                          NLST /USR/*.EXE

               See also:  LIST -- List directory contents




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 202
      Command Reference - FTP Server


      NOOP -- (NO OPeration) does nothing. 

               Syntax:  NOOP

               The NOOP command does not affect anything, and its only 
               action is to cause the server to send an "OK" reply.  It is 
               perhaps useful for testing that the control connection is 
               still functioning.


      PASS -- Specifies user password at login.

               Syntax:  PASS <password>

               The argument to the PASS command is a string of up to 5 
               characters in response to the secure password challenge.  The 
               string may not contain spaces.

               The command must be immediately preceeded by the USER 
               command, which causes the system to replies with a matrix 
               consisting of 5 lines of 5 numbers thus:

                     4 1 6 3 7
                     3 5 2 6 3
                     7 1 9 2 4
                     2 7 1 4 6
                     3 5 2 6 1

               The remote sysop must then choose ONE of the lines, and send 
               the PASS command followed by the 5 characters from the 
               password string which correspond to the 5 numbers on the 
               chosen line.  There must be a space after PASS but no 
               spaces between the characters.

               Example:  PASS WATER

               Notes:
               If the sysop has connected on a port which has SYSOP=1 in the 
               config file (e.g. a secure wire link), the response to this 
               command is ignored, and the sysop is granted full access.

               See also:  USER -- Specify your username.


      PORT -- Specifies the IP address and port for the data connection.

               Syntax:  PORT h1,h2,h3,h4,p1,p2

               The PORT command specifies the IP address and TCP port number 
               to be used by the data connection.  The argument is the 
               concatenation of a 32 bit IP address and a 16 bit TCP port 
               number, broken into 8 bit fields, each field being 
               transmitted as a decimal number.  The fields are seperated by 
               commas, and the high order fields are transmitted first.

               Example:  PORT 44,131,91,2,4,1

               Specifies IP address 44.131.91.2 and TCP port number 0401 
               (1001 decimal)



      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 203
      Command Reference - FTP Server


               Notes:
               Under normal circumstances this command is not needed.  The 
               data connection defaults to TCP port 20 at the client's IP 
               address of the control connection.  However, it allows data 
               to be sent to a completely diffent host if required.


      PWD -- Print Working Directory.

               Syntax:  PWD

               The PWD command causes the full path of the user's current 
               working directory to be displayed via the control connection.

               See also: CWD -- Change Working Directory


      QUIT -- Terminates an FTP session.  

               Syntax:  QUIT

               If a file transfer is not in progress, the QUIT command 
               terminates the FTP session and closes the control connection.

               If file transfer is in progress, the control connection will 
               remain open until transfer is complete, allowing the result 
               code to be transmitted.  The control and data connections 
               will then close.

               An unexpected close on the control connection will abort any 
               data transfer currently in progress.

               See also:  ABOR -- Abort current command.


      RETR -- Retrieve (download) file.

               Syntax:  RETR [drive:\][dir\]<filename>

               The RETR command causes the named file to be sent from the 
               FTP server to the client over the data connection.  If the 
               file can't be found, or access is denied, or the data 
               connection can't be opened, an appropriate error message is 
               returned.

               Examples:  RETR JIM.TXT
                          RETR ../FRED/DOG.EXE
                          RETR C:\CONFIG.SYS

               Notes:  Single files only, wildcards not accepted.

               See also:  PORT -- Specify host/port for data connection.
                          STOR -- Send a file to the server.


      STOR -- Store (upload) file.

               Syntax:  STOR [drive:\][dir\]<filename>




      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 204
      Command Reference - FTP Server


               The STOR command requests the FTP server to accept data via 
               the data connection and store it as a file with the specified 
               name.

               If the file specified in the pathname already exists at the 
               server, it is overwritten by the new data.  The overwrite 
               doesn't take place until the file has been correctly 
               received, which prevents a critical file being lost if the 
               data connection breaks. 

               Examples:  STOR JIM.TXT
                          STOR /FRED/DOG.EXE

               See also:  RETR -- Retrieve a file from the server.


      RMD -- Remove Directory.

               Syntax:  RMD [drive:\]<pathname>

               The RMD command deletes the directory specified by <pathname> 
               from the FTP server, providing you are the owner of that 
               directory and have write access.

               Examples: RMD FRED
                         RMD K:/JIM/BILL

               See also:  MKD -- Make directory


      RNFR -- Rename From

               Syntax:  RNFR [drive:\][dir\]<filename>

               The RNFR command specifies the old pathname of a file which 
               is to be renamed, and must be immediately followed by an RNTO 
               command.  The two commands together cause a file to be 
               renamed.

               If the file isn't found the request will be refused.

               Examples: RNFR ../JIM.TXT
                         RNFR K:/FRED/DOG.EXE

               See also:  RNTO -- Rename To


      RNTO -- Rename To

               Syntax:  RNTO [drive:\][dir\]<filename>

               The RNTO command specifies the new pathname of a file which 
               is being renamed, and must immediately follow an RNFR 
               command.  The two commands together cause a file to be 
               renamed.

               If the new pathname isn't valid, the request will be refused.





      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 205
      Command Reference - FTP Server


               Examples:  RNTO DOG.TXT
                          RNTO K:/FRED/CAT.EXE

               See also:  RNFR -- Rename From.


      STRU -- Specify File Structure.

               Syntax:  STRU <structure_code>

               STRU specifies the internal structure of the files being 
               transferred, i.e.  how the data is organised within them. 
               Structure codes are as follows:

               F - File       No record structure (contiguous bytes)
               R - Record     File is collection of sequential records
               P - Page       File is composed of independant pages

               The default structure, which is the only one currently 
               implemented, is (F)ile.  The command is included to prevent 
               unnecessary error replies.

               Example:  STRU F   Sets (F)ile structure.


      SYST -- Operating system enquiry.

               Syntax:  SYST

               The SYST command is used to find out what type of operating 
               system is being used on the server.

               The first word of the reply is one of the agreed system 
               names, in this case MSDOS.  The rest of the reply gives the 
               server version number and byte size.


      TYPE -- Specifies the data representation type.

               Syntax:  TYPE <type_code>

               The argument to the TYPE command specifies how the data is to 
               be translated between storage and transfer.  Type codes are 
               as follows:

               A - ASCII      Text.  End of line indicated by <CR><LF>   
               I - Image      No translation.  Bytes stored as received.
               L <bytesize>   Size of local storage bytes

               Examples:  TYPE A    Specifies Ascii type.
                          TYPE L 8  Specifies local byte size of 8 bits


      USER -- Specify user name for login.

               Syntax:  USER <username>






      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 206
      Command Reference - FTP Server


               The argument to the USER command is a string of up to 8 
               characters specifying the user's login name (usually 
               callsign).  The string must not contain spaces.

               Users are not allowed access to the system without logging 
               in.

               If the username (or callsign) exists in the PASSWORD.SYS file 
               the server sends a grid of 5x5 numbers (see PASS command) 
               generated from the user's stored password.  If the username 
               is not found, an error message is sent instead, and access 
               will not be permitted.

               The USER command must be immediately followed by the PASS 
               command.

               Example:  USER SYSOP   Enters your login name as "SYSOP"
                         USER G8PZT   Use callsign


               Note: Because the FTP server allows you to use any string of 
               characters as a name, you may set up different passwords for 
               different login names, and these may be in addition to your 
               callsign, which is the one used for ax25 sysop access.

               See also:  PASS -- Specify password.




































      XROUTER Sysop Manual Revision 2.1 (27/7/02)             Page 207
                                                                                                                               