RE: NDIS IM Driver Questions (WAS: Welcome to the NTDEV Discussion List!)

Thomas_Divine-2 · June 1, 2007, 1:05am

In your architecture NDIS IM Driver 2 simply cannot ever exist. No
discussion about this. End of subject!

A NDIS IM driver MUST bind to one or more lower-level miniport at its
lower-edge AND must be bound to at least one or more higher-level protocol
at its upper-edge.

Driver 2 can be some other type of non-NDIS driver, but it cannot be a NDIS
IM driver or an NDIS driver of any type.

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Friday, June 01, 2007 12:46 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!

Sorry the attachment is not allowed.

Here is the module structure

TCP/IP Protocol Stack

|

| All packets

| UDP Packets

NDIS IM Driver 1
<-----------------------------------> NDIS IM Driver 2

| UDP Packets
returned

|

Driver NIC

I have the following queries regarding this module structure

How can i bind NDIS IM Driver 1 to both the underlying NIC and to NDIS
IM Driver 2?
How will NDIS IM Driver 1 differentiate between packet coming from TCP/IP
Stack and from NDIS IM Driver 2.?(Do i need to create a separate interface
for NDIS IM Driver 2).

On 5/31/07, Gianluca Varenni < mailto:xxxxx
xxxxx@gmail.com > wrote:

Yes, it’s feasible to create two drivers that communicate and pass data
between each other.

And as Thomas already said, it’s jst discouraged because

1. inter-driver communication is complex. The problem is not the data
flowing between the two drivers, the problem is the infrastracture you need
to set up in order to guarantee that the one driver acts properly when the
other one gets loaded/unloaded.

2. NDIS IM drivers are complicated on their own (they are already quite two
drivers, a miniport and a protocol driver, bundled within the same binary).
Add to that the communication with another driver, and you can get into
trouble.

Hope it helps

GV

----- Original Message -----

From: shobhit shingla mailto:xxxxx

To: Windows mailto:xxxxx System Software Devs Interest List

Sent: Thursday, May 31, 2007 6:02 AM

Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!

I know that it is difficult but i just want to know that whether it is
feasible or not.if not can you please explain me the reason for the same.

Thanks in adnvance

On 5/31/07, Thomas F. Divine mailto:xxxxx > wrote:

Your question is really too vague to be of help.

In you IM driver you can do anything you want with packets that are sent or
received. You can examine them, pas them through transparently (as in the
Passthru sample), or throw them away.

If your driver can communicate with another driver (a chore in itself…),
then you can exchange information between your IM driver and another driver.
One example of information that you could exchange between your IM driver
and another driver is the information contained within a packet.

At this point you need to carefully understand what a “NDIS packet” really
is. See the “NDIS Packet Discussion” at
http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pwnte.pqdc/
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pwnte.pqdc/> .

After you understand what a “NDIS packet” really is, then you will probably
learn that you can pass the packet information to another driver. However,
the other driver must understand the structure of a “NDIS packet” and also
understand who owns the “NDIS packet” and how it must be returned to its
owner when you no longer have need of it.

The idea you are thinking of will be difficult to implement. I am sure that
most of the experienced NDIS developers on this list would avoid this
architecture at almost any cost.

Rethink your design approach. Try to follow GV’s advice: Process the packets
from within your IM driver!

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Thursday, May 31, 2007 12:15 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!

I can but i just want to check whether it is feasible to pass UDP Packets to
another Driver and then get it back.

On 5/30/07, Gianluca Varenni wrote:

Out of curiosity, why can’t you process the UDP packets from within the same
IM driver?

Have a nice day

GV

----- Original Message -----

From: shobhit shingla mailto:xxxxx

To: Windows mailto:xxxxx System Software Devs Interest List

Sent: Wednesday, May 30, 2007 6:07 AM

Subject: Re:[ntdev] Welcome to the NTDEV Discussion List!

I am developing an NDIS intermediate driver for my application.

I want my NDIS IM Driver to select UDP Packets from the packets coming from
TCP/IP Stack and send them to another driver(Any Driver,can be another IM
Driver) and also send the remaining packets(Non-UDP) to the Driver NIC to be
sent to the network.

The UDP Packets received by the other driver should then be returned as it
is to the sending driver.

My question is how can i send packets from one driver to another driver and
receive them back?
And
Is it possible to send some packets to one driver and other to another
driver.?

Thanks in Advance.

Sunny

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.pvih/page.cfm?name=ListServer>

—
Questions? First check the Kernel Driver FAQ at
http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.p
vih//article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.pvih/page.cfm?name=ListServer>

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih/page.cfm?name=ListServer>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih/page.cfm?name=ListServer>

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih/page.cfm?name=ListServer>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.pxccaazxdv.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:></http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · June 1, 2007, 1:36am

Hi

what kind of Non-NDIS driver it can be.

Thanks in advance.

