Provided by: diald_0.99.4-5_i386 bug

NAME

       diald-examples - examples of how to configure diald

SYNOPSIS

       /etc/diald/diald.options

DESCRIPTION

       This manual page walks through several example configurations of diald.
       Diald is configured by writing a configuration file. Diald always reads
       the configuration file /etc/diald/diald.options on startup, and further
       configuration files can be specified  on  the  command  line.   In  the
       examples considered here, we assume that the configuration is done only
       through the file /etc/diald/diald.options.

       Configuring diald consists of three major tasks:

       1)     Constructing a "connect script", which is a small  program  that
              dials your phone for you and starts up PPP or SLIP on the remote
              side of the link,

       2)     Basic configuration of diald to  use  the  correct  devices  and
              modes, and

       3)     Configuring  the  rules  that  diald  uses to decide if the link
              should be up.

       The remainder of this  manual  divides  discussion  into  three  parts,
       corresponding  to these three tasks. First, the construction of connect
       scripts is briefly discussed. Second, some example  configurations  are
       given  using  the  default  filter  rules.  Lastly, the construction of
       alternate filter rules is discussed.

CONNECT SCRIPTS

       Once diald decides that it wants to bring up the link, it must dial the
       phone  and  log  into  the  remote  system. Diald relies on the user to
       provide a program, called the connect script,  to  do  this.   Clearly,
       writing a connect script is critical. This can be a daunting task for a
       non-programmer.

       If you already have a working pppd connection, then  you  will  already
       have  a  connect  script,  and this can be used for diald as well.  For
       example, suppose that you start pppd with a command something like:

              pppd /dev/ttyS1 ... connect "chat -f /etc/ppp/chatscript" ...

       then you can simply use

              connect "/usr/sbin/chat -f /etc/ppp/chatscript"

       as your connect option for diald. Note that you must specify  the  full
       path  for  the  chat  program,  since diald will run with an empty PATH
       environment.

       If you do not already have a working connect script, then you will have
       to  construct  one.  An example script, called "connect", is located in
       the directory /etc/diald. This script can be customized to  match  your
       needs  by  changing  the  configuration  parameters at the start of the
       script. Most dialing and login sequences can  be  dealt  with  by  this
       script.  The  comments  in the example script explain what the settings
       are for.

       If the connect script in /etc/diald cannot be configured to  meet  your
       needs,  then you will have to write your own script.  If you need to do
       this, then you should read the manual page for chat.  You may also want
       to consider using the expect program to write connect scripts with more
       complex behaviors.  You should also be aware of  the  environment  that
       the  connect  script  runs  in.  In  particular, the standard input and
       output and error streams are all connected to the serial  device  (i.e.
       the  modem).   In addition, the environment variable MODEM will contain
       the name of the device, and if diald is using a control FIFO, then  the
       environment  variable  FIFO  will  contain the name of the command fifo
       used  by  diald.  These  environment  variables  may  be  of  use   for
       particularly complex interactions between diald and the connect script.

