NDIS IM Driver to NDIS Protocol Driver

OSR_Community_User · June 14, 2007, 12:18am

Hi all

I think now i am clear about my requirement.

Can i achieve somethink like this

NDIS IM Driver that receives all the packets from TCP/IP stack and NIC
Driver and passes only UDP Packets to a NDIS Protocol Driver.Then NDIS
Protocol Driver returns the UDP Packets to the IM Driver after some
processing.

Is this possible ?

I also have some questions regarding this

Whether my NDIS IM Driver needs 2 interfaces at the upper edge as it has
to bound to both TCP/IP stack and my NDIS Protocol Driver at the upper edge
or i can do with only one interface?
When NDIS IM Driver receives the modified packet from the protocol driver
how will it distinguish the packet coming from TCP/IP Stack and from the
protocol driver.

Thomas_Divine-2 · June 14, 2007, 12:49am

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Thursday, June 14, 2007 12:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS IM Driver to NDIS Protocol Driver

Hi all

I think now i am clear about my requirement.

Can i achieve somethink like this

NDIS IM Driver that receives all the packets from TCP/IP stack and NIC
Driver and passes only UDP Packets to a NDIS Protocol Driver.Then NDIS
Protocol Driver returns the UDP Packets to the IM Driver after some
processing.

Is this possible ?

[PCAUSA] Yes, this would actually work.

I also have some questions regarding this

Whether my NDIS IM Driver needs 2 interfaces at the upper edge as it
has to bound to both TCP/IP stack and my NDIS Protocol Driver at the upper
edge or i can do with only one interface?

[PCAUSA] Yes. It would follow the DDK “MUX” sample driver architecture.

When NDIS IM Driver receives the modified packet from the protocol
driver how will it distinguish the packet coming from TCP/IP Stack and from
the protocol driver.

[PCAUSA] You must invent your own method to make this distinction.

Splitting the work into two different drivers this way (or any other way.)
will add several months to your development time. It simply makes no sense
to me.

If you have common code that you want to use with different drivers,
consider using an “export driver”. Actually, this is a misnomer. An “export
driver” is not a separate runtime binary. Instead, it is more like a
kernel-mode static DLL. You can put common code in the “export driver” and
use it with different drivers like you would a static DLL.

Good luck. You are putting together a design that will take much more time
to achieve then you think.

Thomas F. Divine

— 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

OSR_Community_User · June 14, 2007, 1:00am

OP: Is your project really so top-secret that you can’t explain it to
us? I’m morbidly curious at this point.