On 6/1/07, Thomas F. Divine wrote:
>
> In your architecture NDIS IM Driver 2 simply cannot ever exist. No
> discussion about this. End of subject!
>
>
>
> A NDIS IM driver MUST bind to one or more lower-level miniport at its
> lower-edge AND must be bound to at least one or more higher-level
> protocol at its upper-edge.
>
>
>
> Driver 2 can be some other type of non-NDIS driver, but it cannot be a
> NDIS IM driver or an NDIS driver of any type.
>
>
>
> Thomas F. Divine
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *shobhit shingla
> Sent: Friday, June 01, 2007 12:46 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
>
>
>
> Sorry the attachment is not allowed.
>
>
>
> Here is the module structure
>
>
>
> TCP/IP Protocol Stack
>
> |
>
> | All packets
>
> | UDP
> Packets
>
> NDIS IM Driver 1
> <-----------------------------------> NDIS IM Driver 2
>
> | UDP Packets
> returned
>
> |
>
> |
>
> |
>
> Driver NIC
>
>
>
> I have the following queries regarding this module structure
>
>
>
> 1. How can i bind NDIS IM Driver 1 to both the underlying NIC and to
> NDIS IM Driver 2?
>
>
>
> 2. How will NDIS IM Driver 1 differentiate between packet coming from
> TCP/IP Stack and from NDIS IM Driver 2.?(Do i need to create a separate
> interface for NDIS IM Driver 2).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 5/31/07, Gianluca Varenni < xxxxx@gmail.com > wrote:
>
> Yes, it’s feasible to create two drivers that communicate and pass data
> between each other.
>
>
>
> And as Thomas already said, it’s jst discouraged because
>
> 1. inter-driver communication is complex. The problem is not the data
> flowing between the two drivers, the problem is the infrastracture you need
> to set up in order to guarantee that the one driver acts properly when the
> other one gets loaded/unloaded.
>
> 2. NDIS IM drivers are complicated on their own (they are already quite
> two drivers, a miniport and a protocol driver, bundled within the same
> binary). Add to that the communication with another driver, and you can get
> into trouble.
>
>
>
> Hope it helps
>
> GV
>
>
>
> ----- Original Message -----
>
> From: shobhit shingla
>
> To: Windows System Software Devs Interest List
>
> Sent: Thursday, May 31, 2007 6:02 AM
>
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
> I know that it is difficult but i just want to know that whether it is
> feasible or not.if not can you please explain me the reason for the same.
>
>
>
> Thanks in adnvance
>
>
>
> On 5/31/07, Thomas F. Divine wrote:
>
> Your question is really too vague to be of help.
>
>
>
> In you IM driver you can do anything you want with packets that are sent
> or received. You can examine them, pas them through transparently (as in the
> Passthru sample), or throw them away.
>
>
>
> If your driver can communicate with another driver (a chore in itself…),
> then you can exchange information between your IM driver and another driver.
> One example of information that you could exchange between your IM driver
> and another driver is the information contained within a packet.
>
>
>
> At this point you need to carefully understand what a “NDIS packet” really
> is. See the “NDIS Packet Discussion” at
> http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pwnte.pqdc/http:</http:>
> .
>
>
>
> After you understand what a “NDIS packet” really is, then you will
> probably learn that you can pass the packet information to another driver.
> However, the other driver must understand the structure of a “NDIS packet”
> and also understand who owns the “NDIS packet” and how it must be returned
> to its owner when you no longer have need of it.
>
>
>
> The idea you are thinking of will be difficult to implement. I am sure
> that most of the experienced NDIS developers on this list would avoid this
> architecture at almost any cost.
>
>
>
> Rethink your design approach. Try to follow GV’s advice: Process the
> packets from within your IM driver!
>
>
>
> Thomas F. Divine
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *shobhit shingla
> *Sent: *Thursday, May 31, 2007 12:15 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
> I can but i just want to check whether it is feasible to pass UDP Packets
> to another Driver and then get it back.
>
> On 5/30/07, Gianluca Varenni wrote:
>
> Out of curiosity, why can’t you process the UDP packets from within the
> same IM driver?
>
>
>
> Have a nice day
>
> GV
>
>
>
> ----- Original Message -----
>
> From: shobhit shingla
>
> To: Windows System Software Devs Interest List
>
> Sent: Wednesday, May 30, 2007 6:07 AM
>
> Subject: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
> I am developing an NDIS intermediate driver for my application.
>
> I want my NDIS IM Driver to select UDP Packets from the packets coming
> from TCP/IP Stack and send them to another driver(Any Driver,can be another
> IM Driver) and also send the remaining packets(Non-UDP) to the Driver NIC to
> be sent to the network.
>
> The UDP Packets received by the other driver should then be returned as it
> is to the sending driver.
>
> My question is how can i send packets from one driver to another driver
> and receive them back?
> And
> Is it possible to send some packets to one driver and other to another
> driver.?
>
> Thanks in Advance.
>
> Sunny
>
> — 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.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih//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:
>
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih//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:
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih//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:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:>

Thomas_Divine-2 · June 1, 2007, 2:35am

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Friday, June 01, 2007 1:36 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS IM Driver Questions (WAS: Welcome to the NTDEV
Discussion List!)

Hi

