Ndis Miniport and IOCTL/OID control code

Jean-Paul Accarie

unread,

Jul 29, 1997, 3:00:00 AM7/29/97

to

Hi,

Suppose we have a Ndis Miniport driver whose NdsiMedium is Experimental,
let's call it "NdisMediumMyDRIVER" (define value > 0xffff0000).
When looking at files Ntddndis.h :
#define _NDIS_CONTROL_CODE(request,method) \
CTL_CODE(FILE_DEVICE_PHYSICAL_NETCARD, request, method,
FILE_ANY_ACCESS)

and Ntddk.h:
//
// Macro definition for defining IOCTL and FSCTL function control codes.
Note
// that function codes 0-2047 are reserved for Microsoft Corporation, and
// 2048-4095 are reserved for customers.
//
#define CTL_CODE( DeviceType, Function, Method, Access ) (
\
((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)
\
)

I conclude that i can define new IOCTL_NDIS_... control code for my NIC
NDIS Miniport driver
(using Function codes > 2047) and that I can call from the user-mode
DeviceIoControl function
to perform any action.
Why does this not make sense?

Elsewhere, as i use my NdsiMedium "NdisMediumMyDRIVER", i should be able to
define
new OIDs (Object Identifiers used by NdisRequest Query/Set Information).
Is it possible?
Whithin the range [0x0B000000; 0x0F000000[ for instance?
OIDs are system-defined, does-it mean that somewhere in NDIS library a
check is performed?

What I would like is to easily and quickly re-use all the IOCTL control
codes, that I had
implemented in my previous non-NDIS driver, in my new NDIS miniport
driver...
When possible without developping a dumy transport layer in charge of
convert IOCTL
requests into NDIS requests.

Thanks for your comments, any suggestion will be appreciated
Regards
Jean-Paul

Cristian

unread,

Jul 29, 1997, 3:00:00 AM7/29/97

to

Jean-Paul Accarie wrote:
>
> Hi,

...............................

It seems you are bumping into the same wall as I did - THEY (need I say
who?) are saying that blending in the same device IOControl Functions
and NDIS Miniport backbone could not be done; the “approved” solution is
having as you said a dummy transport which takes care of the first part
plus an additional NDIS miniport driver.
What I did, (and you might find it useful) (it works in NT 4.0) is
initialize the miniport characteristics at the BEGINNING of
“DriverEntry” (ISRHandler, DisableInterruptHandler,
EnableInterruptHandler = NULL) and then proceed with whatever the rest
of “DriverEntry” and family is supposed to do (interrupts, IO address
and the like), ending with the publishing of the Device IO entry points.
As a result, the wrapper finds it’s miniport device and the apps their
DeviceIO entries. You have to sync between user’s (app’s) requests and
the one coming from the protocol stack.

Regards,

Cristian Chiritescu
Cellsys, Inc.

Stephan Wolf

unread,

Jul 30, 1997, 3:00:00 AM7/30/97

to

On 29 Jul 1997 16:19:09 GMT, "Jean-Paul Accarie"
<acc...@crf.canon.fr> wrote:

...

>Elsewhere, as i use my NdsiMedium "NdisMediumMyDRIVER", i should be able to
>define
>new OIDs (Object Identifiers used by NdisRequest Query/Set Information).
>Is it possible?
>Whithin the range [0x0B000000; 0x0F000000[ for instance?
>OIDs are system-defined, does-it mean that somewhere in NDIS library a
>check is performed?

...

The most siginificant byte (MSB) of the OID specifies the "general
information" part of it. If the MSB is 0xFF, then the OID contains
"Implementation-specific information".

See DDK Help, Network Drivers book, "Chapter 5, NDIS Object
Identifiers" for details.

Stephan Wolf <sw...@syskonnect.de> http://www.syskonnect.de
SysKonnect - The Server Connectivity Company

Jean-Paul Accarie

unread,

Jul 30, 1997, 3:00:00 AM7/30/97

to

Thanks for your response,

Ok as far as the dummy transport is concerned,
but have you defined new OIDs so that you can perform
your specific debug functions inside the NDIS NIC miniport?
If not, you did you proceed?

Thanks
Jean-Paul

Cristian <cris...@cellsys.com> wrote in article
<33DE7D...@cellsys.com>...

Cristian

unread,

Jul 30, 1997, 3:00:00 AM7/30/97

to Jean-Paul Accarie

Jean-Paul Accarie wrote:
>
>
The OIDs are implemented the same way as in the NE2000 sample.
Talk to you later,

Cristian

kyleb

unread,

Jul 31, 1997, 3:00:00 AM7/31/97

to

the method described below is not supported under nt 5.0

k.

kyleb

unread,

Jul 31, 1997, 3:00:00 AM7/31/97

to

yes. you must create a dummy transport that publishes your ioctls.
this will in turn translate them to ndis request calls.
you can create driver specific OIDs that start with 0xFF has the high byte
of the oid.
0xFF000001 for example.

under 5.0 there will be a thing called WMI. Windows Management Interface
(or something close to that).
this will provide a common usermode interface that allows query, set data
items and event indications.

k.
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of Microsoft Corporation

Please respond to this news group. Do not send mail

Jean-Paul Accarie <acc...@crf.canon.fr> wrote in article
<01bc9cc5$a971a920$515102c2@artemis>...

> Thanks for your response,
>
> Ok as far as the dummy transport is concerned,
> but have you defined new OIDs so that you can perform
> your specific debug functions inside the NDIS NIC miniport?
> If not, you did you proceed?
>
> Thanks
> Jean-Paul
>