And regarding your new approach: just bear in mind that complexity is
the enemy of good software development. Or, put another way, from RFC
1925 (http://www.ietf.org/rfc/rfc1925.txt):

(3) With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead.

Or maybe it’s these:

(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.

(6a) (corollary). It is always possible to add another level of
indirection.

It’s certainly this:

(8) It is more complicated than you think.

…and on this group, you have a history of this:

(11) Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.

(11a) (corollary). See rule 6a.

This is important:

(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take
away.

(which holds for drivers)

But alas, I fear this is particularly relevant:

(4) Some things in life can never be fully appreciated nor
understood unless experienced firsthand. Some things in
networking can never be fully understood by someone who neither
builds commercial networking equipment nor runs an operational
network.

-Steve

On Jun 13, 2007, at 11:48 PM, Thomas F. Divine wrote:

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit
shingla
Sent: Thursday, June 14, 2007 12:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS IM Driver to NDIS Protocol Driver

Hi all

I think now i am clear about my requirement.

Can i achieve somethink like this

NDIS IM Driver that receives all the packets from TCP/IP stack and
NIC Driver and passes only UDP Packets to a NDIS Protocol
Driver.Then NDIS Protocol Driver returns the UDP Packets to the IM
Driver after some processing.

Is this possible ?
[PCAUSA] Yes, this would actually work.

I also have some questions regarding this

Whether my NDIS IM Driver needs 2 interfaces at the upper
edge as it has to bound to both TCP/IP stack and my NDIS Protocol
Driver at the upper edge or i can do with only one interface?

[PCAUSA] Yes. It would follow the DDK ?MUX? sample driver
architecture.

When NDIS IM Driver receives the modified packet from the
protocol driver how will it distinguish the packet coming from TCP/
IP Stack and from the protocol driver.

[PCAUSA] You must invent your own method to make this distinction.

Splitting the work into two different drivers this way (or any
other way?) will add several months to your development time. It
simply makes no sense to me.

If you have common code that you want to use with different
drivers, consider using an ?export driver?. Actually, this is a
misnomer. An ?export driver? is not a separate runtime binary.
Instead, it is more like a kernel-mode static DLL. You can put
common code in the ?export driver? and use it with different
drivers like you would a static DLL.

Good luck. You are putting together a design that will take much
more time to achieve then you think.

Thomas F. Divine

— 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

anton_bassov · June 14, 2007, 1:09am

> I think now i am clear about my requirement.

Congratulations!!! Up to this point, we have seen the following “requirements”

Communication between NDIS IM and non-NDIS driver
Two NDIS IM drivers, with one of these “NDIS IM’s” being unbound from the network stack
NDIS PIM

What have you got up your sleeve now? Here we go:

Can i achieve somethink like this

NDIS IM Driver that receives all the packets from TCP/IP stack and NIC
Driver and passes only UDP Packets to a NDIS Protocol Driver.Then NDIS
Protocol Driver returns the UDP Packets to the IM Driver after some processing.

As I told you already on another thread, what you need here is not a protocol driver but a dummy virtual miniport one. If you do it this way, you will have a “proprietary channel” via which IM and this bogus miniport communicate by means of NdisSend() and NdisMIndicatePacket()…

The above is purely a *theory* - in practical terms, you should do everything in a single NDIS IM driver, and you were told it quite a few times on various threads that you have started. It looks like it just does not get in…

I also have some questions regarding this

Whether my NDIS IM Driver needs 2 interfaces at the upper edge as it has
to bound to both TCP/IP stack and my NDIS Protocol Driver at the upper edge
or i can do with only one interface?

Stop posting questions, and, instead, go and learn NDIS basics…

Anton Bassov

OSR_Community_User · June 14, 2007, 1:49am

Why you all are so angry with me and my questions.

You all are experts i know thats why i asked these questions fron you.If i
was a expert i would never ask a question

I know that 2 module approch is useless, waste ,impractical but my client
wants me to check whether it is feasible or not.

He wants that till tomorrow thats why i am so eager and i started several
threads and joined many forums but to my surprise in all the forums i joined
i found only one guy that always gives replies and is always angry with me
that is Thomas F. Divine.

Thomas i know you are God of NDIS.

Lastly i just wants to know is their any tool on winXp that can help me
achieve my goal?

On 6/14/07, xxxxx@hotmail.com wrote:
>
> > I think now i am clear about my requirement.
>
> Congratulations!!! Up to this point, we have seen the following
> “requirements”
>
> 1. Communication between NDIS IM and non-NDIS driver
> 2. Two NDIS IM drivers, with one of these “NDIS IM’s” being unbound from
> the network stack
> 3. NDIS PIM
>
> What have you got up your sleeve now? Here we go:
>
>
> > Can i achieve somethink like this
>
> > NDIS IM Driver that receives all the packets from TCP/IP stack and NIC
> > Driver and passes only UDP Packets to a NDIS Protocol Driver.Then NDIS
> > Protocol Driver returns the UDP Packets to the IM Driver after some
> processing.
>
>
> As I told you already on another thread, what you need here is not a
> protocol driver but a dummy virtual miniport one. If you do it this way, you
> will have a “proprietary channel” via which IM and this bogus
> miniport communicate by means of NdisSend() and NdisMIndicatePacket()…
>
> The above is purely a theory - in practical terms, you should do
> everything in a single NDIS IM driver, and you were told it quite a few
> times on various threads that you have started. It looks like it just does
> not get in…
>
> > I also have some questions regarding this
>
> > 1. Whether my NDIS IM Driver needs 2 interfaces at the upper edge as it
> has
> > to bound to both TCP/IP stack and my NDIS Protocol Driver at the upper
> edge
> > or i can do with only one interface?
>
> Stop posting questions, and, instead, go and learn NDIS basics…
>
> 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
>

Thomas_Divine-2 · June 14, 2007, 2:15am

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Thursday, June 14, 2007 1:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS IM Driver to NDIS Protocol Driver

Why you all are so angry with me and my questions.

You all are experts i know thats why i asked these questions fron you.If i
was a expert i would never ask a question

I know that 2 module approch is useless, waste ,impractical but my client
wants me to check whether it is feasible or not.

He wants that till tomorrow thats why i am so eager and i started several
threads and joined many forums but to my surprise in all the forums i joined
i found only one guy that always gives replies and is always angry with me
that is Thomas F. Divine.

Thomas i know you are God of NDIS.

[PCAUSA] That is far from the truth. Most of the other folks who have given
you answers are brighter than myself.For sure, any of the folks on this list
who have worked on Native 802.11 or 10Gbe Ethernet miniports are in a class
beyond mine.

I’ve just been around a long time.

We have all been trying to tell you that the “two module” approach is
absolutely the worst approach you can think of.

I have always been polite to you and given the best answer that I could
based on the information you provided.

You have finally given the key piece of your story, though. Your “client
wants me to check whether it is feasible or not”. We all understand that our
clients often don’t really know what they are talking about. You have to
educate them sometimes. Sometimes you have to turn down a job because the
client’s “requirements” cannot be realized.

You should consider telling your client that 1.) the two driver (or “two
module”) idea is a very bad one and 2.) you really need more time to learn
about NDIS before you can tell him what is an achievable design.

Lastly i just wants to know is their any tool on winXp that can help me
achieve my goal?

[PCAUSA] No. As always, using one NDIS IM driver is the most practical
approach.

Try to use an “export driver” if you want common code.

Thomas F. Divine

On 6/14/07, xxxxx@hotmail.com wrote:

> I think now i am clear about my requirement.

Congratulations!!! Up to this point, we have seen the following
“requirements”

1. Communication between NDIS IM and non-NDIS driver
2. Two NDIS IM drivers, with one of these “NDIS IM’s” being unbound from the
network stack
3. NDIS PIM

What have you got up your sleeve now? Here we go:

> Can i achieve somethink like this

> NDIS IM Driver that receives all the packets from TCP/IP stack and NIC
> Driver and passes only UDP Packets to a NDIS Protocol Driver.Then NDIS
> Protocol Driver returns the UDP Packets to the IM Driver after some
processing.

As I told you already on another thread, what you need here is not a
protocol driver but a dummy virtual miniport one. If you do it this way, you
will have a “proprietary channel” via which IM and this bogus miniport
communicate by means of NdisSend() and NdisMIndicatePacket()…

The above is purely a theory - in practical terms, you should do
everything in a single NDIS IM driver, and you were told it quite a few
times on various threads that you have started. It looks like it just does
not get in…

> I also have some questions regarding this

> 1. Whether my NDIS IM Driver needs 2 interfaces at the upper edge as it
has
> to bound to both TCP/IP stack and my NDIS Protocol Driver at the upper
edge
> or i can do with only one interface?

Stop posting questions, and, instead, go and learn NDIS basics…

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

— 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

OSR_Community_User · June 14, 2007, 2:57am

Thanks all for guiding me.

My Last Question is that can we use shared memory to pass packets from NDIS
IM Driver to an application.?

i will certainly read some books on NDIS once the approach is finalized.

Please guide me in this last question.

This is request from a beginner to all the experts.

Sunny.

On 6/14/07, Thomas F. Divine wrote:
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *shobhit shingla
> Sent: Thursday, June 14, 2007 1:49 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] NDIS IM Driver to NDIS Protocol Driver
>
>
>
> Why you all are so angry with me and my questions.
>
>
>
> You all are experts i know thats why i asked these questions fron you.If i
> was a expert i would never ask a question
>
>
>
> I know that 2 module approch is useless, waste ,impractical but my client
> wants me to check whether it is feasible or not.
>
>
>
> He wants that till tomorrow thats why i am so eager and i started several
> threads and joined many forums but to my surprise in all the forums i joined
> i found only one guy that always gives replies and is always angry with me
> that is Thomas F. Divine.
>
>
>
> Thomas i know you are God of NDIS.
>
> [PCAUSA] That is far from the truth. Most of the other folks who have
> given you answers are brighter than myself.For sure, any of the folks on
> this list who have worked on Native 802.11 or 10Gbe Ethernet miniports are
> in a class beyond mine.
>
> *
>
> * I’ve just been around a long time.
>
> * *
>
> We have all been trying to tell you that the “two module” approach is
> absolutely the worst approach you can think of.
>
> * *
>
> I have always been polite to you and given the best answer that I could
> based on the information you provided.
>
> * *
>
> You have finally given the key piece of your story, though. Your “client
> wants me to check whether it is feasible or not”. We all understand that our
> clients often don’t really know what they are talking about. You have to
> educate them sometimes. Sometimes you have to turn down a job because the
> client’s “requirements” cannot be realized.
>
> * *
>
> You should consider telling your client that 1.) the two driver (or “two
> module”) idea is a very bad one and 2.) you really need more time to learn
> about NDIS before you can tell him what is an achievable design.
>
>
>
> Lastly i just wants to know is their any tool on winXp that can help me
> achieve my goal?
>
> [PCAUSA] No. As always, using one NDIS IM driver is the most practical
> approach.
>
> * *
>
> Try to use an “export driver” if you want common code.
>
> * *
>
> Thomas F. Divine
>
>
>
>
>
>
>
>
>
> On 6/14/07, xxxxx@hotmail.com wrote:
>
> > I think now i am clear about my requirement.
>
> Congratulations!!! Up to this point, we have seen the following
> “requirements”
>
> 1. Communication between NDIS IM and non-NDIS driver
> 2. Two NDIS IM drivers, with one of these “NDIS IM’s” being unbound from
> the network stack
> 3. NDIS PIM
>
> What have you got up your sleeve now? Here we go:
>
>
> > Can i achieve somethink like this
>
> > NDIS IM Driver that receives all the packets from TCP/IP stack and NIC
> > Driver and passes only UDP Packets to a NDIS Protocol Driver.Then NDIS
> > Protocol Driver returns the UDP Packets to the IM Driver after some
> processing.
>
>
> As I told you already on another thread, what you need here is not a
> protocol driver but a dummy virtual miniport one. If you do it this way, you
> will have a “proprietary channel” via which IM and this bogus
> miniport communicate by means of NdisSend() and NdisMIndicatePacket()…
>
> The above is purely a theory - in practical terms, you should do
> everything in a single NDIS IM driver, and you were told it quite a few
> times on various threads that you have started. It looks like it just does
> not get in…
>
> > I also have some questions regarding this
>
> > 1. Whether my NDIS IM Driver needs 2 interfaces at the upper edge as it
> has
> > to bound to both TCP/IP stack and my NDIS Protocol Driver at the upper
> edge
> > or i can do with only one interface?
>
> Stop posting questions, and, instead, go and learn NDIS basics…
>
> Anton Bassov
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 http:
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> http:
>
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 http:To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer http:
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer http:
></http:></http:></http:></http:></http:></http:>

