IOCTL + XP SP2

In year 2000 I developed a simple Virtual Network Driver in order to exchange
messages from/to Microsoft IP to/from my user-space application that
performs my
proprietary data-link protocol (on both serial ports and modems).

IP exchanges messages with my NIC in the standard way and my application
puts/gets messages into/from my NIC through DeviceIoControl() function.

I use the same IOCTL method with 2 different NDIS_OIDs to put messages into
the
NIC and to get messages from the NIC.

#define IOCTL_NDIS_QUERY_GLOBAL_STATS \
_NDIS_CONTROL_CODE(0, METHOD_OUT_DIRECT)

The NIC was developed for Windows NT 4 (conforming to NDIS 4.0 miniport
interface specifications) and it works also on Windows 2000 and on Windows XP.

Now with Windows XP Service Pack 2 my application can correctly put into my
NIC
messages smaller than or equal to 278 bytes; when the application puts into
my
NIC messages larger than 278 bytes the messages that IP receives from NIC
contain "dirty" information.

What is the reason of this behaviour ?
Maybe is it due to some kind of buffer overrun protection in Windows kernel
message ?

Thank you
Paolo Puricelli

Thomas
Fri Nov 05 09:20:57 CST 2004

Unfortunately, IOCTL_NDIS_QUERY_GLOBAL_STATS has always been defined to be a
query-only (read-only) interface. At least for many years developers have
been able to use the this simple API to perform some NIC management.

The behavior of IOCTL_NDIS_QUERY_GLOBAL_STATS certainly did change with XP
SP2. The changes are almost certainly related to security. In fact, I
suspect that they would like make the API dispappear altogether. I didn't
see the problem that you reported. However, I did see that on XP SP2 they
apparently make some strict buffer alignment tests on the input buffer
before they even attempt to handle the OID. The bug that I saw was that they
tested for 64-bit alignment even if the query was for a 32-bit value.

You might want to make the transition to using WMI or a companion NDIS
protocol driver to facilitate communication beteween your application and
your virtual NIC.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.rawether.net


"Paolo Puricelli" <Paolo Puricelli@discussions.microsoft.com> wrote in
message news:6E4288FC-26CF-40E7-B4D2-913F09FB4D6C@microsoft.com...
> In year 2000 I developed a simple Virtual Network Driver in order to
> exchange
> messages from/to Microsoft IP to/from my user-space application that
> performs my
> proprietary data-link protocol (on both serial ports and modems).
>
> IP exchanges messages with my NIC in the standard way and my application
> puts/gets messages into/from my NIC through DeviceIoControl() function.
>
> I use the same IOCTL method with 2 different NDIS_OIDs to put messages
> into
> the
> NIC and to get messages from the NIC.
>
> #define IOCTL_NDIS_QUERY_GLOBAL_STATS \
> _NDIS_CONTROL_CODE(0, METHOD_OUT_DIRECT)
>
> The NIC was developed for Windows NT 4 (conforming to NDIS 4.0 miniport
> interface specifications) and it works also on Windows 2000 and on Windows
> XP.
>
> Now with Windows XP Service Pack 2 my application can correctly put into
> my
> NIC
> messages smaller than or equal to 278 bytes; when the application puts
> into
> my
> NIC messages larger than 278 bytes the messages that IP receives from NIC
> contain "dirty" information.
>
> What is the reason of this behaviour ?
> Maybe is it due to some kind of buffer overrun protection in Windows
> kernel
> message ?
>
> Thank you
> Paolo Puricelli
>

Calvin
Fri Nov 05 10:02:21 CST 2004

"Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message
news:eXS7Qs0wEHA.1000@TK2MSFTNGP10.phx.gbl...

> You might want to make the transition to using WMI or a companion NDIS
> protocol driver to facilitate communication beteween your application and
> your virtual NIC.

I would strongly suggest using WMI for this purpose. The neat things of WMI:
1) easy to implement in miniport drivers
2) Able to write user mode code in scripting language, all you need is a
text editor, no compiling.
3) Use existing WMI utilities to communicate with the driver, no coding
needed. I like WMIC the best, wbemtest is ok.

4) remote access from other computers

As for NDIS wmi/oid implementation, the limitation I saw is lack of support
for multiple instances, eventing and WMI method.

--
Calvin Guan Software Engineer/Radeon NT Drivers
ATI Technologies Inc. Markham ON, Canada
www.ati.com

Maxim
Fri Nov 05 19:25:11 CST 2004

> You might want to make the transition to using WMI or a companion NDIS
> protocol driver to facilitate communication beteween your application and

Too bad that MS does not provide NDISUIO as a standard documented part of
Windows, like they do for Windows CE.

Requiring the developers to clone the NDISPROT (former NDISUIO) source and
include it to their products are not looking good. Each such product will at
least have installation headaches for this protocol.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Fri Nov 05 19:41:08 CST 2004

> As for NDIS wmi/oid implementation, the limitation I saw is lack of support
> for multiple instances, eventing and WMI method.