what kind of Non-NDIS driver it can be.

[PCAUSA] It will be what is usually called a “legacy NT kernel-mode driver”.
This is the simplest possible Windows driver. It basically has only one
required entry point: DriverEntry. In DriverEntry the driver initializes
it’s DriverObject with various information including the MajorFunction
table, which is a jump table to the system-defined callbacks for handling
opens, reads, writes, I/O control and other functions.

Your IM driver will communicate with this legacy driver by opening a handle
on the legacy driver and then performing open, read, write, I/O control,
etc.

YOU will have to get some books and study the fundamentals to how to write
this kind of driver. Unfortunately, I couldn’t see a really trivial sample
of this sort in the DDK.

As GV, others and I have said there are BIG problems with this design.

Your IM driver will be loaded at startup by the NDIS loader. Your legacy
driver will be loaded at a different time by the Service Control Manager.
You will probably have big problems is knowing or controlling which driver
is loaded first. You will also have big problems in letting each driver know
when the other is unloaded and can’t be called without causing a crash.

Really a scary design approach that I wouldn’t consider unless there was a
requirement that couldn’t be satisfied any other way. Let me put this
another way: It may seem like a good idea to partition functionality this
way - but it probably isn’t.

Thomas F. Divine

Thanks in advance.

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

In your architecture NDIS IM Driver 2 simply cannot ever exist. No
discussion about this. End of subject!

A NDIS IM driver MUST bind to one or more lower-level miniport at its
lower-edge AND must be bound to at least one or more higher-level protocol
at its upper-edge.

Driver 2 can be some other type of non-NDIS driver, but it cannot be a NDIS
IM driver or an NDIS driver of any type.

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Friday, June 01, 2007 12:46 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!

Sorry the attachment is not allowed.

Here is the module structure

TCP/IP Protocol Stack

|

| All packets

| UDP Packets

NDIS IM Driver 1
<-----------------------------------> NDIS IM Driver 2

| UDP Packets
returned

|

|

|

Driver NIC

I have the following queries regarding this module structure

1. How can i bind NDIS IM Driver 1 to both the underlying NIC and to NDIS
IM Driver 2?

2. How will NDIS IM Driver 1 differentiate between packet coming from TCP/IP
Stack and from NDIS IM Driver 2.?(Do i need to create a separate interface
for NDIS IM Driver 2).

On 5/31/07, Gianluca Varenni < mailto:xxxxx
xxxxx@gmail.com > wrote:

Yes, it’s feasible to create two drivers that communicate and pass data
between each other.

And as Thomas already said, it’s jst discouraged because

1. inter-driver communication is complex. The problem is not the data
flowing between the two drivers, the problem is the infrastracture you need
to set up in order to guarantee that the one driver acts properly when the
other one gets loaded/unloaded.

2. NDIS IM drivers are complicated on their own (they are already quite two
drivers, a miniport and a protocol driver, bundled within the same binary).
Add to that the communication with another driver, and you can get into
trouble.

Hope it helps

GV

----- Original Message -----

From: shobhit shingla mailto:xxxxx

To: Windows mailto:xxxxx System Software Devs Interest List

Sent: Thursday, May 31, 2007 6:02 AM

Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!

I know that it is difficult but i just want to know that whether it is
feasible or not.if not can you please explain me the reason for the same.

Thanks in adnvance

On 5/31/07, Thomas F. Divine mailto:xxxxx > wrote:

Your question is really too vague to be of help.

In you IM driver you can do anything you want with packets that are sent or
received. You can examine them, pas them through transparently (as in the
Passthru sample), or throw them away.

If your driver can communicate with another driver (a chore in itself…),
then you can exchange information between your IM driver and another driver.
One example of information that you could exchange between your IM driver
and another driver is the information contained within a packet.

At this point you need to carefully understand what a “NDIS packet” really
is. See the “NDIS Packet Discussion” at
http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pwnte.pqdc/
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pwnte.pqdc/> .

After you understand what a “NDIS packet” really is, then you will probably
learn that you can pass the packet information to another driver. However,
the other driver must understand the structure of a “NDIS packet” and also
understand who owns the “NDIS packet” and how it must be returned to its
owner when you no longer have need of it.

The idea you are thinking of will be difficult to implement. I am sure that
most of the experienced NDIS developers on this list would avoid this
architecture at almost any cost.

Rethink your design approach. Try to follow GV’s advice: Process the packets
from within your IM driver!

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shobhit shingla
Sent: Thursday, May 31, 2007 12:15 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!

I can but i just want to check whether it is feasible to pass UDP Packets to
another Driver and then get it back.

On 5/30/07, Gianluca Varenni wrote:

Out of curiosity, why can’t you process the UDP packets from within the same
IM driver?

Have a nice day

GV

----- Original Message -----

From: shobhit shingla mailto:xxxxx

To: Windows mailto:xxxxx System Software Devs Interest List

Sent: Wednesday, May 30, 2007 6:07 AM

Subject: Re:[ntdev] Welcome to the NTDEV Discussion List!

I am developing an NDIS intermediate driver for my application.

