Known Problems

Number	Symptom	Root Cause	Status	Resolution/Workaround
1	Only directly addressed frames and broadcast/multicast frames are captured.	if the network hardware in use is a switch, this hardware may not be configured to share traffic with ports to which that traffic is not directly addressed the correct input filter is not set in the PROTOCOL.INI, to allow for promiscuous frames the hardware or MAC driver does not support promiscuous mode all Ethernet hardware supports promiscuous mode by design some Token-Ring hardware, especially older or PCMCIA versions may NOT support promiscuous mode even if the hardware supports promiscuous mode, the MAC driver may not	Closed as a permanent design restriction. To gain all of the benefits of using a generic NDIS interface to the network this restriction is the "trade-off".	See LAN Switch Port Monitoring. Make sure that the port on which tracing is to occur is configured to receive non-directly addressed frames. See Configuration for details on the filter settings available. run BINDTREE or NTRACE -q to determine if the LAN hardware and MAC driver support promiscuous mode utilize different hardware or drivers that support promiscuous mode on the network topology of your choice
2	Frame status fields in Token-Ring frames are missing or NULL.	This is the behavior designed into the NDIS architecture which we are reliant upon. MAC drivers do not provide this information to protocol drivers.	Closed as a permanent restriction. To gain all of the benefits of using a generic NDIS interface to the network this restriction is the "trade-off".	None.
3	Frames are sliced at 256 bytes.	this could be due to an evaluation license restriction (run NTRACE -v to display the license restrictions) in protocol mode, some hardware does not support a feature called "multiple TransferData", this means that only the first 256 bytes of a frame can be copied without disabling the other networking in the trace machine	Closed as a restriction of protocol mode.	If an NTRACE -q displays: `Full Frames Mode NO` then this hardware does NOT support multiple TransferData. Use service mode or install the product as a 3rd party trace machine and use the dedicated option.
4	Trace files are missing ALL outbound frames on traces taken on Ethernet LAN adapters.	Ethernet adapter hardware does not provide a loopback feature. This feature is required if protocol mode is in use. Otherwise outbound frames cannot be captured.	Closed as a known restriction of protocol mode.	Use service mode or a 3rd party install .
5	High resolution timestamps are unreliable.	When WINOS2 applications are running on the same machine as NTRACE, the high resolution timing mechanism is not reliable.	Closed as permanent restriction.	If high resolution timestamps are required, do not run WINOS2 applications while tracing. OR run the WINOS2 applications on a separate machine from the trace machine.
6	Trace files are missing some outbound frames on traces taken on Token-Ring LAN adapters.	Unknown. A theory: in protocol mode, Network Trace is reliant upon the loopback feature in order to capture outbound frames. This feature may not be 100% reliable.	This has been seen once, but cannot be duplicated. Please report this condition to technical support immediately if encountered.	The one time this was encountered, subsequent traces (after a reboot) did not show the same condition.
7	The following error message is seen: "SetPacketFilter call returned an error when turning tracing on."	This condition can be triggered if the PacketFilter is set to a filter which the MAC driver cannot support. The PacketFilter is either calculated by the driver or passed using the -pf option of NTRACE.EXE.	There are no known instances of a miscalculated PacketFilter. Please report any instances to technical support. If the problem is with a user specified filter, there is no defect in the code.	A workaround would be to use only a packet filter that is accepted by the MAC driver.
8	Traces captured under heavy loads are found to be missing frames, however no indication of lost frames was provided by the statistics which NTRACE.EXE displays during a trace.	Network Trace is completely dependent upon the LAN adapter and MAC driver for accurate error counts and statistics. Some drivers do not support the reporting of ANY statistics. In addition, even on systems where statistics are being reported, there is no way to determine their complete accuracy. See heavy traffic volumes and lost frames sections for more details.	The device driver and NTRACE.EXE now report any known frame loss. Note that each LAN adapter may calculate these statistics differently. In addition, different statistics may have different meaning between LAN topologies (Ethernet or Token-Ring). If this condition is encountered in a situation where the LAN adapter reports that it does support statistics, please contact technical support. In addition, design changes and optimizations have been implemented to eliminate or minimize this condition.	There is no workaround or change that can be made to eliminate this condition 100% of the time. See the section on lost frames for possible actions.
9	NTRDIAG will incorrectly report an error if it does not find NTR.MSG in the same directory as LANTRAN.LOG.	This is caused by hard coded logic in NTRDIAG and is a limitation of the current version.	This limitation will be removed in a future release.	Ignore this warning as long as the NTR.MSG meets one of the correct search criteria.