Hi,
I registering my ndis driver with NdisMRegisterMiniportDriver but this
function doesn’t have MajorFunctions param so I cannot reigster
functions. I should use NdisMRegisterDevice for MajorFunctions or it
is possible for NdisMRegisterMiniportDriver to register
MajorFunctions?
Regards,
Mustafa
No, it is not. The NDIS wrapper is reponsible for all dispatch for the FDO. The wrapper will call your MiniportXxx() entry points when it sees fit to involve the device specific code. Why do you want to register dispatch entries? You have two options that may make sense depending on the answer to the above: 1. Register an auxilary device (via NDIS). You get to specify the *effective* dispatch entries for the DeviceObject (not the DriverObject). Internally NDIS is doing something akin to virtual dispatch handling for auxilary device objects. 2. Create a [KMDF of course] PnP Filter Driver to deploy along with your Miniport (FDO) Driver and do whatever I/O you want to do in the filter driver. Coordinatiion between the Miniport and the Filter is easy enough (they are both in the same stack - use a private interface). Good Luck,Dave Cattley
Thankyou for your response. I connecting to miniport via CreateFile
and its success but when I call ReadFile or WriteFile its fail with
ERROR_NOT_SUPPORTED.
On Tue, Jul 17, 2012 at 4:24 PM, Dave Cattley wrote:
> No, it is not. The NDIS wrapper is reponsible for all dispatch for the
> FDO. The wrapper will call your MiniportXxx() entry points when it sees
> fit to involve the device specific code.
>
> Why do you want to register dispatch entries?
>
> You have two options that may make sense depending on the answer to the
> above:
>
> 1. Register an auxilary device (via NDIS). You get to specify the
> effective dispatch entries for the DeviceObject (not the DriverObject).
> Internally NDIS is doing something akin to virtual dispatch handling for
> auxilary device objects.
>
> 2. Create a [KMDF of course] PnP Filter Driver to deploy along with your
> Miniport (FDO) Driver and do whatever I/O you want to do in the filter
> driver. Coordinatiion between the Miniport and the Filter is easy enough
> (they are both in the same stack - use a private interface).
>
>
> Good Luck,
> Dave Cattley
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
In general NDIS miniports do not expose an I/O based model.
What are you trying to do? Good Luck,Dave Cattley
I routing all traffic to miniport and reading from user application. I
checked TUN/TAP driver and I can successfully send ping packet from
user application. But when I try to send ping packet to miniport, its
not success with ERROR_NOT_SUPPORTED.
I checked TUN/TAP source and it’s uses NdisMRegisterDevice so easy to
handle IRP_MJ_XXX.
I wondering, it is not possible to handle IRP_MJ_XX requests when
using NdisMRegisterMiniportDriver?
On Tue, Jul 17, 2012 at 9:41 PM, Dave Cattley wrote:
> In general NDIS miniports do not expose an I/O based model.
>
> What are you trying to do?
>
>
> Good Luck,
> Dave Cattley
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
What about using NdisRegisterDeviceEx() to set the Major Function routines?
Larry C
I assume when you say you checked TUN/TAP sources you are referring to some publicly available Windows driver that implements a virtual Ethernet adapter and exposes an *auxilary* device object which can be opened from user mode. There are two device objects involved. - The root enumerated device stack where the NDIS Miniport is acting as the driver for the Function Device Object (FDO). - A Control Device Object (CDO) created by NDIS and with which a set of Dispatch Entry Points have been registered. The User Mode I/O is to/from the CDO not the FDO associated with the Virtual NIC. It is only through the code in the TUN/TAP driver that these two independent device objects are associated and the mechanism of issuing I/O on the CDO has any effect (packet capture & injection) on the Virtual NIC. So if what you are trying to do is just what this class of drivers accomplishes and you have found one in source form that demonstrates how it is done, what is your question? Is it ‘why do I need to do it this way’? The answer was in my other post. NDIS owns the NIC Device Object. NDIS does not expose an I/O model to user mode for packet transfer. That is the way it is. Good Luck,Dave Cattley