FrameSeer sometimes fails to notice interface state-changes

FrameSeer relies on notifications from Mac OS X to become aware of network changes (eg removing or inserting an Ethernet cable). When it receives such a notification, FrameSeer responds by re-discovering the state of the selected interface. Occasionally, the requests made to Mac OS X during this discovery appear to return stale information.

Clicking on the interface popup menu in the Capture tab, or clicking on the Start (or Stop, then Start) button also causes a re-discovery. You can use this to force FrameSeer to re-check the state of the network.

FrameSeer doesn’t discover interface state-changes for third-party network hardware

The built-in Ethernet interfaces for current Macintosh systems have the circuitry and “smarts” to send events such as cable disconnection to Mac OS X (which, in turn, notifies applications such as FrameSeer).

Unfortunately, not all third-party solutions offers such facilities. If your combination of network hardware and driver software does not provide the necessary information to Mac OS X, there is nothing that can be done.

tcpdump doesn’t always stop when network state changes occur

True. This is not actually a bug. The only times that FrameSeer tells tcpdump to stop are:

• When the Stop button is clicked; and
• When the capture buffer fills up.

For all other conditions, including when the network changes state, FrameSeer assumes that tcpdump will either continue to listen to the interface, or will quit of its own accord.

FrameSeer may crash when it runs out of virtual memory

True. This is a bug but we do not believe it to be in FrameSeer.

When FrameSeer asks Cocoa to create an object, a routine called NSAllocateObject is normally called to allocate the memory to represent the object. The documentation says that NSAllocateObject will return a nil value on errors and FrameSeer relies on that statement. However, our testing shows that NSAllocateObject does not return a nil value when virtual memory is exhausted but instead writes a message to the console log and terminates FrameSeer.

The workaround for this problem is to “be reasonable” in the demands you place on FrameSeer. Each Mac OS X application has four gigabytes of virtual memory. If you avoid having many large capture windows open simultaneously, there is no reason why you should ever run out of virtual memory.