@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." (where 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 , 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 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 to the modem, padded with spaces up to a total length of . 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<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 @{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 @{b}MiamiArp -s hostname hw_addr [temp] [pub]@{ub} Create an Arp entry for with the hardware address . 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 . @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 For you can specify an IP address or an interface name (e.g. "ppp0"). 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 [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 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 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 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 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 as input for the filter expression. An additional expression given on the command line is ignored. @{b}-i interface@{ub} Listen on (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 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 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 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 to be interpreted the specified . 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 rather than parsing and printing them out. They can later be printed with the "-r" option. Standard output is used if is "-". @{b}-x@{ub} Print each packet (minus its link level header) in hex. The smaller of the entire packet or bytes will be printed. selects which packets will be dumped. If no is given, all packets on the net will be dumped. Otherwise, only packets for which is `true' will be dumped. The syntax for 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 +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 (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