DDK2K 中的Passthru怎么使用呀

我编译了DDK2K中的Passthru,也已经安装上去，但是不知道怎么使用？用了DriverMoniter也没有输出信息。请问各位大虾是怎么回事。

你想拿它干什么用呀？它只是个driver.

我在研究NDIS方面driver的开发。看意思这个drv只不过把Mini传输到protocol，但问题是我需要这个drv安装后起什么作用。仅仅是将数据包传送到protocol层？

文件里不是有说明吗？

哪个文件？

有以太网的包头结构么？

以太网的包头结构
我昨天刚回答过，就在下面的贴子里。


PASSTHRU.SYS - Sample NDIS Intermediate Driver
SUMMARY
Passthru Intermediate Miniport (IM) Driver

The passthrough Intermediate Miniport driver is a do-nothing pass-through Ndis 5 driver that demonstrates the basic principals of initializing and setting up an IM driver. This driver exposes a virtual adapter for each binding to a real physical adapter. Protocols can bind to these virtual adapters as if they are real adapters.

The Passthru (IM) driver will re-package and send down all requests and sends submitted to this virtual adapter. The Passthru driver can be modified to change the data before passing it along. For example, it can encrypt/compress outgoing and decrypt/decompress incoming data.

This driver is a good example of a driver that exposes a virtual adapter based on a binding to a real physical adapter. It is not a good representative of another class of IM drivers whose underlying physical adapter is not a conventional NIC device, but have to follow IM driver model mainly because the indications from the driver to the upper layers are not happening in the context of a DPC.

BUILDING THE SAMPLE
Run the build command from this directory to build the sample―it creates the binary Passthru.sys.

To install this driver on Windows? 2000, use the SFILTER sample notification object and INF, also found in this DDK.

CODE TOUR
File Manifest
File Description

Makefile Used during compilation to create the object and sys files
Miniport.c Miniport related functions of the passthru driver
Passthru.c DriverEntry routine and any routines common to the passthru miniport and protocol
Passthru.h Prototypes of all functions and data structures used by the Passthru driver
Passthru.htm Html documentation of the Passthru driver (this file)
Passthru.rc Resource file for the Passthru driver
Precomp.h Precompile header file
Protocol.c Protocol related functions of the Passthru driver
Sources List of source files that are compiled and linked to create the passthru driver
Programming Tour
Basic steps in initializing and halting of Passthru driver:

1) During DriverEntry, the Passthru driver registers as a protocol and an Intermediate miniport driver.

2) Later on, Ndis calls the Passthru protocol to bind to a physical adapter.

3) In the context of BindAdapterHandler and after opening of the underlying physical adapter succeeds, the Passthru driver queries the reserved keyword \"UpperBindings\" to get a list of device names for the virtual adapters that this particular binding is to expose.

4) For each device name, the Passthru driver calls NdisIMInitializeDeviceInstance.

5) In response, Ndis will call back Passthru miniport InitializeHandler entry point.

6) After InitializeHandler successfully returns, ndis will take care of getting upper-layer protocols to bind to these newly created virtual adapters.

7) All requests and sends coming from upper-layer protocols for the Passthru miniport driver are repackaged and sent down to ndis, to be passed to the physical adapter.

8) All indications coming from bindings to the physical adapters are sent up as if they belong to virtual adapters.

9) When Ndis asks the Passthru driver to close the binding between a physical adapter and Passthru protocol, the Passthru driver first calls NdisIMDeInitializeDeviceInstance for the virtual adapter representing that particular binding.

10) Ndis in turn will close all the bindings between upper-layer protocols and virtual Passthru adapter.

11) After all the bindings are closed, Ndis will call HaltHandler entry point in Passthru driver for the virtual adapter and returns back from NdisIMDeInitializeDeviceInstance.

12) The Passthru protocol then closes the binding to the physical adapter and completes the unbind request issued in step 9.

13) To add Power Management Capabilities

13.1 During initialization, the Passthru miniport should set the Attribute \'NDIS_ATTRIBUTE_NO_HALT_ON_SUSPEND\' during the miniport initialization.

13.2 When the Passthru miniport is requested to report its Plug and Play capabilities (OID_PNP_CAPABILITIES), the Passthru miniport must pass the request to the miniport below the Passthru protocol. If this request succeeds, then the Passthru miniport should return this buffer with a status of NDIS_STATUS_SUCCESS:

NDIS_DEVICE_POWER_STATE MinMagicPacketWakeUp = NdisDeviceStateUnspecified;

NDIS_DEVICE_POWER_STATE MinPatternWakeUp= NdisDeviceStateUnspecified;

NDIS_DEVICE_POWER_STATE MinLinkChangeWakeUp=NdisDeviceStateUnspecified

If the miniport below the Passthru protocol fails this request, then the status that was returned should be used to respond to the original request that was made to the Passthru miniport.

13.3 The OID_PNP_SET_POWER and OID_PNP_QUERY_POWER should not be passed to the miniport below the Passthru protocol, as those miniports will receive independent requests from ndis.

13.4 When the Passthru is asked to go to standby, it should use the Passthru protocol\'s PnP Handler to block all new sends and requests, and wait for all outstanding sends and requests to complete. This should be done before returning from the PnP Handler.

 

14) To Add LBFO (Load Balancing & Fail Over)

Goal: To add load-balancing capabilities to the Passthru driver. TCP/IP should see only one network card connected to it. This is the primary miniport. The second card is the secondary miniport of this primary miniport. All receives are performed by the primary miniport and all sends are done by the secondary miniport. All sends and related requests are passed to the secondary miniport.

14.1 During miniport initialization, the new Passthru miniport searches through the list of existing Passthru miniport instantiations to see if a miniport with the same bundle identifier exists. If so, it calls NdisMSetMiniportSecondary on the two structures. The already instantiated Passthru miniport is the primary miniport.

14.2 During run time all sends are routed to the secondary miniport, and all receives are sent to the primary miniport.

14.3 All requests, sends, and receives should be completed on the handles that these actions were initiated on.

14.4 All requests should be passed on to the miniport below the Passthru miniport that they were requested on.

Note: There is an exception to above rule: some requests to the primary Passthru miniport may be redirected to the secondary miniport. In such a case, when the request needs to be completed, it should use the handles present in the primary miniport\'s data structure.

14.5 The user can change the bundle ID at run time. A NetEventReconfigure, with the new bundleID, is sent to the Passthru protocol\'s Protocol PnP Handler when this happens.

14.6 When the Passthru is reconfigured, it leaves the bundle that it is part of and could join a new bundle. Salient points follow.

14.7 To activate LBFO, ensure that \'#ifdef __LBFO\' is a valid statement (not commented out) in Passthru.h. Only when __LBFO is defined will the Passthru driver call the NdisMSetMiniportSecondary API.

14.8 The request handler and the request complete handler should have knowledge of the OIDs that are redirected so that those requests will be completed on the miniport handles they were requested on.

14.9 The sample filter installed as a service. To install, follow the steps below.

On the desktop, right-click the My Network Places icon and choose Properties.

Right-click on the relevant Local Area Connection icon and choose Properties.

Click Install, then Service, then Add, then Have Disk.

Browse to the Netsf.inf file. Ensure that Netsf_m.inf is present in the same directory. Click OK. This should install the Passthru driver.

Click OK or Yes each time the system prompts the user.

The two .inf files are needed because the sample filter is installed as a protocol and a miniport and you will be prompted at each installation.

14.10 To change a BundleID:

On the desktop, right-click the My Network Places icon, and then choose Properties.

Right-click the relevant Local Area Connection icon, and then choose Properties.

In the Installed Components list, click Sample Filter and then click the Properties tab. The second parameter is the BundleID. The user can change this value.

The change is recorded when the OK button of the Local Area Connection Properties Window is clicked.

14.11 Reconfiguration algorithm:

Read the new Bundle Id.

If Passthru miniport is a Secondary miniport, call NdisMPromoteMiniport on itself.

If the Passthru miniport is the Primary of a bundle, call NdisMPromoteMiniport on its secondary.

If there is already an instantiation of the Passthru miniport with the new Bundle Id, call NdisMSetMiniportSecondary on that Passthru miniport.

14.12 The Passthru miniport\'s Halt handler needs to be aware that since the miniport is being halted, it will have to promote its secondary miniport.

Top of page


 

? 1999 Microsoft Corporation