Thomas_Divine-2 · June 14, 2007, 9:44am

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Thursday, June 14, 2007 2:57 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS IM Driver to NDIS Protocol Driver

Thanks all for guiding me.

My Last Question is that can we use shared memory to pass packets from NDIS
IM Driver to an application.?

[PCAUSA] Please search the archives of this list for the answer to this.

The most reliable approach is to use the “inverted call” I/O technique. The
archives discuss the benefits and drawbacks of using inverted I/O vs shared
memory.

Thomas F. Divine

i will certainly read some books on NDIS once the approach is finalized.

Please guide me in this last question.

This is request from a beginner to all the experts.

Sunny.

On 6/14/07, Thomas F. Divine wrote:

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Thursday, June 14, 2007 1:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS IM Driver to NDIS Protocol Driver

Why you all are so angry with me and my questions.

You all are experts i know thats why i asked these questions fron you.If i
was a expert i would never ask a question

I know that 2 module approch is useless, waste ,impractical but my client
wants me to check whether it is feasible or not.

He wants that till tomorrow thats why i am so eager and i started several
threads and joined many forums but to my surprise in all the forums i joined
i found only one guy that always gives replies and is always angry with me
that is Thomas F. Divine.

Thomas i know you are God of NDIS.

[PCAUSA] That is far from the truth. Most of the other folks who have given
you answers are brighter than myself.For sure, any of the folks on this list
who have worked on Native 802.11 or 10Gbe Ethernet miniports are in a class
beyond mine.

