Hi all
can anyone guide me about NDIS Pseudo IM Driver?
I want to write a pseudo IM Driver to capture all the packets from both the
TCp/Ip Stack and the NIC driver.
The description given on the www.pcausa.com is not enough for writing the
NDIS PIM.
Thanks in advance.
Sunny
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Wednesday, June 13, 2007 11:16 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS Pseudo IM Driver (PIM)
Hi all
can anyone guide me about NDIS Pseudo IM Driver?
I want to write a pseudo IM Driver to capture all the packets from both the
TCp/Ip Stack and the NIC driver.
[PCAUSA] No you don’t!!!
You have been asking about packet filtering on this newsgroup and others for
a long time and have been given the answer that you need to use a NDIS IM
driver and interface it to your application.
You have apparently also seemed to think that using a NDIS IM driver is too
difficult. I may be wrong on this because you have never stated your
requirements clearly enough for me to know.
Well, let me tell you that using a PIM driver (AKA “NDIS-Hooking”) driver is
unthinkable for someone with your level of experience. Based on the kinds of
questions you have asked about very fundamental things in driver development
you are years away from even beginning this sort of driver.
A NDIS-Hooking solution on current Windows platforms will have all of the
problems of a NDIS IM solution plus will almost certainly lead to system
instability if deployed.
Let me say one additional thing. NDIS-Hooking drivers were absolutely
required on Windows 9X/ME and on Windows NT 4.0. NDIS IM filter drivers were
just a failed experiment on those platforms because they could not be
installed reliably and could not deal robustly with adapter removal, etc. In
fact, on some of those platforms Microsoft actually published system APIs
that made “hooking” a first-class, supported technique.
Not so anymore!!!
Windows 2000 introduced the first Windows version where NDIS IM drivers
actually worked. On that platform NDIS-Hooking also worked.
However, given a choice it is clear that one should not consider
NDIS-Hooking unless there is a truly monumental requirement that must be
satisfied.
If you go down the NDIS-Hooking path you will be shooting yourself in the
foot.
Thomas F. Divine
The description given on the www.pcausa.com is not enough for writing the
NDIS PIM.
Thanks in advance.
Sunny
— 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
What Thomas said and more…
NDIS Hook Drivers that replace function (pointers) in the internal NDIS
datastructures (Miniport Block, Protocol Block) at one time could work if
you were real careful and lucky. Now, however (and I think that starts
*with* Win2K, not after) there are problems and edge conditions that just
cannot be dealt with ‘external to NDIS’. Getting a safe ‘lock’ for
instance to even begin to traverse these data structures on a multiprocessor
system is, well, pretty darn difficult. Moreover, with the removal of the
“Full MAC” driver and the exclusive use of NDIS4+ style Miniport drivers for
NICs, there are some things that just cannot be managed correctly. Some
really fun stuff occurs when media is connected and disconnected, for
instance, that breaks data transfer when one of the more popular NDIS
hooking drivers is installed.
If all you want to do is capture packets then go get WinPCAP and use it.
Good Luck,
-dave
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, June 13, 2007 12:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS Pseudo IM Driver (PIM)
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Wednesday, June 13, 2007 11:16 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS Pseudo IM Driver (PIM)
Hi all
can anyone guide me about NDIS Pseudo IM Driver?
I want to write a pseudo IM Driver to capture all the packets from both the
TCp/Ip Stack and the NIC driver.
[PCAUSA] No you don?t!!!
You have been asking about packet filtering on this newsgroup and others for
a long time and have been given the answer that you need to use a NDIS IM
driver and interface it to your application.
You have apparently also seemed to think that using a NDIS IM driver is too
difficult. I may be wrong on this because you have never stated your
requirements clearly enough for me to know.
Well, let me tell you that using a PIM driver (AKA ?NDIS-Hooking?) driver is
unthinkable for someone with your level of experience. Based on the kinds of
questions you have asked about very fundamental things in driver development
you are years away from even beginning this sort of driver.
A NDIS-Hooking solution on current Windows platforms will have all of the
problems of a NDIS IM solution plus will almost certainly lead to system
instability if deployed.
Let me say one additional thing. NDIS-Hooking drivers were absolutely
required on Windows 9X/ME and on Windows NT 4.0. NDIS IM filter drivers were
just a failed experiment on those platforms because they could not be
installed reliably and could not deal robustly with adapter removal, etc. In
fact, on some of those platforms Microsoft actually published system APIs
that made ?hooking? a first-class, supported technique.
Not so anymore!!!
Windows 2000 introduced the first Windows version where NDIS IM drivers
actually worked. On that platform NDIS-Hooking also worked.
However, given a choice it is clear that one should not consider
NDIS-Hooking unless there is a truly monumental requirement that must be
satisfied.
If you go down the NDIS-Hooking path you will be shooting yourself in the
foot.
Thomas F. Divine
The description given on the www.pcausa.com is not enough for writing the
NDIS PIM.
Thanks in advance.
Sunny
— 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
And to add something more…
**Please** do not implement an NDIS hook driver. As the maintainer of the WinPcap protocol driver (yes, you can yell at me if it doesn’t work!) I can tell you that debugging crashes due to buggy NDIS hooks is A PAIN. And bugs in the hook cause crashes mostly in the NDIS miniport and protocol drivers. This is what users will see in the BSOD. It’s always a joy to see a completely scrambled stack trace in which a protocol driver jumps somewhere in some mysterious binary.
Just my two cents
GV
----- Original Message -----
From: David R. Cattley
To: Windows System Software Devs Interest List
Sent: Wednesday, June 13, 2007 11:10 AM
Subject: RE: [ntdev] NDIS Pseudo IM Driver (PIM)
What Thomas said and more…
NDIS Hook Drivers that replace function (pointers) in the internal NDIS datastructures (Miniport Block, Protocol Block) at one time could work if you were real careful and lucky. Now, however (and I think that starts *with* Win2K, not after) there are problems and edge conditions that just cannot be dealt with ‘external to NDIS’. Getting a safe ‘lock’ for instance to even begin to traverse these data structures on a multiprocessor system is, well, pretty darn difficult. Moreover, with the removal of the “Full MAC” driver and the exclusive use of NDIS4+ style Miniport drivers for NICs, there are some things that just cannot be managed correctly. Some really fun stuff occurs when media is connected and disconnected, for instance, that breaks data transfer when one of the more popular NDIS hooking drivers is installed.
If all you want to do is capture packets then go get WinPCAP and use it.
Good Luck,
-dave
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, June 13, 2007 12:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS Pseudo IM Driver (PIM)
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Wednesday, June 13, 2007 11:16 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS Pseudo IM Driver (PIM)
Hi all
can anyone guide me about NDIS Pseudo IM Driver?
I want to write a pseudo IM Driver to capture all the packets from both the TCp/Ip Stack and the NIC driver.
[PCAUSA] No you don’t!!!
You have been asking about packet filtering on this newsgroup and others for a long time and have been given the answer that you need to use a NDIS IM driver and interface it to your application.
You have apparently also seemed to think that using a NDIS IM driver is too difficult. I may be wrong on this because you have never stated your requirements clearly enough for me to know.
Well, let me tell you that using a PIM driver (AKA “NDIS-Hooking”) driver is unthinkable for someone with your level of experience. Based on the kinds of questions you have asked about very fundamental things in driver development you are years away from even beginning this sort of driver.
A NDIS-Hooking solution on current Windows platforms will have all of the problems of a NDIS IM solution plus will almost certainly lead to system instability if deployed.
Let me say one additional thing. NDIS-Hooking drivers were absolutely required on Windows 9X/ME and on Windows NT 4.0. NDIS IM filter drivers were just a failed experiment on those platforms because they could not be installed reliably and could not deal robustly with adapter removal, etc. In fact, on some of those platforms Microsoft actually published system APIs that made “hooking” a first-class, supported technique.
Not so anymore!!!
Windows 2000 introduced the first Windows version where NDIS IM drivers actually worked. On that platform NDIS-Hooking also worked.
However, given a choice it is clear that one should not consider NDIS-Hooking unless there is a truly monumental requirement that must be satisfied.
If you go down the NDIS-Hooking path you will be shooting yourself in the foot.
Thomas F. Divine
The description given on the www.pcausa.com is not enough for writing the NDIS PIM.
Thanks in advance.
Sunny
— 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
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
Gianluca,
**Please** do not implement an NDIS hook driver. As the maintainer of the
WinPcap protocol driver (yes, you can yell at me if it doesn’t work!) I can tell
you that debugging crashes due to buggy NDIS hooks is A PAIN.
Actually, from our perspective it is better if the OP writes PIM, rather than “conventional” NDIS IM filter - the beauty of PIM here is that it is “unsupported”. Let’s face it - no matter if the OP writes
PIM or “proper” NDIS IM, it is going to be crap anyway (judging from his posts, he has no clue about NDIS whatsoever, and, to make things worse, he is not really willing to learn it - he just wants to be “guided”). If his crap is “unsupported” (which can be easily established with a Driver Verifier) it is much easier to convince your client that it is his “masterpiece” and not your NDIS IM driver who is responsible for crashes. However, if he writes a “conventional” NDIS IM, it is going to be much more difficult to convince a client that it is his “masterpiece” and not your driver who is responsible for lost packets, lost connectivity, etc,etc,etc…
Anton Bassov
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 13, 2007 4:27 PM
Subject: RE:[ntdev] NDIS Pseudo IM Driver (PIM)
> Gianluca,
>
>> Please do not implement an NDIS hook driver. As the maintainer of the
>> WinPcap protocol driver (yes, you can yell at me if it doesn’t work!) I
>> can tell
>> you that debugging crashes due to buggy NDIS hooks is A PAIN.
>
> Actually, from our perspective it is better if the OP writes PIM, rather
> than “conventional” NDIS IM filter - the beauty of PIM here is that it is
> “unsupported”. Let’s face it - no matter if the OP writes
> PIM or “proper” NDIS IM, it is going to be crap anyway (judging from his
> posts, he has no clue about NDIS whatsoever, and, to make things worse, he
> is not really willing to learn it - he just wants to be “guided”). If his
> crap is “unsupported” (which can be easily established with a Driver
> Verifier) it is much easier to convince your client that it is his
> “masterpiece” and not your NDIS IM driver who is responsible for crashes.
> However, if he writes a “conventional” NDIS IM, it is going to be much
> more difficult to convince a client that it is his “masterpiece” and not
> your driver who is responsible for lost packets, lost connectivity,
> etc,etc,etc…
>
You are partially right. It’s just that debugging hooked network stacks is
sometimes a pain, in any case it takes more time. Plus the client who
reports a blue screen just tells you “hey, your driver is faulty. There’s a
bug. Fix it”. Every now and then i receive these mails on the winpcap-bugs
mailing lists. It’s frustrating. Although I love debugging, spending time in
finding other drivers’ bugs instead of improving mine is frustrating…
Having said, I hope that the OP will study NDIS and Windows Internals a lot
before bringing an NDIS IM driver (or whatever that will be) into
production…
Ciao
GV
> 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
> Having said, I hope that the OP will study NDIS and Windows Internals a lot
before bringing an NDIS IM driver (or whatever that will be) into production…
Unfortunately, learning NDIS seems to be the last thing the OP wants to do - the way he put it himself, “he just has no time to study books on it”. Therefore, instead of trying to learn, he wants to be “guided”. Look at his posts - he asks a question, gets a reply to it, and, if the reply is negative, he starts another thread with basically the same question (please note that his questions mainly repeat themselves - he just seems to forget the answers that he gets)…
Therefore, he just has no chance to produce anything, apart from crap. Hopefully, his “masterpiece” is going to fail all tests even on his development machine, so that he will just have no chance to put it into production, in the first place…
Anton Bassov
> Therefore, he just has no chance to produce anything, apart from crap.
Hopefully, his “masterpiece” is going to fail all tests even on his
development machine, so that he will just have no chance to put it
into
production, in the first place…
Something tells me we will see his progress here as a kind of weird
reality show 
OP, sorry, but if you don’t follow advices (i.e. study NDIS first), you
don’t have a chance to make anything working. People are irritated with
your questions just because of this; it is waste of time to help
somebody who doesn’t want to learn. Also, in this list it is expected to
make your homework first and ask later.
Michal
> Something tells me we will see his progress here as a kind of weird reality show
It would be great if this “reality show” was watched by those who try to outsource projects in order to save costs - probably, at this point people would realize whom they actually trust *kernel-level* jobs…
He is far from being an exceptional case. Plese check the thread about interrupts - down there the OP wants to handle interrupts in the user mode, seems to agree to our explanations that this is simply infeasible idea… but somehow keeps on asking how it can get done. The funniest thing is that he has been doing it FOR 6 MONTHS!!!
Anton Bassov
Ok by seeing your replies what i can make out is that you all cannot help me
that’s why you are insulting me .
If you all think that you all are experts in this field then how can you all
give such demotivating replies in all the threads i started.
everytime you all are complaining about my 2 module approach.and each time i
have been telling you that i just want to check the feasibility of this
approach.
You all didn’t suggest anything about the second module.
It was only me who suggested second module as NDIS IM Sometimes,application
sometimes or NDIS Protocol driver sometimes but all the experts can,t
suggest me anything on this second module and instead always saying that
this is difficult.
and for the knowledge of my dear friend antov i joined this list last month
only and not since 6 months.
On 6/15/07, xxxxx@hotmail.com wrote:
>
> > Something tells me we will see his progress here as a kind of weird
> reality show
>
>
> It would be great if this “reality show” was watched by those who try to
> outsource projects in order to save costs - probably, at this point people
> would realize whom they actually trust kernel-level jobs…
>
> He is far from being an exceptional case. Plese check the thread about
> interrupts - down there the OP wants to handle interrupts in the user mode,
> seems to agree to our explanations that this is simply infeasible idea…
> but somehow keeps on asking how it can get done. The funniest thing is that
> he has been doing it FOR 6 MONTHS!!!
>
> 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
>
shobhit shingla wrote:
Ok by seeing your replies what i can make out is that you all cannot
help me that’s why you are insulting me .If you all think that you all are experts in this field then how can
you all give such demotivating replies in all the threads i started.
Martin is right. It’s easy to take things too personally in a mailing list.
Many of us write drivers for a living. We are professionals, and we
take pride in producing a good, reliable product. However, we also know
that there are many, many, MANY companies shipping drivers that are
complete schlock, written by bozos who blindly cut-and-paste suggestions
at random from partly-related postings without a glimmer of
understanding of what those suggestions actually mean. These schlock
drivers give ALL driver writers a bad name, and we are sick and tired of
it. That makes us sensitive.
In most cases, it’s not hard to tell whether a person understands their
topic, or is actually asking for information that they do not possess
the background to understand. Based on your questions, it appears that
several of us have concluded that you don’t understand NDIS well enough
to understand why your suggested architecture is a bad idea. (I don’t,
either; I’m not an NDIS guy.) And yet, you persisted in trying to find
someone to bless your architecture. That’s the kind of thing that makes
people irritable.
everytime you all are complaining about my 2 module approach.and each
time i have been telling you that i just want to check the feasibility
of this approach.
OK. The answer, then, is that it is not feasible. The problem is that
you keep asking about it.
You need to find a different way to accomplish the overall goal.
However, repeating a theme I’ve brought up three times this week, you
have not told us what your overall goal is. You have told us that you
want two NDIS drivers. That’s not a goal. That’s merely one possible
step along a path towards achieving a goal. Tell us what the OVERALL
goal is, and someone here will be happy to suggest an architecture that
will solve the problem in a reliable and supportable way.
You all didn’t suggest anything about the second module.
Of course they did. They said “don’t do it”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Shobit,
It might not apply to you ( or anyone particular), but persistency on the
wrong direction is quite bad. There are few people got mad, seeing your
posting.
Seriously, people here are very very helpful. It is just, if anyone drops
questions of the same nature in different fashions, people gets upset.
Some of the people answered you are very very valuable.
Wellcome to the "windows kernel space craft … , rides could be
frigtening but that is the thrill !!!
-pro
Ok by seeing your replies what i can make out is that you all cannot help
me
that’s why you are insulting me .If you all think that you all are experts in this field then how can you
all
give such demotivating replies in all the threads i started.everytime you all are complaining about my 2 module approach.and each time
i
have been telling you that i just want to check the feasibility of this
approach.You all didn’t suggest anything about the second module.
It was only me who suggested second module as NDIS IM
Sometimes,application
sometimes or NDIS Protocol driver sometimes but all the experts can,t
suggest me anything on this second module and instead always saying that
this is difficult.and for the knowledge of my dear friend antov i joined this list last
month
only and not since 6 months.On 6/15/07, xxxxx@hotmail.com wrote:
>>
>> > Something tells me we will see his progress here as a kind of weird
>> reality show
>>
>>
>> It would be great if this “reality show” was watched by those who try to
>> outsource projects in order to save costs - probably, at this point
>> people
>> would realize whom they actually trust kernel-level jobs…
>>
>> He is far from being an exceptional case. Plese check the thread about
>> interrupts - down there the OP wants to handle interrupts in the user
>> mode,
>> seems to agree to our explanations that this is simply infeasible
>> idea…
>> but somehow keeps on asking how it can get done. The funniest thing is
>> that
>> he has been doing it FOR 6 MONTHS!!!
>>
>> 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
>>Ok by seeing your replies what i can make out is that you all cannot help
me that’s why you are insulting me .
Some have answered your questions (and others haver asked perfectly
reasonable questions of you that have not been answered in reply) with
courtesy. This list has plenty of ‘personality’, however, and getting
called names on this list is par for the course. Too bad, but true. Maybe
that will change someday. Right and Nice are two independent qualities.
Some a right. Some are nice. Some are right *and* nice. Personally, I
can tolerate !Nice && Right. Nice && ~Right don’t help, however and of
course we can just ignore !Nice && !Right.
> everytime you all are complaining about my 2 module approach.and each
time i have been telling you that i just want to check the feasibility of
this approach.
I think that it was explained loudly and clearly that the multi-module
approach, like most things is kernel mode, is feasable but highly
unavisable.
>You all didn’t suggest anything about the second module.
This list suggested that you not do it.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Friday, June 15, 2007 12:48 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS Pseudo IM Driver (PIM)
Ok by seeing your replies what i can make out is that you all cannot help me
that’s why you are insulting me .
If you all think that you all are experts in this field then how can you all
give such demotivating replies in all the threads i started.
everytime you all are complaining about my 2 module approach.and each time i
have been telling you that i just want to check the feasibility of this
approach.
You all didn’t suggest anything about the second module.
It was only me who suggested second module as NDIS IM Sometimes,application
sometimes or NDIS Protocol driver sometimes but all the experts can,t
suggest me anything on this second module and instead always saying that
this is difficult.
and for the knowledge of my dear friend antov i joined this list last month
only and not since 6 months.
Tim,
Based on your questions, it appears that several of us have concluded that you don’t understand > NDIS well enough to understand why your suggested architecture is a bad idea.
This is not the question of knowledge in itself - this is purely the question of *ATTITUDES* to things. If the guy just does not know things, this is not a problem at all - newbies are normally treated quite well in this NG, and originally the OP was not an exception to this rule. However, if the guy does not even *WANT* to learn, this is a totally different story. He got the worst treatment from those who actually worked with NDIS - it is obvious to anyone who is familiar with NDIS that in the period since his very first post (i.e. around a month ago) the OP just could not be bothered to read a *single*document on the subject. This is why because all his question are mainly repeating themselves - once he does not read NDIS-related docs, he is just unable to understand our answers to his questions, so that he repeats the same questions again and again and again. Probably, I gave the OP a bit of hard time, but I got really mad at the statement " I have no time to study books on it" - I hope you can imagine what is is like to have your properly written driver in the same stack with the OP’s “production”.
To summmarize, I don’t see any reason why the OP should play the role of a victim here - he tried really hard to turn everyone against himself.
Anton Bassov