Understanding Filters

This is an advanced topic that requires a thorough understanding of the NDIS environment. Please see the listed references if additional NDIS understanding is required.

Types of Filters

There are two filters which can be utilized to control the types of frames flowing through the NTRACE driver.

First, there is the PacketFilter. This is a bit mask defined by NDIS which allows MAC drivers to determine which frames should be passed to the protocol layer for processing. Traditional NDIS networking does not require any support other than directed frames and broadcasts. NTRACE requires a promiscuous copy mode and this means that this bit mask must be changed.

Second, there is the RejectFrames filter. This is also a bit mask, but it is a value that is unique to NTRACE. This mask allows NTRACE to know which frames should NOT be forwarded on to the protocol drivers. This is required because the change to the PacketFilter required to trace in promiscuous mode now forwards frames which some protocols were not designed to handle.

The easiest way of thinking about these two filters is:

PacketFilter operates on the NTRACE driver's input and RejectFrames operates on the driver's output.

PacketFilter

The NDIS architecture defines four classes of frames (packets in NDIS terminology). A MAC driver can program the network adapter to allow/disallow reception of any or all of these frame classes.

These are:

directly addressed frames

frames containing one of station's network addresses as the Destination Address

broadcast frames

frames containing a special broadcast address as the Destination Address

foreign frames

frames containing a non-broadcast address that doesn't match station's addresses

source routing frames

frames containing Source Routing information (Token-Ring only)

A Packet Filter is a four-bit mask indicating which classes of frames are enabled for reception.

Every network protocol driver sets its own packet filter. If more than one protocol is bound to a MAC, the VECTOR function is inserted in the middle between protocols and the MAC. The VECTOR accepts protocols' packet filters as they are and requests the MAC to set a logically combined packet filter. Thus, the actual packet filter used may be less restrictive than every protocol's individual filter.

When NTRACE turns tracing on, it requests the MAC driver to set the least restrictive packet filter. What this actually means, depends on the MAC capabilities. The ability to receive broadcast, foreign and source routing frames is reported in the Service Specific Characteristics of the MAC. The NTRACE driver consults this table and calculates the least restrictive packet filter enabling the corresponding classes of frames.

Unfortunately, the behavior in tested Token-Ring MAC drivers is different from what is expected based on NDIS documentation. All tested Token-Ring drivers claim the ability to process source routing frames but refuse to accept packet filters with the source routing frames bit ON. Thus, the automatically calculated packet filter causes troubles.

A work around has been implemented. The calculation doesn't take in account the source routing capability and never produces the packet filter with the corresponding bit ON. The calculated packet filter value is calculated depending on MAC driver capabilities:

directly addressed frames and broadcasts are always enabled;

if the adapter supports promiscuous mode, it's enabled.

This yields a packet filter of 7 (where promiscuous copy is supported) and 3 (where no promiscuous copy support is available). This approach has worked in testing without flaws. The MAC drivers tested allow the source routing frames reception regardless of the state of the bit in the packet filter. Our guess is that this bit is merely obsolete, but what if one day a driver is found that behaves differently?

For such a case, you have a full control over the packet filter with the -pf option of NTRACE.EXE

The -pf option accepts a decimal packet filter value. It can be calculated as sum of the following:

1 for accepting directly addressed frames;

2 for accepting broadcast frames;

4 for accepting foreign frames (promiscuous copy);

8 for accepting source routing frames.

There is no penalty for experimentation with different packet filters. If a particular filter is rejected by the MAC driver, the NTRACE.EXE gives you the following diagnostic message:

SetPacketFilter call returned an error when turning tracing on.

RejectFrames

As we have just learned, in the multiprotocol configuration the effective packet filter may differ from what a particular protocol had ordered. With the tracing mode on, the chances for that difference are much higher. Unfortunately, the VECTOR function does nothing to shield protocols from unwanted frames. What happens if a particular protocol receives a frame of a class it didn't asked for?

It really depends. A well designed protocol has to be tolerant, and most protocols are implemented this way. There may be exceptions, though, and we've found one of them, the LANDD protocol, also known as "IBM IEEE 802.2".

This is the situation where RejectFrames filtering comes handy. Designed originally as a shield, it can be used for a generic filtering out of incoming frames.

The RejectFrames filter works on the NTRACE output, and determines what frames are visible for the rest of the system. The default filter can be set with the PROTOCOL.INI. The NTRACE.EXE has the -rf option to modify this default when necessary. If specified, this value activates an additional filtering of frames the Network Trace makes available to the rest of the system. The primary use of it is to compensate for the promiscuity introduced by the Network Trace driver itself.

The RejectFrames has more categories than PacketFilter does. These are calculated as sum of the following:

1 to deny frames with foreign destination address;

2 to deny broadcast frames;

4 to deny NULL-addressed frames;

16 to deny frames with foreign functional address (token ring only);

32 to deny MAC broadcast frames (token ring only);

64 to deny pure MAC frames (token ring only).

A destination address is considered foreign if it does not match neither the current MAC address nor any of the multicast addresses defined by the time of the frame reception. A functional address is considered foreign if it has no common bits with the current MAC functional address.

To compensate for the MAC promiscuity, use a reject filter of 5 for Ethernet and 21 for Token Ring. This is VERY IMPORTANT when using LAN Server, WorkSpace On-Demand and other NetBIOS and 802.2 applications. It has been found that these applications do NOT expect promiscuous frames and will fail or ABEND if these frames are seen. Other applications and subsystems may also have sensitivity to these frames. In most circumstances, this statement should be included in the NTRACE configuration.

By default, there is no reject filter value. It is highly recommended to set a default value, otherwise when using the products listed above, the user will always be required to remember to use the -rf option when starting NTRACE.EXE.