@database MiamiDx.guide

@Master MiamiDx.texinfo

@Width 72


This is the AmigaGuideŽ file MiamiDx.guide, produced by Makeinfo-1.55 from 
the input file MiamiDx.texinfo.

   Documentation for Miami Deluxe V1.0c

   (c) Copyright 1998-2000 Nordic Global Inc. All Rights Reserved.

   $VER: MiamiDx.guide 1.0c (10.4.2000)


@Node Main "MiamiDx.guide"
@Next "NODE_LEGAL"

Miami Deluxe
************

   This is the documentation for Miami Deluxe (MiamiDx) V1.0c, an
integrated TCP/IP router system for AmigaOS. Copyright (C) 1998-2000
Nordic Global Inc. All rights reserved. Program and documentation by
Holger Kruse.


 @{" Legal Issues " Link "NODE_LEGAL"}                            Some legal information
 @{" Getting Started " Link "NODE_GETTINGSTARTED"}                         Requirements and installation
 @{" TCP/IP Concepts " Link "NODE_CONCEPTS"}                         TCP/IP Concepts
 @{" Typical Configuration " Link "NODE_TYPICAL"}                   Easy ways to configure MiamiDx
 @{" Reference " Link "NODE_REFERENCE"}                               Reference section (menus/tooltypes etc.)
 @{" Configuration details " Link "NODE_CONFIG"}                   Configuration details (reference)
 @{" Specifications " Link "NODE_SPECIFICATIONS"}                          File formats, command languages etc.
 @{" Utility Programs " Link "NODE_UTILITY"}                        Other programs for MiamiDx
 @{" Compatibility " Link "NODE_COMPATIBILITY"}                           Compatibility issues
 @{" Restrictions " Link "NODE_RESTRICTIONS"}                            Restrictions of the current version
 @{" History " Link "NODE_HISTORY"}                                 History of MiamiDx
 @{" The Future " Link "NODE_FUTURE"}                              The future of MiamiDx
 @{" Support " Link "NODE_SUPPORT"}                                 How to get help or updates
 @{" Acknowledgements " Link "NODE_ACKNOWLEDGEMENTS"}                        Acknowledgements
 @{" Glossary " Link "NODE_GLOSSARY"}                                Glossary


@EndNode

@Node "NODE_LEGAL" "MiamiDx.guide/NODE_LEGAL"
@Next "NODE_GETTINGSTARTED"
@Prev "Main"
@Toc "Main"

Legal Issues
************


 @{" Disclaimer " Link "NODE_LEGAL_DISCLAIMER"}                             Responsibility disclaimer
 @{" Usage / Copying " Link "NODE_LEGAL_CONDITIONS"}                        Usage and copying conditions
 @{" Registration " Link "NODE_LEGAL_REGISTRATION"}                           Shareware registration


@EndNode

@Node "NODE_LEGAL_DISCLAIMER" "MiamiDx.guide/NODE_LEGAL_DISCLAIMER"
@Next "NODE_LEGAL_CONDITIONS"
@Toc "NODE_LEGAL"

Disclaimer
==========

MiamiDx IS SUPPOSED TO BE A TCP/IP PACKAGE FOR AmigaOS THAT CAN BE USED
TO CONNECT YOUR AMIGA TO THE INTERNET BY MODEM OR THROUGH A NETWORK
DEVICE.  EVEN THOUGH EVERY EFFORT HAS BEEN MADE TO MAKE MiamiDx AS
COMPATIBLE TO THE TCP/IP STANDARD AS POSSIBLE, I CANNOT RULE OUT THE
POSSIBILITY THAT MiamiDx HAS BUGS THAT HAVE HARMFUL SIDE EFFECTS ON
YOUR SYSTEM OR ON OTHER MACHINES CONNECTED TO YOUR AMIGA.

I HEREBY REJECT ANY LIABILITY OR RESPONSIBILITY FOR THESE OR ANY OTHER
CONSEQUENCES FROM THE USE OF MiamiDx WHATSOEVER. THIS INCLUDES, BUT IS
NOT LIMITED TO, DAMAGE TO YOUR EQUIPMENT, TO YOUR DATA, TO OTHER
MACHINES YOUR AMIGA IS CONNECTED TO, ANY EQUIPMENT CONNECTED TO THOSE
HOSTS, PERSONAL INJURIES, FINANCIAL LOSS OR ANY OTHER KINDS OF SIDE
EFFECTS.

MiamiDx IS PROVIDED AS-IS. THIS MEANS I DO NOT GUARANTEE THAT MiamiDx
IS FIT FOR ANY SPECIFIC PURPOSE AND I DO NOT GUARANTEE ANY BUG FIXES,
UPDATES OR HELP DURING ERROR RECOVERY.

   MiamiDx is based on the 4.4BSD V.2 TCP/IP networking code, in the
version distributed by Walnut Creek on CD-ROM.

   All of the original 4.4BSD code is freely distributable, and has
been contributed by different sources. For details about individual
copyright and disclaimer rules, please refer to the source files, which
are available from different sources, e.g. from the @{b}4.4BSD Lite@{ub} CD-ROM
available from Walnut Creek.

   The following copyright notice applies to the complete original
4.4BSD software package:

   Start quote

   All of the documentation and software included in the 4.4BSD and
4.4BSD-Lite Releases is copyrighted by The Regents of the University of
California.

   Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met: 1. Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer.  2.
Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
  must display the following acknowledgement: This product includes
software developed by the University of California, Berkeley and its
contributors.  4. Neither the name of the University nor the names of
its contributors    may be used to endorse or promote products derived
from this software    without specific prior written permission.

   THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

   End Quote

   Please be advised that this copyright notice does NOT apply to the
MiamiDx package. MiamiDx is NOT freely distributable, unless otherwise
stated.  See @{"Usage / Copying" Link "NODE_LEGAL_CONDITIONS"} for details.

   Some of MiamiDx's GUI modules rely on @{b}Magic User Interface (MUI)@{ub}.
MUI is Copyright by Stefan Stuntz.

   Some of MiamiDx's GUI modules require the MUI custom class "Busy.mcc'
by Klaus Melchior. Here is the associated copyright notice:

   Begin Quote

   Busy.mcc is (c) 1994-1996 by Klaus 'kmel' Melchior

   End Quote


@EndNode

@Node "NODE_LEGAL_CONDITIONS" "MiamiDx.guide/NODE_LEGAL_CONDITIONS"
@Next "NODE_LEGAL_REGISTRATION"
@Prev "NODE_LEGAL_DISCLAIMER"
@Toc "NODE_LEGAL"

Usage / Copying
===============

   MiamiDx is shareware. In this case this means that a personalized
key file is required to use the full functionality of MiamiDx.

   Users will receive their personalized key file from me after
registering.  The key file may not be made available to other users !
Giving the key file to other users or using key files that you did not
receive directly from me for your personal use is considered an act of
software piracy !

   Key files are non-transferable and may not be sold or traded to any
other person or organization. They are intended to be used only by the
person who registered.

   The MiamiDx binary or the binaries of any of the utility programs
may not be modified or patched in any way (not even for personal use),
except in ways explicitly approved by me for software updates. Using
patched or modified binaries is considered an act of software piracy !

   MiamiDx binaries may only be used for the purpose intended, i.e. to
be executed on Amiga computers by AmigaOS. Reassembling,
reverse-engineering, or translating binaries is expressly prohibited.

   The documentation and program texts of MiamiDx are subject to the
same copyright as the program itself. This means neither documentation
nor program texts may be modified or translated in any way.

   To avoid any misunderstanding: YOU MAY NOT translate and distribute
MiamiDx program texts or documentation, unless I officially appoint you
as a MiamiDx translator. Unauthorized translations of program texts or
documentation are illegal, violate my copyright, and will be deleted
from public software sites.

   If you want to distribute the MiamiDx archive the following
conditions apply:

   @{b}*@{ub} The sales price must not be higher than the cost of the empty
     disks required for the MiamiDx files plus a nominal copying fee
     plus costs for shipping. The total price must not be higher than
     10 US$ or 15 DM or the equivalent in any other currency.

   @{b}*@{ub} If the MiamiDx archive is to be distributed as part of a CD-ROM
     collection of public domain and/or shareware programs, then the
     retail price of the CD-ROM may not exceed 20 US$, 30 DM or the
     equivalent in any other currency.

   @{b}*@{ub} All parts of the program and the documentation must be complete.
     The distribution of single parts or incomplete subsets of the
     original distribution is not allowed.  The distribution of
     keyfiles is not allowed.

   @{b}*@{ub} MiamiDx or parts of it may usually not be sold in combination with
     or as part of commercial software. Separate licensing conditions
     for commercial resale are available from @{b}kruse@nordicglobal.com@{ub}
     upon request.  However, unless and until you receive my explicit
     written approval, do not assume that you may distribute MiamiDx or
     parts of it in combination or as part of commercial software.

   @{b}*@{ub} Program and documentation may not be changed in any way.
     Exception (this means: acceptable) is the use of archivers such as
     @{b}LHA@{ub} as long as it remains possible to retrieve the original
     program/data.


@EndNode

@Node "NODE_LEGAL_REGISTRATION" "MiamiDx.guide/NODE_LEGAL_REGISTRATION"
@Prev "NODE_LEGAL_CONDITIONS"
@Toc "NODE_LEGAL"

Registration
============

   If you often use MiamiDx or need any of the features disabled in the
demo version or longer connection times than the demo version allows,
then I suggest you register MiamiDx.

   To register please run the program @{b}MiamiRegister@{ub}. It explains the
registration procedure in detail, and allows you to register
interactively.

   Please contact me at @{b}kruse@nordicglobal.com@{ub} if for some reason you
cannot run the registration program @{"MiamiRegister" Link "NODE_UTILITY_MIAMIREGISTER"}.

   The registration fee is US$ 60 for a standard, `full' MiamiDx
license. Registered users of ppp.device or Miami receive a discount
when upgrading to Miami. The details are explained in @{"MiamiRegister" Link "NODE_UTILITY_MIAMIREGISTER"}.

   Special offers for group licensing (10 users or more at a time),
license prepayment and commercial redistribution are also available.
Please contact @{b}kruse@nordicglobal.com@{ub} for more details.


@EndNode

@Node "NODE_GETTINGSTARTED" "MiamiDx.guide/NODE_GETTINGSTARTED"
@Next "NODE_CONCEPTS"
@Prev "NODE_LEGAL"
@Toc "Main"

Getting Started
***************


 @{" Introduction " Link "NODE_GETTINGSTARTED_INTRO"}                                   Introduction
 @{" Requirements " Link "NODE_GETTINGSTARTED_REQUIREMENTS"}                                   Requirements
 @{" Installation " Link "NODE_GETTINGSTARTED_INSTALLATION"}                                   Installation
 @{" Configuration " Link "NODE_GETTINGSTARTED_CONFIG"}                                  Configuration


@EndNode

@Node "NODE_GETTINGSTARTED_INTRO" "MiamiDx.guide/NODE_GETTINGSTARTED_INTRO"
@Next "NODE_GETTINGSTARTED_REQUIREMENTS"
@Toc "NODE_GETTINGSTARTED"

Introduction
============

   MiamiDx is an integrated TCP/IP router system for AmigaOS, that
allows you to access the Internet or a local-area network by modem or by
some other network device (e.g. Ethernet) in a very easy way. It also
allows you to route traffic between different networks, share a single
modem among multiple computers, use your Amiga as a firewall and many
other things.

   MiamiDx is based on the latest version (4.4BSD V2) of the official
BSD networking code, plus some of the extensions made by third parties
(such as FreeBSD T/TCP and Path MTU discovery code).  This means
MiamiDx contains a "true" and complete TCP/IP stack, not just an
emulation that only supports parts of the TCP/IP standard.

   The application programmers' interface of MiamiDx is compatible with
that of AmiTCP 4.x (@{b}bsdsocket.library@{ub}), i.e. most of the programs
written and compiled for AmiTCP 4.x will work with MiamiDx without any
modification and without recompiling. The API used by MiamiDx is fully
backwards-compatible with the one used by Miami, i.e. all programs
specifically written for Miami also work with MiamiDx.

   In addition, MiamiDx has a built-in dialer that can be used both in
script-driven and interactive mode, an implementation of the (C)SLIP
and PPP protocols, an interface to SANA-II drivers, a graphical user
interface for program control and configuration, a client for SOCKS
proxy servers and many other features.

   MiamiDx also has a built-in implementation of @{b}inetd@{ub}, the "Internet
super-server", with several built-in services including "fingerd" and
"identd", a built-in implementation of @{b}TCP:@{ub}, the AmigaDOS stream
handler for TCP/IP, and a built-in implementation of usergroup.library,
the interface to manage users and user groups. Plus MiamiDx comes with
a large collection of clients servers and tools, e.g. a telnet client,
an ftp client and a telnet server.

   Unlike other general-purpose protocol stacks MiamiDx has very
extensive support for modem-based dial-up connections to access the
Internet.  The configuration process is made as simple as possible:
most of the configuration parameters are determined automatically by
MiamiDx.  MiamiD can also be used with a non-modem connection, e.g. an
Ethernet interface, an Arcnet interface, or a cable modem, or several
different interfaces at the same time.

   MiamiDx supports several different GUI modules for its configuration.
When controlling MiamiDx (going online or offline, or changing settings
for instance) a GUI module has to be loaded. Once MiamiDx is online it
is possible to unload the GUI module in order to save memory. You can
reload the GUI module at any time if you want to make any changes to
your setup.

   MiamiDx currently supports the following GUI modules:

@{b}MUI@{ub}
     This module requires MUI (Magic User Interface) 3.8 or higher, and
     generates a user interface in the typical MUI style.


@EndNode

@Node "NODE_GETTINGSTARTED_REQUIREMENTS" "MiamiDx.guide/NODE_GETTINGSTARTED_REQUIREMENTS"
@Next "NODE_GETTINGSTARTED_INSTALLATION"
@Prev "NODE_GETTINGSTARTED_INTRO"
@Toc "NODE_GETTINGSTARTED"

Requirements
============

   To use MiamiDx you need:

   @{b}*@{ub} An Amiga running OS 2.04 or higher. Workbench 2.1 or higher is
     strongly recommended.

   @{b}*@{ub} A 68020 or faster CPU.

   @{b}*@{ub} 3 MB of RAM, more recommended.

   @{b}*@{ub} 3 MB of harddisk space

   @{b}*@{ub} MUI 3.8 or higher if you want to use one of the MUI GUI modules
     (at this time the only GUI modules available).

   You will also need some hardware for networking and a machine to
connect to. This could for instance be:

   @{b}*@{ub} a modem connected to your Amiga and to a phone line. The modem
     should be at least roughly Hayes-compatible. Most contemporary
     modems are. Plus a SLIP or PPP account with an Internet provider.
     If you only have a shell account you can use MiamiDx as well, but
     then you need to install Slirp or TIA at your provider first. In
     this case you should ask your provider whether you are allowed to
     do this, and how and where you can get Slirp or TIA.

   @{b}*@{ub} an Ethernet board, a DSL/cable modem, and an Internet for
     DSL/cable modem service.

   @{b}*@{ub} an Ethernet board connecting your machine to a local area network.

   Note that MiamiDx does @{i}not@{ui} require external SANA-II devices for PPP
or (C)SLIP, such as ppp.device, appp.device, amippp.device or
(rh)(c)slip.device. The protocols PPP and (C)SLIP are built into
MiamiDx, in versions more efficient and more advanced than those
currently available in SANA-II devices.


@EndNode

@Node "NODE_GETTINGSTARTED_INSTALLATION" "MiamiDx.guide/NODE_GETTINGSTARTED_INSTALLATION"
@Next "NODE_GETTINGSTARTED_CONFIG"
@Prev "NODE_GETTINGSTARTED_REQUIREMENTS"
@Toc "NODE_GETTINGSTARTED"

Installation
============

   MiamiDx is packaged in the following archives:

@{b}MiamiDx10-main.lha@{ub}
     The main archive. Everyone needs this.

@{b}MiamiDx10-MUI.lha@{ub}
     The MUI module for Miami. You need this if you want to use Miami
     together with MUI >=3.8. (Currently the only available option)

   Everybody needs to download the main archive and one GUI module
archive.

   Download all archives, unarchive them into the same (temporary)
directory, and then execute the Installer script in that directory to
install MiamiDx. The Installer script can be used for a new
installation or for updates.

   All files are copied from the installation directory to a single
target directory, and no system files or system directories are
touched, with two exceptions:

   @{b}*@{ub} The Installer script asks you whether you want to create a
     "Miami:" assign, and then adds the required statements to your
     user-startup file. Doing this is @{i}required@{ui}.  If you skip this step
     during the installation then you @{i}must@{ui} manually create the assign
     before starting MiamiDx. Otherwise MiamiDx will not work properly.

   @{b}*@{ub} "sanamni.device" is copied to "DEVS:Networks". This is a device
     that allows you to use Envoy in parallel with the Ethernet drivers
     used by MiamiDx. Please see @{"sanamni.device" Link "NODE_UTILITY_SANAMNI"} for more information on
     this.

   If you have already installed Miami and want to upgrade to MiamiDx
then it is safe (and recommended) to install MiamiDx on top of your
existing Miami installation, i.e. in the existing "Miami:" directory.
Your Miami settings files are not affected that way.


@EndNode

@Node "NODE_GETTINGSTARTED_CONFIG" "MiamiDx.guide/NODE_GETTINGSTARTED_CONFIG"
@Prev "NODE_GETTINGSTARTED_INSTALLATION"
@Toc "NODE_GETTINGSTARTED"

Configuration
=============

   There are different ways to configure MiamiDx, depending on whether
you are upgrading from Miami or using MiamiDx for the first time, and
depending on the kind of network equipment you are using MiamiDx with.

   If you are upgrading from Miami then the easiest way to configure
MiamiDx is to just load your existing Miami settings file into MiamiDx,
i.e. start MiamiDx, choose "Load Settings", load "Miami:Miami.default",
and then choose "Save Settings as default".  This creates a MiamiDx
default settings file "Miami:MiamiDx.default" with your former Miami
settings, ready to use. After that you can create additional interfaces
using the procedures described below.

   If you are not upgrading from Miami you need to configure MiamiDx
from scratch. There are two basic ways of configuring MiamiDx or adding
new interfaces to an existing MiamiDx configuration:

   @{b}*@{ub} Configure MiamiDx manually, through the user interface. Please see
     @{"Typical Configuration" Link "NODE_TYPICAL"} for descriptions of many common
     configurations.

   @{b}*@{ub} Use @{"MiamiInit" Link "NODE_UTILITY_MIAMIINIT"}, the "configuration wizard" for MiamiDx.

   The use of MiamiInit is recommended in the following cases:

   @{b}*@{ub} Connection to an Internet service provider via PPP or (C)SLIP, by
     modem or using ISDN hardware.

   @{b}*@{ub} Connection to an Internet service provider via DSL modem or cable
     modem, and your IP address is assigned to you either statically or
     via DHCP.

   Manual configuration of MiamiDx is necessary in the following cases:

   @{b}*@{ub} Connection to an Internet service provider via DSL modem or cable
     modem, using one of the protocols "PPPoE", "PPTP" or "L2TP".

   For most other types of connections (in particular connections to
local Ethernet networks, Arcnet networks, PLIP networks, null-modem
connections etc.) it is your choice whether you want to use MiamiInit
or configure MiamiDx manually. Using MiamiInit is often a little easier.


@EndNode

@Node "NODE_CONCEPTS" "MiamiDx.guide/NODE_CONCEPTS"
@Next "NODE_TYPICAL"
@Prev "NODE_GETTINGSTARTED"
@Toc "Main"

TCP/IP Concepts
***************

   This section explains several concepts that are relevant to TCP/IP
networking, such as IP addresses, netmasks, routing, firewalls etc.


 @{" IP addresses and netmasks " Link "NODE_CONCEPTS_IP"}                                     IP addresses and netmasks
 @{" Using multiple interfaces " Link "NODE_CONCEPTS_MULTI"}                                     Using multiple interfaces
 @{" Modem sharing - IP-NAT/SOCKS " Link "NODE_CONCEPTS_SHARING"}                                  Modem sharing - IP-NAT/SOCKS
 @{" Configuring a firewall " Link "NODE_CONCEPTS_FIREWALL"}                                        Configuring a firewall
 @{" Complex networks - adding manual routes " Link "NODE_CONCEPTS_ROUTES"}                       Complex networks - adding manual routes
 @{" Automatic connect/disconnect " Link "NODE_CONCEPTS_AUTOCONNECT"}                                  Automatic connect/disconnect


@EndNode

@Node "NODE_CONCEPTS_IP" "MiamiDx.guide/NODE_CONCEPTS_IP"
@Next "NODE_CONCEPTS_MULTI"
@Toc "NODE_CONCEPTS"

IP addresses and netmasks
=========================

   Every machine on the Internet must have at least one unique address.
The protocol currently used on the Internet (IPv4) uses 32-bit
addresses for this purpose. The typical notation is "dotted decimal",
i.e. the 32-bit address is split up into four 8-bit bytes, and each
byte is printed as a decimal number, separated by ".", e.g.
124.251.35.178.

   IP addresses are assigned to interfaces on a machine, not to the
machine itself, i.e. a machine may have more than one IP address
assigned to it if it has multiple interfaces. It is possible (with some
restrictions) for multiple interfaces on the same machine to share a
single IP address.  Please see @{"Using multiple interfaces" Link "NODE_CONCEPTS_SHARING"} for more
information on this.

   IP addresses consist of two parts: the network part and the host
part. The network part determines the (physical) network a machine is
located on, the host part is the address of the machine within the
network. A "netmask" is used to define which part of an IP address is
the network part and which is the host part: A netmask has 32 bits,
like an IP address. Any bit set to one means that the corresponding bit
in the IP address belongs to the network address. A bit set to zero in
the netmask means that the corresponding bit in the IP address belongs
to the host address. The ones and zeros are usually, but not always,
consecutive, e.g. a typical netmask could be (in binary notation)
11111111111111111111111100000000 (24 ones and 8 zeros). In dotted
decimal notation this becomes 255.255.255.0. If this IP address is
configured for an interface then this means that the address of the
network connected to the interface takes up the upper 2 bytes of each
IP address, and the lower byte of each IP address is used to address
hosts on the network.

   Traditionally every IP address has belonged to a "class" that
defines its netmask:

@{b}0.0.0.0 - 0.255.255.255@{ub}
     Reserved, not used on the Internet

@{b}1.0.0.0 - 126.255.255.255@{ub}
     "Class A": netmask is 255.0.0.0

@{b}127.0.0.1@{ub}
     Loopback address. Always refers to the local machine

@{b}127.0.0.2 - 127.255.255.255@{ub}
     Reserved for future loopback purposes, should not be used because
     behavior is not consistent across TCP/IP stacks.

@{b}128.0.0.0 - 191.255.255.255@{ub}
     "Class B": netmask is 255.255.0.0

@{b}192.0.0.0 - 223.255.255.255@{ub}
     "Class C": netmask is 255.255.255.0

@{b}224.0.0.0 - 239.255.255.255@{ub}
     Used for multicasting, not assigned to individual machines.

@{b}240.0.0.0 - 255.255.255.254@{ub}
     Reserved.

@{b}255.255.255.255@{ub}
     Special purpose: used for broadcasting on the default interface

   Sometimes the class for an IP address it too large for practical use,
e.g. a company that registered a class A address range might not want to
put all of their machines on a single physical network, but rather split
up the IP address range further. This is called "subnetting". An IP
address range can be split up into smaller chunks, by assigning netmasks
to IP address ranges that have a smaller number of bits allocated to
hosts (and therefore more ones in the netmask). Such netmasks are called
"subnet masks".

   As an example, the class A address range 5.x.y.z might be subnetted
into 256 address ranges that have the size of a class B address range,
i.e.  5.0.y.z, 5.1.y.z, ..., 5.255.y.z, each with a subnet mask of
255.255.0.0.

   The concept of IP address "classes" (and therefore the concept of
implied netmasks for all IP addresses) is obsolete these days. Netmasks
for IP addresses are now always configured explicitly, when needed,
instead of relying on classes. In addition to "subnetting" some
Internet providers now also use "supernetting", i.e. combining multiple
small networks into one larger physical network, thereby reducing the
number of ones in a netmask.

   Within each network two IP addresses are "special" and cannot be
assigned to machines. These are the IP addresses with "hosts" bits set
to all zeroes or all ones, e.g. for the network 10.20.30.x (netmask
255.255.255.0) the IP addresses 10.20.30.0 and 10.20.30.255 cannot be
assigned to machines. Both of these addresses are used for broadcasting
to the network. The official broadcast address is the
"all-ones-address", i.e. 10.20.30.255 in the example, but some old
stacks use the "all-zeoes-address" instead.  On a subnetted network
this applies both to the original network and to each subnet.

   As an additional recommendation, no single byte of any IP address
assigned to a host should ever be 0 or 255, because some older TCP/IP
stacks have problems with such addresses.

   Users often wonder which IP addresses they should use on their
machines. IP addresses are usually assigned by Internet providers, and
you need to use the ones they provide. However if you only want to
create your own private network, not connected to the Internet, or if
you need more IP addresses than your Internet provider assigned to you
and you want to use techniques such as IP-NAT or SOCKS proxy servers to
connect you network to the Internet, through a single official IP
addresses, then you need to assign IP addresses to your machines by
yourself. To do this choose from the following IP address ranges. These
addresses are guaranteed to be unused on the Internet, so using them in
your LAN will not prevent you from connecting to any existing Internet
hosts:

   @{b}*@{ub} 10.0.0.0, netmask 255.0.0.0 (i.e. 10.0.0.0 to 10.255.255.255)

   @{b}*@{ub} 172.16.0.0, netmask 255.240.0.0 (i.e. 172.16.0.0 to 172.31.255.255)

   @{b}*@{ub} 192.168.0.0, netmask 255.255.0.0 (i.e. 192.168.0.0 to
     192.168.255.255)

   If you want to configure an Ethernet consisting of several machines
then a good choice is the IP address range 192.168.1.x (with 1 <= x <=
254 for hosts) and a netmask of 255.255.255.0. Traditionally addresses
ending in ".1" are assigned to the router providing Internet
connectivity.

   Keep in mind that these IP addresses are not "real" IP addresses,
i.e. the machines with these addresses cannot communicate with hosts on
the Internet unless they are connecting through an IP-NAT box or proxy
server with a "real" IP address.


@EndNode

@Node "NODE_CONCEPTS_MULTI" "MiamiDx.guide/NODE_CONCEPTS_MULTI"
@Next "NODE_CONCEPTS_SHARING"
@Prev "NODE_CONCEPTS_IP"
@Toc "NODE_CONCEPTS"

Using multiple interfaces
=========================

   There are two types of physical networks:

@{b}point-to-point networks@{ub}
     Networks that connect exactly two machines. Such a network usually
     does not require any physical addressing. Examples are serial
     connections (SLIP, PPP) and parallel connections (PLIP).

@{b}multi-drop network@{ub}
     Networks that connect (potentially) more than two machines. Such a
     network requires physical addressing of some sort (e.g. 6-byte MAC
     addresses for Ethernet), and a translation mechanism to find the
     physical address from an IP address (typically "Arp"). Examples
     are Ethernet and Arcnet.

   Multi-drop networks are always configured by first assigning an IP
address range (network or subnet) to the whole network, and by then
assigning individual IP addresses from that range to each machine on
the network. For instance an Ethernet network consisting of four
machines could be assigned the network 192.168.1.x/255.255.255.0, with
the IP addresses 192.168.1.1, 192.168.1.2, 192.168.1.3 and 192.168.1.4
for the four machines.

   As a rule, no two physical multi-drop networks may share IP
addresses, i.e. if you have two physical multi-drop networks (e.g. two
Ethernets, or one Ethernet and one Arcnet), then the IP address ranges
of both networks have to be strictly separate and non-overlapping.
(There are a few exceptions to this, but they lead to very complicated
configurations and are therefore not discussed here.)

   From the last two paragraphs it follows that a machine which is
connected to two or more multi-drop networks requires a different IP
address for each of these interfaces, i.e. IP addresses between
multi-drop networks cannot be shared.

   This rule does not apply to point-to-point interfaces. A
point-to-point link has no notion of "netmasks" or "IP address ranges".
Each endpoint of a point-to-point link is assigned one IP address, but
the IP addresses don't need to have any relation to each other, except
that they cannot be the same number. They can be completely different
numbers (e.g. 1.2.3.4 and 111.54.32.222) or they can be similar (e.g.
192.168.2.1 and 192.168.2.2). It does not matter.

   Machines that have multiple point-to-point links can share local IP
addresses among all point-to-point links, and they can even share the
local IP address with no more than ONE multi-drop interface on the same
machine. Sharing local IP addresses among multiple point-to-point
interfaces can simplify the configuration.

   There are two common situation when you want to use more than one
interface on a machine:

   @{b}*@{ub} One machine is acting as an Internet router for a LAN. It could,
     e.g., have one interface providing the PPP or DSL connection to
     the Internet, and another interface connecting the machine to a
     local Ethernet. The machine routing between both interfaces is
     your "Internet router".

   @{b}*@{ub} You have more than one physical network in your LAN, e.g. an
     Ethernet with some machines on it, and a parallel (PLIP)
     connection connecting two machines. One of the machines has to be
     on both networks to route data between them. That machine is a
     "local router".

   It is VERY STRONGLY RECOMMENDED that you have no more than ONE router
in your network. If your LAN consists of multiple physical networks
then the required local routers should be the same machines that also
route data to the Internet, i.e. one router should be connected to all
physical networks, and all other machines on the network should only be
connected to a single network, not route data between networks. That
kind of setup GREATLY simplifies the configuration, because you do not
need to configure any manual routes. All routes are set automatically
for you, just by configuring interface addresses.

   Example for a setup consisting of one router with an Internet
connection, which is also connected to one local Ethernet (with two
other machines on it) and a PLIP link to another machine:

@{b}Machine A (router)@{ub}
    @{b}PPP connection to the Internet@{ub}
          Dynamic IP address

    @{b}PLIP link to machine B@{ub}
          192.168.1.1

    @{b}Ethernet interface@{ub}
          192.168.1.1

@{b}Machine B (on the PLIP link)@{ub}
     192.168.2.1

@{b}Machine C (on the Ethernet)@{ub}
     192.168.1.2

@{b}Machine D (on the Ethernet)@{ub}
     192.168.1.3

   In this example the PLIP link and the Ethernet share the local IP
address on the router. If that router had multiple point-to-point links
then their local IP addresses could all be shared (192.168.1.1), only
the remote IP addresses (assigned to each of the machines connected by
PLIP) would have to be different, e.g. 192.168.2.2, 192.168.2.3,...

   With an Internet connection, as in the example, each machine needs
to know which machine will forward data to the Internet. That machine
is called the "default router" or "default gateway". In the example
above for machine A the default gateway is the router at the Internet
provider (at the other end of the PPP link). For machines B, C and D
the default gateway is machine A. Please note that the default gateway
always has to be DIRECTLY connected, by a single "hop", i.e. it needs
to be on the same physical network.

   In MiamiDx the "default gateway" is defined in "Interfaces->Edit" for
the interface that connects to the default gateway. For the interface
that contains the default gateway set the "Gateway priority" to a
non-zero value, and enter the IP address of the gateway. For all other
interfaces set the gateway priority to zero. If you have multiple
interfaces connecting you to the Internet (e.g. multiple Internet
providers) then you can define which of the various default gateways
should be used if more than one Internet connection is online, by
setting the "gateway priority" for these interfaces to different values.

   The advantage of this kind of configuration with a single router is
that from the point of view of every machine on your LAN routing is
very simple: either data is intended for a machine on the same physical
network, then it is directly delivered to it, or it is intended for a
machine not on the same physical link (which means it is intended for a
machine on a different physical network on your LAN or for a machine
somewhere on the Internet), then it is sent to the default gateway and
routed further from there. No manual routes (overrides) are required
for this.

   If it is technically impossible to configure your network in such a
fashion, with a single router, and you absolutely need multiple routers
then you need to configure manual routes on some of your machines.
Please see @{"Complex networks - adding manual routes" Link "NODE_CONCEPTS_ROUTES"} for more information
on this.

   In addition to setting the default gateway correctly and possibly
setting manual routes, you also need to make sure that every machine
that is supposed to act as a router (forward packets between
interfaces) is configured as a gateway (i.e. has routing enabled). For
routers running MiamiDx you need to enable the "Gateway" switch on the
"TCP/IP" page.


@EndNode

@Node "NODE_CONCEPTS_SHARING" "MiamiDx.guide/NODE_CONCEPTS_SHARING"
@Next "NODE_CONCEPTS_FIREWALL"
@Prev "NODE_CONCEPTS_MULTI"
@Toc "NODE_CONCEPTS"

Modem sharing - IP-NAT/SOCKS
============================

   IP-NAT and SOCKS are mechanisms that allow you to do what is commonly
called "modem sharing": you sign up for a single Internet account with
your Internet provider, for one machine and with one (possibly even
dynamic) IP address, and then you use that account to access the
Internet with more multiple machines simultaneously.

   The IP-NAT and SOCKS discussion in this chapter is only useful to
you if you are using MiamiDx on your Internet router AND you have more
than one computer you want to connect to your Internet AND you have to
use "fake" IP addresses, i.e. you have more computers than IP addresses
assigned to you by your Internet provider.

   The first thing to do is decide which IP addresses you want to use
for your network, then configure the Internet router (Internet and LAN
interfaces), and configure all other machines on the LAN. Please see
@{"Typical Configuration" Link "NODE_TYPICAL"}, @{"IP addresses and netmasks" Link "NODE_CONCEPTS_IP"} and
@{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} for more information on this.

   For IP/NAT and SOCKS setups it is strongly recommended that you use
a static DNS configuration throughout your network. This means ask your
Internet provider for the IP addresses of DNS servers, then enter them
on EVERY machine in "Database->DNS servers.".

   Once you are done you should be able to do the following things:

   @{b}*@{ub} From every machine on your LAN ping (Miami:MiamiPing) every other
     machine on the LAN.

   @{b}*@{ub} From the Internet router ping machines on the Internet.

   Don't continue with the IP-NAT/SOCKS configuration until these
features are working. You will not be able to ping machines on the
Internet from machines in the LAN (other than the router) yet.

   Configuring IP-NAT is very easy: on the Internet router select the
TCP/IP page and click on "LAN-Connect...". Make sure the interfaces
providing your Internet connection are set to "Internet", and the
interfaces connecting to networks in your LAN are set to "LAN". Then
set the "IP-NAT" switch to "internal" and checkmark SOCKSD->Enable.
Click on OK.

   After that every machine on your LAN should be able to ping machines
on the Internet.

   For better compatibility it is recommended that you enable SOCKS
(client) on all machines in the networks that support this (except on
the Internet router). To do this in Miami or MiamiDx select the SOCKS
page, checkmark "Enable SOCKS", and enter the IP address of your
Internet router as the default SOCKS server. On other protocol stacks
SOCKS is enabled in different ways, e.g. on PCs running Windows you
need to enable SOCKS in the "Preferences" section of your web browser.


@EndNode

@Node "NODE_CONCEPTS_FIREWALL" "MiamiDx.guide/NODE_CONCEPTS_FIREWALL"
@Next "NODE_CONCEPTS_ROUTES"
@Prev "NODE_CONCEPTS_SHARING"
@Toc "NODE_CONCEPTS"

Configuring a firewall
======================

   The purpose of a firewall is to isolate a local network from the
Internet, in order to protect it from unauthorized accesses from the
Internet. Please note that a firewall is different from an IP filter.
The IP filter in MiamiDx protects only the machine it is configured on,
whereas a firewall protects all machines "behind" the firewall. If the
Amiga running MiamiDx is the only machine you have (i.e. if you do not
have a LAN behind it) then you do not need a firewall. Just configure
"Database->IP filter" instead.

   Before configuring a firewall you first need to set up your network
correctly. Please see @{"Typical Configuration" Link "NODE_TYPICAL"}, @{"IP addresses and netmasks" Link "NODE_CONCEPTS_IP"}
and @{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} for more information about this. If you
want to use IP-NAT or SOCKS then these services need to be set up as
well (see @{"Modem sharing - IP-NAT/SOCKS" Link "NODE_CONCEPTS_SHARING"}) before configuring the firewall.

   Once the connectivity between all machines and the Internet is
working you are ready to configure the firewall. Select the "TCP/IP"
page and click on "LAN-Connect...". Make sure the interfaces providing
your Internet connection are set to "Internet", and the interfaces
connecting to networks in your LAN are set to "LAN".  Then set the
"Firewall" switch to "auto".

   This gives you a basic firewall with the following features:

   @{b}*@{ub} Protection from IP address spoofing. Internet users that try to
     send packets to you with "from addresses" from your own LAN will
     be filtered out, so servers on your LAN do not lower their
     security for such packets.  Important for rlogin and NFS.

   @{b}*@{ub} Protection from ICMP broadcasts ("smurf" attacks), which try to
     use your LAN as a multiplier for denial-of-service attacks.

   @{b}*@{ub} All servers running on your LAN are protected from accesses from
     the outside.  You can selectively enable accesses by adding
     entries to @{"TCP/IP LAN-Connect Firewall" Link "NODE_CONFIG_OTHER_LANCONNECT_FIREWALL"}.

   Occasionally you may find that some programs on some computers in
your LAN stop working correctly once they are behind a firewall.
Usually this happens with operating systems that do not completely
follow IETF standards on port assignment rules, such as Linux, BeOS and
Mac's OpenTransport. In that case adding entries to
@{"TCP/IP LAN-Connect Firewall" Link "NODE_CONFIG_OTHER_LANCONNECT_FIREWALL"} may help. More detailed instructions how to
work around specific problems with specific programs will be added
later. For the moment please ask on the MiamiDx mailing list.


@EndNode

@Node "NODE_CONCEPTS_ROUTES" "MiamiDx.guide/NODE_CONCEPTS_ROUTES"
@Next "NODE_CONCEPTS_AUTOCONNECT"
@Prev "NODE_CONCEPTS_FIREWALL"
@Toc "NODE_CONCEPTS"

Complex networks - adding manual routes
=======================================

   Warning: this section describes advanced configuration techniques for
complex networks, and configuring this section incorrectly may cause
MiamiDx to stop functioning properly, without any obvious error message.

   Before experimenting with manual routes please see
@{"IP addresses and netmasks" Link "NODE_CONCEPTS_IP"} and @{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} to determine if
you really need manual routes. Just because you need manual routes in
other TCP/IP stacks (AmiTCP, Linux etc.) for the same setup does NOT
mean that you will need manual routes in MiamiDx. MiamiDx is smarter in
the way it maintains its routing table and adds all required routes
automatically in most cases. You only need manual routes in very few
situation.

   Rule of thumb: If you have no routers at all or only a single router
in your network then you do NOT need manual routes. If you have multiple
routers in your network then you may need manual routes.

   Manual routes only have to be added for those IP addresses that
MiamiDx does not already know about AND which cannot (or should not) be
reached through the default gateway. MiamiDx knows about the following
IP addresses:

   @{b}*@{ub} All IP addresses fn the machine MiamiDx is running on, i.e.
     localhost, local IP addresses of all interfaces and aliases.

   @{b}*@{ub} All IP addresses of multi-drop interfaces, as defined by netmasks.

   @{b}*@{ub} All remote IP addresses of point-to-point links.

   All other IP addresses are not known to MiamiDx, i.e. traffic to them
would be directed to the default gateway.

   Usually this means that for any machines that are located away from
the default gateway, on a separate branch, connected through a router,
manual routes have to be added. When adding manual routes always add
them to the interface to which the gateway leading to the target of the
route is connected. In most cases the only routes you need are
"indirect host routes" or "indirect network routes". Here is an example:


     Internet provider
        |
        | PPP
        |
     123.45.67.89
     Machine A
     10.1.1.1
        |        Ethernet, netmask=255.255.255.0
        +-------------+----------------+
        |             |                |
     10.1.1.2       10.1.1.3       10.1.1.4
     Machine B      Machine C      Machine D
                                   10.1.1.4
                                       |
                                       | PLIP
                                       |
                                   10.2.1.2
                                   Machine E

   This example has two routers, A and D. Machine A has the remote IP
address of the PPP link configured as its default gateway. Machines B,
C and D have 10.1.1.1 (machine A) configured as their default gateways,
machine E has 10.1.1.4 (machine D) configured as the default gateways.

   The following manual routes have to be added:

@{b}Machine A@{ub}
     Machine E is unknown to machine A (i.e. routing to 10.2.1.2 cannot
     be inferred from the interface configuration on machine A), so a
     manual route has to be added. Add an "indirect network route" to
     the Ethernet interface of machine A, with an IP address of
     10.2.1.2 and a gateway of 10.1.1.4.

@{b}Machine B@{ub}
     Same as machine A.

@{b}Machine C@{ub}
     Same as machine A.

@{b}Machine D@{ub}
     All IP addresses are known to machine D, so no manual routes have
     to be added.

@{b}Machine E@{ub}
     All IP addresses are downstream from machine E's default gateway
     (machine D), so no manual routes have to be added.

   Some variations:

   @{b}*@{ub} If the link between machines D and E was a multi-drop link (e.g.
     Arcnet), then instead of an "indirect host route" you would have
     to add a "indirect network route", with the netmask of the Arcnet
     network and the IP address of the Arcnet network with a "hosts"
     part of all zeroes. In the example machine D could have an IP
     address of 10.2.1.1 on the Arcnet network, and then the IP address
     and gateway for the manual route would be 10.2.1.0 and
     255.255.255.0.

   @{b}*@{ub} If you add manual routes to a point-to-point link then MiamiDx
     will not ask you for a gateway. This is because the gateway is
     implied by the IP address of the machine on the other end of the
     point-to-point link.

   As you can see, you usually need to add manual routes to most
machines on a network if it is connected to another network away from
the default gateway. For large networks that can make configuration
changes complicated. There is one way to simplify the configuration of
manual routes: in most situations it is sufficient to configure manual
routes on routers only, not on all machines. In the example above it
would usually suffice to configure the route to machine E on machine A
only, not on B and C.

   However this method only works if the router (machine A in this case)
generates "ICMP redirects". MiamiDx usually does (unless you disable
the sysctl option "net.inet.ip.redirect"). However not all TCP/IP
kernels do, and some require you to set this option manually, either
during kernel compilation or in the configuration. Also, not all TCP/IP
kernel react to ICMP redirects correctly (MiamiDx does, of course), so
even if the routers send the redirects correctly some machines on your
LAN, with very old or misconfigured TCP/IP kernels, may still not send
data to the correct place.

   Because of that it is usually recommended to use this configuration
shortcut only in very large networks where adding manual routes to all
machines is infeasible.


@EndNode

@Node "NODE_CONCEPTS_AUTOCONNECT" "MiamiDx.guide/NODE_CONCEPTS_AUTOCONNECT"
@Prev "NODE_CONCEPTS_ROUTES"
@Toc "NODE_CONCEPTS"

Automatic connect/disconnect
============================

   A frequently asked question about MiamiDx is how to make interfaces
automatically go online or offline on certain conditions. The following
possibilities exist:

@{b}Automatically go online with an interface when MiamiDx starts@{ub}
     Switch to the "Interfaces" page, select the interface, click on
     "Edit", then "Events", and checkmark "Start -> Auto-online".  For
     more information please see @{"Events" Link "NODE_CONFIG_EVENTS"}.

@{b}Automatically go offline with an interface after a period of inactivity@{ub}
     Switch to the "Interfaces" page, select the interface, click on
     "Edit", then "Auto-connect/disconnect". Set the "Auto-disconnect"
     behavior to "disconnect after inactivity", and enter the time in
     seconds after which you want a disconnect to be triggered.

@{b}Automatically go online with an interface when necessary, i.e. when traffic occurs@{ub}
     Switch to the "Interfaces" page, select the interface, click on
     "Edit", then "Auto-connect/disconnect". There are two checkmarks
     under "Auto-connect": "Auto-connect from suspended" and
     "Auto-connect from offline".

     "Auto-connect from suspended" should always been enabled for
     interfaces that you want to automatically go online on activity.
     "Auto-connect from offline" can only be enabled for ONE interface
     at a time. It should usually be enabled for your default Internet
     interface. Make sure it is disabled for all other interfaces.

     Whenever using auto-connect functions you need to make sure that
     you are using a static DNS configuration. Dynamic DNS
     configurations are incompatible with auto-connect. Please see
     @{"Interfaces Auto-connect/disconnect" Link "NODE_CONFIG_OTHER_IFACEAUTO"} for more information.


@EndNode

@Node "NODE_TYPICAL" "MiamiDx.guide/NODE_TYPICAL"
@Next "NODE_REFERENCE"
@Prev "NODE_CONCEPTS"
@Toc "Main"

Typical Configuration
*********************

   This section describes the procedure for some typical configurations
of MiamiDx. If you are not importing a configuration from Miami or
MiamiInit then the first thing you need to do is the
@{"Overall configuration" Link "NODE_TYPICAL_OVERALL"}. After that configure the individual interfaces
and connections. Finally configure additional features such as
firewalling, modem sharing, routing, manual routes etc.


 @{" Overall configuration " Link "NODE_TYPICAL_OVERALL"}                                                        Overall configuration
 @{" PPP dial-up Internet access " Link "NODE_TYPICAL_PPPDIALUP"}                                                  PPP dial-up Internet access
 @{" SLIP nullmodem connection to another Amiga " Link "NODE_TYPICAL_SLIP"}                                   SLIP nullmodem connection to another Amiga
 @{" PPP nullmodem connection to a Windows-95/98 PC " Link "NODE_TYPICAL_PPPWIN"}                               PPP nullmodem connection to a Windows-95/98 PC
 @{" PPP nullmodem connection to a Windows-NT 4.0 PC " Link "NODE_TYPICAL_PPPNT"}                              PPP nullmodem connection to a Windows-NT 4.0 PC
 @{" Ethernet connection to a LAN " Link "NODE_TYPICAL_LAN"}                                                 Ethernet connection to a LAN
 @{" Cable/DSL connection via Ethernet, static IP or DHCP " Link "NODE_TYPICAL_DSLSTATIC"}                         Cable/DSL connection via Ethernet, static IP or DHCP
 @{" Cable/DSL connection via Ethernet, PPPoE " Link "NODE_TYPICAL_DSLPPPOE"}                                     Cable/DSL connection via Ethernet, PPPoE
 @{" Cable/DSL connection via Ethernet, VPN (PPTP/L2TP) " Link "NODE_TYPICAL_DSLVPN"}                           Cable/DSL connection via Ethernet, VPN (PPTP/L2TP)


@EndNode

@Node "NODE_TYPICAL_OVERALL" "MiamiDx.guide/NODE_TYPICAL_OVERALL"
@Next "NODE_TYPICAL_PPPDIALUP"
@Toc "NODE_TYPICAL"

Overall configuration
=====================

   The overall configuration affects those parts of MiamiDx that are not
part of any individual interface configuration, i.e. which are not set
to suitable values in any of the scenarios below. If you import settings
files from Miami or MiamiInit then the overall configuration is
automatically set for you. You only need to set it manually if you
configure your interfaces manually as well. Here is how to set the
overall configuration:

   @{b}*@{ub} Switch to the "TCP/IP" page and enter your default host name. If
     you have a well-known host name on the Internet then use that,
     otherwise enter "localhost" or a dummy host name.

   @{b}*@{ub} Next, still on the "TCP/IP" page enter your real name (e.g. "John
     Doe") and the user name you want to use on your local Amiga (e.g.
     "jdoe"). Real name and user name are never sent to any servers by
     MiamiDx. They are only used if you want to run your own servers
     (ftpd, telnetd etc.) on your Amiga, and some applications (email,
     IRC) use them as default values for their own configuration.

   @{b}*@{ub} Still on the "TCP/IP" page, "Ping flood detection" and "T/TCP"
     should usually be enabled, "Allow source routing" should be
     disabled, "Gateway" should be enabled only if you intend to use
     your Amiga as a gateway (router). Please see @{"TCP/IP" Link "NODE_CONFIG_TCPIP"} for more
     information on these options.

   @{b}*@{ub} Switch to the "Database" page and select the "Groups" table.
     Create a group with group name="users", group id=`100' and users
     set to the user name you defined on the TCP/IP page ("jdoe" in the
     example).

   @{b}*@{ub} In the same table create a group with a group name="wheel", a
     group id="0" and an users="root".

   @{b}*@{ub} Still on the "Database" page select the "Users" table. Create a
     user with a user name corresponding the one defined on the
     "TCP/IP" page ("jdoe in the example"). Set the user id to 100, the
     group id to 100, the real name to the real name you configured on
     the TCP/IP page ("John Doe" in the example), set the home dir to
     the home directory you want to use (e.g. "Work:" or "SYS:").
     "Shell" should remain empty for now. You can also enter a password
     at this time, but it will not be used unless/until you use a
     server (e.g. ftp or telnet) on your Amiga.

   @{b}*@{ub} In the same table create a user with user name="root", user
     id="0", group id="0", real name="administrator" (or anything you
     want), and a home directory of your choice, e.g. "SYS:". It is
     good style not to allow any external logins to "root" at all, so
     you should disable logins by entering a password of "*".


@EndNode

@Node "NODE_TYPICAL_PPPDIALUP" "MiamiDx.guide/NODE_TYPICAL_PPPDIALUP"
@Next "NODE_TYPICAL_SLIP"
@Prev "NODE_TYPICAL_OVERALL"
@Toc "NODE_TYPICAL"

PPP dial-up Internet access
===========================

   It is very strongly recommended that you use MiamiInit to configure
interfaces used for PPP dial-up Internet access. That is far easier and
safer than doing it manually. Nevertheless, here is the description of
a manual configuration:

   @{b}*@{ub} Switch to the "Hardware" page and create a hardware entry of type
     "Serial".  Set the "Name" to something meaningful to identify the
     serial device (e.g.  "SER").

   @{b}*@{ub} If you want to use the internal serial port then set "Type" to
     "built-in serial driver", otherwise select the driver and unit
     number of your serial board.

   @{b}*@{ub} Enable "Use CD" for now. You may have to disable it later if your
     modem does not support it.

   @{b}*@{ub} Set "Speed" appropriately. You usually want to use 38400 or 57600
     for the internal serial port, but higher values (e.g. 115200) for
     serial boards.

   @{b}*@{ub} In "Modem settings" set "Dial prefix" to something suitable for
     your phone system, usually "ATDT" or "ATDP". Please see
     @{"Dial prefix" Link "NODE_CONFIG_OTHER_HWMODEM_PREFIX"} for more information on this.

   @{b}*@{ub} After clicking "OK" twice to close the windows switch to the
     "Dialer" page. Create a new dialer, and set the name to something
     meaningful to identify your Internet provider. Add the phone
     numbers of your ISP and the login name and password you have to
     use for your ISP, then click "OK" to close the window.

   @{b}*@{ub} Switch to the "Interface" page and create a interface of type "PPP
     dial-out" and "Internet". Select the hardware and dialer entries
     you have just created.

   @{b}*@{ub} "IP type" and "Gateway type" should usually be set to "dynamic".

   @{b}*@{ub} Click on "TCP/IP" settings, set "Get dynamic host name, priority"
     to a non-zero value, set "Get dynamic DNS servers" to "add" and
     click "OK" twice to close both windows.

   @{b}*@{ub} Select the interface you just created, then click on "Teach". This
     will try to go online and verify that the dial script is working
     correctly.

   There is a good chance that something will go wrong when going
online, e.g.  that no DNS servers can be found (you need to configure
them manually), that no host name can be found (make sure DNS servers
are added or configure a static host name if necessary), that the modem
does not react at all (hardware problem or unsuitable interface speed)
etc.  If you cannot correct the problem yourself then you may want to
consider using MiamiInit after all. It knows about the most common
causes of problems and corrects them automatically.


@EndNode

@Node "NODE_TYPICAL_SLIP" "MiamiDx.guide/NODE_TYPICAL_SLIP"
@Next "NODE_TYPICAL_PPPWIN"
@Prev "NODE_TYPICAL_PPPDIALUP"
@Toc "NODE_TYPICAL"

SLIP nullmodem connection to another Amiga
==========================================

   First decide which IP addresses you want to use for your Amigas.
Also, if one of the two Amigas is supposed to act as a router to the
Internet (or to some other network) for the Amiga then you should make
up your mind now which of the two Amigas you want to use for that,
because it affects the configuration of the SLIP connection.

   Make sure that the null-modem cable you use is a 7-wire (NOT 3-wire)
cable, with the following wiring (pin numbers refering to DB-25
connectors):

      2 -  3
      3 -  2
      4 -  5
      5 -  4
      6 - 20
      7 -  7
     20 -  6

   Configure each Amiga in the following way:

   @{b}*@{ub} Switch to the "Hardware" page and create a hardware entry of type
     "Serial".  Set the "Name" to something meaningful to identify the
     serial device (e.g.  "SER").

   @{b}*@{ub} If you want to use the internal serial port then set "Type" to
     "built-in serial driver", otherwise select the driver and unit
     number of your serial board.

   @{b}*@{ub} Set the speed to a suitable value (has to be the same on both
     Amigas). Enable "Use CD". Click on "Modem settings", enable "Null
     modem" and click "OK"

   @{b}*@{ub} After clicking "OK" to close the windows switch to the "Dialer"
     page. Create a new dialer, and set the name to something
     meaningful (e.g. "NULL").  Click "OK" to close the window.

   @{b}*@{ub} Switch to the "Interface" page and create an interface of type
     "(C)SLIP dial-out".  Choose "Internet" if the OTHER Amiga is
     acting as the Internet router. Choose "LAN" if THIS Amiga is
     acting as the Internet router, or if none of the two Amigas has an
     Internet connection (i.e. if you are just connecting the two
     Amigas, without outside connection).

   @{b}*@{ub} Set "IP address" to the IP address of THIS Amiga and "Gateway" to
     the IP address of the OTHER Amiga. If the other Amiga acts as an
     Internet router then set "Gateway Pri" to a non-zero value,
     otherwise leave it at zero.

   At this point both Amigas are ready to go online. After that you
should be able to ping (see @{"MiamiPing" Link "NODE_UTILITY_PING"} the other Amiga.

   If one of the two Amigas acts as an Internet router then you still
need to enter a host name (on the TCP/IP page) and the DNS servers of
your Internet provider (in Database->DNS servers) on the other Amiga,
i.e. on the Amiga that does NOT act as an Internet router.

   You may also want to read @{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} and
@{"Modem sharing" Link "NODE_CONCEPTS_SHARING"} for more information how to configure the router.


@EndNode

@Node "NODE_TYPICAL_PPPWIN" "MiamiDx.guide/NODE_TYPICAL_PPPWIN"
@Next "NODE_TYPICAL_PPPNT"
@Prev "NODE_TYPICAL_SLIP"
@Toc "NODE_TYPICAL"

PPP nullmodem connection to a Windows-95/98 PC
==============================================

   First decide which IP addresses you want to use for the two machines.
Also, if one of the machines is supposed to act as a router to the
Internet (or to some other network) for the other one then you should
make up your mind now which of the two machine you want to use for
that, because it affects the configuration of the PPP connection.

   Make sure that the null-modem cable you use is a 7-wire (NOT 3-wire)
cable, with the following wiring (pin numbers refering to DB-25
connectors):

      2 -  3
      3 -  2
      4 -  5
      5 -  4
      6 - 20
      7 -  7
     20 -  6


 @{" Configuring the Amiga " Link "NODE_TYPICAL_PPPWIN_AMIGA"}                              Configuring the Amiga
 @{" Configuring the Windows PC " Link "NODE_TYPICAL_PPPWIN_PC"}                         Configuring the Windows PC

   After configuring both machines you are ready to go online. First go
online with the Amiga, then with the PC. After that you should be able
to ping (see @{"MiamiPing" Link "NODE_UTILITY_PING"} the other machine.

   If one of the two machines is supposed to act as an Internet router
then you still need to enter a host name and the DNS servers of your
Internet provider on the other machine, i.e. on the machine that does
NOT act as an Internet router.

   If you are using the Amiga as a router then you may also want to read
@{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} and @{"Modem sharing" Link "NODE_CONCEPTS_SHARING"} for more information how to
configure the router.


@EndNode

@Node "NODE_TYPICAL_PPPWIN_AMIGA" "MiamiDx.guide/NODE_TYPICAL_PPPWIN_AMIGA"
@Next "NODE_TYPICAL_PPPWIN_PC"
@Toc "NODE_TYPICAL_PPPWIN"

Configuring the Amiga
---------------------

   @{b}*@{ub} Switch to the "Hardware" page and create a hardware entry of type
     "Serial".  Set the "Name" to something meaningful to identify the
     serial device (e.g.  "SER").

   @{b}*@{ub} If you want to use the internal serial port then set "Type" to
     "built-in serial driver", otherwise select the driver and unit
     number of your serial board.

   @{b}*@{ub} Set the speed to a suitable value (has to be the same on both
     Amigas). Enable "Use CD" and set the MTU to 1500. Click on "Modem
     settings", enable "Null modem" and click "OK".

   @{b}*@{ub} After clicking "OK" to close the windows switch to the "Dialer"
     page. Create a new dialer, and set the name to something
     meaningful (e.g. "NULL").  Click "OK" to close the window.

   @{b}*@{ub} Switch to the "Interface" page and create an interface of type
     "PPP dial-out".  Choose "Internet" if the PC is acting as the
     Internet router. Choose "LAN" if the Amiga is acting as the
     Internet router, or if none of the two machines has an Internet
     connection (i.e. if you are just connecting the two machines,
     without outside connection).

   @{b}*@{ub} Set "IP address" to the IP address of the Amiga and "Gateway" to
     the IP address of the PC. If the PC acts as an Internet router
     then set "Gateway Pri" to a non-zero value, otherwise leave it at
     zero.


@EndNode

@Node "NODE_TYPICAL_PPPWIN_PC" "MiamiDx.guide/NODE_TYPICAL_PPPWIN_PC"
@Prev "NODE_TYPICAL_PPPWIN_AMIGA"
@Toc "NODE_TYPICAL_PPPWIN"

Configuring the Windows PC
--------------------------

   The description below roughly describes the steps necessary to
configure a Windows-95/98 PC for PPP across a nullmodem link. The
details may vary a little with different versions of Windows.

   @{b}*@{ub} Copy the file "Miami:PC/MDMCISCO.INF" to your PC.

   @{b}*@{ub} Open Settings->Control Panel, double-click on "Modems", select
     "Add", "Don't run the hardware installation wizard" and click on
     "Next".

   @{b}*@{ub} Select "Don't detect my modem; I will select it from a list" and
     click on "Next".

   @{b}*@{ub} Click on "Have Disk" and "Browse", then select "MDMCISCO.INF" and
     click on "OK" twice.

   @{b}*@{ub} Select "RAS Serial Cable between 2 PCs" and click on "Next".

   @{b}*@{ub} Select the correct serial port to which the nullmodem cable is
     connected, then click on "Next".

   @{b}*@{ub} Select "RAS Serial Cable between 2 PCs", click on "Properties", set
     the speed to the same value you used on the Amiga, then click on
     "OK".

   @{b}*@{ub} Click on "Close" to finish the modem configuration.

   @{b}*@{ub} Open My Computer->Dial-Up Networking, double-click on "Make New
     Connection".

   @{b}*@{ub} Change the computer name to something meaningful, e.g. "Amiga".
     Select the device "RAS Serial Cable between 2 PCs" and click on
     "Next".

   @{b}*@{ub} Type anything you want for the phone number and click on "Next".

   @{b}*@{ub} Click on "Finish".

   @{b}*@{ub} Right-click on the newly created dial-up icon and select
     "Properties" from the menu.

   @{b}*@{ub} Select the "Server types" tab, disable all "advanced options". In
     "allowed network protocols" select only "TCP/IP". Click on "TCP/IP
     settings". Click on "Specify an IP address" and enter the IP
     address of the PC.

   @{b}*@{ub} Close all windows to finish the configuration.


@EndNode

@Node "NODE_TYPICAL_PPPNT" "MiamiDx.guide/NODE_TYPICAL_PPPNT"
@Next "NODE_TYPICAL_LAN"
@Prev "NODE_TYPICAL_PPPWIN"
@Toc "NODE_TYPICAL"

PPP nullmodem connection to a Windows-NT 4.0 PC
===============================================

   Below is the description how to configure the PC. The details may
vary a little depending on your NT configuration, version and service
pack. You may also have to add services or network adapters if you have
not already done so during your initial NT installation.

   For all other parts of the setup please see
@{"PPP nullmodem connection to a Windows-95/98 PC" Link "NODE_TYPICAL_PPPWIN"}, except when configuring
IP addresses on your Amiga set both the IP address and the Gateway type
to "dynamic". The IP address range will be configured directly in NT.

   @{b}*@{ub} Open Settings->Control Panel and double-click on "Network". Choose
     the "Services" tab, then "Remote Access Service", click on
     "Properties", "Add", select "RAS Serial Cable between 2 PCs" or
     "Generic NULL modem" with the proper port, click on "OK".

   @{b}*@{ub} Click on "Configure" and select "Dial-out only", click on "Network"
     and make sure exactly "TCP/IP" and "Allow any authentication
     including clear text" are selected.

   @{b}*@{ub} Click on the TCP/IP "Configure" switch, set the IP address range
     to a range of which contains the IP addresses you want to assign
     to both machines.

   @{b}*@{ub} Click on "OK" twice, then "Close". Click on "Continue" and
     "Close". Restart the PC when prompted to do so.


@EndNode

@Node "NODE_TYPICAL_LAN" "MiamiDx.guide/NODE_TYPICAL_LAN"
@Next "NODE_TYPICAL_DSLSTATIC"
@Prev "NODE_TYPICAL_PPPNT"
@Toc "NODE_TYPICAL"

Ethernet connection to a LAN
============================

   First determine which IP address and netmask you want to use. If you
are connecting to an existing LAN then the system administrator will
tell you the netmask and assign an IP address to your Amiga. If you are
creating a new, private LAN then you can use any IP address range you
want. For compatibility with the Internet (in case you ever want to
connect the LAN to the Internet) you should use the IP address range
192.168.1.x, with 1 <= x <= 254.

   If one of the machines on the LAN acts as a router to the Internet
then you need to know its IP address so you can later configure it as
the "default gateway" on all other machines in the LAN.

   To configure the Ethernet LAN connection execute the following steps:

   @{b}*@{ub} Select the "Hardware" page, click on "New", choose "Ethernet", and
     enter a meaningful name for your Ethernet hardware (e.g. the name
     of the network board you are using). Then select either "SANA-II
     driver" or "MNI driver" depending on which type of driver you want
     to use. There is more information on MNI drivers in
     @{"MNI Ethernet drivers" Link "NODE_SPECIFICATIONS_MNI"}.

   @{b}*@{ub} If you want to use an MNI driver with your Ethernet board do the
     following:
        - Select "MNI driver", Click on the "Driver" popup gadget and
          select the correct driver for your Ethernet board. For a list
          of boards and required drivers see @{"MNI Ethernet drivers" Link "NODE_SPECIFICATIONS_MNI"}. That
          section also tells you whether you need to specify any "MNI
          options".

        - Select "Find boards", select your board from the list and
          click on "OK".  This sets the unit number correctly. Click on
          "MNI parameters", "Query device", and "OK".

   @{b}*@{ub} If you want to use a SANA-II driver with your Ethernet board do
     the following:
        - Most SANA-II drivers require a configuration file, usually
          stored in the environment variable ENV:SANA2/unitname.config
          (with unitname depending on your driver). Please see the
          documentation that comes with the SANA-II driver for more
          information how to set up that configuration file.

        - Select "SANA-II driver". Click on the "Driver" popup gadget
          and select the correct driver for your Ethernet board. Then
          set the unit number correctly.  Please see the documentation
          that comes with the SANA-II driver for more information which
          unit numbers are supported by the driver.

        - Click on "SANA-II parameters", "Query device" and "OK".

   @{b}*@{ub} Click on "OK" to close the hardware definition window.

   @{b}*@{ub} Select the "Interface" page, click on "New", and choose "Ethernet".
     Choose "Internet" if another machine on the LAN is acting as the
     Internet router.  Choose "LAN" if the Amiga is acting as the
     Internet router, or if none of the machines on the LAN has an
     Internet connection. Then click on "OK".

   @{b}*@{ub} Select the hardware definition you just created from the list.

   @{b}*@{ub} Enter the IP address and netmask. If one of the machines on the
     LAN acts as a gateway to the Internet (default router) then set
     the Gateway priority to a non-zero value and enter the IP address
     of the gateway.

   @{b}*@{ub} If you want your Ethernet interface to automatically go online
     whenever you start MiamiDx then click on "Events", enable "Start
     -> Auto-online", and click on "OK".

   @{b}*@{ub} Click on "OK" to close the hardware definition window.

   @{b}*@{ub} You are now ready to go online: select the new interface from the
     list and click on "Onl".

   If one of the machines on the LAN acts as an Internet router then
you still need to enter a host name (on the TCP/IP page) and the DNS
servers of your Internet provider (in Database->DNS servers).

   You may also want to read @{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} and
@{"Modem sharing" Link "NODE_CONCEPTS_SHARING"} for more information how to configure the router.


@EndNode

@Node "NODE_TYPICAL_DSLSTATIC" "MiamiDx.guide/NODE_TYPICAL_DSLSTATIC"
@Next "NODE_TYPICAL_DSLPPPOE"
@Prev "NODE_TYPICAL_LAN"
@Toc "NODE_TYPICAL"

Cable/DSL connection via Ethernet, static IP or DHCP
====================================================

   The configuration of a cable/DSL connection via Ethernet with static
IP or DHCP is almost identical to the configuration of a LAN connection
via Ethernet, so please follow the instructions in
@{"Ethernet connection to a LAN" Link "NODE_TYPICAL_LAN"}.

   A few additional hints:

   @{b}*@{ub} Before starting the configuration ask your Internet service
     provider for all necessary information. For DSL connections with
     static IPs you will need to know your own IP address, the netmask,
     the default gateway and the IP addresses of one or more DNS
     servers. For DSL connections with DHCP your own IP address is
     dynamic, but the netmask, default gateway, and/or DNS servers may
     still be static. Ask your Internet provider if these values are
     fixed and, if so, find out the correct values.

   @{b}*@{ub} When configuring the Ethernet interface always choose "Internet",
     not "LAN".

   @{b}*@{ub} If one or more of the items "IP address", "netmask" and "gateway"
     are dynamic, determined by DHCP, then during the interface
     configuration set the corresponding switch ("IP type", "Netmask
     type" or "Gateway type") to "DHCP".

   @{b}*@{ub} If DNS servers are dynamic, determined by DHCP, then during the
     interface configuration select "TCP/IP settings", set "Get dynamic
     DNS servers" to "add" and select "DHCP -> Enable".

   @{b}*@{ub} Some Internet providers use Windows-NT servers as DHCP servers
     which require you to ask for your IP address based on your
     "computer name".  If that is the case then during the interface
     configuration select "TCP/IP settings", select "DHCP -> Enable" and
     "DHCP -> Send host name in request" and enter the computer name you
     registered under with your Internet provider in "DHCP -> Host
     name".

   @{b}*@{ub} If you know the addresses of DNS servers then add them in
     "Database->DNS servers".

   You may also want to read @{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} and
@{"Modem sharing" Link "NODE_CONCEPTS_SHARING"} if you want your Amiga to act as a router between the
cable/DSL line and another LAN.


@EndNode

@Node "NODE_TYPICAL_DSLPPPOE" "MiamiDx.guide/NODE_TYPICAL_DSLPPPOE"
@Next "NODE_TYPICAL_DSLVPN"
@Prev "NODE_TYPICAL_DSLSTATIC"
@Toc "NODE_TYPICAL"

Cable/DSL connection via Ethernet, PPPoE
========================================

   The first step in the configuration of a cable/DSL connection using
PPPoE is the configuration of the hardware part of the Ethernet
interface. Please see @{"Ethernet connection to a LAN" Link "NODE_TYPICAL_LAN"} for more information
on this, but only follow those instructions up to the point when you
have created the hardware entry (i.e. when you have closed the hardware
definition window). After that do the following:

   @{b}*@{ub} Select the "Interface" page, click on "New", and choose "Ethernet"
     and "LAN", then click on "OK".

   @{b}*@{ub} Select the hardware definition you just created from the list.

   @{b}*@{ub} If you want to use the Ethernet for a LAN (as well as for the
     PPPoE connection to the Internet), then decide on an IP address
     range and netmask. You could e.g.  use 192.168.1.1 as the IP
     address for your Amiga, with a netmask of 255.255.255.0.  Then
     enter the IP address and netmask. Leave the "Gateway priority"
     switch at its default (0).

   @{b}*@{ub} If you configured an IP address and gateway in the previous step
     then you probably want this LAN interface to be online at all
     times. To do this click on "Events", enable "Start ->
     Auto-online", and click on "OK" twice, then select the interface
     and click on "Onl". Otherwise just click on "OK" to close the
     interface definition window.

   @{b}*@{ub} Next you need to create the PPPoE interface. First select the
     "Hardware" page, click on "New" and "Serial". Set the name to
     something meaningful (e.g. "PPPoE"), and change the following
     settings: set the device name to "Miami:devs/miamipppoe.device",
     the unit to 0, enable "Use CD", and set the MTU to 1492.

   @{b}*@{ub} Click on "Modem settings", set "DTR mode" to "hangup" and set the
     "dial prefix" to "ATD". Then click on "OK" twice to go back to the
     main window.

   @{b}*@{ub} Now a dialer entry needs to be created: select the "Dialer" page,
     click on "New", set the name to something meaningful (e.g. to the
     name of your ISP), click on "Phone numbers->Add" once to create
     one phone number entry.  You can leave the phone number itself
     blank. Click on "OK" to close the dialer definition window.

   @{b}*@{ub} Finally you need to create an interface entry for PPPoE. Select the
     "Interfaces" page and click on "New". Select "PPP dial-out" and
     "Internet", then select the hardware and dialer definitions you
     just created.

   @{b}*@{ub} In the interface definition window set "IP type" and "Gateway type"
     to "dynamic". Open the "PPP settings" window. If your ISP uses
     loginname/password verification then disable "same as in dialer"
     and enter your loginname and password. Some ISPs may also require
     "Use MS-CHAP" to be enabled. Please note that a lot of PPPoE ISPs
     have unusual requirements for the login name. They are often
     different from the user name you signed up with. Please check with
     your ISP or check the Amiga DSL FAQ on www.nordicglobal.com for
     more information on this.

   @{b}*@{ub} Close the "PPP settings" window, open the "TCP/IP settings" window,
     and set "Get dynamic host name priority" to a non-zero value. Then
     close the TCP/IP settings window.

   @{b}*@{ub} Next configure DNS. If your ISP supports dynamic DNS configuration
     then you could configure the PPP interface for "TCP/IP -> get
     dynamic DNS servers = add" (in the "TCP/IP settings" window).
     However with DSL it is usually better to use a static DNS
     configuration, in particular if you want to use dial on demand.
     This means close the interface definition window and add the DNS
     servers your ISP told you in "Database -> DNS servers".

   @{b}*@{ub} Finally you need to configure PPPoE and map it to the correct
     Ethernet interface. The default is "eth0", so if the name of your
     Ethernet interface is "eth0" then you don't have to manually
     configure PPPoE at all. If the name of your Ethernet interface is
     different from "eth0" then create a text file
     "Miami:data/MiamiPPPoE.config" in your favorite text editor and
     add the following line to that file:

          interface eth1

     (or whatever the name of your Ethernet interface is).

   You are now ready to go online with your PPPoE interface.  You may
also want to read @{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} and @{"Modem sharing" Link "NODE_CONCEPTS_SHARING"} if you
want your Amiga to act as a router between the cable/DSL line and
another LAN.


@EndNode

@Node "NODE_TYPICAL_DSLVPN" "MiamiDx.guide/NODE_TYPICAL_DSLVPN"
@Prev "NODE_TYPICAL_DSLPPPOE"
@Toc "NODE_TYPICAL"

Cable/DSL connection via Ethernet, VPN (PPTP/L2TP)
==================================================

   PPTP/L2TP-based DSL connections require you to configure an Ethernet
connection to a PPTP/L2TP server located in a DSL/cable modem connected
to your Amiga by Ethernet. Before starting the configuration you need to
ask your Internet provider for the IP address the DSL/cable modem uses.
You can also use the Ethernet for LAN, i.e. to hook up other machines to
your Amiga. To do this define an IP address range that contains the IP
address of the DSL modem, e.g. if the DSL modem has the IP address
192.168.5.20 then you could define your private IP address range to be
192.168.5.0 with a netmask of 255.255.255.0. You Amiga could use the IP
address 192.168.5.1 in this example.

   The first step in the configuration of a cable/DSL connection using
PPTP/L2TP is the configuration of the hardware part of the Ethernet
interface. Please see @{"Ethernet connection to a LAN" Link "NODE_TYPICAL_LAN"} for more information
on this, but only follow those instructions up to the point when you
have created the hardware entry (i.e. when you have closed the hardware
definition window). After that do the following:

   @{b}*@{ub} Select the "Interface" page, click on "New", and choose "Ethernet"
     and "LAN", then click on "OK".

   @{b}*@{ub} Select the hardware definition you just created from the list.

   @{b}*@{ub} Enter the IP address and netmask of your Amiga. Leave the "Gateway
     priority" switch at its default (0).

   @{b}*@{ub} You probably want this LAN interface to be online at all times. To
     do this click on "Events", enable "Start -> Auto-online", and
     click on "OK" twice, then select the interface and click on "Onl".
     Otherwise just click on "OK" to close the interface definition
     window.

   @{b}*@{ub} Next you need to create the PPTP/L2TP interface. First select the
     "Hardware" page, click on "New" and "Serial". Set the name to
     something meaningful (e.g. "PPTP"), and change the following
     settings: set the device name to "Miami:devs/miamipptp.device"
     (for PPTP) or "Miami:devs/miamil2tp.device" (for L2TP). Set the
     unit to 0, enable "Use CD", and set the MTU to 1460 (for PPTP) or
     1448 (for L2TP).

   @{b}*@{ub} Click on "Modem settings", set "DTR mode" to "hangup" and set the
     "dial prefix" to "ATD". Then click on "OK" twice to go back to the
     main window.

   @{b}*@{ub} Now a dialer entry needs to be created: select the "Dialer" page,
     click on "New", set the name to something meaningful (e.g. to the
     name of your ISP), click on "Phone numbers->Add" once to create
     one phone number entry.  Enter the host name or IP address of the
     PPTP/L2TP server (DSL/cable modem).  Click on "OK" to close the
     dialer definition window.

   @{b}*@{ub} Finally you need to create an interface entry for PPPoE. Select the
     "Interfaces" page and click on "New". Select "PPP dial-out" and
     "Internet", then select the hardware and dialer definitions you
     just created.

   @{b}*@{ub} In the interface definition window set "IP type" and "Gateway type"
     to "dynamic". Open the "PPP settings" window. If your ISP uses
     loginname/password verification then disable "same as in dialer"
     and enter your loginname and password. Some ISPs may also require
     "Use MS-CHAP" to be enabled. Please note that a lot of PPTP/L2TP
     ISPs have unusual requirements for the login name. They are often
     different from the user name you signed up with. Please check with
     your ISP or check the Amiga DSL FAQ on www.nordicglobal.com for
     more information on this.

   @{b}*@{ub} Close the "PPP settings" window, open the "TCP/IP settings" window,
     and set "Get dynamic host name priority" to a non-zero value. Then
     close the TCP/IP settings window.

   @{b}*@{ub} Next configure DNS. If your ISP supports dynamic DNS configuration
     then you could configure the PPP interface for "TCP/IP -> get
     dynamic DNS servers = add" (in the "TCP/IP settings" window).
     However with DSL it is usually better to use a static DNS
     configuration, in particular if you want to use dial on demand.
     This means close the interface definition window and add the DNS
     servers your ISP told you in "Database -> DNS servers".

   @{b}*@{ub} If you are using PPTP then your configuration is finished now. If
     you are using L2TP and your provider requires the use of challenge
     authentication using a "shared secret" then create a text file
     "Miami:data/MiamiL2TP.config" in your favorite text editor and add
     the following line to that file:

          secret mysharedsecret

     (where "mysharedsecret" is the shared secret your L2TP server needs
     for your host).

   You are now ready to go online with your PPTP/L2TP interface.  You
may also want to read @{"Using multiple interfaces" Link "NODE_CONCEPTS_MULTI"} and @{"Modem sharing" Link "NODE_CONCEPTS_SHARING"} if
you want your Amiga to act as a router between the cable/DSL line and
another LAN.


@EndNode

@Node "NODE_REFERENCE" "MiamiDx.guide/NODE_REFERENCE"
@Next "NODE_CONFIG"
@Prev "NODE_TYPICAL"
@Toc "Main"

Reference
*********


 @{" ToolTypes " Link "NODE_REFERENCE_TOOLTYPES"}                                    ToolTypes for MiamiDx
 @{" Menus " Link "NODE_REFERENCE_MENUS"}                                        Program menus


@EndNode

@Node "NODE_REFERENCE_TOOLTYPES" "MiamiDx.guide/NODE_REFERENCE_TOOLTYPES"
@Next "NODE_REFERENCE_MENUS"
@Toc "NODE_REFERENCE"

ToolTypes
*********

   MiamiDx supports the following ToolTypes when started from Workbench
(or arguments when started from the Shell):

@{b}PACKETDEBUG@{ub}
     Initiates packet-level debugging mode. If you specify
     "PACKETDEBUG=10" or "PACKETDEBUG=20" then MiamiDx creates files
     "MiamiDx.debug.<if>" (where <if> is replaced with the interface
     name) for each interface with a hex dump of all sent and received
     packets. You should only use this during debugging, not during
     normal operation, because these logs grow very quickly and consume
     a lot of CPU time. A value of 10 logs packet payloads only. A
     value of 20 also logs raw packet data (for PPP/SLIP).

@{b}DONTCONNECT@{ub}
     If you have configured MiamiDx to automatically connect to your
     Internet provider whenever you start MiamiDx, then you can use
     this ToolType to override that behavior, giving you a chance to
     change some settings before you connect.

@{b}SETTINGS@{ub}
     Any project icon needs to have a "SETTINGS" ToolType so MiamiDx
     recognizes it as a settings file. From the Shell you can use the
     argument "SETTINGS=filename" to specify the settings file to load.

@{b}AREXX@{ub}
     The argument "AREXX=filename" tells MiamiDx to execute the
     specified ARexx script upon startup.

@{b}PUBSCREEN@{ub}
     The argument "PUBSCREEN=name" sets the public screen you want
     MiamiDx to open on. Note that the MUI modules have their own
     method of configuring screens, through MUI.

@{b}GUI@{ub}
     The argument "GUI=name" tells MiamiDx which GUI engine to use for
     the user interface. This overrides any user interface choise in the
     settings file.

@{b}NOGUI@{ub}
     The argument "NOGUI" causes MiamiDx to start up without showing the
     user interface.

   DO NOT attempt to use undocumented ToolTypes ! Such ToolTypes usually
do not do what you expect them to do, and might reduce the compatibility
or performance of MiamiDx.


@EndNode

@Node "NODE_REFERENCE_MENUS" "MiamiDx.guide/NODE_REFERENCE_MENUS"
@Prev "NODE_REFERENCE_TOOLTYPES"
@Toc "NODE_REFERENCE"

Menus
=====

   Description of all menu items:

@{b}Project/About...@{ub}
     Show information about MiamiDx.

@{b}Project/About MUI...@{ub}
     Show information about MUI (Magic User Interface). This menu item
     is only available when using one of the MUI user interface modules.

@{b}Project/Inhibit auto-connect@{ub}
     If this menu item is checkmarked then the auto-connect function is
     temporarily disabled for all interfaces, allowing you to keep
     interfaces offline and edit their settings and to prevent
     interfaces from accidentally being taken online by spurious
     traffic.

@{b}Project/Iconify@{ub}
     Iconify all windows of MiamiDx. Note that for some interface
     modules this function may be identical to `Project/Kill GUI'.

@{b}Project/Kill GUI@{ub}
     Iconify all windows of MiamiDx and unload the GUI module from
     memory.

@{b}Project/Window to front@{ub}
     Moves the MiamiDx main window to the front of the screen.

@{b}Project/Control panel to front@{ub}
     Moves the MiamiDx control panel to the front of the screen.

@{b}Project/Offline without hangup@{ub}
     Go offline without hanging up the modem line first.

@{b}Project/Quit without hangup...@{ub}
     Leave MiamiDx without hanging up the modem line first.

@{b}Project/Quit...@{ub}
     Leave MiamiDx.

@{b}Settings/Load...@{ub}
     Load a settings file.

@{b}Settings/Save@{ub}
     Save the current settings into the current settings file.

@{b}Settings/Save as...@{ub}
     Save the current settings into a new settings file.

@{b}Settings/Save as default@{ub}
     Save the current settings as the default for MiamiDx.

@{b}Settings/Create icon@{ub}
     Create a project icon for each settings file saved.

@{b}Settings/Import settings from MiamiInit V3...@{ub}
     Import a settings file from MiamiInit version 3. Please note that
     this function imports @{i}all@{ui} settings from MiamiInit and in the
     process deletes all already defined interfaces in MiamiDx. This is
     the function to use when you start using MiamiDx and import your
     first ever settings file from MiamiInit.

@{b}Settings/Import interface from MiamiInit V3...@{ub}
     Import a settings file from MiamiInit version 3, importing only
     the interface definition and adding it to the list of existing
     interfaces. Other parts of the settings are not changed. Use this
     function if you already have a working MiamiDx config and want to
     add a new interface to the list.

@{b}Settings/Encrypt passwords@{ub}
     If this menu item is checkmarked then MiamiDx encrypts all
     passwords when saving the settings. Passwords are encrypted using
     a passphrase that you need to enter when saving the file. The same
     passphrase has to be entered whenever the settings file is loaded
     in order to decrypt the passwords again.

@{b}Settings/Change passphrase...@{ub}
     Change the passphrase MiamiDx uses to encrypt passwords in
     settings files.

@{b}Settings/MUI Settings...@{ub}
     Open the MUI configuration window. This menu item is only
     available when using one of the MUI user interface modules.


@EndNode

@Node "NODE_CONFIG" "MiamiDx.guide/NODE_CONFIG"
@Next "NODE_SPECIFICATIONS"
@Prev "NODE_REFERENCE"
@Toc "Main"

Configuration details
*********************

   The configuration of MiamiDx is done completely through the graphical
user interface. This part of the documentation describes all parts of
the user interface that are directly reachable from the main window.
MiamiDx displays several other dialog windows at various times. They
are described in @{"Other dialog windows" Link "NODE_CONFIG_OTHER"}.


 @{" General " Link "NODE_CONFIG_GENERAL"}                                 The `General' page
 @{" Hardware " Link "NODE_CONFIG_HARDWARE"}                                The `Hardware' page
 @{" Dialer " Link "NODE_CONFIG_DIALER"}                                  The `Dialer' page
 @{" Interfaces " Link "NODE_CONFIG_INTERFACES"}                              The `Interfaces' page
 @{" Database " Link "NODE_CONFIG_DATABASE"}                                The `Database' page
 @{" TCP/IP " Link "NODE_CONFIG_TCPIP"}                                  The `TCP/IP' page
 @{" Events " Link "NODE_CONFIG_EVENTS"}                                  The `Events' page
 @{" Logging " Link "NODE_CONFIG_LOGGING"}                                 The `Logging' page
 @{" Windows " Link "NODE_CONFIG_WINDOWS"}                                 The `Windows' page
 @{" GUI " Link "NODE_CONFIG_GUI"}                                     The `GUI' page
 @{" Socks " Link "NODE_CONFIG_SOCKS"}                                   The `Socks' page
 @{" Other dialog windows " Link "NODE_CONFIG_OTHER"}                    Other dialog windows


@EndNode

@Node "NODE_CONFIG_GENERAL" "MiamiDx.guide/NODE_CONFIG_GENERAL"
@Next "NODE_CONFIG_HARDWARE"
@Toc "NODE_CONFIG"

General
=======

   Not much here, except for the official MiamiDx logo and a gadget to
start the MiamiDx registration program.

   With some GUI modules (e.g. MUI) this page is selected by clicking
on "General" in the Listview. With other GUI modules the MiamiDx main
window always shows the contents of the "General" page, and other pages
pop up in subwindows.


 @{" Register " Link "NODE_CONFIG_GENERAL_REGISTER"}                                The `Register' gadget


@EndNode

@Node "NODE_CONFIG_GENERAL_REGISTER" "MiamiDx.guide/NODE_CONFIG_GENERAL_REGISTER"
@Toc "NODE_CONFIG_GENERAL"

Register
--------

   This gadget starts the program @{b}MiamiRegister@{ub}, allowing you to order
a MiamiDx license code, register MiamiDx or upgrade your registration.
@{b}MiamiRegister@{ub} has to be installed in the "Miami:" directory.


@EndNode

@Node "NODE_CONFIG_HARDWARE" "MiamiDx.guide/NODE_CONFIG_HARDWARE"
@Next "NODE_CONFIG_DIALER"
@Prev "NODE_CONFIG_GENERAL"
@Toc "NODE_CONFIG"

Hardware
========

   This page displays all currently defined hardware entries. You need
to define one entry for each hardware resource you want to use with
MiamiDx, i.e. for each modem, Ethernet board etc.

   The list displays the (user-defined) name of each hardware entry, its
type (e.g. "Ethernet" or "serial"), the number of references (i.e. the
number of interfaces that reference this hardware entry), and an
indicator whether the hardware is "in use" (marked by a centered "x").
A hardware resource is considered to be "in use" if an interface
referencing this hardware is currently using the hardware. This usually
means that the interface is online (or in an online/offline transition).

   The "New", "Copy" and "Del" gadgets allow you to create a new
hardware entry, copy (clone) the selected hardware entry or delete the
selected hardware entry. Hardware entries can only be selected if they
are not referenced ("Ref" count zero). If you want to delete a hardware
entry with non-zero references then you need to delete the Interface
entries which reference the hardware entry first.

   Clicking on "New" brings up the @{"Hardware type" Link "NODE_CONFIG_OTHER_HWTYPE"} dialog, which allows
you to select the type of hardware you want to add and then allows to
define the details (drivers etc.). Clicking on "Copy" creates an
identical clone of the current hardware entry and then allows you to
edit it in the @{"Hardware definition" Link "NODE_CONFIG_OTHER_HWDEF"} dialog. Clicking on "Edit" allows
you to edit the current hardware definition in the @{"Hardware definition" Link "NODE_CONFIG_OTHER_HWDEF"}
dialog. Please note that if you try to edit your hardware entry while
it is in use you may only be able to change a small subset of hardware
settings. To be able to change all hardware settings make sure that
your hardware entry is not in use, i.e. take the interface referencing
the hardware entry offline first.


@EndNode

@Node "NODE_CONFIG_DIALER" "MiamiDx.guide/NODE_CONFIG_DIALER"
@Next "NODE_CONFIG_INTERFACES"
@Prev "NODE_CONFIG_HARDWARE"
@Toc "NODE_CONFIG"

Dialer
======

   This page displays all currently defined dialer entries. You need to
define one dialer entry for each interface of type "PPP dial-out" or
"(C)SLIP dial-out".  Other interface types (Ethernet etc.) do not
require dialer entries.

   The list displays the (user-defined) name of each dialer entry, the
number of references (i.e. the number of interfaces that reference this
dialer entry), and an indicator whether the dialer is "in use" (marked
by a centered "x"). A dialer entry is considered to be "in use" only
while MiamiDx uses it to dial up a connection for an interface that
references the dialer entry. While those interfaces are online or
offline (i.e. not dialing) the dialer entry is not considered to be "in
use".

   The "New", "Copy" and "Del" gadgets allow you to create a new dialer
entry, copy (clone) the selected dialer entry or delete the selected
dialer entry. Dialer entries can only be selected if they are not
referenced ("Ref" count zero). If you want to delete a dialer entry
with non-zero references then you need to delete the Interface entries
which reference the dialer entry first.

   Clicking on "New" brings up the @{"Dialer definition" Link "NODE_CONFIG_OTHER_DIALERDEF"} dialog, which
allows you to define the details of the dialer entry (phone numbers,
dial script etc.).  Clicking on "Copy" creates an identical clone of
the current dialer entry and then allows you to edit it in the
@{"Dialer definition" Link "NODE_CONFIG_OTHER_DIALERDEF"} dialog. Clicking on "Edit" allows you to edit the
current dialer definition in the @{"Dialer definition" Link "NODE_CONFIG_OTHER_DIALERDEF"} dialog. Please note
that if you try to edit your dialer entry while it is in use you may
only be able to change a small subset of dialer settings. To be able to
change all dialer settings make sure that your dialer entry is not in
use, i.e. that the interfaces using it are not in the process of
dialing.


@EndNode

@Node "NODE_CONFIG_INTERFACES" "MiamiDx.guide/NODE_CONFIG_INTERFACES"
@Next "NODE_CONFIG_DATABASE"
@Prev "NODE_CONFIG_DIALER"
@Toc "NODE_CONFIG"

Interfaces
==========

   This section allows you to define and edit all interfaces you want
MiamiDx to use. Please note that before defining an interface entry you
first have to define its resources, i.e. a hardware entry in @{"Hardware" Link "NODE_CONFIG_HARDWARE"},
and for PPP or (S)LIP interfaces you also need to define a dialer entry,
in @{"Dialer" Link "NODE_CONFIG_DIALER"}.

   The list displays the (system-assigned) name of each interface, the
(user-defined) alias, the current status (usually "online", "offline",
or a transitionary state), the hardware entry referenced by this
interface and for PPP/(C)SLIP interfaces the dialer referenced by this
interface. The number in parentheses behind the hardware name indicates
the priority with which this interface entry references the hardware.
Please see @{"Interfaces hardware priority" Link "NODE_CONFIG_OTHER_IFACEDEF_HWPRI"} for more information on that.

   Usually one of the interfaces in your list is displayed with a
highlighted (bold-face) name. That interface is your "GUI default
interface". Please see @{"Interfaces GUI default" Link "NODE_CONFIG_OTHER_IFACEDEF_GUIDEFAULT"} for more information on
this.

   The "New", "Copy" and "Del" gadgets allow you to create a new
interface entry, copy (clone) the selected interface entry or delete
the selected interface entry.

   Clicking on "New" brings up the @{"Interface type" Link "NODE_CONFIG_OTHER_IFACETYPE"} dialog, which allows
you to select the type of interface you want to add and then allows to
define the details (drivers etc.). Clicking on "Copy" creates an
identical clone of the current interface entry and then allows you to
edit it in the @{"Interface definition" Link "NODE_CONFIG_OTHER_IFACEDEF"} dialog. Clicking on "Edit" allows
you to edit the current interface definition in the
@{"Interface definition" Link "NODE_CONFIG_OTHER_IFACEDEF"} dialog. Please note that if you try to edit your
interface entry while it is not offline you may only be able to change
a small subset of interface settings. To be able to change all
interface settings make sure that your interface entry is offline.

   The "Online" and "Offline" gadgets take your interface online and
offline, respectively. Depending on how you defined
@{"Interfaces TCP/IP Preferred offline State" Link "NODE_CONFIG_OTHER_IFACETCPIP_PREFERED"} an interface will either drop
to the "Suspended" or to the "Offline" state after clicking on
"Offline". While an interface is in the "Suspended" state clicking on
"Offline" again will take it completely offline. Please see
@{"Interfaces TCP/IP Preferred offline State" Link "NODE_CONFIG_OTHER_IFACETCPIP_PREFERED"} for more information on
"Offline" vs. "Suspended".

   The "Onl+GUI" gadget takes your interface online and also makes it
your GUI default interface, i.e. it is shorthand for first activating
@{"Interfaces GUI default" Link "NODE_CONFIG_OTHER_IFACEDEF_GUIDEFAULT"} and then clicking on "Online".

   The "Teach" button is only used with PPP and (C)SLIP interfaces, i.e.
interfaces that reference a dialer definition. With those interfaces the
"Teach" button allows you to connect to the PPP/(C)SLIP server
interactively and record a dialer script. This is a useful way to
create a suitable dial script, as an alternative to using MiamiInit, in
particular if your Internet provider just changed their setup and you
need to adjust the dial script, but don't want to go through a
completely new configuration.


@EndNode

@Node "NODE_CONFIG_DATABASE" "MiamiDx.guide/NODE_CONFIG_DATABASE"
@Next "NODE_CONFIG_TCPIP"
@Prev "NODE_CONFIG_INTERFACES"
@Toc "NODE_CONFIG"

Database
========

   The "Database" page is the equivalent of the files in the "db" or
"etc" directory for other TCP/IP protocol stacks, i.e. it allows you to
configure most of the TCP settings on your system, which daemons to
run, a list of users and other things.

   The cycle gadget on top of the listview is used to switch between
different parts of the database. For each part of the database you see
a listview and a set of string gadgets to modify the current entry.

   Using the context menu of the database listview gadget you can
import/export each part of the database from/to ASCII text files. This
allows you to continue to use your old AmiTCP/AS-225 @{b}db/#?@{ub} files with
MiamiDx.

   In the registered version you can also sort sections of a database,
import/export from/to the Clipboard, and merge the database with ASCII
files.

   With the MUI user interface modules you can rearrange entries of the
database by dragging them off the side of the listview and then moving
them back into the listview at their intended position. Please see the
MUI documentation for more information on drag-sorting listviews.

   Each entry in the database can be individually enabled or disabled.
Enabled entries are indicated by a `>>' marker to the left of the
entry. You can enable or disable entries by double-clicking on them
(with most GUI modules), or by selecting an entry and then clicking on
`Enable' or `Disable'.

   Each entry in the database can be marked as "temporary" by clicking
on the "Temp" gadget. This has the effect that this entry is not saved
to disk when you save the settings, and that it is - in some cases -
deleted when reconnecting. This can be useful if some of the entries
(e.g. dynamically obtained DNS server addresses) should not be used for
the next connection.

   By default MiamiDx marks all dynamically obtained DNS server
addresses and your dynamic hostname as temporary.

   Parts of the database:


 @{" Protocols " Link "NODE_CONFIG_DATABASE_PROTOCOLS"}                                     The `protocols' part
 @{" Services " Link "NODE_CONFIG_DATABASE_SERVICES"}                                      The `services' part
 @{" Hosts " Link "NODE_CONFIG_DATABASE_HOSTS"}                                         The `hosts' part
 @{" Networks " Link "NODE_CONFIG_DATABASE_NETWORKS"}                                      The `networks' part
 @{" Domains " Link "NODE_CONFIG_DATABASE_DOMAINS"}                                       The `domains' part
 @{" DNS servers " Link "NODE_CONFIG_DATABASE_DNSSERVERS"}                                   The `DNS servers' part
 @{" InetD " Link "NODE_CONFIG_DATABASE_INETD"}                                         The `InetD' part
 @{" users " Link "NODE_CONFIG_DATABASE_USERS"}                                         The `users' part
 @{" groups " Link "NODE_CONFIG_DATABASE_GROUPS"}                                        The `groups' part
 @{" Arp " Link "NODE_CONFIG_DATABASE_ARP"}                                           The `Arp' part
 @{" Socks " Link "NODE_CONFIG_DATABASE_SOCKS"}                                         The `Socks' part
 @{" Hostaliases " Link "NODE_CONFIG_DATABASE_HOSTALIASES"}                                   The `Socks' part
 @{" SysCtl " Link "NODE_CONFIG_DATABASE_SYSCTL"}                                        The `SysCtl' part
 @{" IP-NAT " Link "NODE_CONFIG_DATABASE_IPNAT"}                                        The `IP-NAT' part
 @{" IP filter " Link "NODE_CONFIG_DATABASE_IPFILTER"}                                     The `IP filter' part


@EndNode

@Node "NODE_CONFIG_DATABASE_PROTOCOLS" "MiamiDx.guide/NODE_CONFIG_DATABASE_PROTOCOLS"
@Next "NODE_CONFIG_DATABASE_SERVICES"
@Toc "NODE_CONFIG_DATABASE"

Protocols
---------

   List of all supported protocols (relative to IP), consisting of a
protocol name, a protocol ID, and an optional list of aliases. The
table corresponds to the "etc/protocols" or "db/protocols" file in
other protocol stacks.

   This table hardly ever has to be changed. You should @{i}never@{ui} remove
one of the default entries from this table.


@EndNode

@Node "NODE_CONFIG_DATABASE_SERVICES" "MiamiDx.guide/NODE_CONFIG_DATABASE_SERVICES"
@Next "NODE_CONFIG_DATABASE_HOSTS"
@Prev "NODE_CONFIG_DATABASE_PROTOCOLS"
@Toc "NODE_CONFIG_DATABASE"

Services
--------

   List of all supported services (TCP or UDP), consisting of a service
name, a service ID, a protocol name, and an optional list of aliases.
The table corresponds to the "etc/services" or "db/services" file in
other protocol stacks.

   Some application programs might require changes (usually additions)
to this list. However you should @{i}never@{ui} remove one of the default
entries from this table.

   In particular: @{i}(very important:)@{ui} removing one entry from this table
is @{i}not@{ui} the proper method to prohibiting access to the corresponding
server. In order to prohibit access to a server you need to disable the
server in InetD, either by removing it from the "InetD" table, or by
disabling its entry in the "InetD" table, but @{i}do not@{ui} remove the entry
from the "services" table. Even if you do not want to allow access to a
service that service should still have a "services" entry, because
otherwise clients trying to access that service on another host might
not be able to do so.


@EndNode

@Node "NODE_CONFIG_DATABASE_HOSTS" "MiamiDx.guide/NODE_CONFIG_DATABASE_HOSTS"
@Next "NODE_CONFIG_DATABASE_NETWORKS"
@Prev "NODE_CONFIG_DATABASE_SERVICES"
@Toc "NODE_CONFIG_DATABASE"

Hosts
-----

   List of all host names (and corresponding IP addresses), consisting
of an IP address, a host name, and an optional list of aliases.  The
table corresponds to the "etc/hosts" or "db/hosts" file in other
protocol stacks.

   MiamiDx automatically adds a mapping for "localhost" and for the
host name of your Amiga to this list. Other mappings can be added
manually to make name->IP translations faster. However you should only
add mappings for names that are under your personal control. Never add
mappings for hosts elsewhere on the Internet, because otherwise you
would be unable to contact those hosts when they are renumbered.

   In particular: if you want to add shortcuts for frequently used
hosts outside of your domain (e.g. "aminet" for "ftp.uni-paderborn.de"
or any other Aminet site), then the correct place to do this is the
@{"Hostaliases" Link "NODE_CONFIG_DATABASE_HOSTALIASES"} section, not "Hosts".


@EndNode

@Node "NODE_CONFIG_DATABASE_NETWORKS" "MiamiDx.guide/NODE_CONFIG_DATABASE_NETWORKS"
@Next "NODE_CONFIG_DATABASE_DOMAINS"
@Prev "NODE_CONFIG_DATABASE_HOSTS"
@Toc "NODE_CONFIG_DATABASE"

Networks
--------

   List of all networks, consisting of a network name, a network ID, and
an optional list of aliases.  The table corresponds to the
"etc/networks" or "db/networks" file in other protocol stacks.

   This table is hardly used any more, and only implemented for
backwards compatibility with very old software and some diagnostic
software.


@EndNode

@Node "NODE_CONFIG_DATABASE_DOMAINS" "MiamiDx.guide/NODE_CONFIG_DATABASE_DOMAINS"
@Next "NODE_CONFIG_DATABASE_DNSSERVERS"
@Prev "NODE_CONFIG_DATABASE_NETWORKS"
@Toc "NODE_CONFIG_DATABASE"

Domains
-------

   List of all local domains, specified by just the domain name.  The
table corresponds to the "etc/domains" or "db/domains" file in other
protocol stacks.

   This table is not strictly needed by TCP/IP, but adds some
convenience for the user: it allows you to abbreviate host names by
specifying just the machine name (without the domain) whenever
referring to a host.

   Example:

   Assume a local machine on your network is named @{b}ex1.foo.edu@{ub}, and you
access this machine frequently. If you add @{b}foo.edu@{ub} to the list of
domains, then you can access machine @{b}ex1.foo.edu@{ub} by just typing @{b}ex1@{ub}.

   Note that abbreviating host names this way only works for names
looked up through DNS, not for names looked up through the "Hosts"
table. This means if you for instance add a domain "foo.edu", have a
host "ex1.foo.edu" at 10.0.0.1 and want to be able to access that host
by just typing "ex1", then you need to add an alias "ex1" for the host
in the "Hosts" table as well (i.e. make the "Hosts" table entry
"10.0.0.1 ex1.foo.edu ex1").


@EndNode

@Node "NODE_CONFIG_DATABASE_DNSSERVERS" "MiamiDx.guide/NODE_CONFIG_DATABASE_DNSSERVERS"
@Next "NODE_CONFIG_DATABASE_INETD"
@Prev "NODE_CONFIG_DATABASE_DOMAINS"
@Toc "NODE_CONFIG_DATABASE"

DNS servers
-----------

   List of DNS servers, specified by just the IP address of the server,
and optionally by the associated interface name. If you specify one or
more interface names (or aliases) then MiamiDx only uses the DNS
servers if at least one of the interfaces is online.

   DNS servers are used to map logical host names to their IP address.
You should have at least one DNS server listed in this table at all
times, preferably a DNS server close to or at your network provider.

   If MiamiDx finds any DNS servers by itself when connecting it
automatically adds them to this list and marks them as "temporary". DNS
servers added this way are always added with interface aliases, so they
are only valid for as long as the corresponding interfaces are online.

   Please note that if you add an interface name then the DNS server is
only used once the interface is completely online. This means
specifying an interface name makes a DNS server incompatible with the
dial-on-demand feature "Auto-connect from offline" (see
@{"Interfaces Auto-connect/disconnect" Link "NODE_CONFIG_OTHER_IFACEAUTO"}, because in order for an interface
to automatically go online, traffic has to be created, and for that a
DNS server has to be defined before the interface goes online.  In
order for `Auto-connect from offline" to work correctly you need to
define at least one DNS server without an interface name.


@EndNode

@Node "NODE_CONFIG_DATABASE_INETD" "MiamiDx.guide/NODE_CONFIG_DATABASE_INETD"
@Next "NODE_CONFIG_DATABASE_USERS"
@Prev "NODE_CONFIG_DATABASE_DNSSERVERS"
@Toc "NODE_CONFIG_DATABASE"

InetD
-----

   List of daemons started by the built-in InetD consisting of a
service name (corresponding to an entry in the "services" table), a
socket type ("dgram" or "stream"), a wait mode ("wait", "nowait" or
"dos"), the owner (usually "root" for AmigaOS), the server's file name,
the server's process name, and a list of arguments to be sent to the
server.  The table corresponds to the "etc/inetd.conf" or
"db/inetd.conf" file in other protocol stacks.

   The InetD built-in to MiamiDx supports many built-in services:
"daytime", "time", "echo", "discard", "chargen", "finger" and "auth".
"auth" is really the same as "identd".

   Daemons for other (external) services can be automatically started
by InetD by adding an appropriate line to this table. If you would like
to install external daemons (e.g. ftpd or telnetd) please check their
documentation for the correct format of the "InetD" entry they require.

   For security reasons it is recommended that you disable the "echo",
"discard" and "chargen" services, because they can be abused for
denial-of-service attacks.


@EndNode

@Node "NODE_CONFIG_DATABASE_USERS" "MiamiDx.guide/NODE_CONFIG_DATABASE_USERS"
@Next "NODE_CONFIG_DATABASE_GROUPS"
@Prev "NODE_CONFIG_DATABASE_INETD"
@Toc "NODE_CONFIG_DATABASE"

Users
-----

   List of users in the system, consisting of a user name, a password,
a user ID, a group ID (index into the "groups" table), a real name, a
home directory, and a command to be used to start a shell through
telnet.  The table corresponds to the "etc/passwd" or "db/passwd" file
in other protocol stacks.

   You usually only need a single entry in this file (for yourself),
unless you want to run daemons like ftpd/telnetd that allow other users
to connect to your Amiga.

   Passwords are stored in an encrypted format and are not displayed in
the listview. The password column shows

@{b}`-'@{ub}
     if no password is associated with a user, i.e. if login is possible
     @{i}without a password@{ui}.

@{b}`*'@{ub}
     if no login is possible to this account.

@{b}a centered `x'@{ub}
     if a valid password is associated with this user.

   The procedure to enter passwords differs depending on the GUI module
you use. For MUI and some other modules click on the "Password" popup
gadget to change the password. A string requester pops up then. For
other module you need to enter the new password directly in the string
gadget.

   If you leave the string gadget empty then no password will be
associated with the user (shown as `-'). If you enter just the single
character `*' then logins will be inhibited (shown as `*'). In all
other cases the text you type will be used as the password (shown as a
centered `x').

   Note: When you import this file from AmiTCP the passwords are @{i}not@{ui}
preserved, i.e. the passwords for all users are set to empty and have
to be entered again manually. This is because the password encryption
algorithm used by AmiTCP cannot be used by MiamiDx for legal reasons.
For more information on this please check @{"Passwords" Link "NODE_SPECIFICATIONS_EXCHANGE_PASSWORDS"}.


@EndNode

@Node "NODE_CONFIG_DATABASE_GROUPS" "MiamiDx.guide/NODE_CONFIG_DATABASE_GROUPS"
@Next "NODE_CONFIG_DATABASE_ARP"
@Prev "NODE_CONFIG_DATABASE_USERS"
@Toc "NODE_CONFIG_DATABASE"

Groups
------

   List of groups in the system, consisting of a group name, a group ID
and an optional user list.  The table corresponds to the "etc/group" or
"db/group" file in other protocol stacks.

   You usually only need a single entry in this file (for yourself),
unless you want to run daemons like ftpd/telnetd that allow other users
to connect to your Amiga.


@EndNode

@Node "NODE_CONFIG_DATABASE_ARP" "MiamiDx.guide/NODE_CONFIG_DATABASE_ARP"
@Next "NODE_CONFIG_DATABASE_SOCKS"
@Prev "NODE_CONFIG_DATABASE_GROUPS"
@Toc "NODE_CONFIG_DATABASE"

Arp
---

   List of manual Arp entries in the system, consisting of an IP address
and a hardware address. The hardware address has to be specified in the
usual colon-hex notation (e.g. `01:23:45').  The table corresponds to
the "etc/ethers" or "db/ethers" file in other protocol stacks.

   Arp is only used with bus/ring-type SANA-II devices, and you only
need to add Arp entries manually if one of the other machines on the
local network does not support Arp.

   Please note that Arp entries in this table only affect lookups on
your own machine. You cannot use the Arp table to publish Arp entries
to the network (for proxy-Arp or similar applications).


@EndNode

@Node "NODE_CONFIG_DATABASE_SOCKS" "MiamiDx.guide/NODE_CONFIG_DATABASE_SOCKS"
@Next "NODE_CONFIG_DATABASE_HOSTALIASES"
@Prev "NODE_CONFIG_DATABASE_ARP"
@Toc "NODE_CONFIG_DATABASE"

Socks
-----

   List of SOCKS configuration entries in the system, consisting of a
protocol type, a command, a list of hosts, a list of ports, and a list
of proxies. The table defines which proxy (SOCKS) server, if any, is
supposed to be contacted, as a function of the host and port to connect
to.

   Most users do not have to make any changes in this table. If you do
not use SOCKS at all then just ignore this table. If you do use SOCKS
then in most cases it is sufficient to leave this table empty, and only
configure a SOCKS server in @{"Socks" Link "NODE_CONFIG_SOCKS"}. You only need to make changes in
this table if you want MiamiDx to contact different SOCKS servers for
different hosts or ports, or if you have a complicated local network
(with multiple subnets) inside of the SOCKS firewall.

   Each entry in this table defines a filter for a connection or bind
attempt, and a list of proxy servers that are supposed to be contacted
for connections matched by the filter. For each connection or bind
attempt the table is scanned from beginning to end, and the first match
is used, i.e. the order of entries in this table is significant. The
format of each entry is as follows:

@{b}Type@{ub}
     This defines the type of connection to be used, if this filter
     entry matches. Valid values are `socks4' for a SOCKS V4 connection,
     `socks5' for a SOCKS V5 connection and `noproxy' for a direct
     connection, without SOCKS.

@{b}Command@{ub}
     This field is part of the filter, and can be a comma-separated list
     of letters, with no white space in between. Each letter indicates
     one type of request: `c': connect. `b': bind. `u': UDP. `p': ping.
     `t': traceroute. `-': any request.

@{b}Hosts@{ub}
     This field is part of the filter, and can be a host definition, as
     follows: `hostip/mask': matches a range of target hosts by IP
     address and netmask, e.g. `1.2.3.4/255.255.0.0'. `-': matches all
     hosts. `n1': equivalent to `n1.0.0.0/255.0.0.0'. `n1.n2':
     equivalent to `n1.n2.0.0/255.255.0.0'.  `n1.n2.n3': equivalent to
     `n1.n2.n3.0/255.255.255.0'. `.domain.name': matches all hosts
     ending in `.domain.name'. `a.host.name': matches exactly the host
     `a.host.name'.

@{b}Ports@{ub}
     This field is part of the filter, and can be a port definition, as
     follows: `-': matches all ports. `name': matches the named
     service, e.g. `ftp'.  `number': matches the given port number,
     e.g. `80'.  `[100,1000]': matches ports 100 through 1000.
     `(100,1000)': matches ports 101-999. `(100,1000]': matches ports
     101-1000.

@{b}Proxies@{ub}
     This defines which proxy servers to contact for requests that
     match this filter. It can be a comma-separated list of server
     entries. Each server entry has to be specified by hostname or IP
     address, optionally followed by a colon and the port number of the
     proxy server.

   This table is only functional if `SOCKS' is enabled in @{"Socks" Link "NODE_CONFIG_SOCKS"}. For
requests not matched by this table the default behavior is to contact
the SOCKS server/port defined in @{"Socks" Link "NODE_CONFIG_SOCKS"} using SOCKS5.


@EndNode

@Node "NODE_CONFIG_DATABASE_HOSTALIASES" "MiamiDx.guide/NODE_CONFIG_DATABASE_HOSTALIASES"
@Next "NODE_CONFIG_DATABASE_SYSCTL"
@Prev "NODE_CONFIG_DATABASE_SOCKS"
@Toc "NODE_CONFIG_DATABASE"

Hostaliases
-----------

   This table can be used to create aliases for frequently used hosts,
e.g.  "aminet" could be an alias for "ftp.uni-paderborn.de" or any
other Aminet host you prefer. The table corresponds to the
"etc/hostaliases" file in other protocol stacks.

   Please note that this table is only used for "real" DNS lookups, not
for names resolved through the "Hosts" table, i.e. if you administer
some local hosts using the "Hosts" table instead of DNS then you have
to add any aliases you want to use in the "Hosts" table, not in
"Hostaliases".


@EndNode

@Node "NODE_CONFIG_DATABASE_SYSCTL" "MiamiDx.guide/NODE_CONFIG_DATABASE_SYSCTL"
@Next "NODE_CONFIG_DATABASE_IPNAT"
@Prev "NODE_CONFIG_DATABASE_HOSTALIASES"
@Toc "NODE_CONFIG_DATABASE"

SysCtl
------

   The SysCtl table contains a lot of system settings and variables
that affect the way MiamiDx works. It is intended for advanced users
only. Most users will find the default settings adequate. Never make
any changes to a setting in this table unless you thoroughly understand
the meaning of the setting and its possible side effects.

   All of these variables can also be accessed externally, using the
"MiamiSysCtl" utility, but such use is deprecated, and is only provided
for compatibility with Miami. MiamiDx should make changes only through
the user interface.

   Explanation of all variables:

@{b}net.inet.ip.forwarding@{ub}
     This option controls whether MiamiDx acts as a router. Never
     change this option directly. Use the switch @{"TCP/IP Gateway" Link "NODE_CONFIG_TCPIP_GATEWAY"} in the
     user interface instead. It is linked to this option.

@{b}net.inet.ip.redirect@{ub}
     This option controls whether MiamiDx should send ICMP redirect
     messages when it receives packets that should be sent to a
     different router. You should usually keep this setting enabled,
     because it is required for dynamic routing.

@{b}net.inet.ip.ttl@{ub}
     Controls the default ttl (time-to-live) for packets MiamiDx sends.
     Should be at the default of 64.

@{b}net.inet.ip.rtexpire/rtminexpire/rtmaxcache@{ub}
     Controls the timing and size for route cloning. You should not
     change these values. TCP depends on reasonable values in these
     entries.

@{b}net.inet.ip.sourceroute@{ub}
     Controls the behavior for packets that contain an IP source route.
     Never change this option directly. Use the switch
     @{"TCP/IP Allow source routing" Link "NODE_CONFIG_TCPIP_SOURCEROUTE"} in the user interface instead. It is
     linked to this option.

@{b}net.inet.ip.pathmtudisc@{ub}
     Specifies whether Path MTU Discovery is enabled (1/0). The default
     is to enable it, but if you are connected through old, buggy
     routers and have problems with TCP traffic then try disabling this
     option.

@{b}net.inet.ip.portrange.*@{ub}
     Port number ranges used by MiamiDx to assign ephemeral port
     numbers to sockets when connecting to a server.
     "deffirst"/"deflast" describe the default port number range.
     "highfirst"/"highlast" describe the port number range officially
     assigned for use as temporary port numbers by IANA.
     "lowfirst"/"lowlast" describe the privileged port number range,
     used e.g. by rlogin. You should usually not change these numbers.

@{b}net.inet.icmp.maskrepl@{ub}
     Controls whether MiamiDx sends the netmask in response to ICMP
     mask queries. If the netmask is configured correctly and you
     enable this option, then any @{i}other@{ui} machine on the local network
     running MiamiInit, Miami or MiamiDx will be able to automatically
     find the correct netmask from ICMP.

@{b}net.inet.tcp.rfc1323@{ub}
     This switch should always be turned off. The RFC1323 extensions
     controlled by this switch are now set automatically by MiamiDx, on
     a per-interface basis.

@{b}net.inet.tcp.rfc1644@{ub}
     Enables T/TCP. Never change this option directly. Use the switch
     @{"TCP/IP T/TCP" Link "NODE_CONFIG_TCPIP_TTCP"} in the user interface instead. It is linked to this
     option.

@{b}net.inet.tcp.mssdflt@{ub}
     Sets the default maximum segment size for TCP. Usually this number
     should not be changed. It is normally not used, because MiamiDx
     uses Path MTU Discovery to determine optimum MSS values.

@{b}net.inet.tcp.rttdflt@{ub}
     This option controls TCP's retransmission timing and should not be
     changed.

@{b}net.inet.tcp.keepidle/keepintvl@{ub}
     These options control TCP's keep-alive timer and should not be
     changed.

@{b}net.inet.tcp.sendspace/recvspace@{ub}
     These options define the default TCP send/recv window size, and
     should usually not be changed.

@{b}net.inet.tcp.bulkftp@{ub}
     Reserved for future use. Currently non-functional. Do not touch.

@{b}net.inet.tcp.initwin@{ub}
     Define the number of packets in the initial TCP window for new
     connections. The default is 1, but recently research has shown
     that in some circumstances it can be beneficial to set this value
     to 2 or 3 for better performance.

@{b}net.inet.tcp.fastlocal@{ub}
     Enables a new optimization that significantly speeds up connections
     to localhost. Should usually be enabled (set to 1).

@{b}net.inet.tcp.sack@{ub}
     This option controls whether some new enhancements in the TCP
     protocol ("SACK", "TSACK", "NewReno" and "modified fast
     retransmit") should be enabled. At this time the best setting is
     208, which enables "SACK", "NewReno" and "modified fast
     retransmit". Usually this provides best performance combined with
     high compatibility with old hosts.

@{b}net.inet.udp.checksum@{ub}
     Enables UDP checksums for all outbound packets. This option should
     always be enabled.

@{b}net.inet.udp.maxdgram/recvspace@{ub}
     These options control UDP packet thresholds and should not be
     changed.

@{b}dns.cache.size@{ub}
     Controls the size of MiamiDx's built-in DNS cache.

@{b}dns.cache.flush@{ub}
     Settings this option to 1 flushes MiamiDx's built-in DNS cache.

@{b}dns.cache.enabled@{ub}
     Enables or disables Miami's built-in DNS cache. The default value
     is 2, i.e. all host entries are cached. If this variable is set to
     1 then only host entries with a single IP address are cached, so
     interferences with round-robin IP address shuffling are avoided.
     If this variable is set to 0 then Miami's DNS cache is completely
     disabled. You should only disable the cache if you have a very fast
     connection to a local DNS server.

@{b}dns.cache.split@{ub}
     This variable is usually 0, indicating that MiamiDx uses a unified
     DNS cache for forward and reverse lookups. If you set this variable
     to 1 then MiamiDx uses separate forward and reverse DNS caches.
     This makes diagnostic output (e.g. from MiamiNetStat) slower, but
     guarantees `correct' reverse resolution of all IP addresses (using
     PTR lookups).

@{b}inetd.retrytime@{ub}
     Defines the delay after which InetD retries to bind to a socket if
     it failed to do so the first time.

@{b}inetd.toomany@{ub}
     Defines the maximum number of connections InetD will accept within
     a given time interval. If you get warnings "Too many requests..."
     in your system log then try increasing this value.

@{b}inetd.cntintvl@{ub}
     Defines the time interval corresponding to inetd.toomany.

@{b}inetd.maxbuiltin@{ub}
     Defines the maximum number of built-in servers spawned by InetD.

@{b}inetd.processpri@{ub}
     Defines the process priority for servers launched by InetD.  The
     default is -5. You should raise this value if you are running any
     CPU-intensive background processes (e.g. the RC5 challenge
     client). Otherwise your servers will never get any CPU time.

@{b}inetd.diagbufsize@{ub}
     Defines the size of socket buffers for diagnostic InetD services
     (chargen, echo etc.). By default this value is 4096, i.e. smaller
     than typical UDP/TCP socket buffers, to reduce the impact of
     denial-of-service attacks.

@{b}inetd.diagtimeout@{ub}
     Timeout in seconds after which connections to diagnostic InetD
     services are terminated.

@{b}socket.maxqlen@{ub}
     This option defines the length of the socket connection queue for
     a listen()-parameter of 5. The default is 7, but if you are
     connected to a very fast network and have sufficient memory you
     might want to increase this value to reduce the effects of SYN
     flood attacks.

@{b}sys.maxmbufs@{ub}
     Maximum number of mbufs (memory buffers, with a size of 128 bytes
     each) MiamiDx will allocate. If you use MiamiDx as a server under
     VERY heavy load (a hundred or more simultaenous TCP connections,
     for example) and you notice "stalling" in some of them, then try
     increasing this value.


@EndNode

@Node "NODE_CONFIG_DATABASE_IPNAT" "MiamiDx.guide/NODE_CONFIG_DATABASE_IPNAT"
@Next "NODE_CONFIG_DATABASE_IPFILTER"
@Prev "NODE_CONFIG_DATABASE_SYSCTL"
@Toc "NODE_CONFIG_DATABASE"

IP-NAT
------

   IP-NAT is usually a transparent mechanism that does not require any
configuration. There are a few exceptions though. Some protocols,
including ftp (in "active" mode) and some subprotocols of IRC-DCC are
not IP-NAT friendly, and require special workarounds in the IP-NAT
server for these protocols to work through an IP-NAT gateway.

   The IP-NAT server has to be "told" which connections to which hosts
and ports use one of these problematic protocols, so it can process
these connections correctly. This table allows you to do that.

   Each entry in the table defines a combination of services and IP
addresses for which one particular IP-NAT processing is required.  The
default is

     21 * ftp
     6667/6668 * irc

   This means that all connections to port 21, to all hosts, are
assumed to be ftp connections and processed accordingly. Similarly all
connections to ports 6667 and 6668, to all hosts, are assumed to be IRC
connections.

   "Service" can be a port number, a service name, or a range separated
by "/". "IP" can be an IP address (with optional "*" wild cards in it),
or an IP-address/netmark combination, separated by "/". "NAT mode"
currently can be either "irc" or "ftp".


@EndNode

@Node "NODE_CONFIG_DATABASE_IPFILTER" "MiamiDx.guide/NODE_CONFIG_DATABASE_IPFILTER"
@Prev "NODE_CONFIG_DATABASE_IPNAT"
@Toc "NODE_CONFIG_DATABASE"

IP filter
---------

   (This function is only available in the registered version.)

   This table allows you to filter out some of the IP packets arriving
at your machine, or to create system log entries if some specific
packets arrive. This allows you to restrict access to servers running
on your machine, or to be notified when someone tries to break into
your machine.

   The table consists of a sequence of rules. Each packet that arrives
is checked against each of the rules, from top to bottom. The first
rule that applies to the packet dictates whether the packet is filtered
out, and whether a log entry for this packet is generated for this
packet. Rules further below in the table are not checked.

   Each entry in the table consists of the following parts:

   @{b}*@{ub} A protocol, i.e. `tcp', `udp' or `*' meaning `any protocol'.

   @{b}*@{ub} A service, i.e. a name that appears in the `services' table, `*'
     meaning `any port' or `$' meaning `any service port', i.e. any
     port @{i}not@{ui} in the range from 1024-5000). It is also possible to
     specify a range of services here, using the `/' as the delimiter
     between the first and last service, e.g.  `1/80' is the range from
     port 1 to port 80.

   @{b}*@{ub} An IP address, refering to the source IP address of the packet.

   @{b}*@{ub} A netmask, defining the range of IP addresses

   @{b}*@{ub} Two parameters that define the action: you can allow or disallow
     access ('y' or 'n'), and create or inhibit a log entry ('y' or
     'n').

   Note that log entries are only created for `tcp' services, not for
`udp' services.

   Here is an example of a useful start configuration for the IP filter:

     * * 127.0.0.1 (empty mask) y n
     tcp auth *.*.*.* (empty mask) y n
     * $ *.*.*.* (empty mask) y y

   What this does is:

   The first line ensures that any packet sent locally (i.e. from your
Amiga to yourself) is allowed without logging.

   The second line also allows incoming `auth' requests without logging.
This is useful because `auth' (`identd') requests are issued by so many
httpd, ftpd and ircd servers that you probably do not want to be
bothered with a log entry for each request.

   The third line allows all remaining external requests, but generates
a log entry, telling you that someone is trying to access your machine.
It is important that the service is specified as `$', not `*'. That's
because ftp uses reverse-connects (from the server to the client)
during upload and download. If you specified the service as `*' then
you would also get a log entry each time you download or upload a file
from/to an ftp server.

   All remaining packets (i.e. packets from the outside sent to a port
between 1024 and 5000) use the implied default rule, which is to allow
the packet and not to generate a log entry.

   Please note that there is a difference between an "IP filter", as
defined in this table, and a "firewall", defined in
@{"TCP/IP LAN-Connect Firewall" Link "NODE_CONFIG_OTHER_LANCONNECT_FIREWALL"}.  The IP filter defined here controls
access to servers running on only this single machine, i.e. it only
affects packets which have this machine as their final destination.
Packets forwarded (routed) by MiamiDx to other machines are not
filtered by the IP filter. The purpose of the IP filter is to limit
access to servers running on this machine only.

   For comparison, a "firewall" can only be used on routers, i.e. on
machines with more than one network connection. The purpose of a
firewall is to logically separate all interfaces on the router into
trusted "LAN" interfaces and untrusted "Internet" interfaces, and to
prohibit most incoming traffic from "Internet" to "LAN" interfaces.
This not only protects servers running on the router, but also protects
all other machines on the LAN from traffic originating from untrusted
"Internet" interfaces.


@EndNode

@Node "NODE_CONFIG_TCPIP" "MiamiDx.guide/NODE_CONFIG_TCPIP"
@Next "NODE_CONFIG_EVENTS"
@Prev "NODE_CONFIG_DATABASE"
@Toc "NODE_CONFIG"

TCP/IP
======

   Users upgrading from Miami will notice that the TCP/IP page looks
much different in MiamiDx than in Miami. The Miami options "Use ICMP",
"Use DHCP", "Verify DNS servers", "Fake IP", "Down when offline" and
"Get time" are now configurable separately for each interface, in
@{"Interfaces TCP/IP settings" Link "NODE_CONFIG_OTHER_IFACETCPIP"}. The option "Auto-add domain" is no longer
available because of conflicts with multi-interface operation. Instead
please define domains permanently in @{"Datebase Domains" Link "NODE_CONFIG_DATABASE_DOMAINS"} or set host
aliases in @{"Datebase Hostaliases" Link "NODE_CONFIG_DATABASE_HOSTALIASES"}. The `Host name' group has changed as
well: this window now only configures the default host name.  Dynamic
host names are configured in @{"Interfaces TCP/IP settings" Link "NODE_CONFIG_OTHER_IFACETCPIP"}, separately for
each interface.

   The "LAN-Connect" gadget on this page opens the @{"LAN-Connect" Link "NODE_CONFIG_OTHER_LANCONNECT"} dialog
window to change the settings of the LAN-Connect module (firewalling,
IP-NAT and SOCKS daemon).


 @{" Default/real host name " Link "NODE_CONFIG_TCPIP_HOSTNAME"}                              The `Host name' group
 @{" Real / User name " Link "NODE_CONFIG_TCPIP_NAME"}                                    The `Real name' and `User name' gadgets
 @{" Gateway " Link "NODE_CONFIG_TCPIP_GATEWAY"}                                             The `Gateway' gadget
 @{" Ping flood protection " Link "NODE_CONFIG_TCPIP_PING"}                               The `Ping flood protection' gadget
 @{" T/TCP " Link "NODE_CONFIG_TCPIP_TTCP"}                                               The `T/TCP' gadget
 @{" Allow source routing " Link "NODE_CONFIG_TCPIP_SOURCEROUTE"}                                The `Allow source routing' gadget


@EndNode

@Node "NODE_CONFIG_TCPIP_HOSTNAME" "MiamiDx.guide/NODE_CONFIG_TCPIP_HOSTNAME"
@Next "NODE_CONFIG_TCPIP_NAME"
@Toc "NODE_CONFIG_TCPIP"

Host name
---------

   The "Default host name" gadget is used to set the default host name,
i.e.  the host name your Amiga uses when no interface has gone online
and provided a different host name dynamically. If your Amiga has a LAN
connection (with a permanent IP address) then you should set the
default host name to the name your Amiga uses on the LAN. Otherwise set
it to "localhost" or some dummy host name.


@EndNode

@Node "NODE_CONFIG_TCPIP_NAME" "MiamiDx.guide/NODE_CONFIG_TCPIP_NAME"
@Next "NODE_CONFIG_TCPIP_GATEWAY"
@Prev "NODE_CONFIG_TCPIP_HOSTNAME"
@Toc "NODE_CONFIG_TCPIP"

Real / User name
----------------

   In these gadgets you should enter your real name (e.g. "Joe Smith"),
and the user name on your Amiga (e.g. "jsmith").

   Although you could theoretically use any names here it is good
practice to use "real" names, not some phantasy names.

   Some programs look up user information based on your user name. To
make these programs behave properly you should ensure that there is an
entry in the "Users" part on the "Database" page that corresponds to
the user name entered here.


@EndNode

@Node "NODE_CONFIG_TCPIP_GATEWAY" "MiamiDx.guide/NODE_CONFIG_TCPIP_GATEWAY"
@Next "NODE_CONFIG_TCPIP_PING"
@Prev "NODE_CONFIG_TCPIP_NAME"
@Toc "NODE_CONFIG_TCPIP"

Gateway
-------

   If this switch is enabled then MiamiDx automatically forwards
packets between interfaces, i.e. it acts as a router. If the switch is
disabled then no traffic is forwarded, i.e. MiamiDx can still
communicate with hosts on all interfaces, but hosts cannot communicate
with hosts on other networks "through" MiamiDx.


@EndNode

@Node "NODE_CONFIG_TCPIP_PING" "MiamiDx.guide/NODE_CONFIG_TCPIP_PING"
@Next "NODE_CONFIG_TCPIP_TTCP"
@Prev "NODE_CONFIG_TCPIP_GATEWAY"
@Toc "NODE_CONFIG_TCPIP"

Ping flood protection
---------------------

   (This option is available in the registered version only.)

   MiamiDx has a simple heuristic to reduce the effects of
denial-of-service attacks resulting from ping flooding:

   If this option is enabled and a user tries to ping-flood your
machine (either by sending very large pings or by sending pings very
quickly), MiamiDx generates a log entry informing you about the
attempt, and stops generating ping responses to that user for a while,
until the user has stopped flooding you for some time.

   Note that there is @{i}no way@{ui} for you to prevent the user from flooding
you, i.e. to stop him from wasting your modem bandwidth.  All MiamiDx
can do in response to ping flooding is to stop sending responses and to
tell you about it (so you can reconnect to a different modem port). It
is not possible for MiamiDx to prevent that user from wasting your
modem bandwidth. That would only be possible by installing a filter at
your Internet provider.


@EndNode

@Node "NODE_CONFIG_TCPIP_TTCP" "MiamiDx.guide/NODE_CONFIG_TCPIP_TTCP"
@Next "NODE_CONFIG_TCPIP_SOURCEROUTE"
@Prev "NODE_CONFIG_TCPIP_PING"
@Toc "NODE_CONFIG_TCPIP"

T/TCP
-----

   (This option is available in the registered version only.)

   T/TCP (TCP for Transactions) is an extension to TCP that can
significantly increase the speed of some types of applications, in
particular of web browsers, if the browser and the server both support
T/TCP.

   Registered users should usually enable this option to make use of the
speed advantage. However a few PPP servers have problems with the
extended TCP packets generated by T/TCP, so if MiamiDx stops working
after enabling T/TCP you might have to disable this option - or switch
providers.


@EndNode

@Node "NODE_CONFIG_TCPIP_SOURCEROUTE" "MiamiDx.guide/NODE_CONFIG_TCPIP_SOURCEROUTE"
@Prev "NODE_CONFIG_TCPIP_TTCP"
@Toc "NODE_CONFIG_TCPIP"

Allow source routing
--------------------

   This option should usually be disabled. Source routing is a
technique at the IP protocol level by which the sender can define
precisely which routers are supposed to forward IP packets (instead of
letting the routers decide for themselves, based on routing tables).
Source routed packets can make your LAN vulnerable to certain types of
attacks, so they should usually be filtered out, i.e. this option hould
be disabled.

   There are very few circumstances in which source routing can be
useful, e.g.  if you are using very old tunnelling software that uses
source routes to define a tunnel path. In cases like that you need to
enable this option.


@EndNode

@Node "NODE_CONFIG_EVENTS" "MiamiDx.guide/NODE_CONFIG_EVENTS"
@Next "NODE_CONFIG_LOGGING"
@Prev "NODE_CONFIG_TCPIP"
@Toc "NODE_CONFIG"

Events
======

   MiamiDx allows you to react in various ways to events such as
offline, online etc., by executing an ARexx or Shell script, iconifying
the MiamiDx window etc.

   The specific events MiamiDx can react to are:

@{b}Start@{ub}
     program start.

@{b}End@{ub}
     program end.

@{b}active Offline@{ub}
     going offline caused by the user, e.g. by clicking on the
     "Offline" gadget or by an ARexx "OFFLINE" command.

@{b}passive Offline@{ub}
     going offline caused by the modem or the provider hanging up.

@{b}Online@{ub}
     going online, i.e. successfully connecting to the Internet
     provider and starting up all required protocols.

@{b}failed Online attempt@{ub}
     an attempt to go online that failed for some reason, e.g. because
     all phone lines were busy, and the maximum number of retries was
     reached.

   Only the "Start" and "End" events are defined on this page. All other
events can be defined separately for each interface.  See
@{"Interfaces Events" Link "NODE_CONFIG_OTHER_IFACEEVENTS"}.

   MiamiDx can react in the following ways to "Start" and "End" events:

@{b}ARexx@{ub}
     Start an ARexx script

@{b}Shell@{ub}
     Start an AmigaDOS shell script

@{b}Hide GUI@{ub}
     iconify the MiamiDx window

@{b}Kill GUI@{ub}
     iconify the MiamiDx window and unload the GUI module

@{b}auto-online@{ub}
     try to go online (dial) automatically

   In the evaluation version of MiamiDx the options "ARexx" and "Shell"
are not available.

   The gadget "Console name" allows you define the input/output stream
that ARexx and Shell scripts use. It should be something like
"CON:1/1/400/100/title".


@EndNode

@Node "NODE_CONFIG_LOGGING" "MiamiDx.guide/NODE_CONFIG_LOGGING"
@Next "NODE_CONFIG_WINDOWS"
@Prev "NODE_CONFIG_EVENTS"
@Toc "NODE_CONFIG"

Logging
=======

   Users upgrading from Miami may be missing the "Phone log" and "PPP
log" settings in this section. These settings are now adjustable
separately for each interface, in @{"Interfaces Logging" Link "NODE_CONFIG_OTHER_IFACELOG"}.


 @{" Console " Link "NODE_CONFIG_LOGGING_CONSOLE"}                                         The `Console' gadget
 @{" File " Link "NODE_CONFIG_LOGGING_FILE"}                                            The `File' gadget
 @{" Use syslog.library " Link "NODE_CONFIG_LOGGING_SYSLOG"}                              The `Use syslog.library' gadget
 @{" Log protocol errors " Link "NODE_CONFIG_LOGGING_ERRORS"}                             The `Log protocol errors' gadget


@EndNode

@Node "NODE_CONFIG_LOGGING_CONSOLE" "MiamiDx.guide/NODE_CONFIG_LOGGING_CONSOLE"
@Next "NODE_CONFIG_LOGGING_FILE"
@Toc "NODE_CONFIG_LOGGING"

Console
-------

   In this gadget you can specify the AmigaDOS stream name of the
console window that MiamiDx uses for system log messages. This file is
kept open after the first system message has occured, so you should use
the "CON:" modifiers "/AUTO/CLOSE" to be able to close the window
without losing old system messages.


@EndNode

@Node "NODE_CONFIG_LOGGING_FILE" "MiamiDx.guide/NODE_CONFIG_LOGGING_FILE"
@Next "NODE_CONFIG_LOGGING_SYSLOG"
@Prev "NODE_CONFIG_LOGGING_CONSOLE"
@Toc "NODE_CONFIG_LOGGING"

File
----

   In this gadget you can specify the AmigaDOS file name of the file
where MiamiDx stores system log messages. If the file already exists
then MiamiDx appends to this file, i.e. old file contents are not
deleted.


@EndNode

@Node "NODE_CONFIG_LOGGING_SYSLOG" "MiamiDx.guide/NODE_CONFIG_LOGGING_SYSLOG"
@Next "NODE_CONFIG_LOGGING_ERRORS"
@Prev "NODE_CONFIG_LOGGING_FILE"
@Toc "NODE_CONFIG_LOGGING"

Use syslog.library
------------------

   If you enable this gadget then MiamiDx tries to access syslog.library
for its system log. syslog.library is part of the SysLog package by
Petri Nordlund.


@EndNode

@Node "NODE_CONFIG_LOGGING_ERRORS" "MiamiDx.guide/NODE_CONFIG_LOGGING_ERRORS"
@Prev "NODE_CONFIG_LOGGING_SYSLOG"
@Toc "NODE_CONFIG_LOGGING"

Log protocol errors
-------------------

   If this gadget is enabled then MiamiDx generates a log entry for
every protocol error during connection attempts, e.g. from PPP or DHCP.


@EndNode

@Node "NODE_CONFIG_WINDOWS" "MiamiDx.guide/NODE_CONFIG_WINDOWS"
@Next "NODE_CONFIG_GUI"
@Prev "NODE_CONFIG_LOGGING"
@Toc "NODE_CONFIG"

Windows
=======


 @{" Quit requester " Link "NODE_CONFIG_WINDOWS_REQQUIT"}                                    The `Quit requester' gadgets
 @{" Offline requester " Link "NODE_CONFIG_WINDOWS_REQOFFLINE"}                                 The `Offline requester' gadget
 @{" Error requester " Link "NODE_CONFIG_WINDOWS_REQERRORS"}                                   The `Error requester' gadget
 @{" Dialer " Link "NODE_CONFIG_WINDOWS_DIALER"}                                            The `Dialer' gadgets


@EndNode

@Node "NODE_CONFIG_WINDOWS_REQQUIT" "MiamiDx.guide/NODE_CONFIG_WINDOWS_REQQUIT"
@Next "NODE_CONFIG_WINDOWS_REQOFFLINE"
@Toc "NODE_CONFIG_WINDOWS"

Quit requester
--------------

   You can configure when MiamiDx shall display a `Quit requester':

   @{b}*@{ub} always

   @{b}*@{ub} when programs that use MiamiDx are still running.

   @{b}*@{ub} when MiamiDx is online

   or combinations of the above.


@EndNode

@Node "NODE_CONFIG_WINDOWS_REQOFFLINE" "MiamiDx.guide/NODE_CONFIG_WINDOWS_REQOFFLINE"
@Next "NODE_CONFIG_WINDOWS_REQERRORS"
@Prev "NODE_CONFIG_WINDOWS_REQQUIT"
@Toc "NODE_CONFIG_WINDOWS"

Offline requester
-----------------

   If you activate this checkmark then MiamiDx asks you before going
offline.


@EndNode

@Node "NODE_CONFIG_WINDOWS_REQERRORS" "MiamiDx.guide/NODE_CONFIG_WINDOWS_REQERRORS"
@Next "NODE_CONFIG_WINDOWS_DIALER"
@Prev "NODE_CONFIG_WINDOWS_REQOFFLINE"
@Toc "NODE_CONFIG_WINDOWS"

Error requester
---------------

   Normally MiamiDx displays an error requester if any problems occur
during dialing or while configuring the link. If you disable this
checkmark then such errors are silently ignored, and MiamiDx does not
display an error requester.


@EndNode

@Node "NODE_CONFIG_WINDOWS_DIALER" "MiamiDx.guide/NODE_CONFIG_WINDOWS_DIALER"
@Prev "NODE_CONFIG_WINDOWS_REQERRORS"
@Toc "NODE_CONFIG_WINDOWS"

Dialer
------

   The standard dialer window has three parts: a help text at the top,
several buttons in the middle, and a dialog window at the bottom. With
the three "Dialer" checkmarks you can enable or disable each of these
three parts.

   If you disable the dialog window then the dialer will display a
single line of text only, that contains the dialer command currently
being executed.

   The "Activate windows" gadget tells MiamiDx whether you want MiamiDx
to activate dial windows and error requesters when they pop up.


@EndNode

@Node "NODE_CONFIG_GUI" "MiamiDx.guide/NODE_CONFIG_GUI"
@Next "NODE_CONFIG_SOCKS"
@Prev "NODE_CONFIG_WINDOWS"
@Toc "NODE_CONFIG"

GUI
===

   This page defines the user interface settings for MiamiDx, i.e.
hotkeys, iconification, icons and the user interface engine to be used.

   Important: Always specify user interface settings on this page, not
in any other preferences program. Even if you use MUI then @{i}do not@{ui} use
the iconify and hotkey functions in MUI preferences for MiamiDx.  These
functions do not work with MiamiDx, because MiamiDx handles
iconification by itself, without MUI.

   The "Control Panel Settings" gadget on this page opens the
@{"Control Panel Settings" Link "NODE_CONFIG_OTHER_PANEL"} dialog window to change the settings of the
control panel.


 @{" Hotkey " Link "NODE_CONFIG_GUI_HOTKEY"}                                       The `Hotkey' gadget
 @{" Show icon " Link "NODE_CONFIG_GUI_SHOWICON"}                                    The `Show icon' gadget
 @{" Show menu " Link "NODE_CONFIG_GUI_SHOWMENU"}                                    The `Show menu' gadget
 @{" No GUI on startup " Link "NODE_CONFIG_GUI_ONSTARTUP"}                            The `No GUI on startup' gadget
 @{" Online icon " Link "NODE_CONFIG_GUI_ONLINEICON"}                                  The `Online icon' gadget
 @{" Offline icon " Link "NODE_CONFIG_GUI_OFFLINEICON"}                                 The `Offline icon' gadget
 @{" GUI engine " Link "NODE_CONFIG_GUI_GUI"}                                   The `GUI engine' gadget
 @{" Switch " Link "NODE_CONFIG_GUI_SWITCH"}                                       The `Switch' gadget


@EndNode

@Node "NODE_CONFIG_GUI_HOTKEY" "MiamiDx.guide/NODE_CONFIG_GUI_HOTKEY"
@Next "NODE_CONFIG_GUI_SHOWICON"
@Toc "NODE_CONFIG_GUI"

Hotkey
------

   This string gadget specifies the Commodities hot key to iconify or
deiconify the MiamiDx user interface. Standard Commodities syntax is
used to define the hot key, e.g. `ctrl alt m' defines the hot key to be
the key `m', pressed together with the `ctrl' key and either `alt' key.
`ctrl alt m' is also the default.


@EndNode

@Node "NODE_CONFIG_GUI_SHOWICON" "MiamiDx.guide/NODE_CONFIG_GUI_SHOWICON"
@Next "NODE_CONFIG_GUI_SHOWMENU"
@Prev "NODE_CONFIG_GUI_HOTKEY"
@Toc "NODE_CONFIG_GUI"

Show icon
---------

   If this gadget is checked then an AppIcon is displayed on the
Workbench screen when MiamiDx is iconified.


@EndNode

@Node "NODE_CONFIG_GUI_SHOWMENU" "MiamiDx.guide/NODE_CONFIG_GUI_SHOWMENU"
@Next "NODE_CONFIG_GUI_ONSTARTUP"
@Prev "NODE_CONFIG_GUI_SHOWICON"
@Toc "NODE_CONFIG_GUI"

Show menu
---------

   If this gadget is checked then a `Miami Deluxe' entry in the
Workbench `Tools' menu is created when MiamiDx is iconified.


@EndNode

@Node "NODE_CONFIG_GUI_ONSTARTUP" "MiamiDx.guide/NODE_CONFIG_GUI_ONSTARTUP"
@Next "NODE_CONFIG_GUI_ONLINEICON"
@Prev "NODE_CONFIG_GUI_SHOWMENU"
@Toc "NODE_CONFIG_GUI"

No GUI on startup
-----------------

   If this gadget is checked then MiamiDx does not load the user
interface module on startup, and does not open its window. This feature
is most useful if you combine it with `automatic online on startup'.
See @{"Events" Link "NODE_CONFIG_EVENTS"} for more information on this.


@EndNode

@Node "NODE_CONFIG_GUI_ONLINEICON" "MiamiDx.guide/NODE_CONFIG_GUI_ONLINEICON"
@Next "NODE_CONFIG_GUI_OFFLINEICON"
@Prev "NODE_CONFIG_GUI_ONSTARTUP"
@Toc "NODE_CONFIG_GUI"

Online icon
-----------

   This gadget lets you specify an icon (`.info' file) that MiamiDx uses
as the AppIcon whenever MiamiDx is online. The default (empty gadget)
is to use a built-in image.


@EndNode

@Node "NODE_CONFIG_GUI_OFFLINEICON" "MiamiDx.guide/NODE_CONFIG_GUI_OFFLINEICON"
@Next "NODE_CONFIG_GUI_GUI"
@Prev "NODE_CONFIG_GUI_ONLINEICON"
@Toc "NODE_CONFIG_GUI"

Offline icon
------------

   This gadget lets you specify an icon (`.info' file) that MiamiDx uses
as the AppIcon whenever MiamiDx is offline. The default (empty gadget)
is to use a built-in image.


@EndNode

@Node "NODE_CONFIG_GUI_GUI" "MiamiDx.guide/NODE_CONFIG_GUI_GUI"
@Next "NODE_CONFIG_GUI_SWITCH"
@Prev "NODE_CONFIG_GUI_OFFLINEICON"
@Toc "NODE_CONFIG_GUI"

GUI engine
----------

   This gadget lets you choose one of several installed GUI engines.
Your choice is remembered by MiamiDx and stored in the settings file
(if you save settings afterwards), but MiamiDx does not immediately
switch to the new GUI engine. To do that click on @{"Switch" Link "NODE_CONFIG_GUI_SWITCH"}.


@EndNode

@Node "NODE_CONFIG_GUI_SWITCH" "MiamiDx.guide/NODE_CONFIG_GUI_SWITCH"
@Prev "NODE_CONFIG_GUI_GUI"
@Toc "NODE_CONFIG_GUI"

Switch
------

   Clicking on this gadget causes MiamiDx to switch to the selected GUI
engine. (What really happens is: MiamiDx iconifies, removes the current
GUI module, loads the new GUI module, and then deiconifies with the new
GUI module.)


@EndNode

@Node "NODE_CONFIG_SOCKS" "MiamiDx.guide/NODE_CONFIG_SOCKS"
@Next "NODE_CONFIG_OTHER"
@Prev "NODE_CONFIG_GUI"
@Toc "NODE_CONFIG"

Socks
=====

   This page lets you configure SOCKS client support in MiamiDx. If you
have never heard about SOCKS then you probably don't need it. SOCKS is
a proxy system to allow sites within a firewall to make connections to
machines outside of the firewall.

   MiamiDx's SOCKS implementation allows Amiga TCP/IP clients to connect
"through" firewalls transparently, without special support in the
clients. If your network provider uses a SOCKS firewall then ask them
for the IP address of the SOCKS server, and for the SOCKS username and
password (if the SOCKS server is password-protected), and configure
MiamiDx for SOCKS on this page.

   The settings on this page are default settings for your setup. You
can configure the SOCKS settings in more detail in @{"Socks" Link "NODE_CONFIG_DATABASE_SOCKS"}.

   Note: This page is only used to configure @{i}client@{ui} support for SOCKS,
i.e. if you want MiamiDx to connect to a SOCKS server on another
machine. If you want to do the opposite, i.e. let MiamiDx act as a SOCKS
server for other machines on your network then you need to keep SOCKS
disabled on this page, and enable the SOCKS server (daemon) instead, in
@{"TCP/IP LAN-Connect SocksD" Link "NODE_CONFIG_OTHER_LANCONNECT_SOCKSD"}.


 @{" Enable SOCKS " Link "NODE_CONFIG_SOCKS_ENABLE"}                                   The `Enable SOCKS' gadget
 @{" Allow DNS forwarding " Link "NODE_CONFIG_SOCKS_DNS"}                           The `Allow DNS forwarding' gadget
 @{" Default SOCKS Server " Link "NODE_CONFIG_SOCKS_SERVER"}                           The `Default SOCKS server' gadgets
 @{" Maximum Syslog level " Link "NODE_CONFIG_SOCKS_MAXLOG"}                           The `Maximum Syslog level' gadget
 @{" Authentication " Link "NODE_CONFIG_SOCKS_AUTH"}                                 The `Authentication' gadgets


@EndNode

@Node "NODE_CONFIG_SOCKS_ENABLE" "MiamiDx.guide/NODE_CONFIG_SOCKS_ENABLE"
@Next "NODE_CONFIG_SOCKS_DNS"
@Toc "NODE_CONFIG_SOCKS"

Enable SOCKS
------------

   If this gadget is enabled then MiamiDx uses SOCKS to connect to any
machine not directly reachable through any interface. You also need to
configure the SOCKS server IP address, port and, with some SOCKS
servers, authentication.


@EndNode

@Node "NODE_CONFIG_SOCKS_DNS" "MiamiDx.guide/NODE_CONFIG_SOCKS_DNS"
@Next "NODE_CONFIG_SOCKS_SERVER"
@Prev "NODE_CONFIG_SOCKS_ENABLE"
@Toc "NODE_CONFIG_SOCKS"

Allow DNS forwarding
--------------------

   If this gadget is enabled then MiamiDx will not try to resolve host
names into IP addresses by itself, but will rather forward them to the
SOCKS server. Usually this gadget should be enabled.


@EndNode

@Node "NODE_CONFIG_SOCKS_SERVER" "MiamiDx.guide/NODE_CONFIG_SOCKS_SERVER"
@Next "NODE_CONFIG_SOCKS_MAXLOG"
@Prev "NODE_CONFIG_SOCKS_DNS"
@Toc "NODE_CONFIG_SOCKS"

Default SOCKS server
--------------------

   These gadgets define the IP address and port number of the default
SOCKS server in your network. The port number for SOCKS is usually 1080.


@EndNode

@Node "NODE_CONFIG_SOCKS_MAXLOG" "MiamiDx.guide/NODE_CONFIG_SOCKS_MAXLOG"
@Next "NODE_CONFIG_SOCKS_AUTH"
@Prev "NODE_CONFIG_SOCKS_SERVER"
@Toc "NODE_CONFIG_SOCKS"

Maximum Syslog level
--------------------

   This gadget defines how many diagnostic messages you want to receive
from the SOCKS wrapper. You should usually keep this gadget at "none"
or "error". Higher settings are useful to get additional diagnostic
messages during debugging.


@EndNode

@Node "NODE_CONFIG_SOCKS_AUTH" "MiamiDx.guide/NODE_CONFIG_SOCKS_AUTH"
@Prev "NODE_CONFIG_SOCKS_MAXLOG"
@Toc "NODE_CONFIG_SOCKS"

Authentication
--------------

   These gadgets specify the authentication data sent to the SOCKS
server. The following authentication methods are possible:

@{b}none@{ub}
     No authentication data is sent. This only works with SOCKS servers
     that do not require authentication.

@{b}same as in dialer@{ub}
     MiamiDx sends the username/password combination you defined in the
     dialer to the SOCKS server.

@{b}username/password@{ub}
     MiamiDx sends the username/password combination specified in the
     gadgets below to the SOCKS server.


@EndNode

@Node "NODE_CONFIG_OTHER" "MiamiDx.guide/NODE_CONFIG_OTHER"
@Prev "NODE_CONFIG_SOCKS"
@Toc "NODE_CONFIG"

Other dialog windows
====================

   This section describes all intermediate dialog windows used by
MiamiDx.


 @{" Hardware type " Link "NODE_CONFIG_OTHER_HWTYPE"}                                                  Hardware type
 @{" Hardware definition " Link "NODE_CONFIG_OTHER_HWDEF"}                                            Hardware definition
 @{" Modem settings " Link "NODE_CONFIG_OTHER_HWMODEM"}                                                 Modem settings
 @{" MNI/SANA-II parameters " Link "NODE_CONFIG_OTHER_HWMNISANA"}                                         MNI/SANA-II parameters
 @{" MNI boards found " Link "NODE_CONFIG_OTHER_HWMNIBOARDS"}                                               MNI boards found
 @{" Dialer definition " Link "NODE_CONFIG_OTHER_DIALERDEF"}                                              Dialer definition
 @{" Interface type " Link "NODE_CONFIG_OTHER_IFACETYPE"}                                                 Interface type
 @{" Interface definition " Link "NODE_CONFIG_OTHER_IFACEDEF"}                                           Interface definition
 @{" Interface logging " Link "NODE_CONFIG_OTHER_IFACELOG"}                                              Interface logging
 @{" Interface PPP settings " Link "NODE_CONFIG_OTHER_IFACEPPP"}                                         Interface PPP settings
 @{" Interface Auto-connect/disconnect " Link "NODE_CONFIG_OTHER_IFACEAUTO"}                              Interface Auto-connect/disconnect
 @{" Interface Manual routes/aliases " Link "NODE_CONFIG_OTHER_IFACEROUTES"}                                Interface Manual routes/aliases
 @{" Interface TCP/IP settings " Link "NODE_CONFIG_OTHER_IFACETCPIP"}                                      Interface TCP/IP settings
 @{" Interface Events " Link "NODE_CONFIG_OTHER_IFACEEVENTS"}                                               Interface Events
 @{" LAN-Connect " Link "NODE_CONFIG_OTHER_LANCONNECT"}                                                    LAN-Connect
 @{" IP-NAT redirection " Link "NODE_CONFIG_OTHER_IPNATREDIR"}                                             IP-Nat redirection
 @{" Control panel settings " Link "NODE_CONFIG_OTHER_PANEL"}                                         Control panel settings


@EndNode

@Node "NODE_CONFIG_OTHER_HWTYPE" "MiamiDx.guide/NODE_CONFIG_OTHER_HWTYPE"
@Next "NODE_CONFIG_OTHER_HWDEF"
@Toc "NODE_CONFIG_OTHER"

Hardware type
-------------

   This window is displayed when you create a new hardware entry. You
need to specify what kind of hardware entry you are adding. The choices
are:

@{b}Serial@{ub}
     For serial connections using PPP or (C)SLIP. Includes modem
     connections and null-modem connections.

@{b}Ethernet@{ub}
     For Ethernet connections.

@{b}Arcnet@{ub}
     For Arcnet connections.

@{b}other bus/ring@{ub}
     For other SANA-II hardware which operates as a bus or ring, as
     multidrop hardware (i.e. allows more than two machines to be
     connected to the same hardware).

@{b}point-to-point@{ub}
     For SANA-II hardware which operates as a point-to-point connection
     (i.e.  which connects exactly two machines).

   After choosing a hardware type MiamiDx displays the
@{"Hardware definition" Link "NODE_CONFIG_OTHER_HWDEF"} dialog.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF"
@Next "NODE_CONFIG_OTHER_HWMODEM"
@Prev "NODE_CONFIG_OTHER_HWTYPE"
@Toc "NODE_CONFIG_OTHER"

Hardware definition
-------------------

   This window allows you to edit most parameters of a hardware
definition.  The exact contents of the window depend on the type of
hardware you are editing, i.e. not all parameters are applicable to all
hardware types.

   For some hardware types the following gadgets open other dialog
windows:

@{b}Modem settings@{ub}
     For serial connections only: displays the @{"Modem settings" Link "NODE_CONFIG_OTHER_HWMODEM"} dialog.

@{b}SANA-II parameters@{ub}
     For hardware definitions using a SANA-II driver only: displays the
     @{"MNI/SANA-II parameters" Link "NODE_CONFIG_OTHER_HWMNISANA"} dialog.

@{b}Find boards@{ub}
     For Ethernet definitions using an MNI driver only: tries to find
     Ethernet boards supported by the current MNI driver. If boards are
     found then the @{"MNI Boards found" Link "NODE_CONFIG_OTHER_HWMNIBOARDS"} dialog is displayed.

@{b}MNI parameters@{ub}
     For Ethernet definitions using an MNI driver only: displays the
     @{"MNI/SANA-II parameters" Link "NODE_CONFIG_OTHER_HWMNISANA"} dialog.

   The following settings are available in the "Hardware definition"
window.  Not all of them appear with all hardware types:


 @{" Name " Link "NODE_CONFIG_OTHER_HWDEF_NAME"}                                         Name
 @{" Type " Link "NODE_CONFIG_OTHER_HWDEF_TYPE"}                                         Type
 @{" Driver " Link "NODE_CONFIG_OTHER_HWDEF_DRIVER"}                                       Driver
 @{" Unit " Link "NODE_CONFIG_OTHER_HWDEF_UNIT"}                                         Unit
 @{" Speed " Link "NODE_CONFIG_OTHER_HWDEF_SPEED"}                                        Speed
 @{" Use CD " Link "NODE_CONFIG_OTHER_HWDEF_USECD"}                                       Use CD
 @{" Flow control " Link "NODE_CONFIG_OTHER_HWDEF_FLOW"}                                 Flow control
 @{" EOF mode " Link "NODE_CONFIG_OTHER_HWDEF_EOF"}                                     EOF mode
 @{" MTU " Link "NODE_CONFIG_OTHER_HWDEF_MTU"}                                          MTU
 @{" Serial mode " Link "NODE_CONFIG_OTHER_HWDEF_SERMODE"}                                  Serial mode
 @{" MNI options " Link "NODE_CONFIG_OTHER_HWDEF_MNIOPT"}                                  MNI options
 @{" Mapping " Link "NODE_CONFIG_OTHER_HWDEF_MAPPING"}                                      Mapping


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_NAME" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_NAME"
@Next "NODE_CONFIG_OTHER_HWDEF_TYPE"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Name
....

   The name of the hardware definition. You can assign any name you
want, but should make it as descriptive as possible. Names can be up to
31 characters in length, and can consist of letters and digits.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_TYPE" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_TYPE"
@Next "NODE_CONFIG_OTHER_HWDEF_DRIVER"
@Prev "NODE_CONFIG_OTHER_HWDEF_NAME"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Type
....

   The type (subtype actually) of this hardware. The exact meaning
depends on the type of hardware:

@{b}For serial hardware@{ub}
     If you want to use the Amiga's built-in serial port then you have
     the choice of either using MiamiDx's built-in serial driver
     (recommended) or one of the other available drivers, e.g.
     "serial.device" or "artser.device". For other serial ports (e.g.
     on Zorro-II serial boards) you need to use the
     manufacturer-provided serial driver.

@{b}For Ethernet hardware@{ub}
     You have the choice of using an MNI driver (a driver specifically
     designed for MiamiDx, recommended) or a manufacturer-provided
     standard SANA-II driver. Please see @{"MNI Ethernet drivers" Link "NODE_SPECIFICATIONS_MNI"} for more
     information on MNI drivers. Not all Ethernet boards are supported
     by MNI yet.

@{b}For Arcnet hardware@{ub}
     You have the choice between two different standards of running
     TCP/IP across Arcnet: "old Arcnet" uses the standard "old" RFC1051
     Arcnet encapsulation, which is more popular on Amiga networks than
     the "new" RFC1201 encapsulation.  Use the "old" encapsulation when
     you need to connect your Amiga to AmiTCP/IP, Inet-225 or NetBSD
     1.1. "new Arcnet" uses the "new" RFC1201 encapsulation. It does not
     interoperate with AmiTCP/IP or NetBSD 1.1, but you might need this
     "new" standard if you want to connect your machine to other
     platforms such as Windows 95.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_DRIVER" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_DRIVER"
@Next "NODE_CONFIG_OTHER_HWDEF_UNIT"
@Prev "NODE_CONFIG_OTHER_HWDEF_TYPE"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Driver
......

   Use this gadget to enter the name of the driver you want to use.
Depending on the type of interface this can either be a serial device,
a SANA-II device or an MNI driver. You also need to set the unit number
correctly.

   Warning: if you want to use the built-in serial port for PPP or
(C)SLIP then it is very strongly recommended to use either the built-in
serial driver in MiamiDx or "artser.device". Other drivers such as
"8n1.device", "BaudBandit.device" and "v34serial.device" have caused
problems for many users (usually random crashes and lockups during
operation).


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_UNIT" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_UNIT"
@Next "NODE_CONFIG_OTHER_HWDEF_SPEED"
@Prev "NODE_CONFIG_OTHER_HWDEF_DRIVER"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Unit
....

   This gadget is used to set the unit number of your driver. For
SANA-II devices the unit number is usually zero (with some exceptions,
e.g. PLIP).  For serial devices the unit is often zero as well, in
particular if the driver only supports a single port. Serial drivers
supporting multiple ports may require different unit numbers. For MNI
drivers you should not set the unit number manually, but rather click
on "Find boards" and then select a board from the list to let MiamiDx
set the unit number correctly for you.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_SPEED" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_SPEED"
@Next "NODE_CONFIG_OTHER_HWDEF_USECD"
@Prev "NODE_CONFIG_OTHER_HWDEF_UNIT"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Speed
.....

   This gadget sets the speed of your serial port for serial interfaces.

   For the internal serial port you should use 19200, 38400 or (if you
have a fast CPU and a graphics board) 57600. For serial boards you
might even be able to use 115200 or 230400.

   Do not use 31250. This speed is reserved for MIDI only and usually
does not work with modems.

   Do not use 14400, 28800 or 33600 either. Your modem might be able to
connect to the other modem at these speeds, but it does probably not
support these speeds on its serial port.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_USECD" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_USECD"
@Next "NODE_CONFIG_OTHER_HWDEF_FLOW"
@Prev "NODE_CONFIG_OTHER_HWDEF_SPEED"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Use CD
......

   For serial devices only:

   If "Use CD" is activated then MiamiDx uses the "Carrier Detect" line
of your modem to determine if your modem is already connected to the
other side or not.

   This can be useful if you reset your Amiga without dropping the line,
so you can restart MiamiDx and reconnect to your provider without
redialing.

   This option can only be used if your modem has been configured to
correctly set the "Carrier Detect" line according to the line state.

   Some modems have factory default settings that always set the
"Carrier Detect" line to high, even if the modem is not connected.  If
this is true for your modem then you either have to change the modem
settings in your modem init string (usually "AT&C1") and then save the
modem settings to NV-RAM from a terminal program (usually "AT&W"), or
switch off the "Use CD" option.

   If you are using the null-modem settings (configured in
@{"Modem settings" Link "NODE_CONFIG_OTHER_HWMODEM"}) then this gadget gets a different meaning:

   @{b}*@{ub} If the gadget is activated then the dial script is not executed at
     all.

   @{b}*@{ub} If the gadget is deactivated then the dial script is executed,
     except that Miami does not dial a number, i.e. the "ATDT..."
     command is skipped, and the list of phone numbers is meaningless.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_FLOW" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_FLOW"
@Next "NODE_CONFIG_OTHER_HWDEF_EOF"
@Prev "NODE_CONFIG_OTHER_HWDEF_USECD"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Flow control
............

   This option is available for serial devices using external serial
drivers only. The builtin serial driver always uses RTS/CTS.

   MiamiDx supports two types of flow control: hardware handshaking
(RTS/CTS) and software handshaking (Xon/Xoff). By default hardware
handshaking is used, and it is strongly recommended that you do not
change this.

   If you cannot use hardware handshaking (usually because of a
defective modem, cable or serial port) you should switch to software
handshaking. However make sure that you change your modem init string
(in the dialer window) appropriately. Also, software handshaking is
only possible with PPP, not with SLIP/CSLIP.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_EOF" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_EOF"
@Next "NODE_CONFIG_OTHER_HWDEF_MTU"
@Prev "NODE_CONFIG_OTHER_HWDEF_FLOW"
@Toc "NODE_CONFIG_OTHER_HWDEF"

EOF mode
........

   This option is available for serial devices using external serial
drivers only. The builtin serial driver always has EOF-mode enabled.

   There are two ways for MiamiDx to detect the end of incoming
packets: The more efficient one (using less CPU time) uses the EOF_MODE
flag. However this is only possible if the serial driver you use
supports EOF-mode. Many third-party drivers do not.

   Usually you should leave this switch in the "auto" setting to let
MiamiDx use the default setting. If you positively know whether your
driver supports EOF-mode or not then you can manually override the
default setting by choosing "on" or "off".


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_MTU" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_MTU"
@Next "NODE_CONFIG_OTHER_HWDEF_SERMODE"
@Prev "NODE_CONFIG_OTHER_HWDEF_EOF"
@Toc "NODE_CONFIG_OTHER_HWDEF"

MTU
...

   This option is available for serial devices only. The MTU value for
SANA-II devices is set through @{"MNI/SANA-II parameters" Link "NODE_CONFIG_OTHER_HWMNISANA"}.

   Maximum Transfer Unit, i.e. the size of the largest packet
transferred at a time.

   Recommended values are:

   @{b}*@{ub} for modem speeds up to 19200 bps: MTU=296

   @{b}*@{ub} for modem speeds higher than 19200 bps: MTU=552

   Please note that changing the MTU value in the configuration window
does not necessarily mean that the maximum packet size is actually
changed to this value:

   (C)SLIP does not have any means to negotiate MTU, i.e. the MTU value
configured here only affects the size of outgoing packets, not the size
of incoming packets.

   PPP has configuration options to negotiate the MTU. MiamiDx always
tries to negotiate the MTU you specified here, but the other side might
disagree and force a different MTU value, in which case MiamiDx might
have to use the value suggested by the other side for one or both
directions.

   Also note: For PPP the MTU value is not critical, i.e. your
connection will still work if the MTU value you selected is higher or
lower than the optimum value. However for (C)SLIP you @{i}must@{ui} make sure
that your MTU value is @{i}not higher than@{ui} the MTU value at your Internet
provider.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_SERMODE" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_SERMODE"
@Next "NODE_CONFIG_OTHER_HWDEF_MNIOPT"
@Prev "NODE_CONFIG_OTHER_HWDEF_MTU"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Serial mode
...........

   This option is available for serial devices using external serial
drivers only. The builtin serial driver always uses 8N1.

   The settings for the number of data bits and parity used during
dialing.  For 99% of all providers the correct settings are 8N1. Very
few providers (e.g. some dial-in points for Compuserve) might require
7E1 or 7O1.

   Please note that these settings only apply during dialing and login.
The (C)SLIP/PPP protocol phases always use 8N1, regardless of the
setting you specified here. It is completely impossible to use PPP or
(C)SLIP across a 7-bit line - with any implementation actually. This is
not a limitation in MiamiDx.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_MNIOPT" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_MNIOPT"
@Next "NODE_CONFIG_OTHER_HWDEF_MAPPING"
@Prev "NODE_CONFIG_OTHER_HWDEF_SERMODE"
@Toc "NODE_CONFIG_OTHER_HWDEF"

MNI options
...........

   This option is available for MNI drivers only.

   The gadget "MNI Options" allows you to enter parameters to configure
the behavior of the MNI driver in more detail. The types of options you
can use vary with each driver. Please check @{"MNI Ethernet drivers" Link "NODE_SPECIFICATIONS_MNI"} for
more information on MNI drivers and supported options.


@EndNode

@Node "NODE_CONFIG_OTHER_HWDEF_MAPPING" "MiamiDx.guide/NODE_CONFIG_OTHER_HWDEF_MAPPING"
@Prev "NODE_CONFIG_OTHER_HWDEF_MNIOPT"
@Toc "NODE_CONFIG_OTHER_HWDEF"

Mapping
.......

   This option is available for SANA-II Arcnet devices only.

   Arcnet supports two different standards to map IP addresses to
hardware addresses:

@{b}Arp@{ub}
     Arp (Address resolution protocol) is used. This is the recommended
     default, and is also what AmiTCP/IP uses.

@{b}direct@{ub}
     The least-significant 8 bits of the IP address are mapped to the
     hardware address. This is what NetBSD 1.1 uses.

   If you have at least one NetBSD 1.1 machine in your Arcnet network
then you can make life easier for you by choosing "direct" mapping
instead of creating manual Arp entries on all machines.

   In all other cases you should choose "Arp" on all machines. Newer
("current") versions of NetBSD 1.2 and higher support Arp for Arcnet.
If you are using one of these newer NetBSD versions then please select
"Arp" mapping in MiamiDx.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMODEM" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMODEM"
@Next "NODE_CONFIG_OTHER_HWMNISANA"
@Prev "NODE_CONFIG_OTHER_HWDEF"
@Toc "NODE_CONFIG_OTHER"

Modem settings
--------------

   This window allows to change the configuration of your modem.


 @{" DTR mode " Link "NODE_CONFIG_OTHER_HWMODEM_DTR"}                                      DTR mode
 @{" Init string " Link "NODE_CONFIG_OTHER_HWMODEM_INIT"}                                   Init string
 @{" Exit string " Link "NODE_CONFIG_OTHER_HWMODEM_EXIT"}                                   Exit string
 @{" Dial prefix " Link "NODE_CONFIG_OTHER_HWMODEM_PREFIX"}                                   Dial prefix
 @{" Dial suffix " Link "NODE_CONFIG_OTHER_HWMODEM_SUFFIX"}                                   Dial suffix
 @{" Escape char " Link "NODE_CONFIG_OTHER_HWMODEM_ESCAPE"}                                   Escape char
 @{" Null modem " Link "NODE_CONFIG_OTHER_HWMODEM_NULL"}                                    Null modem


@EndNode

@Node "NODE_CONFIG_OTHER_HWMODEM_DTR" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMODEM_DTR"
@Next "NODE_CONFIG_OTHER_HWMODEM_INIT"
@Toc "NODE_CONFIG_OTHER_HWMODEM"

DTR mode
........

   This option defines how the DTR line will be used by MiamiDx. The
following options exist:

@{b}ignore@{ub}
     This is the default. MiamiDx tells the modem to ignore the DTR
     line, and uses the escape sequence (+ + +, ATH) to hang up the
     line. The advantage is that this setting allows you to stay
     connected while your Amiga reboots. The disadvantage is that
     hanging up using the above sequence can take several sequence.
     Also, some buggy modems do not hang up reliably with this method.

@{b}drop to cmd mode@{ub}
     Not all modems support this option, and its use is discouraged at
     this time.

@{b}hangup@{ub}
     Use the DTR line to hang up. With this setting hangups are quicker
     than with "ignore", but the disadvantage is that the modem will
     also hang up the line when your Amiga reboots.

   Please note that just setting this option is not enough. The init
string of your modem has to be adjusted as well, so the modem handles
DTR changes correctly. MiamiDx usually does this automatically for you
if you are using a standard init string.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMODEM_INIT" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMODEM_INIT"
@Next "NODE_CONFIG_OTHER_HWMODEM_EXIT"
@Prev "NODE_CONFIG_OTHER_HWMODEM_DTR"
@Toc "NODE_CONFIG_OTHER_HWMODEM"

Init string
...........

   The initialization string for your modem, usually set by MiamiInit.
Please note that if you are using a standard init string MiamiDx will
automatically modify it whenever you change the "DTR mode" or "Escape
char" settings, to ensure that the modem remains in sync with MiamiDx.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMODEM_EXIT" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMODEM_EXIT"
@Next "NODE_CONFIG_OTHER_HWMODEM_PREFIX"
@Prev "NODE_CONFIG_OTHER_HWMODEM_INIT"
@Toc "NODE_CONFIG_OTHER_HWMODEM"

Exit string
...........

   The string sent to your modem when MiamiDx quits. Most users do not
need this, but it can be useful if multiple programs share the modem
port, and your modem needs to be reset to default settings before
MiamiDx exits.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMODEM_PREFIX" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMODEM_PREFIX"
@Next "NODE_CONFIG_OTHER_HWMODEM_SUFFIX"
@Prev "NODE_CONFIG_OTHER_HWMODEM_EXIT"
@Toc "NODE_CONFIG_OTHER_HWMODEM"

Dial prefix
...........

   The command your modem uses for dialing, i.e. the string prepended to
the phone number. This is usually "ATDT" or "ATDP".

   If you are dialing out through a PBX then you may want to add the
required prefix here, e.g. if you have to dial "9" to get an outside
line try "ATDT9W". The "W" waits for another dial tone after the prefix.

   If your PBX does not generate a proper dial tone (i.e. if you get an
error "NO DIALTONE" from your modem) then try something like "ATX1DT9W"
instead. The "X1" before the "D" dial command tells the modem to dial
even without a dial tone. The "W" at the end then waits for a dial tone
before dialing the external number.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMODEM_SUFFIX" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMODEM_SUFFIX"
@Next "NODE_CONFIG_OTHER_HWMODEM_ESCAPE"
@Prev "NODE_CONFIG_OTHER_HWMODEM_PREFIX"
@Toc "NODE_CONFIG_OTHER_HWMODEM"

Dial suffix
...........

   The string that needs to be appended to your phone number to complete
the dial command. This is usually "\\r".


@EndNode

@Node "NODE_CONFIG_OTHER_HWMODEM_ESCAPE" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMODEM_ESCAPE"
@Next "NODE_CONFIG_OTHER_HWMODEM_NULL"
@Prev "NODE_CONFIG_OTHER_HWMODEM_SUFFIX"
@Toc "NODE_CONFIG_OTHER_HWMODEM"

Escape char
...........

   The escape character your modem uses to drop to command mode.
Usually this is `+'. However recently there have been some
denial-of-service attacks via IRC in which users tried to send `+ + +'
to users in order to cause their modems to hang up. Because of that you
may want to set the escape character to a different special character,
e.g. `'.

   Please note that just setting this option is not enough. The init
string of your modem has to be adjusted as well, so the modem expects
the correct escape character. MiamiDx usually does this automatically
for you if you are using a standard init string.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMODEM_NULL" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMODEM_NULL"
@Prev "NODE_CONFIG_OTHER_HWMODEM_ESCAPE"
@Toc "NODE_CONFIG_OTHER_HWMODEM"

Null modem
..........

   MiamiDx usually assumes that you have a modem connected to your
serial port. If your Amiga is directly connected to another computer
using a null-modem cable, then you need to activate this gadget. It
prevents any modem commands ("AT commands") from being sent, and
MiamiDx will not wait for any responses such as "OK" or "CONNECT".

   With "null-modem" activated the meaning of the "Use CD" gadget in
your hardware definition changes:

   @{b}*@{ub} If your machine is connected to a computer that requires a login
     sequence to establish the SLIP/PPP link, then you should
     deactivate the "Use CD" gadget. MiamiDx then uses the dial script
     specified in the "Dialer" window, but without dialing a number
     first. This option is most useful when connecting to a Unix or
     Linux box that runs a getty with login/password check on its
     serial port.

   @{b}*@{ub} If your machine is connected to a computer that runs its serial
     port in dedicated SLIP/PPP mode (e.g. another Amiga running
     MiamiDx), then you should activate the "Use CD" gadget. MiamiDx
     will then completely bypass any dial script and immediately
     proceed with the protocol negotiation.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMNISANA" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMNISANA"
@Next "NODE_CONFIG_OTHER_HWMNIBOARDS"
@Prev "NODE_CONFIG_OTHER_HWMODEM"
@Toc "NODE_CONFIG_OTHER"

MNI/SANA-II parameters
----------------------

   This window is reached via the "MNI parameters" and "SANA-II
parameters" buttons in the @{"Hardware definition" Link "NODE_CONFIG_OTHER_HWDEF"} dialog.  It allows you
to change MNI- and SANA-II-specific parameters.

   In most cases you should initialize all of these values to default
values by clicking on "Query device" (only while MiamiDx is offline).
However you can manually override all values if necessary, e.g. if you
are using a new hardware type for which MiamiDx does not know the
correct default settings.


 @{" Hardware address " Link "NODE_CONFIG_OTHER_HWMNISANA_ADDR"}                                   Hardware address
 @{" IP type " Link "NODE_CONFIG_OTHER_HWMNISANA_IP"}                                            IP type
 @{" Arp type " Link "NODE_CONFIG_OTHER_HWMNISANA_ARP"}                                           Arp type
 @{" RArp type " Link "NODE_CONFIG_OTHER_HWMNISANA_RARP"}                                          RArp type
 @{" MTU " Link "NODE_CONFIG_OTHER_HWMNISANA_MTU"}                                                MTU
 @{" Query device " Link "NODE_CONFIG_OTHER_HWMNISANA_QUERY"}                                       Query


@EndNode

@Node "NODE_CONFIG_OTHER_HWMNISANA_ADDR" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMNISANA_ADDR"
@Next "NODE_CONFIG_OTHER_HWMNISANA_IP"
@Toc "NODE_CONFIG_OTHER_HWMNISANA"

Hardware address
................

   The hardware address of the device, with an option to override it.
(For bus/ring devices only.) Hardware addresses are specified as a
sequence of bytes in hexadecimal notation, separated by `:', e.g.
`01:23:45:67:89:ab'. Normally MiamiDx just displays the hardware
address of the device, but does not change it. However if you activate
"override" then the address you enter overrides the hardware address
hardcoded into the device. This can be useful for devices that do not
have a valid hardcoded address, e.g. ASDG LanRover Ethernet cards
without an address ROM.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMNISANA_IP" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMNISANA_IP"
@Next "NODE_CONFIG_OTHER_HWMNISANA_ARP"
@Prev "NODE_CONFIG_OTHER_HWMNISANA_ADDR"
@Toc "NODE_CONFIG_OTHER_HWMNISANA"

IP packet type
..............

   The link level packet type for IP. With SANA-II devices you also
need to specify the maximum number of IORequests MiamiDx should use
(should be between 10 and 30). For MNI this number is adjusted
automatically by MiamiDx.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMNISANA_ARP" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMNISANA_ARP"
@Next "NODE_CONFIG_OTHER_HWMNISANA_RARP"
@Prev "NODE_CONFIG_OTHER_HWMNISANA_IP"
@Toc "NODE_CONFIG_OTHER_HWMNISANA"

Arp packet type
...............

   The link level packet type for Arp. This option is only shown for
devices that (potentially) support Arp, such as Ethernet, Arcnet, and
bus/ring devices.  With SANA-II devices you also need to specify the
maximum number of IORequests MiamiDx should use (should be between 2
and 4). For MNI this number is adjusted automatically by MiamiDx.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMNISANA_RARP" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMNISANA_RARP"
@Next "NODE_CONFIG_OTHER_HWMNISANA_MTU"
@Prev "NODE_CONFIG_OTHER_HWMNISANA_ARP"
@Toc "NODE_CONFIG_OTHER_HWMNISANA"

RArp packet type
................

   The link level packet type for RArp. This option is only shown for
devices that (potentially) support RArp, such as Ethernet and bus/ring
devices.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMNISANA_MTU" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMNISANA_MTU"
@Next "NODE_CONFIG_OTHER_HWMNISANA_QUERY"
@Prev "NODE_CONFIG_OTHER_HWMNISANA_RARP"
@Toc "NODE_CONFIG_OTHER_HWMNISANA"

MTU
...

   MTU (Maximum Transfer Unit), i.e. the largest packet size supported
on this device. You should usually use the value MiamiDx determines
after clicking on @{"Query device" Link "NODE_CONFIG_OTHER_HWMNISANA_QUERY"}.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMNISANA_QUERY" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMNISANA_QUERY"
@Prev "NODE_CONFIG_OTHER_HWMNISANA_MTU"
@Toc "NODE_CONFIG_OTHER_HWMNISANA"

Query device
............

   If you click on this button MiamiDx asks the device for the
preferred values of all parameters. You should always use this function
when you configure a device for the first time, in order to get useful
start values.


@EndNode

@Node "NODE_CONFIG_OTHER_HWMNIBOARDS" "MiamiDx.guide/NODE_CONFIG_OTHER_HWMNIBOARDS"
@Next "NODE_CONFIG_OTHER_DIALERDEF"
@Prev "NODE_CONFIG_OTHER_HWMNISANA"
@Toc "NODE_CONFIG_OTHER"

MNI Boards found
----------------

   This dialog window is displayed after clicking on the "Find boards"
button in the MNI @{"Hardware definition" Link "NODE_CONFIG_OTHER_HWDEF"} window.  It displays all boards
in the system that are supported by the currently selected MNI driver.
The information displayed consists of the board name and the unit
number you need to use with MNI to access the board.

   In order to select a board click on it to highlight the list entry,
then click on "OK" to use that board and set the MNI unit number
correctly.


@EndNode

@Node "NODE_CONFIG_OTHER_DIALERDEF" "MiamiDx.guide/NODE_CONFIG_OTHER_DIALERDEF"
@Next "NODE_CONFIG_OTHER_IFACETYPE"
@Prev "NODE_CONFIG_OTHER_HWMNIBOARDS"
@Toc "NODE_CONFIG_OTHER"

Dialer definition
-----------------

   This window allows you to edit a dialer definition.


 @{" Name " Link "NODE_CONFIG_OTHER_DIALERDEF_NAME"}                                                   Name
 @{" Dial script " Link "NODE_CONFIG_OTHER_DIALERDEF_SCRIPT"}                                            Dial script
 @{" Phone numbers " Link "NODE_CONFIG_OTHER_DIALERDEF_PHONE"}                                          Phone numbers
 @{" Max Repeat " Link "NODE_CONFIG_OTHER_DIALERDEF_MAX"}                                             Max Repeat
 @{" Repeat Delay " Link "NODE_CONFIG_OTHER_DIALERDEF_DELAY"}                                           Repeat Delay
 @{" Redial Delay " Link "NODE_CONFIG_OTHER_DIALERDEF_RDELAY"}                                           Redial Delay
 @{" Login ID / Password " Link "NODE_CONFIG_OTHER_DIALERDEF_LOGIN"}                                    Login ID / Password


@EndNode

@Node "NODE_CONFIG_OTHER_DIALERDEF_NAME" "MiamiDx.guide/NODE_CONFIG_OTHER_DIALERDEF_NAME"
@Next "NODE_CONFIG_OTHER_DIALERDEF_SCRIPT"
@Toc "NODE_CONFIG_OTHER_DIALERDEF"

Name
....

   The name of the dialer definition. You can assign any name you want,
but should make it as descriptive as possible. Names can be up to 31
characters in length, and can consist of letters and digits.


@EndNode

@Node "NODE_CONFIG_OTHER_DIALERDEF_SCRIPT" "MiamiDx.guide/NODE_CONFIG_OTHER_DIALERDEF_SCRIPT"
@Next "NODE_CONFIG_OTHER_DIALERDEF_PHONE"
@Prev "NODE_CONFIG_OTHER_DIALERDEF_NAME"
@Toc "NODE_CONFIG_OTHER_DIALERDEF"

Dial script
...........

   The listview gadget in the top area of the "Dial script" group
contains the dial script. You can change entries by clicking on them
and editing them in the string gadget below.

   The gadgets at the bottom are used to add and remove entries from
the dial script.

   For more information about the language used by the dialer please see
@{"Dialer command language" Link "NODE_SPECIFICATIONS_DIALER"}.

   The listview has a context menu associated with it, i.e. if you
press the right mouse button over the listview a menu pops up allowing
you to import/export the dial script from/to an ASCII text file.


@EndNode

@Node "NODE_CONFIG_OTHER_DIALERDEF_PHONE" "MiamiDx.guide/NODE_CONFIG_OTHER_DIALERDEF_PHONE"
@Next "NODE_CONFIG_OTHER_DIALERDEF_MAX"
@Prev "NODE_CONFIG_OTHER_DIALERDEF_SCRIPT"
@Toc "NODE_CONFIG_OTHER_DIALERDEF"

Phone numbers
.............

   The "Phone numbers" group works similarly to the "Dial script" group,
but has two additional gadgets: "Enable" and "Disable". Enabled phone
numbers have a ">>" symbol next to them. Only enabled phone numbers will
be used during dialing.

   In the demo version only up to three phone numbers are supported. In
the registered version there is no such limit.


@EndNode

@Node "NODE_CONFIG_OTHER_DIALERDEF_MAX" "MiamiDx.guide/NODE_CONFIG_OTHER_DIALERDEF_MAX"
@Next "NODE_CONFIG_OTHER_DIALERDEF_DELAY"
@Prev "NODE_CONFIG_OTHER_DIALERDEF_PHONE"
@Toc "NODE_CONFIG_OTHER_DIALERDEF"

Max repeat
..........

   If no connection can be established with any of the listed phone
numbers, then MiamiDx waits for the time specified in @{"Repeat Delay" Link "NODE_CONFIG_OTHER_DIALERDEF_DELAY"}, and
then tries again, restarting with the first phone number. However the
maximum number of retries is limited by the number specified in the
"Max Repeat" gadget. After that MiamiDx just gives up and aborts
dialing.


@EndNode

@Node "NODE_CONFIG_OTHER_DIALERDEF_DELAY" "MiamiDx.guide/NODE_CONFIG_OTHER_DIALERDEF_DELAY"
@Next "NODE_CONFIG_OTHER_DIALERDEF_RDELAY"
@Prev "NODE_CONFIG_OTHER_DIALERDEF_MAX"
@Toc "NODE_CONFIG_OTHER_DIALERDEF"

Repeat delay
............

   If no connection can be established with any of the listed phone
number, then MiamiDx waits for the time specified in the "Repeat Delay"
gadget and then tries again, restarting with the first phone number.


@EndNode

@Node "NODE_CONFIG_OTHER_DIALERDEF_RDELAY" "MiamiDx.guide/NODE_CONFIG_OTHER_DIALERDEF_RDELAY"
@Next "NODE_CONFIG_OTHER_DIALERDEF_LOGIN"
@Prev "NODE_CONFIG_OTHER_DIALERDEF_DELAY"
@Toc "NODE_CONFIG_OTHER_DIALERDEF"

Redial delay
............

   This value specifies the delay between successive dial attempts (for
different phone numbers). Usually you want this value to be zero, i.e.
have MiamiDx dial one number immediately after the first number was
busy.

   However some European modems require minimum delays between
successive dial attempts. If you have one of these modems then you need
to set the "Redial Delay" to a value large enough for your modem.


@EndNode

@Node "NODE_CONFIG_OTHER_DIALERDEF_LOGIN" "MiamiDx.guide/NODE_CONFIG_OTHER_DIALERDEF_LOGIN"
@Prev "NODE_CONFIG_OTHER_DIALERDEF_RDELAY"
@Toc "NODE_CONFIG_OTHER_DIALERDEF"

Login ID / Password
...................

   The login id and password used in the dial script. If "Same as in
dialer" is enabled in the PPP window then these values are also used
for PAP/CHAP.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETYPE" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETYPE"
@Next "NODE_CONFIG_OTHER_IFACEDEF"
@Prev "NODE_CONFIG_OTHER_DIALERDEF"
@Toc "NODE_CONFIG_OTHER"

Interface type
--------------

   This window is displayed when you create a new interface entry. You
need to specify what type of interface entry you are adding, and
whether the interface is an "Internet" interface (untrusted, connecting
to a public network) or a "LAN" interface (trusted, connecting to a
local network).  The choices for "interface type" are:

@{b}PPP dial-out@{ub}
     A PPP interface to connect to a PPP server.

@{b}(C)SLIP dial-out@{ub}
     A (C)SLIP interface to connect to a (C)SLIP server.

@{b}Ethernet@{ub}
     For Ethernet connections.

@{b}Arcnet@{ub}
     For Arcnet connections.

@{b}other bus/ring@{ub}
     For other SANA-II devices which operate as a bus or ring, as
     multidrop devices (i.e. allow more than two machines to be
     connected to the same hardware).

@{b}point-to-point@{ub}
     For SANA-II devices which operate as a point-to-point connection
     (i.e.  which connect exactly two machines).

   After making your selection MiamiDx will ask you for the hardware
definition you want to use for this interface and, for "PPP dial-out"
and "(C)SLIP dial-out", for the dialer definition you want to use.
After that MiamiDx displays the @{"Interface definition" Link "NODE_CONFIG_OTHER_IFACEDEF"} dialog which
allows you to configure the details for the new interface.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF"
@Next "NODE_CONFIG_OTHER_IFACELOG"
@Prev "NODE_CONFIG_OTHER_IFACETYPE"
@Toc "NODE_CONFIG_OTHER"

Interface definition
--------------------

   This is the main interface configuration window. Most
interface-specific configuration settings are defined here. There are
several buttons that will open additional windows to configure other
parts of the interface configuration. These buttons include:

@{b}Logging@{ub}
     Only for PPP and (C)SLIP interfaces. This button opens the @{"Logging" Link "NODE_CONFIG_OTHER_IFACELOG"}
     window, allowing you to configure the dialer log, a dialer capture
     and, for PPP interfaces, the PPP protocol log.

@{b}PPP settings@{ub}
     Only for PPP interfaces. This buttons opens the @{"PPP settings" Link "NODE_CONFIG_OTHER_IFACEPPP"}
     window which allows you to configure settings specifically for PPP.

@{b}Auto-connect/disconnect@{ub}
     This button displays the @{"Auto-connect/disconnect" Link "NODE_CONFIG_OTHER_IFACEAUTO"} dialog where you
     can configure "dial-on demand" and "hang-up on inactivity".

@{b}Manual routes/aliases@{ub}
     The @{"Manual routes/aliases" Link "NODE_CONFIG_OTHER_IFACEROUTES"} window opened by this button is for
     advanced users only. It allows you to configure different types of
     manual interface routes. Do not add any routes unless you have a
     thorough understanding of this topic.

@{b}TCP/IP settings@{ub}
     This button opens the @{"TCP/IP settings" Link "NODE_CONFIG_OTHER_IFACETCPIP"} window, which configures
     several higher-level features built on top of the TCP/IP protocol
     suite, such as DNS configuration for this interface and DHCP.

@{b}Events@{ub}
     The @{"Events" Link "NODE_CONFIG_OTHER_IFACEEVENTS"} window opened by this button allows you to specify how
     MiamiDx should react to interface events, such as interfaces going
     online or offline.


 @{" Name " Link "NODE_CONFIG_OTHER_IFACEDEF_NAME"}                                                    Name
 @{" Alias " Link "NODE_CONFIG_OTHER_IFACEDEF_ALIAS"}                                                   Alias
 @{" Type " Link "NODE_CONFIG_OTHER_IFACEDEF_TYPE"}                                                    Type
 @{" Hardware " Link "NODE_CONFIG_OTHER_IFACEDEF_HW"}                                                Hardware
 @{" Hardware priority " Link "NODE_CONFIG_OTHER_IFACEDEF_HWPRI"}                                       Hardware priority
 @{" Dialer " Link "NODE_CONFIG_OTHER_IFACEDEF_DIALER"}                                                  Dialer
 @{" IP type/address " Link "NODE_CONFIG_OTHER_IFACEDEF_IP"}                                         IP type/address
 @{" Netmask type/address " Link "NODE_CONFIG_OTHER_IFACEDEF_MASK"}                                    Netmask type/address
 @{" Gateway type/address/pri " Link "NODE_CONFIG_OTHER_IFACEDEF_GW"}                                Gateway type/address/pri
 @{" Multicasts/pri " Link "NODE_CONFIG_OTHER_IFACEDEF_MCASTS"}                                          Multicasts pri
 @{" Control panel " Link "NODE_CONFIG_OTHER_IFACEDEF_PANEL"}                                           Control panel
 @{" GUI default " Link "NODE_CONFIG_OTHER_IFACEDEF_GUIDEFAULT"}                                             GUI default


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_NAME" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_NAME"
@Next "NODE_CONFIG_OTHER_IFACEDEF_ALIAS"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Name
....

   System-assigned interface name. This name may change every time
settings are loaded.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_ALIAS" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_ALIAS"
@Next "NODE_CONFIG_OTHER_IFACEDEF_TYPE"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_NAME"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Alias
.....

   Alias for this interface definition. You can assign any name you
want, but should make it as descriptive as possible. Names can be up to
8 characters in length, and can consist of letters and digits.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_TYPE" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_TYPE"
@Next "NODE_CONFIG_OTHER_IFACEDEF_HW"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_ALIAS"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Type
....

   The type of the interface, as defined when the interface was created.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_HW" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_HW"
@Next "NODE_CONFIG_OTHER_IFACEDEF_HWPRI"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_TYPE"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Hardware
........

   Name of the hardware entry this interface is associated with. The
hardware type has to match the interface type.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_HWPRI" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_HWPRI"
@Next "NODE_CONFIG_OTHER_IFACEDEF_DIALER"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_HW"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Hardware priority
.................

   If multiple interface definitions reference the same hardware entry,
then there is the issue of whether taking one interface online while
the hardware is in use by another interface should automatically take
the currently active interface offline, or whether such a conflicting
attempt to go online should cause an error. This is determined by the
"Hardware priority" setting.  The rule is that interfaces with higher
hardware priorities automatically cause interfaces with lower hardware
priorities to go offline when they are referencing the same hardware.

   This option is primarily useful if dial-in and dial-out interfaces
reference the same hardware, and you want to be able to automatically
"kick out" any dial-in user when you want to use your serial port and
modem for dial-out operation. (Note: dial-in is not supported by Miami
Deluxe yet).

   The "Hardware priority" does NOT affect performance in any way. It
is NOT related to task priorities or interrupt priorities.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_DIALER" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_DIALER"
@Next "NODE_CONFIG_OTHER_IFACEDEF_IP"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_HWPRI"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Dialer
......

   For PPP/(C)SLIP dial-out interfaces only: name of the dialer entry
this interface is associated with.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_IP" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_IP"
@Next "NODE_CONFIG_OTHER_IFACEDEF_MASK"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_DIALER"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

IP type/address
...............

   Internet providers usually offer two types of Internet connections:
those with a static IP address permanently assigned to your Amiga, or
(more popular) those where your Amiga receives a dynamic IP address
each time you connect.

@{b}For serial interfaces:@{ub}
     If your Amiga has a fixed IP address choose "static" and enter the
     IP address your provider told you. If your provider assigns you a
     dynamic IP address for each connection choose "dynamic", and
     MiamiDx determines the IP address automatically when you connect.

     If you use TIA or Slirp you have to choose "static" and enter the
     pseudo IP address that TIA or Slirp assign to your Amiga. Please
     see the TIA/Slirp docs for more information about this.

@{b}For SANA-II point-to-point interfaces:@{ub}
     If your machine has a fixed address then choose "static" and enter
     the IP address. If the address is assigned by a local BootP/DHCP
     server then choose "DHCP". If the SANA-II device determines the
     dynamic address by itself (e.g. ppp.device) then choose "SANA-II'.

@{b}For SANA-II bus/ring interfaces, Ethernet, Arcnet and MNI:@{ub}
     If your machine has a fixed address then choose "static" and enter
     the IP address. If the address is assigned by a local BootP/DHCP
     server then choose "DHCP". If the address is assigned by a local
     RArp server then choose "RArp".


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_MASK" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_MASK"
@Next "NODE_CONFIG_OTHER_IFACEDEF_GW"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_IP"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Netmask type/address
....................

   This option is available for SANA-II bus/ring devices, Ethernet,
Arcnet and MNI only.

   Your netmask needs to be configured correctly so that MiamiDx knows
how many machines are in your local network. There are three ways of
setting the netmask:

@{b}static@{ub}
     Ask your network administrator for the correct netmask and enter
     it.

@{b}DHCP@{ub}
     MiamiDx tries to get the correct netmask from a local BootP/DHCP
     server.

@{b}ICMP@{ub}
     MiamiDx tries to get the correct netmask from a local server that
     supports ICMP netmask discovery.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_GW" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_GW"
@Next "NODE_CONFIG_OTHER_IFACEDEF_MCASTS"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_MASK"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Gateway type/address/pri
........................

   This option has two purposes:

   @{b}*@{ub} For multidrop interfaces (SANA-II bus/ring, Arcnet, Ethernet, MNI)
     it defines the "default gateway" for the interface, along with a
     priority. Not all multidrop interfaces need a default gateway. You
     should only define one for interfaces that connect you to the
     Internet.

   @{b}*@{ub} For point-to-point interfaces (SANA-II point-to-point, PPP,
     (C)SLIP) it defines the IP address of the peer, i.e. of the host
     you are connected to. It also allow you to make that peer your
     default gateway. For this type of interface you always have to
     define the gateway, either statically or dynamically.

   For multi-drop interfaces the IP address of the gateway can be
determined in three ways:

@{b}static@{ub}
     Ask your network administrator for the correct gateway and enter
     it.

@{b}DHCP@{ub}
     MiamiDx tries to get the correct gateway from a local BootP/DHCP
     server.

@{b}ICMP@{ub}
     MiamiDx tries to get the correct gateway from a local server that
     supports ICMP router discovery.

   For point-to-point interfaces the following three choices exist:

@{b}static@{ub}
     Ask your network administrator for the correct gateway and enter
     it.

@{b}dynamic@{ub}
     MiamiDx tries to get the correct gateway dynamically. The detail
     depend on the type of interface and usually involve PPP-IPCP,
     asking the SANA-II interface (if any), pinging the gateway, DHCP
     and other techniques.  If the gateway cannot be determined then an
     error occurs.

@{b}dynamic/fake@{ub}
     Same as dynamic, except that MiamiDx uses a "dummy" IP address for
     the gateway if the real gateway cannot be determined. This should
     only be necessary for (C)SLIP, usually not for PPP. The advantage
     of using this option is that it allows you to use a point-to-point
     interface without static gateway configuration even if dynamic
     lookup does not work. The disadvantage is that using a dummy IP
     address may interfere with routing between multiple interfaces, so
     you should only use this option if you use MiamiDx with only one
     interface at a time.

   The "priority" determines whether the entered gateway should become
the default gateway: if the priority is zero then MiamiDx never uses
this interface as the default gateway. For multidrop interfaces that
means that the "gateway" IP address is completely ignored (and appears
ghosted). For point-to-point interfaces it means that the gateway is
only used to set the IP address of the peer, but that gateway is never
used as the default gateway for routing.

   If the priority is higher than zero then MiamiDx uses the configured
gateway as the default gateway whenever its priority is the highest
priority among all interfaces that are online at that time.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_MCASTS" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_MCASTS"
@Next "NODE_CONFIG_OTHER_IFACEDEF_PANEL"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_GW"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Multicasts/pri
..............

   MiamiDx support Level-2 multicasting, i.e. both sending, and
receiving multicast messages.

   If you want to use applications that need support multicasting (none
are available yet), you might have to enable Multicasts in MiamiDx. The
possible settings are:

@{b}disabled@{ub}
     Multicasts are disabled.

@{b}send as broadcasts@{ub}
     Multicasts are sent as link-level broadcasts (or for
     point-to-point devices: as ordinary packets).

@{b}send as multicasts@{ub}
     Multicasts are sent as link-level multicasts. This option is only
     available for Ethernet boards.

   Note: Multicasts should only be enabled for an interface if you
receive your multicast feed @{i}directly@{ui} from this interface. If you get
your multicast feed through a tunnel using MiamiMRouteD then you
usually need to @{i}disable@{ui} multicasts on MiamiDx's interface, because
MiamiMRouteD handles multicasting by itself.

   Only one interface at a time can be used for multicating, unless you
run a multicast router such as MiamiMRouteD.  The "priority" determines
which interface is used for multicasting.  If the priority is higher
than zero then MiamiDx uses the interface for multicasting whenever its
priority is the highest priority among all interfaces that are online
at that time.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_PANEL" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_PANEL"
@Next "NODE_CONFIG_OTHER_IFACEDEF_GUIDEFAULT"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_MCASTS"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

Control Panel
.............

   If this option is selected then the interface appears in the Control
Panel.  Please see @{"Control Panel Settings" Link "NODE_CONFIG_OTHER_PANEL"} and the menu item "Project ->
Control Panel to Front in @{"Menus" Link "NODE_REFERENCE_MENUS"} for more information on the Control
Panel.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEDEF_GUIDEFAULT" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEDEF_GUIDEFAULT"
@Prev "NODE_CONFIG_OTHER_IFACEDEF_PANEL"
@Toc "NODE_CONFIG_OTHER_IFACEDEF"

GUI default
...........

   If this option is selected then the current interface becomes the
"GUI default interface". Only one interface can be "GUI default" at any
time. The "GUI default interface" is primarily a compatibility feature
with protocol stacks that only support one interface at a time, such as
Miami. Making an interface "GUI default" has the following effects:

   @{b}*@{ub} The interface reacts to the "Online" and "Offline" button in the
     MiamiDx main window.

   @{b}*@{ub} If an application sends MiamiDx an interface-related ARexx command
     without specifying an interface name, then the GUI default
     interface is used. This affects the commands "GETCONNECT",
     "GETCONNECTTIME", "GETONLINETIME", "GETTRANSFEREDBYTES",
     "ISONLINE", "OFFLINE", and "ONLINE".

   @{b}*@{ub} If an application tries to query or change the "online status" of
     MiamiDx without specifying an interface name then the GUI default
     interface is used. This affects the miami.library calls
     MiamiIsOnline(), MiamiOnOffline() and MiamiPFAddHook().

   If you find that some applications give you bogus error messages such
as "No protocol stack is running" or "You are not online" even when you
are online then this is probably because they check the online status
of your GUI default interface, but the interface you are online with is
not set to GUI default. There are two solutions: either disable the
online check in your application (see the documentation of your
application for that), or set your interface to GUI default.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACELOG" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACELOG"
@Next "NODE_CONFIG_OTHER_IFACEPPP"
@Prev "NODE_CONFIG_OTHER_IFACEDEF"
@Toc "NODE_CONFIG_OTHER"

Interface logging
-----------------

   This window allows you to change the logging option for an
interface. It is only available for PPP and (C)SLIP interfaces.


 @{" Phone log " Link "NODE_CONFIG_OTHER_IFACELOG_PHONE"}                                     Phone log
 @{" Dial capture " Link "NODE_CONFIG_OTHER_IFACELOG_DIAL"}                                  Dial capture
 @{" PPP log " Link "NODE_CONFIG_OTHER_IFACELOG_PPP"}                                       PPP log


@EndNode

@Node "NODE_CONFIG_OTHER_IFACELOG_PHONE" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACELOG_PHONE"
@Next "NODE_CONFIG_OTHER_IFACELOG_DIAL"
@Toc "NODE_CONFIG_OTHER_IFACELOG"

Phone log
.........

   MiamiDx can log any online and offline events in order to assist in
phone bill management.

   The two "Phone log" gadgets let you enable phone logging and specify
the name of a file to which MiamiDx appends billing records.

   At the moment only ASCII format is supported, with records as
follows:

     Online(ppp0): 27.07.1996 17:48:11 (57600)
     Passive Offline(ppp0): 27.07.1996 17:48:11
     Active Offline(ppp0): 27.07.1996 17:48:11
     Reconnect(ppp0): 27.07.1996 17:48:11

   The "Online" record can contain the connection message from the
modem in "()". "Reconnect" occurs when MiamiDx goes online without
actually dialing, e.g. after rebooting the Amiga.

   The difference between "passive" and "active" offline is that an
"active" offline is voluntary, i.e. the result of an "OFFLINE" ARexx
command, someone clicking on the "Offline" gadget etc.  A "passive"
offline is the result of your modem hanging up or your Internet
provider disconnecting you.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACELOG_DIAL" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACELOG_DIAL"
@Next "NODE_CONFIG_OTHER_IFACELOG_PPP"
@Prev "NODE_CONFIG_OTHER_IFACELOG_PHONE"
@Toc "NODE_CONFIG_OTHER_IFACELOG"

Dial capture
............

   This gadget allows you to specify a file where the dialer will save
all data received from the modem during dialing (i.e. a complete dial
log).


@EndNode

@Node "NODE_CONFIG_OTHER_IFACELOG_PPP" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACELOG_PPP"
@Prev "NODE_CONFIG_OTHER_IFACELOG_DIAL"
@Toc "NODE_CONFIG_OTHER_IFACELOG"

PPP log
.......

   This option is available in the registered version only. Only for
PPP interfaces.

   The "PPP log gadget" allows you to specify a file name where MiamiDx
logs the connection establishment phase of PPP. Data is logged in
human-readable form, i.e. not as a hex dump. Only the connection
establishment phase is logged, i.e. until the LCP and IPCP state
machines have reached the `Open' state. After that logging stops,
except for packets at the PPP level that affect the PPP state machines.

   The primary purpose of the PPP log is to help track down
compatibility problems at the PPP level, and to help optimize PPP
options for a particular PPP server.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP"
@Next "NODE_CONFIG_OTHER_IFACEAUTO"
@Prev "NODE_CONFIG_OTHER_IFACELOG"
@Toc "NODE_CONFIG_OTHER"

Interface PPP settings
----------------------

   This window allows you to change the PPP protocol settings for the
current interface.


 @{" PAP/CHAP " Link "NODE_CONFIG_OTHER_IFACEPPP_PAP"}                                                  PAP/CHAP
 @{" Callback " Link "NODE_CONFIG_OTHER_IFACEPPP_CALLBACK"}                                                  Callback
 @{" VJC " Link "NODE_CONFIG_OTHER_IFACEPPP_VJC"}                                                       VJC (TCP header compression)
 @{" ACCM " Link "NODE_CONFIG_OTHER_IFACEPPP_ACCM"}                                                      ACCM
 @{" Get DNS from IPCP " Link "NODE_CONFIG_OTHER_IFACEPPP_DNS"}                                         Get DNS from IPCP
 @{" Escape " Link "NODE_CONFIG_OTHER_IFACEPPP_ESCAPE"}                                                    Escape
 @{" TermReq before hangup " Link "NODE_CONFIG_OTHER_IFACEPPP_TERMREQ"}                                     TermReq before hangup
 @{" Data compression " Link "NODE_CONFIG_OTHER_IFACEPPP_COMPRESS"}                                          Data compression
 @{" Data encryption " Link "NODE_CONFIG_OTHER_IFACEPPP_ENCRYPT"}                                           Data encryption
 @{" Quick Reconnect " Link "NODE_CONFIG_OTHER_IFACEPPP_QUICK"}                                           Quick Reconnect


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_PAP" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_PAP"
@Next "NODE_CONFIG_OTHER_IFACEPPP_CALLBACK"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

PAP/CHAP
........

   PAP and CHAP are protocols used by PPP to send login id and password
to the PPP server.

   Most of the time the login id and password used for PAP or CHAP are
identical to the ones you used in your dial script. In this case choose
"Same as in dialer".

   If your provider requires a PAP/CHAP login id or password different
from the one you chose in the dialer, then do not select "Same as in
dialer", but instead type in your PAP/CHAP login id and password
manually.

   Registered users who have installed MiamiSSL 2.2 or higher can enable
`Allow MS-CHAP'. This improves compatibility with some Windows-NT PPP
servers configured for Microsoft-specific security protocols. If this
option is disabled then MiamiDx falls back to using PAP when the server
requests MS-CHAP. With `Allow MS-CHAP' enabled MiamiDx supports both the
older `MS-CHAP' protocol and the newer `MS-CHAPv2' protocol supported by
Windows-NT 4.0 with recent service packs.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_CALLBACK" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_CALLBACK"
@Next "NODE_CONFIG_OTHER_IFACEPPP_VJC"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_PAP"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

Callback
........

   (This function is available in the registered version only.)

   PPP supports callback (`dialback') according to the CBCP protocol. If
your provider is configured for it, then you can negotiate with your
provider to call you back in order to save on telephone costs.

   Depending on the configuration at your provider you either need to
choose `CBCP fixed', in which case your provider calls you back to a
predefined phone number, or `CBCP variable', in which case your
provider calls you back to the phone number you enter in the gadget
below.

   `Min delay' is the delay you ask the provider to wait before calling
you back. This should be large enough to allow your modem to hang up
the line and reinitialize itself.

   `Max delay' is the maximum delay you want MiamiDx to wait for a
callback before giving up.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_VJC" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_VJC"
@Next "NODE_CONFIG_OTHER_IFACEPPP_ACCM"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_CALLBACK"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

VJC
...

   Van Jacobsen Compression is a technique to save bandwidth by
compressing the headers of TCP packets. Usually this option should be
switched on, meaning that PPP will automatically try to negotiate VJC,
and use it if the other side agrees.

   However some old, buggy PPP servers do not support VJC properly, so
you might have to switch VJC off for them.

   VJC does not interact with your modem's data compression in any way,
i.e.  you should not switch VJC off just because your modem supports
MNP-5 or V.42bis. VJC can be used independently of MNP-5 or V.42bis.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_ACCM" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_ACCM"
@Next "NODE_CONFIG_OTHER_IFACEPPP_DNS"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_VJC"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

ACCM
....

   The PPP protocol supports a list of control characters that are
"escaped" during transmission, i.e. replaced by a two-byte sequence.
This list is called ACCM (Asynchronous Control Character Mask).

   The purpose of this list is to make PPP more robust across lines
that are not completely 8-bit transparent, and to avoid any
interference of the PPP protocol with software modem flow control.

   The default is to only escape characters 17 and 19 (Xon/Xoff), so PPP
can be used across a link with software flow control. If you are running
PPP through a telnet link you might have to escape more characters. Each
character you escape reduces the performance of PPP by about 0.8%.

   To change the ACCM settings either enter the 32-bit mask value
directly in hexadecimal digits, or with some GUI modules click on the
popup gadgets to toggle each control character individually.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_DNS" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_DNS"
@Next "NODE_CONFIG_OTHER_IFACEPPP_ESCAPE"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_ACCM"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

Get DNS from IPCP
.................

   This switch is "on" by default. This means that MiamiDx tries to use
IPCP extensions for automatic DNS discovery to find DNS servers.

   Unfortunately some broken PPP servers neither support this option,
nor reject it properly, but simply violate the protocol. If you
experience problems completing the link level PPP protocol with your
Internet provider then you might have to disable this option.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_ESCAPE" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_ESCAPE"
@Next "NODE_CONFIG_OTHER_IFACEPPP_TERMREQ"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_DNS"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

Escape
......

   PPP can negotiate that characters in the range of 0-31 and 128-159
are escaped. This is configured in the ACCM.

   However there are situations when you might have to escape some
additional characters, e.g. 0xFF across rlogin connections.

   In this case enter the 2-digit hex codes (separated by spaces) into
the "Escape" gadget, and MiamiDx will escape those characters when
sending PPP packets.

   Note that, contrary to the ACCM definition, this only works in one
direction: when sending data. If the channel back from the server to
MiamiDx also requires character escaping, then you have to configure the
PPP server accordingly as well.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_TERMREQ" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_TERMREQ"
@Next "NODE_CONFIG_OTHER_IFACEPPP_COMPRESS"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_ESCAPE"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

TermReq before hangup
.....................

   This option should normally be switched on. In this case MiamiDx
sends an LCP-TermReq message to your provider when you want to hang up
the line. This usually has the effect that your provider hangs up the
modem first, causing your modem to hang up more quickly.

   However some PPP servers do not support LCP-TermReqs properly. If
you notice that hanging up the line takes very long then try disabling
this option and see if hangups are quicker this way.

   Also, some old driver software for Amiga ISDN boards have bugs that
may cause Software Failures or other problems if this option is
disabled.  If you are using such ISDN driver software and experience
problems during hangup then try disabling this option.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_COMPRESS" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_COMPRESS"
@Next "NODE_CONFIG_OTHER_IFACEPPP_ENCRYPT"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_TERMREQ"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

Data compression
................

   This option enables PPP data compression.

   At the moment the only supported compression protocol is Microsoft's
MPPC protocol. The implementation in MiamiDx is compatible with Windows
NT 4.0.  Please note that because of bugs in the decompression engine
in Windows NT MiamiDx currently only uses MPPC for decompression
(downloading), not compression (uploading).

   Important note: You should @{i}NOT@{ui} enable PPP data compression across
modem lines, because it interferes with the data compression already
used by your modem, and thus does @{i}NOT@{ui} improve throughput. It may
actually @{i}reduce@{ui} throughput, because after enabling this option, instead
of letting the modem do the work required to decompress the data, that
work is now done by your Amiga, i.e. the CPU utilization of your Amiga
increases and your Amiga slows down. PPP data compression should only
be enabled on very fast Amigas across lines that do not already have
data compression, e.g. across ISDN lines.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_ENCRYPT" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_ENCRYPT"
@Next "NODE_CONFIG_OTHER_IFACEPPP_QUICK"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_COMPRESS"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

Data encryption
...............

   This option enables PPP data encryption.

   At the moment the only supported encryption protocol is Microsoft's
MPPE protocol. MiamiDx implements both 128-bit and 40-bit encryption,
and automatically negotiates the highest encryption strength available
at the server. The use of MPPE requires MiamiSSL 2.2 or higher.

   Important note: data encryption creates a significant CPU load and
should only be enabled if the server requires it, e.g. when connecting
to an NT server via PPTP across the Internet (to access a VPN). For
normal PPP dial-up operation data encryption should be disabled.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEPPP_QUICK" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEPPP_QUICK"
@Prev "NODE_CONFIG_OTHER_IFACEPPP_ENCRYPT"
@Toc "NODE_CONFIG_OTHER_IFACEPPP"

Quick reconnect
...............

   Usually MiamiDx allows you to reconnect to your provider (without
dialing again) when the modem is still connected, e.g. after resetting
your Amiga, but only if the "Use CD" gadget is switched on in your
hardware definition, and if the modem is configured to "ignore DTR".

   However even then with PPP some providers do not allow reconnection
(and renegotiation of PPP), and instead hang up the line when you try
to reconnect.

   "Quick Reconnect" usually helps in this case: If "Quick Reconnect"
is activated (by either setting it to "RAM" or to "file") then MiamiDx
does not attempt to renegotiate PPP, but bypasses the renegotiation and
fetches all PPP parameters from an area of RAM that has been set up to
survive a reboot (for the "RAM" setting) or from a file on harddisk
(for the "file" setting). In most cases this allows you to reconnect to
your provider after rebooting your Amiga.

   Please note: If you use the "file" setting and your Amiga crashes
(for whatever reason, e.g. caused by a run-away commodity or patch)
@{i}while@{ui} MiamiDx is writing the reconnect-file to harddisk, then it is
possible that your harddisk gets invalidated or damaged in some way,
caused by some bugs and other shortcomings in the Amiga filesystem.

   It is therefore safer to use "RAM", because then MiamiDx does not
have to create a harddisk file. However the "RAM" setting only works if
you do not reboot at all, or after a soft- (warm-) reboot. If your
machine crashes very badly or if you have to cold-reboot (destroying
resident modules) then the old PPP parameters will be gone and the
"RAM" setting does not cause a proper reconnect.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEAUTO" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEAUTO"
@Next "NODE_CONFIG_OTHER_IFACEROUTES"
@Prev "NODE_CONFIG_OTHER_IFACEPPP"
@Toc "NODE_CONFIG_OTHER"

Interface Auto-connect/disconnect
---------------------------------

   This window allows you to specify under which conditions an interface
should automatically go online or offline.


 @{" Auto-connect " Link "NODE_CONFIG_OTHER_IFACEAUTO_CON"}                                     Auto-connect (dial on demand)
 @{" Auto-disconnect " Link "NODE_CONFIG_OTHER_IFACEAUTO_DIS"}                                  Auto-disconnect (hangup on inactivity)


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEAUTO_CON" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEAUTO_CON"
@Next "NODE_CONFIG_OTHER_IFACEAUTO_DIS"
@Toc "NODE_CONFIG_OTHER_IFACEAUTO"

Auto-connect
............

   The auto-connect settings allow you to specify that the current
interface should automatically go online when there is traffic that has
to be routed through the interface. There are two variations:

@{b}Auto-connect from suspended@{ub}
     If you enable this option then MiamiDx takes the interface online
     if there is traffic that has to be routed through the interface
     and the interface is currently in "suspended" state (i.e. the
     routing tables for the interface still exist). You can enable this
     option for as many interfaces as you want.

@{b}Auto-connect from offline@{ub}
     If you enable this option then MiamiDx takes the interface online
     if there is traffic that has to be routed through the interface
     and the interface is currently offline. You can enable this option
     for only @{i}ONE SINGLE@{ui} interface in your settings (typically your
     default Internet interface). If you enable it for more than one
     interface then only the first interface in your list is taken
     offline, and this setting is ignored for all other interfaces.

   The reasoning behind two separate mechanisms is: MiamiDx needs a way
to know which interface should be taken online. If an interface is in
suspended mode then routing tables for it exist, i.e. MiamiDx can
determine for each packet which interface it should be routed through.

   Interfaces that are offline don't participate in routing decisiona,
i.e. in order to support "auto-connect from offline" MiamiDx detects
packets that would normally cause a "host unreachable" response,
because no routing entry for the destination exists, and those packets
then trigger an online transition of one interface.

   You can configure interfaces to go online for "any traffic" (local
or routed), for "local traffic" (only traffic originating on your
Amiga), or for "routed traffic" (only traffic routed to your Amiga from
another machine on the LAN).

   @{i}IMPORTANT@{ui}: In order for "Auto-connect from offline" to work correctly
you @{i}MUST@{ui} have at least one global, static DNS server configured in
@{"Database DNS servers" Link "NODE_CONFIG_DATABASE_DNSSERVERS"}, i.e. a DNS server without the "Temp" flag and
without an interface name. For more information how you switch from a
dynamic DNS server configuration to a static one please see
@{"Get dynamic DNS servers" Link "NODE_CONFIG_OTHER_IFACETCPIP_DYNDNS"}.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEAUTO_DIS" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEAUTO_DIS"
@Prev "NODE_CONFIG_OTHER_IFACEAUTO_CON"
@Toc "NODE_CONFIG_OTHER_IFACEAUTO"

Auto-disconnect
...............

   MiamiDx can be configured two do one of two things when an interface
is online and there is no activity on that interface for a while:

@{b}Disconnect after inactivity@{ub}
     Disconnect, i.e. go offline. This is what you want to do if you
     want to, e.g., reduce your phone bill by disconnecting the line
     when you are not using it.  You can specify after how many seconds
     of inactivity you want MiamiDx to go offline, and exactly what
     kind of traffic should be counted as "activity".  You should
     usually select "IP traffic" or "UDP/TCP traffic".

     The tool @{"MiamiRemind" Link "NODE_UTILITY_REMIND"} provides a similar functionality as
     "disconnect after inactivity", but allows you to more precisely
     define what kind of traffic should be counted as "activity".

@{b}Simulate activity@{ub}
     You can simulate line activity. This is what you want to do if
     your Internet service provider automatically disconnects you after
     a while, and you want to avoid these disconnections.

     The gadget on the left sets the type of activity: PPP ping or ICMP
     ping.  PPP ping consumes less bandwidth, but only works with PPP,
     not with (C)SLIP, and does not have an effect with all providers.
     ICMP ping takes up slightly more bandwidth, but works with both
     PPP and (C)SLIP, and should have an effect with all providers.

     If you use PPP then first try PPP ping, and if your provider still
     hangs up try ICMP ping. For all other interface types try ICMP
     ping directly.

     The gadget on the right sets the number of seconds between
     successive pings. You need to experiment with that. Common values
     are 540 or 840, to prevent hangups after 10 or 15 minutes.

     Note: You need to check with your Internet provider first if he
     allows the use of this type of activity simulator. Some providers
     have policies that do not allow it, and by using such a simulator
     you might be violating their regulations. I will not be
     responsible or liable for any consequences resulting from the
     improper use of this activity simulator.

     Note: There are many reasons why a modem might hang up. One is an
     inactivity timeout at your Internet provider, which should be
     prevented by this function. However modems sometimes also hang up
     the line because of line noise. There is no way to prevent this in
     software.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEROUTES" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEROUTES"
@Next "NODE_CONFIG_OTHER_IFACETCPIP"
@Prev "NODE_CONFIG_OTHER_IFACEAUTO"
@Toc "NODE_CONFIG_OTHER"

Interface Manual routes/aliases
-------------------------------

   This window allows you add manual routes to an interface, i.e.
routes that are automatically added to the routing table whenever an
interface is online.

   @{i}WARNING@{ui}: This function is for advanced users and complex networks
only, usually involving more than one router in your LAN. The majority
of users should NOT add manual routes. Adding manual routes when they
are not necessary can lead to malfunctions. If you think you need manual
routes then please see @{"Complex networks: adding manual routes" Link "NODE_CONCEPTS_ROUTES"} to verify
whether you really need manual routes, and what kind of routes you need.

   For users switching from Unix, AmiTCP/IP or I-Net 225: with those
protocols stacks you need to manually add routes for netmasks, default
gateway, localhost etc. With MiamiDx you do NOT need to do this. All
such routes are automatically added by MiamiDx, without specifying
manual routes.

   The following types of routes and aliases can be added:

@{b}Indirect host route@{ub}
     This route tells MiamiDx that a single host is reachable through a
     different router than the normal interface configuration and
     default gateway imply.  You need to enter the IP address of the
     target host and, for multi-drop interfaces, the IP address of the
     router (must be directly connected to this interface).

@{b}Indirect network route@{ub}
     Same as "Indirect host route", except the target is not a single
     host but a network, specified by its starting IP address and its
     netmask.

@{b}Direct host route@{ub}
     (Only for multi-drop interfaces): This route tells MiamiDx that a
     single host is directly connected to the interface, even though
     its IP address is outside of the range defined by the interface's
     IP address and netmask.

@{b}Direct network route@{ub}
     (Only for multi-drop interfaces): Same as "Direct host route",
     except that the target is not a single host but a network,
     specified by its starting IP address and its netmask.

@{b}Host alias@{ub}
     Assign an alternative IP address to your Amiga. This option can be
     useful if you are running a web server such as Apache and want to
     host multiple domains on a single machine. Usually the host alias
     should be inside of the network implied by this interface's IP
     address and netmask. That way you don't have to configure manual
     routes on the other machines in your LAN.

@{b}Network alias@{ub}
     (Only for multi-drop interfaces): Assign an alternative IP address
     and netmask to your LAN. This option is useful primarily when
     renumbering your LAN. It allows you to operate your LAN with
     separate sets of IP addresses simultaneously.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETCPIP" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETCPIP"
@Next "NODE_CONFIG_OTHER_IFACEEVENTS"
@Prev "NODE_CONFIG_OTHER_IFACEROUTES"
@Toc "NODE_CONFIG_OTHER"

Interface TCP/IP settings
-------------------------

   This window lets you configure some settings at the TCP/IP level and
higher protocol levels.


 @{" Use ICMP " Link "NODE_CONFIG_OTHER_IFACETCPIP_ICMP"}                                                              Use ICMP
 @{" Fake IP " Link "NODE_CONFIG_OTHER_IFACETCPIP_FAKE"}                                                               Fake IP
 @{" Get dynamic host name, priority " Link "NODE_CONFIG_OTHER_IFACETCPIP_DYNHOST"}                                       Get dynamic host name, priority
 @{" Get dynamic DNS servers " Link "NODE_CONFIG_OTHER_IFACETCPIP_DYNDNS"}                                               Get dynamic DNS servers
 @{" Preferred offline state " Link "NODE_CONFIG_OTHER_IFACETCPIP_PREFERED"}                                               Preferred offline state
 @{" Get time/from " Link "NODE_CONFIG_OTHER_IFACETCPIP_GETTIME"}                                                         Get time/from
 @{" DHCP " Link "NODE_CONFIG_OTHER_IFACETCPIP_DHCP"}                                                                  DHCP


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETCPIP_ICMP" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETCPIP_ICMP"
@Next "NODE_CONFIG_OTHER_IFACETCPIP_FAKE"
@Toc "NODE_CONFIG_OTHER_IFACETCPIP"

Use ICMP
........

   If this gadget is switched on then MiamiDx uses ICMP "ping" messages
to verify the correctness of IP addresses, DNS servers etc.

   This gadget should usually be switched on, because it provides
additional protection from incorrect configuration.

   However if you are connecting through some TCP emulator such as TIA
then you might have to switch this gadget off, because not all TCP
emulators support ICMP.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETCPIP_FAKE" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETCPIP_FAKE"
@Next "NODE_CONFIG_OTHER_IFACETCPIP_DYNHOST"
@Prev "NODE_CONFIG_OTHER_IFACETCPIP_ICMP"
@Toc "NODE_CONFIG_OTHER_IFACETCPIP"

Fake IP
.......

   If you are connected to the Internet through a TCP emulator such as
TIA or Slirp, and this emulator does not assign you a "real" IP address,
but a fake address, then you need to activate this switch.

   It tells MiamiDx to obtain your host name by resolving the remote IP
address, not your local ("fake") IP address.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETCPIP_DYNHOST" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETCPIP_DYNHOST"
@Next "NODE_CONFIG_OTHER_IFACETCPIP_DYNDNS"
@Prev "NODE_CONFIG_OTHER_IFACETCPIP_FAKE"
@Toc "NODE_CONFIG_OTHER_IFACETCPIP"

Get dynamic host name, priority
...............................

   If this priority is set to a value higher than zero, then MiamiDx
tries to resolve the local IP address on this interface into a host
name, and uses that host name in the global MiamiDx settings, i.e. the
host name becomes visible to software. If multiple interfaces with a
priority higher than zero are online than the host name is determined
from the interface with the highest host name priority.

   Most users will want to use a host name that corresponds to their
global (Internet) host name, i.e. the host name priority of "Internet"
interfaces should be set to a value greater than zero, and the host
name priority of "LAN" interfaces should be set to zero.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETCPIP_DYNDNS" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETCPIP_DYNDNS"
@Next "NODE_CONFIG_OTHER_IFACETCPIP_PREFERED"
@Prev "NODE_CONFIG_OTHER_IFACETCPIP_DYNHOST"
@Toc "NODE_CONFIG_OTHER_IFACETCPIP"

Get dynamic DNS servers
.......................

   If this option is activated (i.e. not set to "ignore") then MiamiDx
tries to look up DNS servers announced by the Internet service provider
for the current interface, and adds them to the DNS server database
("dynamic DNS server configuration"). You have the choice of either
blindly adding those DNS servesrs (setting "add") or first verifying
all servers and adding only those that are reachable (setting
"verify&add").

   Note: dynamic DNS configuration is convenient, because it does not
require you to add DNS servers manually, but it has several
disadvantages: sometimes Internet service providers do not announce all
DNS servers on all PPP servers, so it may occasionally happen that you
go online without DNS servers. Also, dynamic DNS configuration is
incompatible with some "dial-on-demand" settings (see
@{"Auto-connect/disconnect" Link "NODE_CONFIG_OTHER_IFACEAUTO"} for more information). Because of that it is
recommended that you use dynamic DNS configuration only for the initial
configuration of MiamiDx, and then later configure those DNS servers
statically. To do this do the following:

   Go online with your Internet interface. Switch to "Database/DNS
servers".  You will find some DNS servers that have the "Temp" ("T")
flag set and have the name of your Internet interface in the
"Interfaces" column. For each of these servers select the server, click
on "Temp" to disable the "Temp" flag, and delete the contents of
"Interfaces". Once you have done that for all DNS servers save the
settings. Then set the "Get dynamic DNS servers" switch for the
Internet interface to "ignore". After that MiamiDx uses static DNS
servers for this interface.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETCPIP_PREFERED" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETCPIP_PREFERED"
@Next "NODE_CONFIG_OTHER_IFACETCPIP_GETTIME"
@Prev "NODE_CONFIG_OTHER_IFACETCPIP_DYNDNS"
@Toc "NODE_CONFIG_OTHER_IFACETCPIP"

Preferred offline state
.......................

   This switch selects precisely how connections and routing tables are
affected when an interface goes offline. There are three choices:

@{b}offline@{ub}
     If the Interface goes offline it goes to the "offline" state, i.e.
     routing tables are deleted. However TCP connections established
     "through" the interface are not shut down. This means if you have
     configured this interface for "Auto-connect from offline" (see
     @{"Auto-connect/disconnect" Link "NODE_CONFIG_OTHER_IFACEAUTO"}) then the interface will go online again
     once there is traffic on a TCP connection.  This setting is
     primarily useful for PPP/SLIP connections with static IP addresses.

@{b}suspended@{ub}
     If the Interface goes offline it goes to the "suspended" state,
     i.e. routing tables and TCP connections remain intact. This means
     if you have configured this interface for "Auto-connect from
     suspended" (see @{"Auto-connect/disconnect" Link "NODE_CONFIG_OTHER_IFACEAUTO"}) then the interface will
     go online again once there is traffic on a TCP connection.  This
     option is primarily useful for PPP/SLIP interfaces between
     different parts of a private network. Switching such internal
     interfaces to "suspended" instead of "offline" gives you more
     flexibility in the way dial-on-demand can be configured.

@{b}offline&disconnect@{ub}
     If the Interface goes offline it goes to the "offline" state, i.e.
     routing tables are deleted and all TCP connections established
     "through" the interface are shut down. Use this option for
     PPP/SLIP connections with dynamic IP addresses, when it is likely
     that the next time you go online you will get a different IP
     address.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETCPIP_GETTIME" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETCPIP_GETTIME"
@Next "NODE_CONFIG_OTHER_IFACETCPIP_DHCP"
@Prev "NODE_CONFIG_OTHER_IFACETCPIP_PREFERED"
@Toc "NODE_CONFIG_OTHER_IFACETCPIP"

Get time/from
.............

   If your Amiga is not equipped with a battery-powered real-time clock
then you should activate the "Get time" switch, and enter the name or
IP address of a server that supports the UDP "time" service in the
string gadget. If you are unsure which name to enter just try any
"major" machine run by your provider, e.g. the machine you use for
e-mail or news.

   This feature requires Workbench version 2.1 or higher, and your
Locale settings need to be set to the correct time zone.

   Note: @{i}Do not@{ui} use this function if your Amiga has a battery-backed
clock, because in this case it is possible that setting the time will
cause your Amiga's time to be changed backwards. This can confuse
programs which use GetSysTime() for calculations, and can cause crashes
and other problems.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACETCPIP_DHCP" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACETCPIP_DHCP"
@Prev "NODE_CONFIG_OTHER_IFACETCPIP_GETTIME"
@Toc "NODE_CONFIG_OTHER_IFACETCPIP"

DHCP
....

   If your provider uses dynamic IP addresses then there are different
techniques for MiamiDx to find the correct (dynamic) IP address.

   For PPP lines this is usually handled has part of the PPP protocol.
(C)SLIP does not have such an option though, so for (C)SLIP a protocol
called "DHCP" (or its predecessor "BootP") is sometimes used.
Alternatively the IP address can sometimes be determined from the dial
log. Some Internet providers also use DHCP for Ethernet, e.g. with
cable modem or ADSL setups.

   If you used MiamiInit to configure the line then you can just leave
this switch at its default setting. If you configured MiamiDx manually
then you should first switch "DHCP" on, and then later try again with
"DHCP" switched off, and see if this still works.

   If MiamiDx can find your IP addresses without DHCP then you should
switch "DHCP" off, because it can make the connection establishment
phase quicker.

   The switch "Send host name in request" allows you to enter a machine
name that MiamiDx sends in DHCP requests, to emulate the broken DHCP
behavior used by Windows-95/98 and sometimes requested by Windows-NT.
Do NOT activate this option unless your Internet provider requires you
to do it. If you do have to use this option then the "Host name" has to
be your logical computer name, i.e. a name without any "." in it, and
usually in upper-case characters.


@EndNode

@Node "NODE_CONFIG_OTHER_IFACEEVENTS" "MiamiDx.guide/NODE_CONFIG_OTHER_IFACEEVENTS"
@Next "NODE_CONFIG_OTHER_LANCONNECT"
@Prev "NODE_CONFIG_OTHER_IFACETCPIP"
@Toc "NODE_CONFIG_OTHER"

Interface Events
----------------

   MiamiDx allows you to react in various ways to events such as
offline, online etc., by executing an ARexx or Shell script, iconifying
the MiamiDx window etc.

   The specific events MiamiDx can react to are:

@{b}Active Offline@{ub}
     going offline caused by the user, e.g. by clicking on the
     "Offline" gadget or by an ARexx "OFFLINE" command.

@{b}Passive Offline@{ub}
     going offline caused by the modem or the provider hanging up.

@{b}Online@{ub}
     going online, i.e. successfully taking an interface online and
     starting up all required protocols.

@{b}Failed Online@{ub}
     an attempt to go online that failed for some reason, e.g. because
     all phone lines were busy, and the maximum number of retries was
     reached.

   MiamiDx can react in the following ways. Not each of these options
makes sense for each event, so only a subset of these options is
actually available in each case:

@{b}ARexx@{ub}
     Start an ARexx script

@{b}Shell@{ub}
     Start an AmigaDOS shell script

@{b}Hide GUI@{ub}
     iconify the Miami window

@{b}Kill GUI@{ub}
     iconify the Miami window and unload the GUI module

@{b}Auto-online@{ub}
     try to go online (dial) automatically

@{b}Beep@{ub}
     flash the display or beep, as defined in system preferences

@{b}Show@{ub}
     deiconify the MiamiDx window

   In the evaluation version of Miami the options "ARexx" and "Shell"
are not available, and "auto-online" is not available in response to a
"passive offline" event.


@EndNode

@Node "NODE_CONFIG_OTHER_LANCONNECT" "MiamiDx.guide/NODE_CONFIG_OTHER_LANCONNECT"
@Next "NODE_CONFIG_OTHER_IPNATREDIR"
@Prev "NODE_CONFIG_OTHER_IFACEEVENTS"
@Toc "NODE_CONFIG_OTHER"

LAN-Connect
-----------

   The "LAN-Connect" window, reachable from the "TCP/IP" window, is
used to configure a module within MiamiDx that provides features to
allow you to connect a local network of machines to the Internet,
through a single Internet connection ("modem sharing"). For some
background information on how to set up your Amiga for modem sharing
please see @{"Setting up modem sharing: IP-NAT and SOCKS" Link "NODE_CONCEPTS_SHARING"}.  For more
information on firewalls see @{"Setting up a firewall" Link "NODE_CONCEPTS_FIREWALL"}.


 @{" Interfaces " Link "NODE_CONFIG_OTHER_LANCONNECT_INTERFACES"}                                          Interfaces
 @{" SocksD " Link "NODE_CONFIG_OTHER_LANCONNECT_SOCKSD"}                                              SocksD
 @{" IP-NAT " Link "NODE_CONFIG_OTHER_LANCONNECT_IPNAT"}                                              IP-NAT
 @{" Firewall " Link "NODE_CONFIG_OTHER_LANCONNECT_FIREWALL"}                                            Firewall


@EndNode

@Node "NODE_CONFIG_OTHER_LANCONNECT_INTERFACES" "MiamiDx.guide/NODE_CONFIG_OTHER_LANCONNECT_INTERFACES"
@Next "NODE_CONFIG_OTHER_LANCONNECT_SOCKSD"
@Toc "NODE_CONFIG_OTHER_LANCONNECT"

Interfaces
..........

   You need to divide your interfaces into two categories, "Internet"
and "LAN", resulting in the following properties:

@{b}Internet@{ub}
     Choose "Internet" for all interfaces that connect you to the
     Internet.  Machines on "Internet" interfaces are considered
     untrusted, i.e. if you configure a firewall then connections
     coming from Internet interfaces are subject to firewall rules. If
     you use IP-NAT then IP addresses on "Internet" interfaces are
     considered "real" IP addresses, i.e. not subject to IP-NAT
     translation. If you use a SOCKS daemon then the daemon will reject
     SOCKS connections from Internet interfaces, to ensure that your
     machine is not abused as a proxy by users on the Internet who want
     to "cover their tracks".

@{b}LAN@{ub}
     Choose "LAN" for all interfaces that connect your Amiga to other
     machines on your local network.  Machines on "LAN" interfaces are
     considered trusted, i.e. if you configure a firewall then
     connections coming from LAN interfaces are not subject to firewall
     rules. If you use IP-NAT then IP addresses on "LAN" interfaces are
     considered "fake" IP addresses, i.e. any connection from a machine
     on a "LAN" interface to a machine on an "Internet" interface is
     subject to IP address translation. If you use a SOCKS daemon then
     the daemon will allow SOCKS connections from LAN interfaces.

   To select the correct type of interface select the interface and
then click on "Internet" or "LAN".


@EndNode

@Node "NODE_CONFIG_OTHER_LANCONNECT_SOCKSD" "MiamiDx.guide/NODE_CONFIG_OTHER_LANCONNECT_SOCKSD"
@Next "NODE_CONFIG_OTHER_LANCONNECT_IPNAT"
@Prev "NODE_CONFIG_OTHER_LANCONNECT_INTERFACES"
@Toc "NODE_CONFIG_OTHER_LANCONNECT"

SocksD
......

   This switch enables the SOCKS daemon, turning your Amiga into a
SOCKS proxy server that other machines on the LAN can use to connect to
the Internet.  The port number is usually 1080. Configuring your Amiga
as a SOCKS proxy server is one of two ways to do "modem sharing". The
other method is @{"IP-NAT" Link "NODE_CONFIG_OTHER_LANCONNECT_IPNAT"}. Both can be configured at the same time.

   Please note: MiamiDx can be used both as a "SOCKS client" and a
"SOCKS server", but only one at a time. If you want to use your Amiga
as a SOCKS proxy server, that other machines on the LAN can use to
connect to the Internet, "through" your Amiga, then enable SocksD here,
and DISABLE the SOCKS client in @{"Socks" Link "NODE_CONFIG_SOCKS"}. If you have a different SOCKS
proxy server on your network, and want your Amiga to connect to the
Internet using that proxy server, then DISABLE SocksD here, and enable
the SOCKS client in @{"Socks" Link "NODE_CONFIG_SOCKS"}. Do NOT enable both client and server at once
(unless you are "daisy-chaining" two SOCKS proxy servers, but that is a
rather unusual setup).


@EndNode

@Node "NODE_CONFIG_OTHER_LANCONNECT_IPNAT" "MiamiDx.guide/NODE_CONFIG_OTHER_LANCONNECT_IPNAT"
@Next "NODE_CONFIG_OTHER_LANCONNECT_FIREWALL"
@Prev "NODE_CONFIG_OTHER_LANCONNECT_SOCKSD"
@Toc "NODE_CONFIG_OTHER_LANCONNECT"

IP-NAT
......

   IP-NAT ("IP network address translation", "IP masquerading") is one
of two ways to do "modem sharing". The other method is @{"SocksD" Link "NODE_CONFIG_OTHER_LANCONNECT_SOCKSD"}. Both can
be configured at the same time.

   If you want to use IP-NAT then you should normally set this switch to
"internal". This activates the internal IP-NAT engine in MiamiDx.
Alternatively you can set the switch to "external", but then you need
to start the external IP-NAT daemon (@{"MiamiIPNatD" Link "NODE_UTILITY_IPNATD"}.

   The external IP-NAT daemon has more configuration options, but for
the majority of users the internal IP-NAT engine should be sufficient.
Using the internal engine has the advantage that the IP-NAT
configuration is done automatically, i.e.  MiamiDx automatically
adjusts the IP-NAT configuration if your interface settings, IP
addresses etc. change.

   The internal IP-NAT engine supports "IP-NAT redirection", allowing
you to redirect access from the Internet to some ports on your Amiga to
a different machine on your network. This can, e.g., be useful if you
have an FTP or web server running on one of the machines on your LAN,
behind the IP-NAT router, and you want that server to be "visible" to
the Internet.  Clicking on "IP-NAT redirection" opens the
@{"IP-Nat redirection" Link "NODE_CONFIG_OTHER_IPNATREDIR"} dialog where you can configure the ports you want to
redirect.


@EndNode

@Node "NODE_CONFIG_OTHER_LANCONNECT_FIREWALL" "MiamiDx.guide/NODE_CONFIG_OTHER_LANCONNECT_FIREWALL"
@Prev "NODE_CONFIG_OTHER_LANCONNECT_IPNAT"
@Toc "NODE_CONFIG_OTHER_LANCONNECT"

Firewall
........

   This section allows you to configure MiamiDx as a firewall, i.e. has
a barrier between Internet and LAN interfaces, which prohibits
connections from the Internet to machines in your LAN.

   Most people who want to use MiamiDx as a firewall should set this
switch to "auto". This enables the "automatic firewall" in MiamiDx.
With this setting MiamiDx automatically creates a set of firewall rules
which prevent IP address spoofing attacks, ICMP broadcast attacks
("smurf"), and prohibit connections to all ports on all machines in
your LAN, with the exception of ports 1024-5000 and 49152-65535, which
are typically used for "reverse connections", e.g.  for FTP. Also, if
your interface uses DHCP then packets coming from DHCP servers are
allowed into your network. The firewall rules are automatically updated
whenever your interface settings or IP addresses change.

   The settings described above are reasonable default settings, but
they are rather conservative and completely isolate your LAN from the
Internet.  If you want to allow access to some ports on some machines
then you need to "punch holes" into the firewall, i.e. tell MiamiDx
which ports on which machines should be accessible from the outside.

   You do this by adding entries to the access list. By default the only
entry in the Access list is "Accept TCP auth", which allows connections
to the auth (identd) server on MiamiDx. Allowing this is useful because
a lot of servers (www, irc, ftp and smtp mostly) routinely attempt to
create identd reverse connections in order to authenticate incoming
connections, and not allowing those reverse connections can make it
impossible to connect to certain servers, or slow down connections.

   For each entry you can choose:

@{b}Policy@{ub}
     "Accept" (accept connection) or "Reject" (reject connection). You
     can also choose "Deny" (deny connection and ignore the connection
     attempt, i.e. do not send any response), but using this option is
     not recommended, because it may increase the amount of traffic
     your server is subjected to during denial-of-service attacks and
     can also significantly slow down connections with some servers.

@{b}Protocol@{ub}
     "UDP" or "TCP"

@{b}Source IP address@{ub}
     The source (client) IP addresses of machines on the Internet which
     you want to be able to connect to this service.

@{b}Destination port, on your LAN@{ub}
     Destination (server) port or service name, on your LAN.

@{b}Destination IP address@{ub}
     Destination (server) IP addresses, on your LAN.

   IP addresses can be specified as simple IP addresses (e.g.
`1.2.3.4'), with wildcards (e.g. 1.2.3.*), or as a combination of IP
address and netmark (e.g. 1.2.3.0/255.255.255.0);

   Ports can be specified numerically or by their corresponding service
names. Port ranges can be specified using "/" as the separator, e.g.
"6000/6020".

   Alternatively you can switch the firewall to "manual". In that case
you need to create your own firewall rules, using the utility
@{"MiamiIPFW" Link "NODE_UTILITY_IPFW"}. This gives you more flexibility, but it means that you need
to create all rules manually, and you also need to change these rules
yourself whenever your configuration changes, i.e. MiamiDx will not
maintain these rules for you.


@EndNode

@Node "NODE_CONFIG_OTHER_IPNATREDIR" "MiamiDx.guide/NODE_CONFIG_OTHER_IPNATREDIR"
@Next "NODE_CONFIG_OTHER_PANEL"
@Prev "NODE_CONFIG_OTHER_LANCONNECT"
@Toc "NODE_CONFIG_OTHER"

IP-NAT redirection
------------------

   This window, reachable from the @{"LAN-Connect" Link "NODE_CONFIG_OTHER_LANCONNECT"} dialog, allows you to
"map" ports on your Amiga to ports on any machine on your LAN.  The
effect is that connections to mapped ports on your Amiga will be
forwarded to the port and machine the connection is mapped to. This
allows you to "export" servers running on any machine on your LAN to
the Internet.

   For each redirection entry you can choose:

@{b}Protocol@{ub}
     Usually "udp" or "tcp". Other protocols can be redirected as well,
     but only a complete protocol at a time, i.e. ignoring any port
     numbers.

@{b}Source Port@{ub}
     The port on your Amiga you want to redirect.

@{b}Destination IP@{ub}
     The IP address of the target machine (server) of the redirection.

@{b}Destination Port@{ub}
     The port on the target machine (server) you want to redirect to.

   For instance if you have a machine with an IP address of 10.1.2.5 on
your LAN running a web server (port 80), and you want to make that
server accessible to the Internet, then add an entry "TCP 80 10.1.2.5
80".


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL"
@Prev "NODE_CONFIG_OTHER_IPNATREDIR"
@Toc "NODE_CONFIG_OTHER"

Control panel settings
----------------------

   This window is accessible from the "GUI" page and allows you to
configure the "control panel".

   The "control panel" is a little window independent of the main
MiamiDx user interface that allows you to examine the status of
interfaces and take interfaces online and offline. Please note that in
order for an interface to show up in the control panel you need to
enable the option @{"Control panel" Link "NODE_CONFIG_OTHER_IFACEDEF_PANEL"} in the interface definition.

   The following settings are available to customize the look of the
control panel. Please note that these options apply to the default
control panel module ("plain.MiamiPanel"), but not necessarily to all
third-party control panel modules. Other control panel modules may not
support all of these options or may provide different or additional
options, configured elsewhere.


 @{" Hotkey " Link "NODE_CONFIG_OTHER_PANEL_HOTKEY"}                                                Hotkey
 @{" Font " Link "NODE_CONFIG_OTHER_PANEL_FONT"}                                                  Font
 @{" Public screen " Link "NODE_CONFIG_OTHER_PANEL_SCREEN"}                                         Public screen
 @{" Panel module " Link "NODE_CONFIG_OTHER_PANEL_MODULE"}                                          Panel module
 @{" Refresh " Link "NODE_CONFIG_OTHER_PANEL_REFRESH"}                                               Refresh
 @{" Show on startup " Link "NODE_CONFIG_OTHER_PANEL_STARTUP"}                                       Show on startup
 @{" Show speed " Link "NODE_CONFIG_OTHER_PANEL_SPEED"}                                            Show speed
 @{" Show transfer rate " Link "NODE_CONFIG_OTHER_PANEL_RATE"}                                    Show transfer rate
 @{" Show online time " Link "NODE_CONFIG_OTHER_PANEL_TIME"}                                      Show online time
 @{" Show total traffic " Link "NODE_CONFIG_OTHER_PANEL_TRAFFIC"}                                    Show total traffic
 @{" Show onl/off gadgets " Link "NODE_CONFIG_OTHER_PANEL_ONLOFF"}                                  Show onl/off gadgets
 @{" Show control gadgets " Link "NODE_CONFIG_OTHER_PANEL_CONTROL"}                                  Show control gadgets


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_HOTKEY" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_HOTKEY"
@Next "NODE_CONFIG_OTHER_PANEL_FONT"
@Toc "NODE_CONFIG_OTHER_PANEL"

Hotkey
......

   Key combination that will open and close the control panel. The
default is `control alt d'.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_FONT" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_FONT"
@Next "NODE_CONFIG_OTHER_PANEL_SCREEN"
@Prev "NODE_CONFIG_OTHER_PANEL_HOTKEY"
@Toc "NODE_CONFIG_OTHER_PANEL"

Font
....

   Font to be used in the control panel.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_SCREEN" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_SCREEN"
@Next "NODE_CONFIG_OTHER_PANEL_MODULE"
@Prev "NODE_CONFIG_OTHER_PANEL_FONT"
@Toc "NODE_CONFIG_OTHER_PANEL"

Screen
......

   Name of the public screen to open the control panel on.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_MODULE" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_MODULE"
@Next "NODE_CONFIG_OTHER_PANEL_REFRESH"
@Prev "NODE_CONFIG_OTHER_PANEL_SCREEN"
@Toc "NODE_CONFIG_OTHER_PANEL"

Module
......

   Control panel module. The default (and only control panel module
available at this time) is "Miami:Libs/plain.MiamiPanel". Third party
control panel modules with a different "look and feel" may become
available at a later time. If you are interested in writing a control
panel module then please have a look at the API specifications
(@{"Control Panel API" Link "NODE_SPECIFICATIONS_PANELAPI"}).


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_REFRESH" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_REFRESH"
@Next "NODE_CONFIG_OTHER_PANEL_STARTUP"
@Prev "NODE_CONFIG_OTHER_PANEL_MODULE"
@Toc "NODE_CONFIG_OTHER_PANEL"

Refresh
.......

   Rate at which the data displayed in the control panel is refreshed.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_STARTUP" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_STARTUP"
@Next "NODE_CONFIG_OTHER_PANEL_SPEED"
@Prev "NODE_CONFIG_OTHER_PANEL_REFRESH"
@Toc "NODE_CONFIG_OTHER_PANEL"

Show on startup
...............

   If activated the control panel is opened after starting MiamiDx.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_SPEED" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_SPEED"
@Next "NODE_CONFIG_OTHER_PANEL_RATE"
@Prev "NODE_CONFIG_OTHER_PANEL_STARTUP"
@Toc "NODE_CONFIG_OTHER_PANEL"

Show speed
..........

   Display the modem connection speed in the control panel. This only
applies to PPP/(C)SLIP interfaces, and simply displays the text
displayed by the modem following the "CONNECT" response. For many
modems this is the connection speed. Depending on your modem
configuration it may either be the phone line speed or the speed of the
serial connection to your Amiga.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_RATE" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_RATE"
@Next "NODE_CONFIG_OTHER_PANEL_TIME"
@Prev "NODE_CONFIG_OTHER_PANEL_SPEED"
@Toc "NODE_CONFIG_OTHER_PANEL"

Show transfer rate
..................

   Enables display of the data transfer rate of each interface. It is
measured in the most recent refresh interval with exponentially
decreasing consideration of earlier refresh intervals.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_TIME" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_TIME"
@Next "NODE_CONFIG_OTHER_PANEL_TRAFFIC"
@Prev "NODE_CONFIG_OTHER_PANEL_RATE"
@Toc "NODE_CONFIG_OTHER_PANEL"

Show online time
................

   Enables display of the total online time for each interface.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_TRAFFIC" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_TRAFFIC"
@Next "NODE_CONFIG_OTHER_PANEL_ONLOFF"
@Prev "NODE_CONFIG_OTHER_PANEL_TIME"
@Toc "NODE_CONFIG_OTHER_PANEL"

Show onl/off gadgets
....................

   Enables display of the total amount of data transfered across each
interface.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_ONLOFF" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_ONLOFF"
@Next "NODE_CONFIG_OTHER_PANEL_CONTROL"
@Prev "NODE_CONFIG_OTHER_PANEL_TRAFFIC"
@Toc "NODE_CONFIG_OTHER_PANEL"

Show onl/off gadgets
....................

   Enables onl/off gadgets for each interface, allowing you to take
interfaces online or offline from the control panel.


@EndNode

@Node "NODE_CONFIG_OTHER_PANEL_CONTROL" "MiamiDx.guide/NODE_CONFIG_OTHER_PANEL_CONTROL"
@Prev "NODE_CONFIG_OTHER_PANEL_ONLOFF"
@Toc "NODE_CONFIG_OTHER_PANEL"

Show control gadgets
....................

   Enables display of the "Show", "Hide" and "Quit" control gadgets in
the control panel.


@EndNode

@Node "NODE_SPECIFICATIONS" "MiamiDx.guide/NODE_SPECIFICATIONS"
@Next "NODE_UTILITY"
@Prev "NODE_CONFIG"
@Toc "Main"

Specifications
**************


 @{" MNI Ethernet drivers " Link "NODE_SPECIFICATIONS_MNI"}                                MNI Ethernet drivers
 @{" Dialer command language " Link "NODE_SPECIFICATIONS_DIALER"}                             Dialer command language
 @{" ARexx interface " Link "NODE_SPECIFICATIONS_AREXX"}                                     ARexx interface
 @{" Environment variables " Link "NODE_SPECIFICATIONS_ENV"}                               Environment variables
 @{" Exchanging settings " Link "NODE_SPECIFICATIONS_EXCHANGE"}                                 Exchanging settings
 @{" Misc. config files " Link "NODE_SPECIFICATIONS_CONFIGFILES"}                                  Misc. config files
 @{" Control Panel API " Link "NODE_SPECIFICATIONS_PANELAPI"}                                   Control Panel API


@EndNode

@Node "NODE_SPECIFICATIONS_MNI" "MiamiDx.guide/NODE_SPECIFICATIONS_MNI"
@Next "NODE_SPECIFICATIONS_DIALER"
@Toc "NODE_SPECIFICATIONS"

MNI Ethernet drivers
====================

   MNI drivers are a new way of accessing your Ethernet board. Compared
to traditional SANA-II drivers MNI usually offers better performance
(often MUCH better performance), additional features, e.g. support for
promiscuous mode in MiamiTCPDump, and easier configuration. The
compatibility with some types of hubs and cable modems is also higher
in some situation than with SANA-II.

   The drawback of using MNI is that MNI is not supported by other
networking stacks yet (e.g. Envoy), so running other stacks in parallel
with MiamiDx requires you to change the configuration of those other
stacks. Please see @{"sanamni.device" Link "NODE_UTILITY_SANAMNI"} for more information on this.

   To use your Ethernet board with MNI, set the hardware type of your
Ethernet hardware entry in MiamiDx to "MNI Driver", and enter the name
of the MNI driver for your Ethernet board (see the list below). Then
click on "Find boards" to make sure your board is supported, select the
board and click on "OK". This sets the unit number correctly. Now click
on "MNI parameters" and "Query device", then "OK" to configure
link-level settings. For some MNI drivers you may also have to enter
options in "MNI Options". Please see the description of your MNI driver
to find if this is necessary for your driver.

   Here is a list of all currently supported Amiga Ethernet boards,
along with pointers to the corresponding MNI driver.


 @{" ASDG LanRover EB920 " Link "NODE_SPECIFICATIONS_MNI_ZTDPETNZ"}                                     ASDG LanRover EB920: z2-dp8390.mni
 @{" Ariadne " Link "NODE_SPECIFICATIONS_MNI_ZTAMSNNZ"}                                                 Ariadne: z2-am7990.mni
 @{" Ariadne-II " Link "NODE_SPECIFICATIONS_MNI_ZTDPETNZ"}                                              Ariadne-II: z2-dp8390.mni
 @{" CEI/Ameristar A2065 " Link "NODE_SPECIFICATIONS_MNI_ZTAMSNNZ"}                                     CEI/Ameristar A2065: z2-am7990.mni
 @{" CEI/Ameristar A4066 " Link "NODE_SPECIFICATIONS_MNI_ZTSMCNOCNZ"}                                     CEI/Ameristar A4066: z2-smc91c90.mni
 @{" Commodore A2065 " Link "NODE_SPECIFICATIONS_MNI_ZTAMSNNZ"}                                         Commodore A2065: z2-am7990.mni
 @{" ConneXion " Link "NODE_SPECIFICATIONS_MNI_ZTAMSNNZ"}                                               ConneXion: z2-am7990.mni
 @{" GG2-Bus+, 3COM 3C509 " Link "NODE_SPECIFICATIONS_MNI_GGTTCFZN"}                                    GG2-Bus+, 3COM 3C509: gg2-3c509.mni
 @{" GG2-Bus+, NE2000 " Link "NODE_SPECIFICATIONS_MNI_GGTDPETNZ"}                                        GG2-Bus+, NE2000: gg2-dp8390.mni
 @{" Hydra AmigaNet Z2 " Link "NODE_SPECIFICATIONS_MNI_ZTDPETNZ"}                                       Hydra AmigaNet Z2: z2-dp8390.mni
 @{" QuickNet QN2000 " Link "NODE_SPECIFICATIONS_MNI_ZTMBESNFZ"}                                         QuickNet QN2000: z2-mb86950.mni
 @{" X-Surf " Link "NODE_SPECIFICATIONS_MNI_ZTDPETNZ"}                                                  X-Surf: z2-dp8390.mni

   If your Ethernet board is not on this list then no MNI driver was
available at the time this manual was written. You may want to check
our web site (www.nordicglobal.com) to find out if an MNI driver for
your board has become available since then.

   Here is a list of all currently available MNI drivers, along with
configuration information.


 @{" gg2-3c509.mni " Link "NODE_SPECIFICATIONS_MNI_GGTTCFZN"}                                       gg2-3c509.mni
 @{" gg2-dp8390.mni " Link "NODE_SPECIFICATIONS_MNI_GGTDPETNZ"}                                      gg2-dp8390.mni
 @{" z2-am7990.mni " Link "NODE_SPECIFICATIONS_MNI_ZTAMSNNZ"}                                       z2-am7990.mni
 @{" z2-dp8390.mni " Link "NODE_SPECIFICATIONS_MNI_ZTDPETNZ"}                                       z2-dp8390.mni
 @{" z2-mb86950.mni " Link "NODE_SPECIFICATIONS_MNI_ZTMBESNFZ"}                                      z2-mb86950.mni
 @{" z2-smc91c90.mni " Link "NODE_SPECIFICATIONS_MNI_ZTSMCNOCNZ"}                                     z2-smc91c90.mni


@EndNode

@Node "NODE_SPECIFICATIONS_MNI_GGTTCFZN" "MiamiDx.guide/NODE_SPECIFICATIONS_MNI_GGTTCFZN"
@Next "NODE_SPECIFICATIONS_MNI_GGTDPETNZ"
@Toc "NODE_SPECIFICATIONS_MNI"

gg2-3c509.mni
-------------

   Driver for 3COM 3C509 ISA boards, in Amiga ISA slots bridged via the
GG2-Bus+ board.

   The MNI driver auto-detects and auto-configures the board, using
3COM's proprietary plug'n'play variation.

   Currently only one single 3C509 board in ISA slots will be
recognized.

   Supported MNI options:

   @{b}*@{ub} One of "WAIT=1", "WAIT=0" enables/disables support for wait states
     on the GG2 board. Default is "WAIT=1". "WAIT=0" may slightly
     reduce CPU load with boards that are fast enough.


@EndNode

@Node "NODE_SPECIFICATIONS_MNI_GGTDPETNZ" "MiamiDx.guide/NODE_SPECIFICATIONS_MNI_GGTDPETNZ"
@Next "NODE_SPECIFICATIONS_MNI_ZTAMSNNZ"
@Prev "NODE_SPECIFICATIONS_MNI_GGTTCFZN"
@Toc "NODE_SPECIFICATIONS_MNI"

gg2-dp8390.mni
--------------

   Driver for NE2000-compatible ISA boards (based on the DP8390 chip or
clones), in Amiga ISA slots bridged via the GG2-Bus+ board.

   The driver should support all NE2000-compatible (@{i}NOT@{ui}
NE1000-compatible) boards. This includes boards configured via jumpers,
boards configured via installation disk (with the configuration saved
in Flash-ROM), and jumperless ISA-PnP boards without a fixed
configuration.

   The MNI driver auto-detects the board (IO address and IRQ).  Manual
configuration is not supported at this time. If no board is found in
the supported IO and IRQ range then the driver performs a PnP search
for NE2000-compatible boards, and configures and activates any found
board for the time period the driver is active.

   Currently only one single NE2000 board in ISA slots will be
recognized.

   Supported MNI options:

   @{b}*@{ub} One of "FT=0", "FT=1", "FT=2", "FT=3" selects the FIFO threshold
     for local DMA. The default is "FT=2". You should usually not need
     to change this value.

   @{b}*@{ub} One of "WAIT=1", "WAIT=0" enables/disables support for wait states
     on the GG2 board. Default is "WAIT=1". "WAIT=0" may slightly
     reduce CPU load with boards that are fast enough.


@EndNode

@Node "NODE_SPECIFICATIONS_MNI_ZTAMSNNZ" "MiamiDx.guide/NODE_SPECIFICATIONS_MNI_ZTAMSNNZ"
@Next "NODE_SPECIFICATIONS_MNI_ZTDPETNZ"
@Prev "NODE_SPECIFICATIONS_MNI_GGTDPETNZ"
@Toc "NODE_SPECIFICATIONS_MNI"

z2-am7990.mni
-------------

   Driver for the AM7990 (LANCE), AM79C90 (C-LANCE) and AM79C960
(PC-net) chips, on the Zorro bus. Supported boards at this time:

   @{b}*@{ub} Ariadne (NOT Ariadne-II)

   @{b}*@{ub} CEI/Ameristar A2065

   @{b}*@{ub} Commodore A2065

   @{b}*@{ub} ConneXion in A2065-compatibility mode

   Important information for users of ConneXion boards: Make sure the
jumper on your board is configured for A2065 compatibility. The driver
does not support the ConneXion native mode at this time.

   Important information for users of A2065 boards and ConneXion
boards: When switching from SANA-II to MNI drivers you need to first
change the configuration to MNI in Miami, save the settings, and then
reboot your computer before going online again. That is necessary
because A2065 SANA-II drivers can only be removed from memory by
rebooting the computer.

   Important information for users of Ariadne boards: Your Amiga may
already have an Ariadne driver in "SYS:Expansion". If so then you need
to remove that driver and reboot your Amiga before going online with
the new MNI driver. Otherwise your Amiga may "hang".

   Supported MNI options:

   @{b}*@{ub} Ariadne only: MEDIA=AUTO (Default. Enables automatic media
     detection)

   @{b}*@{ub} Ariadne only: MEDIA=10BASE2 (Selects 10-Base-2, i.e. Coax, BNC,
     Cheapernet cabling)

   @{b}*@{ub} Ariadne only: MEDIA=10BASET (Selects 10-Base-T, i.e. RJ45, UTP
     cabling)


@EndNode

@Node "NODE_SPECIFICATIONS_MNI_ZTDPETNZ" "MiamiDx.guide/NODE_SPECIFICATIONS_MNI_ZTDPETNZ"
@Next "NODE_SPECIFICATIONS_MNI_ZTMBESNFZ"
@Prev "NODE_SPECIFICATIONS_MNI_ZTAMSNNZ"
@Toc "NODE_SPECIFICATIONS_MNI"

z2-dp8390.mni
-------------

   Driver for the DP8390 chip (and its numerous clones, e.g. integrated
chips used for NE2000-compatible boards), on the Zorro bus. Supported
boards at this time:

   @{b}*@{ub} ASDG LanRover EB920

   @{b}*@{ub} Hydra AmigaNet

   @{b}*@{ub} Ariadne-II (NOT Ariadne)

   @{b}*@{ub} X-Surf

   Important information for ASDG LanRover EB920 owners: The board has
a jumper that selects the interrupt (2 or 6). You MUST use an MNI
option that corresponds to the jumper setting on your board. Otherwise
your Amiga will crash. Also, some EB920 boards do not have an on-board
MAC address ROM. If your board is among them then the MAC address
returned by "query device" in "MNI parameters" is 00:00:00:00:00:00.
In that case you need to enter a dummy address and select "Override".
Please consult the documentation of your EB920 board for more
information on this.

   Important information for Hydra AmigaNet owners: With a reasonably
fast CPU (040 or higher) this driver typically achieves very high
throughput (> 800 kB/s) on local networks. If you get poor performance
(500 kB/s or less) on a local network then your Hydra board is most
likely defective. Unfortunately quite a lot of Hydra boards seem to
have this problem. Such poor performance is NOT the result of a bug in
the driver.

   Important information for users of Ariadne-II boards: Your Amiga may
already have an Ariadne-II driver in "SYS:Expansion". If so then you
need to remove that driver and reboot your Amiga before going online
with the new MNI driver. Otherwise your Amiga may "hang".

   Supported MNI options:

   @{b}*@{ub} One of "FT=0", "FT=1", "FT=2", "FT=3" selects the FIFO threshold
     for local DMA. The default is "FT=2". You should usually not need
     to change this value.

   @{b}*@{ub} ASDG LanRover EB920 only: One of "INT=2" or "INT=6". This option
     MUST be set to correspond with the jumper setting on the board.

   @{b}*@{ub} Ariadne-II and X-Surf only: One of "MEDIA=AUTO", "MEDIA=10BASE2" or
     "MEDIA=10BASET" to select the type of cabling.

   @{b}*@{ub} Ariadne-II and X-Surf only: One of "DUPLEX=FULL" or "DUPLEX=HALF"
     to select fullduplex or halfduplex (default).


@EndNode

@Node "NODE_SPECIFICATIONS_MNI_ZTMBESNFZ" "MiamiDx.guide/NODE_SPECIFICATIONS_MNI_ZTMBESNFZ"
@Next "NODE_SPECIFICATIONS_MNI_ZTSMCNOCNZ"
@Prev "NODE_SPECIFICATIONS_MNI_ZTDPETNZ"
@Toc "NODE_SPECIFICATIONS_MNI"

z2-mb86950.mni
--------------

   Driver for the Fujitsu MB86950 Ethernet chip, on the Zorro bus.
Supported boards at this time:

   @{b}*@{ub} QuickNet QN2000

   Important information for QuickNet QN2000 owners: The board has a
switch on the back, which changes the product ID between 1 and 2. Both
product IDs are supported, but product ID 2 tends to work better. It is
therefore recommended that you configure your board for product ID 2,
if possible. To do this first check which product ID you have (click on
"Find Boards" in Miami). If the product ID is 1 then toggle the switch,
reboot your Amiga, and try again. Not all boards can be set to product
ID 2. Some only support product ID 1, in all switch settings.

   Supported MNI options: none.


@EndNode

@Node "NODE_SPECIFICATIONS_MNI_ZTSMCNOCNZ" "MiamiDx.guide/NODE_SPECIFICATIONS_MNI_ZTSMCNOCNZ"
@Prev "NODE_SPECIFICATIONS_MNI_ZTMBESNFZ"
@Toc "NODE_SPECIFICATIONS_MNI"

z2-smc91c90.mni
---------------

   Driver for the SMC91C90 chip (and its successors, e.g. the SMSC
LAN91C94), on the Zorro bus. Supported boards at this time:

   @{b}*@{ub} CEI/Ameristar A4066

   Supported MNI options: none.


@EndNode

@Node "NODE_SPECIFICATIONS_DIALER" "MiamiDx.guide/NODE_SPECIFICATIONS_DIALER"
@Next "NODE_SPECIFICATIONS_AREXX"
@Prev "NODE_SPECIFICATIONS_MNI"
@Toc "NODE_SPECIFICATIONS"

Dialer command language
=======================

   The following commands are supported by the dialer:

@{b}ABORT "text1","text2",...@{ub}
     Specify a list of texts that cause MiamiDx to completely abort
     dialing, e.g. "NO DIALTONE" from the modem.

@{b}ASKPASSWORD@{ub}
     Pop up a requester asking the user for the password.

@{b}DELAY secs@{ub}
     Wait for the specified number of seconds.

@{b}DIALNEXT "text1","text2",...@{ub}
     Specify a list of texts that cause MiamiDx to hang up the phone
     and dial the next number, e.g. "BUSY" from the modem.

@{b}PARSEPASSWORD "endchar"@{ub}
     Parses all characters from the modem up to, but not including
     <endchar>, and replaces the current password by this text. This
     command can be useful for one-time password systems that send the
     password for the next session during login.

@{b}REDIAL "text1","text2",...@{ub}
     Specify a list of texts that cause MiamiDx to hang up the phone
     and redial the current number, e.g. "BUSY" from the modem.

@{b}SAVECONFIG@{ub}
     Save the current configuration (settings) to disk. This command is
     usually used after PARSEPASSWORD to save the settings containing
     the new password.

@{b}SEND "text"@{ub}
     Send <text> to the modem. A linefeed/carriage return is @{i}not@{ui}
     automatically appended. MiamiDx recognizes the following standard
     control sequences: \\",\\\\,\\r,\\n. In addition "\\u" and "\\p"
     are supported to send the current login id (user id) or password,
     respectively.

@{b}SENDBREAK@{ub}
     Send a serial port "break" signal. This is used by some terminal
     servers to switch to command mode.

@{b}SENDPAD "text",padding@{ub}
     Send <text> to the modem, padded with spaces up to a total length
     of <padding>. Example: `SENDPAD "abc",5' would send "abc  ".

@{b}SENDPASSWORD@{ub}
     Send the current password, followed by a "\\r".

@{b}SENDUSERID@{ub}
     Send the current user id (login id), followed by a "\\r".

@{b}TIMEOUT secs@{ub}
     Specify the amount of time to wait for a text during WAIT or
     WAITPPP before giving up.

@{b}WAIT "text"@{ub}
     Wait for "text" to be received from the modem.

@{b}WAITCONNECT@{ub}
     Wait for a CONNECT message and the following text (usually the
     connection speed) to be received from the modem. This is identical
     to `WAIT "CONNECT"', except that MiamiDx copies anything following
     the `CONNECT' message on the same line to an internal buffer, and
     later displays it in the status area and optionally in the control
     panel. With many modems this allows you to see the speed at which
     your modem connected.

@{b}WAITPPP@{ub}
     Wait for the server to switch to PPP mode.

   With the commands "ABORT", "DIAL" and "DIALNEXT" you can specify the
keyword "TIMEOUT" (without the quotes), instead of a text in quotes,
e.g.
     ABORT ``NO CARRIER'',TIMEOUT

   This means that MiamiDx will abort the dial script when a timeout
occurs.  Other options are to dial the current number again, or to dial
the next number when a timeout occurs.


@EndNode

@Node "NODE_SPECIFICATIONS_AREXX" "MiamiDx.guide/NODE_SPECIFICATIONS_AREXX"
@Next "NODE_SPECIFICATIONS_ENV"
@Prev "NODE_SPECIFICATIONS_DIALER"
@Toc "NODE_SPECIFICATIONS"

ARexx interface
===============

   The name of the MiamiDx ARexx port is "MIAMI.1". At the moment
MiamiDx supports all of the standard ARexx commands for MUI applications
("QUIT", "HIDE", "DEACTIVATE", "SHOW", "ACTIVATE", "INFO", "HELP") plus
the following additional commands:

@{b}CHANGEDB@{ub}
     Tells MiamiDx to re-read the file "ENVARC:MiamiChangeDB" to update
     the settings. Please see @{"Client settings" Link "NODE_SPECIFICATIONS_EXCHANGE_CLIENTS"} for more details how to
     use this feature.

@{b}GETCONNECT [interface]@{ub}
     Returns the connection string that followed the `CONNECT' message
     from the modem on the specified interface. Usually this string
     contains an indication of the connection speed. If no interface is
     specified then the GUI default interface is used.

@{b}GETCONNECTTIME [interface]@{ub}
     Returns the number of seconds since MiamiDx received the `CONNECT'
     message from the modem on the specified interface. If no interface
     is specified then the GUI default interface is used.

@{b}GETONLINETIME [interface]@{ub}
     Returns the number of seconds the specified interface has been
     online in the `result' variable. If no interface is specified then
     the GUI default interface is used.

@{b}GETSETTINGSNAME@{ub}
     Returns the file name of the current settings file in the result
     variable.

@{b}GETTRANSFEREDBYTES [interface]@{ub}
     Returns the number of bytes transfered on the specified interface.
     If no interface is specified then the GUI default interface is
     used.  The number is transfered as a 64-bit value, split into two
     32-bit integers, which are sent in a string, separated by a space,
     e.g.  "12 50", meaning that 12*2^32+50 bytes have been transfered.

@{b}HIDEPANEL@{ub}
     Closes the control panel.

@{b}ISONLINE [interface]@{ub}
     Checks if the specified interface is online and sets the error code
     ("RC") accordingly. 1 means: the interface is online. 0 means: the
     interface is offline. If no interface is specified then the GUI
     default interface is used.

@{b}KILLGUI@{ub}
     Iconifies MiamiDx's windows and unloads the current GUI module.

@{b}LOADSETTINGS file/a@{ub}
     Loads the specified settings file.

@{b}LOCKGUI@{ub}
     Locks the user interface, i.e. displays a busy pointer. Calls to
     this function nest.

@{b}OFFLINE [interface]@{ub}
     Hang up and go offline with the specified interface. If no
     interface is specified then the GUI default interface is used.
     Same as clicking on the "Off" gadget.

@{b}ONLINE [interface]@{ub}
     Attempt to go online with the specified interface. If no interface
     is specified then the GUI default interface is used. Same as
     clicking on the "Onl" gadget.

@{b}ONLINEGUI interface@{ub}
     Make "interface" the GUI default interface and attempt to go online
     with it. Same as clicking on "Onl+GUI".

@{b}QUITFORCE@{ub}
     Using the "QUIT" command from an ARexx script is the safest way to
     quit Miami, because MiamiDx only attempts to go offline and quit
     if no other ARexx scripts are still running, to avoid deadlocks.
     The disadvantage of this is that there may be timing problems if
     your ARexx control is complex, involves multiple ARexx scripts (in
     particular scripts for earlier events), and one or more scripts
     are still running when the "QUIT" command is issued: MiamiDx would
     then refuse to quit, even though it might be safe to wait and quit
     later. In that case try the "QUITFORCE" command: it forces MiamiDx
     to wait until all ARexx scripts have completed, and then quit.
     Warning: this command will lock up MiamiDx if one of the pending
     ARexx scripts never returns, e.g. because of an inifite loop or a
     recursive call, so it is potentially dangerous if your ARexx
     scripts are buggy.

@{b}SHOWPANEL@{ub}
     Opens the control panel.

@{b}UNLOCKGUI@{ub}
     Unlocks the user interface, i.e. removes the busy pointer and
     replaces it with the normal mouse pointer if no more instances of
     LOCKGUI are pending.


@EndNode

@Node "NODE_SPECIFICATIONS_ENV" "MiamiDx.guide/NODE_SPECIFICATIONS_ENV"
@Next "NODE_SPECIFICATIONS_EXCHANGE"
@Prev "NODE_SPECIFICATIONS_AREXX"
@Toc "NODE_SPECIFICATIONS"

Environment variables
=====================

   Users usually do not need to set any environment variables in order
to use MiamiDx. Nevertheless here is a list of all variables MiamiDx
uses, in case you want to make manual changes:

@{b}DOMAIN, DOMAINNAME@{ub}
     These variables are set automatically by MiamiDx, whenever MiamiDx
     goes online. They are set to your current domain (i.e. to the part
     of your host name which follows the first ".").

@{b}HOME@{ub}
     This variable is set automatically by MiamiDx, whenever MiamiDx
     goes online. It is set to the home directory configured in
     Database/Users, for the user you selected on the TCP/IP page.

@{b}HOST, HOSTNAME@{ub}
     These variables are set automatically by MiamiDx, whenever MiamiDx
     goes online. They are set to your configured host name (for static
     host names), or to the host name corresponding to your IP address,
     found by MiamiDx through reverse DNS lookup. If no host name was
     found then these variables are set to your IP address.

@{b}MagicWB@{ub}
     If no user interface is specified (by the user, in the settings
     file, or in the environment variable "ENV:MIAMI/GUI") then MiamiDx
     falls back to using either "MUI" or "MUIMWB" as the default GUI.
     "MUIMWB" is used if the "MagicWB" variable exists, indicating that
     MagicWB has been installed.

@{b}REALNAME@{ub}
     This variable is set automatically by MiamiDx, whenever MiamiDx
     goes online. It is set to the real name configured on the TCP/IP
     page.

@{b}SOCKETCONFIG@{ub}
     This variable is set automatically by MiamiDx, whenever MiamiDx
     goes online. It is required by the freeware "socket.library"
     emulation library (for I-Net-225-compatible software), and is set
     in a way that allows that library to work properly.

@{b}USERNAME@{ub}
     This variable is set automatically by MiamiDx, whenever MiamiDx
     goes online. It is set to the user name configured on the TCP/IP
     page.

@{b}MIAMI/GUI@{ub}
     This variable should contain the name of your default GUI engine
     (e.g. `MUI', `MUIMWB' or `GTLayout'). It is set automatically
     during installation.

@{b}MIAMI/SSLLIB@{ub}
     This variable is only needed when you use MiamiSSL, and is set
     automatically during the installation of MiamiSSL. It should
     contain the name of your SSL encryption library, i.e. either
     `Miami:Libs/miamisslintl.library' or
     `Miami:Libs/miamisslusa.library'.


@EndNode

@Node "NODE_SPECIFICATIONS_EXCHANGE" "MiamiDx.guide/NODE_SPECIFICATIONS_EXCHANGE"
@Next "NODE_SPECIFICATIONS_CONFIGFILES"
@Prev "NODE_SPECIFICATIONS_ENV"
@Toc "NODE_SPECIFICATIONS"

Exchanging settings
===================

   The MiamiDx settings are saved in an IFF file, compatible with the
format Miami uses, i.e. a settings file saved by Miami can be loaded
directly into MiamiDx. A settings file saved by MiamiDx can be loaded
by Miami as well, but only the settings for the GUI default interface
are picked up by Miami then.

   The IFF format used by the settings file is currently intentionally
undocumented. However MiamiDx allows you to import and export settings
in a variety of ways:


 @{" Exchanging passwords " Link "NODE_SPECIFICATIONS_EXCHANGE_PASSWORDS"}                                         Exchanging password files
 @{" Client settings " Link "NODE_SPECIFICATIONS_EXCHANGE_CLIENTS"}                                              Custom settings for some clients


@EndNode

@Node "NODE_SPECIFICATIONS_EXCHANGE_PASSWORDS" "MiamiDx.guide/NODE_SPECIFICATIONS_EXCHANGE_PASSWORDS"
@Next "NODE_SPECIFICATIONS_EXCHANGE_CLIENTS"
@Toc "NODE_SPECIFICATIONS_EXCHANGE"

Exchanging passwords
--------------------

   MiamiDx allows you to freely import and export all files from the
Unix/AmiTCP @{b}db@{ub} directories, with one exception: the @{b}passwd@{ub} file can be
imported, but the passwords are cleared in the process, and thus have
to be reentered manually in MiamiDx.

   The reason for this is: AmiTCP (at least up to version 4.3) uses the
DES algorithm for password encryption. DES is a cryptographically
strong encryption algorithm that is subject to US export restrictions.
A program implementing DES may not be exported from the US without an
individual permit, and the US government currently does not issue such
permits.

   The result is that any kind of export of AmiTCP from the US is
illegal. This includes downloading the AmiTCP archive from an ftp
server in the US to a computer outside of the US. For this reason
AmiTCP may not be uploaded to all Aminet sites, severely restricting
the availability of AmiTCP.

   For MiamiDx things would have been even worse: since I am developing
MiamiDx within the US (not in Finland like NSDi) I would not have been
allowed to send MiamiDx to @{i}anybody@{ui} outside of the US, regardless of the
way I distribute it. I therefore decided not to use DES in MiamiDx, but
to use a different encryption algorithm that is not subject to US export
restrictions.

   MiamiDx uses an iterated version of MD5 for password encryption. This
algorithm is cryptographically strong, i.e. not known to be breakable
except by exhaustive search, just like DES. However since MD5 is, unlike
DES, a one-way algorithm, it cannot be decrypted and therefore is not
subject to US export restrictions.

   This means it is completely legal to import and export MiamiDx to
and from the US, to upload MiamiDx to Aminet sites and other ftp sites,
and to use MiamiDx in the US and other countries (unless some country
forbids the use of MD5).

   I am sorry for the problems this may cause for users who have to
maintain multiple and/or large password files, but I do not see any
other way of handling this situation.


@EndNode

@Node "NODE_SPECIFICATIONS_EXCHANGE_CLIENTS" "MiamiDx.guide/NODE_SPECIFICATIONS_EXCHANGE_CLIENTS"
@Prev "NODE_SPECIFICATIONS_EXCHANGE_PASSWORDS"
@Toc "NODE_SPECIFICATIONS_EXCHANGE"

Custom client settings
----------------------

   Some TCP/IP clients such as AmiTalk require changes to the settings
database that most protocol stacks store in the "db" directory. Usually
entries have to be added to the "services" or "inetd.conf" file.

   With MiamiDx you can make the appropriate changes directly through
the graphical user interface, i.e. just select the "Database" page, the
correct section (e.g. "services"), and add the entries you need.

   In some situations it can be more convenient to automatize this
process, e.g. to have the Installer script of a TCP/IP client make the
required changes by itself, without bothering the user. With MiamiDx
this works as follows:

   @{b}*@{ub} You first need to append a line to the file "ENVARC:MiamiChangeDB"
     that looks as follows:
          ADD services ntalk 518/udp
     or
          ADD inetd ntalk dgram udp wait root Servers:talkd (talkd)
     Whenever MiamiDx is started it automatically reads the contents of
     this file (if it exists), updates the settings, and saves the
     resulting settings.

   @{b}*@{ub} If MiamiDx is running when the client is installed and you want
     MiamiDx to update its settings immediately you should send the
     "CHANGEDB" ARexx command to MiamiDx after modifying the above file.

   You can add entries to any of MiamiDx's database tables this way.
However for security reasons only those tables which are commonly used
by clients (`inetd' and `services') are directly changed by MiamiDx. If
applications try to change any other table (e.g. the sensitive `users'
table), then MiamiDx shows a requester, asking the user for
confirmation, after receiving the "CHANGEDB" command.

   To summarize: In your Installer scripts you should have statements
as follows to automatically configure MiamiDx for your client:

     echo >>ENVARC:MiamiChangeDB ``ADD services ntalk 518/udp''
     rx ``address MIAMI.1;CHANGEDB''

   If MiamiDx is running it updates the settings immediately. Otherwise
MiamiDx picks up the changes the next time it is started.


@EndNode

@Node "NODE_SPECIFICATIONS_CONFIGFILES" "MiamiDx.guide/NODE_SPECIFICATIONS_CONFIGFILES"
@Next "NODE_SPECIFICATIONS_PANELAPI"
@Prev "NODE_SPECIFICATIONS_EXCHANGE"
@Toc "NODE_SPECIFICATIONS"

Misc. config files
==================

   Several utilities that are part of the MiamiDx package, including
MiamiTelnet, MiamiTelnetD, miamil2tp.device, miamipppoe.device and
miamipptp.device, support config files that have a common overall
format, and only differ in the specific name-value pairs for each
utility. The overall format of these config files is as follows.

   Config files are ASCII text files. Each line can contain either a
comment (starting with ";" or "#") or a command. Comments can follow
commands in the same line as well.

   Use " for quoting parameters, e.g. "quoted text". Quoted text can
cross line boundaries and contain spaces. You can also cross line
boundaries by putting a "\\" (line continuation character) at the end.

   The config file basically consists of a series of "profile"
definition with its own name-value pairs. The various utilities use
profiles in different ways. For instance in MiamiTelnet a profile
defines a host you want to connect to, and if you want to connect to
the same host in different ways, e.g. on different ports, then just
create different profiles with different names for the same host.

   Each profile definition looks like this:

     profile (profilename)
     (commands for this profile)
     endprofile

   For instance:

     profile myisp
         host shell.myisp.com
         font XEN/9
     endprofile

   or:

     profile amigazone
     	host amigazone.com
     	emulation ansi
     	charset pc8
     	rows 25
     endprofile

   The "profile" and "endprofile" commands are part of the overall
config file format. The other lines (with "host ..." etc.) are example
for MiamiTelnet.  Other utilities may use different name-value pairs
here.

   Any name-value pairs outside of profile definitions are considered
global settings, valid for all profiles (unless individual profiles
override them).


@EndNode

@Node "NODE_SPECIFICATIONS_PANELAPI" "MiamiDx.guide/NODE_SPECIFICATIONS_PANELAPI"
@Prev "NODE_SPECIFICATIONS_CONFIGFILES"
@Toc "NODE_SPECIFICATIONS"

Control Panel API
=================

   MiamiDx has a control panel that can be used to examine the status
of interfaces and to take interfaces online or offline. The control
panel is implemented in a separate module. It is possible to have
multiple different control panel modules installed, each with different
GUI design and behavior. At the moment only a single control panel
module ("plain.MiamiPanel") is available. Below are the specifications
for control panel modules, allowing third parties to develop and
distribute their own modules.

   MiamiDx control panels are shared libraries that need to implement a
certain set of functions. The preferred name of these libraries is
"Miami:Libs/#?.MiamiPanel". The name of the default control panel
included in the MiamiDx distribution is "Miami:Libs/plain.MiamiPanel".
The library version has to be 4 or higher.

   If you plan to write your own control panel then please register a
name for the module with me (kruse@nordicglobal.com), to avoid name
clashes.

   Note: The information in this section is PRELIMINARY and not
structured nicely yet (no symbolic names, header files etc.). An
updated and "nicer" documentation will be part of the next major
MiamiSDK release.

   Here is the fd file for control panels:

     ##base _MiamiPanelBase
     ##bias 30
     ##public
     MiamiPanelInit(synccb,asynccb,flags,font,screen,xo,yo,sigbit)
      (a0,a1,d0,a2,a3,d1,d2,a4)
     MiamiPanelCleanup()()
     MiamiPanelAddInterface(unit,name,state,ontime,speed)(d0,a0,d1,d2,a1)
     MiamiPanelDelInterface(unit)(d0)
     MiamiPanelSetInterfaceState(unit,state,ontime)(d0,d1,d2)
     MiamiPanelSetInterfaceSpeed(unit,speed)(d0,a0)
     MiamiPanelInterfaceReport(unit,rate,now,totalhi,totallo)(d0,d1,d2,d3,d4)
     MiamiPanelToFront()()
     MiamiPanelInhibitRefresh(flag)(d0)
     MiamiPanelGetCoord(xp,yp)(a0,a1)
     MiamiPanelEvent(sigs)(d0)
     MiamiPanelRefreshName(unit,name)(d0,a0)
     MiamiPanelGetVersion()()
     ##end

   Description of all functions:

@{b}long MiamiPanelInit(void *synccb,void *asynccb,long flags,char *font,char *screen,long xo,long yo,ULONG *sigbit);@{ub}
     MiamiDx calls this function before any other function, but after
     MiamiPanelGetVersion() and usually after MiamiPanelInhibit(TRUE).
     See below for more information on these.

     The purpose of MiamiPanelInit() is to pass all relevant
     configuration parameters to the control panel, and to allow the
     control panel to initialize itself.

     Note that interface definitions are NOT passed to the control
     panel at this time. That is done at a later time. Because of that
     MiamiDx first calls MiamiPanelInhibit(TRUE) before
     MiamiPanelInit(), telling the control panel to "stay quiet" and
     not initialize display its window until all interface definitions
     have been passed and the inhibit is released, so you do NOT
     typically open your GUI window during MiamiPanelInit(). For a
     complete description of the initialization process see below.
     Control panels typically just store/copy the parameters passed in
     this function and perform some resource allocations.

     Parameters:

    @{b}syncb@{ub}
          function pointer for synchronous callback. See below for more
          info.

    @{b}asyncb@{ub}
          function pointer for asynchronous callback. See below for
          more info.

    @{b}flags@{ub}
          Flags defining the appearance of the control panel. Currently
          the following values are defined:

         @{b}1<<0@{ub}
               show connection (modem) speed of each interface

         @{b}1<<1@{ub}
               show data transfer rate of each interface

         @{b}1<<2@{ub}
               show uptime for each interface

         @{b}1<<3@{ub}
               show online/offline button for each interface

         @{b}1<<4@{ub}
               show global control buttons (show/hide/quit) and total
               uptime

    @{b}font@{ub}
          font to use in the control panel, in the notation "topaz/8".
          May be empty or NULL indicating the default font.

    @{b}screen@{ub}
          public screen name to use. May be empty or NULL indicating
          the default public screen.

    @{b}xo,yo@{ub}
          Preferred X/Y origin of the control panel window. Note: You
          MUST make sure that the control panel actually fits on the
          current screen, i.e. you may have to adjust these values
          before opening the window.

    @{b}sigbit@{ub}
          You need to set (*sigbit) to the mask of exec signal bits you
          want to be notified on. Typically you need to set this to
          something like 1<<port->mp_SigBit. (Note: Control panels
          typically do not open their window in MiamiPanelInit(), but
          they have to know which signal bits to use. This means you
          usually have to create your own MsgPort at this time and use
          it in subsequent windows, instead of letting Intuition create
          a MsgPort for you).

    @{b}(ret)@{ub}
          return TRUE for success or FALSE for failure.

@{b}void MiamiPanelCleanup(void);@{ub}
     This function is called once by MiamiDx before closing the library.
     Free all resources here, including resources allocated for each
     interface.

@{b}void MiamiPanelAddInterface(long unit,char *name,long state,long ontime,@{ub}
     char *speed);

     MiamiDx calls this function in order to add a new interface to the
     list of interfaces displayed by the control panel.

     Parameters:

    @{b}unit@{ub}
          Logical unit number of the interface.

    @{b}name@{ub}
          Interface name (usually an alias).

    @{b}state@{ub}
          Interface state. This is a bit mask defining the interface
          state.  The following states are currently defined. More than
          one bit may be set at a time, so you MUST check all bits in
          exactly the order specified below, and stop as soon as you
          have found a bit that is set. Then display the text
          corresponding to that interface state.

         @{b}1<< 8@{ub}
               going online

         @{b}1<< 9@{ub}
               going offline

         @{b}1<<10@{ub}
               suspending

         @{b}1<< 0@{ub}
               offline

         @{b}1<< 1@{ub}
               online

         @{b}1<< 2@{ub}
               suspended.

          If none of these bits is set then you should treat the
          interface as offline.

    @{b}ontime@{ub}
          Time stamp indicating the time the interface went online.

    @{b}speed@{ub}
          String describing the modem connection message. May be empty
          or NULL.

@{b}void MiamiPanelDelInterface(long unit);@{ub}
     MiamiDx calls this function in order to delete an interface from
     the list of interfaces displayed by the control panel. Note that
     during cleanup this function is NOT necessarily called for each
     interface.  Your main library cleanup code has to handle
     per-interface cleanup, if some interfaces are still in the list
     when MiamiPanelCleanup() is called.

@{b}void MiamiPanelSetInterfaceState(long unit,long state,long ontime);@{ub}
     Updates the state information for an interface. All parameters have
     the same meaning as in the function MiamiPanelAddInterface().

@{b}void MiamiPanelSetInterfaceSpeed(long unit,char *speed);@{ub}
     Updates the (modem) speed information for an interface. All
     parameters have the same meaning as in the function
     MiamiPanelAddInterface().

@{b}void MiamiPanelInterfaceReport(long unit,long rate,long now,long totalhi,unsigned long totallo);@{ub}
     Updates the data transfer information for each interface.

     Parameters:

    @{b}unit@{ub}
          Logical unit number. Same meaning as in
          MiamiPanelAddInterface().

    @{b}rate@{ub}
          data transfer rate in bytes/second.

    @{b}now@{ub}
          current date stamp. This date stamp uses the same system
          reference time as "ontime" in MiamiPanelAddInterface() and
          MiamiPanelSetInterfaceState(), so you can use (now-ontime) to
          calculate the number of seconds the interface has been online.

    @{b}totalhi/totallo@{ub}
          The total number of bytes transfered on this interface,
          expressed as a 64-bit number.

@{b}void MiamiPanelToFront(void);@{ub}
     Instructs the control panel to move its window and screen to front.

@{b}void MiamiPanelInhibitRefresh(long val);@{ub}
     Inhibits the refresh of the control panel during subsequent
     changes or updates. The purpose of this function is to allow
     MiamiDx to call MiamiPanelAdd/DelInterface() and update functions
     several times without any visible "flicker" in between. Once
     refreshs are enabled again the control panel has to refresh
     itself, reflecting all changes it has received in the meantime.

     Parameters:

    @{b}val@{ub}
          TRUE: inhibit refresh. FALSE: allow refresh. Important: This
          value MUST nest, i.e. you need to associate a counter with
          it, starting at zero, increment it for each TRUE and decrement
          it for FALSE, and only allow refreshs again once the counter
          reaches zero.

@{b}void MiamiPanelGetCoord(long *xp,long *yp);@{ub}
     You need to store the current x and y origins of your window in
     (*xp) and (*yp). MiamiDx stores these values in the settings file
     in order to implement a "snapshot" function.

@{b}void MiamiPanelEvent(ULONG sigs);@{ub}
     This function is called by MiamiDx when one of your requested
     signal bits gets set.

     Parameters:

    @{b}sigs@{ub}
          Signal bit mask, indicating which signals were set.

@{b}void MiamiPanelRefreshName(long unit,char *name);@{ub}
     Updates the name (alias) for an interface. All parameters have the
     same meaning as in the function MiamiPanelAddInterface().

@{b}long MiamiPanelGetVersion(void);@{ub}
     This function is the very first function called by MiamiDx and is
     called to ensure that both MiamiDx and the control panel are using
     compatible API versions. Currently you need to return 1.

   Interface refresh:

   Whenever interfaces have to be added, deleted or renamed the
following functions are called by MiamiDx:

   @{b}*@{ub} MiamiPanelInhibitRefresh(TRUE);

   @{b}*@{ub} MiamiPanelDelInterface, MiamiPanelAddInterface,
     MiamiPanelRefreshName, possibly multiple times.

   @{b}*@{ub} MiamiPanelInhibitRefresh(FALSE);

   Depending on the cause of the refresh MiamiDx either performs a full
refresh (deleting all old interfaces and then adding all new ones, e.g.
after loading a new settings file), or a partial refresh (any number of
Add/Del/RefreshName calls, e.g. after the user made a change in the
GUI).

   You should not make any visible changes to the control panel until
after the inhibitrefresh counter has reached zero again.

   Initialization:

   The following functions are called in this order during
initialization:

   @{b}*@{ub} MiamiPanelGetVersion()

   @{b}*@{ub} MiamiPanelInhibitRefresh(TRUE)

   @{b}*@{ub} MiamiPanelInit(...)

   @{b}*@{ub} After that the interface refresh described above is performed (full
     refresh), in order to pass interface definitions to the control
     panel. Finally:

   @{b}*@{ub} MiamiPanelInhibitRefresh(FALSE)

   This is the time when you should open a window and actually display
the control panel, i.e. within the function MiamiPanelInhibitRefresh()
you need to check if the counter reaches zero and no window has been
opened yet, and use that as a trigger for the "real" initialization of
your GUI.

   Cleanup:

   @{b}*@{ub} MiamiPanelCleanup()

   NO other functions are called, i.e. be sure to do the equivalent of
MiamiPanelDelInterface() yourself, if necessary, to free resources.

   Callbacks:

   The two function pointers synccb and asynccb are passed to the
control panel. Calling one of the functions refered to by the pointers
sends a "command" of some kind to MiamiDx.

   If you use the synchronous pointer then the command is executed
synchronously, on the current schedule, i.e. the function does not
return until the command has been executed. If you use the asynchronous
pointer then the command is queued and the function you called returns
immediately.

   Generally the asynchronous call is preferred, because it avoids
problems with recursion, event reordering or stack size. You will need
the synchronous call if the command you execute returns a result, and
you need that result in the control panel (e.g. when performing a
localization lookup).

   The calling conventions are:

   long (*synccb)(long code,long count,va_list args);

   void (*asynccb)(long code,long count,va_list args);

   The "long" returned by (*synccb) is the return value of the command
that was executed.

   Parameters:

@{b}code@{ub}
     This specifies the command to execute. ONLY the following commands
     are currently defined and are guaranteed to remain the same across
     program versions. DO NOT try to use any other commands, or your
     control panel WILL malfunction in future versions of MiamiDx:

    @{b}27@{ub}
          localization lookup. See below for more info.

    @{b}110@{ub}
          Close control panel. Send this command asynchronously when
          the user clicks the close gadget in your window. count=0, no
          args.

    @{b}56@{ub}
          Deiconify the main GUI. Send this command asynchronously when
          the user clicks on the "show" gadget in your window. count=0,
          no args.

    @{b}19@{ub}
          Iconify the main GUI. Send this command asynchronously when
          the user clicks on the "hide" gadget in your window. count=0,
          no args.

    @{b}112@{ub}
          Take a unit online. Send this command asynchronously when the
          user clicks on the "Onl" gadget for an interface. Set count
          to 1, and pass the logical interface unit in args[0].

    @{b}113@{ub}
          Take a unit offline. Send this command asynchronously when
          the user clicks on the "Off" gadget for an interface. Set
          count to 1, and pass the logical interface unit in args[0].

    @{b}123@{ub}
          Quit Miami. Send this command asynchronously when the user
          clicks on the "quit" gadget in your window.  count=0, no args.

@{b}count@{ub}
     Number of arguments in args array.

@{b}args@{ub}
     Command-specific arguments.

   A convenient way to simplify the use of the two callback functions is
by definining a helper function as follows:

     void callasync(long code,long num,...) {
     	va_list ap;
     	va_start(ap,num);
     	asynccb(code,num,ap);
     	va_end(ap);
     }

   Similarly for synchronous calls:

     long callsync(long code,long num,...) {
     	long ret;
     	va_list ap;
     	va_start(ap,num);
     	ret=synccb(code,num,ap);
     	va_end(ap);
     	return ret;
     }

   This way you can use function calls such as

   callasync(112,1,unit); or callasync(56,0);

   in your code, without having to explicitly deal with argument arrays.

   Localization:

   In order to look up the localized version of a program string use
the synchronous function callback with code 27. Set count to 1, and
pass the string ID of the string you want to look up in args[0].

   The following string IDs are currently defined, and are guaranteed
not to change in future versions of MiamiDx:

   @{b}*@{ub} For interface status messages:

    @{b}5000@{ub}
          ">On"

    @{b}5001@{ub}
          ">Of"

    @{b}5002@{ub}
          ">Su"

    @{b}5003@{ub}
          "Onl"

    @{b}5004@{ub}
          "Off"

    @{b}5005@{ub}
          "Sus"

   @{b}*@{ub} For control gadgets:

    @{b}5006@{ub}
          "Show"

    @{b}5007@{ub}
          "Hide"

    @{b}5008@{ub}
          "Quit"

    @{b}5009@{ub}
          "Onl"

    @{b}5010@{ub}
          "Off"

   With the helper function defined above this means that you can e.g.
look up the localized string for "Show" by calling

   str=(char *)callsync(27,1,5006);


@EndNode

@Node "NODE_UTILITY" "MiamiDx.guide/NODE_UTILITY"
@Next "NODE_COMPATIBILITY"
@Prev "NODE_SPECIFICATIONS"
@Toc "Main"

Utility Programs
****************


 @{" MiamiAddr " Link "NODE_UTILITY_ADDR"}                                              MiamiAddr
 @{" MiamiArp " Link "NODE_UTILITY_ARP"}                                               MiamiArp
 @{" MiamiDiG " Link "NODE_UTILITY_DIG"}                                               MiamiDiG
 @{" MiamiDNSQuery " Link "NODE_UTILITY_DNSQUERY"}                                          MiamiDNSQuery
 @{" MiamiDoD " Link "NODE_UTILITY_DOD"}                                               MiamiDoD
 @{" MiamiFinger " Link "NODE_UTILITY_FINGER"}                                            MiamiFinger
 @{" MiamiFtp " Link "NODE_UTILITY_FTP"}                                               MiamiFtp
 @{" MiamiHost " Link "NODE_UTILITY_HOST"}                                              MiamiHost
 @{" MiamiIfConfig " Link "NODE_UTILITY_IFCONFIG"}                                          MiamiIfConfig
 @{" MiamiInit " Link "NODE_UTILITY_MIAMIINIT"}                                              MiamiInit
 @{" MiamiIPFW " Link "NODE_UTILITY_IPFW"}                                              MiamiIPFW
 @{" MiamiIPNatD " Link "NODE_UTILITY_IPNATD"}                                            MiamiIPNatD
 @{" MiamiMapMBone " Link "NODE_UTILITY_MAPMBONE"}                                          MiamiMapMBone
 @{" MiamiMRInfo " Link "NODE_UTILITY_MRINFO"}                                            MiamiMRInfo
 @{" MiamiMRouteD " Link "NODE_UTILITY_MROUTED"}                                           MiamiMRouteD
 @{" MiamiMTrace " Link "NODE_UTILITY_MTRACE"}                                            MiamiMTrace
 @{" MiamiNetStat " Link "NODE_UTILITY_NETSTAT"}                                           MiamiNetStat
 @{" MiamiNSLookup " Link "NODE_UTILITY_NSLOOKUP"}                                          MiamiNSLookup
 @{" MiamiPing " Link "NODE_UTILITY_PING"}                                              MiamiPing
 @{" MiamiRegister " Link "NODE_UTILITY_MIAMIREGISTER"}                                          MiamiRegister
 @{" MiamiRemind " Link "NODE_UTILITY_REMIND"}                                            MiamiRemind
 @{" MiamiResolve " Link "NODE_UTILITY_RESOLVE"}                                           MiamiResolve
 @{" MiamiRoute " Link "NODE_UTILITY_ROUTE"}                                             MiamiRoute
 @{" MiamiSecureShellKeyGen " Link "NODE_UTILITY_SECURESHELLKEYGEN"}                                 MiamiSecureShellKeyGen
 @{" MiamiSecureShellKill " Link "NODE_UTILITY_SECURESHELLKILL"}                                   MiamiSecureShellKill
 @{" MiamiSysCtl " Link "NODE_UTILITY_SYSCTL"}                                            MiamiSysCtl
 @{" MiamiTCPDump " Link "NODE_UTILITY_TCPDUMP"}                                           MiamiTCPDump
 @{" MiamiTelnet " Link "NODE_UTILITY_TELNET"}                                            MiamiTelnet
 @{" MiamiTelnetD " Link "NODE_UTILITY_TELNETD"}                                           MiamiTelnetD
 @{" MiamiTraceRoute " Link "NODE_UTILITY_TRACEROUTE"}                                        MiamiTraceRoute
 @{" miamil2tp.device " Link "NODE_UTILITY_L2TP"}                                       miamil2tp.device
 @{" miamipppoe.device " Link "NODE_UTILITY_PPPOE"}                                      miamipppoe.device
 @{" miamipptp.device " Link "NODE_UTILITY_PPTP"}                                       miamipptp.device
 @{" sanamni.device " Link "NODE_UTILITY_SANAMNI"}                                         sanamni.device


@EndNode

@Node "NODE_UTILITY_ADDR" "MiamiDx.guide/NODE_UTILITY_ADDR"
@Next "NODE_UTILITY_ARP"
@Toc "NODE_UTILITY"

MiamiAddr
=========

   Convert IP address between different representations

   Usage:

@{b}MiamiAddr -p IP-address@{ub}
     where IP-address is in 1.2.3.4 format (decimal).

@{b}MiamiAddr -n hex-IP-address@{ub}
     where hex-IP-address is in 0x12345678 format (hexadecimal).

   Both forms of the command display the IP address in all formats
(decimal and hexadecimal).


@EndNode

@Node "NODE_UTILITY_ARP" "MiamiDx.guide/NODE_UTILITY_ARP"
@Next "NODE_UTILITY_DIG"
@Prev "NODE_UTILITY_ADDR"
@Toc "NODE_UTILITY"

MiamiArp
========

   Address resolution display and control

   Usage:

@{b}MiamiArp hostname@{ub}
     Display current Arp entry for <hostname>

@{b}MiamiArp [-n] -a@{ub}
     Display all of the current Arp entries. If "-n" is specified then
     all entries are listed numerically instead of symbolically.

@{b}MiamiArp -d hostname@{ub}
     Delete arp entry for <hostname>

@{b}MiamiArp -s hostname hw_addr [temp] [pub]@{ub}
     Create an Arp entry for <hostname> with the hardware address
     <hw_addr>. The entry is permanent unless the word "temp" is given.
     If the word "pub" is given then this system will act as an Arp
     server for the specified host.

@{b}MiamiArp -f filename@{ub}
     Read and execute commands from the file <filename>.


@EndNode

@Node "NODE_UTILITY_DIG" "MiamiDx.guide/NODE_UTILITY_DIG"
@Next "NODE_UTILITY_DNSQUERY"
@Prev "NODE_UTILITY_ARP"
@Toc "NODE_UTILITY"

MiamiDiG
========

   Perform a DNS query for arbitrary DNS information.

   Usage:

     MiamiDiG [@server] [domain] [q-type] [q-class] {q-opt} {d-opt} [%comment]

   Meaning of all parameters:

@{b} @server@{ub}
     Host name or IP address of the DNS server to use for queries.

@{b}domain@{ub}
     Query item, i.e. domain or host name to look up.

@{b}q-type@{ub}
     Query type. Usually one of "a", "any", "mx" etc. to look up the
     corresponding DNS record. Default: "a".

@{b}q-class@{ub}
     Query class. Usually "in" for Internet. Default: "in".

@{b}q-opt@{ub}
     Query options. One of
    @{b}-x dot-notation-address@{ub}
          Shortcut to in-addr.arpa lookups.

    @{b}-f file@{ub}
          Batch mode input file name.

    @{b}-T time@{ub}
          Batch mode time delay, per query.

    @{b}-p port@{ub}
          Port to use for DNS query. Default: 53.

    @{b}-t query-type@{ub}
          Same as q-type.

    @{b}-c query-class@{ub}
          Same as q-class.

@{b}d-opt@{ub}
     Data options. One of
    @{b}[no]aa@{ub}
          [Disable] Enable returning authorized records only.

    @{b}[no]ko@{ub}
          [Disable] Enable keeping the connection to the server open.
          Implies option "v".

    @{b}[no]def@{ub}
          [Disable] Enable using default names.

    @{b}[no]sea@{ub}
          [Disable] Enable using DNS search list.

    @{b}domain=...@{ub}
          Set domain.

    @{b}[no]i@{ub}
          [Disable] Enable ignoring additional data from TCP
          connections.

    @{b}[no]rec@{ub}
          [Disable] Enable recursive query.

    @{b}[no]v@{ub}
          [Disable] Enable virtual circuit (TCP connection).

    @{b}[no]an@{ub}
          [Disable] Enable displaying answer section.

    @{b}[no]qu@{ub}
          [Disable] Enable displaying question section.

    @{b}[no]au@{ub}
          [Disable] Enable displaying authority section.

    @{b}[no]ad@{ub}
          [Disable] Enable displaying additionsection.


@EndNode

@Node "NODE_UTILITY_DNSQUERY" "MiamiDx.guide/NODE_UTILITY_DNSQUERY"
@Next "NODE_UTILITY_DOD"
@Prev "NODE_UTILITY_DIG"
@Toc "NODE_UTILITY"

MiamiDNSQuery
=============

   Perform a DNS query for a host name record.

   Usage:

     MiamiDNSQuery [-h] host [-n ns] [-t type] [-c class]

   Meaning of all parameters:

@{b}[-h] host@{ub}
     Host name to look up.

@{b}-n ns@{ub}
     DNS server to use.

@{b}-t type@{ub}
     Query type, e.g. "a" or "mx".

@{b}-c class@{ub}
     Query class, usually "in" for Internet.


@EndNode

@Node "NODE_UTILITY_DOD" "MiamiDx.guide/NODE_UTILITY_DOD"
@Next "NODE_UTILITY_FINGER"
@Prev "NODE_UTILITY_DNSQUERY"
@Toc "NODE_UTILITY"

MiamiDoD
========

   MiamiDoD provides dial-on-demand functionality similar to the feature
"Auto-connect from offline" (see @{"Interfaces Auto-connect/disconnect" Link "NODE_CONFIG_OTHER_IFACEAUTO"}) in
MiamiDx, but allows more detailed control over what types of traffic
cause the interface to go online. If you want to use this feature then
disable "Auto-connect from offline" in MiamiDx and start MiamiDoD
instead after starting MiamiDx.

   Usage: MiamiDoD [-p pcap_spec] [-I interface]

   Options are:

@{b}-p pcap_spec@{ub}
     libpcap packet expression. Please see @{"MiamiRemind" Link "NODE_UTILITY_REMIND"} for examples of
     valid expressions.

@{b}-I interface@{ub}
     Interface to go online with


@EndNode

@Node "NODE_UTILITY_FINGER" "MiamiDx.guide/NODE_UTILITY_FINGER"
@Next "NODE_UTILITY_FTP"
@Prev "NODE_UTILITY_DOD"
@Toc "NODE_UTILITY"

MiamiFinger
===========

   MiamiFinger displays information about the system users.

   Usage: MiamiFinger [-l] [user][@machinename]

   Options are:

@{b}-l@{ub}
     Show the long output format (for remote machines: send the "/W"
     modifier to the remote finger daemon).

   If no machine name is specified then "localhost" is assumed.

   If a user is specified then information about this user is displayed.
Otherwise some default information for the fingerd connecting to is
displayed. In many cases this is some general system information and/or
a list of users currently logged on.

   This implementation of MiamiFinger supports T/TCP for faster finger
lookups.


@EndNode

@Node "NODE_UTILITY_FTP" "MiamiDx.guide/NODE_UTILITY_FTP"
@Next "NODE_UTILITY_HOST"
@Prev "NODE_UTILITY_FINGER"
@Toc "NODE_UTILITY"

MiamiFtp
========

   Simple command line-based FTP client.

   Usage:

@{b}MiamiFtp [options]@{ub}
     Start up MiamiFtp in interactive mode.

@{b}MiamiFtp [options] host [port]@{ub}
     Start up MiamiFtp, connect to the specified host and port, and
     switch to interactive mode.

@{b}MiamiFtp [options] ftp://[user:password@]host[:port]/file@{ub}
     Download file from FTP site.

@{b}MiamiFtp [options] http://host[:port]/file@{ub}
     Download file from web site by HTTP.

   Options are:

@{b}-a@{ub}
     Bypass normal login procedure, and use anonymous login instead.

@{b}-g@{ub}
     Disables file name globbing

@{b}-i@{ub}
     Turns off interactive prompting during multiple file transfers.

@{b}-n@{ub}
     Refrains from attempting to auto-login upon initial connection.
     If auto-login is enabled MiamiFtp will check its configuration
     file for an entry describing an account on the remote machine.  If
     no entry exists MiamiFtp will prompt for the remote machine login
     name (default is the user identity on the local machine) and, if
     necessary, prompt for a password and an account with which to
     login.

@{b}-p@{ub}
     Enable passive mode operation for use behind connection filtering
     firewalls.

@{b}-P port@{ub}
     Set the port number to connect to.

@{b}-t@{ub}
     Enables packet tracing (not implemented).

@{b}-v@{ub}
     Enable verbose mode.

@{b}-V@{ub}
     Disable verbose mode.

   When MiamiFtp switches to interactive mode the prompt "MiamiFtp>"
appears. For a list of supported commands see @{"MiamiFtp commands" Link "NODE_UTILITY_FTP_COMMANDS"}.

   If MiamiFtp receives a Ctrl-E signal while a transfer is in progress
the current transfer rate statistics will be written to the terminal,
in the same format as the standard completion message.

   The file "Miami:data/MiamiFtp.config" is read upon startup.  The file
contains login and initialization information used by the auto-login
process. For a description of supported tokens please see
@{"MiamiFtp configuration" Link "NODE_UTILITY_FTP_CONFIG"}. The tokens may be separated by spaces, tabs, or
new-lines.


 @{" MiamiFtp commands " Link "NODE_UTILITY_FTP_COMMANDS"}                               Supported commands
 @{" MiamiFtp configuration " Link "NODE_UTILITY_FTP_CONFIG"}                          Supported configuration tokens.


@EndNode

@Node "NODE_UTILITY_FTP_COMMANDS" "MiamiDx.guide/NODE_UTILITY_FTP_COMMANDS"
@Next "NODE_UTILITY_FTP_CONFIG"
@Toc "NODE_UTILITY_FTP"

MiamiFtp commands
-----------------

   MiamiFtp supports the following commands in interactive mode:

@{b}$ macroname arguments@{ub}
     Execute named macro that was defined with the "macdef" command
     earlier.

@{b}account password@{ub}
     Supply a supplemental account password required by a remote system
     for access to resources once a login has been successfully
     completed. If no argument is included the user will be prompted
     for an account password in non-echoing input mode.

@{b}append local-file remote-file@{ub}
     Append a local file to a file on the remote machine. If
     "remote-file" is left unspecified then the local file name is used
     in naming the remote file after being altered by any "ntrans" or
     "nmap" setting. File transfer uses the current settings for
     "type", "format", "mode" and "structure".

@{b}ascii@{ub}
     Set the file transfer "type" to network ASCII. This is the default
     type.

@{b}asyncio on/off@{ub}
     Enable or disable the use of asynchronous DOS I/O for local file
     access.

@{b}bell@{ub}
     Arrange that a bell be sounded after each file transfer command is
     completed.

@{b}binary@{ub}
     Set the file transfer "type" to support binary image transfer.

@{b}bye@{ub}
     Terminate the FTP session with the remote server and exit. An end
     of file will also terminate the session and exit.

@{b}case on/off@{ub}
     Toggle remote computer file name case mapping during mget
     commands. When case is on (default is off), remote computer file
     names with all letters in upper case are written in the local
     directory with the letters mapped to lower case.

@{b}cd remote-directory@{ub}
     Change the working directory on the remote machine.

@{b}cdup@{ub}
     Change the working directory on the remote machine to the parent
     of the current working directory.

@{b}chmod mode file-name@{ub}
     Change the permission modes of the specified file on the remote
     machine to the specified value.

@{b}close@{ub}
     Terminate the FTP session with the remote server and return to the
     command interpreter. Any defined macros are erased.

@{b}cr on/off@{ub}
     Toggle carriage return stripping during ascii type file retrieval.
     Records are denoted by a carriage return/linefeed sequence during
     ascii type file transfer. When cr is on (the default) carriage
     returns are stripped from this sequence to conform with the
     AmigaOS single linefeed record delimiter. Records on
     non-AmigaOS/Unix systems may contain single linefeeds. When an
     ascii type transfer is made these linefeeds may be distinguished
     from a record delimiter only when cr is off.

@{b}delete remote-file@{ub}
     Delete the specified file on the remote machine.

@{b}dir remote-directory local-file@{ub}
     Print a listing of the contents of a directory on the remote
     machine. The listing includes any system-dependent information
     that the server chooses to include. For example most Unix systems
     will produce output from the command "ls -l".  If remote-directory
     is not specified then the current working directory is used. If
     interactive prompting is on MiamiFtp will prompt the user to
     verify that the last argument is indeed the target local file for
     receiving the directory information. If local-file is not
     specified then the output is sent to the terminal.

@{b}disconnect@{ub}
     A synonym for close.

@{b}exit@{ub}
     A synonym for bye.

@{b}form format@{ub}
     Set the file transfer format. The default format is "file".

@{b}ftp host port@{ub}
     A synonym for open

@{b}get remote-file local-file@{ub}
     Retrieve the specified file and store it on the local machine.  If
     the local file name is not specified then the file is given the
     same name it has on the remote machine, subject to alterations by
     the current "case", "ntrans" and "nmap" settings. The current
     settings for "type", "form", "mode" and "structure" are used while
     transfering the file.

@{b}gate host port@{ub}
     Toggle gate-ftp mode. This will not be permitted if the gate-ftp
     server has not been set (either explicitly by the user, or from
     the FTPSERVER environment variable).  If a host is given then
     gate-ftp mode will be enabled and the gate-ftp server will be set
     to the specified host. If a port is also given then that port will
     be used as the port to connect to on the gate-ftp server.

@{b}glob on/off@{ub}
     Toggle filename expansion for mdelete, mget and mput. If globbing
     is turned off then file name arguments are taken literally and not
     wild card-expanded. Globbing for mput is done using AmigaDOS wild
     card conventions. For mdelete and mget each remote file name is
     expanded separately on the remote machine, and the lists are not
     merged.

@{b}hash on/off@{ub}
     Toggle printing of hash signs ("#") during file transfer.

@{b}help command@{ub}
     Prints an informative message about the meaning of a command.  If
     no argument is given then a list of known commands is printed.

@{b}idle seconds@{ub}
     Set the inactivity timer on the remote server. If the argument is
     omitted the current inactivity timer is printed.

@{b}lcd directory@{ub}
     Change the working directory on the local machine.  If no
     directory is specified then the user's home directory is used.

@{b}less file@{ub}
     A synonym for page.

@{b}lpwd@{ub}
     Print the working directory on the local machine.

@{b}ls remote-directory local-file@{ub}
     Print a list of the files in a directory on the remote machine.
     If remote-directory is not specified then the current working
     directory is used. If interactive prompting is on MiamiFtp will
     prompt the user to verify that the last argument is indeed the
     target local file for receiving the directory information. If
     local-file is not specified then the output is sent to the
     terminal.

@{b}macdef macro-name@{ub}
     Define a macro. Subsequent lines are stored as the named macro. A
     null line (consecutive newline characters in a file or carriage
     returns from the terminal) terminates macro input mode. There is a
     limit of 16 macros and 4096 total characters in all defined
     macros. Macros remain defined until a close command is executed.
     The macro processor interprets `$' and `\\e' as special characters.
     A `$' followed by a number (or numbers) is replaced by the
     corresponding argument on the macro invocation command line.  A
     `$' followed by an `i' signals that macro processor that the
     executing macro is to be looped.  On the first pass `$i' is
     replaced by the first argument on the macro invocation command
     line, on the second pass it is replaced by the second argument,
     and so on.  A `\\e' followed by any character is replaced by that
     character.  Use the `\\e' to prevent special treatment of the `$'.

@{b}mdelete remote-files@{ub}
     Delete the specified files on the remote machine.

@{b}mdir remote-files local-file@{ub}
     Like dir, except multipe remote files may be specified.  If
     interactive prompting is on MiamiFtp will prompt the user to
     verify that the last argument is indeed the target local file for
     receiving mdir output.

@{b}mget remote-files@{ub}
     Expand the remote-files on the remote machine and do a get for
     each file name thus produced. See glob for details on the filename
     expansion. Resulting file names will then be processed according
     to the "case", "ntrans" and "nmap" settings. Files are transfered
     into the local working directory.

@{b}mkdir directory-name@{ub}
     Make a directory on the remote machine

@{b}mls remote-files local-file@{ub}
     Like ls, except multipe remote files may be specified and the
     local-file must be specified.  If interactive prompting is on
     MiamiFtp will prompt the user to verify that the last argument is
     indeed the target local file for receiving mls output.

@{b}mode mode-name@{ub}
     Set the file transfer mode. The default mode is "stream".

@{b}modtime file-name@{ub}
     Show the last modification time of the file on the remote machine.

@{b}more file@{ub}
     A synonym for page.

@{b}mput local-files@{ub}
     Expand wild cards in the list of local files given as arguments
     and do a put for each file in the resulting list. See glob for
     details on filename expansion.  Resulting file names will then be
     processed according to the "ntrans" and "nmap" settings.

@{b}msend local-files@{ub}
     A synonym for mput.

@{b}newer file-name@{ub}
     Get the file only if the modification time of the remote file is
     more recent than the file on the current system. If the file does
     not exist on the current system the remote file is considered
     newer. Otherwise the command is identical to get.

@{b}nlist remote-directory local-file@{ub}
     A synonym for ls.

@{b}nmap inpattern outpattern@{ub}
     Set or unset the filename mapping mechanism. If no arguments are
     specified the filename mapping mechanism is unset. If arguments
     are specified remote filenames are mapped during mput commands and
     put comamnds issued without a specified remote target filename.
     If arguments are specified local filenames are mapped during mget
     commands and get comamnds issued without a specified local target
     filename. This command is useful when connecting to a non-Unix
     remote computer with different file naming conventions or
     practices. The mapping follows the pattern set by inpattern and
     outpattern.  Inpattern is a template for incoming filenames (which
     may have already been processed according to the "ntrans" and
     "case" settings). Variable templating is accomplished by including
     sequences `$1', `$2', ..., `$9' in inpattern.  Use `\\' to prevent
     this special treatment of the `$' character. All other characters
     are treated literally and are used to determine the nmap inpattern
     variable values.  For example given inpattern $1.$2 and the remote
     file name "mydata.data", $1 would have the value "mydata" and $2
     would have the value "data". The outpattern determines the
     resulting mapped filename. The sequences `$1', `$2', ..., `$9' are
     replaced by any value resulting from the inpattern template.  The
     sequence `$0' is replaced by the original filename.  Additionally
     the sequence [seq1,seq2] is replaced by seq1 if seq1 is not a null
     string. Otherwise it is replaced by seq2. For example the command
     "nmap $1.$2.$3 [$1,$2].[$2,file]" would yield the output filename
     "myfile.data" for input file names "myfile.data" and
     "myfile.data.old", "myfile.file" for the input filename "myfile",
     and "myfile.myfile" for the input filename ".myfile".  Use the
     `\\e' character to prevent special treatment of the `$','[',']',
     and `,' characters.

@{b}ntrans inchars outchars@{ub}
     Set or unset the filename character translation mechanism.  If no
     arguments are specified, the filename character translation
     mechanism is unset.  If arguments are specified, characters in
     remote filenames are translated during mput commands and put
     commands issued without a specified remote target filename. If
     arguments are specified, characters in local filenames are
     translated during mget commands and get commands issued without a
     specified local target filename.  This command is useful when
     connecting to a non-Unix remote computer with different file
     naming conventions or practices.  Characters in a filename
     matching a character in inchars are replaced with the
     corresponding character in outchars.  If the character's position
     in inchars is longer than the length of outchars the character is
     deleted from the file name.

@{b}open host port@{ub}
     Establish a connection to the specified host FTP server.  An
     optional port number may be supplied, in which case MiamiFtp will
     attempt to contact an FTP server at that port.  If the auto-login
     option is on (default), MiamiFtp will also attempt to
     automatically log the user in to the FTP server (see below).

@{b}page file@{ub}
     Retrieve file and display it with a standard pager.

@{b}passive on/off@{ub}
     Toggle passive mode.  If passive mode is turned on (default is
     off), the ftp client will send a PASV command for all data
     connections instead of the usual PORT command.  The PASV command
     requests that the remote server open a port for the data connection
     and return the address of that port.  The remote server listens on
     that port and the client connects to it.  When using the more
     traditional PORT command, the client listens on a port and sends
     that address to the remote server, who connects back to it.
     Passive mode is useful when using MiamiFtp through a gateway
     router or host that controls the directionality of traffic.  (Note
     that though ftp servers are required to support the PASV command
     by RFC 1123, some do not.)

@{b}preserve on/off@{ub}
     Toggle preservation of modification times on retrieved files.

@{b}progress on/off@{ub}
     Toggle display of transfer progress bar.

@{b}prompt@{ub}
     Toggle interactive prompting.  Interactive prompting occurs during
     multiple file transfers to allow the user to selectively retrieve
     or store files.  If prompting is turned off (default is on), any
     mget or mput will transfer all files, and any mdelete will delete
     all files.  When prompting is on, the following commands are
     available at a prompt:

    @{b}n@{ub}
          Do not transfer the file.

    @{b}a@{ub}
          Answer yes to the current file, and automatically answer yes
          to any remaining files for the current command.

    @{b}p@{ub}
          Answer yes to the current file, and turn off prompt mode (as
          if prompt off had been given).

     Any other reponse will answer yes to the current file.

@{b}proxy ftp-command@{ub}
     Execute an ftp command on a secondary control connection.  This
     command allows simultaneous connection to two remote ftp servers
     for transferring files between the two servers.  The first proxy
     command should be an open, to establish the secondary control
     connection.  Enter the command "proxy ?" to see other ftp commands
     executable on the secondary connection.  The following commands
     behave differently when prefaced by proxy:

    @{b}open@{ub}
          will not define new macros during the auto-login process,

    @{b}close@{ub}
          will not erase existing macro definitions,

    @{b}get, mget@{ub}
          transfer files from the host on the primary control connection
          to the host on the secondary control connection,

    @{b}put, mput , append@{ub}
          transfer files from the host on the secondary control
          connection to the host on the primary control connection.

     Third party file transfers depend upon support of the ftp protocol
     PASV command by the server on the secondary control connection.

@{b}put local-file remote-file@{ub}
     Store a local file on the remote machine.  If remote-file is left
     unspecified, the local file name is used after processing
     according to any "ntrans" or "nmap" settings in naming the remote
     file.  File transfer uses the current settings for "type"
     ,"format" ,"mode" and "structure".

@{b}pwd@{ub}
     Print the name of the current working directory on the remote
     machine.

@{b}quit@{ub}
     A synonym for bye.

@{b}quote arg1 arg2 ...@{ub}
     The arguments specified are sent, verbatim, to the remote FTP
     server.

@{b}recv remote-file local-file@{ub}
     A synonym for get.

@{b}reget remote-file local-file@{ub}
     Reget acts like get, except that if local-file exists and is
     smaller than remote-file, local-file is presumed to be a partially
     transferred copy of remote-file and the transfer is continued from
     the apparent point of failure.  This command is useful when
     transferring very large files over networks that are prone to
     dropping connections.

@{b}remotehelp command-name@{ub}
     Request help from the remote FTP server.  If a command-name is
     specified it is supplied to the server as well.

@{b}rstatus file-name@{ub}
     With no arguments, show status of remote machine.  If file-name is
     specified, show status of file-name on remote machine.

@{b}rename from-file to-file@{ub}
     Rename the file from-file on the remote machine, to the file
     to-file.

@{b}reset@{ub}
     Clear reply queue.  This command re-synchronizes command/reply
     sequencing with the remote ftp server.  Resynchronization may be
     necessary following a violation of the ftp protocol by the remote
     server.

@{b}restart marker@{ub}
     Restart the immediately following get or put at the indicated
     marker. On AmigaOS and Unix systems marker is usually a byte
     offset into the file.

@{b}rmdir directory-name@{ub}
     Delete a directory on the remote machine.

@{b}runique@{ub}
     Toggle storing of files on the local system with unique filenames.
     If a file already exists with a name equal to the target local
     filename for a get or mget command, a ".1" is appended to the name.
     If the resulting name matches another existing file, a ".2" is
     appended to the original name.  If this process continues up to
     ".99", an error message is printed, and the transfer does not take
     place.  The generated unique filename will be reported.  The
     default value is off.

@{b}send local-file remote-file@{ub}
     A synonym for put.

@{b}sendport on/off@{ub}
     Toggle the use of PORT commands.  By default, MiamiFtp will
     attempt to use a PORT command when establishing a connection for
     each data transfer.  The use of PORT commands can prevent delays
     when performing multiple file transfers.  If the PORT command
     fails, MiamiFtp will use the default data port.  When the use of
     PORT commands is disabled, no attempt will be made to use PORT
     commands for each data transfer.  This is useful for certain FTP
     implementations which do ignore PORT commands but, incorrectly,
     indicate they've been accepted.

@{b}site arg1 arg2 ...@{ub}
     The arguments specified are sent, verbatim, to the remote FTP
     server as a SITE command.

@{b}size file-name@{ub}
     Return size of file-name on remote machine.

@{b}status@{ub}
     Show the current status of MiamiFtp.

@{b}struct struct-name@{ub}
     Set the file transfer structure to struct-name.  By default
     "stream" structure is used.

@{b}sunique on/off@{ub}
     Toggle storing of files on remote machine under unique file names.
     Remote ftp server must support ftp protocol STOU command for
     successful completion.  The remote server will report unique name.
     Default value is off.

@{b}system@{ub}
     Show the type of operating system running on the remote machine.

@{b}tenex@{ub}
     Set the file transfer type to that needed to talk to TENEX
     machines.

@{b}type type-name@{ub}
     Set the file transfer type to type-name.  If no type is specified,
     the current type is printed.  The default type is network ASCII.

@{b}umask newmask@{ub}
     Set the default umask on the remote server to newmask.  If newmask
     is omitted, the current umask is printed.

@{b}user user-name password account@{ub}
     Identify yourself to the remote FTP server.  If the password is
     not specified and the server requires it, MiamiFtp will prompt the
     user for it (after disabling local echo).  If an account field is
     not specified, and the FTP server requires it, the user will be
     prompted for it.  If an account field is specified, an account
     command will be relayed to the remote server after the login
     sequence is completed if the remote server did not require it for
     logging in.  Unless MiamiFtp is invoked with auto-login disabled,
     this process is done automatically on initial connection to the FTP
     server.

@{b}verbose on/off@{ub}
     Toggle verbose mode.  In verbose mode, all responses from the FTP
     server are displayed to the user.  In addition, if verbose is on,
     when a file transfer completes, statistics regarding the
     efficiency of the transfer are reported.  By default, verbose is
     on.

@{b}? command@{ub}
     A synonym for help.


@EndNode

@Node "NODE_UTILITY_FTP_CONFIG" "MiamiDx.guide/NODE_UTILITY_FTP_CONFIG"
@Prev "NODE_UTILITY_FTP_COMMANDS"
@Toc "NODE_UTILITY_FTP"

MiamiFtp configuration
----------------------

   The following configuration tokens can be used in the MiamiFtp
configuration file "Miami:data/MiamiFtp.config":

@{b}machine name@{ub}
     Identify a remote machine name. The auto-login process searches the
     config file for a machine token that matches the remote machine
     specified on the MiamiFtp command line or as an open command
     argument.  Once a match is made, the subsequent config file tokens
     are processed, stopping when the end of file is reached or another
     machine or a default token is encountered.

@{b}default@{ub}
     This is the same as "machine name" except that default matches any
     name.  There can be only one default token, and it must be after
     all machine tokens.  This is normally used as: "default login
     anonymous password user@site" thereby giving the user automatic
     anonymous ftp login to machines not specified in the config file.
     This can be overridden by using the "-n" flag to disable
     auto-login.

@{b}login name@{ub}
     Identify a user on the remote machine.  If this token is present,
     the auto-login process will initiate a login using the specified
     name.

@{b}password string@{ub}
     Supply a password.  If this token is present, the auto-login
     process will supply the specified string if the remote server
     requires a password as part of the login process.

@{b}account string@{ub}
     Supply an additional account password.  If this token is present,
     the auto-login process will supply the specified string if the
     remote server requires an additional account password, or the
     auto-login process will initiate an ACCT command if it does not.

@{b}macdef name@{ub}
     Define a macro.  This token functions like the MiamiFtp macdef
     command functions.  A macro is defined with the specified name;
     its contents begin with the next line in the config file and
     continue until a null line (consecutive new-line characters) is
     encountered.  If a macro named "init" is defined, it is
     automatically executed as the last step in the auto-login process.


@EndNode

@Node "NODE_UTILITY_HOST" "MiamiDx.guide/NODE_UTILITY_HOST"
@Next "NODE_UTILITY_IFCONFIG"
@Prev "NODE_UTILITY_FTP"
@Toc "NODE_UTILITY"

MiamiHost
=========

   Perform a DNS query for a host name record.

   Usage:

     MiamiHost [-w] [-v] [-r] [-t type] [-c class] [-a] host [server]

   Meaning of all parameters:

@{b}-w@{ub}
     Wait forever for a reply.

@{b}-v@{ub}
     Verbose output.

@{b}-r@{ub}
     Enable recursive processing

@{b}-t type@{ub}
     Query type, e.g. "a" or "mx".

@{b}-c class@{ub}
     Query class, usually "in" for Internet.

@{b}-a@{ub}
     Equivalent to "-v -r *".

@{b}host@{ub}
     Host name to look up.

@{b}server@{ub}
     Server to contact


@EndNode

@Node "NODE_UTILITY_IFCONFIG" "MiamiDx.guide/NODE_UTILITY_IFCONFIG"
@Next "NODE_UTILITY_MIAMIINIT"
@Prev "NODE_UTILITY_HOST"
@Toc "NODE_UTILITY"

MiamiIfConfig
=============

   Configure network interface parameters

   Note: most of the options of MiamiIfConfig should @{i}not@{ui} be used with
MiamiDx at this time, because MiamiDx usually already sets all values
correctly. Do not play around with this program. You should really know
what you are doing before trying to change any interface options.

   About the only useful options are "up" and "down" to temporarily
mark the interface as unavailable.  Note that this does @{i}not@{ui} cause the
modem to hang up. Other than that you should probably only use
MiamiIfConfig to @{i}examine@{ui} interface settings, not to change them.

   Usage: MiamiIfConfig interface [alias | -alias] [af [address
[dest_addr]] [up] [down] [netmask mask]] [metric n] [arp | -arp]
[broadcast address] [link0 | -link0] [link1 | -link1] [link2 | -link2]

@{b}interface@{ub}
     Interface name, e.g. "lo0" or "ppp0"

@{b}alias/-alias@{ub}
     Consider the specified address an alias for the existing address,
     i.e. do not overwrite an existing address.

@{b}af@{ub}
     Address family: only "inet" is supported at this time.

@{b}address@{ub}
     A protocol-level address. For the address family "inet" this is an
     IP address in dot-notation (e.g. 123.45.67.89).

@{b}dest_addr@{ub}
     The protocol-level destination address. This is only used for
     point-to-point devices.

@{b}up/down@{ub}
     Mark the interface as up or down.

@{b}netmask@{ub}
     Change the netmask for this interface.

@{b}metric@{ub}
     Change the metric (priority) for this interface.

@{b}arp/-arp@{ub}
     Enable/disable Arp for this interface. This option should not be
     used with MiamiDx. Use the MiamiDx GUI instead to choose the type
     of address resolution.

@{b}broadcast@{ub}
     Set the broadcast address for this interface.

@{b}linkx/-linkx@{ub}
     Set or reset link-level flags 0, 1 or 2. These flags are not
     currently used by MiamiDx.


@EndNode

@Node "NODE_UTILITY_MIAMIINIT" "MiamiDx.guide/NODE_UTILITY_MIAMIINIT"
@Next "NODE_UTILITY_IPFW"
@Prev "NODE_UTILITY_IFCONFIG"
@Toc "NODE_UTILITY"

MiamiInit
=========

   MiamiInit allows you to interactively configure your Internet
connection.  It is most useful in combiation with PPP or SLIP modem
links, most types of ISDN connections, and with DSL or cable modem
connections which uses static IP addresses or DHCP.

   MiamiInit supports other types of connections as well, but most other
types are easier to configure manually, directly in MiamiDx. That
includes LAN connections, null-modem connections, DSL or cable
connections which use PPTP, L2TP or PPPoE, and other connections with
"unusual" hardware, e.g. floppy-port-based networks. Those connections
should be configured directly in MiamiDx, without using MiamiInit.  See
@{"Typical Configuration" Link "NODE_TYPICAL"}.

   MiamiInit is for the most part self-explanatory. It displays
extensive help information on each dialog page. Please read that
information carefully before clicking on "Continue" to go to the next
page.


@EndNode

@Node "NODE_UTILITY_IPFW" "MiamiDx.guide/NODE_UTILITY_IPFW"
@Next "NODE_UTILITY_IPNATD"
@Prev "NODE_UTILITY_MIAMIINIT"
@Toc "NODE_UTILITY"

MiamiIPFW
=========

   Firewall configuration utility. MiamiIPFW allows you to list and
change the firewall rules MiamiDx uses. Most firewall users will
probably use the "auto" setting in
@{"TCP/IP LAN-Connect Firewall configuration" Link "NODE_CONFIG_OTHER_LANCONNECT_FIREWALL"}.  In that case MiamiIPFW
should only be used with the "list" options to inspect firewall rules,
but you should not change the rules, because MiamiDx creates them
automatically from the current interface definitions and updates them
whenever interface definitions or states change. If you have set the
firewall setting to "manual" then you need to use MiamiIPFW to define
your own firewall rules.

   Usage:

@{b}MiamiIPFW [options] flush@{ub}
     Deletes all firewall rules

@{b}MiamiIPFW [options] add [number] rule@{ub}
     Adds a rule at the indicated position. The format of "rule" is
     described below.

@{b}MiamiIPFW [options] delete number@{ub}
     Deletes a rule.

@{b}MiamiIPFW [options] list [number ...]@{ub}
     Displays the indicated firewall rules.

@{b}MiamiIPFW [options] show [number ...]@{ub}
     Equivalent to "MiamiIPFW -a list".

@{b}MiamiIPFW [options] zero [number ...]@{ub}
     Zeroes counters of indicated rules.

   Valid options are:

@{b}-a@{ub}
     Show counter values when listing rules.

@{b}-f@{ub}
     Don't ask for confirmation for commands that can cause problems if
     misused (e.g. flush).

@{b}-q@{ub}
     While adding or flushing be quiet about actions (implies "-q").

@{b}-t@{ub}
     While listing, show last match timestamp.

@{b}-N@{ub}
     Try to resolve addresses and service names in output.

   Rules have the following format:

     action proto src dst extras

   "action" can be one of:

@{b}"allow", "pass", "permit", "accept"@{ub}
     Accept the packet and end processing.

@{b}"deny", "drop"@{ub}
     Discard the packet.

@{b}"reject"@{ub}
     Discard the packet and send an ICMP host unreachable notice.

@{b}"unreach" code@{ub}
     Same as "reject", but "code" defines the code used in the ICMP
     unreachable notice. It can be a number from zero to 255 or one of
     these aliases: "net", "host", "protocol", "port", "needfrag",
     "srcfail", "net-unknown", "host-unknown", "isolated",
     "net-prohib", "host-prohib", "tosnet", "toshost", "filter-prohib",
     "host-precedence", "precedence-cutoff".

@{b}"reset"@{ub}
     For TCP packets only: discard the packet and try to send a TCP
     reset (RST) notice.

@{b}"count"@{ub}
     Update counters for all packets that match the rule. The search
     continues with the next rule.

@{b}"divert" port@{ub}
     Divert packets to a divert socket bound to the specified port. This
     is typically used for IP-NAT.

@{b}"tee" port@{ub}
     Like divert, but only send a copy of the packet to the divert
     socket and continue processing at the next rule with the original
     packet.

@{b}"skipto" number@{ub}
     Skips all subsequent rules numbered less than the specified number.

   "proto" can be "ip", "tcp", "udp", "icmp", any IP protocol number,
or a IP protocol name listed in @{"Protocol database" Link "NODE_CONFIG_DATABASE_PROTOCOLS"}.

   "src" and "dst" are in the format "address/mask ports".
"address/mask" can be a simple IP address (e.g. "1.2.3.4"), an IP
address followed by the number of bits defining the network (e.g.
"1.2.3.0/24") or an IP address followed by a netmask (e.g.
"1.2.3.0:255.255.255.0"). Putting the word "not" in front of the
address inverts the sense of the match.  "ports" can be a list of port
numbers (e.g. "10") or port ranges (e.g. "10-20"), separated by commas,
e.g. "1,5-10,20". Service names listed in @{"Services database" Link "NODE_CONFIG_DATABASE_SERVICES"} may be used
instead of port numbers. Fragmented packets which have a non-zero
offset (i.e. not the first fragment) will never match a rule which has
one or more port specifications.

   "extras" can include:

@{b}"in"@{ub}
     Only match incoming packets.

@{b}"out"@{ub}
     Only match outgoing packets.

@{b}"via" interfacename@{ub}
     Only match packets going through a certain interface.

@{b}"via" ipaddress@{ub}
     Only match packets going through an interface having the indicated
     IP address.

@{b}"recv" interfacename@{ub}
     Only match packets arriving through a certain interface.

@{b}"xmit" interfacename@{ub}
     Only match packets leaving through a certain interface.

@{b}"frag"@{ub}
     Matches packets that are fragments and are not the first fragment
     of the datagram.

@{b}"ipoptions" spec@{ub}
     Matches packets having the indicated IP options, which may include
     "ssrr" (strict source route), "lsrr" (loose source route), "rr"
     (record route), "ts" (timestamp). Placing a "!" in front of the
     option inverts the match.

@{b}"established"@{ub}
     Matches TCP packets that have the RST or ACK bits set.

@{b}"setup"@{ub}
     Matches TCP packets that have the SYN bit set but no ACK bit.

@{b}"tcpflags" spec@{ub}
     Matches packets that have the indicated TCP options, which may
     include "fin", "syn", "rst", "psh", "ack" and "urg". Placing a "!"
     in front of the option inverts the match. A rule which contains a
     "tcpflags" specification can never match a fragmented packet with
     a non-zero offset.

@{b}"icmptypes" types@{ub}
     Matches ICMP packets of the indicated (numeric) type.


@EndNode

@Node "NODE_UTILITY_IPNATD" "MiamiDx.guide/NODE_UTILITY_IPNATD"
@Next "NODE_UTILITY_MAPMBONE"
@Prev "NODE_UTILITY_IPFW"
@Toc "NODE_UTILITY"

MiamiIPNatD
===========

   External version of the IP-NAT daemon. MiamiDx has a built-in IP-NAT
daemon that should be sufficient for most users. It is automatically
started when the IP-NAT setting in MiamiDx is set to "internal" (see
@{"TCP/IP LAN-Connect IP-NAT settings" Link "NODE_CONFIG_OTHER_LANCONNECT_IPNAT"}.  If you don't want to use the
internal IP-NAT daemon, but this external one, which provides a few
additional features, then set the IP-NAT settings in MiamiDx to
"external" and also set the Firewall settings (see
@{"TCP/IP LAN-Connect Firewall settings" Link "NODE_CONFIG_OTHER_LANCONNECT_FIREWALL"} to "manual". You then need to
start MiamiIPNatD from the Shell and also set your firewall rules
manually, to redirect packets to the IP-NAT daemon. See @{"MiamiIPFW" Link "NODE_UTILITY_IPFW"}.

   Usage: MiamiIPNatD [options]

   Options can include:

@{b}-u [yes|no]@{ub}
     Alias only unregistered addresses (i.e. addresses in the range
     10.x.y.z, 192.168.x.y and 172.16.x.y-172.31.x.y).

@{b}-l [yes|no]@{ub}
     Enable logging.

@{b}-d [yes|no]@{ub}
     Deny incoming connections.

@{b}-s [yes|no]@{ub}
     Use sockets to inhibit port conflicts

@{b}-m [yes|no]@{ub}
     Try to keep original port numbers for connections.

@{b}-v [yes|no]@{ub}
     Verbose mode.

@{b}-i number|servicename@{ub}
     Set port for incoming packets.

@{b}-o number|servicename@{ub}
     Set port for outgoing packets.

@{b}-p number|servicename@{ub}
     Set port (defaults to natd/divert).

@{b}-a ipaddress@{ub}
     IP address to use for aliasing.

@{b}-n interfacename@{ub}
     Take aliasing address from interface.

@{b}-p tcp|udp src:port dst:port alias@{ub}
     Define permanent link for incoming connection.

@{b}-r tcp|udp localaddr:localport [publicaddr:]publicport@{ub}
     Redirect a port for incoming traffic.

@{b}-f filename@{ub}
     Read options from configuration file.


@EndNode

@Node "NODE_UTILITY_MAPMBONE" "MiamiDx.guide/NODE_UTILITY_MAPMBONE"
@Next "NODE_UTILITY_MRINFO"
@Prev "NODE_UTILITY_IPNATD"
@Toc "NODE_UTILITY"

MiamiMapMBone
=============

   Multicast connection mapper

   Usage: MiamiMapMBone [-d debug-level] [-f] [-g] [-r retry-count] [-t
timeout-count] [starting-router]

   MiamiMapMbone attempts to display all multicast routers that are
reachable from the specified multicast starting_router. If not
specified on the command line, the default multicast starting-router is
the localhost.

   The options have the following meaning:

@{b}-d debug-level@{ub}
     Sets the debug level. When the debug level is greater than the
     default value of 0, addition debugging messages are printed.

@{b}-f@{ub}
     Sets flooding option. Flooding allows the recursive search of
     neighboring multicast routers and is enable by default when
     starting_router is not used.

@{b}-g@{ub}
     Sets graphing in GraphEd format.

@{b}-n@{ub}
     Disables the DNS lookup for the multicast  routers names.

@{b}-r retry-count@{ub}
     Sets the neighbor query retry limit. Default is 1 retry.

@{b}-t timeout-count@{ub}
     Sets the number of seconds to wait for a neighbor query reply
     before retrying. Default timeout is 2 seconds.


@EndNode

@Node "NODE_UTILITY_MRINFO" "MiamiDx.guide/NODE_UTILITY_MRINFO"
@Next "NODE_UTILITY_MROUTED"
@Prev "NODE_UTILITY_MAPMBONE"
@Toc "NODE_UTILITY"

MiamiMRInfo
===========

   Displays configuration info from a multicast router.

   Usage: MiamiMRInfo [-d debug_level] [-r retry_count] [-t
timeout_count] [multicast_router]

   MiamiMRInfo attempts to display the configuration information from
the specified multicast router. If no router is specified then
localhost is used.

   The options have the following meaning:

@{b}-d debug_level@{ub}
     Sets the debug level. When the debug level is greater than the
     default value of 0, addition debugging messages are printed.

@{b}-r retry_count@{ub}
     Sets the neighbor query retry limit. Default is 3 retries.

@{b}-t timeout_count@{ub}
     Sets the number of seconds to wait for a neighbor query reply
     before retrying. Default timeout is 4 seconds.


@EndNode

@Node "NODE_UTILITY_MROUTED" "MiamiDx.guide/NODE_UTILITY_MROUTED"
@Next "NODE_UTILITY_MTRACE"
@Prev "NODE_UTILITY_MRINFO"
@Toc "NODE_UTILITY"

MiamiMRouteD
============

   IP Multicast Routing Daemon

   Usage: MiamiMRouteD [-p] [-c config_file] [-d debug_level]

   MiamiMRouteD is a program you might have to run in the background
("run MiamiMRouteD") to receive or forward multicast feeds. Please see
below for a more detailed explanation.

   The options have the following meaning:

@{b}-p@{ub}
     Start MiamiMRouteD in non-pruning mode. This option should only be
     used for testing.

@{b}-c config_file@{ub}
     Specify which config file to use. The default file name of the
     configuration file is "Miami:MiamiMRouteD.config".

@{b}-d debug_level@{ub}
     Specify the debug level. The default is 0 (no debug info).

   MiamiMRouteD is a very complex and powerful program that allows you
to receive and forward multicast feeds. It is configured through a
separate configuration file, the format of which is partially described
below.

   The two most common configurations are:

   @{b}*@{ub} You are receiving your multicast feed direcly from a broadcast- or
     multicast-capable interface such as Ethernet or Arcnet. In this
     case @{i}DO NOT@{ui} run MiamiMRouteD, unless you have multiple interfaces
     configured and want MiamiMRouteD to forward traffic between
     interfaces. If you only have a single interface configured then
     @{i}enable@{ui} multicasting in MiamiDx, on the "Interface" page, and don't
     run MiamiMRouteD.

   @{b}*@{ub} You are receiving your multicast feed through an IP tunnel,
     possibly via PPP from your provider. In this case @{i}disable@{ui}
     multicasting in MiamiDx for your PPP/SLIP interface, configure
     MiamiMRouteD for a tunnel to your provider (see below), and run
     MiamiMRouteD after starting MiamiDx.

   The configuration file for MiamiMRouteD is a standard ASCII text
file. Each line can contain one command. The following commands are
supported

   @{b}*@{ub} Create a tunnel
          tunnel <local-addr> <remote-addr>

     For <local-addr> you can specify an IP address or an interface
     name (e.g. "ppp0"). <remote-addr> is the IP address of the host on
     the other side of the multicast tunnel, e.g.

          tunnel ppp0 1.2.3.4

     establishes a multicast tunnel to the host 1.2.3.4.

   @{b}*@{ub} Define a physical interface for Multicast routing
          phyint <local-addr> [disable]

     Multicast routing is enabled to all interfaces by default, and
     this command can be used to disable it.

   All "phyint" commands must precede all "tunnel" commands in the
configuration file.


@EndNode

@Node "NODE_UTILITY_MTRACE" "MiamiDx.guide/NODE_UTILITY_MTRACE"
@Next "NODE_UTILITY_NETSTAT"
@Prev "NODE_UTILITY_MROUTED"
@Toc "NODE_UTILITY"

MiamiMTrace
===========

   Print multicast path from a source to a receiver

   Usage: MiamiMTrace [-g gateway] [-i if_addr] [-l] [-M] [-m max_hops]
[-n] [-p] [-q nqueries] [-r resp_dest] [-s] [-S stat_int] [-t ttl] [-v]
[-w waittime] source [receiver] [group]

   MiamiMTrace is a utility very similar to MiamiTraceRoute, but for
multicast addresses, not unicast addresses. Please see @{"MiamiTraceRoute" Link "NODE_UTILITY_TRACEROUTE"}
for more information on TraceRoute. "group" specifies the multicast IP
address to use.  "source" and "receiver" are unicast IP address
specifiying the start and end point in the multicast path to trace. If
"group" is not specified then 224.2.0.1 is used. If "receiver" is not
specified then localhost is assumed.

   The options have the following meaning:

@{b}-g gateway@{ub}
     Send the trace query via unicast directly to the specified
     multicast router rather than multicasting the query.  This must be
     the last-hop router on the path from the intended source to the
     receiver.

@{b}-i if_addr@{ub}
     Use the specified address as the local interface address (on a
     multi-homed host) for sending the trace query and as the default
     for the receiver and the response destination.

@{b}-l@{ub}
     Loop indefinitely printing packet rate and loss statistics for the
     multicast path every 10 seconds (also see `-S stat_int').

@{b}-M@{ub}
     Always send the response using multicast rather than attempting
     unicast first.

@{b}-m max_hops@{ub}
     Set the maximum number of hops that will be traced from the
     receiver back toward the source.  The default is 32 hops (infinity
     for the DVMRP routing protocol).

@{b}-n@{ub}
     Print hop addresses numerically rather than symbolically and
     numerically (saves a nameserver address-to-name lookup for each
     router found on the path).

@{b}-q nqueries@{ub}
     Set the maximum number of query attempts for any hop.  The default
     is 3.

@{b}-p@{ub}
     Listen passively for multicast responses from traces initiated by
     others.  This works best when run on a multicast router.

@{b}-r resp_dest@{ub}
     Send the trace response to the specified host rather than to the
     host on which MiamiMTrace is being run, or to a multicast address
     other than the one registered for this purpose (224.0.1.32).

@{b}-s@{ub}
     Print a short form output including only the multicast path and not
     the packet rate and loss statistics.

@{b}-S stat_int@{ub}
     Change the interval between statistics gathering traces to the
     specified number of seconds (default 10 seconds).

@{b}-t ttl@{ub}
     Set the ttl (time-to-live, or number of hops) for multicast trace
     queries and responses.  The default is 64, except for local
     queries to the "all routers" multicast group which use ttl 1.

@{b}-v@{ub}
     Verbose mode; show hop times on the initial trace and statistics
     display.

@{b}-w waittime@{ub}
     Set the time to wait for a trace response to the specified number
     of seconds.


@EndNode

@Node "NODE_UTILITY_NETSTAT" "MiamiDx.guide/NODE_UTILITY_NETSTAT"
@Next "NODE_UTILITY_NSLOOKUP"
@Prev "NODE_UTILITY_MTRACE"
@Toc "NODE_UTILITY"

MiamiNetStat
============

   MiamiNetStat is a tool to display configuration parameters and
statistics.  It is almost identical in functionality to the version of
"netstat" that is included with 4.4BSD, but has some additional
functions to display link-level statistics.

   @{b}*@{ub} MiamiNetStat [-AaDnNOQ] [-f address_family]

   @{b}*@{ub} MiamiNetStat [-dimnNrs] [-f address_family]

   @{b}*@{ub} MiamiNetStat [-dnN] [-] [-I interface]

   @{b}*@{ub} MiamiNetStat [-s] [-] [-L interface]

   @{b}*@{ub} MiamiNetStat [-s] [-g]

   @{b}*@{ub} MiamiNetStat [-p protocol]

   The MiamiNetStat command symbolically displays the contents of
various network-related data structures. There are a number of output
formats, depending on the options for the information presented.

   The first form of the command displays a list of active sockets for
each protocol.

   The second form presents the contents of one of the other network
data structures according to the option selected.

   Using the third form MiamiNetStat will display information regarding
packet traffic on the specified network interface.

   The fourth form displays link-level configuration information or
(with the "-s" flag) link-level statistics for the specified network
interface.

   The fifth form displays information about virtual interfaces (for
multicasting) and multicast routing statistics.

   The sixth form displays statistics about the named protocol.

   The options have the following meaning:

@{b}-A@{ub}
     With the default display, show the address of any protocol control
     blocks associated with sockets; used for debugging.

@{b}-a@{ub}
     With the default display, show the state of all sockets; normally
     sockets used by server processes are not shown.

@{b}-d@{ub}
     With an interface display (option i or I), show the number of
     dropped packets.

@{b}-D@{ub}
     With the default display, show the total number of transfered bytes
     for each active TCP connection.

@{b}-f address_family@{ub}
     Limit statistics or address control block reports to those of the
     specified address family. Only the address families "inet" and
     "local"/"unix" are currently recongized.

@{b}-g@{ub}
     Display the virtual interface table and multicast routing table.
     Together with the option `-s' this option displays multicast
     routing statistics. Both of these options are only meaningful when
     MiamiMRouteD is running.

@{b}-I interface@{ub}
     Show information about the specified interface.

@{b}-i@{ub}
     Show the state of interfaces which have been configured.

@{b}-m@{ub}
     Show statistics recorded by the memory management routines (the
     network manages a private pool of memory buffers).

@{b}-n@{ub}
     Show network addresses as numbers (normally MiamiNetstat interprets
     addresses and attempts to display them symbolically).  This option
     may be used with any of the display formats.

@{b}-N@{ub}
     Only show a network address symbolically if the symbolic name is
     available without a prior DNS lookup. Otherwise show the network
     address as a number. This option may be used with any of the
     display formats.

@{b}-O@{ub}
     Display the owner (task name) of each socket.

@{b}-p protocol@{ub}
     Show statistics about the specified protocol, which is either a
     well-known name for a protocol or an alias for it. A null response
     typically means that there are no interesting numbers to report.
     The program will complain if the protocol is unknown or if there
     is no statistics routine for it.

@{b}-Q@{ub}
     Display virtual connection mappings established by the IP-NAT
     engine.

@{b}-r@{ub}
     Show the routing tables. When "-s" is also present, show routing
     statistics instead.

@{b}-s@{ub}
     Show per-protocol statistics. If this option is repeated, counters
     with a value of zero are suppressed.

   The default display, for active Internet sockets, shows the local
and remote addresses, send and receive queue sizes (in bytes),
protocol, and the internal state of the protocol. Address formats are
of the form "host.port" or "network.port" if a socket's address
specifies a network but no specific host address. When known the host
and network addresses are displayed symbolically according to the
"hosts" and "networks" databases. If a symbolic name for an address is
unknown, or if the "-n" option is specified, the address is printed
numerically, according to the address family.

   For active Domain sockets ("unix"/"local" sockets) the output shows
the internal socket address, the socket type ("stream"/"dgram"), the
send and receive queue sizes (in bytes), the address of the socket the
current socket is connected to (for connected sockets), two references,
which for datagram sockets form a linked list of connected sockets, and
the logical name a socket is bound to.

   The interface display provides a table of cumulative statistics
regarding packets transferred, errors, and collisions. The network
addresses of the interface and the maximum transmission unit ("mtu")
are also displayed.

   The routing table display indicates the available routes and their
status.  Each route consists of a destination host or network and a
gateway to use in forwarding packets.  The flags field shows a
collection of information about the route stored as binary choices.

@{b}1@{ub}
     RTF_PROTO1 Protocol specific routing flag #1 (currently unused).

@{b}2@{ub}
     RTF_PROTO2 Protocol specific routing flag #2 (used by Arp to
     indicate that an Arp entry is "published").

@{b}3@{ub}
     RTF_PROTO3 Protocol specific routing flag #3 (meaning for TCP:
     route is timing out).

@{b}C@{ub}
     RTF_CLONING Generate new routes on use.

@{b}D@{ub}
     RTF_DYNAMIC Created dynamically (by redirect).

@{b}G@{ub}
     RTF_GATEWAY Destination requires forwarding by intermediary.

@{b}H@{ub}
     RTF_HOST Host entry (net otherwise).

@{b}L@{ub}
     RTF_LLINFO Valid protocol to link address translation.

@{b}M@{ub}
     RTF_MODIFIED Modified dynamically (by redirect).

@{b}P@{ub}
     RTF_PRCLONING Clone routes for use by protocols.

@{b}R@{ub}
     RTF_REJECT Host or net unreachable.

@{b}S@{ub}
     RTF_STATIC Manually added.

@{b}U@{ub}
     RTF_UP Route usable.

@{b}W@{ub}
     RTF_WASCLONED Route was created by cloning another route.

@{b}X@{ub}
     RTF_XRESOLVE External daemon translates proto to link address.

   Direct routes are created for each interface attached to the local
host; the gateway field for such entries shows the address of the
outgoing interface. The refcnt field gives the current number of active
uses of the route. Connection oriented protocols normally hold on to a
single route for the duration of a connection while connectionless
protocols obtain a route while sending to the same destination. The use
field provides a count of the number of packets sent using that route.
The interface entry indicates the network interface utilized for the
route.

   With the option "-L" MiamiNetStat displays link-level configuration
information, such as the current state of the IPCP or LCP subprotocols
of PPP, for the specified interface.

   With the option combination "-sL" MiamiNetstat displays link-level
statistics, including information about different types of packets, and
checksum errors, for the specified interface.

   Currently MiamiDx supports the following interfaces ("x" indicating
a number starting at zero):

@{b}lo0@{ub}
     The local loopback interface

@{b}pppx@{ub}
     A PPP dial-out interface

@{b}slx@{ub}
     A SLIP dial-out interface

@{b}ethx@{ub}
     An Ethernet interface

@{b}arcx@{ub}
     An Arcnet interface

@{b}busx@{ub}
     A SANA-II or MNI bus interface other than Ethernet or Arcnet

@{b}ptpx@{ub}
     A SANA-II point-to-point interface


@EndNode

@Node "NODE_UTILITY_NSLOOKUP" "MiamiDx.guide/NODE_UTILITY_NSLOOKUP"
@Next "NODE_UTILITY_PING"
@Prev "NODE_UTILITY_NETSTAT"
@Toc "NODE_UTILITY"

MiamiNSLookup
=============

   Perform DNS queries.

   MiamiNSLookup has two modes: interactive and non-interactive.
Interactive mode allows the user to query name servers for information
about various hosts and domains or to print a list of hosts is a
domain. Non-interactive mode is used to print just the name and
requested information for a host or domain.

   Interactive mode is entered when no arguments are given or when the
first argument is a hyphen (-) and the second argument is the host name
or IP address of a name server.

   Non-interactive mode is used when the name or IP address of the host
to be looked up is given as the first argument. The optional second
argument specifies the host name or address of a name server.

   The options listed under the "set" command below can be specified in
the startup file "Miami:data/.nslookuprc" if they are listed one per
line.  Options can also be specified on the command line if the precede
the arguments and are prefixed with a hypen. For example to change the
default query type to host information and the initial timeout to 10
seconds type "MiamiNSLookup -query=hinfo -timeout=10".

   The following interactive commands are supported. Commands may be
interrupted ay any time by typing a Control-C. To exit type Control-\\
or type "exit". The command line length must be less than 256
charaters. To treat a built-in command as a host name precede it with
an escape character "\\".  An unrecognized command will be interpreted
as a host name.

@{b}HOST [SERVER]@{ub}
     Look up information for HOST, using SERVER as the DNS server.  If
     HOST is an IP address and the query type is A or PTR the name of
     the host is returned. If HOST is a name and does not have a
     trailing period the default domain name is appended to the name.
     (This behavior depends on the state of the "set" options "domain",
     "srchlist", "defname" and "search"). To look up a host not in the
     current domain append a period to the name.

@{b}server DOMAIN@{ub}
     Change the default server to DOMAIN. Use the current default
     server to look up information about DOMAIN.

@{b}lserver DOMAIN@{ub}
     Change the default server to DOMAIN. Use the initial server to
     look up information about DOMAIN.

@{b}root@{ub}
     Changes the default server to the server for the root of the
     domain name space. The name of the root server can be changed with
     the "set root" command.

@{b}finger NAME [>FILE | >>FILE]@{ub}
     Connects with the finger server on the current host. The current
     host is defined when a previous lookup for a host was successful
     and returned address information. The NAME is optional. ">" and
     ">>" can be used to redirect the output to a file.

@{b}ls [OPTION] domain [>FILE | >>FILE]@{ub}
     List domain information and optionally redirect the output to a
     file. OPTION can be "-t TYPE" to list all records of the specified
     type, "-a" to list aliases of hosts in the domain (synonm for "-t
     CNAME"), "-d" to list all records for a domain (synonym for "-t
     ANY"), "-h" to list CPU and operating system information for the
     domain (synonymfor "-t HINFO") or "-s" to list well-known services
     of hosts in the domain (synonym for "-t WKS").

@{b}view FILENAME@{ub}
     Sort and list the output of previous ls commands.

@{b}help, ?@{ub}
     Show a brief summary of commands.

@{b}exit@{ub}
     Exit the program

@{b}set KEYWORD = VALUE@{ub}
     This command is used to change state information that affects the
     lookups. See below for a list of valid keywords.

   List of keywords for the "set" command:

@{b}all@{ub}
     Prints the current values of the frequently used options.

@{b}class=VALUE@{ub}
     Sets the query class to one of IN, CHAOS, HESIOD or ANY.

@{b}domain=NAME@{ub}
     Changes the default domain.

@{b}srchlist=NAME1/NAME2/...@{ub}
     Change the default domain to NAME1 and the search list to NAME1,
     NAME2, ...

@{b}[no]defname@{ub}
     If set append the default domain name to a single-component lookup
     request.

@{b}[no]search@{ub}
     If the lookup request contains at least one period but does not
     end with a trailing period, append the domain names in the domain
     search list to the request until an answer is received.

@{b}port=VALUE@{ub}
     Change the default TCP/UDP port number.

@{b}querytype=VALUE@{ub}
     Change the type of information query to one of "A", "CNAME",
     "HINFO", "MINFO", "MX", "NS", "PTR", "SOA", "TXT", "UINFO" or
     "WKS".

@{b}type=VALUE@{ub}
     Same as querytype=VALUE.

@{b}[no]recurse@{ub}
     Tell the name server to query other servers if it does not have
     the required information.

@{b}retry=NUMBER@{ub}
     Set the number of retries.

@{b}root=HOST@{ub}
     Define the root name server.

@{b}timeout=SECONDS@{ub}
     Set the query timeout.

@{b}[no]vc@{ub}
     Use TCP for lookups.

@{b}[no]ignoretc@{ub}
     Ignore packet truncation errors.


@EndNode

@Node "NODE_UTILITY_PING" "MiamiDx.guide/NODE_UTILITY_PING"
@Next "NODE_UTILITY_MIAMIREGISTER"
@Prev "NODE_UTILITY_NSLOOKUP"
@Toc "NODE_UTILITY"

MiamiPing
=========

   Send packets to network hosts and listen for their response.

   Usage: MiamiPing [-Rdfnqrv] [-c count] [-i wait] [-l preload] [-p
pattern] [-s packetsize] hostname

   Options:

@{b}-c count@{ub}
     Stop after sending and receiving <count> packets.

@{b}-d@{ub}
     Set the SO_DEBUG option on the socket being used.

@{b}-f@{ub}
     Flood ping. Outputs packets as fast as they come back, or one
     hundred times per second, whichever is more. For every ping sent a
     period "." is printed, while for every ping received a backspace
     is printed. This provides a rapid display of how many packets are
     being dropped. @{i}Note: Abusing this option for denial-of-service
     attacks is illegal.@{ui}

@{b}-i wait@{ub}
     Wait <wait> seconds between sending each packet. The default is to
     wait for one second between each packet. This option is
     incompatible with "-f".

@{b}-l preload@{ub}
     Sends <preload> packets as fast as possible before falling into
     the normal mode of behavior.

@{b}-n@{ub}
     Numeric output only.

@{b}-p pattern@{ub}
     You may specify up to 16 "pad" bytes to fill out the packet you
     send.  This is useful for diagnosing data-dependent problems in a
     network.  For example,"-p ff" will cause the sent packet to be
     filled with all ones.

@{b}-q@{ub}
     Quiet output. Nothing is displayed except the summary lines at
     startup time and when finished.

@{b}-R@{ub}
     Record route. Includes the RECORD_ROUTE option in ping packets and
     displays the route buffer on returned packets. Note that the IP
     header is only large enough for nine such routes. Many hosts
     ignore or discard this option.

@{b}-r@{ub}
     Bypass the normal routing tables and send directly to a host on an
     attached network.  If the host is not on a directly-attached
     network, an error is returned.  This option can be used to ping a
     local host through an interface that has no route through it
     (e.g., after the interface was dropped by routed).

@{b}-s packetsize@{ub}
     Specifies the number of data bytes to be sent.  The default is 56,
     which translates into 64 ICMP data bytes when combined with the 8
     bytes of ICMP header data.

@{b}-v@{ub}
     Verbose output.  ICMP packets other than ping response packets
     that are received are listed.


@EndNode

@Node "NODE_UTILITY_MIAMIREGISTER" "MiamiDx.guide/NODE_UTILITY_MIAMIREGISTER"
@Next "NODE_UTILITY_REMIND"
@Prev "NODE_UTILITY_PING"
@Toc "NODE_UTILITY"

MiamiRegister
=============

   MiamiRegister allows you to register MiamiDx, upgrade to new
versions, upgrade from Miami to MiamiDx, order files which are not
freely available over the Internet, and perform any other action that
requires communication with the MiamiDx registration server.

   MiamiRegister is for the most part self-explanatory. It displays
extensive help information on each dialog page. Please read that
information carefully before clicking on "Continue" to go to the next
page.


@EndNode

@Node "NODE_UTILITY_REMIND" "MiamiDx.guide/NODE_UTILITY_REMIND"
@Next "NODE_UTILITY_RESOLVE"
@Prev "NODE_UTILITY_MIAMIREGISTER"
@Toc "NODE_UTILITY"

MiamiRemind
===========

   Some users consider the automatic warning and disconnect after 30/60
minutes in the MiamiDx demo version a useful feature, to save
telephone/ISP costs. That is why MiamiDx also offers the same
functionality as a feature, if you set `Behavior' to `disconnect after
inactivity in @{"Interfaces Auto-connect/disconnect" Link "NODE_CONFIG_OTHER_IFACEAUTO"}.

   However that function does not provide much control over what kind
of traffic is considered to be "activity". MiamiRemind is a tool that
introduces the same functionality, but with more control over the type
of traffic and the resulting action. It offers the following features:

   @{b}*@{ub} The interface, the number of warnings, and the interval between
     subsequent warnings can be freely configured.

   @{b}*@{ub} It is possible to disconnect after a certain amount of time, to
     only display a finite number of warnings (without disconnecting)
     or to keep displaying warnings at regular intervals.

   @{b}*@{ub} In addition to fixed time intervals it is possible to show
     warnings after a certain amount of *inactivity* on the link. Both
     types of warnings (warnings after fixed amounts of time and
     warnings after inactivity) can be enabled at the same time.

   @{b}*@{ub} Using the inactivity timer directly with the "disconnect" option
     provides the functionality of a "disconnect on inactivity" option,
     something many users have requested for Miami in the past.

   The term "inactivity" is difficult to define for a TCP/IP
connection. The default definition used by MiamiRemind is "lack of TCP
traffic". With this definition MiamiRemind requires extremely little
overhead and memory.

   For users who need more sophisticated definitions of "inactivity",
MiamiRemind provides an expression parser and compiler identical to the
one in MiamiTCPDump, i.e.  you can e.g. use expressions like

   "(tcp[13] & 3 != 0) or udp"

   The above expression would consider all TCP SYN packets, all TCP FIN
packets, and all UDP packets "activity".  All other packets are not
considered.

   The expression parser/compiler requires miamibpf.library and
miamipcap.library, and thus introduces slightly higher memory and cpu
overhead than the hardcoded "TCP traffic" definition.

     Usage: MiamiRemind [-I interface]
                        [-f fixed_timer_spec]
                        [-i inactivity_timer_spec]
                        [-p pcap_spec]

   Option "-I" defines the interface to be watched, e.g.  "ppp0".

   Option "-f" defines the parameters for the fixed timer, i.e.  the
timer that starts when MiamiRemind is started, without considering
activity on the link. The default is to disable the fixed timer.

   Option "-i" defines the parameters for the inactivity timer.  This
timer is reset to zero whenever a packet is transmitted or received
that is considered "activity" on the link. The default is to disable
the inactivity timer.

   Option "-p" defines the inactivity expression, in MiamiPCap format
(see the example above). The expression should be enclosed in double
quotes ("). If this parameter is specified then MiamiRemind uses
miamipcap.library and miamibpf.library to parse, compile and evaluate
the expression. Otherwise the hardcoded definition "TCP traffic" is
used, and both libraries are not needed.

   "timer_spec" (for options "-f" and "-i") is a string that consists
of numbers representing time intervals (measured in minutes), separated
by commas (",").

   Each time interval in the string represents the delay between
subsequent events.

   "event" usually refers to a warning requester. However it is also
possible to prefix numbers with the letter "D", to indicate that
MiamiRemind should disconnect the line at the next event, or with the
letter "L", to indicate that MiamiRemind should loop, i.e. use the next
time interval repeatedly, to define a sequence of events.

   Examples:

@{b}MiamiRemind -I ppp0 -f 30,D30@{ub}
     This is identical in behavior to the behavior of PPP interfaces in
     the demo version of MiamiDx, i.e. show a warning after 30 minutes,
     and disconnect after another thirty minutes.

@{b}MiamiRemind -I ppp0 -f 30,20,L10@{ub}
     Display a warning after 30 minutes, then again after 20 minutes,
     and from then on every 10 minutes (loop). Never disconnect the
     line.

@{b}MiamiRemind -I ppp0 -f 60,60 -i L10@{ub}
     Display a warning after 60 minutes and another one after another
     60 minutes. After that disable the fixed timer.  Also show a
     warning whenever there have been multiples of 10 minutes of
     inactivity (lack of TCP traffic) on the link.

@{b}MiamiRemind -I ppp0 -i D30@{ub}
     Disconnect the link after 30 minutes of inactivity (lack of TCP
     traffic).

@{b}MiamiRemind -I ppp0 -i D20 -p "tcp or udp"@{ub}
     Disconnect the link after 20 minutes of inactivity.  "inactivity"
     refers to TCP or UDP traffic.

   MiamiRemind automatically quits when the interface goes offline
(regardless of the reason), when MiamiDx tries to quit, when the
program receives a Ctrl-C signal, or when both timers are disabled.

   The easiest way to use MiamiRemind is to start it directly from
MiamiDx whenever MiamiDx goes online with the corresponding interface,
i.e. as "run >nil: Miami:MiamiRemind [options]" in a Shell script
launched from MiamiDx (configured in the Events->Online section of the
corresponding interface).


@EndNode

@Node "NODE_UTILITY_RESOLVE" "MiamiDx.guide/NODE_UTILITY_RESOLVE"
@Next "NODE_UTILITY_ROUTE"
@Prev "NODE_UTILITY_REMIND"
@Toc "NODE_UTILITY"

MiamiResolve
============

   Resolve a host name to an IP address or an IP address to a host name.

   Usage:

@{b}MiamiResolve ip_address@{ub}
     Resolve the ip address, and display the associated host name and
     all ip addresses.

@{b}MiamiResolve host_name@{ub}
     Resolve the host name, and display the associated host name and
     all ip addresses.

@{b}MiamiResolve -s port_number@{ub}
     Resolve the port number, and display all associated service names
     and the port number.

@{b}MiamiResolve -s service_name@{ub}
     Resolve the service name, and display all associated service names
     and the port number.


@EndNode

@Node "NODE_UTILITY_ROUTE" "MiamiDx.guide/NODE_UTILITY_ROUTE"
@Next "NODE_UTILITY_SECURESHELLKEYGEN"
@Prev "NODE_UTILITY_RESOLVE"
@Toc "NODE_UTILITY"

MiamiRoute
==========

   Manually manipulate the routing tables.

   Usage: MiamiRoute [-nqv] command modifiers args

   Options:

@{b}-n@{ub}
     Bypasses attempts to print host and network names symbolically
     when reporting actions.  (The process of translating between
     symbolic names and numerical equivalents can be quite time
     consuming, and may require correct operation of the network; thus
     it may be expedient to forgo this, especially when attempting to
     repair networking operations),

@{b}-q@{ub}
     Suppress all output.

@{b}-v@{ub}
     (verbose) Print additional details.

   Commands:

@{b}add@{ub}
     Add a route

@{b}flush@{ub}
     Remove all routes. Be @{i}very@{ui} careful when using this command.  It
     also removes some of MiamiDx's standard routes. Unless you repair
     this manually afterwards you will have to restart MiamiDx to resume
     normal operation.

@{b}delete@{ub}
     Delete a specific route

@{b}change@{ub}
     Change aspects of a route (such as its gateway).

@{b}get@{ub}
     Lookup and display the route for a destination.

@{b}monitor@{ub}
     Continuously report any changes to the routing information base,
     routing lookup misses, or suspected network partitionings. Note:
     without an implementation of "routed" this command is not very
     useful.

   The MiamiRoute command is usually not needed with an integrated
protocol stack like MiamiDx, and very complex and difficult to use.  If
you want to add manual routes then please enter them in
@{"Interfaces Manual routes/aliases" Link "NODE_CONFIG_OTHER_IFACEROUTES"} for the corresponding interface.  For
a complete discussion of routing or the MiamiRoute command please see
the BSD docs for the "route" command.

   About the only useful application of the "MiamiRoute" command at the
moment is to @{i}examine@{ui} routes to hosts, e.g. to find out about round trip
times or path MTU values. To do this use the syntax:

   MiamiRoute get hostname

   To examine the complete routing table use the command "MiamiNetStat
-r", not MiamiRoute.


@EndNode

@Node "NODE_UTILITY_SECURESHELLKEYGEN" "MiamiDx.guide/NODE_UTILITY_SECURESHELLKEYGEN"
@Next "NODE_UTILITY_SECURESHELLKILL"
@Prev "NODE_UTILITY_ROUTE"
@Toc "NODE_UTILITY"

MiamiSecureShellKeyGen
======================

   Create an RSA private/public key pair for use with SecureShell, or
change options of an existing key.

   Usage: MiamiSecureShellKeyGen [-b bits] [-c] [-f file] [-p] [-u] [-C
comment] [-N newpass] [-P pass]

   Options:

@{b}-b bits@{ub}
     Set the key size. The default is 1024. You can reduce it to 512 or
     384 on slow Amigas, but with less security. You should not
     increase it beyond 1024, because values higher than 1024 are for
     legal reasons currently incompatible with the US version of
     MiamiSSL.

@{b}-c@{ub}
     Change the comment.

@{b}-f file@{ub}
     Set the file name of the identity file.

@{b}-p@{ub}
     Change the passphrase

@{b}-u@{ub}
     Update ciphers. This option is used if you want to upgrade your
     keyfile from very early alpha versions of MiamiSecureShell which
     used weaker ciphers than the current version.

@{b}-C comment@{ub}
     Set the new comment.

@{b}-N passphrase@{ub}
     Set the new passphrase

@{b}-P passphrase@{ub}
     Specify the current passphrase

   It is usually sufficient to just start MiamiSecureShellKeyGen without
any options to create a private/public key pair. If you do not enter a
passphrase then your key will not be passphrase-protected. That may be
more convenient when logging in in SecureShell mode (you are not
prompted for a passphrase every time), but it also means that anyone
who gets access to your private key can use it to log into your
accounts.

   By default your private key is stored in
"Miami:SecureShell/Identity", and your public key is stored in
"Miami:SecureShell/Identity.pub".  The private key is in binary format.
The public key is a single line of ASCII text. In order to use your RSA
key to log in to a SecureShell account without a password check you
need to upload the public key to the server you want to connect to, and
append the single line of text in that file to the server's list of
authorized keys for your account. Usually the name of that file is
"~/.ssh/authorized_keys".  Please see the documentation of your SSH
server for more details.


@EndNode

@Node "NODE_UTILITY_SECURESHELLKILL" "MiamiDx.guide/NODE_UTILITY_SECURESHELLKILL"
@Next "NODE_UTILITY_SYSCTL"
@Prev "NODE_UTILITY_SECURESHELLKEYGEN"
@Toc "NODE_UTILITY"

MiamiSecureShellKill
====================

   Display active SecureShell connections and/or terminate them.

   Usage:

@{b}MiamiSecureShellKill@{ub}
     Display all hosts to which SecureShell connections have been
     established.

@{b}MiamiSecureShellKill hostname@{ub}
     Terminate the SecureShell connection to the indicated host.

   As long as you use SecureShell only to establish secure login
sessions with @{"MiamiTelnet" Link "NODE_UTILITY_TELNET"} you do not need this utility, because you can
always close your SecureShell connection by closing MiamiTelnet.
However if you use the port forwarding or X11 forwarding features of
MiamiSecureShell then it is possible that a SecureShell connection
remains established after you close MiamiTelnet, because a forwarded
connection still exists at the time you close MiamiTelnet. In that case
the only way to close the SecureShell main connection is to use
MiamiSecureShellKill.


@EndNode

@Node "NODE_UTILITY_SYSCTL" "MiamiDx.guide/NODE_UTILITY_SYSCTL"
@Next "NODE_UTILITY_TCPDUMP"
@Prev "NODE_UTILITY_SECURESHELLKILL"
@Toc "NODE_UTILITY"

MiamiSysCtl
===========

   MiamiSysCtl lets you examine and change some of MiamiDx's internal
variables. The use of MiamiSysCtl is deprecated, and the program is
only provided for compatibility with Miami installations. Users of
MiamiDx should make sysctl changes in the user interface instead, in
@{"SysCtl database" Link "NODE_CONFIG_DATABASE_SYSCTL"}.


@EndNode

@Node "NODE_UTILITY_TCPDUMP" "MiamiDx.guide/NODE_UTILITY_TCPDUMP"
@Next "NODE_UTILITY_TELNET"
@Prev "NODE_UTILITY_SYSCTL"
@Toc "NODE_UTILITY"

MiamiTCPDump
============

   MiamiTCPDump allows you to dump traffic on a network after filtering
it.

   Usage: MiamiTCPDump [-adflMnNOqStvx] [-c count] [-F file] [-i
interface] [-r file] [-s snaplen] [-T type] [-w file] [expression]

   Options:

@{b}-A@{ub}
     Used in combination with `-x': prints packets in ASCII in addition
     to a hex dump.

@{b}-a@{ub}
     Attempt to convert network and broadcast addresses to names.

@{b}-c count@{ub}
     Exit after receiving <count> packets.

@{b}-d@{ub}
     Dump the compiled packet-matching code in a human-readable form to
     standard output and stop.

@{b}-dd@{ub}
     Dump the compiled packet-matching code as a program fragment.

@{b}-ddd@{ub}
     Dump the compiled packet-matching code as decimal numbers
     (preceded with a count).

@{b}-f@{ub}
     Print "foreign" internet addresses numerically rather than
     symbolically.

@{b}-F file@{ub}
     Use <file> as input for the filter expression. An additional
     expression given on the command line is ignored.

@{b}-i interface@{ub}
     Listen on <interface> (e.g. "lo0" or "ppp0").  If unspecified,
     MiamiTCPDump searches the system interface list for the lowest
     numbered, configured up interface (excluding loopback).  Ties are
     broken by choosing the earliest match.

@{b}-l@{ub}
     Make stdout line buffered.  Useful if you want to see the data
     while capturing it.

@{b}-M@{ub}
     Connect MiamiTCPDump directly to an MNI driver instead of going
     through the TCP/IP kernel to dump traffic. If this option is
     enabled then MiamiTCPDump can dump all packet types on the
     Ethernet, if it is disabled then MiamiTCPDump only dumps IP and
     Arp traffic. This option can only be used with interfaces that use
     MNI drivers.

@{b}-n@{ub}
     Don't convert addresses (i.e., host addresses, port numbers, etc.)
     to names.

@{b}-N@{ub}
     Don't print domain name qualification of host names.  E.g., if you
     give this flag then MiamiTCPDump will print "nic" instead of
     "nic.ddn.mil".

@{b}-O@{ub}
     Do not run the packet-matching code optimizer.  This is useful only
     if you suspect a bug in the optimizer.

@{b}-p@{ub}
     Do not use promiscuous mode. If an MNI driver is used then
     MiamiTCPDump by default sets the interface into promiscuous mode
     for as long as MiamiTCPDump is running. Using this option disables
     that feature, i.e.  it leaves the interface in its normal mode.

@{b}-q@{ub}
     Quick (quiet?) output.  Print less protocol information so output
     lines are shorter.

@{b}-s snaplen@{ub}
     Snarf <snaplen> bytes of data from each packet rather than the
     default of 68. 68 bytes is adequate for IP, ICMP, TCP and UDP but
     may truncate protocol information from name server and NFS packets
     (see below).  Packets truncated because of a limited snapshot are
     indicated in the output with "[proto]", where <proto> is the name
     of the protocol level at which the truncation has occurred.  Note
     that taking larger snapshots both increases the amount of time it
     takes to process packets and, effectively, decreases the amount of
     packet buffering.  This may cause packets to be lost.  You should
     limit <snaplen> to the smallest number that will capture the
     protocol information you're interested in.

@{b}-S@{ub}
     Print absolute, rather than relative, TCP sequence numbers.

@{b}-T type@{ub}
     Force packets selected by <expression> to be interpreted the
     specified <type>. Currently known types are
        @{b}*@{ub} rpc (Remote Procedure Call)

        @{b}*@{ub} rtp (Real-Time Applications protocol)

        @{b}*@{ub} rtcp (Real-Time Applications control protocol),

        @{b}*@{ub} vat (Visual Audio Tool),

        @{b}*@{ub} wb (distributed White Board).

@{b}-t@{ub}
     Don't print a timestamp on each dump line.

@{b}-tt@{ub}
     Print an unformatted timestamp on each dump line.

@{b}-v@{ub}
     (Slightly more) verbose output.  For example, the time to live and
     type of service information in an IP packet is printed.

@{b}-vv@{ub}
     Even more verbose output.  For example, additional fields are
     printed from NFS reply packets.

@{b}-w file@{ub}
     Write the raw packets to <file> rather than parsing and printing
     them out.  They can later be printed with the "-r" option.
     Standard output is used if <file> is "-".

@{b}-x@{ub}
     Print each packet (minus its link level header) in hex.  The
     smaller of the entire packet or <snaplen> bytes will be printed.

   <expression> selects which packets will be dumped.  If no
<expression> is given, all packets on the net will be dumped.
Otherwise, only packets for which <expression> is `true' will be dumped.

   The syntax for <expression> is extremely comprehensive and beyond
the scope of this documenation. For a complete description of the
syntax and of the details of the output format please have a look at
the documentation for the freely distributable BSD version of
"tcpdump". Here are some examples for valid expressions:

@{b}"host sundown"@{ub}
     To print all packets arriving at or departing from "sundown".

@{b}"host helios and ( hot or ace )"@{ub}
     To print traffic between "helios" and either "hot" or "ace".

@{b}"ip host ace and not helios"@{ub}
     To print all IP packets between "ace" and any host except "helios".

@{b}"tcp[13] & 3 != 0"@{ub}
     To print the start and end packets (SYN and FIN) of each TCP
     conversation.

@{b}"icmp[0] != 8 and icmp[0]!= 0"@{ub}
     To print all ICMP packets that are not echo requests/replies
     (i.e., not ping packets).


@EndNode

@Node "NODE_UTILITY_TELNET" "MiamiDx.guide/NODE_UTILITY_TELNET"
@Next "NODE_UTILITY_TELNETD"
@Prev "NODE_UTILITY_TCPDUMP"
@Toc "NODE_UTILITY"

MiamiTelnet
===========

   Very comprehensive telnet/rlogin/SecureShell client with lots of
features. Please see @{"MiamiTelnet features" Link "NODE_UTILITY_TELNET_FEATURES"} for a complete list of all
features.

   Usage: MiamiTelnet [-a|-v] [-d|-e|-h|-l|-r||-t|-z] [-3] [-s service]
[-u username] profile/host [service]

   Options are:

@{b}-3@{ub}
     Request TN3270 mode.

@{b}-a@{ub}
     Choose ANSI color emulation.

@{b}-d@{ub}
     Choose dumbtelnet protocol, i.e. a standard TCP connection without
     echoing and without underlying protocol.

@{b}-e@{ub}
     Choose dumbtelnetecho protocol, i.e. a standard TCP connection
     without underlying protocol, echoing each character locally.

@{b}-h@{ub}
     Choose SecureShell mode. Please see @{"MiamiSecureShellKeyGen" Link "NODE_UTILITY_SECURESHELLKEYGEN"} for
     information how to create keys for SecureShell.

@{b}-l@{ub}
     Choose dumbtelnetline protocol, i.e. a standard TCP connection
     without underlying protocol, but with local line editing and
     echoing.

@{b}-r@{ub}
     Choose rlogin protocol.

@{b}-s service@{ub}
     Service name or port number. Default is 23 (telnet), unless the
     config file specifies something different, and unless a protocol
     was specified that uses a different default port.

@{b}-t@{ub}
     Choose telnet protocol.

@{b}-u@{ub}
     User name for rlogin and secshell. Default is your local user name,
     unless the config file specifies something different.

@{b}-v@{ub}
     Choose VT100 emulation.

@{b}-z@{ub}
     Choose telnets protocol (telnet via SSL).

@{b}profile/host@{ub}
     This can be either the name of an alias defined in the config file,
     or the name of the profile, or if no match for either of them is
     found in the config file, the name of a host to connect to.

@{b}service@{ub}
     Same as "-s service"

   The default for the emulation (ANSI/VT100) is VT100, unless the
config file specifies something different.

   The default for the protocol (dumbtelnet, dumbtelnetecho,
secureshell, dumbtelnetline, rlogin, telnet or telnets) is telnet,
unless the config file specifies something different and unless a
port/service was specified that requires a different protocol.

   MiamiTelnet loads the configuration file
"Miami:data/MiamiTelnet.config" during startup. It is an ASCII text
file which consists of name/value mappings to define settings, and
which supports the notion of "profiles" to define different settings
for different host. For the overall structure of the configuration file
please see @{"Misc. config files" Link "NODE_SPECIFICATIONS_CONFIGFILES"}.  For the name/value pairs supported by
MiamiTelnet please see @{"MiamiTelnet name/value pairs" Link "NODE_UTILITY_TELNET_NAMEVALUEPAIRS"}.

   MiamiTelnet opens a separate window with a Intuition menu bar
attached to it.  For a description of all menu items please see
@{"MiamiTelnet menu items" Link "NODE_UTILITY_TELNET_MENUITEMS"}.

   The MiamiTelnet window consists of three areas: a status line at the
top of the window, the large terminal area in the middle, and the chat
line at the bottom of the window. The status line displays the following
information:

   For TN3270:

@{b}"TELNET   3270"@{ub}
     Indicates TN3270 mode

@{b}"X-Clock"@{ub}
     If displayed indicates that the terminal is in X-Clock mode
     (waiting to be unlocked by the server).

@{b}"X-System"@{ub}
     If displayed indicates that the terminal is in X-System mode
     (waiting to be unlocked by the server).

@{b}"INS"@{ub}
     If displayed indicates that the terminal is in insert mode, i.e.
     each key you press is inserted into the current text field instead
     of overwriting the existing text.

   For all protocols except TN3270:

@{b}Protocol name@{ub}
     One of "TELNET". "RLOGIN", "DUMB" (dumb telnet), "DUMB-ECHO" (dumb
     telnet with echo), "DUMB-LINE" (dumb echo with line editing),
     "TELNETS" (telnet through SSL), "SECSHELL" (secure shell).

@{b}Telnet mode@{ub}
     Only for telnet and telnets: One of "NVT" (network virtual
     terminal), "CHAR" (character mode). "K-LN" (kludge line mode),
     "LINE" (line mode).

@{b}ECHO@{ub}
     Displayed if local echo is enabled.

@{b}EDIT@{ub}
     Displayed if local editing (e.g. for telnet line mode) is enabled.

@{b}RECV:7/8@{ub}
     Number of bits for received data.

@{b}SEND:7/8@{ub}
     Number of bits for sent data.

@{b}Flow control@{ub}
     One of "NOFLOW" (no flow control), "L-FLOW" (local flow control)
     and "R-FLOW" (remote flow control).

@{b}Flow control status@{ub}
     Usually empty. "*SUSP/ANY*" indicates that the display is suspended
     and can be restarted by pressing any key. "*SUSP*" indicates that
     the display is suspended and can be restarted by pressing Ctrl-Q.

@{b}DCS mode@{ub}
     If "DCS" appears here then the server has started to send a control
     string to the terminal. If this indicator does not go away by
     itself (e.g. after you accidentally tried to display a binary
     file) then you need to select "Terminal/Soft reset" to reset the
     VT100 state machine.

@{b}Emulation@{ub}
     One of "ANSI", "VT100", "VT52",


 @{" MiamiTelnet features " Link "NODE_UTILITY_TELNET_FEATURES"}                                             Features of MiamiTelnet
 @{" MiamiTelnet name/value pairs " Link "NODE_UTILITY_TELNET_NAMEVALUEPAIRS"}                                     Configuration file items
 @{" MiamiTelnet menu items " Link "NODE_UTILITY_TELNET_MENUITEMS"}                                           Menu items of MiamiTelnet
 @{" MiamiTelnet TN3270 information " Link "NODE_UTILITY_TELNET_TN3270"}                                   Information on TN3270 mode


@EndNode

@Node "NODE_UTILITY_TELNET_FEATURES" "MiamiDx.guide/NODE_UTILITY_TELNET_FEATURES"
@Next "NODE_UTILITY_TELNET_NAMEVALUEPAIRS"
@Toc "NODE_UTILITY_TELNET"

MiamiTelnet features
--------------------

   @{b}*@{ub} Support for telnet and rlogin protocols, plus support for three
     variations of "dumb telnet" intended to connect to non-telnet
     servers (e.g. SMTP): character-oriented without local echo,
     character-oriented with local echo, line-oriented with local echo.

   @{b}*@{ub} VT100, ANSI-color and VT52 emulations. Both the VT100 and
     ANSI-color emulation go far beyond the basics. Many VT102, VT220,
     VT420 and ECMA-48 control sequences are supported.

   @{b}*@{ub} Optional PC-8 character set emulation, so IBM-style graphical
     characters (for frames, "pseudo-windows" etc.) are rendered
     correctly with Amiga fonts in standard Latin-1 encoding.

   @{b}*@{ub} Emulations have a very high degree of compatibility, even with
     larger than nominal windows and dynamic window resizing. Tested
     with vttest, vi, tin, pine, emacs, lynx and several other
     full-screen programs, and some BBS systems.

   @{b}*@{ub} Support for "inverse", "bold", "italic", "underline", "concealed"
     and "blinking" styles, and 8 ANSI colors. "Blinking" can be
     disabled by the user.

   @{b}*@{ub} Adjustable cursor: solid-block, solid-line, blinking-block or
     blinking-line.

   @{b}*@{ub} Support for telnet NVT mode, character mode, kludge line mode and
     "real" line mode, for better performance across slow network links.
     Other Amiga telnet clients typically only support character mode.

   @{b}*@{ub} Local and remote flow control (Xon/Xoff) with correct handling of
     TCP urgent mode to flush data buffers.

   @{b}*@{ub} Font-sensitive, with adjustable (non-proportional) font. Telnet
     window can be directed to public screens and resized dynamically.
     ANSI color support using pen sharing. Compatible with 16/24-bit
     Picasso96/CyberGraphX screens.

   @{b}*@{ub} Status line for terminal/telnet status information.

   @{b}*@{ub} Option for 8-bit (binary) telnet mode.

   @{b}*@{ub} XPR interface implementation that actually works reliably. Tested
     with xprzmodem.library and telnet protocol on several hosts. No
     problems with ASCII or binary files of varying size (tested up to
     10 MB). Both uploads and downloads tested. Batch up/downloads are
     supported. Gadtools-based parameter and status windows for XPR.
     MiamiTelnet automatically switches to/from 8-bit mode for file
     transfers, if necessary.

   @{b}*@{ub} Automatic adjustment and transfer of HOSTDISPLAY/DISPLAY variable
     to the telnet server. No more need to manually "export DISPLAY" or
     "setenv DISPLAY" after connecting, when using AmiWin.

   @{b}*@{ub} Clipboard support.

   @{b}*@{ub} Chat line with history.

   @{b}*@{ub} Menu for run-time parameter and status changes.

   @{b}*@{ub} ASCII settings file for global settings, host profiles, individual
     per-host settings and host name aliases.

   @{b}*@{ub} Scrollback buffer window with clipboard support.

   @{b}*@{ub} SSL support.

   @{b}*@{ub} Secure-shell support (compatible with SSH (tm) version 1). Very
     comprehensive implementation with password authentication, host
     authentication and RSA authentication. Supported ciphers include
     DES, 3DES, ARCFOUR and BLOWFISH. Allows tunnelling of X11
     connections and TCP port forwarding in both directions through the
     secure-shell link. Supports compression.

   @{b}*@{ub} TN3270 support.

   @{b}*@{ub} SRP "Secure Remote Password" protocol for encrypted telnet login.

   SSH, SRP and Secure-shell are based on MiamiSSL, making MiamiTelnet
the ONLY AmigaOS telnet client supporting these protocols that is legal
to use inside and outside of the USA.

   SSH is a trademark of SSH Communications Security Ltd.


@EndNode

@Node "NODE_UTILITY_TELNET_NAMEVALUEPAIRS" "MiamiDx.guide/NODE_UTILITY_TELNET_NAMEVALUEPAIRS"
@Next "NODE_UTILITY_TELNET_MENUITEMS"
@Prev "NODE_UTILITY_TELNET_FEATURES"
@Toc "NODE_UTILITY_TELNET"

MiamiTelnet name/value pairs
----------------------------

@{b}host (hostname)@{ub}
     Host to contact for this profile (e.g. "telnet.foo.org")

@{b}protocol (protocolname)@{ub}
     Protocol to use: one of "telnet", "rlogin", "dumbtelnet",
     "dumbtelnetecho", "dumbtelnetline", "telnets" and "secshell". The
     default is "telnet", unless a service name is specified. In that
     case the default is "telnet" for port 23, "rlogin" for port 513,
     "telnets" for ports 151 and 992, "secshell" for port 22 and
     "dumbtelnet" for all other ports.

@{b}service (servicename or port number)@{ub}
     Service name or port number to use when contacting the host. The
     default is 23 if no protocol or telnet was chosen, 513 for rlogin,
     992 for telnets and 22 for secshell.

@{b}user (username)@{ub}
     The user name on the host. Only used for rlogin and secshell. The
     default is your local user name.

@{b}columns (cols)@{ub}
     The number of columns in the text window. Default is 80.

@{b}rows (rows)@{ub}
     The number of rows in the text window. Default is 24.

@{b}font (font/size)@{ub}
     The font to use in the text window. Has to be fixed-width. Default
     is "topaz/8".

@{b}emulation (name)@{ub}
     Terminal emulation. One of "vt100" (no colors) or "ansi" (similar
     to vt100, but with support for 8 ansi colors). Default is vt100.

@{b}pen0 (hexcode) - pen7 (hexcode)@{ub}
     pen0, pen1, ..., pen7 can be used to override the default ansi
     colors. Use an RGB hex code such as "35b" to specify the color.
     You can use 3 hex digits, 6 hex digits, 12 hex digits or 24 hex
     digits.

@{b}cursor (type)@{ub}
     Can be one of "block", "blockblink", "line" or "lineblink". The
     default is "blockblink".

@{b}blinking (yes/no)@{ub}
     If set to no then the "blinking disabled" switch defaults on. The
     default is "no".

@{b}bell (system/visual)@{ub}
     Reaction to a BEL character (^G). Can be "system" (DisplayBeep())
     or "visual" (characters inverted in the window). Default is
     "system".

@{b}xprlibrary (libname)@{ub}
     XPR library to use. Default is "LIBS:xprzmodem.library".

@{b}charset (normal/pc8/pc8full)@{ub}
     Character set to use. "normal" is the standard Amiga character set
     (ECMA Latin-1/94). "pc8" is the IBM PC-8 character set. Note that
     this is independent of the font you selected. If you set this
     switch to "pc8" then MiamiTelnet automatically emulates PC-8
     characters, even if your selected font uses Latin-1 encoding.
     Setting it to "pc8full" also causes some characters in the ASCII
     range 0-31 to be emulated. However this may interfere with some
     control sequences in that range.

@{b}leftaltis (alt/meta)@{ub}
     Meaning of the left alt key. Default is "alt".

@{b}rightaltis (alt/meta)@{ub}
     Meaning of the right alt key. Default is "alt".

@{b}backspaceis (backspace/delete)@{ub}
     Character generated for the backspace key. Default is backspace.

@{b}deleteis (backspace/delete)@{ub}
     Character generated for the delete key. Default is delete.

@{b}telnet8bit (yes/no)@{ub}
     Enable telnet-8-bit mode immediately after connecting. Default is
     no.  NOTE: not all telnet servers support 8-bit mode correctly. If
     you enable it and find that shell prompts are staggered in a funny
     way then you are connected to such a buggy server. This is NOT a
     bug in MiamiTelnet.

@{b}telnetlinemode (yes/no)@{ub}
     Allow telnet line mode. Default is yes. Disable this switch if
     your telnet server has problems in line mode.

@{b}windowx (xcoord)@{ub}
     x coordinate of upper left corner of your text window. Default is
     0.

@{b}windowy (ycoord)@{ub}
     y coordinate of upper left corner of your text window. Default is
     0.

@{b}pubscreen (name)@{ub}
     Name of public screen on which all window should be opened.
     Default is the system default public screen.

@{b}chatlineactive (yes/no)@{ub}
     If set to yes then the chatline is activated when MiamiTelnet
     starts.  Default is no.

@{b}scrollbackx (xcoord)@{ub}
     x coordinate of upper left corner of scrollback window. Default is
     0.

@{b}scrollbacky (ycoord)@{ub}
     y coordinate of upper left corner of scrollback window. Default is
     0.

@{b}scrollbackwidth (width)@{ub}
     Width of scrollback window in pixels. Default is 200.

@{b}scrollbackheight (height)@{ub}
     Height of scrollback window in pixels. Default is 100.

@{b}scrollbackmax (lines)@{ub}
     Max number of lines in scrollback buffer. Default is 2000.

@{b}termtype (terminal type)@{ub}
     Overrides the terminal type MiamiTelnet sends to the server.
     Servers usually use this for auto-detection and to initialize the
     TERM environment variable. Default is "ansi" for ansicolor mode
     and "vt100" otherwise.

@{b}flowcontrol (yes/no)@{ub}
     If set to yes disables use of Ctrl-Q/S for local flow control.
     Default is no.

@{b}password (password)@{ub}
     Sets the server (login) password. Currently only used in
     secureshell mode.

@{b}secureshellcompression (yes/no)@{ub}
     Enables or disables compression in secureshell mode.

@{b}secureshellcomplevel (level)@{ub}
     Sets the compression level (1-9) for compression in secureshell
     mode.

@{b}secureshellpassphrase (passphrase)@{ub}
     Sets the passphrase for the identity keyfile in secureshell mode.

@{b}secureshellidentity (pathname)@{ub}
     Sets the path name of the identity keyfile in secureshell mode.

@{b}secureshellauth (auth)@{ub}
     Specifies a list of authentication modes to be used for secureshell
     authenthication, in order of preference. "auth" is a
     comma-separated list of authentication algorithm names. Currently
     supported are RHOSTS, PASSWORD and RSA.

@{b}secureshellciphers (ciphers)@{ub}
     Specifies a list of ciphers to be used for secureshell encryption,
     in order of preference. "ciphers" is a comma-separated list of
     ciphers.  Currently supported are DES, 3DES and RC4.

@{b}reversevideo yes/no@{ub}
     Swaps foreground and background pens. Only effective with non-ANSI
     modes. Default is no.

@{b}quitonclose yes/no@{ub}
     Determines whether MiamiTelnet quits automatically when the
     connection is closed. Default is yes.

@{b}secureshellserverauth yes/no@{ub}
     Determines whether SecureShell connections attempt to authenticate
     the server's RSA key. Disabling this function slightly speeds up
     the login process and avoids maintenance of a "KnownHosts" file,
     but makes the setup vulnerable to man-in-the-middle attacks.
     Default is yes.

@{b}secureshellstrictauth yes/no/ask@{ub}
     Determines what to do if the server key is not listed in
     "KnownHosts", or if it has changed. "no" means silently accept it.
     "yes" means do not accept it, and abort. "ask" means put up a
     requester and ask the user.  Default is no.

@{b}secureshelllocalforward (lport rhost rport)@{ub}
     Causes connections to a local port to be forwarded to a port on a
     remote host, through the SecureShell link. This option can be
     specified more than once. Each occurence adds a new connection
     mapping.

@{b}secureshellremoteforward (rport lhost lport)@{ub}
     Causes connections to a port on the SecureShell server to be
     forwarded to a port on a local host, through the SecureShell link.
     This option can be specified more than once. Each occurence adds a
     new connection mapping.

@{b}secureshellx11forward yes/no@{ub}
     Determines whether connections by X11 clients on the SecureShell
     server should be forwarded to the the X11 server specified in the
     DISPLAY variable on your Amiga, through the SecureShell
     connection. Default is no.

@{b}jumpscroll (distance)@{ub}
     Enables jump scrolling, and determines the maximum distance to
     "jump".  The default is 1.

@{b}ansifrontcolor (number)@{ub}
     Sets the ANSI pen number of the default ANSI foreground color. Only
     effective in ANSI color mode. The default is 7.

@{b}ansibackcolor (number)@{ub}
     Sets the ANSI pen number of the default ANSI background color. Only
     effective in ANSI color mode. The default is 0.

@{b}f1 - f12 / shiftf1 - shiftf12 / altf1 - altf12 / ctrlf1 - ctrlf12 (text)@{ub}
     Programs function keys with a fixed text. The default is for each
     function key to send its VT100 escape sequence.

@{b}ctrllmode (mode)@{ub}
     Specifies the meaning of Ctrl-L (form feed). Can be one of
     "linefeed", "clearscreen" or "newpage". The default is "linefeed".

@{b}tn3270 yes/no@{ub}
     Requests TN3270 mode if set to yes. Default is no.

@{b}tn3270ext yes/no@{ub}
     Enables support for TN3270 "structured fields", "extended
     attributes" and, together with tn3270color, ANSI-like color. The
     default is no.

@{b}tn3270color yes/no@{ub}
     Enables TN3270 color support. Implies "tn3270ext yes". The default
     is no.

@{b}tn3270pen0 - tn3270pen13 (hexcode)@{ub}
     Overrides default colors for TN3270. See the documentation on
     "pen0-pen7" above for more information. See
     @{"MiamiTelnet TN3270 information" Link "NODE_UTILITY_TELNET_TN3270"} for a meaning of all 14 colors.

@{b}clipstripleading (yes/no)@{ub}
     Enable "strip leading blanks". The default is no.

@{b}clipstriptrailing (yes/no)@{ub}
     Enable "strip trailing blanks". The default is no.

@{b}allowdecresize (yes/no)@{ub}
     Allow DECCOLM control sequence for application-triggered displays
     resizes.

@{b}authsrp (yes/no)@{ub}
     Enable SRP authentication for telnet. Requires MiamiSSL 2.11 or
     higher.  The default is no.


@EndNode

@Node "NODE_UTILITY_TELNET_MENUITEMS" "MiamiDx.guide/NODE_UTILITY_TELNET_MENUITEMS"
@Next "NODE_UTILITY_TELNET_TN3270"
@Prev "NODE_UTILITY_TELNET_NAMEVALUEPAIRS"
@Toc "NODE_UTILITY_TELNET"

MiamiTelnet menu items
----------------------

@{b}Project/About...@{ub}
     Display information about MiamiTelnet.

@{b}Project/Quit...@{ub}
     Disconnect from the server and quit.

@{b}Edit/Copy...@{ub}
     Copy the highlighted text to the clipboard.

@{b}Edit/Paste...@{ub}
     Paste the current clipboard contents into the windows, simulating
     input from the keyboard.

@{b}Edit/Strip leading blanks@{ub}
     If this item is checkmarked then leading spaces and tabs are
     removed from each line of text during Copy/Paste operations.

@{b}Edit/Strip trailing blanks@{ub}
     If this item is checkmarked then trailing spaces and tabs are
     removed from each line of text during Copy/Paste operations.

@{b}Terminal/Set to 80x24@{ub}
     Resize the window for 80 columns and 24 rows.

@{b}Terminal/Set to 132x24@{ub}
     Resize the window for 132 columns and 24 rows.

@{b}Terminal/Cursor Type@{ub}
     Set the cursor to one of
    @{b}Block@{ub}
          Solid block, not blinking

    @{b}Block-blink@{ub}
          Solid block, blinking

    @{b}Line@{ub}
          Underline, not blinking

    @{b}Line-blink@{ub}
          Underline, blinking

@{b}Terminal/Soft reset@{ub}
     Perform a soft reset, which includes resetting the emulation state
     machine.

@{b}Terminal/Hard reset@{ub}
     Perform a hard reset, i.e. reset all internal variables to default
     states.

@{b}Terminal/Clear screen@{ub}
     Clear the screen.

@{b}Terminal/Disable blinking@{ub}
     If this item is enabled then text which is displayed by an
     application with the "blinking" property is displayed without
     blinking. This setting does not affect the cursor.

@{b}Terminal/Send backspace as@{ub}
     Send either a backspace or a delete character when pressing the
     backspace key. This setting supports the different interpretations
     of the backspace and delete characters in the DEC-VT100 and ANSI
     standards.

@{b}Terminal/Send delete as@{ub}
     Send either a backspace or a delete character when pressing the
     delete key. This setting supports the different interpretations of
     the backspace and delete characters in the DEC-VT100 and ANSI
     standards.

@{b}Terminal/Bell type@{ub}
     Define the action to be performed when receiving a BEL character
     (Ctrl-G, ASCII 7). With the "System" setting the AmigaOS function
     DisplayBeep() is used, and the behavior of that function can be
     configured in AmigaOS "Sound" preferences. With the "Visual"
     setting the window contents flash briefly.

@{b}Terminal/Character set@{ub}
     "Normal (Latin-1)" is the normal setting and should be used in most
     cases. Use "PC-8 emulation (hi-only)" when connecting to a BBS that
     uses IBM-PC-style graphics character for pseudo-windows. Use "PC-8
     emulation (full)" only with some full-screen programs that require
     a wider range of PC-8 emulation. Please note that this setting is
     incompatible with many programs and with standard ANSI control
     sequences.

@{b}Terminal/Chat line@{ub}
     Enables the chat line (below the bottom border in the window).
     With the chat line enabled everything you type is buffered in the
     chat line first and only sent to the server once you hit the
     return key.

@{b}Terminal/Scrollback window@{ub}
     Enables the scrollback window.

@{b}Terminal/Flow control@{ub}
     Enables local flow control, i.e. Ctrl-S and Ctrl-Q are intercepted
     and used to stop/start scrolling. If this option is disabled then
     Ctrl-S/Ctrl-Q are passed through to the server.

@{b}Terminal/Reset scroll region@{ub}
     Resets the VT100 scroll region. This function is only needed if
     programs set the scroll region to non-standard values and do not
     clean up after themselves properly.

@{b}Telnet/Change char mode to@{ub}
     Attempt to set the telnet protocol to 7-bit or 8-bit mode.  The
     default is 7-bit mode, but with this setting international
     characters are not displayed correctly. 8-bit mode is the
     preferred setting, but does not work correctly with all telnet
     servers. If, after switching to 8-bit mode, you get "staggered"
     shell prompts then you are connected to such a broken server.
     This is NOT a bug in MiamiTelnet.

@{b}Telnet/Change telnet mode to@{ub}
     The default mode is "char" (full-duplex character based
     communication). "Kludge-line" and "line" are line-based telnet
     protocols, which may improve performance with some servers by
     allowing local line editing. Not all telnet servers support this
     though.

@{b}Telnet/Change telnet line mode to@{ub}
     With telnet line mode enabled you can enable or disable
     full-duplex operation with this option. This should never be
     necessary though, because it is the responsibility of the server
     to select the correct mode.

@{b}Telnet/Send IP command@{ub}
     Send a telnet IP ("Interrupt Process") command.

@{b}Transfer/Protocol...@{ub}
     Select the XPR protocol for file transfer.

@{b}Transfer/Options...@{ub}
     Set the XPR protocol options.

@{b}Transfer/Send...@{ub}
     Send a file to the server using the currently configured XPR
     protocol. Before selecting this option you need to start the
     reception at the server.

@{b}Transfer/Receive...@{ub}
     Receive a file from the server using the currently configured XPR
     protocoo. Before selecting this option you need to start sending
     the file on the server.

@{b}Transfer/Set directory...@{ub}
     Set the default directory for up/downloads.


@EndNode

@Node "NODE_UTILITY_TELNET_TN3270" "MiamiDx.guide/NODE_UTILITY_TELNET_TN3270"
@Prev "NODE_UTILITY_TELNET_MENUITEMS"
@Toc "NODE_UTILITY_TELNET"

MiamiTelnet TN3270 information
------------------------------

   MiamiTelnet contains a fiull-fledged TN3270 emulation that can be
activated with the "-3" command line option.

   TN3270 key mapping:

@{b}PF1 - PF10@{ub}
     F1 - F10

@{b}PF11 - PF20@{ub}
     Shift F1 - F10

@{b}PF21 - PF30@{ub}
     Alt F1 - F10

@{b}PF31 - PF36@{ub}
     Shift Alt F1 - F6

@{b}PA1 - PA3@{ub}
     Ctrl F1 - F3

@{b}Attn@{ub}
     Ctrl A

@{b}Clear@{ub}
     Ctrl C

@{b}DUP@{ub}
     Ctrl D

@{b}Error Ovrd@{ub}
     Ctrl E

@{b}Field Mark@{ub}
     Ctrl F

@{b}Reset@{ub}
     Ctrl R

@{b}SysReq@{ub}
     Ctrl S

@{b}Erase EOF@{ub}
     Shift DEL

@{b}Erase Input@{ub}
     Alt DEL

@{b}Insert Mode@{ub}
     Shift Keypad 0

   TN3270 color mapping:

   Pens 0-13 are supposed to be assigned to the following colors.  IBM
3270 users: note that the numbering of pens in MiamiTelnet is different
from the numbering of color codes in the 3270 SNA protocol.

@{b}0@{ub}
     black

@{b}1@{ub}
     blue

@{b}2@{ub}
     red

@{b}3@{ub}
     pink

@{b}4@{ub}
     green

@{b}5@{ub}
     turquoise

@{b}6@{ub}
     yellow

@{b}7@{ub}
     white

@{b}8@{ub}
     deep blue

@{b}9@{ub}
     orange

@{b}10@{ub}
     purple

@{b}11@{ub}
     pale green

@{b}12@{ub}
     pale turquoise

@{b}13@{ub}
     grey


@EndNode

@Node "NODE_UTILITY_TELNETD" "MiamiDx.guide/NODE_UTILITY_TELNETD"
@Next "NODE_UTILITY_TRACEROUTE"
@Prev "NODE_UTILITY_TELNET"
@Toc "NODE_UTILITY"

MiamiTelnetD
============

   Telnet and rlogin daemon. This daemon allows incoming telnet and
rlogin connections to an Amiga shell. It can be run in the background
(in stand-alone mode) or started from INetD.

   Usage: MiamiTelnetD [-p profile] [-s service] [-r] [-t]

   Options:

@{b}-p profile@{ub}
     Name of a profile in the configuration file.

@{b}-s service@{ub}
     Port number or service name to listen on. This is only used if the
     daemon is run in stand-alone mode, as a background program. If it
     is started from INetD then the port to listen on is determined by
     the INetD configuration.

@{b}-r@{ub}
     Use the rlogin protocol.

@{b}-t@{ub}
     Use the telnet protocol.

   If no protocol is specified then telnet is used except if the port
is 513. In that case rlogin is used. If no port is specified then the
default port for the specified protocol is used. If neither port nor
protocol are specified then the default is to run in telnet mode on
port 23. In other words: MiamiTelnetD uses reasonable defaults unless
you override them with one or more command line options.

   In order to run MiamiTelnetD from INetD add the following lines to
the INetD configuration (see @{"InetD database" Link "NODE_CONFIG_DATABASE_INETD"}):

@{b}For telnet:@{ub}
     telnet stream tcp nowait nobody Miami:MiamiTelnetD MiamiTelnetD

@{b}For rlogin:@{ub}
     login stream tcp nowait nobody Miami:MiamiTelnetD MiamiTelnetD

   The last column ("Args") should contain the command line options you
want to use, e.g. "-r". It usually can remain empty.

   In order to allow users to log in you have to create valid user
entries in the Users database (see @{"Users database" Link "NODE_CONFIG_DATABASE_USERS"}).  The "Shell" column
in the user entry determines the program MiamiTelnetD runs after a user
has logged in. A good choice is "newcli * s:remote-startup".  This
opens a shell and executes the script "s:remote-startup".  That script
has to be set up to add all necessary paths and assigns.  It should
also disable AmigaDOS requesters, using a tool such as "util/cli/NoReq"
on Aminet.

   In addition to command line parameters MiamiTelnetD reads a
configuration file during startup, with more detailed configuration
parameters. Currently this file allows you to define logging parameters
and "trusted" users for rlogin. For that you need to create a
configuration file "Miami:data/MiamiTelnetD.config".  This is an ASCII
text file which consists of name/value mappings to define settings. For
the overall structure of the configuration file please see
@{"Misc. config files" Link "NODE_SPECIFICATIONS_CONFIGFILES"}. Valid name/value pairs are:

@{b}syslog yes/no@{ub}
     Specifies whether MiamiTelnetD should log events (successful and
     failed connection attempts and disconnects) in the MiamiDx system
     log. Default: false.

@{b}logfile (filename)@{ub}
     Specifies the file name of a log file MiamiTelnetD uses to log
     events directly, i.e. without going through the system log.
     Default: no file.

@{b}logidentd (yes/no)@{ub}
     Specifies whether MiamiTelnetD should attempt to perform an identd
     (auth) lookup to find out the real user name of the client and add
     it to log entries. This lookup is done in parallel with the normal
     login procedure, but if it takes longer than the login then access
     will block until the lookup is complete.

@{b}loghost (yes/no)@{ub}
     Specifies whether MiamiTelnetD should attempt to perform a reverse
     DNS lookup on the IP address of the connecting host, in order to
     find out the remote host name and add it to log entries. This
     lookup is done in parallel with the normal login procedure, but if
     it takes longer than the login then access will block until the
     lookup is complete.

@{b}trusted (hosts) (clientusers) (serverusers)@{ub}
     This item defines a set of hosts, client user names and server
     user names which are considered "trusted", i.e. which are allowed
     to log in using rlogin without a password check. "hosts",
     "clientusers" and "serverusers" are comma- (",")- separated lists.
     If a user tries to connect from a host in the list, using a client
     user name appearing in the list, and trying to log in to the
     server using a server user name appearing in the list, then he is
     allowed to do so without a password check. Hosts MUST be specified
     using IP addresses, not host names (for security reasons). IP
     address ranges can be specified using a host/mask notation, e.g.
     192.2.3.0/255.255.255.0.  The "*" can be used as a wildcard for
     user names and means "all users". The "%" can be used as a
     wildcard for server user names and means "same as client user",
     i.e. it only allows users to log in if their client user name is
     identical to their server user name. Multiple "trusted" lines can
     appear in a single configuration file. Examples:

    @{b}trusted 192.2.3.0/255.255.255.0,55.66.77.88 joe,fred %@{ub}
          Allows users joe and fred to log in without password check
          from any hosts in the 192.2.3.* network or from the host
          55.66.77.88, but only if they are trying to log in with the
          same user name they are using on the machine they are logging
          in from.

    @{b}trusted 1.2.3.4 * %@{ub}
          Allows anyone from 1.2.3.4 to log in without password check
          using the same user name they are using on 1.2.3.4.

    @{b}trusted 1.2.3.4 bob keith@{ub}
          Allows bob on 1.2.3.4 to log in as the user "keith" on your
          Amiga without a password check.

   MiamiTelnetD performs extensive rewriting of input (keyboard) and
output (screen) control sequences in order to make Amiga applications,
which are used to using the Amiga-ANSI dialect, transparently
compatible with the more widely used VT100 and ANSI standards. The
telnet client used to connect to MiamiTelnetD must implement some
subset of the VT100/ANSI standard for MiamiTelnetD to work correctly
with it.

   Both "raw mode" and "cooked mode" are supported, and MiamiTelnetD
emulates a console unit, so most standard pagers (e.g.
"SYS:Utilities/More") work correctly with MiamiTelnetD. In "cooked
mode" MiamiTelnetD provides line editing and command history facilities
similar to those in the original AmigaOS 2.x/3.x console windows.


@EndNode

@Node "NODE_UTILITY_TRACEROUTE" "MiamiDx.guide/NODE_UTILITY_TRACEROUTE"
@Next "NODE_UTILITY_L2TP"
@Prev "NODE_UTILITY_TELNETD"
@Toc "NODE_UTILITY"

MiamiTraceRoute
===============

   Print the route packets take to a network host.

   Usage: MiamiTraceRoute [-m max_ttl] [-n] [-p port] [-q nqueries]
[-r] [-s src_addr] [-t tos] [-v] [-w waittime] host [packetsize]

   Options:

@{b}-m max_ttl@{ub}
     Set the max time-to-live (max number of hops) used in outgoing
     probe packets.  The default is 30 hops.

@{b}-n@{ub}
     Print hop addresses numerically rather than symbolically and
     numerically (saves a nameserver address-to-name lookup for each
     gateway found on the path).

@{b}-p port@{ub}
     Set the base UDP port number used in probes (default is 33434).
     MiamiTraceRoute hopes that nothing is listening on UDP ports base
     <port>+nhops-1 at the destination host (so an ICMP PORT_UNREACHABLE
     message will be returned to terminate the route tracing).  If
     something is listening on a port in the default range, this option
     can be used to pick an unused port range.

@{b}-q nqueries@{ub}
     Set the number of probes per "ttl" to <nqueries> (default is three
     probes).

@{b}-r@{ub}
     Bypass the normal routing tables and send directly to a host on an
     attached network. If the host is not on a directly-attached
     network, an error is returned.

@{b}-s src_addr@{ub}
     Use the following IP address (which must be given as an IP number,
     not a hostname) as the source address in outgoing probe packets.
     On hosts with more than one IP address, this option can be used to
     force the source address to be something other than the IP address
     of the interface the probe packet is sent on.  If the IP address
     is not one of this machine's interface addresses, an error is
     returned and nothing is sent.

@{b}-t tos@{ub}
     Set the type-of-service in probe packets to the following value
     (default zero). The value must be a decimal integer in the range 0
     to 255.  This option can be used to see if different
     types-of-service result in different paths.

@{b}-v@{ub}
     Verbose output.  Received ICMP packets other than TIME_EXCEEDED
     and UNREACHABLE are listed.

@{b}-w@{ub}
     Set the time (in seconds) to wait for a response to a probe
     (default 3 sec.).


@EndNode

@Node "NODE_UTILITY_L2TP" "MiamiDx.guide/NODE_UTILITY_L2TP"
@Next "NODE_UTILITY_PPPOE"
@Prev "NODE_UTILITY_TRACEROUTE"
@Toc "NODE_UTILITY"

miamil2tp.device
================

   miamil2tp.device is a serial.device-compatible driver for L2TP
(Layer-2 Tunnelling Protocol). L2TP is one of the protocols commonly
used for VPNs (Virtual Private Networks), and is also used for
DSL/cable modem connections by some Internet providers.

   miamil2tp.device can be configured for a PPP dial-up link just like
any other serial device. Please see @{"PPP dial-up Internet access" Link "NODE_TYPICAL_PPPDIALUP"} for
more information. You should use the following parameters during the
configuration:

   @{b}*@{ub} Name: "Miami:devs/miamil2tp.device"

   @{b}*@{ub} Unit: 0

   @{b}*@{ub} Use CD: enabled

   @{b}*@{ub} MTU: 1448

   @{b}*@{ub} Modem settings, DTR mode: hangup

   @{b}*@{ub} Modem settings, Dial prefix: ATD

   The dialer entry you use should contain a single "phone number" set
to the IP address of the L2TP server you are connecting to.

   If the L2TP server you are conneting to requires challenge
authentication (separately from the normal PPP authentication) using a
"shared secret" then you need to create a text file
"Miami:data/MiamiL2TP.config" and add the following line to that file:

   secret mysharedsecret

   (with whatever shared secret your L2TP server needs for your host).

   For more complex setups the "phone number" can also contain a
profile name for a configuration file. The configuration file uses the
same format that other MiamiDx utilities use (see @{"Misc. config files" Link "NODE_SPECIFICATIONS_CONFIGFILES"}),
and supports the following keywords:

@{b}server name@{ub}
     Server name or IP address.

@{b}secret sharedsecret@{ub}
     Shared secret for challenge authentication.


@EndNode

@Node "NODE_UTILITY_PPPOE" "MiamiDx.guide/NODE_UTILITY_PPPOE"
@Next "NODE_UTILITY_PPTP"
@Prev "NODE_UTILITY_L2TP"
@Toc "NODE_UTILITY"

miamipppoe.device
=================

   miamippppoe.device is a serial.device-compatible driver for PPPoE
(PPP over Ethernet). PPPoE is one of the protocols commonly used
DSL/cable modem connections by some Internet providers.

   miamipppoe.device can be configured for a PPP dial-up link just like
any other serial device. Please see @{"PPP dial-up Internet access" Link "NODE_TYPICAL_PPPDIALUP"} for
more information. You should use the following parameters during the
configuration:

   @{b}*@{ub} Name: "Miami:devs/miamipppoe.device"

   @{b}*@{ub} Unit: 0

   @{b}*@{ub} Use CD: enabled

   @{b}*@{ub} MTU: 1492

   @{b}*@{ub} Modem settings, DTR mode: hangup

   @{b}*@{ub} Modem settings, Dial prefix: ATD

   The dialer entry you use should contain a single "phone number".
The number itself can be empty.

   By default MiamiDx tries to run PPPoE across the interface "eth0"
(the first configured Ethernet interface). If you have multiple
Ethernet interfaces and want to run PPPoE across a different interface
then create a text file "Miami:data/MiamiPPPoE.config" and add the
following line to that file:

   interface interfacename

   (with whatever shared interface name you want to use, e.g.  "eth1").

   For more complex setups the "phone number" can also contain a
profile name for a configuration file. The configuration file uses the
same format that other MiamiDx utilities use (see @{"Misc. config files" Link "NODE_SPECIFICATIONS_CONFIGFILES"}),
and supports the following keywords:

@{b}interface interfacename@{ub}
     Interface to use

@{b}service@{ub}
     Name of service to use

@{b}timeout@{ub}
     Timeout during PPPoE queries in seconds.


@EndNode

@Node "NODE_UTILITY_PPTP" "MiamiDx.guide/NODE_UTILITY_PPTP"
@Next "NODE_UTILITY_SANAMNI"
@Prev "NODE_UTILITY_PPPOE"
@Toc "NODE_UTILITY"

miamipptp.device
================

   miamipptp.device is a serial.device-compatible driver for PPTP
(Point-to-Point Tunnelling Protocol). PPTP is one of the protocols
commonly used for VPNs (Virtual Private Networks), and is also used for
DSL/cable modem connections by some Internet providers.

   miamipptp.device can be configured for a PPP dial-up link just like
any other serial device. Please see @{"PPP dial-up Internet access" Link "NODE_TYPICAL_PPPDIALUP"} for
more information. You should use the following parameters during the
configuration:

   @{b}*@{ub} Name: "Miami:devs/miamipptp.device"

   @{b}*@{ub} Unit: 0

   @{b}*@{ub} Use CD: enabled

   @{b}*@{ub} MTU: 1460

   @{b}*@{ub} Modem settings, DTR mode: hangup

   @{b}*@{ub} Modem settings, Dial prefix: ATD

   The dialer entry you use should contain a single "phone number" set
to the IP address of the PPTP server you are connecting to.

   For more complex setups the "phone number" can also contain a
profile name for a configuration file. The configuration file uses the
same format that other MiamiDx utilities use (see @{"Misc. config files" Link "NODE_SPECIFICATIONS_CONFIGFILES"}),
and supports the following keywords:

@{b}server name@{ub}
     Server name or IP address.


@EndNode

@Node "NODE_UTILITY_SANAMNI" "MiamiDx.guide/NODE_UTILITY_SANAMNI"
@Prev "NODE_UTILITY_PPTP"
@Toc "NODE_UTILITY"

sanamni.device
==============

   sanamni.device is a SANA-II-compatible device that allows you to use
MNI drivers with applications that support SANA-II devices. Its
intended purpose is to allow the use Envoy V3 in parallel with MiamiDx,
with different packet types.

   Notes:

   @{b}*@{ub} sanamni.device requires the registered version of MiamiDx.
     MiamiDx does not have to be running when sanamni.device is used,
     but is has to be installed, complete with keyfiles.

   @{b}*@{ub} sanamni.device CANNOT be used by a TCP/IP stack or some other
     application that uses IP/Arp packet types. Packet types 2048 and
     2054 are reserved for MiamiDx, and are not forwarded by
     sanamni.device. If you use Envoy V3 with sanamni.device then make
     sure that you configure Envoy for different packet types.

   @{b}*@{ub} Applications that use sanamni.device on top of an MNI driver will
     be slower than applications that use the same MNI driver directly,
     possibly even slower than applications that use a dedicated
     equivalent SANA-II driver.

   @{b}*@{ub} The SANA-II emulation in sanamni.device is not complete. It is
     sufficient for Envoy V3, but may not be sufficient for some other
     applications. Among the features not implemented are multicasting,
     packet statistics, online/offline transitions and most types of
     notification. sanamni.device probably won't work with most SANA-II
     monitor utilities.

   Configuration (Example for unit 0):

   Create a file "ENV:SANA2/sanamni0.config" which contains the
following line of text:

   mnidrivername mniunitnumber mniparameters

   For instance:

   z2-smc91c90.mni 0

   (no MNI parameters given in this example)

   The AmigaDOS pattern used to parse the file is
"MNINAME/A,MNIUNIT/N,MNIOPTIONS".

   In your application specify the SANA-II device name as
"sanamni.device" and the unit number as "0".


@EndNode

@Node "NODE_COMPATIBILITY" "MiamiDx.guide/NODE_COMPATIBILITY"
@Next "NODE_RESTRICTIONS"
@Prev "NODE_UTILITY"
@Toc "Main"

Compatibility
*************

   So far MiamiDx has worked with all AmiTCP clients and servers it has
been tested with, with one exception:

   The AmiTCP 4.x version of "telnet" does not normally work with
MiamiDx.  This is because that version of "telnet" uses some
non-documented features of "TCP:" that cannot be emulated by MiamiDx.

   There are two solutions to this:

   @{b}*@{ub} Use a different version of telnet, e.g.  MiamiTelnet (see
     @{"MiamiTelnet" Link "NODE_UTILITY_TELNET"}), part of the MiamiDx package, or any other
     third-party telnet implementation, e.g. "AmTelnet", from Vaporware.

   @{b}*@{ub} Install the version of "inet-handler" that comes with AmiTCP
     4.0demo, create an appropriate mountlist entry for "TCP:", and type
     "mount TCP:" @{i}before@{ui} starting MiamiDx. "telnet" will then use the
     AmiTCP version of "TCP:" (still accessing the MiamiDx TCP/IP stack,
     of course) instead of the version of "TCP:" built in to MiamiDx.


@EndNode

@Node "NODE_RESTRICTIONS" "MiamiDx.guide/NODE_RESTRICTIONS"
@Next "NODE_HISTORY"
@Prev "NODE_COMPATIBILITY"
@Toc "Main"

Restrictions
************

   The demo version has the following limitations:

   @{b}*@{ub} After 60 minutes the modem hangs up the line. SANA-II connections
     are interrupted after 30 minutes.

   @{b}*@{ub} It is not possible to keep TCP connections alive when the modem
     hangs up.

   @{b}*@{ub} The "Events" options "auto-online after passive offline" and
     launching ARexx or Shell scripts are not available.

   @{b}*@{ub} The number of phone numbers in the dialer is limited to three.

   @{b}*@{ub} Phone logging is disabled.

   @{b}*@{ub} The Window customization options are disabled.

   @{b}*@{ub} Multicasting and T/TCP are not functional.

   @{b}*@{ub} The IP filter is not available.

   @{b}*@{ub} Ping flood protection is not available.

   @{b}*@{ub} The sorting, merging and Clipboard import/export functions on the
     Database are not available.

   @{b}*@{ub} PPP Callback is not available.

   @{b}*@{ub} The packet monitoring callback (for external packet monitors like
     MiamiTCPDump) is not functional.

   @{b}*@{ub} System log events cannot be exported to syslog.library.

   @{b}*@{ub} Many utility programs, all multicasting and DNS tools, and the
     libraries miamibpf.library and miamipcap.library cannot be used.

   @{b}*@{ub} MS-CHAP support, PPP encryption and PPP compression are not
     available.

   @{b}*@{ub} The control panel is not available.

   @{b}*@{ub} The interface auto-connect function is not available.

   @{b}*@{ub} Manual routes and IP aliases cannot be added.

   @{b}*@{ub} The SysCtl, IP-NAT and IP-Filter pages of the database are not
     accessible.

   @{b}*@{ub} Routing between interfaces is not available. That includes normal
     routing as well as IP-NAT, SOCKS and firewalling.


@EndNode

@Node "NODE_HISTORY" "MiamiDx.guide/NODE_HISTORY"
@Next "NODE_FUTURE"
@Prev "NODE_RESTRICTIONS"
@Toc "Main"

History
*******

@{b}Version 0.99a@{ub}
     Pre-release version


@EndNode

@Node "NODE_FUTURE" "MiamiDx.guide/NODE_FUTURE"
@Next "NODE_SUPPORT"
@Prev "NODE_HISTORY"
@Toc "Main"

The Future
**********

   Future extensions to MiamiDx @{i}could@{ui} include:

   @{b}*@{ub} A full BIND release v8 including named (DNS server).

   @{b}*@{ub} IPv6 support

   @{b}*@{ub} IP-SEC: ESP and AH.

   @{b}*@{ub} PPP dial-in


@EndNode

@Node "NODE_SUPPORT" "MiamiDx.guide/NODE_SUPPORT"
@Next "NODE_ACKNOWLEDGEMENTS"
@Prev "NODE_FUTURE"
@Toc "Main"

Support
*******

   There are several ways to get technical support, updates etc.:

@{b}email@{ub}
     kruse@nordicglobal.com

@{b}snail mail@{ub}
     Nordic Global Inc.
     Attn: Holger Kruse
     PO Box 780248
     Orlando FL 32878-0248
     USA

@{b}WWW@{ub}
     http://www.nordicglobal.com/md.html

@{b}mailing lists@{ub}
     send "SUBSCRIBE miamidx-talk-ml" or "SUBSCRIBE miamidx-announce-ml"
     in the body of a mail to "listar@nordicglobal.com".


@EndNode

@Node "NODE_ACKNOWLEDGEMENTS" "MiamiDx.guide/NODE_ACKNOWLEDGEMENTS"
@Next "NODE_GLOSSARY"
@Prev "NODE_SUPPORT"
@Toc "Main"

Acknowledgements
****************

   My sincere thanks go to

   @{b}*@{ub} the early alpha and beta testers Karl Bellve, Mike Fitzgerald,
     Adam Hough, Daniel Saxer, Stefan Stuntz and Oliver Wagner.

   @{b}*@{ub} Karl Bellve and Daniel Saxer for their great support efforts.

   @{b}*@{ub} NSDi for the first publically available TCP/IP protocol suite for
     AmigaOS and its very usable API.

   @{b}*@{ub} James Cooper, Steve Krueger and Doug Walker for the SAS/C
     development system and their great support.

   @{b}*@{ub} Stefan Stuntz for his nice graphical user interface package MUI.

   @{b}*@{ub} Klaus Melchior for his MUI custom class "Busy.mcc".

   @{b}*@{ub} Robert Reiswig for loaning me some important computer equipment.

   @{b}*@{ub} the University of California for their successful continued work on
     the excellent BSD networking code.

   @{b}*@{ub} Reinhard Spisser and Sebastiano Vigna for their Amiga port of
     "makeinfo".

   @{b}*@{ub} Paul Trauth, the winner of the Miami logo contest, for his nice
     collection of images.

   @{b}*@{ub} John Pszeniczny for his nice variations of the "Miami" logo.

   @{b}*@{ub} Jim Szutowicz for his high-color versions of the "Miami" logo.

   @{b}*@{ub} Martin Huttenloher and Stefan Stuntz for their permission to use
     MagicWB images in Miami.

   @{b}*@{ub} Roman Patzner for new icon designs.

   @{b}*@{ub} Olaf Barthel for gtlayout.library and help in tracking down some
     problems.

   @{b}*@{ub} Fred Wright for his expertise and help.

   @{b}*@{ub} all users who decide to register Miami.


@EndNode

@Node "NODE_GLOSSARY" "MiamiDx.guide/NODE_GLOSSARY"
@Prev "NODE_ACKNOWLEDGEMENTS"
@Toc "Main"

Glossary
********

@{b}6Bone@{ub}
     Backbone for IPv6. The 6Bone is a virtual network on top of the
     Internet that is used for implementation and testing of the IPv6
     protocol family.

@{b}ACCM@{ub}
     See "Asynchronous Control Character Map"

@{b}Address Resolution Protocol (Arp)@{ub}
     A protocol used to translate IP addresses into the addresses used
     at the link layer (physical addresses, MAC addresses). Most
     commonly used with Ethernet.

@{b}Arp@{ub}
     See "Address Resolution Protocol"

@{b}Asynchronous Control Character Map (ACCM)@{ub}
     Parameter configured as part of PPP that determines which ASCII
     character codes should be escaped on the PPP link. ACCM is a 32-bit
     mask, with one bit for each character in the range 0-31. Ideally
     this parameter should always be 0x00000000, indicating that no
     characters need to be escaped (providing best performance).
     However in order to support software handshaking on portions of
     the link the ACCM is usually set to 0x000a0000 to escape
     characters 17 and 19 (Xon/Xoff).

@{b}BootP@{ub}
     See "Bootstrap Protocol"

@{b}Bootstrap Protocol (BootP)@{ub}
     A protocol used to automatically configure IP addresses and other
     configuration parameters by querying a central server. Commonly
     used with SLIP and in some Ethernet LANs. BootP does not support
     dynamic IP addresses. For that the newer protocol "DHCP" is
     required.

@{b}Callback Control Protocol (CBCP)@{ub}
     A sub-protocol of PPP used to configure a call-back (dial-back),
     usually when connecting to Windows-NT RAS servers.

@{b}CBCP@{ub}
     See "Callback Control Protocol"

@{b}CCP@{ub}
     See "Compression Control Protocol"

@{b}CERN Proxy@{ub}
     Proxy-server protocol for http and ftp. Commonly used with web
     browsers to provide local caching of web pages and sometimes to
     traverse a firewall.

@{b}Challenge Handshake Authentication Protocol (CHAP)@{ub}
     A sub-protocol of PPP used to authenticate a user, i.e. to exchange
     user name and password. CHAP sends passwords in encrypted form.
     Alternative protocols for the same purpose are PAP and MS-CHAP.

@{b}CHAP@{ub}
     See "Challenge Handshake Authentication Protocol"

@{b}Compressed SLIP (CSLIP)@{ub}
     Variation of SLIP that supports VJC TCP header compression.

@{b}Compression Control Protocol (CCP)@{ub}
     A sub-protocol of PPP used to configure which compression protocol
     (and sometimes which encryption protocol) should be used on a PPP
     link.

@{b}CSLIP@{ub}
     See "Compressed SLIP"

@{b}Default Gateway@{ub}
     The gateway (router) a packet is sent to when the destination IP
     address of the packet does not refer to a machine within the local
     network. The default gateway is typically the machine which
     connects the local network to the Internet.

@{b}DHCP@{ub}
     See "Dynamic Host Configuration Protocol"

@{b}DNS@{ub}
     See "Domain Name System"

@{b}Domain Name System (DNS)@{ub}
     Infrastructure on the Internet allowing the use of symbolic host
     names instead of IP addresses in applications. DNS is responsible
     for maintaining the mapping between host names and IP addresses
     and for providing the necessary translation between the two.

@{b}Dynamic Host Configuration Protocol (DHCP)@{ub}
     A protocol used to automatically configure IP addresses (static or
     dynamic) and other configuration parameters by querying a central
     server. Commonly used with DSL and cable modem setups.

@{b}File Transfer Protocol (FTP)@{ub}
     TCP-based protocol used to transfer files between hosts on the
     Internet. Requires an FTP server on one end and either an FTP
     client or a web browser that supports `ftp://' URLs on the other
     end.

@{b}Firewall@{ub}
     Security mechanism that isolates a LAN from the Internet, usually
     limiting what kinds of connections machines on the Internet can
     make to machines on the LAN, with the purpose of better protecting
     a LAN from break-in attempts from the Internet. Sometimes
     firewalls limit connections in the other direction (from the LAN
     to the Internet) as well.

@{b}FTP@{ub}
     See "File Transfer Protocol"

@{b}Gateway@{ub}
     Synonym for "router". If the term "gateway" is used in the context
     of an interface configuration then it usually refers to a "Default
     Gateway" located on the physical network this interface is
     connected to.

@{b}HTTP@{ub}
     See "Hypertext Transfer Protocol"

@{b}HTTPS@{ub}
     See "HTTP with Security"

@{b}Hypertext Transfer Protocol (HTTP)@{ub}
     Protocol to transfer web pages across the Internet. Requires a web
     server on one end and a web browser on the other end.

@{b}HTTP with Security (HTTPS)@{ub}
     Same as HTTP, except that all data is transfered across an
     SSL-encrypted and authenticated connection, for security purposes.

@{b}ICMP@{ub}
     See "Internet Control Message Protocol"

@{b}IETF@{ub}
     See "Internet Engineering Task Force"

@{b}Integrated Services Digital Network (ISDN)@{ub}
     Digital telephone system primarily used in Europe, with higher
     bandwidth than the conventional analog phone system (up to 128
     kB/s) and direct support for digital fax and digital data
     connections.

@{b}Internet Control Message Protocol (ICMP)@{ub}
     Protocol on top of IP used for administrative purposes. ICMP allows
     automatic configuration of netmasks, gateways and routing, flow
     control for TCP, detection and transmission of network errors,
     detection of reachibility (ping) and other things.

@{b}Internet Engineering Task Force (IETF)@{ub}
     The organization that develops and published official Internet
     standards.

@{b}Internet Protocol (IP)@{ub}
     The lowest-layer protocol of the TCP/IP protocol hierarchy. IP
     provides addressing, routing and delivery of individual packets
     (IP datagrams).

@{b}Internet Protocol Next Generation (IPng)@{ub}
     The name of the next generation IP protocol (success of the
     "normal" IP protocol, i.e. IPv4), while the standardization was in
     its early stages. The protocol that was chosen as the successor is
     now officially called IPv6.

@{b}Internet Protocol Version 6 (IPv6)@{ub}
     Successor of the current IP protocol (IPv4), destined to supercede
     and on the long run replace IPv4 on the Internet. IPv6 is expected
     to be deployed during the first decade of the 21st century. Among
     the advantages of IPv6 over IPv4 are a larger address space and
     better support for streaming media. MiamiDx is "IPv6-ready" in the
     sense that it provides the necessary API for IPv6 so applications
     can be developed for IPv6. MiamiDx does not currently implement
     IPv6 though.  a larger address

@{b}IP@{ub}
     See "Internet Protocol"

@{b}IP Control Protocol (IPCP)@{ub}
     Sub-protocol of PPP, used to configure IP parameters of a PPP link.
     IPCP typically configures the IP addresses of a PPP link, VJC TCP
     header compression and sometimes DNS servers.

@{b}IPCP@{ub}
     See "IP Control Protocol"

@{b}IPng@{ub}
     See "Internet Protocol Next Generation"

@{b}IPv6@{ub}
     See "Internet Protocol Version 6"

@{b}ISDN@{ub}
     See "Integrated Services Digital Network"

@{b}ISDN Terminal Adapter (ISDN-TA)@{ub}
     Device to connect a computer to an ISDN line, sometimes incorrectly
     called "ISDN modem". From a computer's point of view an ISDN modem
     usually behaves like an analog modem connected to a phone line.

@{b}ISDN-TA@{ub}
     See "ISDN Terminal Adapter"

@{b}L2TP@{ub}
     See "Layer-Two Tunneling Protocol"

@{b}LAN@{ub}
     See "Local Area Network"

@{b}Layer-Two Tunneling Protocol (L2TP)@{ub}
     Industry standard protocol for VPNs, sometimes also used for DSL
     or cable modem access. MiamiDx can act as an L2TP client, using
     miamil2tp.device.

@{b}LCP@{ub}
     See "Link Control Protocol"

@{b}Link Control Protocol (LCP)@{ub}
     A sub-protocol of PPP responsible for configuring the physical line
     parameters of a PPP link, including among other things MTU and
     ACCM.

@{b}Local Area Network (LAN)@{ub}
     Network of computers set up within a relatively small physical
     space, e.g. a room or a building, often using protocols like
     Ethernet or Arcnet.  Contrasts with Wide Area Networks (WANs),
     Metropolitan Area Networks (MANs) or Internet connections.

@{b}MAC Address@{ub}
     See "Media Access Control Address"

@{b}Maximum Transfer Unit (MTU)@{ub}
     Maximum packet size that can be transfered across a specific
     physical network, often determined by hardware limitations.  For
     Ethernet this value is 1500, for other networks it may vary.

@{b}MBone@{ub}
     See "Multicast Backbone"

@{b}Media Access Control Address (MAC address)@{ub}
     Address used to identify computers on a physical network such as
     Ethernet. MAC addresses are different from IP addresses, and the
     length of format of a MAC address depends on the physical network.
     For instance Ethernet uses 6-byte MAC addresses, whereas Arcnet
     uses 1-byte MAC addresses. Arp is often used to translate IP
     addresses into MAC addresses.

@{b}Microsoft CHAP (MS-CHAP)@{ub}
     A sub-protocol of PPP used to authenticate a user, i.e. to exchange
     user name and password. Commonly required by Windows-NT RAS
     servers and supported by Windows-95/98. Two versions of MS-CHAP
     exist: MS-CHAPv1 (commonly just called MS-CHAP) and MS-CHAPv2.
     Newer versions of Windows-NT requires MS-CHAPv2 for PPTP (VPN)
     access. MS-CHAP and MS-CHAPv2 send passwords in encrypted form.
     Alternative protocols for the same purpose are PAP and CHAP. In
     order to use MS-CHAP or MS-CHAPv2 with MiamiDx, MiamiSSL V2 or
     higher has to be installed.

@{b}MiamiSSL@{ub}
     Add-on to Miami and MiamiDx providing SSL and TLS support. MiamiSSL
     is available free of charge to all registered users of Miami and
     MiamiDx.

@{b}MS-CHAP@{ub}
     See "Microsoft CHAP"

@{b}MTU@{ub}
     See "Maximum Transfer Unit"

@{b}Multicast Backbone (MBone)@{ub}
     Testbed for multicasting, set up as a virtual network running on
     top of the Internet. The MBone is used to develop and test
     multicasting protocols for streaming media applications.

@{b}Multihomed computer@{ub}
     A computer that has multiple IP addresses, usually the result of
     being connected to more than one physical interface.

@{b}NCP@{ub}
     See "Network Control Protocol"

@{b}Netmask@{ub}
     32-bit number that determines the size of a physical network, i.e.
     which IP addresses are located directly on a physical network (e.g.
     Ethernet) and which have to be reached through routers.

@{b}Network Control Protocol (NCP)@{ub}
     A sub-protocol of PPP used to configure Network Protocols such as
     IP. When PPP is used in combination with TCP/IP then the NCP being
     used is IPCP.

@{b}PAP@{ub}
     See "Password Authentication Protocol"

@{b}Password Authentication Protocol (PAP)@{ub}
     A sub-protocol of PPP used to authenticate a user, i.e. to exchange
     user name and password. PAP sends passwords in cleartext, without
     encryption. Alternative protocols for the same purpose are CHAP and

@{b}Path MTU Discovery@{ub}
     A procedure that allows one end of a TCP connection to find out
     the minimum MTU across all segments of a TCP connection, i.e. the
     maximum packet size that can be sent to the other end of the TCP
     connection without causing fragmentation. In older TCP/IP stacks
     TCP has been limited to 552 or 576 bytes for non-local connections
     (a number guaranteed to be supported by all segments on the
     Internet).  Newer stacks usually support Path MTU Discovery,
     allowing TCP to determine the largest supported packet size of a
     TCP path dynamically. This often means that TCP can split up its
     payload into larger TCP packets and thus provide better
     performance.

@{b}Point-to-Point Protocol (PPP)@{ub}
     Standard for transmitting IP traffic across serial lines. PPP has
     replaced the obsolete SLIP and CSLIP standards that formerly used
     for this purpose. PPP has several sub-protocols including LCP,
     IPCP, PAP, CHAP, MS-CHAP, CBCP, and CCP.

@{b}Point-to-Point Tunneling Protocol (PPTP)@{ub}
     Microsoft's protocol for VPNs, sometimes also used for DSL or cable
     modem access. MiamiDx can act as a PPTP client, using
     miamipptp.device.

@{b}PPP@{ub}
     See "Point-to-Point Protocol"

@{b}PPP over Ethernet (PPPoE)@{ub}
     Industry standard for tunneling PPP connections across Ethernet.
     Used by some Internet service providers for DSL and cable modem
     access.  MiamiDx can act as a PPPoE client, using
     miamipppoe.device.

@{b}PPPoE@{ub}
     See "PPP over Ethernet"

@{b}PPTP@{ub}
     See "Point-to-Point Tunneling Protocol" MS-CHAP.

@{b}RArp@{ub}
     See "Reverse Address Resolution Protocol"

@{b}Reverse Address Resolution Protocol (RArp)@{ub}
     A protocol used to translate MAC addresses into IP addresses. It is
     typically used in older LAN setups to configure the IP addresses
     of hosts dynamically, from a database on a central server that
     maps MAC addresses to IP addresses. Newer LAN setups typically use
     BootP or DHCP for this purpose.

@{b}Rlogin@{ub}
     Protocol to log in to another computer across a TCP/IP network.
     Rlogin is similar to telnet, but, depending on configuration, may
     allow logins without a password check if both client and server
     are within a "trusted" environment.

@{b}Router@{ub}
     A computer which is connected to more than one physical interface
     and which forwards data between interfaces.

@{b}Secure Socket Layer (SSL)@{ub}
     Security protocol on top of the transport layer (i.e. on top of
     TCP).  SSL allows applications to authenticate the identity of a
     server and to transfer data in encrypted form. SSL is most
     commonly used with HTTP (with the combination of the two being
     refered to as HTTPS), but can also be used with some other
     application protocols. SSL exists in two versions, SSLv2 and
     SSLv3, both of which are widely used, but none of which are
     official standards. The new official standard is called TLS and is
     a slight variation of SSLv3. SSLv2, SSLv3 and TLS are supported by
     MiamiSSL.

@{b}Serial Line Internet Protocol (SLIP)@{ub}
     Obsolete standard for transmitting IP traffic across serial lines.
     SLIP has been replaced by PPP.

@{b}SLIP@{ub}
     See "Serial Line Internet Protocol"

@{b}SOCKS@{ub}
     Proxy-server protocol that allows clients to connect to a location
     outside of a LAN through a firewall or NAT server.

@{b}SSL@{ub}
     See "Secure Socket Layer"

@{b}Subnet@{ub}
     Physical network that is smaller (contains fewer IP addresses) than
     implied by the class (A/B/C) of its IP address range. The use of
     subnets requires the configuration of "subnet masks" on all hosts
     in the subnet, to define the size of the subnet.

@{b}Subnet Mask@{ub}
     Same as "netmask", except that using the term "subnet mask"
     emphasizes that the mask corresponds to a subnet, not to a default
     network (class A/B/C).

@{b}TCP@{ub}
     See "Transmission Control Protocol"

@{b}TCP for Transactions (T/TCP)@{ub}
     Variation of TCP that reduces the number of packets exchanged when
     a TCP link is created and shut down. Particularly useful for
     transaction processing (i.e. short-lived TCP connections) in order
     to improve performance.

@{b}TCP/IP@{ub}
     General term describing all protocols and mechanisms used on the
     Internet. References to "TCP/IP" usually include IP, UDP, TCP,
     ICMP, rules for IP addressing and routing, DNS, host names and
     many other things.

@{b}Telnet@{ub}
     Protocol to log in to another computer across a TCP/IP network.

@{b}TLS@{ub}
     See "Transport Layer Security"

@{b}TN3270@{ub}
     Special version of telnet that emulats IBM 3270 terminals. TN3270
     is typically used to connect to IBM AS/400 servers.

@{b}Transmission Control Protocol (TCP)@{ub}
     Transport protocol used by most Internet application. TCP provides
     a "virtual pipe" between client and server, guaranteeing data
     delivery and hiding the details if packetization from applications.

@{b}Transport Layer Security (TLS)@{ub}
     Security protocol on top of the transport layer (i.e. on top of
     TCP).  TLS is an official Internet standard and the successor of
     the older SSL protocol. TLS is supported by MiamiSSL.

@{b}T/TCP@{ub}
     See "TCP for Transactions"

@{b}UDP@{ub}
     See "User Datagram Protocol"

@{b}Universal Resource Locator (URL)@{ub}
     Global identifer to reference a piece of information (a web page, a
     file etc.) on the Internet, such as
     "http://www.foo.bar/myfile.html", typically consisting of a
     protocol identifier (e.g. "http:"), a host name and some path/file
     information.

@{b}URL@{ub}
     See "Universal Resource Locator"

@{b}User Datagram Protocol (UDP)@{ub}
     Transport protocol based on IP that allows the exchange of
     individual packets (datagram). UDP does not guarantee packet
     delivery and packets may arrive out of order.

@{b}Van Jacobson TCP Header Compression (VJC)@{ub}
     Method to compress TCP headers with PPP or CSLIP, by caching
     connection-dependent information on both ends of the serial line.
     VJC does NOT interfere with the compression in modems and
     therefore should NOT be disabled just because a modem has its own
     compression scheme.

@{b}Virtual Private Network (VPN)@{ub}
     A logical network that consists of several physically separate
     components, at different locations. These components are then
     connected together using "VPN tunnels", i.e. encrypted connections
     across the Internet. VPNs are often used to allow users to log in
     to corporate networks across the Internet. Protocols commonly used
     for VPNs are PPTP and L2TP.

@{b}VJC@{ub}
     See "Van Jacobson TCP Header Compression"

@{b}VPN@{ub}
     See "Virtual Private Network"

@EndNode