I’ve just been around a long time.

We have all been trying to tell you that the “two module” approach is
absolutely the worst approach you can think of.

I have always been polite to you and given the best answer that I could
based on the information you provided.

You have finally given the key piece of your story, though. Your “client
wants me to check whether it is feasible or not”. We all understand that our
clients often don’t really know what they are talking about. You have to
educate them sometimes. Sometimes you have to turn down a job because the
client’s “requirements” cannot be realized.

You should consider telling your client that 1.) the two driver (or “two
module”) idea is a very bad one and 2.) you really need more time to learn
about NDIS before you can tell him what is an achievable design.

Lastly i just wants to know is their any tool on winXp that can help me
achieve my goal?

[PCAUSA] No. As always, using one NDIS IM driver is the most practical
approach.

Try to use an “export driver” if you want common code.

Thomas F. Divine

On 6/14/07, xxxxx@hotmail.com < mailto:xxxxx
xxxxx@hotmail.com > wrote:

> I think now i am clear about my requirement.

Congratulations!!! Up to this point, we have seen the following
“requirements”

1. Communication between NDIS IM and non-NDIS driver
2. Two NDIS IM drivers, with one of these “NDIS IM’s” being unbound from the
network stack
3. NDIS PIM

What have you got up your sleeve now? Here we go:

> Can i achieve somethink like this

> NDIS IM Driver that receives all the packets from TCP/IP stack and NIC
> Driver and passes only UDP Packets to a NDIS Protocol Driver.Then NDIS
> Protocol Driver returns the UDP Packets to the IM Driver after some
processing.

As I told you already on another thread, what you need here is not a
protocol driver but a dummy virtual miniport one. If you do it this way, you
will have a “proprietary channel” via which IM and this bogus miniport
communicate by means of NdisSend() and NdisMIndicatePacket()…

The above is purely a theory - in practical terms, you should do
everything in a single NDIS IM driver, and you were told it quite a few
times on various threads that you have started. It looks like it just does
not get in…

> I also have some questions regarding this

> 1. Whether my NDIS IM Driver needs 2 interfaces at the upper edge as it
has
> to bound to both TCP/IP stack and my NDIS Protocol Driver at the upper
edge
> or i can do with only one interface?

Stop posting questions, and, instead, go and learn NDIS basics…

Anton Bassov

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:pvih/article.cfm?id=256>

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
http:pvih/page.cfm?name=ListServer>

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:pvih/article.cfm?id=256> To unsubscribe, visit the List Server section of
OSR Online at http://www.osronline.com/page.cfm?name=ListServer
http:pvih/page.cfm?name=ListServer>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:pvih/article.cfm?id=256>

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
http:pvih/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</http:></http:></http:></http:></http:></http:></mailto:xxxxx>

anton_bassov · June 14, 2007, 10:05am

> My Last Question is that can we use shared memory to pass packets from NDIS

IM Driver to an application.?

