NDIS筛选器使用NdisFSendNetBufferLists时是否必须FilterSendNetBufferLists处理程序?

本文介绍了NDIS筛选器使用NdisFSendNetBufferLists时是否必须FilterSendNetBufferLists处理程序?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

每个人，我都将WinPcap从NDIS6协议移植到NDIS6过滤器.已经快完成了，但是我还有一个问题:

ndislwf的评论说:不提供FilerSendNetBufferList处理程序的过滤器不能自行发起发送."这是否意味着如果我使用了NdisFSendNetBufferLists函数，我必须提供FilerSendNetBufferList处理程序?我的驱动程序将通过NdisFSendNetBufferLists发送自构造的数据包，但我不想过滤其他程序的已发送数据包.

与FilterReturnNetBufferLists相同，它说:不提供FilterReturnNetBufferLists处理程序的过滤器无法自行发出接收指示.". 发出接收指示"是什么意思? NdisFIndicateReceiveNetBufferLists或NdisFReturnNetBufferLists还是两者兼而有之?另外，对于我的驱动程序，我只想捕获收到的数据包，而不是返回的数据包.因此，如果可能的话，我不想出于性能目的而提供FilterReturnNetBufferLists函数.

另一个类似的情况是FilterOidRequestComplete和NdisFOidRequest，实际上我的过滤器驱动程序只希望通过NdisFOidRequest自己发送Oid请求，而不是过滤其他人发送的Oid请求.我可以将FilterOidRequest，FilterCancelOidRequest和FilterOidRequestComplete保留为NULL吗?还是必须使用NdisFOidRequest中的哪一个?

谢谢.

解决方案

发送和接收

LWF可以是:

• 完全从发送路径中排除，看不到其他协议的发送流量，并且无法发送自己的任何流量；或
• 已集成到发送路径中，能够查看和过滤其他协议的发送和发送完成流量，并能够注入自己的流量

这是一个全有或全无的模型.由于要发送自己的自构造数据包，因此必须 安装FilterSendNetBufferLists处理程序和FilterSendNetBufferListsComplete处理程序.如果您对其他协议的流量不感兴趣，则您的发送处理程序可以与示例的发送处理程序一样简单-—只需将所有内容转储到NdisFSendNetBufferLists而不查看它.

FilterSendNetBufferListsComplete处理程序需要更加小心.遍历所有已完成的NBL，并挑选出您发送的NBL.您可以通过查看NET_BUFFER_LIST::SourceHandle识别发送的数据包.从流中删除它们(可能重新使用它们，或者只是NdisFreeNetBufferList它们).然后，所有其他数据包都通过NdisFSendNetBufferListsComplete进入堆栈.

以上讨论也适用于接收路径.发送和接收之间的唯一区别是，在接收路径上，您必须密切注意 NDIS_RECEIVE_FLAGS_RESOURCES 标志.

OID请求

与数据路径一样，如果您想完全参与OID请求(过滤或发出自己的请求)，则必须将其集成到整个OID堆栈中.这意味着您提供了FilterOidRequest，FilterOidRequestComplete和FilterCancelOidRequest处理程序.除了再次检测样本中过滤器源自oid-complete处理程序的OID请求，并从流中删除这些请求(在它们上调用NdisFreeCloneOidRequest)之外，您无需在这些处理程序中做任何特别的事情，除了再次检测OID请求./p> 性能

请不要担心此处的性能.第一步是使其正常运行.即使样本过滤器将自己插入到发送，接收和OID路径中；几乎不可能提出任何可以检测到样品过滤器存在的基准.在过滤器中不执行处理程序非常便宜.

如果您对此非常有信心，则可以 通过调用NdisFRestartFilter和NdisSetOptionalHandlers(NDIS_FILTER_PARTIAL_CHARACTERISTICS)有选择地从数据路径中删除过滤器.但是我绝对不认为您需要复杂性.如果您来自以混杂模式捕获的NDIS 5协议，那么通过切换到本机网络数据结构(NDIS_PACKET-> NBL)并消除环回路径，您已经获得了很大的性能提升.您可以对下一个版本进行其他微调.

everyone, I am porting the WinPcap from NDIS6 protocol to NDIS6 filter. It is nearly finished, but I still have a bit of questions:

The comment of ndislwf said "A filter that doesn't provide a FilerSendNetBufferList handler can not originate a send on its own." Does it mean if I used the NdisFSendNetBufferLists function, I have to provide the FilerSendNetBufferList handler? My driver will send self-constructed packets by NdisFSendNetBufferLists, but I don't want to filter other programs' sent packets.

The same as the FilterReturnNetBufferLists, it said "A filter that doesn't provide a FilterReturnNetBufferLists handler cannot originate a receive indication on its own.". What does "originate a receive indication" mean? NdisFIndicateReceiveNetBufferLists or NdisFReturnNetBufferLists or both? Also, for my driver, I only want to capture received packets instead of the returned packets. So if possible, I don't want to provide the FilterReturnNetBufferLists function for performance purpose.

Another ressembled case is FilterOidRequestComplete and NdisFOidRequest, in fact my filter driver only want to send Oid requests itself by NdisFOidRequest instead of filtering Oid requests sent by others. Can I leave the FilterOidRequest, FilterCancelOidRequest and FilterOidRequestComplete to NULL? Or which one is a must to use NdisFOidRequest?

Thx.

解决方案

Send and Receive

A LWF can either be:

• completely excluded from the send path, unable to see other protocols' send traffic, and unable to send any of its own traffic; or
• integrated into the send path, able to see and filter other protocols' send and send-complete traffic, and able to inject its own traffic

It's an all-or-nothing model. Since you want to send your own self-constructed packets, you must install a FilterSendNetBufferLists handler and a FilterSendNetBufferListsComplete handler. If you're not interested in other protocols' traffic, then your send handler can be as simple as the sample's send handler — just dump everything into NdisFSendNetBufferLists without looking at it.

The FilterSendNetBufferListsComplete handler needs to be a little more careful. Iterate over all the completed NBLs and pick out the ones that you sent. You can identify the packets you sent by looking at NET_BUFFER_LIST::SourceHandle. Remove those from the stream (possibly reusing them, or just NdisFreeNetBufferList them). All the other packets then go up the stack via NdisFSendNetBufferListsComplete.

The above discussion also applies to the receive path. The only difference between send and receive is that on the receive path, you must pay close attention to the NDIS_RECEIVE_FLAGS_RESOURCES flag.

OID requests

Like the datapath, if you want to participate in OID requests at all (either filtering or issuing your own), you must be integrated into the entire OID stack. That means that you provide FilterOidRequest, FilterOidRequestComplete, and FilterCancelOidRequest handlers. You don't need to do anything special in these handlers beyond what the sample does, except again detecting OID requests that your filter originated in the oid-complete handler, and removing those from the stream (call NdisFreeCloneOidRequest on them).

Performance

Do not worry about performance here. The first step is to get it working. Even though the sample filter inserts itself into the send, receive, and OID paths; it's almost impossible to come up with any sort of benchmark that can detect the presence of the sample filter. It's extremely cheap to have do-nothing handlers in a filter.

If you feel very strongly about this, you can selectively remove your filter from the datapath with calls to NdisFRestartFilter and NdisSetOptionalHandlers(NDIS_FILTER_PARTIAL_CHARACTERISTICS). But I absolutely don't think you need the complexity. If you're coming from an NDIS 5 protocol that was capturing in promiscuous mode, you've already gotten a big perf improvement by switching to the native networking data structures (NDIS_PACKET->NBL) and eliminating the loopback path. You can leave additional fine-tuning to the next version.