PacketFilter and promiscuous mode

NTDEV
1

I have an NDIS 6 miniport driver I am getting to work under Windows 7. The code is based on the WDK sample C:\WinDDK\7600.16385.1\src\network\ndis\athwifi\driver.
There is also a NDIS protocol driver that is based on the WDK sample C:\WinDDK\7600.16385.1\src\network\ndis\ndisprot\60\sys.
There is a test program to exercise the two drivers. When I put the miniport driver into promiscuous mode I do the following in the test program:

send an IOCtl (IOCTL_NPD_SET_OID_VALUE) with an OID (OID_ATH_MONITOR_MODE) that tells the miniport driver to switch to promiscuous mode. The buffer looks like this,
OID_ATH_MONITOR_MODE
0 // default port
enable/disable

when the above IOCtl completes with STATUS_SUCCESS, I send an IOCtl (IOCTL_NPD_SET_OID_VALUE) with an OID (OID_GEN_CURRENT_PACKET_FILTER) that sets PacketFilter to NDIS_PACKET_TYPE_ALL_LOCAL. The buffer looks like this,
OID_GEN_CURRENT_PACKET_FILTER
0 // default port
NDIS_PACKET_TYPE_ALL_LOCAL

when the first IOCtl completes with STATUS_SUCCESS, I send an IOCtl (IOCTL_NPD_SET_OID_VALUE) with an OID (OID_ATH_CHANNEL) that sets the frequency to the requested frequency. The buffer looks like this,
OID_ATH_PRAXIS_CHANNEL
0 // default port
_frequency
_chanFlags

I also manually disconnect the NIC from any wireless access point. I will programmatically do this soon. Note, PacketFilter is automatically set to 0x20001 when I disconnect. I am not doing this. I assume the worker thread is doing this for NDIS. All three IOCtls return STATUS_SUCCESS after returning STATUS_PENDING.

Here is my problem. Packets are detected and rejected in my miniport receive filter (identical to the sample filter) as PacketFilter is still set to 0x20001. Am I taking the right approach to getting packets to make their way up the stack to the test program? My IOCtl to set PacketFilter succeeded, yet was never detected in any of my miniport code. When the request came down from my test program to the protocl driver, I stepped into NDIS far enough to see the request get queued. It then returned STATUS_PENDING then a STATUS_SUCCESS, but my miniport never received the request.

Basically, in an NDIS 6 miniport running under Win 7 how do I get packets to go up the stack to my protocol driver. Once it has them, the rest should be easy.

This looks like my last hurdle, but it has me stumped.

Thanks,
Paul

2

You need to understand that the Microsoft Native Wi-Fi filter is inserted
between any NDIS protocol and any Native 802.11 miniport. So, when your
protocol makes an NidsOidRequest call to set an OID value that call goes
first to the Microsoft Native Wi-Fi filter. What it does with your OID is
totally unknown.

Of course, the WDL NdisProt sample only understands Ethernet
(NdisMedium802_3) frames. See ndisprotCreateBinding. So, if you don’t have
Ethernet traffic passing through your adapter the protocol will not see it.

See if there is a way to use the Microsoft user-mode Native 802.11 API to
set the mode to DOT11_OPERATION_MODE_NETWORK_MONITOR. Perhaps that turns on
your monitor mode.

The Microsoft user-mode Native 802.11 API talks to the Microsoft Native
Wi-Fi filter. The Microsoft Native Wi-Fi filter is really the only software
component that Microsoft thinks should actually interface directly with any
Native 802.11 miniport.

You can try the experimental PCAUSA “Wireless LAB Explorer” (WLANExplorer)
to see if it can see any of your packets can be seen. Of course, it doesn’t
know about your proprietary OID_ATH_MONITOR_MODE OID.

http://www.pcausa.com/WlanExplorer/

Good luck,

Thomas F. Divine
http://www.pcausa.com

From:
Sent: Thursday, April 28, 2011 2:22 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] PacketFilter and promiscuous mode

