ARM Club 1/ARM_CLUB_CD.iso/contents/apps/comms/a/freenet/!FreeNet_Docs_Setup

Text File | 1995-04-22 | 9.0 KB | 206 lines

                  Configuring the FreeNet TCP/IP Stack

                          (C) Tom Hughes 1995

0. Copyright

  The FreeNet module and application and the tools and documentation
  that go with them are all copyright. They are however released as
  freeware subject to certain terms and conditions. These are described
  in the file named 'Licence' which should have accompanied this
  document.

1. Overview

  Configuring FreeNet is a relatively simple process which requires the
  editing of two scripts; one which starts up FreeNet and one which
  shuts it down again.

  The first of these two scripts, !FreeUser.Startup, begins by loading
  the necessary modules and then configures the interfaces and routing
  ready for use. The second kills off all the modules, and returns the
  system to its normal state.

  The remainder of this document details the various commands used in
  the startup file to configure parts of the system. This, together with
  the example provided with FreeNet should be sufficient to configure
  FreeNet without any problems. Hopefully a future release of FreeNet
  will include a desktop application to do this configuration.

2. Installing additional hardware drivers

  If you wish to use a hardware driver other than those supplied with
  FreeNet, you will to place the appropriate module in !FreeUser.Drivers
  and then add a line to the startup script to load this driver.

  You can of course store the module somewhere else if you wish. The
  named directory is simply provided as a convenient place where you may
  wish to place it. Note that this is not the same as !FreeNet.Drivers
  which is the directory used to hold the supplied drivers.

  The startup script will also need to be modified to load this driver
  by adding an appropriate 'RMRun' command. If the driver has been
  installed in !FreeUser.Drivers, you can use the FreeNet: path to
  locate the driver, as in this example:

      RMRun FreeNet:Drivers.SLIPdriver

  This command would load a driver named SLIPdriver which was in either
  !FreeUser.Drivers (for user installed drivers) or !FreeNet.Drivers
  (for FreeNet supplied drivers).

3. Configuring interfaces

  The first thing you will need to do after loading FreeNet and your
  chosen hardware driver is to configure the interfaces that you wish to
  use. You should note that some drivers (including the supplied SLIP
  driver) will need some configuration before this can be done, and you
  should consult the documentation supplied with the driver for the
  relevant information.

  Once this has been done, the ifconfig command can be used to inform
  FreeNet that the interface exists, and to set various relevant
  options. The syntax of this command is as follows:

      ifconfig <interface> [inet <local-address> [<remote-address>]]
               [netmask <mask>] [broadcast <address>] [arp] [up|down]

  Here, you should give the address that you wish to assign to the
  interface as <local-address> and for point-to-point links like SLIP or
  PPP connections, the address of the other end of the link should be
  given for <remote-address>.

  If the interface is on a network that has been subnetted, you will
  need to specify an appropriate value for the netmask. If you don't
  know what this should be, your sysadmin should be able to tell you.

  For broadcast networks such as ethernet, you can specify the address
  to be used for broadcast packets on that network. This will default to
  the standard 255.255.255.255 unless otehrwise specified. You will also
  need to include the arp flag when configuring an interface on a
  broadcast network, to specify that the ARP protocol should be used to
  resolve addresses on the local network.

  Finally, the interface is marked up or down by including the keyword
  up or down in the ifconfig command line. An interface that is marked
  down will not be used to transmit packets, so this can be used to
  temporarily disable an interface.

  To summarise all this, consider the following examples of ifconfig
  commands. The first example configures a SLIP interface with a local
  address of 158.152.40.58 which talks to 158.152.1.222 at the other end
  of the link:

      ifconfig sl0 inet 158.152.40.58 158.152.1.222 up

  A typical ethernet interface would be configured as follows, where the
  host 163.162.5.45 is on subnet 163.162.5.0 of a class B network whose
  number is 163.162.0.0, giving a netmask of 0xffffff00.

      ifconfig eb0 inet 163.162.5.45 netmask 0xffffff00 arp up

  This interface could be temporarily removed from operation using the
  command:

      ifconfig eb0 down

  It would then be returned to use using the following:

      ifconfig eb0 up

  Once you have configured your interfaces, you should be able to obtain
  a list of available interfaces using the command 'netstat -i'.

4. Configuring the routing tables

  Having a system with properly configured interfaces is not much help
  unless TCP/IP is told which packets to route through which interfaces,
  and what address those packets should be addressed through. When an
  interface is configured, a single route will be added to the routing
  tables for that interface, which will be sufficient to reach some
  local hosts.

  In the case of point-to-point links like SLIP, a route will have been
  added for the remote address at the other end of the link. This will
  allow you to talk to that machine but to nothing else. For interfaces
  on broadcast networks such as ethernet, things are slightly better as
  there will be a route to all hosts on the local (sub)net. You should
  be able to use 'netstat -r' to see what routes are currently in the
  routing tables.

  Adding and removing routes is done using the route command. The add
  form of the command has the following syntax:

      route add <destination>[/<bits>] <gateway> <metric>

  Where <destination> is the address of a host or network that can be
  reached via the host identified by <gateway>. The <metric> parameter
  is an indication of the efficiency of that route compared to others to
  the same destination.

  Normally, the destination address will be examined to see whether the
  host part of the address is zero. If it is, the route will be treated
  as a route to a network, otherwise it will be treated as a route to a
  specific host. This can be overridden by specifying the number of bits
  of the destination address which should be treated as significant.

  Where the destination is on a directly attached network, you should
  specify your own address as the gateway, and give a metric of zero. In
  other cases, the gateway should be the address of a machine on a
  directly connected network that knows how to reach the specified
  destination, and the metric should be non-zero.

  As an example, consider the following, which tells the machine from
  our previous example (163.162.5.45) how to reach machines on the
  subnet 163.162.12.0 of the local network:

      route add 163.162.12.0 163.162.5.1 1

  This says that addresses on subnet 163.162.12.0 can be reached by
  sending packets to 163.162.5.1 which is on the directly connected
  subnet (163.162.5.0) and knows how to reach the other subnet. By
  comparison, the following tells the same machine how to reach the
  local subnet (this would normally be done automatically by ifconfig of
  course):

      route add 163.162.5.0 163.162.5.45 0

  One final, and vital point about adding routes is the setting of the
  default route. This is done by specifing 'default' as the destination,
  and this route will be used for any destination which does not have an
  explicit route in the routing tables.

  Deleteing routes is accomplished by using the following, alternative
  syntax of the route command:

      route delete <destination>[/<bits>] <gateway>

  Where the <destination> and <gateway> parameters are those given to
  the original 'route add', and which can be displayed by using the
  command 'netstat -r' to examine the routing tables.

5. Checking your configuration

  Once you have configured your interfaces and routing tables, and
  verified them using 'netstat -i' and 'netstat -r', you should be ready
  to go.

  At this point, you will probably want to use the ping utility to
  ensure that your machine can see other machines. In its simplest form,
  you can simply type 'ping <address>' to test whether your machine can
  see a particular remote machine. Full documentation for the ping tool
  can be found in the appropriate file.

  Another useful utility is traceroute which will attempt to work out
  what route a packet would follow to reach a given address. This is
  useful in attempting to solve routing problems, and can be used by
  entering 'traceroute <address>'. Full documentation of other options
  for this tool are documented seperately.

  Other forms of the netstat command which you may also find useful
  include 'netstat' which lists all sockets which are currently in
  existence, 'netstat -s' which gives a large number of statistics about
  the number and type of packets which have passed throught the TCP/IP
  stack, and 'netstat -m' which reports how many memory buffers ar
  currently free for use.