Frequently Asked Questions

Q. How does NDIS packet filtering work?
 

A. The NDIS packet filter provides a coarse control of the types of network packets for which a protocol receives indications from a NIC driver. Each NDIS protocol individually specifies its desired NDIS packet filter setting by making a NDIS request to set information on OID_GEN_CURENT_PACKET_FILTER. The NDIS packet filter value that a protocol can specify consists of a bit field that can be a combination of several values defined in the DDK. Important values are:

Notice that a NDIS packet filter value of zero disables packet reception. When a protocol makes the NdisOpenAdapter call NDIS sets the initial packet filter value to zero; so, a protocol will not receive any packets until it makes a subsequent call to set the packet filter to a non-zero value.

It is important for a protocol to check the return status when setting the NDIS packet filter since not all NICs accept all NDIS packet filter settings. For example, most 802.3 NICs will accept the NDIS_PACKET_FILTER_TYPE_PROMISCUOUS setting needed for network monitoring. However, if the NIC is actually a 802.11 adapter the setting will fail; in this case it is necessary to fall back to the "next best thing" which would probably be NDIS_PACKET_TYPE_ALL_LOCAL.

Each NDIS protocol's NDIS packet filter is independent from the NDIS packet filter's set by other NDIS protocols. So, for example, if a protocol sets it's packet filter value to zero, that has no influence on whether other protocols bound to the same adapter will receive packets.

NDIS does not "drop" any packets. As packets are received on a NIC and indicated "upwards" to protocols that are bound to it NDIS will examine each packet on a per-protocol basis. If the packet satisfies a protocol's NDIS packet filter setting, then the packet will be indicated to that protocol. NDIS will do this for all protocols bound to a given NIC.

Packets that satisfy a protocol's NDIS packet filter setting are passed to the protocol's ProtocolReceive or ProtocolReceivePackets handlers. The protocol usually takes a quick look at the packet and decides whether or not it will accept the packet for further processing. If a packet is accepted by one protocol it will still be indicated to all other protocols (assuming that it satisfies their NDIS packet filter settings).

This means quite specifically that one NDIS protocol driver cannot "block" packets from being received by other NDIS protocol drivers. You must use a NDIS Intermediate (IM) filter driver to block packets.

In January, 2005 there was a discussion in the microsoft.public.development.device.drivers newsgroup concerning how NDIS actually implements NDIS packet filters. Alireza Dabagh of Microsoft had this to say:

"What NDIS does (as far as filtering the packets goes) is first to coalesce all the packet filters and multicast addresses set by different protocols and send them as appropriate "aggregated" requests (OID_GEN_PACKET_FILTER and OID_802_3_MULTICAST_LIST) to the underlying miniport. Miniports are required to only report packets that match the filters set by these "aggregated" requests and nothing more. NDIS then goes through all the packets and makes sure each protocol only gets those packets that match the filter set by that particular protocol."
 

PCAUSA Home · Privacy Statement · Products · Ordering · Support · Utilities · Resources
Mailing Lists  · PCAUSA Newsletter · PCAUSA Discussion List

Rawether for Windows, Rawether .NET, WinDis 32 and NDIS Press are trademarks of Printing Communications Assoc., Inc. (PCAUSA)
Microsoft, MS, Windows, Windows Vista, Windows 95, Windows 98, Windows Millennium, Windows 2000, and Win32 are registered trademarks and Visual C++ and Windows NT are trademarks of the Microsoft Corporation.
Copyright © 1996-2007 Printing Communications Assoc., Inc. (PCAUSA)
Last modified: January 20, 2007