BASIC CONFIGURATIONS

       The   configuration   of   diald   is   controlled    by    the    file
       /etc/diald/diald.options.    This   section  covers  several  different
       configuration scenarios, starting with some very simple ones, and  then
       covering  a  few  more  complex  cases.  Throughout this section, it is
       assumed that the connect script  is  /etc/diald/connect.  Each  of  the
       examples  cases  provides  an /etc/diald/diald.options file that can be
       used as an example to construct your own /etc/diald/diald.options file.
       You  should probably read all the examples before you try to write your
       own /etc/diald/diald.options file. In particular, most of the  examples
       are stripped to the bare minimum number of options needed to make diald
       run. There are several options that are  only  discussed  in  the  last
       example that you probably want to use.

   A Leaf Node with a static IP address using PPP.
       The  simplest  connection  case occurs when you have a fixed IP address
       assigned to your local machine, and that machine is not connected to  a
       local  network.  Generally PPP is simpler to setup correctly than SLIP.
       Suppose for this example that your machine is to be connected  by  PPP,
       that  your  machine  has been assigned the IP address 137.130.1.14, and
       that the machine you are connecting to has  the  address  137.130.2.44.
       Also, suppose your modem is on the serial line /dev/ttyS1, and that you
       want to set the modem speed to 115200, since you  have  a  fast  modem.
       Then   the   following   /etc/diald/diald.options  file  is  a  minimal
       configuration for this case:

              mode ppp
              connect /etc/diald/connect
              device /dev/ttyS1
              speed 115200
              modem
              lock
              crtscts
              local 137.130.1.14
              remote 137.130.2.44
              defaultroute
              include /etc/diald/standard.filter

       The mode option tells diald that it should use the PPP  protocol.   The
       connect  option  tells  diald  where  to  find the connect script.  The
       device option tells diald that the modem is on the  /dev/ttyS1  device,
       and the speed option tells diald that it should connect to the modem at
       a speed of 115000 bps.  The modem option tells diald that  there  is  a
       modem  on  the serial line.  Without this option diald will assume that
       it is connected directly to the remote system by a serial cable. Unless
       this  is  really  the  case,  you will want the modem option.  The lock
       option tells diald that it should  perform  locking  to  prevent  other
       programs from using the modem while it is doing so.  The crtscts option
       tells diald that it should use the hardware flow control lines for  the
       serial  device.  This  is almost certainly necessary for any high speed
       serial connections.

       The local option specifies the IP address for your machine.  Similarly,
       the  remote  option  specifies  the  IP  address for the machine at the
       remote end of your  link.   The  defaultroute  option  tells  diald  to
       install a default route in the routing table that goes through the link
       it is controlling. If the link that diald is controlling is  your  link
       to the rest of the Internet, then you will want this option.

       Finally,  the  last  line  tells  diald to load the options in the file
       "/etc/diald/standard.filter".  These options specify a set of rules for
       diald  to  use  to  determine  when  to  bring  the  link  up  or down.
       Modifications to these rules are discussed in the third  part  of  this
       manual page.

   A Leaf Node with Static IP Addresses using SLIP
       Suppose  that you needed to connect using the SLIP protocol rather than
       the PPP protocol?  In this case the line that says "mode ppp" needs  to
       be  changed  to read "mode slip" (if you are using compressed SLIP this
       should read "mode cslip" instead).  Assuming that your  connect  script
       does  the right thing to start SLIP on the remote machine this might be
       enough.  However, it is usually  necessary  to  also  set  the  Maximum
       Transmission  Unit  (MTU)  on  a  SLIP link, since this setting must be
       identical on both ends of a SLIP link, and the default  value  of  1500
       may  be incorrect.  Supposing that your MTU setting should be 576, then
       the  following  modification  of  the  above  example  is   a   minimal
       /etc/diald/diald.options file for this situation:

              mode slip
              connect /etc/diald/connect
              device /dev/ttyS1
              speed 115200
              modem
              lock
              crtscts
              local 137.130.1.14
              remote 137.130.2.44
              mtu 576
              defaultroute
              include /etc/diald/standard.filter

   A Leaf Node with Dynamic Remote Address using PPP
       Assume  now  that when you dial your remote site you might be connected
       to any one of a number  of  terminal  servers,  each  of  which  has  a
       different  remote  address. What should you pick for the remote address
       to tell diald?  Curiously enough, it doesn’t matter. The remote address
       assigned  to  an  interface is really only a local label that the route
       program uses to find the right interface. Once  the  routes  have  been
       established  the number is never used again.  Therefore, faced with the
       above situation you can choose the address of any one of  the  terminal
       servers that you can be connected to as the remote address.

   A Leaf Node with Dynamic Local Address using PPP
       Let us again complicate matters for ourselves. Assume now that not only
       do you not know the remote address you will get connected to, but  that
       the  remote  site  might assign you a different local address each time
       you connect.  In this situation we must use the dynamic  option.   Note
       that  you  must  still supply an initial local address, otherwise diald
       won’t be able to fake the existence of a connection when none  has  yet
       been  made. This initial local address should be picked from one of the
       unroutable subnets that have been set  aside  for  use  as  private  IP
       numbers.  It is usually also convenient to choose a fake number for the
       remote IP address in this case. If you do not have a local  IP  network
       that is using one of these private addresses, then you can just use the
       IP addresses 192.168.0.1 and 192.168.0.2.  If  you  are  already  using
       these  addresses  in  your  local  network,  then  you  should  pick IP
       addresses that you have  not  assigned  to  a  machine  on  your  local
       network.   The following is a minimal /etc/diald/diald.options file for
       this case:

              mode ppp
              connect /etc/diald/connect
              device /dev/ttyS1
              speed 115200
              modem
              lock
              crtscts
              local 192.168.0.1
              remote 192.168.0.2
              dynamic
              defaultroute
              include /etc/diald/standard.filter

   A Leaf Node with Dynamic Local Address using SLIP
       If you are using SLIP  with  dynamic  IP  addresses,  then  things  are
       slightly  more complicated.  This is because the SLIP protocol does not
       specify a way for the two machines to negotiate the addresses  assigned
       to  the  endpoints.  The  standard way to get around this problem is to
       have the remote SLIP server output a string stating the addresses  that
       have  been  assigned  before it actually goes into SLIP mode. The local
       machine can then read these strings from the  modem  before  it  enters
       SLIP mode.  Diald is capable of reading and interpreting these strings,
       but it needs a little help. In particular, diald can’t know in  advance
       which  order the local and remote addresses will be output, or for that
       matter if both will even appear.  The dslip-mode command allows you  to
       specify  what  address should be expected to appear and what order they
       will appear in.  For example, if your remote site prints out the remote
       address  followed  by the local address (possibly with some intervening
       text between the addresses), the you might use  the  following  minimal
       /etc/diald/diald.options file:

              mode slip
              connect /etc/diald/connect
              device /dev/ttyS1
              speed 115200
              modem
              lock
              crtscts
              local 192.168.0.1
              remote 192.168.0.2
              dynamic
              dslip-mode remote-local
              mtu 576
              defaultroute
              include /etc/diald/standard.filter

   A More Complex Example
       We  now  consider  a  more  complex  example.  This example illustrates
       several more advanced options that you might need to be aware of.

       Suppose that you have a small network that has  been  assigned  the  IP
       addresses   in  the  network  137.130.1.0/255.255.255.0  that  must  be
       connected to corporate headquarters via a PPP server that  has  the  IP
       address  137.130.2.44.   Also, suppose that your main connection to the
       Internet is via some other connection, and that you only want to  route
       addresses  on  the  network  137.130.2.0/255.255.255.0 through the link
       maintained by diald.

       Let us further suppose that the server at headquarters depends  on  you
       to  specify  the  address  of your local machine in the PPP negotiation
       phase, since you may need to change it in the event of a breakdown, and
       headquarters  doesn’t  want  to  be  bothered  with reconfiguring their
       server when this happens.  In this case, pppd must be passed an address
       parameter of the form "137.130.1.14:".

       Finally,  suppose  that  there  is  a  pool  of  modems  on the devices
       /dev/ttyS1 through /dev/ttyS5, and that outgoing calls should  use  any
       of these modems that is not busy already.

       The  following  /etc/diald/diald.options file can be used in this case.
       The options that have not been used in previous examples are  discussed
       below.

              # General options
              mode ppp
              accounting-log /var/log/diald.log
              fifo /var/run/diald.fifo
              pppd-options 137.130.1.14:

              # Device configuration
              connect /etc/diald/connect
              device /dev/ttyS1
              device /dev/ttyS2
              device /dev/ttyS3
              device /dev/ttyS4
              device /dev/ttyS5
              rotate-devices
              speed 115200
              modem
              lock
              crtscts

              # Network configuration
              local 137.130.1.14
              remote 137.130.2.44
              netmask 255.255.255.0
              mtu 576
              mru 576
              window 2048
              addroute /etc/diald/addroute
              ip-up /etc/diald/shipmail

              # Timeouts
              redial-backoff-start 4
              redial-backoff-limit 300
              dial-fail-limit 15

              # Get the standard filter policy
              include /etc/diald/standard.filter

       The accounting-log option specifies a file in which diald should record
       a log of the phone calls it makes. If you don’t need this log, then you
       can just omit this option.

       The   fifo   option   tells   diald   to  make  a  control  fifo  named
       /var/run/diald/diald.fifo that can be used to control diald once it  is
       running.  The  programs  dcntl  and  diald-top make use of this control
       fifo, and it is easy to write new programs that also make  use  of  it.
       Note  that  although the fifo need not exist when diald is started, the
       directory that it is located in (/etc/diald in the example) must exist.

       The  pppd-options  option  specifies a list of one or more options that
       should be passed to pppd when diald starts it. In this case the  option
       "137.130.1.14:"  is passed so that pppd can negotiate the correct local
       IP address.

       Note that there is more than one device option. Each specifies  one  of
       the  possible  modem devices.  The rotate-devices option tells diald to
       start with a different device every time it tries to make a call.  This
       ensures  that  if  one  of the modems gets broken diald won’t get stuck
       trying to use the same broken modem every time.

       The netmask option sets the network mask for the local side of the  PPP
       interface.   In  this case we want the mask to be 255.255.255.0.  Often
       the correct netmask can be deduced by diald knowing the IP address, but
       if this is not the case you can specify it with this option.

       Unlike  previous  examples using the PPP mode, this example includes an
       MTU setting. The default setting for the MTU in PPP mode is  1500.   To
       get  better  interactive response you might want to negotiate a smaller
       value. In this example we are trying to get both sides of the  link  to
       set  their MTU to 576.  The mtu option sets the MTU on this side of the
       link.  The mru option forces diald to ask the other side of the link to
       set its MTU to 576.

       The  window  option  is also present for performance tuning reasons. In
       particular, the TCP protocol can normally send quite large  amounts  of
       data  (30-40k) at a time. This much data can take quite a while to pass
       through a modem.  This option tells diald to set the window size in its
       entries  in  the  routing table. This restricts the amount of data that
       TCP  will  send  in  a  single  burst.  This  can  improve  interactive
       performance quite a bit.  See the diald manual page for a discussion of
       appropriate window settings.

       The   addroute   option   asks   diald   to   run   a   script    named
       /etc/diald/addroute  when  it  is  ready  to add entries to the routing
       table. We do this so  that  we  can  add  the  routes  to  the  network
       137.130.2.0/255.255.255.0 as we discussed in the description leading up
       to this example. An appropriate  /etc/diald/addroute  script  for  this
       purpose would be:

              #!/bin/sh
              /sbin/route add -net 137.130.2.0 \
                netmask 255.255.255.0 gw $4 \
                window 2048 metric $5 dev $1

       The  ip-up  option asks diald to run a script named /etc/diald/shipmail
       whenever the IP layer is brought up. In this case we might suppose that
       this  script  sends  out  any  mail  that  is  destine for addresses at
       headquarters.  You can use an ip-up script to do  any  processing  that
       you need to do every time the link comes up.

       The  redial-backoff-start,  rediald-backoff-limit,  and dial-fail-limit
       options all help limit how often diald will attempt to make consecutive
       failing  calls.  The  rediald-backoff-start option tells diald to start
       doubling  the  time  between  successive  calls  after  4   consecutive
       failures.   The  rediald-backoff-limit  option  tells diald not to wait
       more than 300 seconds after a failed  call.   Finally,  the  dial-fail-
       limit  option  tells  diald not to make more than 15 consecutive failed
       calls.  If diald should make 15 consecutive calls that failed, then  it
       would  stop  attempting  to  dial  out,  issue  a  report  of the error
       condition to the system logs, and wait for an operator to issue  it  an
       instruction  to  restart  dialing.  The manual page for diald describes
       these options in more detail.

