Forum Replies Created
-
Posts
-
The mere existence of this Packet11 driver suggests that the Miniport/adapter driver architecture does NOT limit the sending of raw 802.11 frames. Some hardware might limit it
…but not the Miniport/adapter driver architecture.Hmm, do you know the nature of the limitation of the 802.11 drivers in Windows?
In other words, what is the DRIVER MODEL limitation inside these 802.11 adapter drivers that prevents them from injecting raw packets ?
By comparison, Linux 802.11 adapter drivers do not have that problem…
That was going to be my next question. The data received by the 802.11 adapter in the monitor mode should not have the MAC address at the beginning of the indicated packet. It must have some other stuff to accommodate the reception of raw management frames, etc…
I am surprised that IM drivers are no longer supported natively on NDIS 6.x.
Does a corresponding “Heavy Wight” filter driver exist on NDIS 6.x, that is the big brother of the Low Weight Filter driver ?
Vadim,
Did you ever investigate your solution #3 further?
Why is this problem with double indications happening anyway?
Where in the driver hierarchy, is the WinPkFlt LWF driver positioned in relation to the current Wireshark’s NPCAP driver ?Is the WinPkFlt LWF driver always BELOW* the Wireshark’s NPCAP driver …or is their relationship affected by their order of installation ?
Is there a diagram of WinPkFlt LWF and NPCAP driver and these pesky NDIS loopbacks anywhere to elucidate all of this ?
* BELOW = closer to the NDIS miniport (adapter driver).
