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
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 Puri...@discussions.microsoft.com> wrote in
message news:6E4288FC-26CF-40E7...@microsoft.com...
> 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
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
ma...@storagecraft.com
http://www.storagecraft.com
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.
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
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.
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
"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:eHAGv95w...@TK2MSFTNGP15.phx.gbl...