Each Network Monitor protocol parser uses an initialization (.INI) file. This section explains the sections of parser .INI files and situations in which you might need to modify these files.
An Ethertype is a four-digit hexadecimal number that uniquely identifies a protocol implementation. If you write a new implementation for an existing protocol, you register the implementation with the Xerox Corporation, and you are assigned an Ethertype. This Ethertype appears in any frame that uses the new implementation, and enables software that receives the frame to distinguish the frame from any frame that does not use the new implementation.
The ETYPES section of a parser .INI file lists protocols and their associated Ethertypes. This information is used by the Network Monitor application programming interface (NMAPI) to ensure that a frame is passed to the correct parser for processing.
For example, the MAC.INI file contains the following entry:
0x600 = XNS
If the media access control (MAC) protocol parser for Network Monitor encounters 0x600 in a frame, the parser reads its .INI file to identify the protocol associated with this Ethertype. It passes this protocol name to the NMAPI. The NMAPI passes the frame to the correct XNS parser.
If you add a parser to Network Monitor, or replace a Network Monitor parser with an implementation of your own, you must add the protocol name and the associated Ethertype to the ETYPES list in the Network Monitor .INI files. Make appropriate additions to the .INI file for every parser that can pass frames to your parser.
The information in this section applies only to the MAC.INI file.
Use the FORCE_RAW_IPX section of the MAC.INI file to specify how Network Monitor should respond when it receives an Ethernet or Fiber Distributed Data Interface (FDDI) frame that contains ambiguous data in the first two bytes after the frame's Length field.
An Institute of Electrical and Electronics Engineers (IEEE) 802.3 frame contains the following components:
Destination Address
Identified in the first six bytes of the frame.
Source Address
Identified in the second six bytes of the frame.
Length
Identified in the thirteenth and fourteenth bytes of the frame.
LLC Header
Identified in the next three bytes of the frame. Contains the destination service access point (DSAP), source service access point (SSAP), and control information.
All implementations of the IEEE 802.3 standard use the first three fields described in the preceding list to store the same types of information. However, implementations of IPX differ in their use of the bytes that follow the Length field. Differences in implementation can render the IPX protocol parser unable to interpret the first two bytes following the Length field.
For example, in a raw IEEE 802.3 frame, the bytes following the Length field always contain the hexadecimal numbers FFFF, which marks the beginning of the IPX frame. Because IPX frames currently do not use the checksum field, these two bytes are always FFFF and constitute the IPX header.
A true IEEE 802.3 frame, on the other hand, uses these bytes to store the DSAP and the SSAP. In the event that the DSAP and SSAP fields both equate to FF, the IEEE 802.3 frame cannot be distinguished from the IPX header in a raw IEEE 802.3 frame.
In most cases in which the number FFFF appears in the first two bytes following the Length field, it indicates that the frame is a raw IEEE 802.3 frame. Therefore, the FORCE_RAW_IPX field of the parser MAC.INI file is set to Yes for both Ethernet and FDDI frames. This setting notifies Network Monitor to interpret a frame containing FFFF in the first four bytes following the Length field as a raw IPX frame. If you set these entries to No, such frames are interpreted as true IEEE 802.3 frames.