Provided by: ax25-apps_0.0.6-16.2_amd64 bug

NAME

       ax25rtd.conf - ax25 routing daemon configuration file

SYNOPSIS

       /etc/ax25/ax25rtd.conf

DESCRIPTION

       The  file /etc/ax25/ax25rtd.conf is the configuration file for ax25rtd.  The parameters of
       the options shown here are the default values except the ones marked with (example)

       ax25-maxroutes 256

       ip-maxroutes   256
              The maximum size of the three lists / caches. On overflow, ax25rtd will  substitute
              the oldest entry with the new one.

       [1k2]
              This  marks  the  beginning of per-port definitions. Note that you have to use port
              names as defined in axports(5) here, anywhere else you may  use  the  port  or  the
              device name.

       ax25-learn-routes no
              Set  this  to "yes", ax25rtd will add the routing information for every heard frame
              (with complete digipeater path) to  the  kernel  AX.25  routing  table.  Note  that
              ax25rtd's internal cache will be updated anyway, regardless of this option.

       ax25-learn-only-mine no
              If  you  set  it to "yes", only frames that are sent to (1) the interface callsign,
              (2) any of the listeners  on  this  device,  or  (3)  the  callsigns  specified  by
              ax25-more-mycalls  will  be  used  to  update  the internal cache and (depending on
              ax25-learn-routes) the kernel routing table.

       ax25-add-path db0ach     (example)
              This is useful on DAMA digipeaters. In this case, the DAMA master has  to  be  used
              for  _every_  AX.25  connection,  thus ax25rtd will add this digipeater(s) to every
              target we learn that has no digipeater path (yet).  "db0ach"  is  just  an  example
              here.

       ax25-more-mycalls dl1bke dl1bke-8  (example)
              You  can specify more calls as calls here that belong to this interface... "dl1bke"
              and "dl1bke-8" are examples.

       ip-learn-routes no
              If set to "yes", ax25rtd will modify the IP routing table  if  it  receives  an  IP
              frame (directed to us). This is dangerous!

              It  should  not screw up your routing table, though. Ax25rtd recognizes the netmask
              of the device and will adjust the route only if it fits the  netmask  and  the  old
              route points to one of the devices ax25rtd knows about (hence an AX.25 device).

              The  problems  begin if you have more than one port and a user is able to hear your
              outgoing traffic on at least two of them.  Due to technical reasons ax25rtd adjusts
              the  route _after_ the kernel has sent the reply to the received TCP frame already.
              This has technical reasons.

              If the remote does the same both are switching between the two ports.

              Don't use this feature unless you know what you are doing.

              It _should_ be safe do enable  this  on  one-port  machines,  although  I  strongly
              recommend to set a network route instead, i.e.:

                      route add -net 44.0.0.0 scc3

              Note  that  ax25rtd's  internal  cache  will  be updated anyway, regardless of this
              option.

       irtt <irtt>
              If ip-learn-routes is enabled this will assign newly added routes an initial  round
              trip time (IRTT) for TCP. <irtt> is measured in msec, hence

                      irtt 10000

              sets the irtt to 10 seconds. A value of 0 disables this feature (default).

       ip-adjust-mode no
              If  you  set  this  option  to  "yes" ax25rtd will change the IP encapsulation mode
              according to the last received IP frame.

              The problem with this option is that the kernel AX.25 sends a received IP frame  to
              the  IP  layer  regardless  if it was sent in UI frame encapsulation "mode datagram
              (dg)" or in I frame encaps, hence in an AX.25  connection,  "mode  virtual  connect
              (vc)".  The  Linux  kernel will respond to this frame before ax25rtd can adjust the
              mode. If the remote does the same... You get the picture.

              Don't use this feature unless you know what you are doing.

       arp-add   no
              This option, if set to "yes", changes the ARP table to the source callsign  of  the
              received  frame. It should be harmless, just has the the effect that if it is a new
              entry, the Linux ARP code will send one ARP request before ax25rtd has  adjust  the
              ARP  table.  If  there  was already an existing ARP entry for this IP route, one IP
              datagram will be sent to the old address. Not really a problem, I hope.

SEE ALSO

       ax25rtd(8), ax25rtctl(8).

AUTHORS

       Jörg Reuter <jreuter@poboxes.com>
       Llaus Kudielka OE1KIB