			 XRouter Changes Since V179c
			 ============================

Please read this thoroughly.  You may need to make some changes to your
v179 configuration in order to run v180.

- Added very rudimentary HTTP server / user interface.  This will serve
  files off disk, and also provides a means to run certain node commands
  and view the output as web pages.  It includes tunnelling and proxy
  tunnelling support, with egress control.  The HTTP server is located
  on port 80.

  When servicing a request which does not include a filename in the URL,
  (e.g. "http://g8pzt.ath.cx/") the web server looks in the HTTP root
  directory for a file called INDEX.HTM.  If that file is not present, it
  will look for DEFAULT.HTM.  I have supplied a simple example INDEX.HTM,
  for your guidance.  It is by no means a perfect web page, just something
  thrown together to test a concept. You may alter it to suit your own
  preferences if you have some HTML skill.  You may need to alter the
  address in the "Connect" link to suit your own IP address/hostname.
  The connect function is normally performed by a Java applet, but I am
  not including that at present, as someone has reported that their
  browser doesn't display it properly.  I'll post it to the group when
  I've had a look at the problem.

  INDEX.HTM is meant as a default entry point for your Xrouter-hosted web
  site.  Although Xrouter's primary purpose is a router not a server,
  and the primary purpose of Xrouter's HTTP server is to provide a web
  interface to the system, you may choose to create a complex web site,
  of which the command interface is but a small part.  You may prefer to
  use index.htm as a splash or menu page for your site, putting the
  command interface on one or more linked sub-pages.  Or you may choose
  the opposite approach, putting all the commands on the main page along
  with links to other sites.  I leave the creativity to you...

  The web server root directory is specified using the HTTPROOT directive
  in Xrouter.cfg, e.g. "HTTPROOT=C:\WEB".  If you omit this directive,
  the default will be a directory called "HTTP" within the xrouter
  directory.  For security reasons it is important that you don't use the
  Xrouter directory as the HTTP root!

  A new HTTP.ACL file holds the egress control rules for the proxy/tunnel,
  and should preferably be located on a ramdisk configured as drive R: for
  best results. If a ramdisk is not used, locate the file in the same
  directory as Xrouter.  If the file not present, all egress is blocked.

- The SEND command caused crashing when used in CRONTAB.SYS - fixed.

- In networks where there are a lot of unreliable nodes, Xrouter could
  waste a lot of airtime trying to connect to them, not only for link
  checking but also when trying to route traffic for nodes advertised
  by those neighbours.

  For non-locked routes therefore, Xrouter now zeros the route quality
  if it fails to connect, which prevents it from trying again until the
  next nodes broadcast is heard from that neighbour.

  There is a caveat... a *good* non-locked route could be disabled for
  up to an hour by a temporary outage, so the sysop must now lock in all
  the wanted routes to ensure best reliability.

- Added "-a" switch to Netrom/ax25->telnet proxy.  This must be the
  LAST argument, and if present it opens an ascii (i.e. normal telnet)
  downlink instead of a binary one. This is to allow it to be used with
  DxSpider.

- The "R X" command was displaying the wrong caption probably since
  v179a - fixed.

- Added new file TELPROXY.ACL to provide TCP/IP egress control for the
  Telnet proxy server.  This should preferably be located on a ramdisk
  configured as drive R: for best results. If a ramdisk is not used,
  locate the file in the same directory as Xrouter.  If the file not
  present, all egress is blocked.

- Added comprehensive TCP/IP packet filtering controlled by ACL rules
  located in IPROUTE.SYS.  This acts upon both incoming datagrams and
  those originated by xrouter, and can filter packets based on any
  combination of source or destination IP addresses, Layer 4 protocols
  and layer 4 service port numbers.  It can for example be used to
  control access to the HTTP server, telnet proxy etc., or as a firewall
  for other systems.  If no ACL rules are specified, no filtering is
  performed.  Even if you don't need this at the moment, you might like
  to cut the following and append it to your IPROUTE.SYS file to keep
  it up to date.

  ------------------------------ Cut -------------------------------

# ==================================================================
# TCP/IP filter control rules
#
# Fields: ACL <action> <src_ip>[/mask][:port] <dst_ip>[/mask][:port] [proto]
#
# <action>      PERMIT  Allow routing / access
#               DENY    Prevent routing / access
# <src_ip>      Source IP address of datagrams
# <dst_ip>      Destination IP address of datagrams
# [mask]        Either: No. of bits (0-32) to match from left to right
#               Or:     Subnet mask in form n.n.n.n
# [port]        TCP / UDP service numbers (0-65535) 0 = all ports.
# [proto]	Protocol number (TCP=6, UDP=17. 0=all protocols)
#
;acl permit	192.168.0.0/16	44.131.91.0/24
;
; prevent tcp access to test xrouter web server from bbs
;acl deny	192.168.0.4	192.168.0.2:80	6
;acl permit	192.168.0.0/24	0.0.0.0/0

  ----------------------------  End -------------------------------


- The L3ONLY configuration keyword was obsoleted by CFLAGS two years ago
  and should have been removed because it no longer had any effect - now
  removed.

- If CFLAGS was configured to prevent users from downlinking on a port,
  it also prevented applications from downlinking on that port.  This
  was intentional, because some applications contain gateways which
  allow users to connect from the application to the node, thus any
  users which do so must not be able to override security.  However,
  some applications may have valid reasons for needing to override a
  downlink ban, so I have added a new flag to CFLAGS:

     4  - Applications may downlink unconditionally.

  If this flag is set, applications may downlink whatever the setting
  of the "Enable L2 downlinks" flag. e.g. CFLAGS=1 prevents everyone
  except sysops from downlinking, whereas CFLAGS=5 prevents everyone
  except sysops and applications from downlinking.

- The ability to give an application sysop privileges might be useful
  for those who run tsthost or pac4 as a sysop console, so I have added
  a new keyword APPLFLAGS to the APPL configuration block.  If
  APPLFLAGS=1, the application gets sysop privileges.  This required a
  minor change to PZTHOST.EXE v1.5, the new version being v1.6.  You must
  use pzthost1.5 with xrouter179 and pzthost1.6 with xrouter180.

- Added another flag to CFLAGS, to keep the Luddites happy.  Setting this
  flag (bit 4, decimal 8) will prevent L3RTT frames from being originated
  on the port.  It will not prevent Xrouter from trying to hold L2 links
  open, as that is a retrograde step.  This flag is not set by default.
  Without L3RTT frames, INP3-capable neighbours will not send INP3 to you.

- If global MAXTT or all port MAXTT's were set to 0, the "internal" nodes
  such as chat, pms, proxies etc. were not entered into nodes table - fixed.