I want my NDIS IM Driver to select UDP Packets from the packets coming from
TCP/IP Stack and send them to another driver(Any Driver,can be another IM
Driver) and also send the remaining packets(Non-UDP) to the Driver NIC to be
sent to the network.

The UDP Packets received by the other driver should then be returned as it
is to the sending driver.

My question is how can i send packets from one driver to another driver and
receive them back?
And
Is it possible to send some packets to one driver and other to another
driver.?

Thanks in Advance.

Sunny

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih
/page.cfm?name=ListServer>

—
Questions? First check the Kernel Driver FAQ at
http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.p
vih//article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih
/page.cfm?name=ListServer>

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.pvih/page.cfm?name=ListServer>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.pvih/page.cfm?name=ListServer>

— Questions? First check the Kernel Driver FAQ at
http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.p
vih//article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.pvih/page.cfm?name=ListServer>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.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:xaz.pbbt.pnu/servlet/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet
/redirect.srv/p5.p1.pbcd.plrcufhrecdxaz.pbbt.pnu/servlet/redirect.srv/p5.p1.
pbcd.pxccaazxdv.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.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.p
vih//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:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · June 1, 2007, 3:05am

Thanks…

Actually my requirment is to block packets coming from TCP/IP stack and send
UDP Packets to something (which can be another driver, application etc) and
send remaining packets through driver NIC to the network.

So can i send packets from NDIS IM Driver to another module(which can be
another driver, application etc) and get back these packets from that
module.

Thanks in advance.

On 6/1/07, Thomas F. Divine wrote:
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *shobhit shingla
> Sent: Friday, June 01, 2007 1:36 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] NDIS IM Driver Questions (WAS: Welcome to the NTDEV
> Discussion List!)
>
>
>
>
>
> Hi
>
>
>
> what kind of Non-NDIS driver it can be.
>
> [PCAUSA] It will be what is usually called a “legacy NT kernel-mode
> driver”. This is the simplest possible Windows driver. It basically has only
> one required entry point: DriverEntry. In DriverEntry the driver initializes
> it’s DriverObject with various information including the MajorFunction
> table, which is a jump table to the system-defined callbacks for handling
> opens, reads, writes, I/O control and other functions.
>
> * *
>
> Your IM driver will communicate with this legacy driver by opening a
> handle on the legacy driver and then performing open, read, write, I/O
> control, etc.
>
> * *
>
> YOU will have to get some books and study the fundamentals to how to
> write this kind of driver. Unfortunately, I couldn’t see a really trivial
> sample of this sort in the DDK.
>
> * *
>
> As GV, others and I have said there are BIG problems with this design.
>
> * *
>
> Your IM driver will be loaded at startup by the NDIS loader. Your legacy
> driver will be loaded at a different time by the Service Control Manager.
> You will probably have big problems is knowing or controlling which driver
> is loaded first. You will also have big problems in letting each driver know
> when the other is unloaded and can’t be called without causing a crash.
>
> * *
>
> Really a scary design approach that I wouldn’t consider unless there was
> a requirement that couldn’t be satisfied any other way. Let me put this
> another way: It may seem like a good idea to partition functionality this
> way ? but it probably isn’t.
>
> * *
>
> Thomas F. Divine
>
> * *
>
>
>
> Thanks in advance.
>
>
>
> On 6/1/07, Thomas F. Divine wrote:
>
> In your architecture NDIS IM Driver 2 simply cannot ever exist. No
> discussion about this. End of subject!
>
>
>
> A NDIS IM driver MUST bind to one or more lower-level miniport at its
> lower-edge AND must be bound to at least one or more higher-level
> protocol at its upper-edge.
>
>
>
> Driver 2 can be some other type of non-NDIS driver, but it cannot be a
> NDIS IM driver or an NDIS driver of any type.
>
>
>
> Thomas F. Divine
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *shobhit shingla
> *Sent: *Friday, June 01, 2007 12:46 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
>
>
>
> Sorry the attachment is not allowed.
>
>
>
> Here is the module structure
>
>
>
> TCP/IP Protocol Stack
>
> |
>
> | All packets
>
> | UDP
> Packets
>
> NDIS IM Driver 1
> <-----------------------------------> NDIS IM Driver 2
>
> | UDP Packets
> returned
>
> |
>
> |
>
> |
>
> Driver NIC
>
>
>
> I have the following queries regarding this module structure
>
>
>
> 1. How can i bind NDIS IM Driver 1 to both the underlying NIC and to
> NDIS IM Driver 2?
>
>
>
> 2. How will NDIS IM Driver 1 differentiate between packet coming from
> TCP/IP Stack and from NDIS IM Driver 2.?(Do i need to create a separate
> interface for NDIS IM Driver 2).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 5/31/07, Gianluca Varenni < xxxxx@gmail.com > wrote:
>
> Yes, it’s feasible to create two drivers that communicate and pass data
> between each other.
>
>
>
> And as Thomas already said, it’s jst discouraged because
>
> 1. inter-driver communication is complex. The problem is not the data
> flowing between the two drivers, the problem is the infrastracture you need
> to set up in order to guarantee that the one driver acts properly when the
> other one gets loaded/unloaded.
>
> 2. NDIS IM drivers are complicated on their own (they are already quite
> two drivers, a miniport and a protocol driver, bundled within the same
> binary). Add to that the communication with another driver, and you can get
> into trouble.
>
>
>
> Hope it helps
>
> GV
>
>
>
> ----- Original Message -----
>
> From: shobhit shingla
>
> To: Windows System Software Devs Interest List
>
> Sent: Thursday, May 31, 2007 6:02 AM
>
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
> I know that it is difficult but i just want to know that whether it is
> feasible or not.if not can you please explain me the reason for the same.
>
>
>
> Thanks in adnvance
>
>
>
> On 5/31/07, Thomas F. Divine wrote:
>
> Your question is really too vague to be of help.
>
>
>
> In you IM driver you can do anything you want with packets that are sent
> or received. You can examine them, pas them through transparently (as in the
> Passthru sample), or throw them away.
>
>
>
> If your driver can communicate with another driver (a chore in itself…),
> then you can exchange information between your IM driver and another driver.
> One example of information that you could exchange between your IM driver
> and another driver is the information contained within a packet.
>
>
>
> At this point you need to carefully understand what a “NDIS packet” really
> is. See the “NDIS Packet Discussion” at
> http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pwnte.pqdc/http:</http:>
> .
>
>
>
> After you understand what a “NDIS packet” really is, then you will
> probably learn that you can pass the packet information to another driver.
> However, the other driver must understand the structure of a “NDIS packet”
> and also understand who owns the “NDIS packet” and how it must be returned
> to its owner when you no longer have need of it.
>
>
>
> The idea you are thinking of will be difficult to implement. I am sure
> that most of the experienced NDIS developers on this list would avoid this
> architecture at almost any cost.
>
>
>
> Rethink your design approach. Try to follow GV’s advice: Process the
> packets from within your IM driver!
>
>
>
> Thomas F. Divine
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *shobhit shingla
> *Sent: *Thursday, May 31, 2007 12:15 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
> I can but i just want to check whether it is feasible to pass UDP Packets
> to another Driver and then get it back.
>
> On 5/30/07, Gianluca Varenni wrote:
>
> Out of curiosity, why can’t you process the UDP packets from within the
> same IM driver?
>
>
>
> Have a nice day
>
> GV
>
>
>
> ----- Original Message -----
>
> From: shobhit shingla
>
> To: Windows System Software Devs Interest List
>
> Sent: Wednesday, May 30, 2007 6:07 AM
>
> Subject: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
> I am developing an NDIS intermediate driver for my application.
>
> I want my NDIS IM Driver to select UDP Packets from the packets coming
> from TCP/IP Stack and send them to another driver(Any Driver,can be another
> IM Driver) and also send the remaining packets(Non-UDP) to the Driver NIC to
> be sent to the network.
>
> The UDP Packets received by the other driver should then be returned as it
> is to the sending driver.
>
> My question is how can i send packets from one driver to another driver
> and receive them back?
> And
> Is it possible to send some packets to one driver and other to another
> driver.?
>
> Thanks in Advance.
>
> Sunny
>
> — 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.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih//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:
>
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih//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.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih/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.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pxccaazxdv.pvih//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:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:>