And, again, you ask a question to which you have already been given an answer and that had been discussed a countless number of times on OSR and MSFT forums…

Are you still wondering why we find your questions irritating???

I will tell you just one more time - indeed, you *CAN* use shared memory for this purpose,
but it does not mean that this is a good idea in this context ( idiomatically, it is like putting peas up your nose - it can be done, but any reasonable individual just would not do it). What you need here is “inverted call” - you have to register a standalone device with NdisMRegisterDevice() so that non-NDIS components will be able to deal with your IM via a regular Dispatch interface, and make your app send requests to it. Your driver will pend these requests, and complete them when it wants to inform an app about some event and/or pass some data to it…

Anton Bassov

Tim_Roberts · June 14, 2007, 1:03pm

shobhit shingla wrote:

My Last Question is that can we use shared memory to pass packets from
NDIS IM Driver to an application.?

See, once again you are asking a very specific question about a very
narrow area without telling us what the real goal is. Of course is it
POSSIBLE to use shared memory to pass packets from an NDIS IM Driver to
an application. Is it a good idea? Almost certainly not. Are there
better ways to achieve your goal? Almost certainly yes. Can we tell
you those better ways? No, because you have NOT TOLD US WHAT THE ACTUAL
GOAL IS. Are you trying to write a packet monitor? Are you trying to
write something to reflect packets to another destination on the
network? Are you trying to write a packet broadcaster or a “tee”
filter? Are you trying to write a spyware network hijacker? All of
these things can be done in a supported way, but they require different
solutions, and at this point you simply do not have the experience or
knowhow to ask questions at the level you are asking.

I don’t want you to think we are picking on you. This is a very, very
common problem on newsgroups and lists like this. People want to feel
like “one of the club”, so they ask very specific questions about the
architecture they THINK they need to use, without understanding that
there may be perfectly viable and well-known ways to solve the overall
problem they are trying to solve.

i will certainly read some books on NDIS once the approach is finalized.

That’s kind of like studying for the SAT just after you have taken and
failed the test. You should read up on NDIS long BEFORE an approach is
finalized. It is your new NDIS knowledge that will help you architect
the correct approach.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

anton_bassov · June 14, 2007, 6:27pm

>> i will certainly read some books on NDIS once the approach is finalized.

You should read up on NDIS long BEFORE an approach is finalized. It is your
new NDIS knowledge that will help you architect the correct approach.

Actually, AFAIK, neither books nor tutorials that can be easily understood by beginners are available on this subject - you’ve got to learn everything on your own. In order to be able to do it, one needs a good understanding of general kernel concepts, and, preferably, at least some practical experience in writing WDM drivers. However, the OP does not seems to have either, so that he is just miles away from the point when he can start thinking about NDIS…

Anton Bassov

Prokash_Sinha-1 · June 14, 2007, 8:54pm

http://www.amazon.com/Networking-Device-Drivers-Sanjay-Dhawan/dp/0471286710

with Thomas’s website could be a good start …

-pro

>> i will certainly read some books on NDIS once the approach is
>> finalized.

> You should read up on NDIS long BEFORE an approach is finalized. It is
> your
> new NDIS knowledge that will help you architect the correct approach.

Actually, AFAIK, neither books nor tutorials that can be easily understood
by beginners are available on this subject - you’ve got to learn
everything on your own. In order to be able to do it, one needs a good
understanding of general kernel concepts, and, preferably, at least some
practical experience in writing WDM drivers. However, the OP does not
seems to have either, so that he is just miles away from the point when he
can start thinking about NDIS…

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

anton_bassov · June 14, 2007, 9:54pm

> http://www.amazon.com/Networking-Device-Drivers-Sanjay-Dhawan/dp/0471286710

Actually, I am not sure it is still in print - 3 out of 4 reviews made back in June 2000 describe it as completely outdated and useless. If I got it right, it is focused on NDIS2, so it must be, softly speaking, “of rather limited value” to NDIS developers in the year 2007…

with Thomas’s website could be a good start …

