in reply to OID Power Status Query

The following info from a google groups discussion may be relevent:
The DDK wording is not straightforward enough. It should say:

"The OID_PNP_QUERY_POWER OID requests the miniport driver to indicate whether it can transition its NIC to the low- power state specified in the NDIS_DEVICE_POWER_STATE value pointed by InformationBuffer." instead of "low-power state specified in the InformationBuffer". One time I interpreted it as:

PowerState = (NDIS_DEVICE_POWER_STATE) InformationBuffer;

In addition, in responding to a previous discussion on wmi, it bothered me that a some external code was run and interpreted in order to get NIC info, so I came up with this: (You need to install DBD::WMI:
use DBI; use strict; my $dbh = DBI->connect('dbi:WMI:'); # You need to install DBD::WM +I my $sth = $dbh->prepare(<<WQL ); SELECT * from Win32_NetworkAdapterConfiguration WHERE IPEnabled = True WQL my @atts = qw[caption DefaultIPGateway Description ServiceName Index + IPAddress MACAddress ]; # $sth->execute(); while (my @row = $sth->fetchrow) { my $item= $row[0]; for (@atts){ if (ref $item->{$_} eq "ARRAY"){ print "$_\t=". join (",", @{$item->{$_}}) . ";\n"; }else{ print "$_\t=". $item->{$_} . ";\n"; } } print "\n"; }
This probably needs some tweaking to get the info you require. MS document is at http://msdn2.microsoft.com/en-us/library/aa394217.aspx .

Update: One more point : I read somewhere in the MSDN site (Can't find the URL now) that using the WIN32 API to get NDIS info is deprecated. It recommended using WMI.

     "As you get older three things happen. The first is your memory goes, and I can't remember the other two... " - Sir Norman Wisdom

Replies are listed 'Best First'.
Re^2: OID Power Status Query
by cmv (Chaplain) on Oct 03, 2007 at 20:05 UTC
    Wow, great reply NetWallah! I've been chewing through information links since last night. The google group pointer was interesting reading, but I wasn't able to apply anything they said to get things working (there was a lot I didn't understand though).

    On the plus side, I was able to track down some stuff yesterday afternoon. After my original posting, I was thinking that the hardcoded use of IOCTL_NDIS_QUERY_GLOBAL_STATS may be the problem. I ran across some other possibilities that could be used, here:

    // // NtDeviceIoControlFile IoControlCode values for this device. // // Warning: Remember that the low two bits of the code specify how the // buffers are passed to the driver! // #define _NDIS_CONTROL_CODE(request,method) \ CTL_CODE(FILE_DEVICE_PHYSICAL_NETCARD, request, method, FI +LE_ANY_ACCESS) #define IOCTL_NDIS_QUERY_GLOBAL_STATS _NDIS_CONTROL_CODE(0, METHOD_O +UT_DIRECT) #define IOCTL_NDIS_QUERY_ALL_STATS _NDIS_CONTROL_CODE(1, METHOD_O +UT_DIRECT) #define IOCTL_NDIS_DO_PNP_OPERATION _NDIS_CONTROL_CODE(2, METHOD_B +UFFERED) #define IOCTL_NDIS_QUERY_SELECTED_STATS _NDIS_CONTROL_CODE(3, METHOD_O +UT_DIRECT) #define IOCTL_NDIS_ENUMERATE_INTERFACES _NDIS_CONTROL_CODE(4, METHOD_B +UFFERED) #define IOCTL_NDIS_ADD_TDI_DEVICE _NDIS_CONTROL_CODE(5, METHOD_B +UFFERED) #define IOCTL_NDIS_GET_LOG_DATA _NDIS_CONTROL_CODE(7, METHOD_O +UT_DIRECT) #define IOCTL_NDIS_GET_VERSION _NDIS_CONTROL_CODE(8, METHOD_O +UT_DIRECT)
    I couldn't make much sense of the CTL_CODE macro, but found documentation on it here, and found a freeBSD implementation of it at this link:
    #define CTL_CODE(devType, func, meth, acc) (((devType) << 16) | ((acc) + << 14) | ((func) << 2) | (meth))
    Using any of these didn't help me any towards a solution (although you may have to deal with the METHOD_BUFFERED differently), and that's as far as I've gotten so far.

    Also, thanks for the DBD::WMI code! Alas, I'm constrained to only using modules distributed via activestate, and this isn't one of them. I actually asked for some help on solving this issue last November, but got nowhere.

    Any other thoughts, or pointers are welcome!

    -Craig