NDIS Filter driver and delayed processing of NDIS_BUFFER_LISTs, pppoe (wan) RRS feed

  • Question

  • Hello!
    I am writing rusroute network driver based on NDIS LightWeight Filter for interception of network packets (NDIS_BUFFER_LISTs), generation of new NDIS_BUFFER_LISTs, send and receive indication of them on Windows 8-10.
    WDK NDIS LightWeight Filter is do nothing with NDIS_BUFFER_LISTs so works.
    I had to make packets handling in system theads of send/receive queues for routing+NAT and win32 application CPU offload, witch calling packets send/indicate receive. win32 application (service) can send/indicate Ethernet packets by calling iocontrol too.
    All works fine with generic Ethernet adapters.
    But there is a problem with pppoe (this is a type of wan) connections: the system makes BSOD with status unexpected irq level in nic card driver after calling NdisFIndicateReceiveNetBufferLists for first wan packet.
    My system threads are working at PASSIVE_LEVEL. No problem... may be raise irql?. I have rewrite the code:
                            KIRQL Old = KeGetCurrentIrql();
                            if (DISPATCH_LEVEL > Old)
                                    KIRQL tmp, disp = DISPATCH_LEVEL;
                                    KeRaiseIrql(disp, &tmp);
                            RecvFlags = NDIS_RECEIVE_FLAGS_DISPATCH_LEVEL;

                            NdisFIndicateReceiveNetBufferLists(pInfo->m_pAdapt->FilterHandle, pnbl, NDIS_DEFAULT_PORT_NUMBER, N, RecvFlags);

                            KIRQL Irql = KeGetCurrentIrql();
                            if (Old < Irql)
    Thats work but unstable. On the first or third test by firefox url the system is hangs up. Breaking by WinDbg is shown callstack of Windows 10 Pro x64 (in this case system had hang up in iocontrol-called function of indication of receive packet):


    - hangs up in wanarp. The system is hang up too when iocontrol fonction is not called receive indication/sending function, but placing packet in system thread's qeueu.
    My spinlocks should be ok'ey.
    Can anybody help to suggest the solution of problem of how to use functions NdisFIndicateReceiveNetBufferLists, NdisFSendNetBufferLists right within  kernel-mode thread for wan interface using, not in FilterReceiveNetBufferLists, FilterSendNetBufferLists callbacks?
    I'l not prefere to raise irql if possible because MSDN tell NdisFIndicateReceiveNetBufferLists, NdisFSendNetBufferLists are calling at irql <= DISPATCH_LEVEL.

    Friday, January 12, 2018 9:05 AM

All replies

  • Do you test with the Windows in-box pppoe, or any 3rd party?

    -- pa

    Friday, January 12, 2018 3:54 PM
  • I have tested with in-box (Windows 10 Pro x64 build 16299rs3_release.170928-1534) pppoe driver.

    Friday, January 12, 2018 5:31 PM
  • "BSOD with status unexpected irq level"

    The bugcheck has a bad description.  It is not usually caused by IRQL at all.  It's actually probably just an access violation (segmentation fault / bad pointer).

    Your callstack is missing OS symbols.  It'll be difficult to debug until you fix the symbols.

    It's perfectly okay to indicate NBLs from a filter driver while at PASSIVE_LEVEL or DISPATCH_LEVEL. Your choice.

    Since this is probably a bad pointer, make sure that the NET_BUFFER_LIST is well-formed.  Make sure that the packet payload is in either non-paged memory, or memory that has been probe + locked.  Make sure you're using the correct NDIS filter module handle.

    Friday, January 12, 2018 10:42 PM
  • The BSOD was really "Unexpected IRQL" while PASSIVE_LEVEL.

    Sunday, January 14, 2018 9:23 PM