Thomas’s site it is not meant to be a starting point for newbies - it is meant to help NDIS developers with dodgy and not-so-obvious issues that they may encounter while writing NDIS drivers( and there are *plenty* of them), so that newbies have a rather slim chance to understand anything there. For example, someone who does not know what OIDs are ,what they are used for and how they are submitted to miniports by the bound protocols is very unlikely to understand the article that explains why modifying NDIS IM filter should fail OID_TCP_TASK_OFFLOAD, instead of passing it down to miniport. Therefore, first of all, you have to read all NDIS-related docs on MSDN and review code samples that come with WDK - otherwise, you will be just unable to understand what articles on Thomas’s site are about.

Anton Bassov

Prokash_Sinha-1 · June 14, 2007, 10:28pm

>> http://www.amazon.com/Networking-Device-Drivers-Sanjay-Dhawan/dp/0471286710

Actually, I am not sure it is still in print - 3 out of 4 reviews made
back in June 2000 describe it as completely outdated and useless. If I got
it right, it is focused on NDIS2, so it must be, softly speaking, “of
rather limited value” to NDIS developers in the year 2007…

I’ve used it about 8 yrs back. It is really a good start for someone who
has hardly any background on networking ( a bit of ndis history and
perspective, get to know about the framework etc.etc).

If you give the OP ndis 5.x or 6.y, he could very well be lost ( well if
he is not already ! )

> with Thomas’s website could be a good start …

Thomas’s site it is not meant to be a starting point for newbies - it is
meant to help NDIS developers with dodgy and not-so-obvious issues that
they may encounter while writing NDIS drivers( and there are *plenty* of
them), so that newbies have a rather slim chance to understand anything
there. For example, someone who does not know what OIDs are ,what they
are used for and how they are submitted to miniports by the bound
protocols is very unlikely to understand the article that explains why
modifying NDIS IM filter should fail OID_TCP_TASK_OFFLOAD, instead of
passing it down to miniport. Therefore, first of all, you have to read all
NDIS-related docs on MSDN and review code samples that come with WDK -
otherwise, you will be just unable to understand what articles on Thomas’s
site are about.

Few of these are really covered in that book, IIRC, though at a basic
level and that is what he needs.

Also there might be a video presentation by Brian Catlan ( can’t remember
the name ) and that also has a nice coverage.

Frankly, he is at a point that requires any and every help, then he could
be picky later !!!

-pro

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

anton_bassov · June 14, 2007, 11:29pm

> If you give the OP ndis 5.x or 6.y, he could very well be lost

5.x or 6.y??? Please note that NDIS 6 is much easier than NDIS 5, at least when it comes to filtering. NDIS 6 introduced the concept of LWF,so that you don’t have to write your IM filter as a combination miniport and protocol drivers. Although, in practical terms, LWF may have all functionality of NDIS 5 IM filter, it is not required to deal with anything. There are only 4 handlers that are necessary, and only 1 out of these 4 requires implementation (you have to set filter attributes in FltAttach()). The remaining 3 required handlers may be just do-nothing dummies, and all other handlers are optional - you don’t even have to register them. Certainly, so simplistic filter is of very little (if any) practical value, but, for the very beginning, this is OK. The beauty of LWF is that you can develop your driver incrementally, i.e. to add new functionality only when you are absolutely sure the existing one work perfectly well - this is not the kind of thing you can do with NDIS 5 IM filter that has to do quite a lot even for a simple initialization. To make things even easier, unlike NDIS 5, NDIS 6 allows only one path (which is true for both for incoming and outgoing packets), so that you don’t have to worry about media-specific vs packet-based indications, partial indications, as well as about single-packet vs multi-packet sends.

Actually, if the OP went for NDIS 6 LWF, I think he would have a chance to produce more or less workable driver, despite his lack of knowledge - once LWF can be developed incrementally, he would have a chance to gain knowledge on step-by-step basis. However, he has absolutely no chance to write a workable NDIS 5 IM filter with his level of knowledge …

Anton Bassov