OSR_Community_User · June 1, 2007, 11:28am

Discussing requirements is an excellent idea. Can you explain what
you’re trying to accomplish by sending UDP packets to something? Are
you trying to create a packet log or something? Is it *all* UDP
packets that you want to re-direct, or just some, or is it not
specifically UDP packets at all, and that you’re just creating a new
UDP packet for each one you intercept?

And most of all, why do you think you need a separate driver to do
whatever processing you need? Surely this would be easier if you
could process everything in one driver.

I haven’t been paying 100% attention to this thread, so I apologize
if I missed your earlier explanation.

-sd

On Jun 1, 2007, at 2:04 AM, shobhit shingla wrote:

Thanks…

Actually my requirment is to block packets coming from TCP/IP stack
and send UDP Packets to something (which can be another driver,
application etc) and send remaining packets through driver NIC to
the network.

So can i send packets from NDIS IM Driver to another module(which
can be another driver, application etc) and get back these packets
from that module.

Thanks in advance.

On 6/1/07, Thomas F. Divine wrote:
>
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of shobhit
> shingla
> Sent: Friday, June 01, 2007 1:36 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] NDIS IM Driver Questions (WAS: Welcome to the
> NTDEV Discussion List!)
>
>
>
> Hi
>
>
> what kind of Non-NDIS driver it can be.
>
> [PCAUSA] It will be what is usually called a “legacy NT kernel-mode
> driver”. This is the simplest possible Windows driver. It basically
> has only one required entry point: DriverEntry. In DriverEntry the
> driver initializes it’s DriverObject with various information
> including the MajorFunction table, which is a jump table to the
> system-defined callbacks for handling opens, reads, writes, I/O
> control and other functions.
>
>
>
> Your IM driver will communicate with this legacy driver by opening
> a handle on the legacy driver and then performing open, read,
> write, I/O control, etc.
>
>
>
> YOU will have to get some books and study the fundamentals to how
> to write this kind of driver. Unfortunately, I couldn’t see a
> really trivial sample of this sort in the DDK.
>
>
>
> As GV, others and I have said there are BIG problems with this design.
>
>
>
> Your IM driver will be loaded at startup by the NDIS loader. Your
> legacy driver will be loaded at a different time by the Service
> Control Manager. You will probably have big problems is knowing or
> controlling which driver is loaded first. You will also have big
> problems in letting each driver know when the other is unloaded and
> can’t be called without causing a crash.
>
>
>
> Really a scary design approach that I wouldn’t consider unless
> there was a requirement that couldn’t be satisfied any other way.
> Let me put this another way: It may seem like a good idea to
> partition functionality this way ? but it probably isn’t.
>
>
>
> Thomas F. Divine
>
>
>
>
> Thanks in advance.
>
>
>
> On 6/1/07, Thomas F. Divine wrote:
>
> In your architecture NDIS IM Driver 2 simply cannot ever exist. No
> discussion about this. End of subject!
>
>
> A NDIS IM driver MUST bind to one or more lower-level miniport at
> its lower-edge AND must be bound to at least one or more higher-
> level protocol at its upper-edge.
>
>
> Driver 2 can be some other type of non-NDIS driver, but it cannot
> be a NDIS IM driver or an NDIS driver of any type.
>
>
> Thomas F. Divine
>
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of shobhit
> shingla
> Sent: Friday, June 01, 2007 12:46 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
> Sorry the attachment is not allowed.
>
>
> Here is the module structure
>
>
> TCP/IP Protocol Stack
>
> |
>
> | All packets
>
> | UDP
> Packets
>
> NDIS IM Driver 1
> <-----------------------------------> NDIS IM Driver 2
>
> | UDP
> Packets returned
>
> |
>
> |
>
> |
>
> Driver NIC
>
>
> I have the following queries regarding this module structure
>
>
> 1. How can i bind NDIS IM Driver 1 to both the underlying NIC and
> to NDIS IM Driver 2?
>
>
> 2. How will NDIS IM Driver 1 differentiate between packet coming
> from TCP/IP Stack and from NDIS IM Driver 2.?(Do i need to create a
> separate interface for NDIS IM Driver 2).
>
>
>
>
>
>
>
>
>
>
> On 5/31/07, Gianluca Varenni < xxxxx@gmail.com > wrote:
>
> Yes, it’s feasible to create two drivers that communicate and pass
> data between each other.
>
>
> And as Thomas already said, it’s jst discouraged because
>
> 1. inter-driver communication is complex. The problem is not the
> data flowing between the two drivers, the problem is the
> infrastracture you need to set up in order to guarantee that the
> one driver acts properly when the other one gets loaded/unloaded.
>
> 2. NDIS IM drivers are complicated on their own (they are already
> quite two drivers, a miniport and a protocol driver, bundled within
> the same binary). Add to that the communication with another
> driver, and you can get into trouble.
>
>
> Hope it helps
>
> GV
>
>
> ----- Original Message -----
>
> From: shobhit shingla
>
> To: Windows System Software Devs Interest List
>
> Sent: Thursday, May 31, 2007 6:02 AM
>
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
> I know that it is difficult but i just want to know that whether it
> is feasible or not.if not can you please explain me the reason for
> the same.
>
>
> Thanks in adnvance
>
>
>
> On 5/31/07, Thomas F. Divine wrote:
>
> Your question is really too vague to be of help.
>
>
> In you IM driver you can do anything you want with packets that are
> sent or received. You can examine them, pas them through
> transparently (as in the Passthru sample), or throw them away.
>
>
> If your driver can communicate with another driver (a chore in
> itself…), then you can exchange information between your IM driver
> and another driver. One example of information that you could
> exchange between your IM driver and another driver is the
> information contained within a packet.
>
>
> At this point you need to carefully understand what a “NDIS packet”
> really is. See the “NDIS Packet Discussion” at http://
> www.christcollege.edu.ms/servlet/redirect.srv/p5.p1.pbcd.pwnte.pqdc/.
>
>
> After you understand what a “NDIS packet” really is, then you will
> probably learn that you can pass the packet information to another
> driver. However, the other driver must understand the structure of
> a “NDIS packet” and also understand who owns the “NDIS packet” and
> how it must be returned to its owner when you no longer have need
> of it.
>
>
> The idea you are thinking of will be difficult to implement. I am
> sure that most of the experienced NDIS developers on this list
> would avoid this architecture at almost any cost.
>
>
> Rethink your design approach. Try to follow GV’s advice: Process
> the packets from within your IM driver!
>
>
> Thomas F. Divine
>
>
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of shobhit
> shingla
> Sent: Thursday, May 31, 2007 12:15 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
> I can but i just want to check whether it is feasible to pass UDP
> Packets to another Driver and then get it back.
>
> On 5/30/07, Gianluca Varenni wrote:
>
> Out of curiosity, why can’t you process the UDP packets from within
> the same IM driver?
>
>
> Have a nice day
>
> GV
>
>
> ----- Original Message -----
>
> From: shobhit shingla
>
> To: Windows System Software Devs Interest List
>
> Sent: Wednesday, May 30, 2007 6:07 AM
>
> Subject: Re:[ntdev] Welcome to the NTDEV Discussion List!
>
>
>
>
> I am developing an NDIS intermediate driver for my application.
>
> I want my NDIS IM Driver to select UDP Packets from the packets
> coming from TCP/IP Stack and send them to another driver(Any
> Driver,can be another IM Driver) and also send the remaining packets
> (Non-UDP) to the Driver NIC to be sent to the network.
>
> The UDP Packets received by the other driver should then be
> returned as it is to the sending driver.
>
> My question is how can i send packets from one driver to another
> driver and receive them back?
> And
> Is it possible to send some packets to one driver and other to
> another driver.?
>
> 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.christcollege.edu.ms/servlet/redirect.srv/
> p5.p1.pbcd.pxccaazxdv.pvih//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
>
>
> —
> 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.christcollege.edu.ms/servlet/redirect.srv/
> p5.p1.pbcd.pxccaazxdv.pvih//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.christcollege.edu.ms/servlet/redirect.srv/
> p5.p1.pbcd.pxccaazxdv.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
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://
> www.christcollege.edu.ms/servlet/redirect.srv/
> p5.p1.pbcd.pxccaazxdv.pvih//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
>
>
> —
> 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 3, 2007, 2:01am