Am I wrong that NDIS can convert some NdisMIndicateStatus calls to WMI events?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Calvin
Fri Nov 05 21:03:47 CST 2004

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:u5pSpG6wEHA.2624@TK2MSFTNGP11.phx.gbl...
> Am I wrong that NDIS can convert some NdisMIndicateStatus calls to WMI
events?

Yes, you're right.

NdisMIndicateStatus will fire WMI events pre-defined by ndis.sys. As an
example, indicating NDIS_STATUS_MEDIA_CONNECT will trigger ndis.sys to fire
a MSNdis_StatusMediaConnect event defined as:

[WMI, dynamic: ToInstance, provider("WMIProv"),
guid("{981f2d7d-b1f3-11d0-8dd7-00c04fc3358c}"), locale("MS\\0x409"),
WmiExpense(1), Description("NDIS Status Media Connect")]
class MSNdis_StatusMediaConnect : WMIEvent
{
[key, read] string InstanceName;
[read] boolean Active;
};

You may use the following VBscript to listen to the event.

' Script name: ndis.vbs
' (c) Calvin Guan
' Purpose:
' Demonstrate how to listen to a WMI event provided by kernel mode driver.
'
' Launch the script:
'
' Console mode: (command line)
' c:\>cscript.exe c:\cguan\nt\filterdrivers\wdm\bfport\sbin\ndis.vbs
' GUI Mode:
' double-click the ndis.vbs in explorer.

Set
objWMIServices=GetObject("winmgmts:{impersonationLevel=impersonate}!root/wmi
")

set objSink = WScript.CreateObject("WbemScripting.SWbemSink","SINK_")

objWMIServices.ExecNotificationQueryasync objSink, "Select * from
MSNdis_StatusMediaConnect"

WScript.Echo "Listening to Media_connect Events..." & vbCrLf

While(1)
WScript.Sleep 1000
Wend

Sub SINK_OnObjectReady(wmiObject, wmiAsyncContext)
WScript.Echo "Received media connect Event" & vbCrLf & _
wmiObject.GetObjectText_()
End Sub
'End of script - ndis.vbs

In NDIS, I'm not able to fire my custom events simply because I'm not
allowed to call IoWMIWriteEvent in a miniport if I need to WHQL my driver-:(
The other uncertainty is how ndis treat my own events when it handles
IRP_MN_ENABLE/DISABLE_EVENTS.

--
Calvin Guan Software Engineer/Radeon NT Drivers
ATI Technologies Inc. Markham ON, Canada
www.ati.com

Pavel
Sat Nov 06 12:59:02 CST 2004

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message news:eHAGv95wEHA.2012@TK2MSFTNGP15.phx.gbl...
> Too bad that MS does not provide NDISUIO as a standard documented part of
> Windows, like they do for Windows CE.

Hmm. This opinion can be formulated as "MS should open to everybody and his
brother a wide access to easy tampering with all network adapters, since
they are going to do this anyway."
The solution for CE is not nesessary good for "big" Windows.

Regards,
--PA

Maxim
Sun Nov 07 15:05:10 CST 2004

> Hmm. This opinion can be formulated as "MS should open to everybody and his
> brother a wide access to easy tampering with all network adapters, since
> they are going to do this anyway."

Exactly so, and I think that this statement is valid. Surely this must be
restricted to admins, but the feature must exist, just like AF_PACKET exists in
UNIXen.

Security by obscurity just do not work.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

PaoloPuricelli
Mon Nov 08 07:55:03 CST 2004

"Thomas F. Divine [DDK MVP]" wrote:
> However, I did see that on XP SP2 they
> apparently make some strict buffer alignment tests on the input buffer
> before they even attempt to handle the OID. The bug that I saw was that they
> tested for 64-bit alignment even if the query was for a 32-bit value.
> Thomas F. Divine, Windows DDK MVP
> http://www.rawether.net

I want to thank you for the very quick and precise response and I want to
confirm
that I solved my problem alligning to 64-bit values the messages that my
application send to my network driver.

Thank for the precious help
Paolo Puircelli

Nam
Wed Nov 10 03:22:03 CST 2004

Dear Maxim!
I know that I can get NDISPROT in examples of Windows Server 2003 DDK. But I
don't have that DDK so could you send me a copy of NDISPROT?
Thank in advance!
Nam.
PS: if you can, please send it to me directly by mail. (namdt@gmx.net).

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eHAGv95wEHA.2012@TK2MSFTNGP15.phx.gbl...
>> You might want to make the transition to using WMI or a companion NDIS
>> protocol driver to facilitate communication beteween your application and
>
> Too bad that MS does not provide NDISUIO as a standard documented part of
> Windows, like they do for Windows CE.
>
> Requiring the developers to clone the NDISPROT (former NDISUIO) source and
> include it to their products are not looking good. Each such product will
> at
> least have installation headaches for this protocol.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>