Sustainable Sustworks - Tools for Internet Travel
Advanced Networking for Mactintosh Professionals

Release Notes



User Guide: Frequently Asked Questions

IPNetMonitor Status (last updated 14-Sept-2001)

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 key

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, what happened?

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, what happened?

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 folder.

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 is for.

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 inserted.

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 in IPNetMonitor.

Our software router, IPNetRouter, supports ICMP port forwarding for unix style tracerouting properly and you are welcome to install it and compare the performance, unix compatiblity-wise.