Bridge between two adapters: How to get the Binding Handle of another adapter in PtReceive()?

Discussion in 'Windows Vista Drivers' started by Rajesh Gupta, Aug 10, 2004.

  1. Rajesh Gupta

    Rajesh Gupta Guest

    Hi All,

    I am writting an NDIS IM driver, in which i have to send all the recived
    pacekts on one interface to another interface. I have two adapters in my
    system. If i receive some packets on Adapter 1, i want to retransmit those
    packets through Adapter 2. I am acting as a bridge between two adapters.
    lets say.
    Adapter 1 (
    Adapter 2 (

    So when i receive the packets on Adapter 1 (, then i block
    that received packet in PtReceive. I allocated new send packet, new buffers
    and copied all the data from the received packet to send packet. I modified
    the Source (to and Destination address, modified MAC
    addresses in the packet. I am sure packet is fine. I have checked it with
    Single adapter. Then i used NdisSend() function to send that packet. But the
    problem is, I do not have the Binding handle to Adapter 2 when i received
    the packet on Adapter 1. I am not sure, how can i get the binding handle to
    Adapter 2 in this scenario?
    I did use the Binding handle of Adapter 1, packet is fine. But it does not
    go through Adapter 2, so it does not reach the destination.

    In passthru sample, there is global list of Adapters. Can i use that list
    directly, so there is good and nice way of getting the Binding handle of
    another adapter in PtReceive()?

    thanks a lot on advance
    Rajesh Gupta, Aug 10, 2004
    1. Advertisements

  2. problem is, I do not have the Binding handle to Adapter 2 when i received
    Maintain some data structures of your own (possibly manageable from user mode)
    to keep the information about what adapters are bridged.
    Maxim S. Shatskih, Aug 11, 2004
    1. Advertisements

  3. Rajesh Gupta

    Rajesh Gupta Guest

    Maintain some data structures of your own (possibly manageable from user
    I already have the PdaptList (Like the one in Passthru sample.) . Can i
    safely use the same structure and BindingHandle in that structure? Though i
    do not get the PAdaptList in PtReceive, its global list. Hope BindingHandles
    will be valid untill i unbind the adapter.

    Why do i need to manage the data structure from user mode? If i have only
    two adapters, and i know they are bridged. I do not need to manage them from
    user mode. Is there any other reason to manage them from user mode?

    Rajesh Gupta, Aug 11, 2004
  4. First of all, understand that the "ADAPT" structure used in the PassThru
    sample is "your friend". You can and should add your own members to the
    ADAPT structure to keep track of the implementation details that you are
    adding yourself.

    But before adding anything, make sure that you know how the baseline ADAPT
    structure is constructed. For example, notice how the memory for the body of
    NDIS_STRINGS is provided by allocating extra memory at the end of the ADAPT
    structure. Be sure to understand what information is in the ADAPT structure
    and where it came from.

    Next notice how a pointer to a particular ADAPT structure is recovered in
    various calls to the driver such as in PtReceive and MPSendPackets.
    Understand that if you have safely found a pointer to an ADAPT structure you
    have access to the two handles you need to make send calls on the lower
    miniport (the BindingHandle) and to make your own receive indications
    "upwards" to a higher-level protocol (the MiniportHandle).

    You also need to understand the "lifetime" of the memory that backs the
    ADAPT structure and why you must use techniques such as reference counting.
    Basically if you don't understand this idea then under some conditions the
    ADAPT structure may be freed while you are using it.

    The sample code for "Extending the PassThru NDIS IM Driver" on the Windows
    Driver Developer's Digest,, has added reference counting
    to the ADAPT structure.

    The Extended PassThru sample includes a function called
    PtLookupAdapterByName. That function accepts a string and safely "walks the
    adapter list" to find the ADAPT structure with the matching name. It is
    essential to notice that PtLookupAdapterByName adds a reference count to the
    ADAPT structure before returning the ADAPT structure that if it finds it. At
    some point you need to dereference the ADAPT when you no longer need the
    ADAPT pointer that was returned by PtLookupAdapterByName.

    Finally we reach your real question: "so there is good and nice way of
    getting the Binding handle of another adapter in PtReceive()?".

    You must consider a variety of network configurations.

    1.) One real adapter: Can't bridge at all.
    2.) One real adapter + someone's MUX IM driver - two virtual miniports: Do
    you want to bridge between these two?
    3.) More then two real and/or virtual miniports: Which two do you want to

    Without any other information all your NDIS IM driver can do in PtReceive

    1.) Find the ADAPT structure for the protocol binding that the packet is
    being received on in the usual way.
    2.) Then walk the AdaptList to find the other adapter(s) in the list whose
    ADAPT structure pointer is not the same as the one that you have fetched in

    The functions that you could invent would have the logical prototypes:

    PADAPT FindFristAdapterThatDoesNotMatchThisOne( PADAPT receiveAdapt );
    PADAPT FindNextAdapterThatDoesNotMatchThisOne( PADAPT receiveAdapt );

    (Be sure that each holds spinlock while walking the list and adds refcount
    before returning ADAPT pointer... See the PtLookupAdapterByName for ideas.)

    These (stupid) functions are the best you can do by the NDIS IM driver
    standalone. They are fairly useless - EXCEPT in the one unlikely case that
    the host really has two and exactly two real physical NICs and no virtual
    NICs that it can bind to. It that unlikely configuration is all you ever
    expect to deal with, then you are done.

    More likely, you must deal with other configurations.

    You must have some sort of user-mode configuration tool that directly or
    indirectly tells the IM driver what two miniports to open and bridge across.

    Perhaps an application or property sheet that the user is presented to allow
    him or her to pick the two adapters to bridge. The user-mode component would
    then need to communicate the selection to the NDIS IM driver. Probably using
    registry entries that can be read using NdisReadConfiguration. Perhaps
    Adapter A's configuration could include the NDIS adapter name of "the other
    adapter" (adapter B) for bridging and likewise Adapter B's configuration
    would the NDIS adapter name for "the other adapter" (adapter A). The
    PtLookupAdapterByName function could be used to lookup the other adapter's
    ADAPT structure and keep track of it somewhere.

    It isn't as simple as it seems because the idea of "the other adapter" is
    logically not trivial.

    Hope these ramblings are useful.

    Good luck,

    Thomas F. Divine, Windows DDK MVP
    Thomas F. Divine [DDK MVP], Aug 11, 2004
  5. Rajesh Gupta

    Rajesh Gupta Guest

    Thanks a lot Thomas

    This is really useful. I am working on very specific solution with specific
    Adapters. Right now i am not worried about different configurations. I want
    my driver to work for one confguration and then i will scale it.

    My configuration right now is
    One real adapter + someone's MUX IM driver - two virtual miniports: i.e.
    My adapter supports VLAN. So i will set up two VLANS on my adapter (I will
    have two virtual Miniports). When i will receive data on one VLAN, some of
    that data, i would like to send on another VLAN.

    I have taken care of the User Interface. User can specify the IP address,
    whose data user wants to thro on another VLAN.
    Thanks a lot on info about PADAPT structure. I have modified the structure
    for my IM driver and i am taking care of all the memory and locking issue of
    the structure.

    As i know the name of the Adapters, i will try to implement the
    FindAdapterThatDoesNotMatchThisOne function and try to implement it. Thanks
    a lot for your information. Thanks a lot about refrence counting before
    returning the PADAPT structure. That was not in my mind.

    Thanks again.
    Rajesh Gupta, Aug 11, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.