From: Peter on
Hi!

Is this IOCTL still supported on NDIS 6.x platforms? In particular, can I
still use this IOCTL on these platforms to plumb proprietary OIDs (i.e., OID
value >= 0xFF000000) to a driver? I've heard the this IOCTL was in the
process of being deprecated, and it seems that we have problems with it and
proprietary OIDs on NDIS 6.x.

Thanks!


From: Volodymyr M. Shcherbyna on
Well, it works OK for me (I get the OID_802_3_CURRENT_ADDRESS). What error
do you get? Can you publish your code here?

--
Volodymyr, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)

"Peter" <ImInSoquel(a)nospam.nospam> wrote in message
news:e3mpWpR5IHA.4848(a)TK2MSFTNGP02.phx.gbl...
> Hi!
>
> Is this IOCTL still supported on NDIS 6.x platforms? In particular, can I
> still use this IOCTL on these platforms to plumb proprietary OIDs (i.e.,
> OID value >= 0xFF000000) to a driver? I've heard the this IOCTL was in the
> process of being deprecated, and it seems that we have problems with it
> and proprietary OIDs on NDIS 6.x.
>
> Thanks!
>


From: Peter on
There's no code yet. Also, this question had more to do with plumbing
proprietary OIDs to a driver over this IOCTL.

This is all driven by the Server 2003 SP2 DDK, which says this about this
IOCTL:

"This IOCTL will be deprecated in later operating system releases. You
should use WMI interfaces to query miniport driver information."

My guess is that if this still works on NDIS 6.x platforms, it may be due to
NDIS servicing the IOCTL and returning OID data from cached information it
has from queries it made itself of underlying miniports. NDIS is servicing a
lot of OID queries in NDIS 6.x, such as OID_802_3_CURRENT_ADDRESS, since it
gets a lot of this data during the miniport's registration during
MiniportInitilaizeEx.

My guess is that proprietary OIDs are not serviced through this IOCTL,
however. Does anyone know if this is true?


"Volodymyr M. Shcherbyna" <v_scherbina(a)online.mvps.org> wrote in message
news:e4BXnVZ5IHA.784(a)TK2MSFTNGP04.phx.gbl...
> Well, it works OK for me (I get the OID_802_3_CURRENT_ADDRESS). What error
> do you get? Can you publish your code here?
>
> --
> Volodymyr, blog: http://www.shcherbyna.com/
> (This posting is provided "AS IS" with no warranties, and confers no
> rights)
>
> "Peter" <ImInSoquel(a)nospam.nospam> wrote in message
> news:e3mpWpR5IHA.4848(a)TK2MSFTNGP02.phx.gbl...
>> Hi!
>>
>> Is this IOCTL still supported on NDIS 6.x platforms? In particular, can I
>> still use this IOCTL on these platforms to plumb proprietary OIDs (i.e.,
>> OID value >= 0xFF000000) to a driver? I've heard the this IOCTL was in
>> the process of being deprecated, and it seems that we have problems with
>> it and proprietary OIDs on NDIS 6.x.
>>
>> Thanks!
>>
>
>


From: Alireza Dabagh [MS] on
Make sure the private OID you are after is reported in supported OID list by
the underlying miniport driver.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Peter" <ImInSoquel(a)nospam.nospam> wrote in message
news:%23SQRq8o5IHA.1176(a)TK2MSFTNGP02.phx.gbl...
> There's no code yet. Also, this question had more to do with plumbing
> proprietary OIDs to a driver over this IOCTL.
>
> This is all driven by the Server 2003 SP2 DDK, which says this about this
> IOCTL:
>
> "This IOCTL will be deprecated in later operating system releases. You
> should use WMI interfaces to query miniport driver information."
>
> My guess is that if this still works on NDIS 6.x platforms, it may be due
> to NDIS servicing the IOCTL and returning OID data from cached information
> it has from queries it made itself of underlying miniports. NDIS is
> servicing a lot of OID queries in NDIS 6.x, such as
> OID_802_3_CURRENT_ADDRESS, since it gets a lot of this data during the
> miniport's registration during MiniportInitilaizeEx.
>
> My guess is that proprietary OIDs are not serviced through this IOCTL,
> however. Does anyone know if this is true?
>
>
> "Volodymyr M. Shcherbyna" <v_scherbina(a)online.mvps.org> wrote in message
> news:e4BXnVZ5IHA.784(a)TK2MSFTNGP04.phx.gbl...
>> Well, it works OK for me (I get the OID_802_3_CURRENT_ADDRESS). What
>> error do you get? Can you publish your code here?
>>
>> --
>> Volodymyr, blog: http://www.shcherbyna.com/
>> (This posting is provided "AS IS" with no warranties, and confers no
>> rights)
>>
>> "Peter" <ImInSoquel(a)nospam.nospam> wrote in message
>> news:e3mpWpR5IHA.4848(a)TK2MSFTNGP02.phx.gbl...
>>> Hi!
>>>
>>> Is this IOCTL still supported on NDIS 6.x platforms? In particular, can
>>> I still use this IOCTL on these platforms to plumb proprietary OIDs
>>> (i.e., OID value >= 0xFF000000) to a driver? I've heard the this IOCTL
>>> was in the process of being deprecated, and it seems that we have
>>> problems with it and proprietary OIDs on NDIS 6.x.
>>>
>>> Thanks!
>>>
>>
>>
>
>