Tips for using the Configurator
Slow start-up on Macs
For unknown reasons, the configurator can occasionally require between
30 seconds and a minute between the time the application is double-clicked
and the time the configurator window appears. The problem seems to be sporadic
- sometimes it will fire up immediately, while at other times it will require
half a minute. Thus if nothing seems to happen, wait a minute. (The cause
of this problem is under investigation.)
Shrunken text entry fields
It is possible that when you start the configurator, or retrieve settings,
all of the textboxes into which you can enter information will appear very
narrow, unable to hold even 1 character. This is a Swing anomaly: if the
outer window size isn't large enough to hold all of the contained components,
all of the textboxes shrink to 1 pixel wide! The solution is simple: just
enlarge the window size (drag the bottom-right corner); when the size is
big enough, the textfields will all suddenly pop out to their normal size.
Note that this shrinkage happens whether the window is too narrow (not
wide enough), or too short (not tall enough), so you might have to enlarge
either of these dimensions.
One problem that I've seen in several users' configuration files is
the lack of the "hidden" modem initialization string prefix that
controls the country code setting. Without this prefix, the modem won't
dial out; versions of the configurator released prior to July 13, 2000
assumed the string would be present, and thus didn't automatically write
it in. Since it appears not to always be present in default factory
configuration files, the latest version of the configurator always writes
this in. If you've been unable to get your modem to dial out, try the latest
configurator version. In addition, the visible part of the default modem
init string should be "&FX4S0=0&WZ" (without quotes,
and those are zeros). If yours shows up empty in the configurator's modem
initialization string text field, put this in and see if it doesn't solve
Modem initialization string facts
The modem initialization string displayed is actually only the latter
part of the actual modem initialization string sent to the base station.
The string actually begins with "*NC22", where the digits "22" could be
replaced by some other pair. Thus the default initialization string is
"*NC22&FX4&WZ" (for base stations sold in North America, anyway),
or "*NC22&FX4S0=0&WZ" for later base stations. The configurator
only displays the latter part, "&FX4&WZ". This is because the prefix
"*NC22" controls the country specification: the digits 22 set the base
station for the North American phone system, the digits 40 set it for the
phone system used in Australia and South Africa, and so on. Since there
is already a combo box available to specify this information, which sets
the digits in the string according to the country selected, this part of
the modem string is hidden. This prevents inconsistent information from
being entered in the combo box and initialization string. Just be aware
that the modem string actually contains some additional information compared
to what is displayed.
Airport 1.2 compatibility
The configurator (any version) is compatible with Airport 1.2.
Saving current settings when uploading firmware
You can preserve your current settings when uploading firmware, rather
than having the base station reset to a "plain vanilla" configuration,
by retrieving the current settings first (or opening a previously saved
settings file) before selecting the "Upload new base station firmware..."
item from the "File" menu. These settings will then be automatically sent
to the base station along with the new firmware, so the station will be
configured and ready to go after it restarts.
Base station reset with Airport 1.1 and up
In the original version of the firmware (1.0), the reset procedure
(sticking the paperclip into the bottom of the base station immediately
after power-up) set the base station to a "plain vanilla" configuration,
which was ready for reconfiguration. In Airport 1.1 and 1.2, the reset
truly lobotomizes the base station: it puts it in a state where it's waiting
for a firmware reload (complete software update), and won't do anything
else until it gets it. This non-functional state is indicated by the center
LED glowing amber (or maybe red?) rather than the normal healthy green.
Version 1.2 of the configurator includes facilities for uploading firmware,
which you can use to get the base station out of this zombie state. For
instructions on how to do this, see the updated version of the manual.
Note that you will need to connect to the base station through its Ethernet
port, using a crossover cable or by connecting through a hub. When reset,
the base station will no longer respond through its wireless interface.
Not exactly a resounding endorsement of wireless communication capability....
Double-clickability in Windows
Use the Sun JRE 1.2 or higher runtime environment to get the convenience
of double-click running of jar files; this is available at http://java.sun.com/products/jdk/1.2/jre/index.html.
While the configurator is Java 1.1.8-compliant, it's more of a pain to
run in this setting. You need to download the library "swingall.jar"; with
this in the same directory as the configurator jar file, "cd" into that
directory and run the command
jre -cp "AirportBaseStationConfig.jar;swingall.jar" AirportBaseStationConfigurator
(You might have to use the full pathname for jre.) This should start the
You can save the settings you're currently using by selecting "Save
settings..." from the "File" menu. This is a good idea, especially if you're
experimenting with the base station settings, so that if you need to revert
to your last known "good" settings you'll have then available. The configurator
will also open settings saved with Apple's configuration software.
Don't create settings from scratch - always work from retrieved settings
(or previously saved settings)
While it would seem to be possible to create your own settings, starting
with the "blank" settings present when the configurator first starts up,
this is not a good idea and would probably lead to the base station's being
in an inconsistent state and not functioning properly when updated. This
is because there are many fields in the configuration data that aren't
accessible through the configurator, and hence are sent back unchanged
when retrieved settings are modified and updated. If you attempted to create
your own settings from scratch, these "hidden" fields would be sent back
as "0", which could wreak havoc with the base station's operation. While
I haven't tested this to actually see what happens (why look for trouble?),
I know that there are fields whose corruption could only lead to grief.
So always work from settings that have been retrieved from the base station
(or previously saved settings which were created in this way).
The role of the Ethernet port in modem connections
The Airport connects to the "outside world" through either the modem
or the Ethernet port; when connected via the modem, the Ethernet port becomes
part of the "wireless" LAN - that is, you can connect wired devices to
the base station's Ethernet port, and they will use the base station exactly
as the true wireless stations do. (The Ethernet-port-connected hosts can
be treated slightly differently, if desired - there's a checkbox in the
configurator's "Bridging" panel that determines if the base station delivers
DHCP/NAT addresses to the Ethernet-connected devices. By checking this,
the Ethernet-connected devices are treated exactly as the wireless devices
Where is the "Ignore dial tone" checkbox?
The reason there isn't a checkbox for "Ignore dial tone" is because
it actually just changes a field in the modem init string:
Thus you can use this to achieve that effect (it apparently loads a different
set of factory settings into the modem); since the Apple configuration
software doesn't give access to the modem init string, it has a checkbox
for this setting.
standard modem init string: &FX4&WZ
ignore dial tone init string: &FX3&WZ
Modem initialization string and phone number length
The length of the modem initialization string is limited by the size
of its field in the base station settings memory block. This field actually
stores the initialization string and phone number together, and has 40
bytes total (ignoring the "*NC22" prefix discussed above - 45 bytes if
you include that, which I won't). Each charater of the initialization string
requires 1 byte, while each digit of the phone number (including spaces,
parentheses and dashes) uses 1/2 byte. (The phone number is in binary-coded
decimal, with each hex "nibble" (half-byte) storing one decimal digit,
or "D" for space or parentheses and "E" for dash.) Thus the maximum permissible
length for the initialization string depends on the length of the phone
number. For example, if the phone number 610-5551212 is entered, this has
11 characters, requiring 5 1/2 bytes to store; this leaves 34 1/2 bytes
available for the modem string, which can therefore have at most 34 characters.
Note that if you eliminated the "dash" in the phone number, you would gain
an extra space for the initialization string. There is (unfortunately)
currently no check done on the length of the initialization string / phone
number supplied - if it's too long, only the part that fits will be written,
which would result in only a partial phone number being present.
Slow response from base station
The base station may sometimes be slow to return settings when they
are being retrieved, or slow to accept settings when they are being updated.
This "lag time" may sometimes be as much as 30 seconds, especially when
the base station is (currently) improperly configured. The reason for this
has to do with Java's network API: whenever communication occurs to a remote
host, a domain name lookup is performed, even if an IP address has been
specified - Java treats all addresses as if they're domain names. Thus
when the "Retrieve Settings" button is clicked, with, say, host 10.0.1.1
in the address field, the configurator tries to do a domain name lookup
on "10.0.1.1". If the domain name servers are accessible, they quickly
report back that the supplied name "10.0.1.1" is in fact the IP address
of the desired host, and this is then used to send the request for the
settings information to the base station. However, if for some reason the
domain name servers can't be contacted - for example, when the base station
can't connect with the outside world due to bad configuration data -
the configurator waits for a period of time to hear back from the name
servers, and finally gives up and sends its message using the address it
has had all along, at which point the base station should respond. A shorter
lag may also be noticed when the base station is configured to connect
through its modem, since the base station must establish a dial-up connection
(if it is not currently connected) to transfer the domain name request
to the name servers.