My Design idea is to build 2 separate NDIS IM Drivers.
One of the NDIS IM Driver will receive all the packets from TCP/IP stack and
from the network.
This IM Driver will then send selected packets(UDP) to another NDIS IM
Driver which will then return these packets to the first IM driver which
will then send these packets to the network/Stack.
My Questions regarding this design are -
-
Can 2 separate NDIS IM Driver simultaneously exists in one system?
-
How can i bind one NDIS IM Driver to another(Is there any inf file entry
or something else in the code itself)?
3.NDIS IM Driver 2 should not receive all packets from either TCP/IP Stack
or Network but can receive some selected packets from the NDIS IM Driver
1.How can i acheive this?
Thanks in advance.
On 6/7/07, shobhit shingla wrote:
>
> My Design idea is to build 2 separate NDIS IM Drivers.
>
> One of the NDIS IM Driver will receive all the packets from TCP/IP stack
> and from the network.
> This IM Driver will then send selected packets(UDP) to another NDIS IM
> Driver which will then return these packets to the first IM driver which
> will then send these packets to the network/Stack.
>
> My Questions regarding this design are -
>
> 1. Can 2 separate NDIS IM Driver simultaneously exists in one system?
>
There could be more than one IM driver in a network stack. There are already
MS supplied IM drivers. So yes yu can have it.
> 2. How can i bind one NDIS IM Driver to another(Is there any inf file
> entry or something else in the code itself)?
>
IIRC, there is no such binding needed, at the install time you may have to
look for load ordering to place them in proper order. Think of it as a stack
of drivers
> 3.NDIS IM Driver 2 should not receive all packets from either TCP/IP Stack
> or Network but can receive some selected packets from the NDIS IM Driver
> 1.How can i acheive this?
>
You can do it, but you have to skip stack location for the IRPs that should
not go to your 2nd ( from the top ) driver. But incoming traffic will go to
2nd driver.
As suggested earlier, you can have one IM driver and tackle it in one place.
What would it buy you, if you have 2 or more IM driver for this ?
>
> Thanks in advance.
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
On Jun 7, 2007, at 8:29 AM, Prokash Sinha wrote:
On 6/7/07, shobhit shingla wrote:
> 2. How can i bind one NDIS IM Driver to another(Is there any inf
> file entry or something else in the code itself)?
>
> IIRC, there is no such binding needed, at the install time you may
> have to look for load ordering to place them in proper order.
> Think of it as a stack of drivers
The network class installer does all of the binding for you, based on
your INF files. You shouldn’t have to do anything special.
If you do have to do special pruning of bindings, you can use a
notify object, but my guess is that you won’t need this.
You should get familiar with the Passthru sample in the WDK. It shows
all of this.
> 3.NDIS IM Driver 2 should not receive all packets from either TCP/
> IP Stack or Network but can receive some selected packets from the
> NDIS IM Driver 1.How can i acheive this?
>
> You can do it, but you have to skip stack location for the IRPs
> that should not go to your 2nd ( from the top ) driver. But
> incoming traffic will go to 2nd driver.
This isn’t quite right; NDIS drivers don’t deal with IRPs. The
concept is right, though; you can simply pass packets on that you’re
not interested in. You will see all packets in both directions,
unless you start pruning bindings as described above, but don’t.
Of course, you have to be able to make a decision about what you’re
interested in.
Again, look at Passthru; this is exactly what it does.
-sd
PassThru simply blocks the packets based on sourec or destination address
but i want to send the blocked packets to another IM Driver.
Can i have an intermediate driver that is not bound to TCP/Ip stack and also
not ot miniport adapter and is only bind to another IM Driver.In the case
the other IM Driver should bind to all three i.e TCP/IP stack,miniport
adapter and second IM Driver.?
On 6/7/07, Steve Dispensa wrote:
>
>
> On Jun 7, 2007, at 8:29 AM, Prokash Sinha wrote:
>
>
>
> On 6/7/07, shobhit shingla wrote:
> >
> > 2. How can i bind one NDIS IM Driver to another(Is there any inf file
> > entry or something else in the code itself)?
> >
>
> IIRC, there is no such binding needed, at the install time you may have
> to look for load ordering to place them in proper order. Think of it as a
> stack of drivers
>
>
>
>
>
> The network class installer does all of the binding for you, based on your
> INF files. You shouldn’t have to do anything special.
>
>
> If you do have to do special pruning of bindings, you can use a notify
> object, but my guess is that you won’t need this.
>
>
> You should get familiar with the Passthru sample in the WDK. It shows all
> of this.
>
>
>
>
>
> 3.NDIS IM Driver 2 should not receive all packets from either TCP/IP
> > Stack or Network but can receive some selected packets from the NDIS IM
> > Driver 1.How can i acheive this?
> >
>
> You can do it, but you have to skip stack location for the IRPs that
> should not go to your 2nd ( from the top ) driver. But incoming traffic will
> go to 2nd driver.
>
>
>
> This isn’t quite right; NDIS drivers don’t deal with IRPs. The concept is
> right, though; you can simply pass packets on that you’re not interested in.
> You will see all packets in both directions, unless you start pruning
> bindings as described above, but don’t.
>
>
> Of course, you have to be able to make a decision about what you’re
> interested in.
>
>
> Again, look at Passthru; this is exactly what it does.
>
>
> -sd
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServerhttp:
></http:></http:>
> 3.NDIS IM Driver 2 should not receive all packets from either TCP/IP Stack
or Network but can receive some selected packets from the NDIS IM Driver
1.How can i acheive this?
If I got it right, you want to make Driver2 a “proprietary” driver that does not deal with the network stack and that cannot be accessed by anyone, apart from Driver1. The best thing to do here is
to write Driver2 just as a virtual miniport driver, rather than NDIS IM…
The idea stands as following. You write a NDIS IM filter that sits in between TCPIP and
NIC(Driver1) and a virtual miniport driver (Driver2), and make sure that no one, apart from Driver1’s protocol side, is bound to Driver2 (it can be done via UpperRange section of Driver2’s INF file). Once no one, apart from Driver1, is bound to the virtual miniport that Driver2 represents, no one, apart from Driver1, is able to either send or receive anything to/from DRiver2…
When Driver1 wants to send data to Driver2, it can do it with NdisSend() - it just has to specify a handle that corresponds to its binding with Driver2 on this call. When Driver2 wants to send something to Driver1, it just calls NdisMIndicateReceivePacket() - once no one, apart from Driver1, is bound to the virtual miniport that Driver2 implements, NDIS will indicate this packet only to Driver1’s protocol side. Pure and simple
Anton Bassov
On Jun 7, 2007, at 11:37 AM, shobhit shingla wrote:
PassThru simply blocks the packets based on sourec or destination
address
You must be reading a different Passthru sample. The passthru from
the WDK is just what the name implies - it just passes data through,
up and down.
but i want to send the blocked packets to another IM Driver.
No, you probably don’t. We’ve been over this several times.
Can i have an intermediate driver that is not bound to TCP/Ip stack
and also not ot miniport adapter and is only bind to another IM
Driver.
Nope, that driver wouldn’t have any valid binding paths and wouldn’t
load. Why on earth would you want such a thing?
In the case the other IM Driver should bind to all three i.e TCP/IP
stack,miniport adapter and second IM Driver.?
Seriously, you haven’t provided a single reason why this dual-IM
driver architecture is the way to go. I really suspect it isn’t.
Use ONE IM driver. Modify the packets that need it. Pass through the
ones you’re not interested in.
-Steve
On 6/7/07, Steve Dispensa wrote:
>
> On Jun 7, 2007, at 8:29 AM, Prokash Sinha wrote:
>
>>
>>
>> On 6/7/07, shobhit shingla < xxxxx@gmail.com> wrote:
>> 2. How can i bind one NDIS IM Driver to another(Is there any inf
>> file entry or something else in the code itself)?
>>
>> IIRC, there is no such binding needed, at the install time you may
>> have to look for load ordering to place them in proper order.
>> Think of it as a stack of drivers
>
>
>
>
> The network class installer does all of the binding for you, based
> on your INF files. You shouldn’t have to do anything special.
>
>
> If you do have to do special pruning of bindings, you can use a
> notify object, but my guess is that you won’t need this.
>
>
> You should get familiar with the Passthru sample in the WDK. It
> shows all of this.
>
>
>
>
>> 3.NDIS IM Driver 2 should not receive all packets from either TCP/
>> IP Stack or Network but can receive some selected packets from the
>> NDIS IM Driver 1.How can i acheive this?
>>
>> You can do it, but you have to skip stack location for the IRPs
>> that should not go to your 2nd ( from the top ) driver. But
>> incoming traffic will go to 2nd driver.
>
>
> This isn’t quite right; NDIS drivers don’t deal with IRPs. The
> concept is right, though; you can simply pass packets on that
> you’re not interested in. You will see all packets in both
> directions, unless you start pruning bindings as described above,
> but don’t.
>
>
> Of course, you have to be able to make a decision about what you’re
> interested in.
>
>
> Again, look at Passthru; this is exactly what it does.
>
>
> -sd
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> — Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at http://www.osronline.com/page.cfm?
> name=ListServer
----- Original Message -----
From: shobhit shingla
To: Windows System Software Devs Interest List
Sent: Thursday, June 07, 2007 9:37 AM
Subject: Re: [ntdev] NDIS IM Driver Binding to another NDIS IM Driver
PassThru simply blocks the packets based on sourec or destination address but i want to send the blocked packets to another IM Driver.
Again, what’s the point in that? An IM driver is a filter in the network stack. What buys you in sending the packets to another IM (which is somewhere below or above your first IM in the network stack)?
Can i have an intermediate driver that is not bound to TCP/Ip stack and also not ot miniport adapter and is only bind to another IM Driver.In the case the other IM Driver should bind to all three i.e TCP/IP stack,miniport adapter and second IM Driver.?
Then the second driver is *not* an IM driver, if it’s not bound to any upper or lower binding. I don’t understand why you want this and why you call this second driver “IM driver”.
Have a nice day
GV
On 6/7/07, Steve Dispensa wrote:
On Jun 7, 2007, at 8:29 AM, Prokash Sinha wrote:
On 6/7/07, shobhit shingla < xxxxx@gmail.com> wrote:
2. How can i bind one NDIS IM Driver to another(Is there any inf file entry or something else in the code itself)?
IIRC, there is no such binding needed, at the install time you may have to look for load ordering to place them in proper order. Think of it as a stack of drivers
The network class installer does all of the binding for you, based on your INF files. You shouldn’t have to do anything special.
If you do have to do special pruning of bindings, you can use a notify object, but my guess is that you won’t need this.
You should get familiar with the Passthru sample in the WDK. It shows all of this.
3.NDIS IM Driver 2 should not receive all packets from either TCP/IP Stack or Network but can receive some selected packets from the NDIS IM Driver 1.How can i acheive this?
You can do it, but you have to skip stack location for the IRPs that should not go to your 2nd ( from the top ) driver. But incoming traffic will go to 2nd driver.
This isn’t quite right; NDIS drivers don’t deal with IRPs. The concept is right, though; you can simply pass packets on that you’re not interested in. You will see all packets in both directions, unless you start pruning bindings as described above, but don’t.
Of course, you have to be able to make a decision about what you’re interested in.
Again, look at Passthru; this is exactly what it does.
-sd
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
In that case does Driver 1 be a MUX intermediate driver(As it has to bind
with both NIC and Driver 2) or it can simply be a Filter Intermediate driver
like PassThru?
On 6/7/07, xxxxx@hotmail.com wrote:
>
> > 3.NDIS IM Driver 2 should not receive all packets from either TCP/IP
> Stack
> > or Network but can receive some selected packets from the NDIS IM Driver
> > 1.How can i acheive this?
>
> If I got it right, you want to make Driver2 a “proprietary” driver that
> does not deal with the network stack and that cannot be accessed by anyone,
> apart from Driver1. The best thing to do here is
> to write Driver2 just as a virtual miniport driver, rather than NDIS
> IM…
>
> The idea stands as following. You write a NDIS IM filter that sits in
> between TCPIP and
> NIC(Driver1) and a virtual miniport driver (Driver2), and make sure that
> no one, apart from Driver1’s protocol side, is bound to Driver2 (it can be
> done via UpperRange section of Driver2’s INF file). Once no one, apart from
> Driver1, is bound to the virtual miniport that Driver2 represents, no one,
> apart from Driver1, is able to either send or receive anything to/from
> DRiver2…
>
> When Driver1 wants to send data to Driver2, it can do it with NdisSend() -
> it just has to specify a handle that corresponds to its binding with Driver2
> on this call. When Driver2 wants to send something to Driver1, it just calls
> NdisMIndicateReceivePacket() - once no one, apart from Driver1, is bound to
> the virtual miniport that Driver2 implements, NDIS will indicate this
> packet only to Driver1’s protocol side. Pure and simple
>
> Anton Bassov
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
I have some queries regarding the solution suggested by Anton Bassov(
xxxxx@hotmail.com) -
- Can i use this approach to send both incoming(from TCP/IP Stack) and
outgoing(From NIC) UDP Packets from IM Driver to Miniport driver.
2.Does IM driver be a MUX IM Driver or Filter IM Driver.
On 6/8/07, shobhit shingla wrote:
>
> In that case does Driver 1 be a MUX intermediate driver(As it has to bind
> with both NIC and Driver 2) or it can simply be a Filter Intermediate driver
> like PassThru?
>
>
>
> On 6/7/07, xxxxx@hotmail.com wrote:
> >
> > > 3.NDIS IM Driver 2 should not receive all packets from either TCP/IP
> > Stack
> > > or Network but can receive some selected packets from the NDIS IM
> > Driver
> > > 1.How can i acheive this?
> >
> > If I got it right, you want to make Driver2 a “proprietary” driver that
> > does not deal with the network stack and that cannot be accessed by anyone,
> > apart from Driver1. The best thing to do here is
> > to write Driver2 just as a virtual miniport driver, rather than NDIS
> > IM…
> >
> > The idea stands as following. You write a NDIS IM filter that sits in
> > between TCPIP and
> > NIC(Driver1) and a virtual miniport driver (Driver2), and make sure that
> > no one, apart from Driver1’s protocol side, is bound to Driver2 (it can be
> > done via UpperRange section of Driver2’s INF file). Once no one, apart from
> > Driver1, is bound to the virtual miniport that Driver2 represents, no one,
> > apart from Driver1, is able to either send or receive anything to/from
> > DRiver2…
> >
> > When Driver1 wants to send data to Driver2, it can do it with NdisSend()
> > - it just has to specify a handle that corresponds to its binding with
> > Driver2 on this call. When Driver2 wants to send something to Driver1, it
> > just calls NdisMIndicateReceivePacket() - once no one, apart from Driver1,
> > is bound to the virtual miniport that Driver2 implements, NDIS will
> > indicate this packet only to Driver1’s protocol side. Pure and simple
> >
> > Anton Bassov
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih//article.cfm?id=256http:
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServerhttp:
> >
>
></http:></http:>
> I have some queries regarding the solution suggested by Anton Bassov
- Can i use this approach to send both incoming(from TCP/IP Stack) and
outgoing(From NIC) UDP Packets from IM Driver to Miniport driver.
Sure - you can send both outgoing and incoming packets, as well as the ones that your IM has generated on its own initiative solely for the purpose of communicating with the virtual miniport driver - NdisSend() is, in this context, just a channel via which your filter sends data of any description to with the virtual miniport
2.Does IM driver be a MUX IM Driver or Filter IM Driver.
It depends on your objectives. If I got it right, your objective is just to monitor incoming and outgoing packets (i.e. bound protocols, apparently, should not have any idea about your IM’s presence - you don’t want them to think of your IM as of adapter). If this is the case, your IM should be filter…
However, you haven’t yet answered Steve’s question (BTW, you have been asked this question on another thread as well)…
Why do you think you need so complext architecture here??? There are some cases when it can be justified, but these are relatively rare - in the vast majority of cases it is better to do everything in a single driver…
Anton Bassov
Actually i also want to do everything in the same driver but my client wants
me to study the feasibility of two separate modules.
Now as suggested by you how can i bind the lower protocol interface of my IM
Driver to both actual miniport adapter and also to my miniport driver(the
bindings of protocol interface is specified by inf file enteries or
bindadapter method within the code).Surely I can send packets to one of them
by specifying proper handle in NDISSend() method.
Please guide me as i am fairly new to this topic but i don’t have much time
to study books on it.
Thanks in advace.
On 6/8/07, xxxxx@hotmail.com wrote:
>
> > I have some queries regarding the solution suggested by Anton Bassov
>
> > 1. Can i use this approach to send both incoming(from TCP/IP Stack) and
> > outgoing(From NIC) UDP Packets from IM Driver to Miniport driver.
>
> Sure - you can send both outgoing and incoming packets, as well as the
> ones that your IM has generated on its own initiative solely for the purpose
> of communicating with the virtual miniport driver - NdisSend() is, in this
> context, just a channel via which your filter sends data of any description
> to with the virtual miniport
>
>
> > 2.Does IM driver be a MUX IM Driver or Filter IM Driver.
>
> It depends on your objectives. If I got it right, your objective is just
> to monitor incoming and outgoing packets (i.e. bound protocols,
> apparently, should not have any idea about your IM’s presence - you don’t
> want them to think of your IM as of adapter). If this is the case, your IM
> should be filter…
>
>
> However, you haven’t yet answered Steve’s question (BTW, you have been
> asked this question on another thread as well)…
>
> Why do you think you need so complext architecture here??? There are some
> cases when it can be justified, but these are relatively rare - in the vast
> majority of cases it is better to do everything in a single driver…
>
> Anton Bassov
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> Actually i also want to do everything in the same driver but my client wants
me to study the feasibility of two separate modules.
Tell your client that the whole thing is feasible, but, from the practical standpoint, unreasonable…
Please guide me as i am fairly new to this topic but i don’t have much time
to study books on it.
AFAIK, there are no books on NDIS, and, unfortunately, MSDN is not that helpfull here either- all our knowledge of NDIS is obtained only through reading code samples, examining ndis.h and disassembling NDIS.SYS. This is the only way to go here. If you have no time for trying to figure out how NDIS works, please do us a favour and just forget about the whole thing - you will never write NDIS IM driver properly anyway, so that if you give it up, you will do a huge favour to all NDIS-level developers (otherwise, we may have a misfortune to adjust our drivers to the possible presence of your “masterpiece” on the target machine…)
Anton Bassov