>

I want to process the UDP packets separately (like change the UDP header
fields etc).

Actually my design idea is to process the UDP packets separately so i
canot process it in the same driver.

The Driver which had to write is “Pseudo Driver” .

I need help regarding the feasibilty of Pseudo driver

I Also want to know what will be the module that will process the UDP
Packets and return them to the driver.(Whether it will be another driver, an
application or something else)

On 6/1/07, Steve Dispensa wrote:
> >
> > Discussing requirements is an excellent idea. Can you explain what
> > you’re trying to accomplish by sending UDP packets to something? Are you
> > trying to create a packet log or something? Is it all UDP packets that you
> > want to re-direct, or just some, or is it not specifically UDP packets at
> > all, and that you’re just creating a new UDP packet for each one you
> > intercept?
> >
> >
> > And most of all, why do you think you need a separate driver to do
> > whatever processing you need? Surely this would be easier if you could
> > process everything in one driver.
> >
> >
> > I haven’t been paying 100% attention to this thread, so I apologize if I
> > missed your earlier explanation.
> >
> >
> > -sd
> >
> >
> >
> > On Jun 1, 2007, at 2:04 AM, shobhit shingla wrote:
> >
> > Thanks…
> >
> > Actually my requirment is to block packets coming from TCP/IP stack and
> > send UDP Packets to something (which can be another driver, application etc)
> > and send remaining packets through driver NIC to the network.
> >
> > So can i send packets from NDIS IM Driver to another module(which can be
> > another driver, application etc) and get back these packets from that
> > module.
> >
> > Thanks in advance.
> >
> >
> >