> I have an NDIS 6 miniport driver I am getting to work under Windows 7. The
> code is based on the WDK sample
> C:\WinDDK\7600.16385.1\src\network\ndis\athwifi\driver.
> There is also a NDIS protocol driver that is based on the WDK sample
> C:\WinDDK\7600.16385.1\src\network\ndis\ndisprot\60\sys.
> There is a test program to exercise the two drivers. When I put the
> miniport driver into promiscuous mode I do the following in the test
> program:
>
> send an IOCtl (IOCTL_NPD_SET_OID_VALUE) with an OID (OID_ATH_MONITOR_MODE)
> that tells the miniport driver to switch to promiscuous mode. The buffer
> looks like this,
> OID_ATH_MONITOR_MODE
> 0 // default port
> enable/disable
>
> when the above IOCtl completes with STATUS_SUCCESS, I send an IOCtl
> (IOCTL_NPD_SET_OID_VALUE) with an OID (OID_GEN_CURRENT_PACKET_FILTER) that
> sets PacketFilter to NDIS_PACKET_TYPE_ALL_LOCAL. The buffer looks like
> this,
> OID_GEN_CURRENT_PACKET_FILTER
> 0 // default port
> NDIS_PACKET_TYPE_ALL_LOCAL
>
> when the first IOCtl completes with STATUS_SUCCESS, I send an IOCtl
> (IOCTL_NPD_SET_OID_VALUE) with an OID (OID_ATH_CHANNEL) that sets the
> frequency to the requested frequency. The buffer looks like this,
> OID_ATH_PRAXIS_CHANNEL
> 0 // default port
> _frequency
> _chanFlags
>
> I also manually disconnect the NIC from any wireless access point. I will
> programmatically do this soon. Note, PacketFilter is automatically set to
> 0x20001 when I disconnect. I am not doing this. I assume the worker thread
> is doing this for NDIS. All three IOCtls return STATUS_SUCCESS after
> returning STATUS_PENDING.
>
> Here is my problem. Packets are detected and rejected in my miniport
> receive filter (identical to the sample filter) as PacketFilter is still
> set to 0x20001. Am I taking the right approach to getting packets to make
> their way up the stack to the test program? My IOCtl to set PacketFilter
> succeeded, yet was never detected in any of my miniport code. When the
> request came down from my test program to the protocl driver, I stepped
> into NDIS far enough to see the request get queued. It then returned
> STATUS_PENDING then a STATUS_SUCCESS, but my miniport never received the
> request.
>
> Basically, in an NDIS 6 miniport running under Win 7 how do I get packets
> to go up the stack to my protocol driver. Once it has them, the rest
> should be easy.
>
> This looks like my last hurdle, but it has me stumped.
>
> Thanks,
> Paul
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

3

Thomas,
Thank you for your response.

I will definitely take a look at the Microsoft user-mode Native 802.11 API to see if it helps. Not having a custom protocol driver would be nice. The only real changes that have been made to the sample prot driver are adding OIDs to the valid list.

I have seen the wifi filter on the stack. On some of my user-mode calls it is there and sometimes it isn’t. I am fairly certain that my IOCtl approach works on everything, but the PacketFilter. I could see where the filter driver might handle that request. I’m thinking I need to use the actual port address and not the default port of 0. With the IOCtl approach, every call ends up right where I want it to be in the miniport and the data is untouched. Still if API’s are available, I will look into how quickly I can implement them. Time is an issue.

Thanks again,
Paul

4

Sometimes the behavior is that your OID will be passed down…

But later the Microsoft software will find out that the adapter isn’t
configured the way IT expects it to be configured. It will then reconfigure
the adapter to suit it’s grand plan.

The proverb goes like this: “No 802.11 miniport can obey two masters.”

If the Microsoft 802.11 software is running it will probably interfere with
anything you are trying to do.

Good luck!!!

Thomas F. Divine
http://www.pcausa.com

From:
Sent: Thursday, April 28, 2011 3:58 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] PacketFilter and promiscuous mode

> Thomas,
> Thank you for your response.
>
> I will definitely take a look at the Microsoft user-mode Native 802.11 API
> to see if it helps. Not having a custom protocol driver would be nice. The
> only real changes that have been made to the sample prot driver are adding
> OIDs to the valid list.
>
> I have seen the wifi filter on the stack. On some of my user-mode calls it
> is there and sometimes it isn’t. I am fairly certain that my IOCtl
> approach works on everything, but the PacketFilter. I could see where the
> filter driver might handle that request. I’m thinking I need to use the
> actual port address and not the default port of 0. With the IOCtl
> approach, every call ends up right where I want it to be in the miniport
> and the data is untouched. Still if API’s are available, I will look into
> how quickly I can implement them. Time is an issue.
>
> Thanks again,
> Paul
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer