c - 未调用 NDIS 筛选器驱动程序的 FilterReceiveNetBufferLists 处理程序

Question

我正在开发一个 NDIS 过滤器驱动程序，我发现它FilterReceiveNetBufferLists在某些条件下（如打开 Wireshark 或单击它的“接口列表”按钮）从未被调用（网络被阻塞）。但是当我开始捕获时，FilterReceiveNetBufferLists得到正常（网络恢复），这太奇怪了。

我发现当我手动返回WinPcap 驱动程序的 OID 起源位置（NPF_IoControl 的 BIOCQUERYOID 和 BIOCSETOID 开关分支）中NDIS_STATUS_FAILURE的NdisFOidRequest函数时，驱动程序不会阻塞网络（winpcap 也无法工作）。

NdisFOidRequest通话有问题吗？

Packet.c 中发起 OID 请求的 DeviceIO 例程：

case BIOCQUERYOID:
case BIOCSETOID:

    TRACE_MESSAGE(PACKET_DEBUG_LOUD, "BIOCSETOID - BIOCQUERYOID");

    //
    // gain ownership of the Ndis Handle
    //
    if (NPF_StartUsingBinding(Open) == FALSE)
    {
        //
        // MAC unbindind or unbound
        //
        SET_FAILURE_INVALID_REQUEST();
        break;
    }


    // Extract a request from the list of free ones
    RequestListEntry = ExInterlockedRemoveHeadList(&Open->RequestList, &Open->RequestSpinLock);
    if (RequestListEntry == NULL)
    {
        //
        // Release ownership of the Ndis Handle
        //
        NPF_StopUsingBinding(Open);

        SET_FAILURE_NOMEM();
        break;
    }

    pRequest = CONTAINING_RECORD(RequestListEntry, INTERNAL_REQUEST, ListElement);

    //
    //  See if it is an Ndis request
    //
    OidData = Irp->AssociatedIrp.SystemBuffer;

    if ((IrpSp->Parameters.DeviceIoControl.InputBufferLength == IrpSp->Parameters.DeviceIoControl.OutputBufferLength) &&
        (IrpSp->Parameters.DeviceIoControl.InputBufferLength >= sizeof(PACKET_OID_DATA)) &&
        (IrpSp->Parameters.DeviceIoControl.InputBufferLength >= sizeof(PACKET_OID_DATA) - 1 + OidData->Length))
    {
        TRACE_MESSAGE2(PACKET_DEBUG_LOUD, "BIOCSETOID|BIOCQUERYOID Request: Oid=%08lx, Length=%08lx", OidData->Oid, OidData->Length);

        //
        //  The buffer is valid
        //
        NdisZeroMemory(&pRequest->Request, sizeof(NDIS_OID_REQUEST));
        pRequest->Request.Header.Type = NDIS_OBJECT_TYPE_OID_REQUEST;
        pRequest->Request.Header.Revision = NDIS_OID_REQUEST_REVISION_1;
        pRequest->Request.Header.Size = NDIS_SIZEOF_OID_REQUEST_REVISION_1;

        if (FunctionCode == BIOCSETOID)
        {
            pRequest->Request.RequestType = NdisRequestSetInformation;
            pRequest->Request.DATA.SET_INFORMATION.Oid = OidData->Oid;

            pRequest->Request.DATA.SET_INFORMATION.InformationBuffer = OidData->Data;
            pRequest->Request.DATA.SET_INFORMATION.InformationBufferLength = OidData->Length;
        }
        else
        {
            pRequest->Request.RequestType = NdisRequestQueryInformation;
            pRequest->Request.DATA.QUERY_INFORMATION.Oid = OidData->Oid;

            pRequest->Request.DATA.QUERY_INFORMATION.InformationBuffer = OidData->Data;
            pRequest->Request.DATA.QUERY_INFORMATION.InformationBufferLength = OidData->Length;
        }

        NdisResetEvent(&pRequest->InternalRequestCompletedEvent);

        if (*((PVOID *) pRequest->Request.SourceReserved) != NULL)
        {
            *((PVOID *) pRequest->Request.SourceReserved) = NULL;
        }
        //
        //  submit the request
        //
        pRequest->Request.RequestId = (PVOID) NPF6X_REQUEST_ID;
        ASSERT(Open->AdapterHandle != NULL);
        Status = NdisFOidRequest(Open->AdapterHandle, &pRequest->Request);
        //Status = NDIS_STATUS_FAILURE;
    }
    else
    {
        //
        // Release ownership of the Ndis Handle
        //
        NPF_StopUsingBinding(Open);

        //
        //  buffer too small
        //
        SET_FAILURE_BUFFER_SMALL();
        break;
    }

    if (Status == NDIS_STATUS_PENDING)
    {
        NdisWaitEvent(&pRequest->InternalRequestCompletedEvent, 1000);
        Status = pRequest->RequestStatus;
    }

    //
    // Release ownership of the Ndis Handle
    //
    NPF_StopUsingBinding(Open);

    //
    // Complete the request
    //
    if (FunctionCode == BIOCSETOID)
    {
        OidData->Length = pRequest->Request.DATA.SET_INFORMATION.BytesRead;
        TRACE_MESSAGE1(PACKET_DEBUG_LOUD, "BIOCSETOID completed, BytesRead = %u", OidData->Length);
    }
    else
    {
        if (FunctionCode == BIOCQUERYOID)
        {
            OidData->Length = pRequest->Request.DATA.QUERY_INFORMATION.BytesWritten;

            if (Status == NDIS_STATUS_SUCCESS)
            {
                //
                // check for the stupid bug of the Nortel driver ipsecw2k.sys v. 4.10.0.0 that doesn't set the BytesWritten correctly
                // The driver is the one shipped with Nortel client Contivity VPN Client V04_65.18, and the MD5 for the buggy (unsigned) driver
                // is 3c2ff8886976214959db7d7ffaefe724 *ipsecw2k.sys (there are multiple copies of this binary with the same exact version info!)
                // 
                // The (certified) driver shipped with Nortel client Contivity VPN Client V04_65.320 doesn't seem affected by the bug.
                //
                if (pRequest->Request.DATA.QUERY_INFORMATION.BytesWritten > pRequest->Request.DATA.QUERY_INFORMATION.InformationBufferLength)
                {
                    TRACE_MESSAGE2(PACKET_DEBUG_LOUD, "Bogus return from NdisRequest (query): Bytes Written (%u) > InfoBufferLength (%u)!!", pRequest->Request.DATA.QUERY_INFORMATION.BytesWritten, pRequest->Request.DATA.QUERY_INFORMATION.InformationBufferLength);

                    Status = NDIS_STATUS_INVALID_DATA;
                }
            }

            TRACE_MESSAGE1(PACKET_DEBUG_LOUD, "BIOCQUERYOID completed, BytesWritten = %u", OidData->Length);
        }
    }


    ExInterlockedInsertTailList(&Open->RequestList, &pRequest->ListElement, &Open->RequestSpinLock);

    if (Status == NDIS_STATUS_SUCCESS)
    {
        SET_RESULT_SUCCESS(sizeof(PACKET_OID_DATA) - 1 + OidData->Length);
    }
    else
    {
        SET_FAILURE_INVALID_REQUEST();
    }

    break;

三个过滤器 OID 例程：

_Use_decl_annotations_
NDIS_STATUS
NPF_OidRequest(
    NDIS_HANDLE         FilterModuleContext,
    PNDIS_OID_REQUEST   Request
    )
{
    POPEN_INSTANCE          Open = (POPEN_INSTANCE) FilterModuleContext;
    NDIS_STATUS             Status;
    PNDIS_OID_REQUEST       ClonedRequest=NULL;
    BOOLEAN                 bSubmitted = FALSE;
    PFILTER_REQUEST_CONTEXT Context;
    BOOLEAN                 bFalse = FALSE;

    TRACE_ENTER();

    do
    {
        Status = NdisAllocateCloneOidRequest(Open->AdapterHandle,
                                            Request,
                                            NPF6X_ALLOC_TAG,
                                            &ClonedRequest);
        if (Status != NDIS_STATUS_SUCCESS)
        {
            TRACE_MESSAGE(PACKET_DEBUG_LOUD, "FilerOidRequest: Cannot Clone Request\n");
            break;
        }

        Context = (PFILTER_REQUEST_CONTEXT)(&ClonedRequest->SourceReserved[0]);
        *Context = Request;

        bSubmitted = TRUE;

        //
        // Use same request ID
        //
        ClonedRequest->RequestId = Request->RequestId;

        Open->PendingOidRequest = ClonedRequest;

        Status = NdisFOidRequest(Open->AdapterHandle, ClonedRequest);

        if (Status != NDIS_STATUS_PENDING)
        {
            NPF_OidRequestComplete(Open, ClonedRequest, Status);
            Status = NDIS_STATUS_PENDING;
        }


    }while (bFalse);

    if (bSubmitted == FALSE)
    {
        switch(Request->RequestType)
        {
            case NdisRequestMethod:
                Request->DATA.METHOD_INFORMATION.BytesRead = 0;
                Request->DATA.METHOD_INFORMATION.BytesNeeded = 0;
                Request->DATA.METHOD_INFORMATION.BytesWritten = 0;
                break;

            case NdisRequestSetInformation:
                Request->DATA.SET_INFORMATION.BytesRead = 0;
                Request->DATA.SET_INFORMATION.BytesNeeded = 0;
                break;

            case NdisRequestQueryInformation:
            case NdisRequestQueryStatistics:
            default:
                Request->DATA.QUERY_INFORMATION.BytesWritten = 0;
                Request->DATA.QUERY_INFORMATION.BytesNeeded = 0;
                break;
        }

    }

    TRACE_EXIT();
    return Status;

}

//-------------------------------------------------------------------

_Use_decl_annotations_
VOID
NPF_CancelOidRequest(
    NDIS_HANDLE             FilterModuleContext,
    PVOID                   RequestId
    )
{
    POPEN_INSTANCE                      Open = (POPEN_INSTANCE) FilterModuleContext;
    PNDIS_OID_REQUEST                   Request = NULL;
    PFILTER_REQUEST_CONTEXT             Context;
    PNDIS_OID_REQUEST                   OriginalRequest = NULL;
    BOOLEAN                             bFalse = FALSE;

    FILTER_ACQUIRE_LOCK(&Open->OIDLock, bFalse);

    Request = Open->PendingOidRequest;

    if (Request != NULL)
    {
        Context = (PFILTER_REQUEST_CONTEXT)(&Request->SourceReserved[0]);

        OriginalRequest = (*Context);
    }

    if ((OriginalRequest != NULL) && (OriginalRequest->RequestId == RequestId))
    {
        FILTER_RELEASE_LOCK(&Open->OIDLock, bFalse);

        NdisFCancelOidRequest(Open->AdapterHandle, RequestId);
    }
    else
    {
        FILTER_RELEASE_LOCK(&Open->OIDLock, bFalse);
    }
}

//-------------------------------------------------------------------

_Use_decl_annotations_
VOID
NPF_OidRequestComplete(
    NDIS_HANDLE         FilterModuleContext,
    PNDIS_OID_REQUEST   Request,
    NDIS_STATUS         Status
    )
{
    POPEN_INSTANCE                      Open = (POPEN_INSTANCE) FilterModuleContext;
    PNDIS_OID_REQUEST                   OriginalRequest;
    PFILTER_REQUEST_CONTEXT             Context;
    BOOLEAN                             bFalse = FALSE;

    TRACE_ENTER();

    Context = (PFILTER_REQUEST_CONTEXT)(&Request->SourceReserved[0]);
    OriginalRequest = (*Context);

    //
    // This is an internal request
    //
    if (OriginalRequest == NULL)
    {
        TRACE_MESSAGE1(PACKET_DEBUG_LOUD, "Status= %p", Status);
        NPF_InternalRequestComplete(Open, Request, Status);
        TRACE_EXIT();
        return;
    }


    FILTER_ACQUIRE_LOCK(&Open->OIDLock, bFalse);

    ASSERT(Open->PendingOidRequest == Request);
    Open->PendingOidRequest = NULL;

    FILTER_RELEASE_LOCK(&Open->OIDLock, bFalse);


    //
    // Copy the information from the returned request to the original request
    //
    switch(Request->RequestType)
    {
        case NdisRequestMethod:
            OriginalRequest->DATA.METHOD_INFORMATION.OutputBufferLength =  Request->DATA.METHOD_INFORMATION.OutputBufferLength;
            OriginalRequest->DATA.METHOD_INFORMATION.BytesRead = Request->DATA.METHOD_INFORMATION.BytesRead;
            OriginalRequest->DATA.METHOD_INFORMATION.BytesNeeded = Request->DATA.METHOD_INFORMATION.BytesNeeded;
            OriginalRequest->DATA.METHOD_INFORMATION.BytesWritten = Request->DATA.METHOD_INFORMATION.BytesWritten;
            break;

        case NdisRequestSetInformation:
            OriginalRequest->DATA.SET_INFORMATION.BytesRead = Request->DATA.SET_INFORMATION.BytesRead;
            OriginalRequest->DATA.SET_INFORMATION.BytesNeeded = Request->DATA.SET_INFORMATION.BytesNeeded;
            break;

        case NdisRequestQueryInformation:
        case NdisRequestQueryStatistics:
        default:
            OriginalRequest->DATA.QUERY_INFORMATION.BytesWritten = Request->DATA.QUERY_INFORMATION.BytesWritten;
            OriginalRequest->DATA.QUERY_INFORMATION.BytesNeeded = Request->DATA.QUERY_INFORMATION.BytesNeeded;
            break;
    }


    (*Context) = NULL;

    NdisFreeCloneOidRequest(Open->AdapterHandle, Request);

    NdisFOidRequestComplete(Open->AdapterHandle, OriginalRequest, Status);

    TRACE_EXIT();
}

Answer 1

---

以下是我从 Jeffrey 收到的邮件，我认为这是这个问题的最佳答案：）

---

数据包过滤器对 LWF 和协议的工作方式不同。让我给你一些背景。我敢肯定，您已经知道其中的一些内容，但复习基础知识总是有帮助的，因此我们可以确定我们都在同一页面上。NDIS 数据路径像树一样组织：

数据包过滤发生在此堆栈中的两个位置：

(a) 一次在微型端口硬件中，并且

(b) 在堆栈的顶部，就在协议的下方。

NDIS 将单独跟踪每个协议的数据包过滤器，以提高效率。如果一个协议要求查看所有数据包（混杂模式），那么并非所有协议都必须对所有流量进行分类。所以实际上，系统中有 ( P +1) 个不同的数据包过滤器，其中P是协议的数量：

现在，如果有所有这些不同的数据包过滤器，那么 OID_GEN_CURRENT_PACKET_FILTER 究竟是如何工作的？NDIS 所做的是 NDIS 跟踪每个协议的数据包过滤器，但也将过滤器合并到微型端口堆栈的顶部。所以假设protocol0请求A+B的包过滤器，protocol1请求C的包过滤器，protocol2请求B+D的包过滤器：

然后在堆栈的顶部，NDIS 将数据包过滤器合并到 A+B+C+D。这是向下发送到过滤器堆栈，并最终发送到微型端口的内容。

由于这个合并过程，无论protocol2设置什么包过滤器，protocol2都不能影响其他协议。因此协议不必担心“共享”数据包过滤器。但是，对于 LWF，情况并非如此。如果 LWF1 决定设置一个新的包过滤器，它不会被合并：

在上图中，LWF1 决定将包过滤器更改为 C+E。这覆盖了协议的 A+B+C+D 包过滤器，这意味着标志 A、B 和 D 永远不会进入硬件。如果协议依赖于标志 A、B 或 D，那么协议的功能将被破坏。

这是设计使然——LWF 具有强大的功能，它们可以对堆栈做任何事情。它们被设计成有权否决所有其他协议的数据包过滤器。但是在您的情况下，您不想弄乱其他协议；您希望过滤器对系统其余部分的影响最小。

因此，您要做的是始终跟踪数据包过滤器是什么，并且永远不要从当前数据包过滤器中删除标志。这意味着您应该在附加过滤器时查询数据包过滤器，并在看到 OID_GEN_CURRENT_PACKET_FILTER 从上方下降时更新缓存值。

如果您的用户模式应用程序需要比当前数据包过滤器更多的标志，您可以发出 OID 并添加额外的标志。这意味着硬件的数据包过滤器将有更多的标志。但是没有协议的数据包过滤器会改变，所以协议仍然会看到相同的东西。

在上面的例子中，过滤器 LWF1 表现不错。尽管 LWF1 只关心标志 E，但 LWF1 仍然传递了所有标志 A、B、C 和 D，因为 LWF1 知道它上面的协议希望设置这些标志。

一旦你了解了管理数据包过滤器需要做什么，管理这个的代码还不错：

1. 始终跟踪来自上述协议的最新数据包过滤器。

2. 永远不要让 NIC 看到标志数少于协议的数据包过滤器的数据包过滤器。

3. 根据需要添加您自己的标志。

好的，希望这能让您很好地了解包过滤器是什么以及如何管理它。下一个问题是如何将“混杂模式”和“非混杂模式”映射到实际的标志中？让我们仔细定义这两种模式：

非混杂模式：捕获工具只看到操作系统通常会收到的接收流量。如果硬件过滤掉流量，那么我们不想看到该流量。用户想要在正常状态下诊断本地操作系统。

混杂模式：为捕获工具提供尽可能多的接收数据包——理想情况下是在线传输的每一位。数据包是否发往本地主机并不重要。用户想要诊断网络，因此想要查看网络上发生的一切。

我认为当你这样看时，数据包过滤器标志的后果是相当简单的。对于非混杂模式，不要更改数据包过滤器。只要让硬件数据包过滤器成为操作系统想要的任何东西。然后对于混杂模式，添加 NDIS_PACKET_TYPE_PROMISCUOUS 标志，NIC 硬件将为您提供它可能提供的一切。

因此，如果 LWF 就这么简单，为什么旧​​的基于协议的 NPF 驱动程序需要这么多标志呢？旧的基于协议的驱动程序有几个问题：

1. 它无法完全正确地获得“非混杂模式”

2. 它不能轻易捕获其他协议的发送数据包

NPF-protocol 的第一个问题是它不能轻易正确地实现我们对“非混杂模式”的定义。如果 NPF-the-protocol 想要像操作系统看到的那样看到接收流量，那么它应该使用什么数据包过滤器？如果它将数据包过滤器设置为零，则 NPF 将看不到任何流量。所以NPF可以设置Directed|Broadcast|Multicast的包过滤。但这只是 TCPIP 和其他协议设置的假设。如果 TCPIP 决定设置一个混杂标志（某些套接字标志会导致这种情况发生），那么 NPF 实际上会看到比 TCPIP 看到的更少的数据包，这是错误的。但是如果 NPF 设置了混杂标志，那么它会看到比 TCPIP 看到的更多的流量，这也是错误的。因此，捕获协议很难决定设置哪些标志，以便它看到与操作系统其余部分看到的完全相同的数据包。LWF 没有这个问题，因为在所有协议的过滤器合并后，LWF 可以看到组合的 OID。

NPF 协议的第二个问题是它需要环回模式来捕获发送的数据包。LWF 不需要环回——事实上，它会非常有害。让我们用同一张图来看看为什么。这是 NPF 在混杂模式下捕获接收路径：

现在让我们看看收到单播数据包时会发生什么：

由于数据包与硬件的过滤器匹配，因此数据包会出现在堆栈中。然后，当数据包到达协议层时，NDIS 将数据包提供给 tcpip 和 npf 这两个协议，因为这两个协议的数据包过滤器都与数据包匹配。所以效果很好。

但是现在发送路径很棘手：

tcpip 发送了一个数据包，但 npf 从来没有机会看到它！为了解决这个问题，NDIS 添加了“环回”数据包过滤标志的概念。这个标志有点特别，因为它不属于硬件。相反，环回数据包过滤器告诉 NDIS 将所有发送流量反弹回接收路径，以便 npf 等诊断工具可以看到数据包。它看起来像这样：

现在环回路径实际上只用于诊断工具，所以我们没有花太多时间优化它。而且，由于这意味着所有发送的数据包都会穿过堆栈两次（一次用于正常发送路径，另一次用于接收路径），因此它至少具有两倍的 CPU 成本。这就是为什么我说 NDIS LWF 能够以比协议更高的吞吐量被捕获，因为 LWF 不需要环回路径。

为什么不？为什么 LWF 不需要环回？好吧，如果您回头查看最后几张图，您会发现我们所有的 LWF 都看到了所有流量——发送和接收——没有任何环回。所以 LWF 满足了看到所有流量的要求，而无需费心环回。这就是为什么 LWF 通常不应该设置任何环回标志的原因。

好的，那封电子邮件比我想要的要长，但我希望能解决一些关于数据包过滤器、环回路径以及 LWF 与协议有何不同的问题。如果有任何不清楚的地方，或者图表没有通过，请告诉我。