NDIS筛选器使用NdisFSendNetBufferLists时是否必须FilterSendNetBufferLists处理程序? [英] Is FilterSendNetBufferLists handler a must for an NDIS filter to use NdisFSendNetBufferLists?

问题描述

每个人，我都将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进入堆栈.

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

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.

这篇关于NDIS筛选器使用NdisFSendNetBufferLists时是否必须FilterSendNetBufferLists处理程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！