OSR_Community_User · June 3, 2007, 5:05pm

On Jun 3, 2007, at 1:00 AM, shobhit shingla wrote:

I want to process the UDP packets separately (like change the UDP
header fields etc).

Actually my design idea is to process the UDP packets separately so
i canot process it in the same driver.

The Driver which had to write is “Pseudo Driver” .

I need help regarding the feasibilty of Pseudo driver

I’m not sure I understand what you’re getting at.

I Also want to know what will be the module that will process the
UDP Packets and return them to the driver.(Whether it will be
another driver, an application or something else

You could consider sending the packets to a user-mode application for
processing, which would keep extra code out of the kernel, which is
always good. Performance may be a consideration, though; it just
depends on what you’re trying to do and on the environment you’re
aiming for. You would have to carefully think through the failure
paths in order to not break all networking on the box when the app is
not running.

If the processing is simple and straightforward, you could do it
within the IM driver itself. Almost everyone does it this way.

Based on my limited understanding of what you’re trying to do here, I
don’t think you should have a separate kernel-mode driver to do this.

-sd

OSR_Community_User · June 3, 2007, 11:51pm

I am not sure that I can send Packets from NDIS IM Driver to an user mode application.

How can this be done.

OSR_Community_User · June 4, 2007, 12:00am

On Jun 3, 2007, at 10:52 PM, xxxxx@gmail.com wrote:

I am not sure that I can send Packets from NDIS IM Driver to an
user mode application.

How can this be done.

There are several examples of sending data between kernel-mode and
user-mode in the world. The basic idea from an IM driver is to
register a control device object using NdisMRegisterDevice, and then
to define and use an IOCTL interface between the two. There are a lot
of caveats, though, so it may be better for you to just do your
processing in-driver.

What kind of processing do you have to do?

-Steve

OSR_Community_User · June 4, 2007, 12:21am

I want to change the IP Header fields like Source Address of UDP Packets

On 6/4/07, Steve Dispensa wrote:
>
>
> On Jun 3, 2007, at 10:52 PM, xxxxx@gmail.com wrote:
>
> > I am not sure that I can send Packets from NDIS IM Driver to an
> > user mode application.
> >
> > How can this be done.
>
> There are several examples of sending data between kernel-mode and
> user-mode in the world. The basic idea from an IM driver is to
> register a control device object using NdisMRegisterDevice, and then
> to define and use an IOCTL interface between the two. There are a lot
> of caveats, though, so it may be better for you to just do your
> processing in-driver.
>
> What kind of processing do you have to do?
>
> -Steve
>
>
>
>
> —
> 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 4, 2007, 12:42am

I’d probably stick to in-driver logic, then.

Note that there are a lot of intricacies here; it sounds like you’re
doing some sort of a NAT. You should refer to other open-source NAT
implementations to make sure you don’t introduce security problems in
the process.

-Steve

On Jun 3, 2007, at 11:20 PM, shobhit shingla wrote:

I want to change the IP Header fields like Source Address of UDP
Packets

On 6/4/07, Steve Dispensa wrote:
> On Jun 3, 2007, at 10:52 PM, xxxxx@gmail.com wrote:
>
> > I am not sure that I can send Packets from NDIS IM Driver to an
> > user mode application.
> >
> > How can this be done.
>
> There are several examples of sending data between kernel-mode and
> user-mode in the world. The basic idea from an IM driver is to
> register a control device object using NdisMRegisterDevice, and then
> to define and use an IOCTL interface between the two. There are a lot
> of caveats, though, so it may be better for you to just do your
> processing in-driver.
>
> What kind of processing do you have to do?
>
> -Steve
>
>
>
>
> —
> 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 4, 2007, 3:21am

I want to know how to send packet from NDIS IM Driver to a user mode
application.

We can write from user mode application to NDIS IM Driver using
CreateFile,ReadFile and WriteFile functions but how can we write a packet
from NDIS IM Driver to an application.

On 6/4/07, Steve Dispensa wrote:
>
> I’d probably stick to in-driver logic, then.
>
> Note that there are a lot of intricacies here; it sounds like you’re
> doing some sort of a NAT. You should refer to other open-source NAT
> implementations to make sure you don’t introduce security problems in
> the process.
>
> -Steve
>
> On Jun 3, 2007, at 11:20 PM, shobhit shingla wrote:
>
> > I want to change the IP Header fields like Source Address of UDP
> > Packets
> >
> > On 6/4/07, Steve Dispensa wrote:
> > On Jun 3, 2007, at 10:52 PM, xxxxx@gmail.com wrote:
> >
> > > I am not sure that I can send Packets from NDIS IM Driver to an
> > > user mode application.
> > >
> > > How can this be done.
> >
> > There are several examples of sending data between kernel-mode and
> > user-mode in the world. The basic idea from an IM driver is to
> > register a control device object using NdisMRegisterDevice, and then
> > to define and use an IOCTL interface between the two. There are a lot
> > of caveats, though, so it may be better for you to just do your
> > processing in-driver.
> >
> > What kind of processing do you have to do?
> >
> > -Steve
> >
> >
> >
> >
> > —
> > 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
>
>
> —
> 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 4, 2007, 4:00am

Search the archives for “inverted call”. The basic idea is that you
park your read IRP (or whatever) in a CSQ until you have data.

There are a couple of tricky races in there. Be careful.

-Steve

On Jun 4, 2007, at 2:20 AM, shobhit shingla wrote:

I want to know how to send packet from NDIS IM Driver to a user
mode application.

We can write from user mode application to NDIS IM Driver using
CreateFile,ReadFile and WriteFile functions but how can we write a
packet from NDIS IM Driver to an application.

On 6/4/07, Steve Dispensa wrote:
> I’d probably stick to in-driver logic, then.
>
> Note that there are a lot of intricacies here; it sounds like you’re
> doing some sort of a NAT. You should refer to other open-source NAT
> implementations to make sure you don’t introduce security problems in
> the process.
>
> -Steve
>
> On Jun 3, 2007, at 11:20 PM, shobhit shingla wrote:
>
> > I want to change the IP Header fields like Source Address of UDP
> > Packets
> >
> > On 6/4/07, Steve Dispensa wrote:
> > On Jun 3, 2007, at 10:52 PM, xxxxx@gmail.com wrote:
> >
> > > I am not sure that I can send Packets from NDIS IM Driver to an
> > > user mode application.
> > >
> > > How can this be done.
> >
> > There are several examples of sending data between kernel-mode and
> > user-mode in the world. The basic idea from an IM driver is to
> > register a control device object using NdisMRegisterDevice, and then
> > to define and use an IOCTL interface between the two. There are a
> lot
> > of caveats, though, so it may be better for you to just do your
> > processing in-driver.
> >
> > What kind of processing do you have to do?
> >
> > -Steve
> >
> >
> >
> >
> > —
> > 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
>
>
> —
> 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