Can a NDIS protocol driver (npf.sys of WinPcap) be ported to LWF or WFP?

Question

everyone. I am doing some improvements for WinPcap. Now I have ported the npf.sys driver from NDIS5.0 to NDIS6.0. Is there still improvement space for this driver, like porting it to LWF (Light-Weight Filter) or WFP (Windows Filter Platform)? We just want to make sure to use a newer and better framework.

Here're some other questions:

It seems that LWF is a product in the Vista time, and now it's not much mentioned by Microsoft, is this true?

Can a LWF or a WFP driver do things that a NDIS protocol driver can do?

Does LWF or WFP have relation with WDF (Windows Driver Framework), or compatible with both WDF and WDM framework?

If this is viable to port, how about the difficulty, I have developed some NDIS Intermediate drivers before, does LWF or WFP harder or easier than that?

Thanks!

Answer 1

Congratulations on porting WinPcap to NDIS 6.x. I'm impressed. I hope you can convince upstream to take your changes :-)

Regarding LWFs

LWFs are still quite supported by Microsoft. We don't talk about them much, simply because there is limited interest in them. Most people really want to work at layer-3 or layer-4, where they are better served by WFP than by a LWF. However, a low-level packet capturing toolkit is a perfect example of what LWFs are good for.

We are happy to see people write new LWFs, WFP callouts, NDIS miniports, or NDIS protocols. These are all supported and current technologies. (Assuming NDIS 6.x for the miniport & protocol).

Comparing LWFs, NDIS protocols, and WFP callouts

A LWF can do almost anything that an NDIS protocol driver can do. There are a few small corner cases, but generally you'll find that LWFs are powerful.

WFP callouts operate at a different layer, and so have rather different strengths and weaknesses than an NDIS protocol or LWF. For example, a WFP callout cannot interact with media-connect state, hardware offloads, or power management. But unlike NDIS LWFs, a WFP callout can peer into the plaintext of an IPsec-protected packet, query the identity of the user/application that originally sent a packet, intercept loopback IP traffic, and authorize the creation of a socket itself (before any traffic is sent).

You should sit down and ask yourself: "Which layer of the network stack am I really interested in?" If the answer is layer-2, then go ahead with an NDIS driver. If it's layer-3 or layer-4 of the IPv4/6 stack, then you'll want a WFP callout. (Some people start with an NDIS driver because they're most familiar with NDIS, but then run into difficulties because they're actually trying to solve a problem at the TCP layer.)

Using WDF with NDIS or WFP

WDF is largely orthogonal to NDIS or WFP. You can choose to use either WDF or WDM or a mix of both in your NDIS driver or WFP callout. Microsoft, the NDIS team and I officially encourage you to use WDF as much as possible, since it will save you time and make your driver higher-quality.

Generally if your LWF or NDIS protocol is just a basic "hello world" driver, WDF will work fine, but won't be terribly useful. WDF doesn't help much with the part of your driver that interacts with NDIS. But as soon as you add an IOCTL to usermode (or any other non-NDIS trick), WDF can spare you a lot of time and bugs.

Difficulty of LWFs and WFP callouts

I think you'll find that NDIS LWFs and WFP callouts are some of the easiest network drivers to write. A LWF is easier than an NDIS protocol driver, and much easier than an NDIS IM driver. A complete do-nothing LWF driver is only about 20 lines of code. WFP callouts are no more difficult to write than an LWF.