🚀 go-pugleaf

Archive-name: linux/howto/AX25-HOWTO/part2
Last-modified: 30 Jun 97

-----BEGIN PGP SIGNED MESSAGE-----

*** The `Linux AX25 HOWTO' is posted automatically by the
*** Linux HOWTO coordinator, Greg Hankins <gregh@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Terry Dawson <terry@perf.no.itg.telecom.com.au>.

- --- BEGIN Linux AX25 HOWTO part 2/3 ---

  To assist in the diagnosis of problems you can use the sccstat program
  to display the current configuration of an SCC device. To use it try:

       # sccstat /dev/scc0

  you will displayed a very large amount of information relating to the
  configuration and health of the /dev/scc0 SCC port.
  The sccparam command allows you to change or modify a configuration
  after you have booted. Its syntax is very similar to the NOS param
  command, so to set the txtail setting of a device to 100mS you would
  use:

       # sccparam /dev/scc0 txtail 0x8

  7.1.8.  Creating a BPQ ethernet device.

  Kernel Compile Options:

       General setup  --->
           [*] Networking support
       Network device support  --->
           [*] Network device support
           ...
           [*] Radio network interfaces
           [*] BPQ Ethernet driver for AX.25

  Linux supports BPQ Ethernet compatibility. This enables you to run the
  AX.25 protocol over your Ethernet LAN and to interwork your linux
  machine with other BPQ machines on the LAN.

  The BPQ network devices are named `bpq[0-9]'. The `bpq0' device is
  associated with the `eth0' device, the `bpq1' device with the `eth1'
  device etc.

  Configuration is quite straightforward. You firstly must have
  configured a standard Ethernet device. This means you will have
  compiled your kernel to support your Ethernet card and tested that
  this works. Refer to the Ethernet-HOWTO <Ethernet-HOWTO.html> for more
  information on how to do this.

  To configure the BPQ support you need to configure the Ethernet device
  with an AX.25 callsign. The following command will do this for you:

       # /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up

  Again, remember that the callsign you specify should match the entry
  in the /etc/ax25/axports file that you wish to use for this port.

  7.1.9.  Configuring the BPQ Node to talk to the Linux AX.25 support.

  BPQ Ethernet normally uses a multicast address. The Linux
  implementation does not, and instead it uses the normal Ethernet
  broadcast address. The NET.CFG file for the BPQ ODI driver should
  therefore be modifified to look similar to this:

       LINK SUPPORT

               MAX STACKS 1
               MAX BOARDS 1

       LINK DRIVER E2000                    ; or other MLID to suit your card

               INT 10                       ;
               PORT 300                     ; to suit your card

               FRAME ETHERNET_II

               PROTOCOL BPQ 8FF ETHERNET_II ; required for BPQ - can change PID

       BPQPARAMS                            ; optional - only needed if you want
                                            ; to override the default target addr

               ETH_ADDR  FF:FF:FF:FF:FF:FF  ; Target address

  7.2.  Creating the /etc/ax25/axports file.

  The /etc/ax25/axports is a simple text file that you create with a
  text editor. The format of the /etc/ax25/axports file is as follows:

       portname  callsign  baudrate  paclen  window  description

  where:

     portname
        is a text name that you will refer to the port by.

     callsign
        is the AX.25 callsign you want to assign to the port.

     baudrate
        is the speed at which you wish the port to communicate with your
        TNC.

     paclen
        is the maximum packet length you want to configure the port to
        use for AX.25 connected mode connections.

     window
        is the AX.25 window (K) parameter. This is the same as the
        MAXFRAME setting of many tnc's.

     description
        is a textual description of the port.

  In my case, mine looks like:

       radio    VK2KTJ-15       4800        256     2       4800bps 144.800 MHz
       ether    VK2KTJ-14       10000000    256     2       BPQ/ethernet device

  Remember, you must assign unique callsign/ssid to each AX.25 port you
  create.  Create one entry for each AX.25 device you want to use, this
  includes KISS, Baycom, SCC, PI, PT and SoundModem ports. Each entry
  here will describe exactly one AX.25 network device. The entries in
  this file are associated with the network devices by the
  callsign/ssid. This is at least one good reason for requiring unique
  callsign/ssid.

  7.3.  Configuring AX.25 routing.

  You may wish to configure default digipeaters paths for specific
  hosts.  This is useful for both normal AX.25 connections and also IP
  based connections.  The axparms command enables you to do this. Again,
  the man page offers a complete description, but a simple example might
  be:

       # /usr/sbin/axparms -route add radio VK2XLZ VK2SUT

  This command would set a digipeater entry for VK2XLZ via VK2SUT on the
  AX.25 port named radio.

  8.  Configuring an AX.25 interface for TCP/IP.

  It is very simple to configure an AX.25 port to carry TCP/IP.  If you
  have KISS interfaces then there are two methods for configuring an IP
  address. The kissattach command has an option that allows you to do
  specify an IP address. The more conventional method using the ifconfig
  command will work on all interface types.

  So, modifying the previous KISS example:

       # /usr/sbin/kissattach -i 44.136.8.5 -m 512 /dev/ttyS0 radio
       # /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 ax0
       # /sbin/route add default ax0

  to create the AX.25 interface with an IP address of 44.136.8.5 and an
  MTU of 512 bytes. You should still use the ifconfig to configure the
  other parameters if necessary.

  If you have any other interface type then you use the ifconfig program
  to configure the ip address and netmask details for the port and add a
  route via the port, just as you would for any other TCP/IP interface.
  The following example is for a PI card device, but would work equally
  well for any other AX.25 network device:

       # /sbin/ifconfig pi0a 44.136.8.5 netmask 255.255.255.0 up
       # /sbin/ifconfig pi0a broadcast 44.136.8.255 mtu 512
       # /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 pi0a
       # /sbin/route add default pi0a

  The commands listed above are typical of the sort of configuration
  many of you would be familiar with if you have used NOS or any of its
  derivatives or any other TCP/IP software. Note that the default route
  might not be required in your configuration if you have some other
  network device configured.

  To test it out, try a ping or a telnet to a local host.

       # ping -i 5 44.136.8.58

  Note the use of the `-i 5' arguments to ping to tell it to send pings
  every 5 seconds instead of its default of 1 second.

  9.  Configuring a NetRom port.

  The NetRom protocol relies on, and uses the AX.25 ports you have
  created.  The NetRom protocol rides on top of the AX.25 protocol. To
  configure NetRom on an AX.25 interface you must configure two files.
  One file describes the Netrom interfaces, and the other file describes
  which of the AX.25 ports will carry NetRom. You can configure multiple
  NetRom ports, each with its own callsign and alias, the same procedure
  applies for each.

  9.1.  Configuring /etc/ax25/nrports

  The first is the /etc/ax25/nrports file. This file describes the
  NetRom ports in much the same way as the /etc/ax25/axports file
  describes the AX.25 ports. Each NetRom device you wish to create must
  have an entry in the /etc/ax25/nrports file. Normally a Linux machine
  would have only one NetRom device configured that would use a number
  of the AX.25 ports defined. In some situations you might wish a
  special service such as a BBS to have a seperate NetRom alias and so
  you would create more than one.

  This file is formatted as follows:

       name callsign  alias  paclen   description

  Where:

     name
        is the text name that you wish to refer to the port by.

     callsign
        is the callsign that the NetRom traffic from this port will use.
        Note, this is not that address that users should connect to to
        get access to a node style interface. (The node program is
        covered later). This callsign/ssid should be unique and should
        not appear elsewhere in either of the /etc/ax25/axports or the
        /etc/ax25/nrports files.

     alias
        is the NetRom alias this port will have assigned to it.

     paclen
        is the maximum size of NetRom frames transmitted by this port.

     description
        is a free text description of the port.

  An example would look something like the following:

       netrom  VK2KTJ-9        LINUX   236     Linux Switch Port

  This example creates a NetRom port known to the rest of the NetRom
  network as `LINUX:VK2KTJ-9'.

  This file is used by programs such as the call program.

  9.2.  Configuring /etc/ax25/nrbroadcast

  The second file is the /etc/ax25/nrbroadcast file. This file may
  contain a number of entries. There would normally be one entry for
  each AX.25 port that you wish to allow NetRom traffic on.

  This file is formatted as follows:

       axport min_obs def_qual worst_qual verbose

  Where:

     axport
        is the port name obtained from the /etc/ax25/axports file. If
        you do not have an entry in /etc/ax25/nrbroadcasts for a port
        then this means that no NetRom routing will occur and any
        received NetRom broadcasts will be ignored for that port.

     min_obs
        is the minimum obselesence value for the port.

     def_qual
        is the default quality for the port.

     worst_qual
        is the worst quality value for the port, any routes under this
        quality will be ignored.

     verbose
        is a flag determining whether full NetRom routing broadcasts
        will occur from this port or only a routing broadcast
        advertising the node itself.

  An example would look something like the following:

       radio    1       200      100         1

  9.3.  Creating the NetRom Network device

  When you have the two configuration files completed you must create
  the NetRom device in much the same way as you did for the AX.25
  devices.  This time you use the nrattach command. The nrattach works
  in just the same way as the axattach command except that it creates
  NetRom network devices called `nr[0-9]'. Again, the first time you use
  the nrattach command it creates the `nr0' device, the second time it
  creates the `nr1' network devices etc. To create the network device
  for the NetRom port we've defined we would use:

       # nrattach netrom

  This command would start the NetRom device (nr0) named netrom
  configured with the details specified in the /etc/ax25/nrports file.

  9.4.  Starting the NetRom daemon

  The Linux kernel does all of the NetRom protocol and switching, but
  does not manage some functions. The NetRom daemon manages the NetRom
  routing tables and generates the NetRom routing broadcasts. You start
  NetRom daemon with the command:

       # /usr/sbin/netromd -i

  You should soon see the /proc/net/nr_neigh file filling up with
  information about your NetRom neighbours.

  Remember to put the /usr/sbin/netromd command in your rc files so that
  it is started automatically each time you reboot.

  9.5.  Configuring NetRom routing.

  You may wish to configure static NetRom routes for specific hosts.
  The nrparms command enables you to do this. Again, the man page offers
  a complete description, but a simple example might be:

       # /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9

  This command would set a NetRom route to #MINTO:VK2XLZ-10 via a
  neighbour VK2SUT-9 on my AX.25 port called `radio'.

  You can manually create entries for new neighbours using the nrparms
  command as well. For example:

  # /usr/sbin/nrparms -routes radio VK2SUT-9 + 120

  This command would create VK2SUT-9 as a NetRom neighbour with a
  quality of 120 and this will be locked and will not be deleted
  automatically.

  10.  Configuring a NetRom interface for TCP/IP.

  Configuring a NetRom interface for TCP/IP is almost identical to
  configuring an AX.25 interface for TCP/IP.

  Again you can either specify the ip address and mtu on the nrattach
  command line, or use the ifconfig and route commands, but you need to
  manually add arp entries for hosts you wish to route to because there
  is no mechanism available for your machine to learn what NetRom
  address it should use to reach a particular IP host.

  So, to create an nr0 device with an IP address of 44.136.8.5, an mtu
  of 512 and configured with the details from the /etc/ax25/nrports file
  for a NetRom port named netrom you would use:

       # /usr/sbin/nrattach -i 44.136.8.5 -m 512 netrom
       # route add 44.136.8.5 nr0

  or you could use something like the following commands manually:

       # /usr/sbin/nrattach netrom
       # ifconfig nr0 44.136.8.5 netmask 255.255.255.0 hw netrom VK2KTJ-9
       # route add 44.136.8.5 nr0

  Then for each IP host you wish to reach via NetRom you need to set
  route and arp entries. To reach a destination host with an IP address
  of 44.136.80.4 at NetRom address BBS:VK3BBS via a NetRom neighbour
  with callsign VK2SUT-0 you would use commands as follows:

       # route add 44.136.80.4 nr0
       # arp -t netrom -s 44.136.80.4 vk2sut-0
       # nrparms -nodes vk3bbs + BBS 120 6 sl0 vk2sut-0

  The `120' and `6' arguments to the nrparms command are the NetRom
  quality and obsolescence count values for the route.

  11.  Configuring a Rose port.

  The Rose packet layer protocol is similar to layer three of the X.25
  specification. The kernel based Rose support is a modified version of
  the FPAC Rose implementation
  <http://fpac.lmi.ecp.fr/f1oat/f1oat.html>.

  The Rose packet layer protocol protocol relies on, and uses the AX.25
  ports you have created. The Rose protocol rides on top of the AX.25
  protocol.  To configure Rose you must create a configuration file that
  describes the Rose ports you want. You can create multiple Rose ports
  if you wish, the same procedure applies for each.

  11.1.  Configuring /etc/ax25/rsports

  The file where you configure your Rose interfaces is the
  /etc/ax25/rsports file. This file describes the Rose port in much the
  same way as the /etc/ax25/axports file describes the AX.25 ports.

  This file is formatted as follows:

       name  addresss  description

  Where:

     name
        is the text name that you wish to refer to the port by.

     address
        is the 10 digit Rose address you wish to assign to this port.

     description
        is a free text description of the port.

  An example would look something like the following:

       rose  5050294760  Rose Port

  Note that Rose will use the default callsign/ssid configured on each
  AX.25 port unless you specify otherwise.

  To configure a seperate callsign/ssid for Rose to use on each port you
  use the rsparms command as follows:

       # /usr/sbin/rsprams -call VK2KTJ-10

  This example would make Linux listen for and use the callsign/ssid
  VK2KTJ-10 on all of the configured AX.25 ports for Rose calls.

  11.2.  Creating the Rose Network device.

  When you have created the /etc/ax25/rsports file you may create the
  Rose device in much the same way as you did for the AX.25 devices.
  This time you use the rsattach command. The rsattach command creates
  network devices named `rose[0-5]'. The first time you use the rsattach
  command it create the `rose0' device, the second time it creates the
  `rose1' device etc. For example:

       # rsattach rose

  This command would start the Rose device (rose0) configured with the
  details specified in the /etc/ax25/rsports file for the entry named
  `rose'.

  11.3.  Configuring Rose Routing

  The Rose protocol currently supports only static routing. The rsparms
  utility allows you to configure your Rose routing table under Linux.

  For example:

       # rsparms -nodes add 5050295502 radio vk2xlz

  would add a route to Rose node 5050295502 via an AX.25 port named
  `radio' in your /etc/ax25/axports file to a neighbour with the call�
  sign VK2XLZ.

  You may specify a route with a mask to capture a number of Rose
  destinations into a single routing entry. The syntax looks like:

       # rsparms -nodes add 5050295502/4 radio vk2xlz

  which would be identical to the previous example except that it would
  match any destination address that matched the first four digits sup�
  plied, in this case any address commencing with the digits 5050. An
  alternate form for this command is:

       # rsparms -nodes add 5050/4 radio vk2xlz

  which is probably the less ambiguous form.

  12.  Making AX.25/NetRom/Rose calls.

  Now that you have all of your AX.25, NetRom and Rose interfaces
  configured and active, you should be able to make test calls.

  The AX25 Utilities package includes a program called `call' which is a
  splitscreen terminal program for AX.25, NetRom and Rose.

  A simple AX.25 call would look like:

       /usr/bin/call radio VK2DAY via VK2SUT

  A simple NetRom call to a node with an alias of SUNBBS would look
  like:

       /usr/bin/call netrom SUNBBS

  A simple Rose call to HEARD at node 5050882960 would look like:

       /usr/bin/call rose HEARD 5050882960

  Note: you must tell call which port you wish to make the call on, as
  the same destination node might be reachable on any of the ports you
  have configured.

  The call program is a linemode terminal program for making AX.25
  calls. It recognises lines that start with `~' as command lines.  The
  `~.' command will close the connection.

  Please refer to the man page in /usr/man for more information.

  13.  Configuring Linux to accept Packet connections.

  Linux is a powerful operating system and offers a great deal of
  flexibility in how it is configured. With this flexibility comes a
  cost in configuring it to do what you want. When configuring your
  Linux machine to accept incoming AX.25, NetRom or Rose connections
  there are a number of questions you need to ask yourself. The most
  important of which is: "What do I want users to see when they
  connect?". People are developing neat little applications that may be
  used to provide services to callers, a simple example is the pms
  program included in the AX25 utilities, a more complex example is the
  node program also included in the AX25 utilities. Alternatively you
  might want to give users a login prompt so that they can make use of a
  shell account, or you might even have written your own program, such
  as a customised database or a game, that you want people to connect
  to. Whatever you choose, you must tell the AX.25 software about this
  so that it knows what software to run when it accepts an incoming
  AX.25 connection.

  The ax25d program is similar to the inetd program commonly used to
  accept incoming TCP/IP connections on unix machines. It sits and
  listens for incoming connections, when it detects one it goes away and
  checks a configuration file to determine what program to run and
  connect to that connection. Since this the standard tool for accepting
  incoming AX.25, NetRom and Rose connections I'll describe how to
  configure it.

  13.1.  Creating the /etc/ax25/ax25d.conf file.

  This file is the configuration file for the ax25d AX.25 daemon which
  handles incoming AX.25, NetRom and Rose connections.

  The file is a little cryptic looking at first, but you'll soon
  discover it is very simple in practice, with a small trap for you to
  be wary of.

  The general format of the ax25d.conf file is as follows:

       # This is a comment and is ignored by the ax25d program.
       [port_name] || <port_name> || {port_name}
       <peer1>    window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       <peer2>    window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       parameters window T1 T2 T3 idle N2 <mode>
       <peer3>    window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       default    window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>

  Where:

     #  at the start of a line marks a comment and is completely ignored
        by the ax25d program.

     <port_name>
        is the name of the AX.25, NetRom or Rose port as specified in
        the /etc/ax25/axports, /etc/ax25/nrports and /etc/ax25/rsports
        files. The name of the port is surrounded by the `[]' brackets
        if it is an AX.25 port, the `<>' brackets if it is a NetRom
        port, or the `{}' brackets if it is a Rose port.  There is an
        alternate form for this field, and that is use prefix the port
        name with `callsign/ssid via' to indicate that you wish accept
        calls to the callsign/ssid via this interface. The example
        should more clearly illustrate this.

     <peer>
        is the callsign of the peer node that this particular
        configuration applies to. If you don't specify an SSID here then
        any SSID will match.

     window
        is the AX.25 Window parameter (K) or MAXFRAME parameter for this
        configuration.

     T1 is the Frame retransmission (T1) timer in half second units.

     T2 is the amount of time the AX.25 software will wait for another
        incoming frame before preparing a response in 1 second units.

     T3 is the amount of time of inactivity before the AX.25 software
        will disconnect the session in 1 second units.

     idle
        is the idle timer value in seconds.

     N2 is the number of consecutive retransmissions that will occur
        before the connection is closed.

     <mode>
        provides a mechanism for determining certain types of general
        permissions. The modes are enabled or disabled by supplying a
        combination of characters, each representing a permission. The
        characters may be in either upper or lower case and must be in a
        single block with no spaces.

        u/U
           UTMP                   - currently unsupported.

        v/V
           Validate call          - currently unsupported.

        q/Q
           Quiet                  - Don't log connection

        n/N
           check NetRom Neighbour - currently unsupported.

        d/D
           Disallow Digipeaters   - Connections must be direct, not
           digipeated.

        l/L
           Lockout                - Don't allow connection.

        */0
           marker                 - place marker, no mode set.

     <uid>
        is the userid that the program to be run to support the
        connection should be run as.

     <cmd>
        is the full pathname of the command to be run, with no arguments
        specified.

     <cmd-name>
        is the text that should appear in a ps as the command name
        running (normally the same as <cmd> except without the directory
        path information.

     <arguments>
        are the command line argument to be passed to the <:cmd> when it
        is run. You pass useful information into these arguments by use
        of the following tokens:

        %d Name of the port the connection was received on.

        %U AX.25 callsign of the connected party without the SSID, in
           uppercase.

        %u AX.25 callsign of the connected party without the SSID, in
           lowercase.

        %S AX.25 callsign of the connected party with the SSID, in
           uppercase.

        %s AX.25 callsign of the connected party with the SSID, in
           lowercase.

        %P AX.25 callsign of the remote node that the connection came in
           from without the SSID, in uppercase.

        %p AX.25 callsign of the remote node that the connection came in
           from without the SSID, in lowercase.

        %R AX.25 callsign of the remote node that the connection came in
           from with the SSID, in uppercase.
        %r AX.25 callsign of the remote node that the connection came in
           from with the SSID, in lowercase.

  You need one section in the above format for each AX.25, NetRom or
  Rose interface you want to accept incoming AX.25, NetRom or Rose
  connections on.

  There are two special lines in the paragraph, one starts with the
  string `parameters' and the other starts with the string `default'
  (yes there is a difference). These lines serve special functions.

  The `default' lines purpose should be obvious, this line acts as a
  catch-all, so that any incoming connection on the <interface_call>
  interface that doesn't have a specific rule will match the `default'
  rule. If you don't have a `default' rule, then any connections not
  matching any specific rule will be disconnected immediately without
  notice.

  The `parameters' line is a little more subtle, and here is the trap I
  mentioned earlier. In any of the fields for any definition for a peer
  you can use the `*' character to say `use the default value'. The
  `parameters' line is what sets those default values. The kernel
  software itself has some defaults which will be used if you don't
  specify any using the `parameters' entry. The trap is that the these
  defaults apply only to those rules below the `parameters' line not to
  those above. You may have more than one `parameters' rule per
  interface definition, and in this way you may create groups of default
  configurations.

  13.2.  A simple example ax25d.conf file.

  Ok, an illustrative example:

       # ax25d.conf for VK2KTJ - 02/03/97
       # This configuration uses the AX.25 port defined earlier.

       # <peer> Win T1  T2  T3  idl N2 <mode> <uid> <exec> <argv[0]>[<args....>]

       [VK2KTJ-0 via radio]
       parameters 1    10  *  *  *   *   *    root  /usr/sbin/axspawn axspawn %u +
       VK2XLZ     *     *  *  *  *   *   *
       VK2DAY     *     *  *  *  *   *   *
       NOCALL     *     *  *  *  *   *   L
       default    1    10  5 100 180 5   *    root  /usr/sbin/pms pms -a -o vk2ktj

       [VK2KTJ-1 via radio]
       default    *     *    *   *   *   0    root /usr/sbin/node node

       <netrom>
       parameters 1    10  *  *  *   *   *
       NOCALL     *     *  *  *  *   *   L
       default    *     *  *  *  *   *   0        root /usr/sbin/node node

       {VK2KTJ-0 via rose}
       parameters 1    10  *  *  *   *   *    root  /usr/sbin/axspawn axspawn %u +
       VK2XLZ     *     *  *  *  *   *   *
       VK2DAY     *     *  *  *  *   *   *
       NOCALL     *     *  *  *  *   *   L
       default    1    10  5 100 180 5   *    root  /usr/sbin/pms pms -a -o vk2ktj

       {VK2KTJ-1 via rose}
       default    *     *    *   *   *   0    root /usr/sbin/node node radio

  This example says that anybody attempting to connect to the callsign
  `VK2KTJ-0' heard on the AX.25 port called `radio' will have the
  following rules applied:

  Anyone whose callsign is set to `NOCALL' should be locked out, note
  the use of mode `L'.

  The parameters line changes two parameters from the kernel defaults
  (Window and T1) and will run the /usr/sbin/axspawn program for them.
  Any copies of /usr/sbin/axspawn run this way will appear as axspawn in
  a ps listing for convenience. The next two lines provide definitions
  for two stations who will receive those permissions.

  The last line in the paragraph is the `catch all' definition that
  everybody else will get (including VK2XLZ and VK2DAY using any other
  SSID other than -1).  This definition sets all of the parameters
  implicitly and will cause the pms program to be run with a command
  line argument indicating that it is being run for an AX.25 connection,
  and that the owner callsign is VK2KTJ. (See the `Configuring the PMS'
  section below for more details).

  The next configuration accepts calls to VK2KTJ-1 via the radio port.
  It runs the node program for everybody that connects to it.

  The next configuration is a NetRom configuration, note the use of the
  greater-then and less-than braces instead of the square brackets.
  These denote a NetRom configuration. This configuration is simpler, it
  simply says that anyone connecting to our NetRom port called `netrom'
  will have the node program run for them, unless they have a callsign
  of `NOCALL' in which case they will be locked out.

  The last two configurations are for incoming Rose connections. The
  first for people who have placed calls to `vk2ktj-0' and the second
  for `VK2KTJ-1 at the our Rose node address. These work precisely the
  same way. Not the use of the curly braces to distinguish the port as a
  Rose port.

  This example is a contrived one but I think it illustrates clearly the
  important features of the syntax of the configuration file. The
  configuration file is explained fully in the ax25d.conf man page. A
  more detailed example is included in the ax25-utils package that might
  be useful to you too.

  13.3.  Starting ax25d

  When you have the two configuration files completed you start ax25d
  with the command:

       # /usr/sbin/ax25d

  When this is run people should be able to make AX.25 connections to
  your Linux machine. Remember to put the ax25d command in your rc files
  so that it is started automatically when you reboot each time.

  14.  Configuring the node software.

  The node software was developed by Tomi Manninen
  <tomi.manninen@hut.fi> and was based on the original PMS program.  It
  provides a fairly complete and flexible node capability that is easily
  configured. It allows users once they are connected to make Telnet,
  NetRom, Rose, and AX.25 connections out and to obtain various sorts of
  information such as Finger, Nodes and Heard lists etc. You can
  configure the node to execute any Linux command you wish fairly
  simply.

  The node would normally be invoked from the ax25d program although it
  is also capable of being invoked from the TCP/IP inetd program to
  allow users to telnet to your machine and obtain access to it, or by
  running it from the command line.

  14.1.  Creating the /etc/ax25/node.conf file.

  The node.conf file is where the main configuration of the node takes
  place. It is a simple text file and its format is as follows:

  # /etc/ax25/node.conf
  # configuration file for the node(8) program.
  #
  # Lines beginning with '#' are comments and are ignored.

  # Hostname
  # Specifies the hostname of the node machine
  hostname        radio.gw.vk2ktj.ampr.org

  # Local Network
  # allows you to specify what is consider 'local' for the
  # purposes of permission checking using nodes.perms.
  localnet        44.136.8.96/29

  # Hide Ports
  # If specified allows you to make ports invisible to users. The
  # listed ports will not be listed by the (P)orts command.
  hiddenports     rose netrom

  # Node Identification.
  # this will appear in the node prompt
  NodeId          LINUX:VK2KTJ-9

  # NetRom port
  # This is the name of the netrom port that will be used for
  # outgoing NetRom connections from the node.
  NrPort          netrom

  # Node Idle Timeout
  # Specifies the idle time for connections to this node in seconds.
  idletimout      1800

  # Connection Idle Timeout
  # Specifies the idle timer for connections made via this node in
  # seconds.
  conntimeout     1800

  # Reconnect
  # Specifies whether users should be reconnected to the node
  # when their remote connections disconnect, or whether they
  # should be disconnected complete.
  reconnect       on

  # Command Aliases
  # Provide a way of making complex node commands simple.
  alias           CONV    "telnet vk1xwt.ampr.org 3600"
  alias           BBS     "connect radio vk2xsb"

  # Externam Command Aliases
  # Provide a means of executing external commands under the node.
  # extcmd <cmdname> <flag> <userid> <command>
  # Flag == 1 is the only implemented function.
  # <command> is formatted as per ax25d.conf
  extcmd          PMS     1       root    /usr/sbin/pms pms -u %U -o VK2KTJ

  # Logging
  # Set logging to the system log. 3 is the noisiest, 0 is disabled.
  loglevel        3

  # The escape character
  # 20 = (Control-T)
  EscapeChar      20

  14.2.  Creating the /etc/ax25/node.perms file.

  The node allows you to assign permissions to users. These permissions
  allow you to determine which users should be allowed to make use of
  options such as the (T)elnet, and (C)onnect commands, for example, and
  which shouldn't. The node.perms file is where this information is
  stored and contains five key fields. For all fields an asterisk `*'
  character matches anything. This is useful for building default rules.

     user
        The first field is the callsign or user to which the permissions
        should apply.  Any SSID value is ignored, so you should just
        place the base callsign here.

     method
        Each protocol or access method is also given permissions. For
        example you might allow users who have connected via AX.25 or
        NetRom to use the (C)onnect option, but prevent others, such as
        those who are telnet connected from a non-local node from having
        access to it. The second field therefore allows you to select
        which access method this permissions rule should apply to.  The
        access methods allowed are:

          method  description
          ------  -----------------------------------------------------------
          ampr    User is telnet connected from an amprnet address (44.0.0.0)
          ax25    User connected by AX.25
          host    User started node from command line
          inet    user is telnet connected from a non-loca, non-ampr address.
          local   User is telnet connected from a 'local' host
          netrom  User connected by NetRom
          rose    User connected by Rose
          *       User connected by any means.

     port
        For AX.25 users you can control permissions on a port by port
        basis too if you choose. This allows you to determine what AX.25
        are allowed to do based on which of your ports they have
        connected to. The third field contains the port name if you are
        using this facility. This is useful only for AX.25 connections.

     password
        You may optionally configure the node so that it prompts users
        to enter a password when they connect. This might be useful to
        help protect specially configured users who have high authority
        levels. If the fourth field is set then its value will be the
        password that will be accepted.

     permissions
        The permissions field is the final field in each entry in the
        file.  The permissions field is coded as a bit field, with each
        facility having a bit value which if set allows the option to be
        used and if not set prevents the facility being used. The list
        of controllable facilities and their corresponding bit values
        are:

     value   description
     -----   -------------------------------------------------
      1      Login allowed.
      2      AX25 (C)onnects allowed.
      4      NetRom (C)onnects allowed.
      8      (T)elnet to local hosts allowed.
      16     (T)elnet to amprnet (44.0.0.0) hosts allowed.
      32     (T)elnet to non-local, non-amprnet hosts allowed.
      64     Hidden ports allowed for AX.25 (C)onnects.
      128    Rose (C)onnects allowed.

     To code the permissions value for a rule, simply take each of the
     permissions you want that user to have and add their values
     together. The resulting number is what you place in field five.

  A sample nodes.perms might look like:

       # /etc/ax25/node.perms
       #
       # The node operator is VK2KTJ, has a password of 'secret' and
       # is allowed all permissions by all connection methods
       vk2ktj  *       *       secret  255

       # The following users are banned from connecting
       NOCALL  *       *       *       0
       PK232   *       *       *       0
       PMS     *       *       *       0

       # INET users are banned from connecting.
       *       inet    *       *       0

       # AX.25, NetRom, Local, Host and AMPR users may (C)onnect and (T)elnet
       # to local and ampr hosts but not to other IP addresses.
       *       ax25    *       *       159
       *       netrom  *       *       159
       *       local   *       *       159
       *       host    *       *       159
       *       ampr    *       *       159

  14.3.  Configuring node to run from ax25d

  The node program would normally be run by the ax25d program.  To do
  this you need to add appropriate rules to the /etc/ax25/ax25d.conf
  file. In my configuration I wanted users to have a choice of either
  connecting to the node or connecting to other services. ax25d allows
  you to do this by cleverly creating creating port aliases. For
  example, given the ax25d configuration presented above, I want to
  configure node so that all users who connect to VK2KTJ-1 are given the
  node. To do this I add the following to my /etc/ax25/ax25d.conf file:

       [vk2ktj-1 via radio]
       default    *     *    *   *   *   0    root /usr/sbin/node node

  This says that the Linux kernel code will answer any connection
  requests for the callsign `VK2KTJ-1' heard on the AX.25 port named
  `radio', and will cause the node program to be run.

  14.4.  Configuring node to run from inetd

  If you want users to be able to telnet a port on your machine and
  obtain access to the node you can go this fairly easily. The first
  thing to decide is what port users should connect to. In this example
  I've arbitrarily chosen port 4000, though Tomi gives details on how
  you could replace the normal telnet daemon with the node in his
  documentation.

  You need to modify two files.

  To /etc/services you should add:

       node    3694/tcp        #OH2BNS's node software

  and to /etc/inetd.conf you should add:

       node    stream  tcp     nowait  root    /usr/sbin/node node

  When this is done, and you have restarted the inetd program any user
  who telnet connects to port 3694 of your machine will be prompted to
  login and if configured, their password and then they will be con�
  nected to the node.

  15.  Configuring axspawn.

  The axspawn program is a simple program that allows AX.25 stations who
  connect to be logged in to your machine. It may be invoked from the
  ax25d program as described above in a manner similar to the node
  program. To allow a user to log in to your machine you should add a
  line similar to the following into your /etc/ax25/ax25d.conf file:

       default * * * * * 1 root /usr/sbin/axspawn axspawn %u

  If the line ends in the + character then the connecting user must hit
  return before they will be allowed to login. The default is to not
  wait.  Any individual host configurations that follow this line will
  have the axspawn program run when they connect. When axspawn is run it
  first checks that the command line argument it is supplied is a legal
  callsign, strips the SSID, then it checks that /etc/passwd file to see
  if that user has an account configured. If there is an account, and
  the password is either "" (null) or + then the user is logged in, if
  there is anything in the password field the user is prompted to enter
  a password. If there is not an existing account in the /etc/passwd
  file then axspawn may be configured to automatically create one.

  15.1.  Creating the /etc/ax25/axspawn.conf file.

  You can alter the behaviour of axspawn in various ways by use of the
  /etc/ax25/axspawn.conf file. This file is formatted as follows:

       # /etc/ax25/axspawn.conf
       #
       # allow automatic creation of user accounts
       create    yes
       #
       # guest user if above is 'no' or everything else fails. Disable with "no"
       guest     no
       #
       # group id or name for autoaccount
       group     ax25
       #
       # first user id to use
       first_uid 2001
       #
       # maximum user id
       max_uid   3000
       #
       # where to add the home directory for the new users
       home      /home/ax25
       #
       # user shell
       shell     /bin/bash
       #
       # bind user id to callsign for outgoing connects.
       associate yes

  The eight configurable characteristics of axspawn are as follows:

     #  indicates a comment.

     create
        if this field is set to yes then axspawn will attempt to
        automatically create a user account for any user who connects
        and does not already have an entry in the /etc/passwd file.

     guest
        this field names the login name of the account that will be used
        for people who connect who do not already have accounts if
        create is set to no. This is usually ax25 or guest.

     group
        this field names the group name that will be used for any users
        who connect and do not already have an entry in the /etc/passwd
        file.

     first_uid
        this is the number of the first userid that will be
        automatically created for new users.

     max_uid
        this is the maximum number that will be used for the userid of
        new users.

     home
        this is the home (login) directory of new users.

     shell
        this is the login shell of any new users.

     associate
        this flag indicates whether outgoing AX.25 connections made by
        this user after they login will use their own callsign, or your
        stations callsign.

  16.  Configuring the pms

  The pms program is an implementation of a simple personal message
  system. It was originally written by Alan Cox. Dave Brown, N2RJT,
  <dcb@vectorbd.com> has taken on further development of it.  At present
  it is still very simple, supporting only the ability to send mail to
  the owner of the system and to obtain some limited system information
  but Dave is working to expand its capability to make it more useful.

  After that is done there are a couple of simple files that you should
  create that give users some information about the system and then you
  need to add appropriate entries into the ax25d.conf file so that
  connected users are presented with the PMS.

  16.1.  Create the /etc/ax25/pms.motd file.

  The /etc/ax25/pms.motd file contains the `message of the day' that
  users will be presented with after they connect and receive the usual
  BBS id header. The file is a simple text file, any text you include in
  this file will be sent to users.

  16.2.  Create the /etc/ax25/pms.info file.

  The /etc/ax25/pms.info file is also a simple text file in which you
  would put more detailed information about your station or
  configuration.  This file is presented to users in response to their
  issuing of the Info command from the PMS> prompt.

  16.3.  Associate AX.25 callsigns with system users.

  When a connected user sends mail to an AX.25 callsign, the pms expects
  that callsign to be mapped, or associated with a real system user on
  your machine. This is described in a section of its own.

  16.4.  Add the PMS to the /etc/ax25/ax25d.conf file.

  Adding the pms to your ax25d.conf file is very simple.  There is one
  small thing you need to think about though. Dave has added command
  line arguments to the PMS to allow it to handle a number of different
  text end-of-line conventions. AX.25 and NetRom by convention expect
  the end-of-line to be carriage return, linefeed while the standard
  unix end-of-line is just newline. So, for example, if you wanted to
  add an entry that meant that the default action for a connection
  received on an AX.25 port is to start the PMS then you would add a
  line that looked something like:

       default  1  10 5 100 5   0    root  /usr/sbin/pms pms -a -o vk2ktj

  This simply runs the pms program, telling it that it is an AX.25
  connection it is connected to and that the PMS owner is vk2ktj.  Check
  the man page for what you should specify for other connection methods.

  16.5.  Test the PMS.

  To test the PMS, you can try the following command from the command
  line:

  # /usr/sbin/pms -u vk2ktj -o vk2ktj

  Substitute your own callsign for mine and this will run the pms,
  telling it that it is to use the unix end-of-line convention, and that
  user logging in is vk2ktj. You can do all the things connected users
  can.

  Additionally you might try getting some other node to connect to you
  to confirm that your ax25d.conf configuration works.

  17.  Configuring the user_call programs.

  The `user_call' programs are really called: ax25_call and netrom_call.
  They are very simple programs designed to be called from ax25d to
  automate network connections to remote hosts. They may of course be
  called from a number of other places such as shell scripts or other
  daemons such as the node program.

  They are like a very simple call program. They don't do any meddling
  with the data at all, so the end of line handling you'll have to worry
  about yourself.

  Let's start with an example of how you might use them. Imagine you
  have a small network at home and that you have one linux machine
  acting as your Linux radio gateway and another machine, lets say a BPQ
  node connected to it via an ethernet connection.

  Normally if you wanted radio users to be able to connect to the BPQ
  node they would either have to digipeat through your linux node, or
  connect to the node program on your linux node and then connect from
  it.  The ax25_call program can simplify this if it is called from the
  ax25d program.

  Imagine the BPQ node has the callsign VK2KTJ-9 and that the linux
  machine has the AX.25/ethernet port named `bpq'. Let us also imagine
  the Linux gateway machine has a radio port called `radio'.

  An entry in the /etc/ax25/ax25d.conf that looked like:

       [VK2KTJ-1 via radio]
       default    * * * *   *   *  *
                       root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9

  would enable users to connect direct to `VK2KTJ-1' which would actu�
  ally be the Linux ax25d daemon and then be automatically switched to
  an AX.25 connection to `VK2KTJ-9' via the `bpq' interface.

  There are all sorts of other possible configurations that you might
  try.  The `netrom_call' and `rose_call' utilities work in similar
  ways. One amateur has used this utility to make connections to a
  remote BBS easier. Normally the users would have to manually enter a
  long connection string to make the call so he created an entry that
  made the BBS appear as though it were on the local network by having
  his ax25d proxy the connection to the remote machine.

  18.  Configuring the Rose Uplink and Downlink commands

  If you are familiar with the ROM based Rose implementation you will be
  familiar with the method by which AX.25 users make calls across a Rose
  network. If a users local Rose node has the callsign VK2KTJ-5 and the
  AX.25 user wants to connect to VK5XXX at remote Rose node 5050882960
  then they would issue the command:

       c vk5xxx v vk2ktj-5 5050 882960

  At the remote node, VK5XXX would see an incoming connection with the
  local AX.25 users callsign and being digipeated via the remote Rose
  nodes callsign.

  The Linux Rose implementation does not support this capability in the
  kernel, but there are two application programs called rsuplnk and
  rsdwnlnk which perform this function.

  18.1.  Configuring a Rose downlink

  To configure your Linux machine to accept a Rose connection and
  establish an AX.25 connection to any destination callsign that is not
  being listened for on your machine you need to add an entry to your
  /etc/ax25/ax25d.conf file. Normally you would configure this entry to
  be the default behaviour for incoming Rose connections. For example
  you might have Rose listeners operating for destinations like NODE-0
  or HEARD-0 that you wish to handle locally, but for all other
  destination calls you may want to pass them to the rsdwnlink command
  and assume they are AX.25 users.

  A typical configuration would look like:

       #
       {* via rose}
       NOCALL   * * * * * *  L
       default  * * * * * *  - root  /usr/sbin/rsdwnlnk rsdwnlnk 4800 vk2ktj-5
       #

  With this configuration any user who established a Rose connection to
  your Linux nodes address with a destination call of something that you
  were not specifically listening for would be converted into an AX.25
  connection on the AX.25 port named 4800 with a digipeater path of
  VK2KTJ-5.

  18.2.  Configuring a Rose uplink

  To configure your Linux machine to accept AX.25 connections in the
  same way that a ROM Rose node would you must add an entry into your
  /etc/ax25/ax25d.conf file that looks similar to the following:

       #
       [VK2KTJ-5* via 4800]
       NOCALL   * * * * * *  L
       default  * * * * * *  - root  /usr/sbin/rsuplnk rsuplnk rose
       #

  Note the special syntax for the local callsign. The `*' character
  indicates that the application should be invoked if the callsign is
  heard in the digipeater path of a connection.

  This configuration would allow an AX.25 user to establish Rose calls
  using the example connect sequence presented in the introduction.
  Anybody attempting to digipeat via VK2KTJ-5 on the AX.25 port named
  4800 would be handled by the rsuplnk command.

  19.  Associating AX.25 callsigns with Linux users.

  There are a number of situations where it is highly desirable to
  associate a callsign with a linux user account. One example might be
  where a number of amateur radio operators share the same linux machine
  and wish to use their own callsign when making calls. Another is the
  case of PMS users wanting to talk to a particular user on your
  machine.

  The AX.25 software provides a means of managing this association of
  linux user account names with callsigns. We've mentioned it once
  already in the PMS section, but I'm spelling it out here to be sure
  you don't miss it.

  You make the association with the axparms command. An example looks
  like:

       # axparms -assoc vk2ktj terry

  This command associates that AX.25 callsign vk2ktj with the user terry
  on the machine. So, for example, any mail for vk2ktj on the pms will
  be sent to Linux account terry.

  Remember to put these associations into your rc file so that they are
  available each time your reboot.

  Note you should never associate a callsign with the root account as
  this can cause configuration problems in other programs.

  20.  HOWTO link NOS and the Linux kernel networking software

  Many people like to run some version of NOS under Linux because it has
  all of the features and facilities they are used to. Most of those
  people would also like to have the NOS running on their machine
  capable of talking to the Linux kernel so that they can offer some of
  the linux capabilities to radio users.

  20.1.  Linking NOS and Linux using a pipe device

  Brandon S. Allbery, KF8NH, contributed the following information to
  explain how to interconnect the NOS running on a Linux machine with
  the kernel code using the Linux pipe device.

  Since both Linux and NOS support the slip protocol it is possible to
  link the two together by creating a slip link. You could do this by
  using two serial ports with a loopback cable between them, but this
  would be slow and costly. Linux provides a feature that many other
  Unix-like operating systems provide called `pipes'. These are special
  pseudo devices that look like a standard tty device to software but in
  fact loopback to another pipe device. To use these pipes the first
  program must open the master end of the pipe, and the open then the
  second program can open the slave end of the pipe. When both ends are
  open the programs can communicate with each other simply by writing
  characters to the pipes in the way they would if they were terminal
  devices.

  To use this feature to connect the Linux Kernel and a copy of NOS, or
  some other program you first must choose a pipe device to use. You can
  find one by looking in your /dev directory. The master end of the
  pipes are named: ptyp[1-f] and the slave end of the pipes are known
  as: ttyp[1-f]. Remember they come in pairs, so if you select
  /dev/ptypf as your master end then you must use /dev/ttypf as the
  slave end.

  Once you have chosen a pipe device pair to use you should allocate the
  master end to you linux kernel and the slave end to the NOS program,
  as the Linux kernel starts first and the master end of the pipe must
  be opened first.  You must also remember that your Linux kernel must
  have a different IP address to your NOS, so you will need to allocate
  a unique address for it if you haven't already.

  You configure the pipe just as if it were a serial device, so to
  create the slip link from your linux kernel you can use commands
  similar to the following:

       # /sbin/slattach -s 38400 -p slip /dev/ptypf &
       # /sbin/ifconfig sl0 broadcast 44.255.255.255 pointopoint 44.70.248.67 /
               mtu 1536 44.70.4.88
       # /sbin/route add 44.70.248.67 sl0
       # /sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.70.248.67

  In this example the Linux kernel has been given IP address 44.70.4.88
  and the NOS program is using IP address 44.70.248.67. The route
  command in the last line simply tells your linux kernel to route all
  datagrams for the amprnet via the slip link created by the slattach
  command. Normally you would put these commands into your
  /etc/rc.d/rc.inet2 file after all your other network configuration is
  complete so that the slip link is created automatically when you
  reboot.  Note: there is no advantage in using cslip instead of slip as
  it actually reduces performance because the link is only a virtual one
  and occurs fast enough that having to compress the headers first takes
  longer than transmitting the uncompressed datagram.

  To configure the NOS end of the link you could try the following:

  # you can call the interface anything you want; I use "linux" for convenience.
  attach asy ttypf - slip linux 1024 1024 38400
  route addprivate 44.70.4.88 linux

  These commands will create a slip port named `linux' via the slave end
  of the pipe device pair to your linux kernel, and a route to it to
  make it work. When you have started NOS you should be able to ping and
  telnet to your NOS from your Linux machine and vice versa. If not,
  double check that you have made no mistakes especially that you have
  the addresses configured properly and have the pipe devices around the
  right way.

  21.  The /proc/ file system entries.

  The /proc filesystem contains a number of files specifically related
  to the AX25 and NetRom kernel software. These files are normally used
  by the AX52 utilities, but they are plainly formatted so you may be
  interested in reading them. The format is fairly easily understood so
  I don't think much explanation will be necessary.

     /proc/net/arp
        contains the list of Address Resolution Protocol mappings of IP
        addresses to MAC layer protocol addresses. These can can AX.25,
        ethernet or some other MAC layer protocol.

     /proc/net/ax25
        contains a list of AX.25 sockets opened. These might be
        listening for a connection, or active sessions.

     /proc/net/ax25_bpqether
        contains the AX25 over ethernet BPQ style callsign mappings.

     /proc/net/ax25_calls
        contains the linux userid to callsign mappings set my the
        axparms -assoc command.

     /proc/net/ax25_route
        contains AX.25 digipeater path information.

     /proc/net/nr
        contains a list of NetRom sockets opened. These might be
        listening for a connection, or active sessions.

     /proc/net/nr_neigh
        contains information about the NetRom neighbours known to the
        NetRom software.

     /proc/net/nr_nodes
        contains information about the NetRom nodes known to the NetRom
        software.

     /proc/net/rose
        contains a list of Rose sockets opened. These might be listening
        for a connection, or active sessions.

     /proc/net/rose_nodes
        contains a mapping of Rose destinations to Rose neighbours.

     /proc/net/rose_neigh
        contains a list of known Rose neighbours.

     /proc/net/rose_routes
        contains a list of all established Rose connections.

  22.  Some sample configurations.

  Following are examples of the most common types of configurations.
  These are guides only as there are as many ways of configuring your
  network as there are networks to configure, but they may give you a
  start.

  22.1.  Small Ethernet LAN with Linux as a router to Radio LAN

  Many of you may have small local area networks at home and want to
  connect the machines on that network to your local radio LAN. This is
  the type of configuration I use at home. I arranged to have a suitable
  block of addresses allocated to me that I could capture in a single
  route for convenience and I use these on my Ethernet LAN. Your local
  IP coordinator will assist you in doing this if you want to try it as
  well. The addresses for the Ethernet LAN form a subset of the radio
  LAN addresses. The following configuration is the actual one for my
  linux router on my network at home:

                                                 .      .   .    .    . .
         ---                                .
          | Network       /---------\     .    Network
          | 44.136.8.96/29|         |    .     44.136.8/24        \ | /
          |               | Linux   |   .                          \|/
          |               |         |  .                            |
          |          eth0 | Router  |  .  /-----\    /----------\   |
          |---------------|         |-----| TNC |----| Radio    |---/
          |   44.136.8.97 |  and    |  .  \-----/    \----------/
          |               |         | sl0
          |               | Server  | 44.136.8.5
          |               |         |    .
          |               |         |     .
          |               \_________/       .
         ---                                     .      .   .    .    . .

  #!/bin/sh
  # /etc/rc.net
  # This configuration provides one KISS based AX.25 port and one
  # Ethernet device.

  echo "/etc/rc.net"
  echo "  Configuring:"

  echo -n "    loopback:"
  /sbin/ifconfig lo 127.0.0.1
  /sbin/route add 127.0.0.1
  echo " done."

  echo -n "    ethernet:"
  /sbin/ifconfig eth0 44.136.8.97 netmask 255.255.255.248 \
                  broadcast 44.136.8.103 up
  /sbin/route add 44.136.8.97 eth0
  /sbin/route add -net 44.136.8.96 netmask 255.255.255.248 eth0
  echo " done."

  echo -n "    AX.25: "
  kissattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800
  ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255
  route add -host 44.136.8.5 sl0
  route add -net 44.136.8.0 window 1024 sl0

  echo -n "    Netrom: "
  nrattach -i 44.136.8.5 netrom

  echo "  Routing:"
  /sbin/route add default gw 44.136.8.68 window 1024 sl0
  echo "    default route."
  echo done.

  # end

  /etc/ax25/axports

       # name  callsign        speed   paclen  window  description
       4800    VK2KTJ-0        4800    256     2       144.800 MHz

  /etc/ax25/nrports

       # name  callsign        alias   paclen  description
       netrom  VK2KTJ-9        LINUX   235     Linux Switch Port

  /etc/ax25/nrbroadcast

       # ax25_name     min_obs def_qual        worst_qual      verbose
       4800            1       120             10              1

  �  You must have IP_FORWARDING enabled in your kernel.

  �  The AX.25 configuration files are pretty much those used as
     examples in the earlier sections, refer to those where necessary.

  �  I've chosen to use an IP address for my radio port that is not
     within my home network block. I needn't have done so, I could have
     easily used 44.136.8.97 for that port too.

  �  44.136.8.68 is my local IPIP encapsulated gateway and hence is
     where I point my default route.

  �  Each of the machines on my Ethernet network have a route:

       route add -net 44.0.0.0 netmask 255.0.0.0 \
               gw 44.136.8.97 window 512 mss 512 eth0

  The use of the mss and window parameters means that I can get optimum
  performance from both local Ethernet and radio based connections.

  �  I also run my smail, http, ftp and other daemons on the router
     machine so that it needs to be the only machine to provide others
     with facilities.

- --- END Linux AX25 HOWTO part 2/3 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gregh@cc.gatech.edu for public key

iQCVAwUBM+fqNXtNTo2suu5NAQFdPQP/UmL+stwwUFR0GwuexAKmrZAmQXDqh3Kx
t5ubwBi7hsVMHdVoeDooKWX6wucFPeuZPOkScHJW8ZGHreiFpYyD1+E1zbXm2n44
QawMWQRyxjLuwsSD05//pnPNECyoFTQlIvrDYEy8tvg7YISef06qGTLn8G2XeJOa
6ZtDmk8McEc=
=+X2F
-----END PGP SIGNATURE-----