PRB: Multicast packets Might Pass through Despite MAC Filtering

• Microsoft Win32 Device Driver Kit (DDK) for Windows NT, version 4.0

SYMPTOMS

Although Multicast definition requires that we have the first bit set to 1, Windows NT 4.0 might not filter the packets correctly if the multicast definition was used randomly.

CAUSE

Our source code only checks for the first byte for broadcast packet filtering.

RESOLUTION

Use a bit in the first byte, except the first bit, to differentiate a proprietary multicast address.

STATUS

This behavior is by design.

MORE INFORMATION

The Microsoft filter code checks to see whether or not the first byte contains 0xFF. If so, it sees this as a broadcast packet and passes it through. However, the definition states a broadcast as FFFFFFFFFFFF.

In the meantime, the definition of the multicast packet is indicated (if the first byte is 1, it is a multicast). For example, if the multicast packet definition is set as FF35FFFFFFFF, it would pass through the Microsoft filter code as a broadcast because the first byte is FF. Typically, this should not happen because all standard networks use the first byte to identify their multicast packet (for example, Appletalk as 0x09, NetBEUI as 0x03). If you are using the Microsoft IP, your users should not experience this problem.

• If the broadcast filter is set, NDIS filter passes up all packets with first byte 0xFF, whether it is broadcast or multicast.



• If broadcast is not set, NDIS will not pass up any mcast packets whose mcast address starts with 0xFF.



• Since IP and Appletalk enforce mechanisms whereby associated 802.3 multicast addresses never have first byte 0xFF, the above NDIS behavior might be acceptable.

Additional query words: Broadcast Multicast Filter

Keywords : kbDDK kbNDIS kbNTOS400
Version :
Platform :
Issue type : kbprb