NDIS IM driver usermode app communication

Hi,
I know that we can make use of DeviceIoControl(...) to the usermode
app -- driver communication. I am yet to read James's wmi mechanism also.

Thing is I want to send the bits and bytes (the one that comes into the send
routine) back to a user mode app.
I don't think using DeviceIOControl is a good way to acheive this because of
the increased buffering being involved. I thought of logging to file and
then have the usermode app read from it, but that approach would be ugly.

Is there a better, easier and cleaner way to do the communication from
kernel mode to user mode?

Thanks
Vipin

"Vipin" <> wrote in message
news:%...
> Hi,
> I know that we can make use of DeviceIoControl(...) to the usermode
> app -- driver communication. I am yet to read James's wmi mechanism also.
>
> Thing is I want to send the bits and bytes (the one that comes into the
> send
> routine) back to a user mode app.
> I don't think using DeviceIOControl is a good way to acheive this because
> of
> the increased buffering being involved. I thought of logging to file and
> then have the usermode app read from it, but that approach would be ugly.
>
> Is there a better, easier and cleaner way to do the communication from
> kernel mode to user mode?
>
No, Read or IOCTL is the best way to pass the bytes to user-mode.

If you are monitoring packets, pass a large buffer to the driver and have
the driver fill the buffer with multiple packets. Of course, some sort of
structure will be needed to "package" each received packet.

Examine the use of direct I/O. Using this method the buffer exchanged
between the driver and the application is not copied an extra time. However,
the driver must do a little extra work to get a kernel-mode pointer to the
user-allocated buffer. See MmGetSystemAddressForMdlSafe and friends. There
are always security issues when using method direct, so you should
incorporate schemes to validate the buffer passed to the driver if you go
this route. The DevCon 2003 conference proceeding has a few good talks about
security issues; I believe they can be found online.

If you must handle each packet one-at-a-time, then the kernel-mode/user-mode
latency will certainly cause performance issues at high packet rates. There
is an old article Rawether.Net that talks about this a little. See:

http://www.rawether.net/support/KB06300101.htm

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com



> Thanks
> Vipin
>
>

ok, thanks for the info.
Vipin

"Thomas F. Divine [DDK MVP]" <> wrote in message
news:...
>
> "Vipin" <> wrote in message
> news:%...
>> Hi,
>> I know that we can make use of DeviceIoControl(...) to the usermode
>> app -- driver communication. I am yet to read James's wmi mechanism also.
>>
>> Thing is I want to send the bits and bytes (the one that comes into the
>> send
>> routine) back to a user mode app.
>> I don't think using DeviceIOControl is a good way to acheive this because
>> of
>> the increased buffering being involved. I thought of logging to file and
>> then have the usermode app read from it, but that approach would be ugly.
>>
>> Is there a better, easier and cleaner way to do the communication from
>> kernel mode to user mode?
>>
> No, Read or IOCTL is the best way to pass the bytes to user-mode.
>
> If you are monitoring packets, pass a large buffer to the driver and have
> the driver fill the buffer with multiple packets. Of course, some sort of
> structure will be needed to "package" each received packet.
>
> Examine the use of direct I/O. Using this method the buffer exchanged
> between the driver and the application is not copied an extra time.
> However, the driver must do a little extra work to get a kernel-mode
> pointer to the user-allocated buffer. See MmGetSystemAddressForMdlSafe and
> friends. There are always security issues when using method direct, so you
> should incorporate schemes to validate the buffer passed to the driver if
> you go this route. The DevCon 2003 conference proceeding has a few good
> talks about security issues; I believe they can be found online.
>
> If you must handle each packet one-at-a-time, then the
> kernel-mode/user-mode latency will certainly cause performance issues at
> high packet rates. There is an old article Rawether.Net that talks about
> this a little. See:
>
> http://www.rawether.net/support/KB06300101.htm
>
> Good luck,
>
> Thomas F. Divine, Windows DDK MVP
> http://www.pcausa.com
>
>
>
>> Thanks
>> Vipin
>>
>>
>