User Guide: Frequently Asked Questions
IPNetMonitor Status (last updated
Version 2.5 was released in August, 2001. IPNetMonitor 2.5 includes
a new port scanning tool, new link rate tool, and a new
ICMP traceroute feature.
We currently have plans to port IPNetMonitor to OS X. For more
info about Mac OS X and our products visit our OS
X Status web page.
See our site download page and
the release notes for the
more info on the latest available versions of IPNetMonitor.
I tried to install the IPNetMonitor demo
but it says it expired
The demo is designed to expire after 21 days. It sounds like
someone ran a previous version of the program on your system,
so the demo thinks it has expired. This problem might also occur
if you ran the IPNetMonitor uninstaller before updating to a newer
version. In that case, you will need to register
or reregister the application.
IPNetMonitor won't accept my registration
It is important to enter each character of the registration data
exactly as shown. Changing a single character from lower to upper
case will prevent the key from being recognized. If you are still
having difficulty, please open
a support case for further assistance.
The Installer did not install some files,
The installer includes a number of checks to make sure the version
of IPNetMonitor you have selected is compatible with your system.
Specifically it checks the following:
- Correct processor (PPC or 68K)
- OT1.1.1 or later
- System 7
The 68K version of IPNetMonitor is not fully supported on the
PPC because not all Open Transport functions are emulated. Specifically,
the application will quit any time you open the Monitor window
because ASLM (the Apple Shared Library Manager) will not be able
to find one of the Open Transport functions IPNetMonitor calls.
The installation was not successful,
IPNetMonitor was previously named "IP NetLink". Some
early customers may still have a "IP NetLink Prefs"
file in their Preferences folder. The installer will try to rename
this to "IPNetMonitor Prefs" for you, but may fail if
you already have an "IPNetMonitor Prefs" file.
How do I remove IPNetMonitor completely?
To remove IPNetMonitor completely from your system, use the IPNetMonitor
installer application and hold the option key down when you get
to the window with the installer button. If you are running IPNetRouter,
you will want to manually remove everything except for the OTModl$Proxy
file--do not use the installer in this case.
IPNetRouter and IPNetSentry
require this file to continue being your Internet sharing gateway.
To manually remove IPNetMonitor except for the OTModl$Proxy extension,
trash your IPNetMonitor folder, and the "IPNetMonitor Prefs"
and "IPNM.log" files from your system's Preferenence
Manually removing the OTModl$Proxy file without using the installer
is not recommended, especially on pre-OS 9 installations. Consult
the accompanying Read Me documentation.
I can't get the Monitor tool to work,
what should I do?
If the Monitor menu item is grayed out and you have IPNetSentry
also installed, upgrade to IPNetSentry
1.2 or later.
If the "Start" button in the Monitor window changes
to read "Pending", this means the OTModl$Proxy STREAMs
module was never opened, either because it was not successfully
inserted in the TCP/IP protocol stack, or all active IP protocol
stacks have been unloaded.
In order for monitoring to work, the monitor needs to insert
a probe module into your TCP/IP protocol stack below IP and above
any Data Link Provider.
The probe module is a shared library called OTModl$Proxy and
must be in your Extensions folder. This usually isn't a problem.
How it gets inserted into your protocol stack is a little more
complicated. Two different techniques are used depending on what
Data Link Provider you are trying to monitor.
If you are using OT/PPP, it tries to autopush OTModl$Proxy above
your PPP module. In order for this to work, OT needs to be configured
for autopush before the Link Stack is built. This is what SetupAP
For other Data Link Providers, it modifies your TCP/IP Preferences
file to include OTModl$Proxy in the stack. For this to work, you
must have OT1.1.1 or later and IPNetMonitor needs to be able to
find and modify your "TCP/IP Preferences" file.
The first time you try monitoring and each time you select a
new TCP/IP configuration (Cmd-K from the TCP/IP control panel),
IPNetMonitor will display the following dialog:
Monitor is not set up to use the current TCP/IP configuration.
Change to Monitor: <new-configuration>
This dialog is actually confirming that it is Okay to modify
your TCP/IP Preferences file. If you are using a non-US version
of Open Transport, you may need to edit 'STR#' resource 134 to
match the name of your TCP/IP Preferences file (no longer necessary
in version 2.0 or later).
You may need to restart after the first time you try monitoring
so the Link Stack can be created with the OTModl$Proxy module
Finally, I've heard from one customer that Monitoring MacIP does
not work. It appears MacIP uses a different configurator that
does not find the OTModl$Proxy STREAMs module. I haven't implemented
a solution for this yet.
Does the extension you place in the extensions
folder in any way slow down OT/PPP?
The "extension" is a STREAMs module that passes packets
from PPP to IP and looks in the message block header to see how
big they are. I'd guess it adds a couple hundred instructions
of processing to each IP datagram. But since you are waiting for
the much slower network interface to send/receive datagrams, it
is totally transparent.
The other thing the module does is send the stats it collects
to the application to be plotted, but this is totally independent
of the PPP to IP data path (handled by a separate timer interrupt
that is synchronized with the STREAMs environment).
So the simple answer is no. It adds a very small amount of processing
to the protocol stack, but should not affect OT/PPP performance
in any way.
The STREAMs module is not really an extension. It doesn't patch
anything or change the behavior of the operating system. It is
a shared library that is loaded and linked by Open Transport when
the corresponding protocol stack is created.
Why does either the Ping or Traceroute
tool work but not both?
Some less costly or older NAT implementations do not support
ICMP port forwarding correctly. Apple's AirPort hardware basestation
is known to have this problem. Other NAT gateways have configureable
options that control the type of ICMP forwarding that is permitted--check
the documentation for any suspected intervening gateway that might
be causing a problem with ICMP port forwarding. If you see similar
symptoms using a unix based traceroute application (eg, the Network
Utility in OS X), the upstream router does not support ICMP port
forwarding properly and the problem is not with IPNetMonitor.
Check your NAT router's documentation for unix traceroute and
ICMP compatibility information, etc.
To work around the problem of poor intervening NAT implementations,
IPNetMonitor 2.5 and later has a checkbox option in the traceroute
window to perform the traditional, Unix style traceroute or a
fully ICMP based traceroute.
Note, that Windows standard traceroute tool is not a Unix based
implentation either and may behave differently then the two implementations
Our software router, IPNetRouter,
supports ICMP port forwarding for unix style tracerouting properly
and you are welcome to install it and compare the performance,