FILTER RULES

       Diald maintains a virtual link to the remote site at  all  times.  This
       link is in one of two modes.  Either the corresponding physical link is
       expected to be up, or it is expected to be  down.   When  the  physical
       link  is  expected to be up diald will attempt to maintain the physical
       link, dialing and re-dialing if necessary.  It will  also  monitor  any
       packets passing over the virtual link to determine if the physical link
       should be brought down.  When the physical link is expected to be  down
       diald  will  monitor  packets  that  are  sent  to  the virtual link to
       determine if the physical link  should  be  brought  up.   The  general
       approach  used  by  diald to determine when to change between these two
       modes is to keep a connection set of connection identities,  each  with
       an  associated  timeout.   When  a timeout associated with a connection
       identity expires, it is removed from the set.  When the connection  set
       is  empty  diald  expects the physical link to be down, otherwise diald
       expects the physical link to be up.  This  section  discusses  how  the
       rules that diald follows to construct the connection set are written.

   Filter Rule Basics
       Accept,  bringup,  keepup  and ignore rules control the addition of new
       connection identities to the connection set. Each  accept,  bringup  or
       keepup  rule  specifies a set of conditions that a packet must match, a
       method to generate a connection identity from a packet, and a  timeout.
       Ignore rules specify only a set of conditions that a packet must match.
       When a packet  arrives  that  matches  a  given  accept  rule,  then  a
       connection  identity,  say <id>, is generated from the packet, and <id>
       is added to the connection set with the timeout specified by the filter
       rule. If <id> was already in the set, then the new timeout will replace
       the old timeout.  Note that the new timeout may be less  than  the  old
       timeout.

       Each  accept, bringup, keepup or ignore statement must specify the name
       of a protocol rule.  Protocol rules specify  how  to  build  connection
       identifiers.   The  distributed /etc/diald/diald.defs file contains the
       following four definitions:

       prule tcp tcp 9:12:13:14:15:16:17:18:19:+0:+1:+2:+3:9:9:9
       prule udp udp 9:12:13:14:15:16:17:18:19:+0:+1:+2:+3:9:9:9
       prule icmp icmp 9:12:13:14:15:16:17:18:19:9:9:9:9:9:9:9
       prule any any 9:12:13:14:15:16:17:18:19:9:9:9:9:9:9:9

       The tcp and udp rules respectively match tcp and udp packets, and build
       connection  identifiers  consisting  of the packet protocol, the source
       and destination IP addresses,  and  the  source  and  destination  port
       numbers.   The icmp and any rules construct identifiers consisting only
       of the packet protocol and source and destination IP addresses.  It  is
       important  to  note  that  diald  does not build connection identifiers
       directly from the matched  packet.  Before  generating  the  connection
       identifier diald may swap the source and destination addresses, so that
       the numerically smaller address is always in the  source  field  before
       generating  the  connection  identifier.  This is done so that the same
       connection identifier is generated  regardless  of  the  direction  the
       packet is going across the interface.

       As  well, each accept, bringup, keepup or ignore statement must specify
       some set  of  conditions  on  the  contents  of  the  packet.  Variable
       definitions  allow  access  to the contents of the packet in accept and
       reject statements.  The distributed /etc/diald/diald.defs file  defines
       variables  for  all  the fields in the ip packet header and for all the
       fields in the tcp, udp and icmp packet headers.  The names match  those
       used in the include files found in /usr/include/linux.

       The IP packet header variables are:
           ip.ihl               header length
           ip.version           format version
           ip.tos               type of service
           ip.tot_len           length of ip packet in words
           ip.id                packet id
           ip.frag_off          fragment offset
           ip.ttl               time to live
           ip.protocol          ip protocol
           ip.check             ip header checksum
           ip.saddr             ip source address
           ip.daddr             ip destination address

       The TCP packet header variables are:
           tcp.source           tcp source port
           tcp.dest             tcp destination port
           tcp.seq              tcp sequence number
           tcp.ack_seq          tcp ack sequence number
           tcp.doff             tcp data offset in words
           tcp.fin              tcp finish flag
           tcp.syn              tcp synchronize flag
           tcp.rst              tcp reset flag
           tcp.psh              tcp push flag
           tcp.ack              tcp acknowledge flag
           tcp.urg              tcp urgent flag
           tcp.live             tcp connection state

       The  final  variable (tcp.live) is a pseudo variable provided by diald.
       It is true if and only if the TCP connection has not been shut down.

       The UDP packet header variables are:
           udp.source           udp source port
           udp.dest             udp destination port
           udp.len              udp header length
           udp.check            udp packet checksum

       The ICMP packet header variables are:
           icmp.type            icmp packet type
           icmp.code            icmp packet code
           icmp.checksum        icmp packet checksum
           icmp.echo.id         icmp echo id
           icmp.echo.sequence   icmp echo sequence
           icmp.gateway         icmp gateway

   Simple Examples
       It may help to consider some examples.  The rule

              accept tcp 10 any

       says to match any  tcp  packet  and  assign  the  generated  connection
       identity  a  timeout  of  10  seconds.   The  method used to generate a
       connection identity is specific to tcp packets. The identity of  a  tcp
       packet consists of the protocol, the source and destination ip address,
       and the source and destination port associated with the tcp packet.

       Similarly, the rule

              accept any 10 any

       says to match any packet and assign the generated connection identity a
       timeout of 10 seconds.

       The more complex rule

              accept tcp 60 tcp.dest=tcp.www,ip.daddr&255.255.0.0=149.100.0.0

       matches  any  tcp  packet  with a destination matching the tcp www port
       number specified in /etc/services, and an ip destination address on the
       149.100.0.0 subnet.

   The Standard Filter Rules
       We  now  describe the construction of much of the rule set found in the
       file "/etc/diald/standard.filter". Rather than listing the contents  of
       this  file  in  one piece, we will discuss small groups of rules in the
       order they appear in the file.  Be warned that some  knowledge  of  the
       internal  workings  of  the  Internet  protocols  may  be  required  to
       completely understand some of these examples. Also be warned  that  the
       description  here  is  intended  to help understand how to write filter
       rules.  Some rules that occur in the actual file at the  time  of  this
       writing  have  been left out, and the distributed file may have evolved
       since this was written. This should not affect the  usefulness  of  the
       discussion.

       Note that the order in which filter rules occur is critical.  Each time
       a packet arrives diald will apply the first filter  rule  that  matches
       the packet.

       The  rules in the standard filter file are divided into three sections:
       TCP rules, UDP rules, and a general catch all set of rules.

       TCP Rules

       Before proceeding to describe the rules, it will  be  helpful  to  make
       some general remarks about the reasoning behind these rules.

       In  general,  we  would  like  to  treat  only  data  on  a TCP link as
       significant for timeouts. Therefore, we try to ignore packets  with  no
       data.  Since the shortest possible set of headers in a TCP/IP packet is
       40 bytes.  Any packet with length 40 must have no data  riding  in  it.
       We  may  miss some empty packets this way (optional routing information
       and other extras may be present in the IP header), but  we  should  get
       most  of  them.  Note  that  we  don’t  want to filter out packets with
       tcp.live clear, since we use them later to speedup disconnects on  some
       TCP links.

       We  also  want  to make sure WWW packets live even if the TCP socket is
       shut down. We do this because WWW doesn’t keep  connections  open  once
       the data has been transfered, and it would be annoying to have the link
       keep bouncing up and down every time you get a document.

       Outside  of  WWW  the  most  common  use  of  TCP  is  for  long  lived
       connections, that once they are gone mean we no longer need the network
       connection.  We don’t necessarily want  to  wait  10  minutes  for  the
       connection  to  go  down  when  we  don’t have any telnet’s or rlogin’s
       running, so we want to speed up the timeout  on  TCP  connections  that
       have shutdown. We do this by catching packets that do not have the live
       flag set.

       The first rule is designed to give the link 15 seconds up time when  we
       are  initiating  a  TCP  connection.   The  idea  here  is to deal with
       possibility that the network on the opposite end of the  connection  is
       unreachable.  In  this  case  you don’t really want to give the link 10
       minutes up time. With the rule below we only give the link  15  seconds
       initially.  If  the  network  is  reachable then we will normally get a
       response that actually contains some data within 15  seconds.  If  this
       causes  problems because you have a slow response time at some site you
       want to regularly access, you can either increase the timeout or remove
       this rule.

              accept tcp 15 tcp.syn

       If  you  are  running  named,  then  it  will send data across the link
       periodically to synchronize against other domain name  servers.   Since
       this  can happen at any time, it is undesirable to keep the link up for
       it. Therefore, we ignore any traffic from or to a domain name server.

              ignore tcp tcp.dest=tcp.domain
              ignore tcp tcp.source=tcp.domain

       Normally the packet that starts a connection is longer that  40  bytes,
       since  it  normally  contains TCP options to specify the MSS.  However,
       some TCP implementations don’t include these  options.   Therefore,  we
       must  be careful not to ignore SYN packets that are only 40 bytes long.

              accept tcp 5 ip.tot_len=40,tcp.syn

       Otherwise, we want to ignore any TCP packet that is only 40 bytes long,
       since  it is not carrying any data. However, we don’t want to ignore 40
       byte packets that mark the closing of a connection, since we use  those
       to  cut  short the timeout on connections that have died.  Therefore we
       must test the tcp.live flag here. If it is not set we might want to see
       this packet later on in the rules.

              ignore tcp ip.tot_len=40,tcp.live

       Make  sure  http transfers hold the link for 2 minutes, even after they
       end.  This prevents web browsers from bouncing the connection too much.
       You may find the 2 minutes is a bit short for your taste.

              accept tcp 120 tcp.dest=tcp.www
              accept tcp 120 tcp.source=tcp.www

       Once  the  link  is  no longer live, we try to shut down the connection
       quickly. Note that if the link is already down, the closing  of  the  a
       connection (which will generate traffic) will not bring it back up.

              keepup tcp 5 !tcp.live
              ignore tcp !tcp.live

       An  ftp-data  or  ftp  connection  can  be  expected to show reasonably
       frequent traffic, so we can use  a  short  timeout  for  this  kind  of
       traffic.

              accept tcp 120 tcp.dest=tcp.ftp
              accept tcp 120 tcp.source=tcp.ftp

       Finally, if we don’t match the TCP packet somewhere above, then we give
       the link 10 minutes up time. Most TCP packets match this rule.

              accept tcp 600 any

       UDP Rules

       Not many programs communicate via UDP packets, and many of  those  that
       do  are  programs  that  we  don’t want to hold the link up, since they
       broadcast UDP packets every few minutes. However, the  normal  sequence
       of  events  when the link is down is for the user to initiate a network
       program that needs to perform a domain name query before it can make  a
       TCP  connection.  Therefore, we want to bring up the link when we see a
       domain name packet cross the link.   We  explicitly  ignore  may  other
       kinds of UDP packets.

       Don’t bring the link up for rwho.

              ignore udp udp.dest=udp.who
              ignore udp udp.source=udp.who

       Don’t bring the link up for routing packets.

              ignore udp udp.dest=udp.route
              ignore udp udp.source=udp.route

       Don’t bring the link up for NTP or timed.

              ignore udp udp.dest=udp.ntp
              ignore udp udp.source=udp.ntp
              ignore udp udp.dest=udp.timed
              ignore udp udp.source=udp.timed

       Don’t  bring  up  on domain name requests between two running copies of
       named.

              ignore udp udp.dest=udp.domain,udp.source=udp.domain

       Bring up the network whenever we make a domain request  from  someplace
       other  than  named.  We time out domain requests quite quickly. We just
       want them to bring the link up, not keep it around for very long.  This
       is because the network will usually come up on a call from the resolver
       library, but once it is  up  we  will  get  a  response  and  make  TCP
       connection.  If that fails we don’t want the link to stay up because of
       the prior domain name query.  Note that you should not make the timeout
       shorter  than  the  time  you  might  expect your DNS server to take to
       respond. Otherwise when the initial link gets established  there  might
       be  a  delay  greater  than this between the time the initial series of
       packets goes across the link and the time  that  any  response  packets
       cross the link, in which case you will loose the link.

              accept udp 30 udp.dest=udp.domain
              accept udp 30 udp.source=udp.domain

       We treat netbios-ns broadcasts the same as domain name queries.

              ignore udp udp.source=udp.netbios-ns,udp.dest=udp.netbios-ns
              accept udp 30 udp.dest=udp.netbios-ns
              accept udp 30 udp.source=udp.netbios-ns

       Any  other  UDP  packets  keep  the  link up for 2 minutes.  If you are
       having trouble because various UDP protocols are keeping your  link  up
       when you don’t want them to, you might try changing this rule to ignore
       any UDP packets that were not caught above. Of course  this  may  break
       something else.

              accept udp 120 any

       Catch All Rules

       Catch any packets that we didn’t catch above and give the connection 30
       seconds of live time. Most often this just catches ICMP ping packets.

              accept any 30 any

