4

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!

hsluoyz
  • 2,739
  • 5
  • 35
  • 59

1 Answers1

9

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.

Jeffrey Tippet
  • 3,146
  • 1
  • 14
  • 15
  • Thanks for your reply again, Jeffrey:) WinPcap is mainly a layer-2 packet capture software, So I think WFP callout(callback) can be excluded. So maybe 1) NDIS6 protocol and 2) NDIS LWF are the two alternative designs we can pick from. Which one is better? – hsluoyz Aug 07 '13 at 06:43
  • Some doubts from myself are here: 1) albeit a LWF driver is kind of more simple than a NDIS protocol, but under the condition that we already have a ready-to-use NDIS protocol driver, a migration to LWF will take more efforts. 2) what about the functionalities, I know LWF can deny a packet which a NDIS protocl cannot do, but this is also not what WinPcap focuses on, if there are other features like processing loopback packets (ping 127.0.0.1) that LWF can own? 3) what about the performance. Someone told me that the NDIS protocol is more inefficient than a NDIS LWF and even an NDIS IM driver? – hsluoyz Aug 07 '13 at 06:50
  • 1
    Well, if you have a working NDIS protocol, that's 100 points in favor of the NDIS protocol. Architecturally, I'd prefer an NDIS LWF, though. An NDIS LWF will easily win on performance, since it doesn't force the slow loopback path for capturing TX packets. LWFs also can see raw 802.11 packets (including probe response, authentication frames, etc.), which are impossible for protocols to see. – Jeffrey Tippet Aug 08 '13 at 01:03
  • What did you mean by "force the slow loopback path for capturing TX packets"? What is a TX packet? I didn't get it very well. Also as far as I know the currently used WinPcap can capture wireless packets, so 802.11 packets can be seen by a NDIS protocol? Thanks – hsluoyz Aug 08 '13 at 02:53
  • TX is send path, aka egress. RX is receive path, aka ingress. If one protocol sends a packet (TX path), NDIS needs to do a lot of extra work to get that packet over to the receive path of another protocol (RX path). This the slow loopback path. (I wish I had a whiteboard to draw this on....) – Jeffrey Tippet Aug 08 '13 at 19:50
  • WinPcap can see the *data* of 802.11 packets, but it can't see the special 802.11 management frames. The 802.11 protocol has a bunch of extra frames that are a part of layer-2, and don't ever make it up to protocols. This page gives a wrong (or at least, 10 years out-of-date) explanation of the problem: http://wiki.wireshark.org/CaptureSetup/WLAN#Windows . But if you use Microsoft Network Monitor, which is a LWF, you *can* capture these special 802.11 management frames. – Jeffrey Tippet Aug 08 '13 at 19:55
  • It seems that a LWF driver (I found an official phrase: NDIS Filter Driver which owns more links on google) wins over a protocol in both performance and functionality. Indeed, I am a little worried about whether I still have enough time to finish a LWF driver within the Google Summer of Code time span. This is why I'm a little tended to a currently ready-to-use protocol. But now I decide to have a try for LWF:) – hsluoyz Aug 09 '13 at 02:30
  • hello, jeffrey.. I have been reading your answers. Is there any way to contact you in private? I want to code my own virtual access point.. I think I need NDIS for that? Please help me out.. Thank you – Ahmed Can Unbay Feb 23 '23 at 23:40