none
In NDIS's passthru example, how to send a NDIS_PACKET with a specific adapter? RRS feed

  • Question

  • Hi. I'm working on a NAT-like driver software in Windows platform by modifying the original passthru example in WDK 7600.16385.1.

    Here're several ethernet network adapters in my machine, and I wanna analyze every packet I received then decide which adapter to forward the packet to. There comes the problem: I don't know how to specify the adapter for sending when calling the NdisSend function in PtReceive\PtReceivePacket\MPTransferData\PtTransferDataComplete.

    As follows, there's a BindingHandle arg in NdisSend, but in my understanding it should stand for all the adapters in passthru(may not right:)

    NdisSend(&Status, pAdapt->BindingHandle, MyPacket);

    So how to specify a adapter like this form :{62E9DB05-88D3-479D-A194-22D6A591DB96} when calling NdisSend?

    Very thx..

    Sunday, December 9, 2012 2:44 AM

Answers

  • The issue here is that NDIS 5 has two fundamentally different kinds of IM drivers: MUX-IM drivers and Filter-IM drivers.

    • Filter-IM drivers sit in between a single adapter and tcpip.  Filters don't have access to any other network adapters on the system.  PASSTHRU is a sample Filter-IM driver.
    • MUX-IMs sit over N adapters, and expose M interfaces to tcpip.  MUX-IMs have much more flexibility in rerouting traffic; you can decide which adapter to send to on a packet-by-packet basis.  The price of this power, however, is complexity: it's much more difficult to build a working MUX-IM driver than it is to build a Filter-IM driver.  MUXIM is a sample MUX-IM driver.

    So it sounds like you want to be able to route packets to different adapters.  For that kind of functionality, you'll need to build a MUX-IM driver, and bind yourself over every physical adapter.  Then you'll get a handle for each, and you can call NdisSend for whichever adapter.

    You can read more about this here:

        http://msdn.microsoft.com/en-us/library/windows/hardware/ff548970(v=vs.85).aspx
        http://msdn.microsoft.com/en-us/library/windows/hardware/ff556949(v=vs.85).aspx
        http://msdn.microsoft.com/en-us/library/windows/hardware/ff557076(v=vs.85).aspx

    I'd like to emphasize again... it's difficult to build a correctly-functioning MUX-IM driver.

    Sunday, December 9, 2012 8:14 PM
  •  

    • Filter-IM drivers sit in between a single adapter and tcpip.  Filters don't have access to any other network adapters on the system.  PASSTHRU is a sample Filter-IM driver.

    Filter-IM driver can bind to several adapters. Just check Passthru's MPInitialize() function. There isn't any point to put single adapter into the list ;)

            //
            // Add this adapter to the global pAdapt List
            //
            NdisAcquireSpinLock(&GlobalLock);
    
            pAdapt->Next = pAdaptList;
            pAdaptList = pAdapt;
    
            NdisReleaseSpinLock(&GlobalLock);
    

    For the original question. pAdapt->BindingHandle is unique for every adapter. Find the correct pAdapt from the pAdaptList by comparing miniport name stored in PtBindAdapter().

    Be careful when sending the packet to different adapter, especially with the power management and bindings. Easiest way is just to copy the data from the old NDIS_PACKET to new NDIS_PACKET, this way you don't have nasty references for NDIS packet pools between different adapters.

    If you don't need to support XP, consider using Windows Filtering Platform (WFP) for this task instead of NDIS.

    BR, Antti

    • Marked as answer by hsluoyc Friday, December 14, 2012 2:42 PM
    Monday, December 10, 2012 8:58 AM

All replies

  • The issue here is that NDIS 5 has two fundamentally different kinds of IM drivers: MUX-IM drivers and Filter-IM drivers.

    • Filter-IM drivers sit in between a single adapter and tcpip.  Filters don't have access to any other network adapters on the system.  PASSTHRU is a sample Filter-IM driver.
    • MUX-IMs sit over N adapters, and expose M interfaces to tcpip.  MUX-IMs have much more flexibility in rerouting traffic; you can decide which adapter to send to on a packet-by-packet basis.  The price of this power, however, is complexity: it's much more difficult to build a working MUX-IM driver than it is to build a Filter-IM driver.  MUXIM is a sample MUX-IM driver.

    So it sounds like you want to be able to route packets to different adapters.  For that kind of functionality, you'll need to build a MUX-IM driver, and bind yourself over every physical adapter.  Then you'll get a handle for each, and you can call NdisSend for whichever adapter.

    You can read more about this here:

        http://msdn.microsoft.com/en-us/library/windows/hardware/ff548970(v=vs.85).aspx
        http://msdn.microsoft.com/en-us/library/windows/hardware/ff556949(v=vs.85).aspx
        http://msdn.microsoft.com/en-us/library/windows/hardware/ff557076(v=vs.85).aspx

    I'd like to emphasize again... it's difficult to build a correctly-functioning MUX-IM driver.

    Sunday, December 9, 2012 8:14 PM
  •  

    • Filter-IM drivers sit in between a single adapter and tcpip.  Filters don't have access to any other network adapters on the system.  PASSTHRU is a sample Filter-IM driver.

    Filter-IM driver can bind to several adapters. Just check Passthru's MPInitialize() function. There isn't any point to put single adapter into the list ;)

            //
            // Add this adapter to the global pAdapt List
            //
            NdisAcquireSpinLock(&GlobalLock);
    
            pAdapt->Next = pAdaptList;
            pAdaptList = pAdapt;
    
            NdisReleaseSpinLock(&GlobalLock);
    

    For the original question. pAdapt->BindingHandle is unique for every adapter. Find the correct pAdapt from the pAdaptList by comparing miniport name stored in PtBindAdapter().

    Be careful when sending the packet to different adapter, especially with the power management and bindings. Easiest way is just to copy the data from the old NDIS_PACKET to new NDIS_PACKET, this way you don't have nasty references for NDIS packet pools between different adapters.

    If you don't need to support XP, consider using Windows Filtering Platform (WFP) for this task instead of NDIS.

    BR, Antti

    • Marked as answer by hsluoyc Friday, December 14, 2012 2:42 PM
    Monday, December 10, 2012 8:58 AM
  • Thanks both of you, but i think antti's way is simpler:)
    Friday, December 14, 2012 2:43 PM