Time Restrictions and Impulses

   Simple Time Restrictions
       Often it will be the case that you do not want to use the same  set  of
       filter  rules  at all times. This can be accomplished by the use of the
       restrict and or-restrict statements.  For  example,  suppose  that  you
       wanted  diald  to  keep  the  line  up at all times from 08:00 to 18:00
       Monday to Friday, and from 08:00 to 14:00 on Saturday, but  you  wanted
       the  line  to stay down at all other times.  This could be accomplished
       by the following filter rules:

              restrict 08:00:00 18:00:00 1-5 * *
              or-restrict 08:00:00 14:00:00 6 * *
              up
              restrict * * * * *
              down

       Note that the statement "restrict * * * * *" means that the "down" rule
       is  applicable  at  all  times.  The  reason this set of rules works as
       intended is that diald looks for the first rule that is  applicable  to
       each  packet.  During  the  hours that the "up" rule is applicable, the
       down rule will never be examined. Outside of those hours the down  rule
       will be the only matching rule.

       As a slightly more complicated example, suppose that we wanted the line
       to be up "on demand" outside  of  normal  working  hours,  rather  than
       forced  down.  In  addition suppose that we must force the line down 15
       minutes after the end of normal business hours for 15 minutes to  clear
       the  modem  to  accept  an  incoming  call from a branch site that will
       update the sales database.  This can be accomplished by  the  following
       filter rules:

              restrict 08:00:00 18:00:00 1-5 * *
              or-restrict 08:00:00 14:00:00 6 * *
              up
              restrict 18:15:00 18:30:00 1-5 * *
              restrict 14:15:00 14:30:00 6 * *
              down
              restrict * * * * *
              include /etc/diald/standard.filter

   Impulses
       In  many countries phone calls are charged in fixed size quanta, called
       impulses. Once an impulse has started, you are charged for  the  entire
       impulse.  This  means  that there is no money to be saved by hanging up
       the phone just after the start of an impulse.   Diald  has  a  facility
       that  allows  you to specify the impulse charging mechanism in use, and
       arrange to try and hang up near the end of impulses.

       As an example, suppose that on Monday to Friday, from  08:00  to  15:00
       phone  calls are charged in impulses of 3 minutes, but outside of these
       hours they are charged in impulses of 9 minutes.  In  addition  suppose
       that  the  first  impulse  of  any  phone  call  is  always  3 minutes,
       regardless of when the call is made.

       The  following  rules,  placed   before   your   filtering   rules   in
       /etc/diald/diald.options, will tell diald about this impulse system.

              restrict 08:00:00 15:00:00 1-5 * *
              impulse 150,510,30
              restrict * * * * *
              impulse 150,30

              The diald man page should be consulted for the precise semantics
              of the impulse command.

   Restrictions Dont Do Everything
       There are some problems that you might be tempted to solve  using  time
       restrictions, that are better solved in a different way.

       For  example,  suppose  you  wanted to bring the phone line up every 30
       minutes for 5 minutes to check your mail. You might be tempted have the
       mail  collection  started  in  your  ip-up  script, and to write a long
       series of rules like:

              restrict 00:00:00 00:05:00 * * *
              or-restrict 00:30:00 00:35:00 * * *
               .
               .
               .
              up

       This will work, but requires writing a rather  long  series  of  rules.
       Furthermore,  the problem can better be solved by having cron run a job
       every 30 minutes that  issues  diald  an  "up"  command  via  the  fifo
       control,  or sends it a SIGUSR1, which has the same effect.  This would
       cause diald to make a single attempt to dial out, and if it succeeds in
       making  the  connection  the  ip-up script will be run, collecting your
       mail.

SEE ALSO

       diald(8), dctrl(1), diald-monitor(5), diald-control(5)

AUTHOR

       Eric Schenk (Eric.Schenk@dna.lth.se)

                            DIALD 0.99 - 1999.04.06          DIALD-EXAMPLES(5)