Rawether Does NOT Allow
Multiple Applications
To Receive
The Same Packet
Knowledge Base ID
KB09230001
Category
LIMITATION
Effected Product
Rawether/WINDIS32 - Win32 NDIS Framework
Effected Versions
All
Effected Platforms
All
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:
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.
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
September 25, 2000
There are no current plans to remove this limitation.
Keywords
RAWETHER,WINDIS32, LIMITATION
Created
September 25, 2000
Last Reviewed
September 25, 2000
