Rawether Does NOT Allow
Multiple Applications
To Receive
The Same Packet

Symptoms

If multiple WinDis 32 applications access the same adapter concurrently using the same Berkeley Packet Filter (BPF) settings, only one of the applications will receive the packets.

More generally, if multiple adapter handles are opened concurrently (using the W32N_OpenAdapter function) to the same adapter using the same Berkeley Packet Filter (BPF) settings, packets will be received on only ONE of the adapter handles.

Cause

In the current Rawether design all Win32 applications access the lower level NDIS MAC driver via a common NDIS protocol driver (PCANDIS3.VXD, PCANDIS4.SYS or PCANDIS5.SYS). The design of this NDIS protocol driver is such that it only opens the lower level NDIS MAC driver once - regardless of how many Win32 applications are using the Rawether API to access the adapter.

The supporting NDIS protocol driver uses a per-open context structure in kernel mode to maintain separate information for each user mode handle returned by the Rawether W32N_OpenAdapter function. This means that a different BPF can be specified on each user mode adapter handle. The NDIS protocol driver keeps per-open information in a list.

When a packet is received the driver's behavior is simple:

The NDIS protocol driver walks the per-open context list and indicates the received packet on the first user mode handle whose BPF accepts the packet.

The driver does NOT attempt to look further into the per-open context list once the first BPF match is found and satisfied.

Discussion

The memory and processor resources required to "lift" received packets from the kernel mode NDIS protocol driver to the user mode Win32 application are substantial.

In PCAUSA's opinion, a design that would support "lifting" the same packet to more than one application would almost certainly degrade the performance of all applications using the Rawether API and probably degrade the overall performance of the host workstation.

You can explore this behavior using NDIScope and the HookPeek application:

1. Use NDIScope to start two instances of the HookPeek application with both set to capture All Protocols. You will see that the first HookPeek instance that was started will display all packets and the second will not display any packets.
2. Use NDIScope to start two instances of HookPeek. Start the first instance to capture IP Protocols only and the second to capture NetBEUI protocol (for example). In this the first instance of HookPeek will display IP packets and the second instance of HookPeek will display NetBEUI packets.

Suggestions

Consider designs that employ a single principal application or service which is the only application that actually exercises the Rawether API to access NDIS MAC drivers. If other companion applications require packets, consider a design where the principle application provides these packets to the other applications.

Status

Mailing Lists  · PCAUSA Newsletter · PCAUSA Discussion List
· Privacy Statement · 

WinDis 32 is a trademark of Printing Communications Assoc., Inc. (PCAUSA).
Rawether for Windows and Rawether .NET are trademarks of Printing Communications Assoc., Inc. (PCAUSA).
Microsoft, MS, Windows, Windows 95, Windows 98, Windows Millennium, Windows 2000, Windows XP, and Win32 are registered trademarks and Visual C++ and Windows NT are trademarks of the Microsoft Corporation.
Send mail to rawether-webmaster@pcausa.com with questions or comments about this web site.
Copyright © 1996-2008 Printing Communications Assoc., Inc. (PCAUSA).
All rights reserved.
Last modified: December 31, 2007