@database Miami.guide @Master Miami.texinfo @Width 72 This is the AmigaGuide file Miami.guide, produced by Makeinfo-1.55 from the input file Miami.texinfo. Documentation for Miami V2.0g (c) Copyright 1996,1997 Nordic Global Inc. All Rights Reserved. $VER: Miami.guide 2.0g (20.02.97) @Node Main "Miami.guide" @Next "NODE_DISCLAIMER" Miami ***** This is the documentation for Miami V2.0g, an integrated TCP/IP system for AmigaOS. Copyright (C) 1996,1997 Nordic Global Inc. All rights reserved. Program and documentation by Holger Kruse. @{" Disclaimer " Link "NODE_DISCLAIMER"} Legal information @{" Usage / Copying " Link "NODE_CONDITIONS"} Usage and copying conditions @{" Registration " Link "NODE_REGISTRATION"} Shareware registration @{" Introduction " Link "NODE_INTRODUCTION"} Introduction to Miami @{" Requirements " Link "NODE_REQUIREMENTS"} Required hardware and software @{" Installation " Link "NODE_INSTALLATION"} How to install Miami @{" MiamiInit " Link "NODE_MIAMIINIT"} Quick start using MiamiInit @{" MiamiInitSANA2 " Link "NODE_MIAMIINITSANAT"} Quick start using MiamiInitSANA2 @{" ToolTypes " Link "NODE_TOOLTYPES"} ToolTypes for Miami @{" Menus " Link "NODE_MENUS"} Program menus @{" Configuration " Link "NODE_CONFIGURATION"} Manual configuration options @{" Dialer Command Language " Link "NODE_DIALERLANG"} Description of the dialer @{" ARexx Interface " Link "NODE_AREXX"} Supported ARexx commands @{" Exchanging Settings " Link "NODE_EXCONFIG"} How to import/export your settings @{" Utility Programs " Link "NODE_UTILITY"} Other programs for Miami @{" Compatibility " Link "NODE_COMPATIBILITY"} Compatibility issues @{" Restrictions " Link "NODE_RESTRICTIONS"} Restrictions of the current version @{" History " Link "NODE_HISTORY"} History of Miami @{" The future " Link "NODE_FUTURE"} The future of Miami @{" Support " Link "NODE_SUPPORT"} How to get help or updates @{" Acknowledgements " Link "NODE_ACKNOWLEDGEMENTS"} Acknowledgements @EndNode @Node "NODE_DISCLAIMER" "Miami.guide/NODE_DISCLAIMER" @Next "NODE_CONDITIONS" @Prev "Main" @Toc "Main" Disclaimer ********** Miami 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 Miami AS COMPATIBLE TO THE TCP/IP STANDARD AS POSSIBLE, I CANNOT RULE OUT THE POSSIBILITY THAT Miami 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 Miami 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. Miami IS PROVIDED AS-IS. THIS MEANS I DO NOT GUARANTEE THAT Miami IS FIT FOR ANY SPECIFIC PURPOSE AND I DO NOT GUARANTEE ANY BUG FIXES, UPDATES OR HELP DURING ERROR RECOVERY. Miami 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 Miami package. Miami is NOT freely distributable, unless otherwise stated. See @{"Usage / Copying" Link "NODE_CONDITIONS"} for details. Miami relies on @{b}Magic User Interface (MUI)@{ub}. MUI is Copyright by Stefan Stuntz. Miami requires 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_CONDITIONS" "Miami.guide/NODE_CONDITIONS" @Next "NODE_REGISTRATION" @Prev "NODE_DISCLAIMER" @Toc "Main" Usage / Copying *************** Miami is shareware. In this case this means that a personalized key file is required to use the full functionality of Miami. 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 Miami 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 ! Miami 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 Miami 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 Miami program texts or documentation, unless I officially appoint you as a Miami 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 Miami archive the following conditions apply: @{b}*@{ub} The sales price must not be higher than the cost of the empty disks required for the Miami 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 Miami 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} Miami 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 Miami 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_REGISTRATION" "Miami.guide/NODE_REGISTRATION" @Next "NODE_INTRODUCTION" @Prev "NODE_CONDITIONS" @Toc "Main" Registration ************ If you often use Miami, need any of the features disabled in the demo version, or want to stay connected for more than one hour at a time, I suggest you register Miami. 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 @{b}MiamiRegister@{ub}. The registration fee is US$ 35 for a standard, `full' Miami license. It is also possible to obtain a `limited' Miami license that only works with a single Internet provider, if this provider is participating in the Miami promotion program. Registered users of ppp.device receive a discount when upgrading to Miami. The details are explained by @{b}MiamiRegister@{ub}. 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_INTRODUCTION" "Miami.guide/NODE_INTRODUCTION" @Next "NODE_REQUIREMENTS" @Prev "NODE_REGISTRATION" @Toc "Main" Introduction ************ Miami is an integrated TCP/IP 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. Miami 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 Miami 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 Miami 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 Miami without any modification and without recompiling. In addition, Miami 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 and a graphical user interface for program control and configuration. Miami 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. Unlike other general-purpose protocol stacks Miami 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 Miami. Miami also supports preconfigured settings that can be distributed by Internet providers. Miami can also be used with a non-modem connection, e.g. an Ethernet interface, an Arcnet interface, or a cable modem. Miami uses MUI 3.3 or higher for its user interface, i.e. you must have MUI installed before you can use Miami. Before starting Miami you should have a look at @{"MiamiInit" Link "NODE_MIAMIINIT"} (for PPP/SLIP connections) or at @{"MiamiInitSANA2" Link "NODE_MIAMIINITSANAT"} (for SANA-II connections). MiamiInit and MiamiInitSANA2 are programs that for most users automatically configure Miami to your needs, including dial script, authentication, IP address, DNS servers, netmask and all other configuration variables. After running MiamiInit or MiamiInitSANA2 you should run Miami, import the configuration, save the new settings, and connect to your provider. @EndNode @Node "NODE_REQUIREMENTS" "Miami.guide/NODE_REQUIREMENTS" @Next "NODE_INSTALLATION" @Prev "NODE_INTRODUCTION" @Toc "Main" Requirements ************ To use Miami you need: @{b}*@{ub} an Amiga running OS 2.04 or higher @{b}*@{ub} MUI 3.3 or higher 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 Miami 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 cable modem, and a SLIP/PPP account as described above. @{b}*@{ub} an Ethernet board connecting your machine to a local area network. Note that Miami does @{i}not@{ui} require ppp.device, appp.device, amippp.device or (rh)(c)slip.device. The protocols PPP and (C)SLIP are built into Miami, in versions more efficient and more advanced than those currently available in SANA-II devices. @EndNode @Node "NODE_INSTALLATION" "Miami.guide/NODE_INSTALLATION" @Next "NODE_MIAMIINIT" @Prev "NODE_REQUIREMENTS" @Toc "Main" Installation ************ Please run the enclosed Installer script to install Miami on your harddisk. The Installer script can be used for a new installation, for updates, to copy the files during installation and to install "in place". All files are installed into a single directory, and no system files or system directories are touched, with one exception: 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 recommended for maximum compatibility, but not absolutely required, and you can skip this step during installation. Miami comes with three different program icons: a standard icon, an icon for "Magic Workbench" and an icon in "NewIcons" style. The Installer script lets you choose the icon you prefer. @EndNode @Node "NODE_MIAMIINIT" "Miami.guide/NODE_MIAMIINIT" @Next "NODE_MIAMIINITSANAT" @Prev "NODE_INSTALLATION" @Toc "Main" MiamiInit ********* MiamiInit is a utility program that tries to determine all configuration parameters for Miami that are required for a serial connection (SLIP or PPP), and then saves a configuration file that can later be used by Miami. The first thing you should do to configure a serial line after installing the Miami package is to run MiamiInit, and go through the dialog. In the process MiamiInit dials up your Internet provider, determines all required parameters, and saves them at the end. MiamiInit only supports the most common setups at the moment. Very unusual cases such as data formats other than @{b}8N1@{ub}, non-Hayes-compliant modems or 3-wire modem cables are not supported. If you have any such unusual setup you need to configure Miami manually instead of running MiamiInit. @EndNode @Node "NODE_MIAMIINITSANAT" "Miami.guide/NODE_MIAMIINITSANAT" @Next "NODE_TOOLTYPES" @Prev "NODE_MIAMIINIT" @Toc "Main" MiamiInitSANA2 ************** MiamiInitSANA2 is a utility program that tries to determine all configuration parameters for Miami that are required for a SANA-II network connection (Ethernet, Arcnet etc.), and then saves a configuration file that can later be used by Miami. The first thing you should do to configure a SANA-II network connection after installing the Miami package is to run MiamiInitSANA2, and go through the dialog. In the process MiamiInitSANA2 accesses the SANA-II device and the local network, trying to gather all information required to configure your link. Note that depending on the configuration of your local network MiamiInitSANA2 might not be able to find all information entirely by itself. It is @{i}not@{ui} an error if MiamiInitSANA2 asks you for things like IP address or netmask during the cofiguration. This just means that there is no server on the local network which provides this kind of information to MiamiInitSANA2. In this case you need to ask your Internet provider or network administrator for the missing information. Generally, if you are setting up a very small local network, that just consists of Amigas and PCs, then you will usually have to enter most of the information yourself. On the other hand if you are connecting to an existing corporate network which has been set up to configure new machines then MiamiInitSANA2 can often find most or all of the information from a server. @EndNode @Node "NODE_TOOLTYPES" "Miami.guide/NODE_TOOLTYPES" @Next "NODE_MENUS" @Prev "NODE_MIAMIINITSANAT" @Toc "Main" ToolTypes ********* Miami supports the following ToolTypes when started from Workbench (or arguments when started from the Shell): @{b}DONTCONNECT@{ub} If you have configured Miami to automatically connect to your Internet provider whenever you start Miami, 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 Miami recognizes it as a settings file. From the Shell you can use the argument "SETTINGS=filename" to specify the settings file to load. @{b}IMPORTMIAMIINIT@{ub} The argument "IMPORTMIAMIINIT=filename" tells Miami to import a settings file from MiamiInit. @{b}IMPORTASCII@{ub} The argument "IMPORTASCII=filename" tells Miami to import an ASCII settings file (distribution format). @{b}SAVESETTINGS@{ub} The argument "SAVESETTINGS" tells Miami to save the settings as default. This argument is most useful when combined with "IMPORTMIAMIINIT" or "IMPORTASCII" to import a foreign settings file and convert it to a Miami settings file. @EndNode @Node "NODE_MENUS" "Miami.guide/NODE_MENUS" @Next "NODE_CONFIGURATION" @Prev "NODE_TOOLTYPES" @Toc "Main" Menus ***** Description of all menu items: @{b}Project/About...@{ub} Show information about Miami. @{b}Project/About MUI...@{ub} Show information about MUI (Magic User Interface). @{b}Project/Iconify@{ub} Iconify all windows of Miami. @{b}Project/Quit without hangup...@{ub} Leave Miami without hanging up the modem line first. @{b}Project/Quit...@{ub} Leave Miami. @{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 Miami. @{b}Settings/Create icon@{ub} Create a project icon for each settings file saved. @{b}Settings/Import from distribution...@{ub} Import a settings file from Miami's distribution (ASCII) format. @{b}Settings/Export from distribution...@{ub} Export the settings into a file in Miami's distribution (ASCII) format. @{b}Settings/Import from MiamiInit...@{ub} Import a settings file from MiamiInit. @{b}Settings/Import from MiamiInitSANA2...@{ub} Import a settings file from MiamiInitSANA2. @{b}Settings/MUI Settings...@{ub} Open the MUI configuration window @EndNode @Node "NODE_CONFIGURATION" "Miami.guide/NODE_CONFIGURATION" @Next "NODE_DIALERLANG" @Prev "NODE_MENUS" @Toc "Main" Configuration ************* The configuration of Miami is done completely through the graphical user interface. There are no configuration files or environment variables to edit. Description of the graphical user interface: @{" General " Link "NODE_GUI_GENERAL"} The `General' page @{" Interface " Link "NODE_GUI_INTERFACE"} The `Interface' page @{" PPP " Link "NODE_GUI_PPP"} The `PPP' page @{" Dialer " Link "NODE_GUI_DIALER"} The `Dialer' page @{" Database " Link "NODE_GUI_DATABASE"} The `Database' page @{" TCP/IP " Link "NODE_GUI_TCPIP"} The `TCP/IP' page @{" Events " Link "NODE_GUI_EVENTS"} The `Events' page @{" Modem " Link "NODE_GUI_MODEM"} The `Modem' page @{" Logging " Link "NODE_GUI_LOGGING"} The `Logging' page @{" GUI " Link "NODE_GUI_GUI"} The `GUI' page @{" Misc " Link "NODE_GUI_MISC"} Other GUI elements @EndNode @Node "NODE_GUI_GENERAL" "Miami.guide/NODE_GUI_GENERAL" @Next "NODE_GUI_INTERFACE" @Toc "NODE_CONFIGURATION" General ======= Not much here, except for the official Miami logo and a gadget to start the Miami registration program. @{" Register " Link "NODE_GUI_GENERAL_REGISTER"} The `Register' gadget @EndNode @Node "NODE_GUI_GENERAL_REGISTER" "Miami.guide/NODE_GUI_GENERAL_REGISTER" @Toc "NODE_GUI_GENERAL" Register -------- This gadget starts the program @{b}MiamiRegister@{ub}, allowing you to order a Miami license code, register Miami or upgrade your registration. @{b}MiamiRegister@{ub} has to be in the same directory as Miami, or in the standard Shell path. @EndNode @Node "NODE_GUI_INTERFACE" "Miami.guide/NODE_GUI_INTERFACE" @Next "NODE_GUI_PPP" @Prev "NODE_GUI_GENERAL" @Toc "NODE_CONFIGURATION" Interface ========= @{" Interface type " Link "NODE_GUI_INTERFACE_TYPE"} The `Interface type' gadget @{" Device / Unit " Link "NODE_GUI_INTERFACE_DEVICE"} The `Device' and `Unit' gadgets @{" Speed " Link "NODE_GUI_INTERFACE_SPEED"} The `Speed' gadget @{" Use CD " Link "NODE_GUI_INTERFACE_CD"} The `CD' gadget @{" Protocol " Link "NODE_GUI_INTERFACE_PROTOCOL"} The `Protocol' gadget @{" Flow control " Link "NODE_GUI_INTERFACE_FLOW"} The `Flow control' gadget @{" EOF mode " Link "NODE_GUI_INTERFACE_EOF"} The `EOF mode' gadget @{" Serial mode " Link "NODE_GUI_INTERFACE_SERIAL"} The `Serial mode' gadget @{" IP type / address " Link "NODE_GUI_INTERFACE_IP"} The `IP' gadgets @{" Netmask type / address " Link "NODE_GUI_INTERFACE_MASK"} The `Netmask' gadgets @{" Gateway type / address " Link "NODE_GUI_INTERFACE_GWAY"} The `Gateway' gadgets @{" Multicasts " Link "NODE_GUI_INTERFACE_MULTICASTS"} The `Multicasts' gadget @{" Mapping " Link "NODE_GUI_INTERFACE_MAPPING"} The `Mapping' gadget @{" MTU " Link "NODE_GUI_INTERFACE_MTU"} The `MTU' gadget @{" SANA-II parameters " Link "NODE_GUI_INTERFACE_STP"} The `SANA-II parameters' gadget @{" Inactivity " Link "NODE_GUI_INTERFACE_INACTIVITY"} The `Inactivity' gadgets @EndNode @Node "NODE_GUI_INTERFACE_TYPE" "Miami.guide/NODE_GUI_INTERFACE_TYPE" @Next "NODE_GUI_INTERFACE_DEVICE" @Toc "NODE_GUI_INTERFACE" Interface type -------------- This gadget selects the type of interface you want to use. The exact layout of the `Interface' page depends on the type you choose, i.e. only those gadgets that are applicable for the type of interface you chose are shown. Available types: @{b}serial (PPP/CSLIP)@{ub} The standard built-in implementation of PPP or (C)SLIP, running on top of any serial.device-compatible device. This interface type does not require a SANA-II driver. @{b}SANA-II point-to-point@{ub} A SANA-II driver for a device that connects exactly two machines, like SLIP, PPP or PLIP. @{b}SANA-II Ethernet@{ub} A SANA-II driver for an Ethernet device, like the A2065 board, the Hydra board or the Ariadne board. @{b}SANA-II standard "old" Arcnet@{ub} A SANA-II driver for an Arcnet board, like the A2060 board. This setting 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. @{b}SANA-II "new" Arcnet@{ub} A SANA-II driver for an Arcnet board, like the A2060 board. This setting 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. @{b}SANA-II other bus/ring@{ub} A SANA-II driver for a bus or ring device other than Ethernet or Arcnet. Choose this setting if your hardware can connect more than two machines, but is neither Ethernet-compatible nor Arcnet-compatible. @EndNode @Node "NODE_GUI_INTERFACE_DEVICE" "Miami.guide/NODE_GUI_INTERFACE_DEVICE" @Next "NODE_GUI_INTERFACE_SPEED" @Prev "NODE_GUI_INTERFACE_TYPE" @Toc "NODE_GUI_INTERFACE" Device / Unit ------------- @{b}For serial interfaces:@{ub} Enter the device name and unit number of the serial port to which your modem is connected. For the built-in Amiga serial port use `serial.device' `0'. For serial boards use the driver that comes with the board, e.g. `gvpser.device', with the correct unit number. Other device drivers for the internal serial port like `v34serial.device' are supported, too. You should not use `8n1.device' at this time though, because of bugs in the device. Some users have also reported problems with `BaudBandit.device'. @{b}For SANA-II interfaces:@{ub} Enter the device name and unit number of your SANA-II hardware. The unit number is 0 in most cases. @EndNode @Node "NODE_GUI_INTERFACE_SPEED" "Miami.guide/NODE_GUI_INTERFACE_SPEED" @Next "NODE_GUI_INTERFACE_CD" @Prev "NODE_GUI_INTERFACE_DEVICE" @Toc "NODE_GUI_INTERFACE" Speed ----- (This option is available for serial devices only.) Speed of your serial port. 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_GUI_INTERFACE_CD" "Miami.guide/NODE_GUI_INTERFACE_CD" @Next "NODE_GUI_INTERFACE_PROTOCOL" @Prev "NODE_GUI_INTERFACE_SPEED" @Toc "NODE_GUI_INTERFACE" Use CD ------ (This option is available for serial devices only.) If "Use CD" is activated then Miami 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 Miami 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 on the "Modem" page) 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_GUI_INTERFACE_PROTOCOL" "Miami.guide/NODE_GUI_INTERFACE_PROTOCOL" @Next "NODE_GUI_INTERFACE_FLOW" @Prev "NODE_GUI_INTERFACE_CD" @Toc "NODE_GUI_INTERFACE" Protocol -------- (This option is available for serial devices only.) The protocol your Internet provider uses. Currently supported are SLIP/CSLIP and PPP. @EndNode @Node "NODE_GUI_INTERFACE_FLOW" "Miami.guide/NODE_GUI_INTERFACE_FLOW" @Next "NODE_GUI_INTERFACE_EOF" @Prev "NODE_GUI_INTERFACE_PROTOCOL" @Toc "NODE_GUI_INTERFACE" Flow control ------------ (This option is available for serial devices only.) Miami 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_GUI_INTERFACE_EOF" "Miami.guide/NODE_GUI_INTERFACE_EOF" @Next "NODE_GUI_INTERFACE_SERIAL" @Prev "NODE_GUI_INTERFACE_FLOW" @Toc "NODE_GUI_INTERFACE" EOF mode -------- (This option is available for serial devices only.) There are two ways for Miami 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 Miami use the default setting. If you positively know whether your driver supports EOF-mode or not you can manually override the default setting by choosing "on" or "off". @EndNode @Node "NODE_GUI_INTERFACE_SERIAL" "Miami.guide/NODE_GUI_INTERFACE_SERIAL" @Next "NODE_GUI_INTERFACE_IP" @Prev "NODE_GUI_INTERFACE_EOF" @Toc "NODE_GUI_INTERFACE" Serial mode ----------- (This option is available for serial devices only.) 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 dialin 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 Miami. @EndNode @Node "NODE_GUI_INTERFACE_IP" "Miami.guide/NODE_GUI_INTERFACE_IP" @Next "NODE_GUI_INTERFACE_MASK" @Prev "NODE_GUI_INTERFACE_SERIAL" @Toc "NODE_GUI_INTERFACE" 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 Miami 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 server then choose "BootP". 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:@{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 server then choose "BootP". If the address is assigned by a local RArp server then choose "RArp". @EndNode @Node "NODE_GUI_INTERFACE_MASK" "Miami.guide/NODE_GUI_INTERFACE_MASK" @Next "NODE_GUI_INTERFACE_GWAY" @Prev "NODE_GUI_INTERFACE_IP" @Toc "NODE_GUI_INTERFACE" Netmask type / address ---------------------- (This option is available for SANA-II bus/ring devices only.) Your netmask needs to be configured correctly so that Miami 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}BootP@{ub} Miami tries to get the correct netmask from a local BootP server. @{b}ICMP@{ub} Miami tries to get the correct netmask from a local server that supports ICMP netmask discovery. @EndNode @Node "NODE_GUI_INTERFACE_GWAY" "Miami.guide/NODE_GUI_INTERFACE_GWAY" @Next "NODE_GUI_INTERFACE_MULTICASTS" @Prev "NODE_GUI_INTERFACE_MASK" @Toc "NODE_GUI_INTERFACE" Gateway type / address ---------------------- (This option is available for SANA-II bus/ring devices only.) Your default gateway needs to be configured correctly so that Miami knows where to send packets that are not intended for a machine on your local network. There are three ways of setting the gateway: @{b}static@{ub} Ask your network administrator for the correct gateway and enter it. @{b}BootP@{ub} Miami tries to get the correct gateway from a local BootP server. @{b}ICMP@{ub} Miami tries to get the correct gateway from a local server that supports ICMP router discovery. @EndNode @Node "NODE_GUI_INTERFACE_MULTICASTS" "Miami.guide/NODE_GUI_INTERFACE_MULTICASTS" @Next "NODE_GUI_INTERFACE_MAPPING" @Prev "NODE_GUI_INTERFACE_GWAY" @Toc "NODE_GUI_INTERFACE" Multicasts ---------- (This option is available in the registered version only.) Miami support Level-1 multicasting, i.e. sending, but not receiving multicast messages. If you want to use applications that need to send multicasts (none are available yet), then you need to enable Multicasts in Miami. 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. @EndNode @Node "NODE_GUI_INTERFACE_MAPPING" "Miami.guide/NODE_GUI_INTERFACE_MAPPING" @Next "NODE_GUI_INTERFACE_MTU" @Prev "NODE_GUI_INTERFACE_MULTICASTS" @Toc "NODE_GUI_INTERFACE" 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. @EndNode @Node "NODE_GUI_INTERFACE_MTU" "Miami.guide/NODE_GUI_INTERFACE_MTU" @Next "NODE_GUI_INTERFACE_STP" @Prev "NODE_GUI_INTERFACE_MAPPING" @Toc "NODE_GUI_INTERFACE" (This option is available for serial devices only.) 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. Miami always tries to negotiate the MTU you specified here, but the other side might disagree and force a different MTU value, in which case Miami 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_GUI_INTERFACE_STP" "Miami.guide/NODE_GUI_INTERFACE_STP" @Next "NODE_GUI_INTERFACE_INACTIVITY" @Prev "NODE_GUI_INTERFACE_MTU" @Toc "NODE_GUI_INTERFACE" SANA-II parameters ------------------ (This option is available for SANA-II devices only.) The gadget "SANA-II parameters" pops up a window with SANA-II link level settings for the device. These settings include @{b}*@{ub} 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'. @{b}*@{ub} The link-level packet types for IP, Arp and RArp packets. (RArp is not available with Arcnet, and Arp is not available with point-to-point devices.) @{b}*@{ub} The MTU for the device. @{b}*@{ub} The number of IORequests used for IP and Arp packets. (Arp is not available with point-to-point devices.) In most cases you should initialize all of these values to default values by clicking on "Query device" (only while Miami is offline). However you can manually override all values when necessary, e.g. if you are using a new hardware type for which Miami does not know the correct default settings. @EndNode @Node "NODE_GUI_INTERFACE_INACTIVITY" "Miami.guide/NODE_GUI_INTERFACE_INACTIVITY" @Prev "NODE_GUI_INTERFACE_STP" @Toc "NODE_GUI_INTERFACE" Inactivity ---------- Some Internet providers hang up the line if there is no activity on the line for a while to prevent users from occupying lines that are not really used. The "Inactivity" gadgets allow you to configure Miami to simulate line activity even if you are not really using the line, so your provider does not hang up. 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 (C)SLIP then choose ICMP ping. Otherwise first try PPP ping, and if your provider still hangs up try ICMP ping. The gadget on the right sets the number of minutes between successive pings. You need to experiment with that. Common values are 9 or 14, 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_GUI_PPP" "Miami.guide/NODE_GUI_PPP" @Next "NODE_GUI_DIALER" @Prev "NODE_GUI_INTERFACE" @Toc "NODE_CONFIGURATION" @{" PAP / CHAP password " Link "NODE_GUI_PPP_CHAP"} The `PAP/CHAP' gadgets @{" Callback " Link "NODE_GUI_PPP_CALLBACK"} The `Callback' gadgets @{" VJC " Link "NODE_GUI_PPP_VJC"} The `VJC' gadget @{" ACCM " Link "NODE_GUI_PPP_ACCM"} The `ACCM' gadget @{" Quick Reconnect " Link "NODE_GUI_PPP_QUICK"} The `Quick Reconnect' gadget @{" Escape " Link "NODE_GUI_PPP_ESCAPE"} The `Escape' gadget @{" Get DNS from IPCP " Link "NODE_GUI_PPP_DNSIPCP"} The `Get DNS from IPCP' gadget @{" TermReq before hangup " Link "NODE_GUI_PPP_TERMREQ"} The `TermReq before hangup' gadget @EndNode @Node "NODE_GUI_PPP_CHAP" "Miami.guide/NODE_GUI_PPP_CHAP" @Next "NODE_GUI_PPP_CALLBACK" @Toc "NODE_GUI_PPP" PAP / CHAP password ------------------- 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. @EndNode @Node "NODE_GUI_PPP_CALLBACK" "Miami.guide/NODE_GUI_PPP_CALLBACK" @Next "NODE_GUI_PPP_VJC" @Prev "NODE_GUI_PPP_CHAP" @Toc "NODE_GUI_PPP" 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 Miami to wait for a callback before giving up. @EndNode @Node "NODE_GUI_PPP_VJC" "Miami.guide/NODE_GUI_PPP_VJC" @Next "NODE_GUI_PPP_ACCM" @Prev "NODE_GUI_PPP_CALLBACK" @Toc "NODE_GUI_PPP" 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_GUI_PPP_ACCM" "Miami.guide/NODE_GUI_PPP_ACCM" @Next "NODE_GUI_PPP_QUICK" @Prev "NODE_GUI_PPP_VJC" @Toc "NODE_GUI_PPP" 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 heaxdecimal digits, or click on the popup gadgets to toggle each control character individually. @EndNode @Node "NODE_GUI_PPP_QUICK" "Miami.guide/NODE_GUI_PPP_QUICK" @Next "NODE_GUI_PPP_ESCAPE" @Prev "NODE_GUI_PPP_ACCM" @Toc "NODE_GUI_PPP" Quick Reconnect --------------- Usually Miami 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 on the "Interface" page. 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 then Miami 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. In most cases this allows you to reconnect to your provider after rebooting your Amiga. However this technique 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 "Quick Reconnect" does not work. @EndNode @Node "NODE_GUI_PPP_ESCAPE" "Miami.guide/NODE_GUI_PPP_ESCAPE" @Next "NODE_GUI_PPP_DNSIPCP" @Prev "NODE_GUI_PPP_QUICK" @Toc "NODE_GUI_PPP" 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 Miami 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 Miami also requires character escaping, then you have to configure the PPP server accordingly as well. @EndNode @Node "NODE_GUI_PPP_DNSIPCP" "Miami.guide/NODE_GUI_PPP_DNSIPCP" @Next "NODE_GUI_PPP_TERMREQ" @Prev "NODE_GUI_PPP_ESCAPE" @Toc "NODE_GUI_PPP" Get DNS from IPCP ----------------- This switch is "on" by default. This means that Miami 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 you might have to disable this option. @EndNode @Node "NODE_GUI_PPP_TERMREQ" "Miami.guide/NODE_GUI_PPP_TERMREQ" @Prev "NODE_GUI_PPP_DNSIPCP" @Toc "NODE_GUI_PPP" TermReq before Hangup --------------------- This option should normally be switched on. In this case Miami 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. @EndNode @Node "NODE_GUI_DIALER" "Miami.guide/NODE_GUI_DIALER" @Next "NODE_GUI_DATABASE" @Prev "NODE_GUI_PPP" @Toc "NODE_CONFIGURATION" Dialer ====== @{" Dial script " Link "NODE_GUI_DIALER_SCRIPT"} The `Dial script' listview @{" Phone numbers " Link "NODE_GUI_DIALER_PHONE"} The `Phone numbers' listview @{" Max Repeat " Link "NODE_GUI_DIALER_MAX"} The `Max Repeat' gadget @{" Repeat Delay " Link "NODE_GUI_DIALER_DELAY"} The `Repeat Delay' gadget @{" Redial Delay " Link "NODE_GUI_DIALER_RDELAY"} The `Redial Delay' gadget @{" Teach " Link "NODE_GUI_DIALER_TEACH"} The `Teach' gadget @{" Login ID / Password " Link "NODE_GUI_DIALER_NAME"} The `Login ID' / `Password' gadgets @{" Capture " Link "NODE_GUI_DIALER_CAPTURE"} The `Capture' gadgets @EndNode @Node "NODE_GUI_DIALER_SCRIPT" "Miami.guide/NODE_GUI_DIALER_SCRIPT" @Next "NODE_GUI_DIALER_PHONE" @Toc "NODE_GUI_DIALER" 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_DIALERLANG"}. 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_GUI_DIALER_PHONE" "Miami.guide/NODE_GUI_DIALER_PHONE" @Next "NODE_GUI_DIALER_MAX" @Prev "NODE_GUI_DIALER_SCRIPT" @Toc "NODE_GUI_DIALER" 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_GUI_DIALER_MAX" "Miami.guide/NODE_GUI_DIALER_MAX" @Next "NODE_GUI_DIALER_DELAY" @Prev "NODE_GUI_DIALER_PHONE" @Toc "NODE_GUI_DIALER" Max Repeat ---------- If no connection can be established with any of the listed phone numbers, then Miami waits for the time specified in @{"Repeat Delay" Link "NODE_GUI_DIALER_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 Miami just gives up and aborts dialing. @EndNode @Node "NODE_GUI_DIALER_DELAY" "Miami.guide/NODE_GUI_DIALER_DELAY" @Next "NODE_GUI_DIALER_RDELAY" @Prev "NODE_GUI_DIALER_MAX" @Toc "NODE_GUI_DIALER" Repeat Delay ------------ If no connection can be established with any of the listed phone number, then Miami waits for the time specified in the "Repeat Delay" gadget and then tries again, restarting with the first phone number. @EndNode @Node "NODE_GUI_DIALER_RDELAY" "Miami.guide/NODE_GUI_DIALER_RDELAY" @Next "NODE_GUI_DIALER_TEACH" @Prev "NODE_GUI_DIALER_DELAY" @Toc "NODE_GUI_DIALER" 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 Miami 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_GUI_DIALER_TEACH" "Miami.guide/NODE_GUI_DIALER_TEACH" @Next "NODE_GUI_DIALER_NAME" @Prev "NODE_GUI_DIALER_RDELAY" @Toc "NODE_GUI_DIALER" Teach ----- The "Teach" gadget starts the Miami dialer in interactive mode (i.e. without executing a dial script), records all text send by the user or received from the modem, and then tries to create a proper dial script from that. Most of the time MiamiInit is used to create a dial script, not "Teach", but if your provider changes the login procedure it might be more convenient for you to only create a new dial script (using "Teach") instead of running MiamiInit all over again. @EndNode @Node "NODE_GUI_DIALER_NAME" "Miami.guide/NODE_GUI_DIALER_NAME" @Next "NODE_GUI_DIALER_CAPTURE" @Prev "NODE_GUI_DIALER_TEACH" @Toc "NODE_GUI_DIALER" 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_GUI_DIALER_CAPTURE" "Miami.guide/NODE_GUI_DIALER_CAPTURE" @Prev "NODE_GUI_DIALER_NAME" @Toc "NODE_GUI_DIALER" Capture ------- If you activate the "Capture" checkmark gadget and enter a file name in the corresponding string gadget, then the dialer will save all data received from the modem during dialing (i.e. a complete dial log) to a file. @EndNode @Node "NODE_GUI_DATABASE" "Miami.guide/NODE_GUI_DATABASE" @Next "NODE_GUI_TCPIP" @Prev "NODE_GUI_DIALER" @Toc "NODE_CONFIGURATION" Database ======== The "Database" page is the equivalent of the files in the "db" 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 gadget 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 Miami. 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. 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 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 Miami marks all dynamically obtained DNS server addresses and your dynamic hostname as temporary. Parts of the database: @{" Protocols " Link "NODE_GUI_DATABASE_PROTOCOLS"} The `protocols' part @{" Services " Link "NODE_GUI_DATABASE_SERVICES"} The `services' part @{" Hosts " Link "NODE_GUI_DATABASE_HOSTS"} The `hosts' part @{" Networks " Link "NODE_GUI_DATABASE_NETWORKS"} The `networks' part @{" Domains " Link "NODE_GUI_DATABASE_DOMAINS"} The `domains' part @{" DNS servers " Link "NODE_GUI_DATABASE_DNSSERVERS"} The `DNS servers' part @{" InetD " Link "NODE_GUI_DATABASE_INETD"} The `InetD' part @{" users " Link "NODE_GUI_DATABASE_USERS"} The `users' part @{" groups " Link "NODE_GUI_DATABASE_GROUPS"} The `groups' part @{" Arp " Link "NODE_GUI_DATABASE_ARP"} The `Arp' part @{" IP filter " Link "NODE_GUI_DATABASE_IPFILTER"} The `IP filter' part @EndNode @Node "NODE_GUI_DATABASE_PROTOCOLS" "Miami.guide/NODE_GUI_DATABASE_PROTOCOLS" @Next "NODE_GUI_DATABASE_SERVICES" @Toc "NODE_GUI_DATABASE" Protocols --------- List of all supported protocols (relative to IP), consisting of a protocol name, a protocol ID, and an optional list of aliases. 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_GUI_DATABASE_SERVICES" "Miami.guide/NODE_GUI_DATABASE_SERVICES" @Next "NODE_GUI_DATABASE_HOSTS" @Prev "NODE_GUI_DATABASE_PROTOCOLS" @Toc "NODE_GUI_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. 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: removing one entry from this table is @{i}not@{ui} the proper way of disabling its function in InetD. If you want to disable a server in InetD then remove it from the "InetD" table, not from the "services" table. Otherwise you might get spurious errors from other applications later. @EndNode @Node "NODE_GUI_DATABASE_HOSTS" "Miami.guide/NODE_GUI_DATABASE_HOSTS" @Next "NODE_GUI_DATABASE_NETWORKS" @Prev "NODE_GUI_DATABASE_SERVICES" @Toc "NODE_GUI_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. Miami 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. @EndNode @Node "NODE_GUI_DATABASE_NETWORKS" "Miami.guide/NODE_GUI_DATABASE_NETWORKS" @Next "NODE_GUI_DATABASE_DOMAINS" @Prev "NODE_GUI_DATABASE_HOSTS" @Toc "NODE_GUI_DATABASE" Networks -------- List of all networks, consisting of a network name, a network ID, and an optional list of aliases. This table is hardly used any more, and only implemented for backwards compatibility with very old software and some diagnostic software. @EndNode @Node "NODE_GUI_DATABASE_DOMAINS" "Miami.guide/NODE_GUI_DATABASE_DOMAINS" @Next "NODE_GUI_DATABASE_DNSSERVERS" @Prev "NODE_GUI_DATABASE_NETWORKS" @Toc "NODE_GUI_DATABASE" Domains ------- List of all local domains, specified by just the domain name. 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}. @EndNode @Node "NODE_GUI_DATABASE_DNSSERVERS" "Miami.guide/NODE_GUI_DATABASE_DNSSERVERS" @Next "NODE_GUI_DATABASE_INETD" @Prev "NODE_GUI_DATABASE_DOMAINS" @Toc "NODE_GUI_DATABASE" DNS servers ----------- List of DNS servers, specified by just the IP address of the server. 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 provider. If Miami finds any DNS servers by itself when connecting it automatically adds them to this list and marks them as "temporary". @EndNode @Node "NODE_GUI_DATABASE_INETD" "Miami.guide/NODE_GUI_DATABASE_INETD" @Next "NODE_GUI_DATABASE_USERS" @Prev "NODE_GUI_DATABASE_DNSSERVERS" @Toc "NODE_GUI_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 InetD built-in to Miami 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. @EndNode @Node "NODE_GUI_DATABASE_USERS" "Miami.guide/NODE_GUI_DATABASE_USERS" @Next "NODE_GUI_DATABASE_GROUPS" @Prev "NODE_GUI_DATABASE_INETD" @Toc "NODE_GUI_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. 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. To change the password click on the "Password" popup 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 Miami for legal reasons. For more information on this please check @{"Passwords" Link "NODE_EXCONFIG_PASSWORDS"}. @EndNode @Node "NODE_GUI_DATABASE_GROUPS" "Miami.guide/NODE_GUI_DATABASE_GROUPS" @Next "NODE_GUI_DATABASE_ARP" @Prev "NODE_GUI_DATABASE_USERS" @Toc "NODE_GUI_DATABASE" Groups ------ List of groups in the system, consisting of a group name, a group ID and an optional user list. 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_GUI_DATABASE_ARP" "Miami.guide/NODE_GUI_DATABASE_ARP" @Next "NODE_GUI_DATABASE_IPFILTER" @Prev "NODE_GUI_DATABASE_GROUPS" @Toc "NODE_GUI_DATABASE" 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'). 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. @EndNode @Node "NODE_GUI_DATABASE_IPFILTER" "Miami.guide/NODE_GUI_DATABASE_IPFILTER" @Prev "NODE_GUI_DATABASE_ARP" @Toc "NODE_GUI_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 the local interface, or to create system log entries if some specific packets arrive. This allows you to implement a very rudimentary firewall, 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 a protocol (`tcp', `udp' or `*' meaning `any protocol'), a service (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), an IP address (the source IP address of the packet), a netmask (defining the range of IP addresses), and 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. @EndNode @Node "NODE_GUI_TCPIP" "Miami.guide/NODE_GUI_TCPIP" @Next "NODE_GUI_EVENTS" @Prev "NODE_GUI_DATABASE" @Toc "NODE_CONFIGURATION" TCP/IP ====== @{" Host name " Link "NODE_GUI_TCPIP_HOSTNAME"} The `Host name' group @{" Real / User name " Link "NODE_GUI_TCPIP_NAME"} The `Real name' and `User name' gadgets @{" Use ICMP " Link "NODE_GUI_TCPIP_ICMP"} The `Use ICMP' gadget @{" Use BootP " Link "NODE_GUI_TCPIP_BOOTP"} The `Use BootP' gadget @{" Verify DNS servers " Link "NODE_GUI_TCPIP_VERIFYDNS"} The `Verify DNS servers' gadget @{" Fake IP " Link "NODE_GUI_TCPIP_FAKEIP"} The `Fake IP' gadget @{" T/TCP " Link "NODE_GUI_TCPIP_TTCP"} The `T/TCP' gadget @{" Auto-add domain " Link "NODE_GUI_TCPIP_ADDDOMAIN"} The `Auto-add domain' gadget @{" Down when offline " Link "NODE_GUI_TCPIP_DOWN"} The `Down when offline' gadget @{" Ping flood protection " Link "NODE_GUI_TCPIP_PING"} The `Ping flood protection' gadget @{" Get time " Link "NODE_GUI_TCPIP_GETTIME"} The `Get time' gadgets @EndNode @Node "NODE_GUI_TCPIP_HOSTNAME" "Miami.guide/NODE_GUI_TCPIP_HOSTNAME" @Next "NODE_GUI_TCPIP_NAME" @Toc "NODE_GUI_TCPIP" Host name --------- In most cases you should switch the gadget "dynamic" on. In this case Miami automatically determines your Amiga's host name through reverse DNS lookup whenever you connect. However some providers do not support reverse DNS lookup, or assign a static host name to their users that is not listed in the DNS. In this case switch "dynamic" off and enter your host name manually. @EndNode @Node "NODE_GUI_TCPIP_NAME" "Miami.guide/NODE_GUI_TCPIP_NAME" @Next "NODE_GUI_TCPIP_ICMP" @Prev "NODE_GUI_TCPIP_HOSTNAME" @Toc "NODE_GUI_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_GUI_TCPIP_ICMP" "Miami.guide/NODE_GUI_TCPIP_ICMP" @Next "NODE_GUI_TCPIP_BOOTP" @Prev "NODE_GUI_TCPIP_NAME" @Toc "NODE_GUI_TCPIP" Use ICMP -------- If this gadget is switched on then Miami 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_GUI_TCPIP_BOOTP" "Miami.guide/NODE_GUI_TCPIP_BOOTP" @Next "NODE_GUI_TCPIP_VERIFYDNS" @Prev "NODE_GUI_TCPIP_ICMP" @Toc "NODE_GUI_TCPIP" Use BootP --------- If your provider uses dynamic IP addresses then there are different techniques for Miami 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 "BootP" is sometimes used. Alternatively the IP address can sometimes be determined from the dial log. If you used MiamiInit to configure the line then you can just leave this switch at its default setting. If you configured Miami manually then you should first switch "BootP" on, and then later try again with "BootP" switched off, and see if this still works. If Miami can find your IP addresses without BootP then you should switch "BootP" off, because it can make the connection establishment phase quicker. @EndNode @Node "NODE_GUI_TCPIP_VERIFYDNS" "Miami.guide/NODE_GUI_TCPIP_VERIFYDNS" @Next "NODE_GUI_TCPIP_FAKEIP" @Prev "NODE_GUI_TCPIP_BOOTP" @Toc "NODE_GUI_TCPIP" Verify DNS servers ------------------ Usually Miami tries to verify the correctness of the IP addresses of all DNS servers. However this can cause problems with some Internet providers if their DNS servers have a bad connectivity or do not respond to requests immediately after connection establishment. If you deactivate the "Verify DNS servers" gadget then Miami skips the DNS verification step when going online. @EndNode @Node "NODE_GUI_TCPIP_FAKEIP" "Miami.guide/NODE_GUI_TCPIP_FAKEIP" @Next "NODE_GUI_TCPIP_TTCP" @Prev "NODE_GUI_TCPIP_VERIFYDNS" @Toc "NODE_GUI_TCPIP" 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 Miami to obtain your host name by resolving the remote IP address, not your local ("fake") IP address. @EndNode @Node "NODE_GUI_TCPIP_TTCP" "Miami.guide/NODE_GUI_TCPIP_TTCP" @Next "NODE_GUI_TCPIP_ADDDOMAIN" @Prev "NODE_GUI_TCPIP_FAKEIP" @Toc "NODE_GUI_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 Miami stops working after enabling T/TCP you might have to disable this option - or switch providers. @EndNode @Node "NODE_GUI_TCPIP_ADDDOMAIN" "Miami.guide/NODE_GUI_TCPIP_ADDDOMAIN" @Next "NODE_GUI_TCPIP_DOWN" @Prev "NODE_GUI_TCPIP_TTCP" @Toc "NODE_GUI_TCPIP" Auto-add domain --------------- If this gadget is activated then Miami will automatically add your host name's domain (i.e. everything after the first '.') to Miami's "domain" database. This is not strictly required for Miami or for any software, but it can be convenient if you want to use abbreviated host names. Please see @{"The `Database' page" Link "NODE_GUI_DATABASE"} for more details on the meaning of the "domain" database. @EndNode @Node "NODE_GUI_TCPIP_DOWN" "Miami.guide/NODE_GUI_TCPIP_DOWN" @Next "NODE_GUI_TCPIP_PING" @Prev "NODE_GUI_TCPIP_ADDDOMAIN" @Toc "NODE_GUI_TCPIP" Down when offline ----------------- (This option is available in the registered version only.) In the unregistered version Miami always disconnects all active TCP sessions when the interface goes offline. In the registered version Miami keeps TCP sessions alive in such a situation. This has the advantage that you might be able to reconnect quickly and to continue to use your TCP session. The drawback of keeping TCP sessions alive when the interface goes offline is that applications cannot detect whether Miami is online or offline, i.e. their connection attempts would just time out when Miami is offline, but not generate any other error message. If you don't like this behavior and would prefer Miami to generate proper errors when the interface is offline then enable this option. @EndNode @Node "NODE_GUI_TCPIP_PING" "Miami.guide/NODE_GUI_TCPIP_PING" @Next "NODE_GUI_TCPIP_GETTIME" @Prev "NODE_GUI_TCPIP_DOWN" @Toc "NODE_GUI_TCPIP" Ping flood protection --------------------- (This option is available in the registered version only.) Miami 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), Miami 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 Miami 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 Miami to prevent that user from wasting your modem bandwidth. That would only be possible by a filter at your Internet provider. @EndNode @Node "NODE_GUI_TCPIP_GETTIME" "Miami.guide/NODE_GUI_TCPIP_GETTIME" @Prev "NODE_GUI_TCPIP_PING" @Toc "NODE_GUI_TCPIP" Get time -------- 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 "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. If you use this feature you need to make sure that your "ENV:TZ" variable is set correctly, i.e. usually to something like "EST5", or to "EST4EDT" during daylight savings time. This is important, because the server transmits the time in GMT (UTC) format, and Miami needs to adjust it to your local time zone. @EndNode @Node "NODE_GUI_EVENTS" "Miami.guide/NODE_GUI_EVENTS" @Next "NODE_GUI_MODEM" @Prev "NODE_GUI_TCPIP" @Toc "NODE_CONFIGURATION" Events ====== Miami allows you to react in various ways to events such as offline, online etc., by executing an ARexx or Shell script, iconifying the Miami window etc. The specific events Miami 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. Miami 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@{ub} iconify the Miami window @{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 Miami 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. 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_GUI_MODEM" "Miami.guide/NODE_GUI_MODEM" @Next "NODE_GUI_LOGGING" @Prev "NODE_GUI_EVENTS" @Toc "NODE_CONFIGURATION" Modem ===== @{" Init String " Link "NODE_GUI_MODEM_INIT"} The `Init String' gadget @{" Exit String " Link "NODE_GUI_MODEM_EXIT"} The `Exit String' gadget @{" Dial prefix " Link "NODE_GUI_MODEM_PREFIX"} The `Dial prefix' gadget @{" Dial suffix " Link "NODE_GUI_MODEM_SUFFIX"} The `Dial suffix' gadget @{" Null modem " Link "NODE_GUI_MODEM_NULLMODEM"} The `Null modem' gadget @EndNode @Node "NODE_GUI_MODEM_INIT" "Miami.guide/NODE_GUI_MODEM_INIT" @Next "NODE_GUI_MODEM_EXIT" @Toc "NODE_GUI_MODEM" Init String ----------- The initialization string for your modem, usually set by MiamiInit. @EndNode @Node "NODE_GUI_MODEM_EXIT" "Miami.guide/NODE_GUI_MODEM_EXIT" @Next "NODE_GUI_MODEM_PREFIX" @Prev "NODE_GUI_MODEM_INIT" @Toc "NODE_GUI_MODEM" Exit String ----------- The string sent to your modem when Miami 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 Miami exits. @EndNode @Node "NODE_GUI_MODEM_PREFIX" "Miami.guide/NODE_GUI_MODEM_PREFIX" @Next "NODE_GUI_MODEM_SUFFIX" @Prev "NODE_GUI_MODEM_EXIT" @Toc "NODE_GUI_MODEM" Dial prefix ----------- The command your modem uses for dialing, i.e. the string prepended to the phone number. This is usually "ATDT" or "ATDP". @EndNode @Node "NODE_GUI_MODEM_SUFFIX" "Miami.guide/NODE_GUI_MODEM_SUFFIX" @Next "NODE_GUI_MODEM_NULLMODEM" @Prev "NODE_GUI_MODEM_PREFIX" @Toc "NODE_GUI_MODEM" 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_GUI_MODEM_NULLMODEM" "Miami.guide/NODE_GUI_MODEM_NULLMODEM" @Prev "NODE_GUI_MODEM_SUFFIX" @Toc "NODE_GUI_MODEM" Null modem ---------- Miami 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 Miami will not wait for any responses such as "OK" or "CONNECT". With "null-modem" activated the meaning of the "Use CD" gadget on the "Interface" page 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. Miami 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 Miami), then you should activate the "Use CD" gadget. Miami will then completely bypass any dial script and immediately proceed with the protocol negotiation. @EndNode @Node "NODE_GUI_LOGGING" "Miami.guide/NODE_GUI_LOGGING" @Next "NODE_GUI_GUI" @Prev "NODE_GUI_MODEM" @Toc "NODE_CONFIGURATION" Logging ======= @{" Console " Link "NODE_GUI_LOGGING_CONSOLE"} The `Console' gadget @{" File " Link "NODE_GUI_LOGGING_FILE"} The `File' gadget @{" Use syslog.library " Link "NODE_GUI_LOGGING_SYSLOG"} The `Use syslog.library' gadget @{" Phonelog " Link "NODE_GUI_LOGGING_PHONE"} The `Phonelog' gadgets @EndNode @Node "NODE_GUI_LOGGING_CONSOLE" "Miami.guide/NODE_GUI_LOGGING_CONSOLE" @Next "NODE_GUI_LOGGING_FILE" @Toc "NODE_GUI_LOGGING" Console ------- In this gadget you can specify the AmigaDOS stream name of the console window that Miami 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_GUI_LOGGING_FILE" "Miami.guide/NODE_GUI_LOGGING_FILE" @Next "NODE_GUI_LOGGING_SYSLOG" @Prev "NODE_GUI_LOGGING_CONSOLE" @Toc "NODE_GUI_LOGGING" In this gadget you can specify the AmigaDOS file name of the file where Miami stores system log messages. If the file already exists then Miami appends to this file, i.e. old file contents are not deleted. @EndNode @Node "NODE_GUI_LOGGING_SYSLOG" "Miami.guide/NODE_GUI_LOGGING_SYSLOG" @Next "NODE_GUI_LOGGING_PHONE" @Prev "NODE_GUI_LOGGING_FILE" @Toc "NODE_GUI_LOGGING" Use syslog.library ------------------ If you enable this gadget then Miami tries to access syslog.library for its system log. syslog.library is part of the SysLog package by Petri Nordlund. @EndNode @Node "NODE_GUI_LOGGING_PHONE" "Miami.guide/NODE_GUI_LOGGING_PHONE" @Prev "NODE_GUI_LOGGING_SYSLOG" @Toc "NODE_GUI_LOGGING" Phonelog -------- Miami can log any online and offline events in order to assist in phone bill management. The two "Phonebill" gadgets let you enable phone logging and specify the name of a file to which Miami appends billing records. At the moment only ASCII format is supported, with records as follows: Online: 27.07.1996 17:48:11 (5551234) Passive offline: 27.07.1996 17:48:11 Active offline: 27.07.1996 17:48:11 Reconnect: 27.07.1996 17:48:11 The "Online" record contains the phone number that was dialed in "()". "Reconnect" occurs when Miami 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_GUI_GUI" "Miami.guide/NODE_GUI_GUI" @Next "NODE_GUI_MISC" @Prev "NODE_GUI_LOGGING" @Toc "NODE_CONFIGURATION" @{" Quit requester " Link "NODE_GUI_GUI_REQQUIT"} The `Quit requester' gadgets @{" Offline requester " Link "NODE_GUI_GUI_REQOFFLINE"} The `Offline requester' gadget @{" Error requester " Link "NODE_GUI_GUI_REQERRORS"} The `Error requester' gadget @{" Dialer " Link "NODE_GUI_GUI_DIALER"} The `Dialer' gadgets @EndNode @Node "NODE_GUI_GUI_REQQUIT" "Miami.guide/NODE_GUI_GUI_REQQUIT" @Next "NODE_GUI_GUI_REQOFFLINE" @Toc "NODE_GUI_GUI" Quit requester -------------- You can configure when Miami shall display a `Quit requester': @{b}*@{ub} always @{b}*@{ub} when programs that use Miami are still running. @{b}*@{ub} when Miami is online or combinations of the above. @EndNode @Node "NODE_GUI_GUI_REQOFFLINE" "Miami.guide/NODE_GUI_GUI_REQOFFLINE" @Next "NODE_GUI_GUI_REQERRORS" @Prev "NODE_GUI_GUI_REQQUIT" @Toc "NODE_GUI_GUI" Offline requester ----------------- If you activate this checkmark then Miami asks you before going offline. @EndNode @Node "NODE_GUI_GUI_REQERRORS" "Miami.guide/NODE_GUI_GUI_REQERRORS" @Next "NODE_GUI_GUI_DIALER" @Prev "NODE_GUI_GUI_REQOFFLINE" @Toc "NODE_GUI_GUI" Error requester --------------- Normally Miami 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 Miami does not display an error requester. @EndNode @Node "NODE_GUI_GUI_DIALER" "Miami.guide/NODE_GUI_GUI_DIALER" @Prev "NODE_GUI_GUI_REQERRORS" @Toc "NODE_GUI_GUI" 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 Miami whether you want Miami to activate dial windows and error requesters when they pop up. @EndNode @Node "NODE_GUI_MISC" "Miami.guide/NODE_GUI_MISC" @Prev "NODE_GUI_GUI" @Toc "NODE_CONFIGURATION" There are three more gadgets in Miami that are not described in any of the previous sections: @{b}*@{ub} "Online": Causes Miami to start dialing and try to go online. @{b}*@{ub} "Offline": Causes Miami to hang up the line and go offline. @{b}*@{ub} A listview gadget on the left side of the Miami window, that is used to select one of the configuration pages. @EndNode @Node "NODE_DIALERLANG" "Miami.guide/NODE_DIALERLANG" @Next "NODE_AREXX" @Prev "NODE_CONFIGURATION" @Toc "Main" Dialer Command Language *********************** The following commands are supported by the dialer: @{b}ABORT "text1","text2",...@{ub} Specify a list of texts that cause Miami 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 Miami 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 Miami 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. Miami 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}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, ABORT "NO CARRIER",TIMEOUT This means that Miami 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_AREXX" "Miami.guide/NODE_AREXX" @Next "NODE_EXCONFIG" @Prev "NODE_DIALERLANG" @Toc "Main" ARexx Interface *************** The name of the Miami ARexx port is "MIAMI.1". At the moment Miami 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 Miami to re-read the file "ENVARC:MiamiChangeDB" to update the settings. Please see @{"Client settings" Link "NODE_EXCONFIG_CLIENTS"} for more details how to use this feature. @{b}GETONLINETIME@{ub} Returns the number of seconds Miami has been online in the `result' variable. @{b}GETSETTINGSNAME@{ub} Returns the file name of the current settings file in the result variable. @{b}ISONLINE@{ub} Checks if Miami is online and sets the error code ("RC") accordingly. 1 means: Miami is online. 0 means: Miami is offline. @{b}LOADSETTINGS file/a@{ub} Loads the specified settings file. @{b}OFFLINE@{ub} Hang up and go offline. Same as clicking on the "Offline" gadget. @{b}ONLINE@{ub} Attempt to go online. Same as clicking on the "Online" gadget. @EndNode @Node "NODE_EXCONFIG" "Miami.guide/NODE_EXCONFIG" @Next "NODE_UTILITY" @Prev "NODE_AREXX" @Toc "Main" Exchanging Settings ******************* The Miami settings are saved in an IFF file in a format that is currently intentionally undocumented. However Miami allows you to import and export settings in a variety of ways: @{" Distribution format " Link "NODE_EXCONFIG_DIST"} Importing/exporting settings for distribution @{" Exchanging passwords " Link "NODE_EXCONFIG_PASSWORDS"} Exchanging password files @{" Client settings " Link "NODE_EXCONFIG_CLIENTS"} Custom settings for some clients @EndNode @Node "NODE_EXCONFIG_DIST" "Miami.guide/NODE_EXCONFIG_DIST" @Next "NODE_EXCONFIG_PASSWORDS" @Toc "NODE_EXCONFIG" Distribution format =================== Miami allows you to export settings into an ASCII format that is suitable for distribution, e.g. to upload it to Aminet, or to give it to other users who have accounts with the same Internet provider. It can also be used by Internet providers to preconfigure complete Miami settings for new user. The ASCII file format contains a header, followed by a variable number of parameters. When exporting files Miami only includes those parameters that are related to the provider, but not those that are related to the individual user's system setup or that are security-relevant in any way. This means you can safely export your settings and give the file to other user, without compromising sensitive information like passwords. When importing files Miami does support user-related information like passwords though, so providers can write Installer scripts which ask the user for his login id and password, and which then create an ASCII settings file for Miami that contains @{i}all@{ui} information required by Miami. To get an idea how the ASCII file looks just export your current settings to ASCII. The general format is @{b}*@{ub} a 2-line header. Each line starts with a "$" sign. Do not modify this header. @{b}*@{ub} a variable number of lines starting with a ";". These lines are comments and can be edited freely. @{b}*@{ub} a variable number of lines that specify parameters. Most parameters are specified in a single line. These lines look like this: PARAMETER=value Some parameters (e.g. the dial script) require several lines. In this case the format is as follows: PARAMETER=% first value second value third value % This means a single "%" indicates a multi-line parameter, and another "%" as the only character on a line indicates the end of the list of values. The order of parameters within the file is arbitrary. You should not make any assumptions that Miami stores parameters in a specific order. List of supported parameters: A (m) indicates a multi-line parameter. A (i) indicates that the parameter is only imported, but never exported. A (r) indicates that this feature is only available in the registered version, and ignored in the unregistered version. "(m)", "(i)" and "(r)" are not actually part of the ASCII file. Values indicated as "A / B" means that the value is a single character, either "A" or "B". @{b}DEVNAME= (i)@{ub} devicename @{b}UNIT= (i)@{ub} device unit number @{b}BAUD= (i)@{ub} serial port speed @{b}PROTOCOL=@{ub} P / S (ppp or slip) @{b}FLOWCONTROL= (i)@{ub} H / S (hardware (RTS/CTS) or software (Xon/Xoff) handshaking) @{b}EOFMODE= (i)@{ub} Y / N / A (yes / no / auto) @{b}SERMODE=@{ub} 8N1 / 7E1 / 7O1 @{b}MTU=@{ub} integer @{b}IPTYPE=@{ub} D / S (dynamic or static) @{b}IP=@{ub} 1.2.3.4 @{b}CD= (i)@{ub} Y / N (Use CD) @{b}BOOTP=@{ub} Y / N (Use BootP) @{b}INACTIVITY=@{ub} N / I / P (inactivity type: none, ICMP, PPP) @{b}INACTIVITYDELAY=@{ub} minutes @{b}PAPNAME= (i)@{ub} username @{b}PAPPWD= (i)@{ub} password @{b}PAPSAME=@{ub} Y / N @{b}CALLBACKTYPE= (r)@{ub} NONE / CBCPFIXED / CBCPVARIABLE @{b}CALLBACKPHONE= (i) (r)@{ub} phone_number @{b}CALLBACKMINDELAY= (r)@{ub} integer @{b}CALLBACKMAXDELAY= (r)@{ub} integer @{b}ACCM=@{ub} 000a0000 @{b}VJC=@{ub} Y / N @{b}QUICKRECONNECT=@{ub} Y / N @{b}TERMREQ=@{ub} Y / N @{b}DIALNAME= (i)@{ub} login id @{b}DIALPWD= (i)@{ub} password @{b}INITSTRING= (i)@{ub} modem_init_string @{b}DIALPREFIX= (i)@{ub} dial_prefix @{b}DIALSUFFIX= (i)@{ub} dial_suffix @{b}DIALSCRIPT= (m)@{ub} dial_script @{b}DIALNUMBERS= (i)(m)@{ub} phone_numbers @{b}DIALMAXREPEAT=@{ub} maxrepeat @{b}DIALREPEATDELAY=@{ub} repeatdelay @{b}DIALREDIALDELAY=@{ub} redialdelay @{b}HOSTDYNAMIC=@{ub} Y / N (host name dynamic: yes / no) @{b}HOSTNAME= (i)@{ub} hostname @{b}REALNAME= (i)@{ub} real_name @{b}USERNAME= (i)@{ub} user_name @{b}DOICMP=@{ub} Y / N @{b}FAKEIP=@{ub} Y / N @{b}TTCP= (r)@{ub} Y / N @{b}DBHOSTS= (m)@{ub} host_database @{b}DBNETWORKS= (m)@{ub} network_database @{b}DBDOMAINS= (m)@{ub} domain_database @{b}DBDNSSERVERS= (m)@{ub} dns_servers_database @EndNode @Node "NODE_EXCONFIG_PASSWORDS" "Miami.guide/NODE_EXCONFIG_PASSWORDS" @Next "NODE_EXCONFIG_CLIENTS" @Prev "NODE_EXCONFIG_DIST" @Toc "NODE_EXCONFIG" Exchanging passwords ==================== Miami 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 Miami. 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 Miami things would have been even worse: since I am developing Miami within the US (not in Finland like NSDi) I would not have been allowed to send Miami to @{i}anybody@{ui} outside of the US, regardless of the way I distribute it. I therefore decided not to use DES in Miami, but to use a different encryption algorithm that is not subject to US export restrictions. Miami 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 Miami to and from the US, to upload Miami to Aminet sites and other ftp sites, and to use Miami 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_EXCONFIG_CLIENTS" "Miami.guide/NODE_EXCONFIG_CLIENTS" @Prev "NODE_EXCONFIG_PASSWORDS" @Toc "NODE_EXCONFIG" 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 Miami 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 Miami 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 Miami is started it automatically reads the contents of this file (if it exists), updates the settings, and saves the resulting settings. @{b}*@{ub} If Miami is running when the client is installed and you want Miami to update its settings immediately you should send the "CHANGEDB" ARexx command to Miami after modifying the above file. To summarize: In your Installer scripts you should have statements as follows to automatically configure Miami for your client: echo >>ENVARC:MiamiChangeDB "ADD services ntalk 518/udp" rx "address MIAMI.1;CHANGEDB" If Miami is running it updates the settings immediately. Otherwise Miami picks up the changes the next time it is started. @EndNode @Node "NODE_UTILITY" "Miami.guide/NODE_UTILITY" @Next "NODE_COMPATIBILITY" @Prev "NODE_EXCONFIG" @Toc "Main" Utility Programs **************** @{" MiamiArp " Link "NODE_UTILITY_ARP"} MiamiArp @{" MiamiFinger " Link "NODE_UTILITY_FINGER"} MiamiFinger @{" MiamiIfConfig " Link "NODE_UTILITY_IFCONFIG"} MiamiIfConfig @{" MiamiNetStat " Link "NODE_UTILITY_NETSTAT"} MiamiNetStat @{" MiamiPing " Link "NODE_UTILITY_PING"} MiamiPing @{" MiamiResolve " Link "NODE_UTILITY_RESOLVE"} MiamiResolve @{" MiamiRoute " Link "NODE_UTILITY_ROUTE"} MiamiRoute @{" MiamiSysCtl " Link "NODE_UTILITY_SYSCTL"} MiamiSysCtl @{" MiamiTCPDump " Link "NODE_UTILITY_TCPDUMP"} MiamiTCPDump @{" MiamiTraceRoute " Link "NODE_UTILITY_TRACEROUTE"} MiamiTraceRoute @EndNode @Node "NODE_UTILITY_ARP" "Miami.guide/NODE_UTILITY_ARP" @Next "NODE_UTILITY_FINGER" @Toc "NODE_UTILITY" MiamiArp ======== Address resolution display and control Usage: @{b}arp hostname@{ub} Display current Arp entry for @{b}arp [-n] -a@{ub} Display all of the current Arp entries. If "-n" is specified then all entries are listed numerically instead of symbolically. @{b}arp -d hostname@{ub} Delete arp entry for @{b}arp -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}arp -f filename@{ub} Read and execute commands from the file . @EndNode @Node "NODE_UTILITY_FINGER" "Miami.guide/NODE_UTILITY_FINGER" @Next "NODE_UTILITY_IFCONFIG" @Prev "NODE_UTILITY_ARP" @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_IFCONFIG" "Miami.guide/NODE_UTILITY_IFCONFIG" @Next "NODE_UTILITY_NETSTAT" @Prev "NODE_UTILITY_FINGER" @Toc "NODE_UTILITY" MiamiIfConfig ============= Configure network interface parameters Note: most of the options of MiamiIfConfig should @{i}not@{ui} be used with Miami at this time, because Miami 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} Currently either "lo0" or "mi0" @{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. This has no effect for a single-interface stack like Miami. @{b}arp/-arp@{ub} Enable/disable Arp for this interface. This option should not be used with Miami. Use the Miami 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 Miami. @EndNode @Node "NODE_UTILITY_NETSTAT" "Miami.guide/NODE_UTILITY_NETSTAT" @Next "NODE_UTILITY_PING" @Prev "NODE_UTILITY_IFCONFIG" @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 [-AaDnN] [-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 [-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 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 family "inet" is currently recongized. @{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}-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}-s@{ub} Show per-protocol statistics. If this option is repeated, counters with a value of zero are suppressed. @{b}-r@{ub} Show the routing tables. When "-s" is also present, show routing statistics instead. The default display, for active 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. 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 (currently unused). @{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 Miami only supports two interfaces: @{b}lo0@{ub} The local loopback interface @{b}mi0@{ub} The PPP/(C)SLIP interface using the interface driver built into Miami, or the current SANA-II interface. @EndNode @Node "NODE_UTILITY_PING" "Miami.guide/NODE_UTILITY_PING" @Next "NODE_UTILITY_RESOLVE" @Prev "NODE_UTILITY_NETSTAT" @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_RESOLVE" "Miami.guide/NODE_UTILITY_RESOLVE" @Next "NODE_UTILITY_ROUTE" @Prev "NODE_UTILITY_PING" @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. @EndNode @Node "NODE_UTILITY_ROUTE" "Miami.guide/NODE_UTILITY_ROUTE" @Next "NODE_UTILITY_SYSCTL" @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 Miami's standard routes. Unless you repair this manually afterwards you will have to restart Miami 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 a single-interface protocol stack like Miami, and very complex and difficult to use. For a complete discussion 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_SYSCTL" "Miami.guide/NODE_UTILITY_SYSCTL" @Next "NODE_UTILITY_TCPDUMP" @Prev "NODE_UTILITY_ROUTE" @Toc "NODE_UTILITY" MiamiSysCtl =========== MiamiSysCtl lets you examine and change some of Miami's internal variables. Usage: @{b}MiamiSysCtl [-n] variable@{ub} Examine the value of a variable. @{b}MiamiSysCtl [-n] -w variable=value@{ub} Change the value of a variable. @{b}MiamiSysCtl [-n] -a@{ub} Show a list of all variables. @{b}MiamiSysCtl [-n] -A@{ub} Show a list of all variables, plus additional information for domains not accessible through MiamiSysCtl. Options: @{b}-n@{ub} Show numerical output only. Explanation of all variables: @{b}net.inet.ip.forwarding/redirect@{ub} These options have no meaning on a single-interface stack like Miami. @{b}net.inet.ip.ttl@{ub} Controls the default ttl (time-to-live) for packets Miami 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. @{b}net.inet.op.sourceroute@{ub} Controls the behavior for packets that contain an IP source route. This option is only important for routers. @{b}net.inet.icmp.maskrepl@{ub} Controls whether Miami 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 MiamiInitSANA2 or Miami will be able to automatically find the correct netmask from ICMP. @{b}net.inet.tcp.rfc1323@{ub} Enables RFC1323 TCP extensions. These extensions collide with PPP/SLIP-VJC, so they should only be enabled for bus interfaces, not for point-to-point interfaces. @{b}net.inet.tcp.rfc1644@{ub} Enables T/TCP. @{b}net.inet.tcp.mssdflt@{ub} Sets the default maximum segment size for TCP. If your interface has an MTU larger than 552 then you might want to increase this value to make better use of Path MTU Discovery. @{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.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 Miami's built-in DNS cache. @{b}dns.cache.flush@{ub} Settings this option to 1 flushes Miami's built-in DNS cache. @{b}inetd.retrytime/toomany/cntintvl/maxbuiltin@{ub} These options control InetD's built-in SYN flood protection. If you are running a very busy web server you might want to adjust these parameters (in particular "toomany") so clients do not get spurious error messages if your machine is overloaded. @{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. @EndNode @Node "NODE_UTILITY_TCPDUMP" "Miami.guide/NODE_UTILITY_TCPDUMP" @Next "NODE_UTILITY_TRACEROUTE" @Prev "NODE_UTILITY_SYSCTL" @Toc "NODE_UTILITY" MiamiTCPDump ============ MiamiTCPDump allows you to dump traffic on a network after filtering Usage: MiamiTCPDump [-adflnNOqStvx] [-c count] [-F file] [-i interface] [-r file] [-s snaplen] [-T type] [-w file] [expression] Options: @{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 (currently "lo0" or "mi0"). 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. Currently the result of this search is always "mi0". @{b}-l@{ub} Make stdout line buffered. Useful if you want to see the data while capturing it. @{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}-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_TRACEROUTE" "Miami.guide/NODE_UTILITY_TRACEROUTE" @Prev "NODE_UTILITY_TCPDUMP" @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_COMPATIBILITY" "Miami.guide/NODE_COMPATIBILITY" @Next "NODE_RESTRICTIONS" @Prev "NODE_UTILITY" @Toc "Main" Compatibility ************* So far Miami 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 Miami. This is because that version of "telnet" uses some non-documented features of "TCP:" that cannot be emulated by Miami. There are two solutions to this: @{b}*@{ub} Use a different version of telnet, e.g. the version available from Aminet in comm/tcp, a terminal program together with telser.device, or "napsaterm" in telnet-mode. A graphical telnet client that works well with Miami is expected to be available soon. @{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 Miami. "telnet" will then use the AmiTCP version of "TCP:" (still accessing the Miami TCP/IP stack, of course) instead of the version of "TCP:" built in to Miami. @EndNode @Node "NODE_RESTRICTIONS" "Miami.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 GUI 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} The utility programs MiamiIfConfig, MiamiRoute, MiamiSysCtl and MiamiTCPDump, and the libraries miamibpf.library and miamipcap.library cannot be used. @EndNode @Node "NODE_HISTORY" "Miami.guide/NODE_HISTORY" @Next "NODE_FUTURE" @Prev "NODE_RESTRICTIONS" @Toc "Main" History ******* @{b}Version 2.0g@{ub} intermediate public release version @{b}*@{ub} Made a few more adjustments to MiamiInitSANA2 and Miami. iwan.device and ciwan.device might work now - or they might not... @{b}*@{ub} MiamiAirport would crash if a SANA-II connection was stopped after reading the config file for a serial connection - fixed. @{b}*@{ub} Some ToolTypes mysteriously did not work when Miami was started from Workbench - should be fixed now... @{b}*@{ub} Bumped all catalog version numbers to 7 in preparation for localization. @{b}Version 2.0f@{ub} intermediate public release version @{b}*@{ub} MiamiTraceRoute would crash on 68000/010 machines - fixed. @{b}*@{ub} Fixed another case of `hang during quit' that occured when Miami was told to quit while a program was sending data to the TCP: dos device. @{b}*@{ub} Added option IDEBUG to MiamiInitSANA2. @{b}*@{ub} Again removed fossil.device from the list of EOF-mode-compatible devices. @{b}*@{ub} Improved the workaround to deal with buggy Linux servers if T/TCP is used. Now Miami only sends SFP packets to those host which have previously agreed to negotiate TAO. If you have had problems with T/TCP and Voyager-NG then try again now. @{b}*@{ub} Added NSD checks to Miami, MiamiInit and MiamiInitSANA2 when NSDPatch is running. @{b}*@{ub} After PPP-callback there was a chance for Miami to accidentally skip part of the ppp reinitialization, causing Enforcer/Poolwatch hits and other problems - fixed. @{b}Version 2.0e@{ub} intermediate public release version @{b}*@{ub} Some more minor changes in inetd. @{b}*@{ub} MiamiNetStat restarted the output after a Ctrl-C - fixed. @{b}*@{ub} Added ToolType "DISABLECHAP" to manually disable CHAP to support some providers with defective PPP configs. Sigh... @{b}*@{ub} The AppIcon now supports drag&drop for settings files. @{b}*@{ub} Miami now reacts much faster to clicks on the "Cancel" gadget when resetting the modem. @{b}*@{ub} Many changes in the cleanup code. Lockups due to "stuck" or misbehaving clients should no longer occur. @{b}Version 2.0d@{ub} intermediate public release version @{b}*@{ub} Fixed a bug in MiamiPing that could cause an endless loop when reporting statistics. @{b}Version 2.0c@{ub} intermediate public release version @{b}*@{ub} All built-in inetd services now use a 2-minute timeout during receiving and sending to prevent a malicious caller from tying up resources indefinitely. @{b}*@{ub} Increased the stack size of "Miami Airport". This should prevent the crashes some users reported after a PPP callback. @{b}Version 2.0b@{ub} intermediate public release version @{b}*@{ub} Added MiamiArp back to the distribution. @{b}*@{ub} Fixed a few minor bugs in Installer script. @{b}*@{ub} The "dial next" function was broken when a non-zero "redial delay" was used. @{b}*@{ub} Added some more of the new features to the im/export list of the distribution file format. @{b}*@{ub} A "dial next" and some other functions could cause crashes when used within "Teach" - fixed. @{b}*@{ub} A non-zero "redial delay" disabled "repeat delay" - fixed. @{b}Version 2.0a@{ub} Intermediate public release version @{b}*@{ub} Fixed a bug in one of the icons. @{b}Version 2.0@{ub} sixth public release version @{b}*@{ub} Implemented support for T/TCP in the kernel. @{b}*@{ub} Added support for T/TCP in the identd, daytime and time services of the built-in InetD. @{b}*@{ub} Added SANA-II support for point-to-point devices and bus devices. @{b}*@{ub} Added support for Level-1 Multicasting. @{b}*@{ub} Fixed a bug in MiamiNetStat in the way IP addresses were resolved. @{b}*@{ub} Miami ignored the last character specified in the PPP "escape" list - fixed. @{b}*@{ub} Added text frames around the program pages. @{b}*@{ub} The built-in DNS cache now uses the TTL field to expire cache entries. @{b}*@{ub} Slight change to PPP state machine to improve the timing of static IP negotiation when PAP/CHAP is used. @{b}*@{ub} Added option "Down when offline" to mark interface and route as down when Miami goes offline. @{b}*@{ub} Datagrams with a size between (windowsize-35) and (windowsize) were not sent correctly - fixed. @{b}*@{ub} Recompiled with SAS/C 6.57. @{b}*@{ub} Added "NO DIALTONE" to the default dial script as a synonym for "NO DIAL TONE". @{b}*@{ub} Miami now adds a trailing '/' to the user's home directory when necessary. @{b}*@{ub} There was an incompatibility in the way 4.4BSD handles socket flags compared to 4.3, causing AWS to behave incorrectly - fixed. @{b}*@{ub} Fixed an incompatibility between the DNS resolver and some versions of named, that could cause all unknown host names to be "resolved" to some pseudo-random IP address. @{b}*@{ub} Since version 1.1 Miami would incorrectly terminate TCP connections when hanging up the line even in the registered version - fixed. @{b}*@{ub} The built-in identd now only reports the user name on connections that actually exist, and reports "UNIX" as the operating system. These changes were required for compatibility with newer versions of ircd. Identd should now be fully RFC-compliant. @{b}*@{ub} Changing an internal InetD entry to an external one did not always work if done when Miami was online - fixed. @{b}*@{ub} Dialer commands are case-insensitive now, as they always should have been. @{b}*@{ub} MiamiRegister now saves the registration file even if it was sent correctly - in case someone wants to retransmit it later. @{b}*@{ub} Implemented Path MTU Discovery in the Miami TCP/IP kernel. @{b}*@{ub} Increased default TCP window size from 8kB to 16kB like most other recent 4.4BSD implementations have done. @{b}*@{ub} Added a MUI ID to the busy window so the MUI snapshot function works for it. @{b}*@{ub} Added option "-D" to MiamiNetStat to display the amount of data sent across an established TCP connection. @{b}*@{ub} Bug fix in built-in InetD: fingerd and identd did not always clean up properly if the client closed the connection before sending any data. This bug was already partially fixed in version 1.1d. @{b}*@{ub} MiamiInit now adds a "\\r" to the end of the modem init string if the user forgets to do so. @{b}*@{ub} Added parameter "redial delay" to support the mandatory delay between successive dial attempts required by some European modems. @{b}*@{ub} With the dial dialog switched off the dial window now also displays the "repeat delay" and "dial delay" messages. @{b}*@{ub} Changed the background of the demo requester to the MUI text background. @{b}*@{ub} For SLIP the total number of IP packets reported by NetStat was always zero. @{b}*@{ub} The "lastlog" time in usergroup.library was set to local time instead of GMT, causing "finger" to output an incorrect time value - fixed. @{b}*@{ub} A bug in getpwent() prevented "finger name" from working. @{b}*@{ub} Minor bug fix in PPP/LCP: Miami sometimes sent one superfluous NAK for magic number. @{b}*@{ub} Improved the output queue throttling for SLIP/PPP. @{b}*@{ub} MiamiPing added to distribution. @{b}*@{ub} MiamiTraceRoute added to distribution. @{b}*@{ub} MiamiSysCtl added to distribution. @{b}*@{ub} MiamiIfConfig added to distribution. @{b}*@{ub} MiamiRoute added to distribution. @{b}*@{ub} Miami no longer sets the MTU values to the defaults of 1500 and 1006 when changing the protocol. @{b}*@{ub} Miami no longer displays the "resetting modem" requester if a previous connection is resumed or a nullmodem connection is used. @{b}*@{ub} Hangups are a bit quicker now. @{b}*@{ub} Added "fossil.device" to the device list in MiamiInit, and enabled EOF-mode for it. @{b}*@{ub} EOF-mode=auto should now work correctly with A2232 boards for all possible unit mappings. @{b}*@{ub} The PPP receiver now initiates a VJC restart after receiving a bad packet, to prevent TCP sequence errors resulting from missing packets with a compressed ID field. @{b}*@{ub} Improved buffer alignment heuristic for PPP and SLIP. This should reduce the CPU load in many cases. @{b}*@{ub} Bug fix: During dialing sometimes not the complete modem dial string was echoed to the dial window. @{b}*@{ub} Reenabled support for GetSocketEvents(). @{b}*@{ub} Added an 68020 version of Miami (for reg. users only) to the distribution. @{b}*@{ub} Slight change in the way PAP/CHAP failure messages are displayed. @{b}*@{ub} Modem init/exit string can now be up to 80 characters long each. @{b}*@{ub} Slight change to the rendering code to fix one possible refresh problem with simple-refresh windows in OS 3.x. @{b}*@{ub} Minor bugfix in the way ENV:TZ is handled for European summer time. @{b}*@{ub} Changed that workaround for broken Win-NT servers again to support Win-NT servers that have PAP disabled. @{b}*@{ub} Added support for a new proposed extension to the IPCP option IP_ADDRESS. @{b}*@{ub} Formally separated PPP authentication phase from NCP config phase. This might help work around a bug in some Win-NT servers. @{b}*@{ub} Added option "-N" to MiamiNetStat to display cached host names, but suppress additional DNS lookups. @{b}*@{ub} Increased serial.device buffer size from 4 kB to 16 kB. @{b}*@{ub} Miami now saves the position of the balancing bar in the dial window. @{b}*@{ub} Added Tooltype "AREXX" to start an ARexx script upon startup. @{b}*@{ub} Syslog messages now include the system date and time. @{b}*@{ub} Added ARexx commands GETONLINETIME and LOADSETTINGS. @{b}*@{ub} Added Tooltype ACCMBUG to work around a bug in some Xylogics servers (e.g. those used by InternetFCI). @{b}*@{ub} Added "MiamiResolve" and "MiamiFinger" to the distribution. @{b}*@{ub} Miami now asks the user to import a settings file from MiamiInit or MiamiInitSANA2 and to save the settings after startup if no settings file exists yet. @{b}*@{ub} Added dialer commands ASKPASSWORD and SENDPAD. @{b}*@{ub} Redesigned the Database page to be more intuitive to use. @{b}*@{ub} Bug fix in built-in InetD: fingerd and identd could overwrite their internal buffers causing Miami to crash in some cases. @{b}*@{ub} Added a simple heuristic for ping flood protection. @{b}*@{ub} Added miamibpf.library, miamipcap.library and MiamiTCPDump to the distribution. @{b}*@{ub} Added menu-help for Miami's menu. @{b}*@{ub} Changed the "one-behind" cache for TCP and UDP PCBs to a multi-entry hashlist-based cache. @{b}*@{ub} Added support for some missing "standard" MUI ARexx commands. @{b}*@{ub} Added callback hook mechanism for packet monitoring. @{b}*@{ub} Added support for shell scripts on the Events page. @{b}*@{ub} Improvements in WaitSelect() to enhance compatibility with other protocol stacks. @{b}*@{ub} Added customizable IP filter. @{b}*@{ub} Added automatic IP filter for invalid IP addresses (such as 0.*.*.*). @{b}*@{ub} Added option "Console name" to the Events page. @{b}*@{ub} Added support for Petri Nordlund's SysLog package. @{b}*@{ub} Added support for CBCP PPP Callback. @{b}*@{ub} Several improvements to the PPP state machine. @{b}*@{ub} Added menu item "Iconify". @{b}*@{ub} Many other minor changes I have already forgotten about :-). @{b}Version 1.1d@{ub} intermediate public release version @{b}*@{ub} Fixed a bug that could cause authd/identd to hog the CPU in certain cases. @{b}Version 1.1b@{ub} intermediate public release version @{b}*@{ub} More than three phone numbers were not always handled correctly in the registered version - fixed. @{b}Version 1.1a@{ub} intermediate public release version @{b}*@{ub} Most of the entries in MiamiInit were "off by one". Fixed. @{b}Version 1.1@{ub} fifth public release version @{b}*@{ub} Probably fixed the bug that sometimes the ARexx command "QUIT" did not work when the GUI is iconified. @{b}*@{ub} When the dial dialog was disabled the dial text field would not always clip text properly - fixed. @{b}*@{ub} Added several modem entries to MiamiInit. @{b}*@{ub} Corrected some MUI background patterns in Miami. @{b}*@{ub} Added a border of one additional pixel around the text field in the dial window to accomodate some fonts that do not correctly define their spacing. @{b}*@{ub} Fixed a slight rendering bug in the dial window that occured when the dial dialog was switched off. @{b}*@{ub} MiamiInit now attempts to find the correct MTU and passes it to Miami. @{b}*@{ub} Fixed yet another memory leak. @{b}*@{ub} Changed the appearance of the "General" page for the registered version. @{b}*@{ub} Launching MiamiRegister from Miami now works if Miami was started from the shell with a non-default path. @{b}*@{ub} Two slight performance enhancements in the TCP/IP kernel. @{b}*@{ub} Added warning message if someone tries to load an old settings file with an incomplete database (as generated by Miami 1.0.1 and 1.0.2). @{b}Version 1.0.3@{ub} fourth public release version @{b}*@{ub} Change in the DNS resolver: Previously if the host name did not end in a '.' DNS lookups would first assume that the host name is an abbreviation and append all domain names one by one for DNS lookup, before doing a lookup on the host name alone. Now, after the change, any host name that contains at least one '.' is considered fully qualified, and DNS lookups are done for this host name first (without appending a domain). Only if these lookups fail, and if the host name does not end in a '.' are domain-based lookups done. This new strategy is different from what BSD usually does, but it apparently gives better performance (reduces the number of DNS lookups) if host name abbreviations are not used very often, and if DNS lookups can take a non-negligible amount of time for at least one predefined domain. The bottom line is: The "looking up host name" phase of web browsers should be quicker now than before, especially if you have more than one domain listed in Miami's domain database. @{b}*@{ub} Fixed a minor bug in the way the "daytime" service handles ENV:TZ. @{b}*@{ub} Added a GUI configuration page to customize many aspects of the user interface. @{b}*@{ub} The "quit" requester is now more customizable and useful, an "offline" requester has been added, and all protocol-related error requesters can be suppressed. @{b}*@{ub} The help text and buttons in the dial window can now be separately disabled, and it is possible to only switch to a much smaller dial window that just displays the currently executed command, not the complete dial dialog. @{b}*@{ub} If gethostbyname() failed incorrect error values were returned in errno and herrno. @{b}*@{ub} Added an "escape" function to PPP to allow other characters than 0-31 and 128-159 to be sent escaped. @{b}*@{ub} Executing the ARexx command "QUIT" from within an ARexx script launched from Miami works now, and quits the program after all ARexx scripts have returned. @{b}*@{ub} Added requester to Miami, MiamiInit and MiamiRegister to inform the user that MUI 3.3 or higher is required. @{b}*@{ub} syslog() did not work properly with all programs. @{b}*@{ub} syslog() now logs the process id if requested by a program. @{b}*@{ub} If Miami was started without a settings file the database was not initialized correctly. @{b}*@{ub} Added support for "dos" type servers in built-in InetD. @{b}*@{ub} The main window now acts as an AppWindow, i.e. if you drop the icon of a settings file on it Miami loads that settings file. @{b}*@{ub} Miami now tries to use "ENV:Sys/def_MiamiApp.info" as its AppIcon when started from Workbench. If this icon does not exist or if Miami was started from the Shell the standard built-in icon is used. @{b}*@{ub} There was one more special case left in which the memory allocation problem of version 1.0 still occured - fixed. @{b}Version 1.0.2@{ub} third public release version @{b}*@{ub} Minor changes to MiamiRegister only, to reflect the new host name of the Miami registration server. @{b}Version 1.0.1@{ub} second public release version @{b}*@{ub} Workaround for a problem with some Annex terminal servers. @{b}*@{ub} Control sequences "\\p" and "\\u" incorrectly added a "\\r" character. @{b}*@{ub} The "passive offline" ARexx script is now executed before attempting to reconnect. @{b}*@{ub} There was some debugging output left in the code when Miami replied to an ARexx message - fixed. @{b}*@{ub} PPP now no longer signals a "down" event to Miami when IPCP goes down, but only when LCP goes down. This should prevent problems with very slow terminal servers that try to renegotiate IPCP after it has already come up once. @{b}*@{ub} Added ARexx commands "SHOW", "HIDE" and "GETSETTINGSNAME". @{b}*@{ub} Added PPP option "Get DNS from IPCP" to disable IPCP-based DNS discovery. Some buggy PPP servers are unable to handle or reject IPCP DNS extensions correctly. @{b}*@{ub} Miami now explicitly checks for MUI >=3.3. @{b}*@{ub} Fixed a race condition in the unregistered version that could cause Miami to reallocate the same buffer over and over again after one hour of inactivity, quickly exhausting all available RAM. @{b}*@{ub} Fixed a menu shortcut collision. @{b}*@{ub} If ToolTypes were used to import MiamiInit settings or an exported configuration then the database was not initialized properly - fixed. @{b}*@{ub} Some combinations of Slirp/TIA with Slip/PPP were not configured correctly after importing settings from MiamiInit. @{b}*@{ub} Some minor changes in MiamiInit. @{b}*@{ub} Fixed a memory leak in built-in InetD. @{b}Version 1.0@{ub} first public release version @EndNode @Node "NODE_FUTURE" "Miami.guide/NODE_FUTURE" @Next "NODE_SUPPORT" @Prev "NODE_HISTORY" @Toc "Main" The future ********** My more immediate plans for the next Miami versions include @{b}*@{ub} Transparent SOCKS V4 and V5 client support. @{b}*@{ub} Full support for Level-2 Multicasting (including compatibility to MBone live audio/video transmissions and an implementation of MRouteD). @{b}*@{ub} A new API to handle automatic online/offline transitions controlled by clients. ISDN is another big issue. External ISDN terminal adapters are already completely supported. So is the ISDN-Master board in most modes, except in "synchronous PPP in HDLC mode". That mode requires new drivers and a new API, but people are working on it... The only really major (intentional) limitation of Miami is that it is restricted to a single interface. A follow-up protocol stack "Miami Deluxe" is planned for later this year. Currently my plans for Miami Deluxe include support for PPP dial-in connections, multiple interfaces and probably many other functions useful for routers, such as Socks daemon support, IP masquerading and firewall functions. There will be a discount for registered users of Miami towards a registration of Miami Deluxe. @EndNode @Node "NODE_SUPPORT" "Miami.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/Miami.html @{b}mailing lists@{ub} send "SUBSCRIBE miami-talk-ml" or "SUBSCRIBE miami-announce-ml" in the body of a mail to "amiga-lists@nordicglobal.com". @EndNode @Node "NODE_ACKNOWLEDGEMENTS" "Miami.guide/NODE_ACKNOWLEDGEMENTS" @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} all users who decide to register Miami. @EndNode