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

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 (172.10.10.110)
Adapter 2 (172.10.10.111)

So when i receive the packets on Adapter 1 (172.10.10.110), 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 172.10.10.111) 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

 

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.

 

Maintain some data structures of your own (possibly manageable from user
mode)

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?

Thanks
Raj

 

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, http://www.wd-3.com, 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
bridge?

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

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
PtReceive.

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
http://www.rawether.net

 

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.