Hi,
I am new to Windows driver writing. I am writing NDIS IM driver and have taken NDIS Pass Thru Sample of DDK as the starting point. Here is what I am looking to do with IM driver-
? I need to capture all the incoming and outgoing packets.
? I need to modify the payload of the packets.
I am able to capture the packets in the IM driver and able to modify them also. But I am able to do the packet modification in driver level only.
So I need the help in following queries-
-
I want to do the modification of the incoming and outgoing packets in user mode application. So I want to provide the packets to user mode application via IM driver. Please suggest the best possible way to do this.
-
For some packets it is possible that the user mode application can take around 3 seconds to do the packet modification though it will happen rarely but the chances are there. Otherwise the average time for the packets which are eligible for the modification would be around 200 milli second. So the question is whether it is possible to put on hold the IM driver for that long time and how because as per my understanding TCP/IP may retransmit the packet.
Thanks!
Deepak
>1. I want to do the modification of the incoming and outgoing packets in user >mode application. So I want to provide the packets to user mode application >via IM driver. Please suggest the best possible way to do this.
Do you mean modify packets and return back to IM driver? If so,it is not good idea. IM driver is very critical components and any significant delay in IM driver affect performances of others network components.
- For some packets it is possible that the user mode application can take >around 3 seconds to do the packet modification though it will happen rarely >but the chances are there. Otherwise the average time for the packets >which are eligible for the modification would be around 200 milli second. So >the question is whether it is possible to put on hold the IM driver for that >long time and how because as per my understanding TCP/IP may >retransmit the packet.
Windows OS is a preemptive OS and you could not force Windows always to do processing packets in application level for 200 millisecond and no more.
For such scenario you need to choose a real-time system.
Igor Sharovar
I’m afraid Igor is right. Since user mode application works always in
PASSIVE level, they have lower priority than any other process in the
kernel, more over the interrupt form the NIC generates a IRQ more or equal
to dispatch level which tends to be served first.
its better that the packet is modified at the IM level with policies/filters
applied from the user level via ioctl calls.
whatever you do, DO NOT modify the packets at user level. this may even lead
to packet flooding and IM Driver to get a hang.
2009/10/5
> >1. I want to do the modification of the incoming and outgoing packets in
> user >mode application. So I want to provide the packets to user mode
> application >via IM driver. Please suggest the best possible way to do this.
>
> Do you mean modify packets and return back to IM driver? If so,it is not
> good idea. IM driver is very critical components and any significant delay
> in IM driver affect performances of others network components.
>
> >2. For some packets it is possible that the user mode application can take
> >around 3 seconds to do the packet modification though it will happen rarely
> >but the chances are there. Otherwise the average time for the packets
> >which are eligible for the modification would be around 200 milli second.
> So >the question is whether it is possible to put on hold the IM driver for
> that >long time and how because as per my understanding TCP/IP may
> >retransmit the packet.
> Windows OS is a preemptive OS and you could not force Windows always to do
> processing packets in application level for 200 millisecond and no more.
> For such scenario you need to choose a real-time system.
>
>
> Igor Sharovar
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
–
When you can’t fly Try to Run
When you cant’t run Try to Walk
When you can’t walk Try to Crawl
But whatever you do Keep moving"
– Martin Luther
Angad!
Mobile:+91- 9741308545
Igor’s advice is not universally correct - although it certainly applies to
servers.
For example, if the packets being filtered are known to always be on a
low-bandwidth network ( e.g., 10Mbps or less) on a workstation then passing
all packets to user mode and then back to the kernel will have hardly any
noticeable effect on network performance or CPU utilization. Just have the
application read and write packets individually using techniques similar to
those illustrated in the NDISPROT sample.
On a higher bandwidth network - in particular in a server environment -
passing packets back and forth to user-mode will cause a noticeable
performance degradation.
Holding delaying a packet for 3 seconds may or may not be a problem
depending on what the packet is…
Good luck,
Thomas F. Divine
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anand
Sent: Monday, October 05, 2009 8:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS Queries
I’m afraid Igor is right. Since user mode application works always in
PASSIVE level, they have lower priority than any other process in the
kernel, more over the interrupt form the NIC generates a IRQ more or equal
to dispatch level which tends to be served first.
its better that the packet is modified at the IM level with policies/filters
applied from the user level via ioctl calls.
whatever you do, DO NOT modify the packets at user level. this may even lead
to packet flooding and IM Driver to get a hang.
2009/10/5
>1. I want to do the modification of the incoming and outgoing packets in
user >mode application. So I want to provide the packets to user mode
application >via IM driver. Please suggest the best possible way to do this.
Do you mean modify packets and return back to IM driver? If so,it is not
good idea. IM driver is very critical components and any significant delay
in IM driver affect performances of others network components.
>2. For some packets it is possible that the user mode application can take
>around 3 seconds to do the packet modification though it will happen rarely
>but the chances are there. Otherwise the average time for the packets
>which are eligible for the modification would be around 200 milli second.
So >the question is whether it is possible to put on hold the IM driver for
that >long time and how because as per my understanding TCP/IP may
>retransmit the packet.
Windows OS is a preemptive OS and you could not force Windows always to do
processing packets in application level for 200 millisecond and no more.
For such scenario you need to choose a real-time system.
Igor Sharovar
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
–
When you can’t fly Try to Run
When you cant’t run Try to Walk
When you can’t walk Try to Crawl
But whatever you do Keep moving"
– Martin Luther
Angad!
Mobile:+91- 9741308545
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>For example, if the packets being filtered are known to always be on a >low-bandwidth network ( e.g., 10Mbps or less) on a workstation then passing >all packets to user mode and then back to the kernel will have hardly any >noticeable effect on network performance or CPU utilization.
The question is why such design is needed? I don’t think OP is going to use such design only in 10Mbps network.
I wonder, why does OP need to process packets in application level instead of doing it in kernel? Are there any special circumstances?
Igor Sharovar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, October 05, 2009 9:03 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS Queries
For example, if the packets being filtered are known to always be on a
low-bandwidth network ( e.g., 10Mbps or less) on a workstation then passing
all packets to user mode and then back to the kernel will have hardly any
noticeable effect on network performance or CPU utilization.
The question is why such design is needed? I don’t think OP is going to use
such design only in 10Mbps network.
[PCAUSA] We don’t know what the intended use is. However, it may be entirely
appropriate in some cases.
I wonder, why does OP need to process packets in application level instead
of doing it in kernel? Are there any special circumstances?
[PCAUSA] Why is there UMDF?
If the bandwidth is appropriate (e.g., satellite link bandwidth
accelerator/limiter) then perhaps the driver is simpler and more robust.
Point is: There is no single answer to the OP’s question. Once again the OP
should give more info instead of suggesting a solution to an unknown
problem.
Thomas F. Divine
Igor Sharovar
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>my understanding TCP/IP may retransmit the packet.
It will retransmit the packet. You’re doomed.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks a lot for the answers.
Below is some more details of what I am looking for. I need to do two things-
-
To redirect the URLs based upon their categories: For the categorization of the URL I am dependent on another application which runs in user mode. This application interacts with the server and provides the category of the URL. Based upon the category returned by that application, NDIS IM need to allow/redirect the URL. So for that I have to provide the URL from NDIS IM to user mode application.
-
To modify the chat content of chat applications: In instant messaging, I need to block the whole chat application or to modify some content being sent and received. So I was implementing that logic in user mode application once NDIS IM gives the packet to it.
Please suggest if there is another easy and efficient way to fulfill the above requirements.
Thanks!
Deepak
Why NDIS IM? Why not WFP filter? Why not layered WinSock provider?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Thanks a lot for the answers.
>
> Below is some more details of what I am looking for. I need to do two things-
>
> 1. To redirect the URLs based upon their categories: For the categorization of the URL I am dependent on another application which runs in user mode. This application interacts with the server and provides the category of the URL. Based upon the category returned by that application, NDIS IM need to allow/redirect the URL. So for that I have to provide the URL from NDIS IM to user mode application.
>
> 2. To modify the chat content of chat applications: In instant messaging, I need to block the whole chat application or to modify some content being sent and received. So I was implementing that logic in user mode application once NDIS IM gives the packet to it.
>
> Please suggest if there is another easy and efficient way to fulfill the above requirements.
>
> Thanks!
> Deepak
>
>
You need to move filtering in some layers up in network stack as Maxim suggests. Doing such things in NDIS level is not very efficient in your design.
What kind of version of Windows are you using?
Igor Sharovar
You might be needing a user mode proxy running which can redirect the url,
if the filtering is done and decided on a runtime basis(content
filtering).neither
a predefined rules for may work at the ndis level which can mangle the
packet.
mind you, you cannot possibly modify the original packet, you have to work
on the copy of the packet and send complete for the original one.
it would be a highly in-efficient design if you’re seriously thinking of
packet mangling at the user level.
why don’t you move over most of the decision making code at the lower level?
you can very well indicate the status at the user level.
2009/10/6
> You need to move filtering in some layers up in network stack as Maxim
> suggests. Doing such things in NDIS level is not very efficient in your
> design.
> What kind of version of Windows are you using?
>
> Igor Sharovar
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
–
When you can’t fly Try to Run
When you cant’t run Try to Walk
When you can’t walk Try to Crawl
But whatever you do Keep moving"
– Martin Luther
Angad!
Mobile:+91- 9741308545