Hi,
I’ve modified the ndislwf to be a monitoring filter that binds below at the native 802.11 layer (below native wifi) at the “custom” level in Windows Vista. The sample works great, but the problem is whenever I install the driver it prevents network connectivity. I’m NOT putting it into monitor mode or some such where it can’t sustain active connections, nor have I changed anything in ndislwf that, as far as I know, would cause this (it’s still a “pass through” filter). When I do an “ipconfig /all” in a command window after it has been installed, the 802.11 device does not appear. Also, using Window’s “connect to wireless network” feature, I can see the other wireless networks with the driver installed, but attempting to connect to them fails.
The cause of this has been eluding me and any suggestions would be greatly appreciated!
Here are a couple of tangentially related threads I could find:
http://www.osronline.com/showthread.cfm?link=131689
https://www.osronline.com/cf.cfm?PageURL=showThread.CFM?link=134437
You have something screwed up. I know that a NDIS 6 monitoring filter can be
installed below Native Wi-Fi and allow connectivity to continue.
For a monitoring filter you don’t need a custom class - at least not at
first. A monitoring filter installs multiple instances at different
“altitudes” above the Native Wi-Fi miniport. One should be below the Native
Wi-Fi filter and another below the Virtual Wi-Fi filter (if it is
installed).
Probably something in your Custom level logic is causing a problem.
Good luck,
Thomas F. Divine
http://www.pcausa.com
From:
Sent: Wednesday, January 06, 2010 6:27 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Using ndislwf as monitoring filter kills network
connectivty
> Hi,
>
> I’ve modified the ndislwf to be a monitoring filter that binds below at
> the native 802.11 layer (below native wifi) at the “custom” level in
> Windows Vista. The sample works great, but the problem is whenever I
> install the driver it prevents network connectivity. I’m NOT putting it
> into monitor mode or some such where it can’t sustain active connections,
> nor have I changed anything in ndislwf that, as far as I know, would cause
> this (it’s still a “pass through” filter). When I do an “ipconfig /all”
> in a command window after it has been installed, the 802.11 device does
> not appear. Also, using Window’s “connect to wireless network” feature, I
> can see the other wireless networks with the driver installed, but
> attempting to connect to them fails.
>
> The cause of this has been eluding me and any suggestions would be greatly
> appreciated!
>
> Here are a couple of tangentially related threads I could find:
> http://www.osronline.com/showthread.cfm?link=131689
> https://www.osronline.com/cf.cfm?PageURL=showThread.CFM?link=134437
>
> —
> 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
The problem was I was telling it to fail if it tried to bind to 802.3, which I had it set to (I think) cause the whole stack to be torn down. Thanks for your help! Just out of curiosity, what reason would there to NOT use “custom” level logic? If I’m the only filter on my system and I want to be as close to the miniport as possible, how could it hurt? The MS documentation makes it seem as if it only effects the stacking order if there are multiple filters of the same type on an adapter.