table of Contents
1 NDIS Intermediate Layer 21.1 NDIS Intermediate Drivers (NDIS Intermediate Drivers) Overview 21.2 NDIS Intermediate Layer Driver Used 41.3 NDIS Intermediate Layer Driver Development Environment 42 NDIS Intermediate Layer Driver Development 42.1 Speedless and Discard Code 42.2 Access to Shared Resources Synchronization 52.3 Intermediate Layer Driver DRIVERENTRY Functions 52.3.1 Register NDIS Intermediate Layer Driver 62.3.1.1 MINIPORT 62.3.1.2 Registered Intermediate Layer Driver 92.4 Middle Layer Driver Dynamics Binding 112.4.1 Opens the Adapter 122.4.2 Micro Port (MiniPort) Initialization 122.4.3 Intermediate Layer Driver Query and Setup Operation 132.4.3.1 Publishing Settings and Query Request 142.4.3.2 Response Settings and Query Request 152.4 As the intermediate layer driver data packet management 172.5.1.1 Renewable data packet management 172.5.1.1 Renewable Packet 182.6 Intermediate Layer Driver Restriction 192.7 Intermediate Layer Driver Receive Data 192.7.1 The lower boundary is facing the intermediate Layer Driver Receive Data 192.7.1.1 Implementing the ProtocolReceivePacket Handle 202.7.1.2 in the Intermediate Layer Driver 202.7.1.2 Implementing the ProtocolReceive Processor 212.7.1.3 Under the Boundary Direction of Non-Connected Intermediate Layer Drivers Receive OOB Data Information 222.7.2 The lower boundary facing the intermediate layer driver receiving data 222.7.2.1 Implementing the ProtocolcorecePacket handler 232.7.2.2 in the intermediate layer driver Receive OOB data information 232.7.3 to the high-level driver indication to the high-level driver Packet 232.8 Transfering Packets By Intermediate Layer Driver 232.8.1 Transfer Media Related Information 252.9 Processing the PNP Events of the Intermediate Layer Driver and PM Event 262.9.1 Processing OID_PNP_XXX Query and Settings 262.9.2 Intermediate Layer Driver ProtocolPNPEVENT Handling 272.9.3 Handling the prescribed power supply request 282.9.3.1 Power settings for sleep Status Request 282.9.3.2 Working Status Power Settings 292.10 Intermediate Layer Driver Reset Operation 292.11 Intermediate Layer Driver Remove Binding Operation 30 2.12 Intermediate Layer Driver Status Indication 313 Load Balancing and Failure 313.1 About LBFO 313.2 Specifying LBFO Support 323.3 Implementing LBFO 323.3.1 Initializing Micro Port Driver 333.3.2 Balance Micro Port Drivers 333.3 .3 Enhance a sub-microfile 344 installation network component 344.1 to install a network component and file 344.2 Creating a network INF file 354.2.1 Network INFS file name 354.2.2 Network INF file version 354.2.3 Network INF file model festival 364.2.4 INF file DdInstall section 374.2.5 Delete Festival 384.2.6 ControlFlags section 394.2.7 Network INF file Add-registry-sections 39
Table 1 Abbreviation
Project English description Chinese description NDIS Network Driver Interface Specification Network Driver Interface Standard IMD Intermediate Drivers Intermediate Driver TDI Transport driver Interface Transport Driver Interface NIC Network Interface Card Network Interface Card SP Service Pack Service Pack LAN Local Area Network LAN LAN-E LAN emulation LAN emulation NAT network address Translation network address Translation LBFO load balancing and fail-Over load balancing and failure Alternatively DDK device drivers Kit device driver development Kit SMP symmetry multiprocessing symmetric multiprocessing OS operating system OS IDE integrated development environment integrated development environment 1 NDIS Intermediate Layer Driver 1.1 NDIS Intermediate Drive (NDIS Intermediate Drivers) Overview
Microsoft Windows Network Driver Interface Standard (NDIS 4.0) and Windows NT 4.0 (SP3) introduces a new NDIS driver that can be embedded in NDIS transmission drivers TDI (eg, TCP / IP) and the underlying NDIS network interface The middle of the driver. This new type of driver is called NDIS intermediate layer drive, as shown in Figure 1. The NDIS (Network Drive Interface Standard) The middle layer driver exports the MiniPortxxx function on its upper boundary, and exports the Protocalxxx function under its lower boundary. The driver only provides connection-free communication support in its upper boundary, and in its lower boundary, you can support faceless communication or support for connection communication. The micro-port portion (upper boundary) of the intermediate layer driver must be non-serial, and the system will rely on these non-serial drivers, rather than NDIS to serialize the operation of the MiniPortxxx function and queue the internal generated output package. Operation, this driver can provide a full-duplex operation of performance as long as the driver maintains a small critical area (each time there is only one thread to execute the code). But these non-serial MiniPort is more restrictions on more stringent design requirements, often pay more debugging and testing for this. The intermediate layer driver is a typical hierarchy, which is based on one or more NDIS NIC drivers, which is a transport driver supported by providing TDI (transmission driver interface) upward layer (possibly multilayer structure). ). In theory, an intermediate layer driver can also be based on other intermediate layer drivers or a low-layer that is other intermediate layer drivers, although this program does not necessarily exhibit better performance. One example of the intermediate layer driver is a LAN emulation intermediate layer driver, which is an early transmission driver, and the lower layer is a micro-port NIC driver of a non-LAN medium. The driver receives the data packet in the LAN format from the upper layer and converts it to the media format of the local network card, and then sends it to the NDIS micro port of that NIC. When receiving data, the driver converts the packet sent by the low-layer NIC driver into a LAN compatible format, and finally transfers these converted packets up to the upper transfer driver. For example, NDiswan has some of the above features. NDISWAN converts the packet from the upper transfer LAN format to a WAN packet format, or converts a packet from a low-level NIC drive WAN format to a LAN packet format. In addition, if the low-level NIC hardware does not support these functions, NDISWAN can also provide data formatting functions such as compression, encryption, and end-to-peer protocol (PPP). NDISWAN provides a private interface for communication between NDIS API and NIC drivers, and NDISWAN also maps protocol bindings to active connection requests. Another example of another intermediate layer driver is an ATM LANE (LAN Simulation) driver that converts the packet from the upper layer-free transport format to the ATM format supported by the lower-level network card. Figure 1.1 illustrates the intermediate layer driver structure chart 1 intermediate layer driver structure
The NDIS Intermediate Layer driver plays a packet sent by the upper-layer driver in NDIS and transmits it to the interface function sent by the next driver. When the intermediate layer driver receives the packet from the lower driver, it either calls the NDISMXXIDICATERECEIVE function, or call the NDISMISMISMISMISMISMISMICEIVEPACKET function to indicate the packet up. The intermediate layer driver opens and creates a binding of the low-level NIC driver or NDIS intermediate layer driver by calling NDIS. The intermediate layer driver provides the MiniPortSetInformation and MiniPortQueryInformation function to process the settings and query requests for the high-level driver. In some cases, these requests may also be passed to the low-level NDIS driver. If the lower boundary is a connectionless Call NidSRequest implements this feature, if its lower boundary is connected, the function is implemented by calling NidscoreQuest. The intermediate layer driver sends a packet to the network low NDIS driver by calling the function provided by NDIS. For example, the lower boundary facing the unconnected intermediate layer driver must call NDISSEND or NDISSENDPACKETS to send packets or packet array, and NDISCOSENDPACKETS must be called to send packet data packets when the lower boundary is connected. If the intermediate layer driver is based on a non-NDIS NIC driver, then after the MINIPORTSEND or MiniPort (CO) Sendpackets function of the intermediate layer driver is called, the send interface will be opaque to NDIS. NDIS provides a group of NDISxxx functions hidden with low-level operating system details and macros. For example, an intermediate layer driver can call ndismInitializetimer to create a synchronization clock, you can call NdisinitializElisthead to create a list. The intermediate layer driver uses a function that meets the NDIS standard to increase portability of its Microsoft operating system that supports Win32 interface. 1.2 Use of NDIS Intermediate Layer Driver
There are several ways to drive NDIS intermediate layer, including: LAN emulation - NDIS intermediate layer driver enables a non-LAN NIC drive (eg, ATM) is like a local area NIC drive (eg, Ethernet). Packet filtering - can intercept and modify the network package between the high-level TDI (transmission driver) and the underlying NIC driver (PASS / DROP PACKETS) delay or reorder (Delay / Reorder) Packets) Encryption or Decryption / Decryption Routing Packet (NAT Network Address Translation) LBFO Load Balancing and Failure and Fail-Over )
1.3 Development Environment of NDIS Intermediate Layer Driver
OS: Microsoft Windows 2000 Serveride: Microsoft Visual C V6.0 DDK: Windows 2000 Device Drivers Kit
2 Development of NDIS Intermediate Layer Driver
2.1 can be pageable and discarded
Each MiniPortxxx function or protocolxxx function runs on a specific IRQL, which can be used in the Intermediate Layer Driver IRQL from Passive_LEVEL until Dispatch_level (including Dispatch_level). The intermediate layer driver function running on IRQL Passive_level can be tagged as a pageable code by calling NDIS_PAGEABLE_FUNCTION macros. The driver designer should design the program code as a pageable, which must reside the memory code release system space. Running the driver function of the IRQL Passive_level, when it is not called any function running in IRQL> = Dispatch_level, nor is it running in any function call to IRQL> = Dispatch_level, and it can be marked as a pageable. For example, a function of acquiring self-spinch, and gets self-spinning locks will cause the getting thread to rise to IRQL Dispatch_level. A function running in Irql Passive_LEVEL, such as protocolbindadapter, if you are marked as a pageable, you cannot call functions running in IRQL> = Dispatch_level NDIS. For more information on the NDIS function running on the IRQL, see the "NetWork Drivers Reference" of online DDK, which lists the IRQL of each NDISxxx function. The DRIVERENTRY function of the intermediate layer driver and the code that only in Driverentry, should be set to use only as the system initialization function with NDIS_INIT_FUNCTION macros. Suppose the code of the NDIS_INIT_FUNCTION macro identity is only running when the system is initialized so that the part of the code will only be mapped when initialization, and the part of the NDIS_INIT_FUNCTION macro identifies will be discarded. 2.2 Access to shared resources is 2.3 steps
If the resource allocated by the driver can be shared by two driver functions, or the intermediate layer driver can run on the SMP (symmetric multiprocessing) machine, so the same driver function can access the resource from multiple processors, Then synchronize the access to these shared resources. For example, the driver maintains a shared queue, using a spin lock to synchronize the queue, and the spin lock calls NDisallocateSpinLock before the queue creates. Of course, you don't have to protect shared resources too much, for example, for queues, some read operations are not serialized. But any operations for queue link must be synchronized. Self-spin locks should be used as little as possible, and each time you can shorten the time it is used. Refer to "Kernel_Mode Drivers Design Guide" for a more in-depth discussion of spin locks.
2.4 DriveREntry function for intermediate layer driver
In order to enable the loader to accurately identify, the initial entry point of the intermediate layer driver must be explicitly specified as the DRIVERENTRY. All other drivers export functions, the MiniPortxxx and Protocolxx functions described herein, because their address is transmitted to NDIS, so it can be arbitrarily specified by the developer when designing. Any kernel mode driver DriveREntry has the following form: NTSTAUSDRIVERENTRY (in PDRIVER_OBJECT DriverObject, In Punicode_String RegistryPath); If in addition to Protocolxxx, the driver also exports a set of standard kernel mode driver functions, then these standard functions must be The address write to the driver object for DriveREntry. In the intermediate layer driver, DriveREntry should at least complete the following: call NDISMINIALIZEWrapper and save the handle returned in NDisWrapperHandle; pass the handle of the previous step, call the NDisimRegisterLayeredMiniport registration driver's MiniPortxxx function; if the driver then binds to the low layer On the NDIS driver, call the NDisRegisterProtocol registration of the protocolxxx function; if the driver exports the MiniPortxxx and Protocolxx function, call NDisimassociateminIPORT to advertise the micro-port low boundaries and protocols of the driver for the NDISimassociateMiniport; DriveRentry can be the intermediate layer All shared resources allocated by the driver are initialized from the spinch, such as the driver for tracking the components and memory regions of the running connection and sending tasks. When DriveREntry does not assign all resources for the network I / O operation to the driver, it should release any of the previously assigned resources and return an appropriate error. For example, if the DriveREntry has called the NDISMINIAL ZEWRAPPER function, the NDisterMinateWrapper reset system status must be called when the following is wrong. The DriveREntry function of the intermediate layer driver can perform some global initialization operations. However, if the driver provides the protocolbindadapter function that implements the opening and binding function of the low-level device in Section 2.4, the driver can make protocolbindadapter to allocate binding-related system resources, protocolbindadapter as required by DeviceName Perform resource allocation and binding operations. DriveREntry must initialize the package program and register the micro-port driver. If the intermediate layer driver exports a set of Protocolxxx functions, the protocol driver is also registered. If the intermediate layer driver exports a set of MiniPortxxx functions to NDIS, just register these functions to the NDIS library, as described below. 2.4.1 Register NDIS Intermediate Layer Driver
The NDIS Intermediate Layer driver must register its MiniPortxxx function and protocolxxx function to NDIS in the environment of the DriveREntry function. The driver registered by calling NDisimRegisterLayeredminIPort, which exports the MiniPortxxx function of the intermediate layer driver. When the virtual NIC is initialized, and when the driver will receive and send packets based on the NIC, pay attention to the control process of the driver. For the specified virtual NIC, NDIS will call the MINIPORTINIALIZE function of the intermediate layer driver in the NDisimInitializedEviceInstance environment to initialize it. If the intermediate layer driver exports multiple virtual NICs, the driver must be initialized for each NIC function to invoke each NIC. This can generate the corresponding number of virtual NICs according to the network traffic. If the NDIS intermediate layer driver also exports a set of Protocolxxx functions, you must call the corresponding NDisRegisterProtocol function to register these functions to the NDIS library.
2.4.1.1 Register the MINIPORT Intermediate Layer Driver for the Intermediate Layer Driver Exports the MiniPortxxx function by calling NDisimRegisterLayeredminIPort. NdisIMRegisterLayeredMiniport declared in the following manner: NDIS_STATUSNdisIMRegisterLayeredMiniport (IN NDIS_HANDLE NdisWrapperHandle, IN PNDIS_MINIPORT_CHARACTERISTICS MiniportCharacteristics, IN UINT CharacteristicsLength, OUT PNDIS_HANDLE DriverHandle); intermediate drivers must save DriverHandle handle NdisIMRegisterLayeredMiniport return and call NdisIMInitializeDeviceInstance function driver, requested intermediate layer The MINIPORTINIALIALIZE function of the driver is initialized to the virtual NIC, and the handle is input to NDIS. When the intermediate layer driver is successfully bound to one or more low-level NIC drivers or when it is bound to a non-NIC device driver, the NDISimInitializedEviceInstance function will call the intermediate driver to initialize the MiniPort component to accept I / O requests on the virtual NIC. The NDisWrapperHandle handle is returned by the previous NDISMINIALZEWRAPPPPper function. The intermediate layer driver must complete the following: use the NDiszeromeMory function zero to initialize a Ndis_MiniPort_Characteristics type component; save all the mandatory and non-mandated MiniPortxxx functions exported by all drivers, and set all the non-powerful miniPortxxx portal pointers to NULL; When other types of NDIS drivers are 0x03,0x04,0455, if you want to export any new V4.0 or V5.0's MiniPortxxx function, the main version of the intermediate layer driver must be 4.0 and provide The MiniPortCharacteristics component of 4.0 or version 5.0. For miniPortCharacteristics, if the driver does not export the MiniPortxxx function, you must set it to NULL, but if you want to export the function, you must set it to a valid MiniPortxxx function address value. HaltHandler When the low-level NIC timeout and NDIS have stopped the NIC driver, or the operating system is performing a controllable system shutdown operation, NDIS will call the function. INITIALIZEHANDAL is called the results of NdisimInitializedEviceInstance initialized micro ports as an intermediate layer driver, calling this function to initialize the virtual network card. QueryInformationHandler This function receives OID_XXX requests, which comes from a high-level driver (using the NDisRequestQueryInformation request type as a parameter, calling ndisRequest). RESETHANDLER Instructions in NDisReset, NDIS can call the MINIPORTRESET function of the intermediate layer driver. However, the protocol driver does not start the reset function, usually, NDIS starts a low-layer NIC driver reset operation and calls the ProtocolStatusComplete function in the intermediate layer driver to notify the intermediate layer driver low-level micro-port is resetting the network card.
SetInformationHandler This function receives OID_xxx requests, which comes from a high-level driver (using NDisRequestSetInformation request type as a parameter, calling ndisRequest). SendHandlerndis calls this function Send a single packet to the low-level NIC (or device) driver. If the intermediate layer driver does not support the MiniPortsendPackets function, then the MiniPortSend function (or miniPortWansend function) must be available. Unless the intermediate layer driver is always based on only a single packet, only a single packet or a driver that itself is binds to the low-level WAN NIC, the MiniPortsendPackets function should always be available in SendPacketShander, not by the SendHander handler. For more discussions on this area, please refer to Section 2.9. SendPacketsHander This function receives the population of packet descriptor pointer for specifying the online transfer packet. Unless the intermediate layer driver is bound to the low-level WAN NIC driver, the driver should provide the MINIPORTSENDPACKETS instead of the MiniPortSend function support for the MINIPORTSEND function. In other words, regardless of the intermediate layer driver is based on a network card driver that can only transmit a single packet, it is based on a network card driver that can transmit multiple packets per time, regardless of the intermediate layer driver based on only each time. Can transmit a single packet protocol driver; or a miniPortsendPacketS function can achieve the best performance based on a protocol driver that can transmit multiple packets, and more discussions on this area can be found in Section 2.9. TransferDataHandler This function is used to transmit the remainder of the received packet not indicated in the front-view buffer, which is passed by the intermediate layer driver to the NDismxxIndicateReceive function. This indicated packet can be the ProtocolReceive function of the intermediate layer driver or a conversion packet received by the ProtocolReceivePackets handler. If the intermediate layer driver indicates the receiving packet by calling (except NdismwanIndicateRereceive) NDISMXXIndicateRereceive function, the handler is required to be provided. If the intermediate layer driver always indicates the NDISMINDICATERECEVEPACKET to indicate the data package to the up-layer driver, it is not necessary to provide the MiniPortTransferData function. ReturnPacketHandler This function receives the return packet descriptor (the package descriptor has previously called to the high-level indication through the NDISMISMISMISMISMISMISMECEVEPACKET to release the control of the resource indicating to the high-level driver. After the high-level driver is processed, the descriptor assigned by the intermediate layer driver and the descriptive resources will be returned to the MiniPortReturnPacket function. Of course, if the intermediate layer driver always indicates the packet up to the upper layer by calling the media-related ndismxxcribedIndicateReceive function, or set the OOB data block (related to each descriptor) status to NDIS_STATUS_RESOUCES before calling NDISMIndateRerecePacket, no need to provide MiniPortReturnPacket function. CheckForhangHandler This function is called by NDIS, or runs at intervals specified by the intermediate layer driver, both of them only. If the handler is provided, the miniPortCheckForhang function is called once every two seconds (or calls the interval required by the driver).
More information about the MINIPORTCHECKFORHANG function can be found in "NetWork Drivers Reference" or the second part of the manual. Typically, since the driver cannot determine if the low-layer network card is suspended, the NDIS intermediate layer driver does not provide support for the MiniPortCheckForhang function. If the driver cannot reach the NDIS driver based on the NDIS, the intermediate layer driver may provide support for the handler. Since the driver does not manage the interrupt device, it does not assign buffers in use, or because NDIS does not call the miniPortReconfigure function (in ReconfigureHandler), the intermediate layer driver does not provide the following micro-port handler. function. DisableInterruptHandlenableInterruptHandlerHandleInterRuptHandlerismLeralLocateCompletehandlerReconfigureHandler
2.4.1.2 Register the Protocol Intermediate Layer Driver Registered by calling NDisRegisterProtocol to NDISROTOCOLXXX functions. NdisRegisterProtocol statement carried out as follows: VOIDNdisRegisterProtocol (OUT PNDIS_STATUS Status, OUT PNDIS_HANDLE NdisProtocolHandler, IN NDIS_PROTOCOL_CHARACTERISTICS ProtocolCharacteristics, IN UINT CharacteristicsLength); NdisRegisterProtocol before calling a function, the intermediate layer driver must do the following: zero initializing a NDIS_PROTOCOL_CHARACTERISTICS type structure. The intermediate layer driver can use a 4.0 or version 5.0 version of the Protocolcharacteristics structure. The protocol driver must support plug and play features, so NDIS no longer supports the 3.0 version of the protocol driver. Save all of the mandatory and unforgettable protocolxxx functions supported by all drivers; the NDisProtocolHandler that the call to the NDisProtocolHandler is opaque, the intermediate layer driver must save the handle, and in the future NDIS intermediate layer driver The function call of the protocol section is passed as input parameters, for example, the function call of the low-layer adapter is opened. 2.4.1.2.1 Registration The lower boundary The protocolxxx function of the unconnected intermediate layer driver under the boundary facing the unconnected intermediate layer driver (including optional and must-have) protocol handler functions are listed below: BindAdapterHandler It is a function that must be provided. NDIS calls the function requesting the intermediate layer driver Binds to the low-level NIC or virtual NIC, and the NIC name is transmitted as a parameter of the handler. See Section 2.4 for more information on dynamic binding. UNBINDADAPTERHANDALHER This is a function that must be provided. NDIS calls ProtocolunbindAdapter release the binding of the low-level NIC or virtual NIC, and the NIC name is passed as a parameter of the handler. When the binding is successfully closed, protocolunbindadapter will call the NDisCloseadapter function and release the resources. OpenAdapterCompleteHandler This is a function that must be provided. If the intermediate layer driver returns ndis_status_pend in the call of NDisopenadapter, then then call ProtocolopenAdapterComplete to complete the binding. CloseadapterCompletehandler This is a function that must be provided. If the intermediate layer driver returns NDIS_STATUS_PENDING to NDISCLOSEADAPTER's call, then pro is then called to complete the binding release. ReceiveHandler This is a function that must be provided. The ProtocolReceive function is to point to the pointer to the front view buffer containing the network reception data to be called executed. If the buffer contains not a complete network packet, ProtocolReceive calls NDISTRANSFERDATA to receive the remainder of the packet by a packet descriptor as a parameter. If the low-level driver calls NDISMindicateReceivePacket Indicates the receiving packet, the front-view buffer passing to the ProtocolReceive function will always be a complete network packet. ReceivePacketHandler This is an optional function. If the NIC driver based on the intermediate layer driver indicates that the packet descriptor pointer array, or calls the NDISMISMISMISMISMISMISMISMECEIVEPACKET function indicating that the extracted data is received, the driver should provide the ProtocolReceivePacket function.
If the developer does not determine the execution environment of the intermediate layer driver, a function should be provided because the intermediate layer driver will achieve better performance on the low-level NIC driver capable of generating a multi-package indication. ReceiveCompleteHandler This is a function that must be provided. The ProtocolReceComplete function will be called when the packet previously indicated to the ProtocolRecEive function is processed. TransferDatacpeleTehandler If protocolreceive wants to call NDISTRANSFERDATA functions, you must provide this handler. If the NDISTRANSFERDATA function call returns NDISTRANSFERDATA function call returns NDIS_STATUS_PENDING, the ProtocolTransferDataComplete function will be called when the transfer operation is complete. ResetCompleteHandler This is a function that must be provided. The ProtocolreSetComplete function will be called when the NDisRest function (returning ndis_status_pending) calls the start-up reset operation. Typically, the intermediate layer driver does not call NDisReset, but because the upper driver may call the function, the intermediate layer driver may only forward the reset request to the low-level NDIS driver. RequestCompleteHandler This is a function that must be provided. The ProtocolRequestComplete function will be called when the NDISREQUEST function (returning ndis_status_pending) calls the startup query or setup operation. SendCompleteHandler This is a function that must be provided. For each data packet that calls the NDISSEND function, when it returns ndis_status_pending as a transmission state, the ProtocolsendComplete function is called to complete the sending operation. If you call NDISsendPackets Send a group of packets, ProtocolsendComplete will be called once for each packet that is delivered to NDISSENDPACKETS. The intermediate layer driver can determine the status of the sending operation of the NDISSendPackets function to the NDISSendPackets function only according to the status parameter sent to ProtocolsendComplete. StatusHandler This is a function that must be provided. NDIS calls the ProtocolStatus function with the status notification initiated by the low-level NIC driver. StatusCompleteHandler This is a function that must be provided. NDIS calls the ProtocolStatusComplete function to indicate that the status change operation has been completed, which is previously indicated to the ProtocolStatus function. PnpeventHandler This is a function that must be provided. NDIS calls protocolpnpevent to indicate plug and play events or power management events. See Section 2.9 for more information. UnloadHandler This is an optional function. NDIS calls the ProtocolunLoad function to respond to the user's request for the intermediate layer driver. For each binding adapter, NDIS will call the protocolunload function to uninstall the driver after calling the ProtocolunBindAdapter. Protocolunload executes the clearance operation determined by the driver.
The intermediate driver function boundary ProtocolXxx 2.4.1.2.2 registered connection-oriented lower boundary intermediate drivers must be registered connection-oriented and shared miniport connection-oriented protocol handler functions as follows connectionless: BindHandlerUnbindHandlerOpenAdapterCompleteHandlerCloseAdapterCompleteHandlerReceiveCompleteHandlerResetCompleteHandlerRequestCompleteHandlerStatusCompleteHandlerPnPEventHandler These functions have been summarized in the last small section. The next boundary is a connection-oriented intermediate layer driver must also register the following facing connection protocol function: CosendCompleteHandler This is a function that must be provided. One ProtocolCoSendComplete function is called for each packet passing to NDisCosndPackets. The intermediate layer driver can determine the status of the sending operation of the NDisCoSendPackets only based on the status parameters sent to the protocolcosndcomplete. CostatusHandler This is a function that must be provided. NDIS calls the Protocolcostatus function with the status notification initiated by the low-level NIC driver. CorecevicePacketsHandler This is a function that must be provided. NDIS will call the ProtocolcorecePacketHandler function of the intermediate layer driver when the NDismCoIndeRecePackets indicates a pointer array by calling NDismCoIndicateRerecePackets. COAFREGISTERNOTIFYHANDLER If the intermediate layer driver is a connection customer-oriented customer-oriented, the ProtocolCoAfregisterNotify function must be registered, which is used to determine whether the intermediate layer driver can use the call manager or MCM ( Services that have been registered with address families, publish their services). 2.5 Dynamic Binding of Intermediate Layer Drivers
The intermediate layer driver must provide the ProtocolBindAdApter and the ProtocolunBindAdapter function to support dynamic binding of the low-level NIC. When NIC is available, NDIS calls the middle layer driver (can bind to NIC) to implement dynamic binding operations. VOID ProtocolBindAdapter (OUT PNDIS_STATUS Status, IN NDIS_HANDLE BindContext, IN PNDIS_STRING DeviceName, IN PVOID SystemSpecific1, IN PVOID SystemSpecific2); BindContext handle presenting bind request NDIS environment, the intermediate layer must save the handle of the driver, the driver and the intermediate layer is completed Binding the relevant operation, and is ready to accept the send request, return the handle to NDISCOMPLETEBINDADAPTER's parameters. The operation of the binding includes assigns the NIC-related environmental area and initializes the binding, followed by calling the NdisopenAdapter binding to the adapter specified by the DeviceName parameter. DeviceName may be a NIC of the low-level NIC driver management, or it is also a virtual NIC that is intermediary-free between the NIC driver of the called intermediate layer driver and the management adapter, which is derived from the control transmission request exported by the intermediate layer NDIS driver. Typically, there may be only one intermediate NDIS driver based on the NIC driver, which implements the transition between medium formats supported by the early high-level protocol driver and media format supported by the low-level NIC driver. Note that the DeviceName transmitted by the intermediate layer driver to NDisopenadapter must be the same as DeviceName (a Unicode string buffer pointer) that is previously passed from the protocolbindadapter function. The driver cannot copy the pointer and passes the pointer copy to the NDisopenadapter function. The intermediate layer driver can save BindContext on the assigned binding associated environmental area or another driver accessible location. If ndisopenadapter returns ndis_status_pedding, you must save the BindContext value, in which case the intermediate layer driver is completed until the operation of the adapter is turned on, and its ProtocolopenadapterComplete function has been called completed, and the NDISCompletebindAdapter function completes the binding work. BindContext must be obtained from a known location and passed by ProtocolopenadapterComplete to the NDiscompletebindAdapter function. If the intermediate layer driver stores the adapter related information into the registry, SystemSpect will point to the registry path, which will pass to the NDisopenProtocolConfiguration function to obtain a handle for reading the adapter information. Systemspecific2 reserved system use. If the intermediate layer driver is converted from a medium format into another format, the ProtocolBindAdAPter can assign the packet descriptor pool and the buffer descriptor required for each binding. Refer to Section 2.5 for the requirements for allocation and management of data packets. In addition, if the intermediate layer driver receives internal data with the Protocol (CO) Receive function, the driver should allocate the packet pool and buffer pool to copy the received data. 2.5.1 Open the adapter of the lower layer of the intermediate layer driver
The ProtocolBindAdapter function opens the low-level NIC or virtual network card via the DeviceName parameter value to create a binding of the low-level NIC driver, which can also read the required additional configuration information from the registry. NdisopenProtocolConfiguration is used to get registration deactivation handles that point to the intermediate layer driver storage adapter related information. The intermediate layer driver opens the NdisopenFigurationKeyByNAME function or the NDisopenfigurationKeyByname function opens and gets the primary key (opened by the NDisopenProtocolConfiguration function). The intermediate layer driver can then call the NDisread (WRITE) Configuration function read and write the relevant information under the registry primary key or sub-key. The NDisread (Write) Configuration function has a detailed description in the "NetWork Drivers Reference" in the online DDK. Typically, ProtocolBindAdapter uses a environmental area (representing DeviceName binding) to store all bindings (associated with the bind adapter). The final binding operation is realized by NdisOpenAdapter function call, the function is declared as follows: VOID NdisOpenAdapter (OUT PNDIS_STATUS Status, OUT PNDIS_STATUS OpenErrorStatus, OUT PNDIS_HANDLE NdisBindingHandle, OUT PUNIT SelectedMediumIndex, IN PNDIS_MEDIUM MediumArray, IN UINT MediumArraySize, IN NDIS_HANDLE NdisProtocolHandle, IN NDIS_HANDLE ProtocolBindingContext , In pndis_string adaptername, in uint openOptions, in pstring addressingInformation; the intermediate layer driver passed the handle representing the binding-related environment area (allocated and initialized) in ProtocolBindingContext. NDIS will return to the environment to the intermediate layer driver in the future with the binding-related call. For example, in the call to the Protocol (CO) Receive or Protocol (CO) Status function. Similarly, when the NDisopenadapter call returns, NDIS will pass the NDisProtocolHandle handle to the intermediate layer driver. The driver must save the handle, typically saved in the binding-related environment area, in the future related to the binding, the intermediate layer driver will transmit the handle to NDIS, such as NDissend or NDIS (CO) SendPackets function call. ProtocolBindAdapter can also pass the supported media type through MediumArray. If the NDisopenadapter function call is successful, the low-level NIC driver will select a media type he supports and returns its index from the media selected from the MediumRray by SelectedMediumHandle. ProtocolBindAdapter can successfully call the returned value before passing the NDisregisterProtocol function before passing NDisProtocolHandle. If Ndisopenadapter returns an error, the intermediate layer driver should be recovered to bind the memory space allocated by the relevant environment area and release all other resources assigned to the binding assignment.
Typically, ProtocolBindAdapter records any failed binding operation by calling NDisWriteErrorLoGentry. 2.5.2 Micro Port (MiniPort) initialization
When the low-level NIC is successfully opened and the request and send data are received on the virtual NIC or NIC, ProtocolBindAdAdapter will make the NDISIMINTIALIZEVICEINSTANCE once or multiple calls to request an initialization operation of one or more network cards. NdisimintializedEviceInstance Call the MINIPORTINIALIALIZE function of the intermediate layer driver executes the initialization of the specified network card. When the MiniPortInitialize function returns, the upper NDIS driver can perform the binding operation of the virtual NIC (S) of the intermediate layer driver. The MiniPortInitialize function must assign and initialize the virtual NIC-related environmental area. As part of the initialization operation, MiniPortInitialize must call NDismSetAttributeEx functions with the corresponding environment handle, and NDIS will pass the environment handle in the MINIPORTXX function call. MiniPortInitialize must also set the NDIS_ATTRIBUTE_INTERMEDITE_DIS_ATTRIBUTE_INTERMEDIATE_DISMER tag in the AttributeFlags parameter (will be passed to the NDismSetAttributeEx function). The intermediate layer driver identifies the NDIS driver type by setting the NDIS_ATTRIBUTE_INTERMEDIATE_DRIVER tag. Further, if, when sending the intermediate layer driver queue and request operation timed out, do not want to NDIS calls MiniportCheckForHang (or MiniportReset) function, then MiniportInitialize must AttributeFlags parameters (will be passed to NdisMSetAttributeEx function) in NDIS_ATTRIBUTE_IGNORE_PACKET_TIMEOUT and NDIS_ATTRIBUTE_IGNORE_REQUEST_TIMEOUT markers Set. NDIS will be notified by setting the timeout tag to handle the virtual NIC timeout operation by the intermediate layer driver. Because the intermediate layer driver does not manipulate the low-layer NIC, it cannot control how long it does not perform untreated send and request operations, and the driver usually does not provide the MiniPortCheckForhang function or does not process virtual NIC times. However, if the intermediate layer driver has registered the entry point of the CheckforhangHandler handle, and no NDIS is not requested to ignore the packet and request timeout, there is no overall interval, then by default, the MiniPortCheckForhang function will be performed every two seconds. One call. If the MiniPortCheckForhang function returns true, the driver will call the MiniPortreset function. If the driver supports the MiniPortCheckForhang function, you can clearly specify a different timeinseconds value by calling the NDISMSetAttributeEx function, changing the default two second call intervals. The intermediate layer driver must be operated as a non-serial driver, and the NDIS_ATTRIBUTE_DSERIALIZE tag will be delivered by setting the NDIS_ATTRIBUTE_DSERIALIZE tag to be passed to the NDISMSetAttributeEx function. Non-serial drivers serialize the operation of the MiniPortxxx function and queued inside all of the introduced sending packets instead of relying on NDIS to save the send queue. The intermediate layer driver must also set the NDIS_ATTRIBUTE_NO_HALT_SUSPEND tag in the AttributeFlags parameter (will be passed to the NDismSetaTRibuteEx function) to prevent NDIS to interrupt the driver before the low-level micro-port transition to the low power state. The intermediate layer driver must ensure that the status information held is fully initialized.
If the intermediate layer driver requests sending related resources (such as MiniPortSend or MiniPortsendPackets will have a width of the packets sent by the neighboring low-layer, if the NdisimInitializedEviceInstance is called, ProtocolBindadapter has not allocated the packet pool, and allocated the packet pool. . 2.5.3 Intermediate Layer Driver Query and Setup Operation
When it is successfully binding to the low-layer NIC and complete the initialization operation of the virtual NIC (S), the intermediate layer driver can query the operational characteristics of the low-layer NIC driver, set its internal state, or negotiate some parameters (such as low-level NIC drive) The program reserved buffer size, etc.). The lower boundary is not connected to the intermediate layer driver implemented this function by calling the NDisRequest, and the lower boundary facing the intermediate layer driver implemented this function by calling the NDIS (CO) Request function. The intermediate layer driver can also receive query and setup requests from the MiniPortQueryInformation function from the protocol driver, which either responds to these requests to pass these requests to the low-level driver. In the "NetWork Drivers Reference" in the online DDK, all universal, connected, non-media related OIDs, and media-related OID, and media-related OIDs are included. Next, several standards and commonly used general classification OIDs will be discussed, facing the OID and some media related OIDs. 2.5.3.1 Publishing settings and query requests typically, the lower boundary facing the unconnected intermediate layer driver By publishing an OID_GEN_MAXIMUM_FRAME_SIZE request, query the maximum length supported by the low-layer NIC driver, which does not include the length of the frame head portion. The lower boundary is a non-connected intermediate layer driver to request the OID_GEN_MAXIMUM_TOTAL_SIZE request, query binding to determine the maximum packet that the NIC can accept by the low-level NIC driver, and the intermediate layer driver must set the sending packet to make it Meet this dimensional requirements. If the upper driver sends a packet that can support the size of the NIC driver (intermediate layer driver), an error will occur. The lower boundary facing the connectionless intermediate layer driver can request the OID_GEN_CURRENT_LOOKAHEAD request to query the size of the front-wide data buffer. If the intermediate layer driver submits this query request, NDIS returns the latest front view buffer size for a given binding of the low-level NIC driver. If the intermediate layer driver performs a corresponding setup request, it will indicate the proposed front-view buffer size, but the intermediate layer driver does not guarantee that the low-level NIC driver can set the front view buffer in accordance with the indicated size. The lower boundary is a connected intermediate layer driver with an OID_GEN_LINK_SPEED request, query the link rate of the low-layer NIC driver, and modifies the internal timeout settings of the returned value using the request. The lower boundary facing the intermediate layer driver requests the link rate of the low-layer NIC driver with an OID_GEN_CO_LINK_SPEED request, and can be requested with an OID_GEN_CO_LINK_SPEED request to set the low-layer NIC driver's link rate. If the intermediate layer driver is bound to the WAN NIC driver, the link rate can be determined until a link indication is received (indicating the local node and the remote node connection). For a description of link instructions, see the "Indication of WAN Timple Diffift Drivers" in Chapter 8 of the Section 8. The intermediate layer driver must also determine the setting of the operational characteristics of the low-level NIC driver. Under the lower boundary, the lower boundary is unconnected to implement this function with an OID_GEN_MAC_OPTIONS request, and the lower boundary is connected to the connected intermediate layer driver to implement it with an OID_GEN_CO_MAC_OPTIONS request. This feature. The lower boundary is not connected to the intermediate layer driver, which is usually published is an OID_GEN_MAXIMUM_SEND_PACKETS query (especially in the intermediate layer driver exports the MiniPortSendPackets function), the driver can pass the upper layer when checking the OID_GEN_MAXIMUM_SEND_PACKETS in response to the high-level driver. The return value of the query.
Intermediate driver can also query the current address of the associated media by the media related the OID, for example, the lower boundary for the intermediate drivers connectionless posting OID_WAN_CURRENT_ADDRESS, OID_802_3_CURRENT_ADDRESS, OID_802_5_CURRENT_ADDRESS or OID_FDDI_LONG_CURRENT_ADDRESS query, intermediate driver lower boundary for connection may OID_ATM_WAN_CURRENT_ADDRESS query. If necessary, the intermediate layer driver can publish a setting request to notify NDIS information about its operational characteristics. The lower boundary is a non-connected intermediate layer driver to invoke the NDisRequest function with OID_GEN_PROTOCOL_OPTIONS to implement this function, and the lower boundary facing the intermediate layer driver to call NDisRequest to implement this function with OID_GEN_CO_PROTOCOL_OPTIONS. The intermediate layer driver that is bound to the NIC that supports the WAN must also complete the following setup information request: Use the OID_WAN_PROTOCOL_TYPE request to inform the low-level NIC driver's protocol type, which is provided in the form of single-byte network layer protocol identifier; OID_WAN_HEADER_FORMAT request, notify the low-level NIC driver to send the head format of the packet. 2.5.3.2 Response Settings and Query Request Because the NDIS intermediate layer driver can be bound by a high-level NDIS driver, it can also receive query and setting requests for the MiniPortQueryInformation and MiniPortsetInformation function. In some cases, the role of the intermediate layer driver is only to transmit these requests to the low-layer driver. In addition, when these requests are about their media derived in the upper boundary, they can also respond to these queries and settings. Note that the intermediate layer driver must receive it from the upper NDIS driver to pass the OID_PNP_xxx request to the low-level MiniPort driver. Typically, the general OID received by the intermediate layer driver is similar or even identical to the OID submitted to the low-layer NIC driver, and the media related OID received by the intermediate layer driver will be the medium desired by the high-level driver. Types of.
2.5.4 As an intermediate layer driver for connection client
The lower boundary facing intermediate layer driver must be registered as a connection client. Connecting a client using a Call Manager or a Call-Setup and a TEAR-DOWN service for a Call-Setup and a Tear-Down service, you can also use the connection-oriented micro-port or MCM reception. And send functions to send and receive data operations. For more information on connecting communication, please refer to Chapter 4 of the first section. When the call manager or MCM calls NDIS (M) CmregisteraddressFamily registered address family from the ProtocolBindAdapter function, NDIS calls the ProtocolcoregisterafNotify function of all protocol drivers on the binding. If the ProtocolcoreGisterAfNotify function is called when the protocol is registered, NDIS calls the ProtocolcoreGisterAfNotify function of the intermediate layer driver. If the ProtocolcoregisterafNotify function determines that the intermediate layer driver can use the call manager or MCM (registered address family) service, it will assign the corresponding environmental area for each AF of the customer and call the NDisClopenaddressFamily function to register a set of functions provided by a group of customers. NdisClOpenAddressFamily defined as follows: NDIS_STATUSNdisClOpenAddressFamily (IN NDIS_HANDLE NdisBindingHandle, IN PCO_ADDRESS_FAMILY AddressFamily, IN NDIS_HANDLE ProtocolAfContext, IN PNDIS_CLIENT_CHARACTERISTICS ClCharacteristics, IN UINT SizeOfClCharactertistics, OUT PNDIS_HANDLE NdisAfHandle); before calling NdisClOpenAddressFamily, intermediate driver must perform the following operations: PNDIS_CLIENT_CHARACTERISTICS type ClCharacteristics The structure is zero, the latest version of this structure is 5.0; the address of the Protocolxxx client function supported by the driver is stored. The return value of the call NDisafhandle is opaque to the intermediate layer driver, and the intermediate layer driver must save the handle and passed to NDIS as parameters in the protocol part of the intermediate layer driver. For example, registering the NDisClRegistersap function call for SAP. The intermediate layer driver must use NDisClopenaddressFamily registered client functions: Clcreatevchandler Sets the entry point of the ProtocolcOcReatevc function of the call. CLDeletevchandler Sets the entry point of the Protocolcodeletevc function of the call. ClRequestHandler Set the entry point of the ProtocolcoreQuest function of the call. ClRequestCompleteHandler Sets the entry point of the ProtocolcoreQuestComplete function of the call. ClopenaFCompleteHandler Sets the entry point of the ProtocolClopenaFComplete function of the call. ClcloseafCompleteHandler Sets the entry point of the ProtocolClCloseafComplete function of the call. ClregistersAppCompleteHandler Sets the entry point of the ProtocolClRegistersapComplete function of the call, and the client receives the call to the remote machine with this function. CLDEREGISTERSAPCompleteHandler Sets the entry point of the ProtocolCldeRegistersApComplete function of the call.
ClmakeCallCompleteHandler Sets the entry point of the ProtocolClmakeCallComplete function of the call, and the client uses the function to make a call for the remote machine. ClModifyCallQoScompleteHandler Set the entry point of the ProtocolClModifyCallQoScomplete function of the call, and the client uses this function to dynamically modify the established VC service quality, or use the function and call manager to establish QoS with this function and call manager when preparing a internal call. ClcloseCallCompleteHandler Sets the entry point of the ProtocolClCloseCallComplete function of the call. CladdPartyCompleteHandler sets the entry point of the ProtocolCladdPartyComplete function of the call, and the client uses this function to create a point-to-multi-point VCS for the wreath of the remote machine. CLDRoppartyCompleteHandler Sets the entry point of the ProtocolCldropPartyComplete function of the call. ClincomingCallHandler sets the entry point of the ProtocolClIncomingCall function of the call, and the client receives the call to the remote machine with this function. ClincomingCallQoSchangeHandler Sets the entry point of the ProtocolClinCallQoSchange function of the call, and the client receives the call from the remote machine, which can dynamically change the QoS on the remote machine. ClincomingCloseCallHandler Sets the entry point of the ProtocolClIncomingCloseCall function of the call. ClincomingDropPartyHandler Set the entry point of the ProtocolClinComingDropParty function of the call. ClcallConnectedHandler sets the entry point of the ProtocolClCallConnected function of the call, and the client receives the call of the remote machine with this function. Even if the intermediate layer driver does not support internal calls, an outgoing call or a "point-multipoint" connection, each CLXXX parameter member of the NDIS_CLEINT_CHARACTERISTISTICS structure must be set by the protocolcl / coxx function called for those intermediate layer drivers. The procedure is not supported by the connection function, the protocolcl / Coxx function will only simply return NDIS_STATUS_NOT_SUPPPPPORTED value. 2.6 Intermediate Layer Driver Packet Management
The intermediate layer driver receives the packet descriptor from the high-level driver and transmits on the network that is associated with one or more chain data buffers. The intermediate layer driver can repack the data and use the new packet descriptor to perform data transmission, or directly pass the packet to the low-level driver. If the driver is not connected, the NDISSEND or NDISSENDPACKETS function can be called. Complete this feature, if the driver is connected, you can call the ndiscosendpackets function to complete this feature. The intermediate layer driver can also perform some operations to change the contents of the chain buffer, or adjust the incoming data packet relative to the sequence or transmission timing of other transmission tasks. However, even if the intermediate layer driver is only transmitted to the lower layer, for example, only a new packet descriptor must be allocated, and some or all new package structures must be assigned. Each intermediate layer driver must assign its own package descriptor to replace the high-level packet descriptor. If the intermediate layer driver is to convert the packet from a format to another, it must allocate the buffer descriptor to map the buffer for copying the transition data, which is allocated by the intermediate layer driver. If there is an OOB data associated with the copied package descriptor, then these data can be copied to a new OOB data block associated with the package descriptor (intermediate layer driver), the process is, first, use ndis_oob_data_from_packet macro to get OOB The pointer of the data area, then call NDISMOVEMEMORY to move its content into the OOB data area associated with the new package descriptor. The driver can also use NDIS_GET_PACKET_XXX or NDIS_SET_PACKET_XXX macros to read the related content from the OOB data area associated with the old package descriptor, and written to the OOB data area associated with the new package descriptor. The package descriptor assigns the following NDIS function: call ndisallocatepacketpool or ndisallocatepacketpool, assign a set of non-scalable pilot to fixed size package descriptors (specified by the call) and initialize a set of non-scalable pilot; call the ndisallocatepacket function, from NdisallocatePacketPool (EX) has been assigned The pool is distributed in the package descriptor; depending on the purpose of the intermediate layer driver, the driver can re-packed the buffer that introduces the packet descriptor connection. For example, the intermediate layer driver can allocate the packet buffer in the next case, repacking the introduction packet data: if the intermediate layer driver receives the data buffer received by the high-level protocol driver, a single buffer that can be transmitted than the low-layer medium The area is larger, then the intermediate layer driver must split the introduced data buffer into smaller data buffers that meet the low-level transmission requirements. The intermediate layer driver can change the length of the internal data packet by compressing or encrypting data before transfers the transmission task to the low-layer driver. NDIS function call the following buffer allocation requirements above: obtaining a buffer descriptor NdisAllocateBufferPool for dispensing handle; NdisAllocateMemoryWithTag allocated buffer with or NdisAllocateMemory; NdisAllocateBuffer allocation and provided with a buffer descriptor, the mapping assigned by NdisAllocateMemory (WithTag) The buffer and link to the package descriptor assigned by the NDisallocatePacket. The driver can link the buffer descriptor and the package descriptor by calling the NDischainBufferatback or NDischainBufferatFront function.
Call NDisAllocateMemory (WithTAG) The virtual address and buffer length will be passed to the NDisallocateBuffer function to initialize the buffer descriptor of the mapped. The package descriptor that meets the typical requirements can be allocated according to the requirements when the driver is initialized, or can be implemented via the ProtocolBindADAPTER function. If necessary or for performance, the intermediate layer driver developer can assign a certain number of package descriptors and buffers mapping by the buffer descriptor, which, copy intrinstron data for protocolRecEive (will To the high-level driver indication) The resources are allocated, and the transmitted packets that are introduced to the neighboring low-level drivers to the neighboring low-level drivers to the neighboring low driver. If the last buffer actual data length is smaller than the length of the buffer, the intermediate layer driver will call NdisadjustBufferLength than the length of the buffer, then the intermediate layer driver will call the buffer description. The actual length of the data is adjusted to the data. When the packet returns to the intermediate layer driver, the function should be called again to adjust its length to the actual size of the full buffer. The lower boundary facing the connectionless intermediate layer driver can receive intrinsic data from the low-level NIC driver by the ProtocolReceivePacket function, which is specified by the NDIS_PACKET type package descriptor, and can also indicate the intrinsic data Give the ProtocolReceive function and copy the data to the packet provided by the intermediate layer driver. The lower boundary facing the intermediate layer driver always uses the ProtocolcoreCePacket function, receives data from the low-level NIC driver as a complete packet. In the following case, the intermediate layer driver can maintain the ownership of the received data packet: When the bottom boundary is not connected to the protocolreceivepacket function, when the protocolreceivepacket function indicates the full packet; the current boundary is the connected intermediate layer driver to the protocolcorecepect function indication When the packet is packet, the Status member of NDIS_PACKET_OOB_DATA is set to any value other than NDIS_STATUS_RESOURES. In these cases, the intermediate layer driver can maintain the ownership of the package descriptor and the resources thereof, until the received data is processed, and call the NDISRETURNPACKETS function to return these resources to the low-level driver. If the ProtocolReceivePacket passes the resource it receives to the high-level driver, then at least the packet descriptor that has been assigned by the intermediate layer driver should be used instead of the introduction package descriptor. Based on the purpose of the intermediate layer driver, there will be several different package management strategies when it receives a complete packet from the low-level driver. For example, the following is a possible package management policy: copy the buffer content into the buffer allocated by the intermediate layer driver, the buffer is mapped and linked to a new package descriptor, returning the input package to the low-level driver Descriptor, then you can indicate a new packet to the high-level driver; create a new package descriptor, link the buffer (associated with the indicated package descriptor) to the new package descriptor, then put the new package descriptor Indicates to the high-level driver. When the high-level driver returns the package descriptor, the intermediate layer driver must remove the link between the buffer and the package descriptor, and link these buffers to the package descriptor that is initially received from the low-layer driver, and finally drivers the low-layer driver. Returns the original package descriptor and the resources they described. Even if the lower boundary is facing the connected intermediate layer driver, it also provides the ProtocolReceive function.
When the low-level driver does not release ownership of the resource indicated by the package descriptor, NDIS will call the ProtocolReceive function. When such cases occur, the intermediate layer driver must copy the received data into its own buffer. If the intermediate layer driver also indicates the external data, the ProtocolReceive function can call NDisGETRECEIVEPACKET with NDIS_GET_ORIGINAL_PACKET to get the received data that receives the associated data. For the intermediate layer driver for the lower boundary, when the low-level driver does not release the ownership of the resource indicated by the package descriptor, set the status member of the packet NDIS_PACKET_OOB_DATA to NDIS_STATUS_RESOURCES, and the driver's protocolcoreceptivePacket function must be received. Data is copied into their buffer. 2.6.1.1 Reusing Packets Before, Ndissend returns the NDIS_STATUS_SUCCESS status flag for the packet descriptor (intermediate layer driver), not to return the package descriptor to the ProtocolsendComplete function, which is the data allocated by the intermediate layer driver The package is returned to the MiniPortReturnPacket function. The ownership of the package descriptor and the resources described are returned to the intermediate layer driver. If the high-level driver provides a buffer (chain to the returning package descriptor), the intermediate layer driver should accurately return to these resources to the driver of the allocated resource. If the intermediate layer driver is initially assigned a buffer with a package descriptor and a link, it can reclaim these resources and can use these resources during the next transmission and data reception. For the intermediate driver, the link buffer descriptor and buffer of any intermediate layer driver allocation is reused by reinocating, reinitial, reinitial, reinitial and reuse the package descriptor, re-allocate and reuse it. District will be a more effective way. The intermediate layer driver reinitializes the packet descriptor by calling the NdisreInitializePacket function, however, the intermediate layer driver must first determine that all link buffers and buffer descriptors have been called NDISUNCHAINBUFFERATXXX. Because NdisreInitializePacket will clear a member to the buffer chain, if there is no predecessor or store the chain buffer, the call will cause memory leakage. Similarly, if the OOB data is included in the MediasPecificInformation associated with the package descriptor, the memory must be recovered before reinitializing the package descriptor. 2.7 Limitations of intermediate layer drivers
The intermediate layer driver must have sequentially executed in order: When the middle layer driver is called NDISMSetAttributex when the intermediate layer driver calls NDISMSetAttributex, the NDIS_ATTRIBUTE_INTERMEDIATE_DIVER ID will only be used only by the current Value identification intermediate layer driver type and takes certain measures to ensure that the extension operation does not cause a deadlock, such as transmitting internal send queue data packets to the intermediate layer driver. The intermediate layer driver should at least use the new packet descriptor assigned by it instead of the incubated packet descriptor, regardless of whether the packet is transmitted to the low-layer driver, or transmit it to the high-level driver to receive. Thereafter, the original package descriptor must also be used to replace its own package descriptor (initially associated with packets passed to the intermediate layer driver), for example, when a transmission or completion of a reception indication is completed. In addition, the intermediate layer driver must also return a resource borrowed from a high-level or low-layer driver by returning a package descriptor and its specified resource. In particular, the intermediate layer driver must follow the next guidelines, which apply to all non-serial micrograph drivers: if all internal resources of the driver are shared by the intermediate layer driver send functions and other miniPortxxx functions, then This resource must be protected by self-rotational lock, including MiniPortsend or MiniPortsendPackets, and other MiniPortxxx functions, unique exceptions are the MiniporreSet function, which is serialized by NDIS. For non-serial micro-port drivers, the intermediate layer driver organizes the shared resources of each bound environment area (only self-rotational lock protection) to discrete dedicated receiving area, dedicated sector, and shared areas, which is relative to Over-Protecting drivers that distributes unregistered transmission, reception, and sharing variables will be able to achieve better performance. 2.8 Intermediate Layer Driver Receive Data
This section will discuss how the lower boundary is not connected and the intermediate layer driver for the lower boundary facing the connection is received.
2.8.1 Receive data from the lower boundary facing intermediate layer driver
Low-level, unconnected NIC driver, can indicate the data packet by the following two ways: NIC driver calls non-filtered related ndismindicateRerecePacket, transfer the pointer to the pointer array of packet descriptors, transfer the indicated package resources to the high-level driver transfer ownership. When the high-level driver processes the corresponding data, returns the NIC driver to those package descriptors and the resources they point to. The NIC driver calls the filter-related NDISMXXIIDicateReceive function to pass the size value of the front view buffer pointer and packet. The lower boundary is not a connected intermediate layer driver to provide a ProtocolReceive function, in addition, it can also include the ProtocolReceivePacket function, depending on its specific operating environment. The ProtocolReceive function must be provided for the lower boundary to unconnected intermediate layer drivers. This function passes the front view buffer pointer. If the packet is considered to be required after the unconnected intermediate layer driver, it is necessary to copy the data to allocated packets, the data package The high-level driver will be indicated. If the front view buffer size is less than the received packet size, the intermediate layer driver must first call NDistransferData to copy the rest of the data packet in the ProtocolReceive environment. In order to make ProtocolReceive execution as fast as possible, the intermediate layer driver should be a pressed package descriptor, buffer, and buffer descriptor for this purpose. ProtocolReceive is usually called because the low-level driver calls the NDismxxIndicateReceive function, however, when the low-level NIC driver is used with the NDISMISMindicateRecePacket function indicates that the NDIS_STATUS_RESOUCES is set to NDIS_STATUS_RESOUCES, then ProtocolReceive can also Call. Because the packets indicated by NDISMindicateRecePacket are passed to the ProtocolReceive function, the size of the front view buffer is always equal to the size of the packet, so the intermediate layer driver does not adjust the NDISTRANSFERDATA to perform the size of the package. However, if the low-level NIC driver also indicates OOB data, the intermediate layer driver must call ndisgetRecEference to the parameter in the ProtocolReceive processing to call NDisgetRecEferencePacket to find this information. The ProtocolReceivePacket function is optional for the lower boundary facing intermediate layer driver. ProtocolReceivePacket receives a package descriptor pointer describing the full network packet. If the low-level NIC is a DMA bus control device, the driver must also call non-filtered NDISMISMISMISMISMISMISMIECEVEVEPACKET functions indicate the receiving packet, and if the driver is bound to the low-level NIC driver, then the intermediate layer driver should Provide the ProtocolReceivePacket function. In addition, low-level NIC drivers that support OOB data In most cases, the packet descriptor will be transmitted to the NDISMindicateRecePacket function in the receiving data to enable the intermediate layer driver to access the OOB data associated with the descriptor. ProtocolReceivePacket checks the packet if it thinks that the package is required, then it keeps the ownership of the packet by returning a non-zero value. If a non-zero value is returned, the intermediate layer driver will then call NDisReturnPackets as the package descriptor pointer, and for a specific package descriptor, the number of times the function is called should be returned when the reception indication is returned. The number of non-zero values is equal.
After the middle layer driver is called NdisreturnPackets in the specified number of times, the ownership and related buffers that initially indicate the receiving data, the intermediate layer driver should be invoked as quickly as possible to call the NDisReturnPackets function. . On the other hand, if the intermediate layer driver returns zero value from NDISRETURNPACKETS, this means that the packets and related resources will be released immediately. For example, if the intermediate layer driver replicates indicating data to its own buffer, the corresponding processing of data is performed inside the previously driver, this situation will happen.
2.8.1.1 Implementing the ProtocolReceivePacket handler in the Intermediate Layer Driver When the low-level NIC driver indicates a packet array of OOB data by calling the ndismindicateRerecePacket function, NDIS usually calls the intermediate layer driver in each package descriptor. Function, and allow the intermediate layer driver to hold the resource specified by the intermediate layer driver to keep the package descriptor and processes the data. The two types of typical NIC drivers that call the NDISMISMISMISMIECEVEPACKET function with the population array are as follows: Manage the NIC driver capable of receiving a plurality of network packets to the buffer to control the adapter; in the NDIS_PACKET_OOB_DATA data block related to the package descriptor To the high-level driver, providing a NIC driver (such as package priority, etc.) containing media related information. Of course, these drivers are not necessarily the driver of the DMA bus control device. If the intermediate layer driver is bound to the NIC driver, it is as mentioned earlier, then it should provide the ProtocolReceivePacket function. This allows the driver to complete the following operation: In each reception instruction, receive a full packet; call the NDIS macro, read the OOB data related to the package descriptor, not call NDisGetRecEVePacket and NDIS_GET_ORIGINAL_PACKET to receive and copy data; keep it The ownership of the intrinsic packet descriptor, and through these packet descriptors, the buffer data is read directly, and then, in the processing of each package descriptor, multiple copies of the data may be made to the client program; There is also other possible package descriptors through the NdisReturnPackets function returns the package descriptor and the resources thereof. Even if the intermediate layer driver provides the ProtocolReceivePacket handler, the NIC driver's call to the NDISMISMISMISMISMICEVEPACKET function may also cause call to the intermediate layer driver ProtocolRecEVE function. When the NIC driver calls NDISMindicateReceivePacket temporarily releases the ownership of the driver allocated resource, it will depend on these package users to call NDisReturnPackets to return to the low-level driver to the low-level driver. In other words, the NIC driver can open the receiving resource operation, such as receiving buffer space in the NIC. The NIC driver is written to the NDIS_STATUSURES status identity by writing the NDIS_STATUS_Resources status identifier by associating the OOB block (associated with the package descriptor passing to the packet descriptor that is transmitted). Advised other packages call the high-level driver's ProtocolReceive function, which will force the intermediate layer driver to copy the package data instead of the ownership of the package. If the intermediate layer driver wants to obtain OOB data associated with the PROTOCOLRECEVE function, it must call NDisGETRECEIVEPACKET with ndis_get_original_packet, copy specific media information to the buffer assigned by the intermediate layer driver, and if the low layer The NIC driver provides a timestamp, then TimeSent and TimeReceived information must also be copied. 2.8.1.2 Implementing the ProtocolReceive handler in the Intermediate Layer Driver If the NDismxxxIndicate function is called, the driver will always call the ProtocolReceive function to process the received packet.
If the intermediate layer driver accepts the packet, ProtocolReceive must call NDISTRANSFERDATA functions as a package descriptor, copy the rest of the front view buffer and the buffer to the intermediate layer driver has allocated. NDISTRANSFERDATA must call in the ProtocolReceive environment, and can only call it. The intermediate layer driver should set a chain buffer package descriptor with sufficient size to save all received data. When NDISTRANSFERDATA returns, the data received from the low-level NIC driver will not be useful. If the data transmitted to ProtocolReceive is indicated by calling NDismxxIndicateReceive, the front-view buffer size transmitted to the ProtocolReceive function will not exceed the value returned by NdisRequest with OID_GEN_CURRENT_LOOKAHEAD. For the intermediate layer driver, the data in all front view buffers is read-only. If the call to the ProtocolReceive function is due to the NDISMIISMINDECEVEVEPACKET, the lower NIC driver sets one or more of the packet status in the packet array to ndis_status_resources, then the size of the front view buffer will always be equal to the size of the entire network packet. So the intermediate layer driver will not have to call the NDISTRANSFERDATA function. The ProtocolReceive function must return to the resource control as quickly as possible, so ensure that the available package descriptors, buffers, and buffer descriptors are available before the intermediate layer driver receives the reception indication. If the intermediate layer driver checks the front view data, it is considered that the package is not the one to be copied, the driver should return ndis_status_not_accept identity. When the receiving package is copied, the ProtocolReceive function cannot process reception data, as this will seriously affect system performance and the ability of the low-level NIC from the network to receive internal data packets. Alternatively, the intermediate layer driver processes the received packet in the subsequent ProtocolReceiveComplete function, which is then called when the data package is later processed. Typically, the above operation will occur when the low-level NIC driver has indicated all packets determined by the NIC driver or before the DPC layer receives the handle. The intermediate layer driver must queue the PROTOCOLRECEVE replicated packets to make the ProtocolReceiveComplete function over process.
2.8.1.3 Lower Boundary Disabled Intermediate Layer Driver Receives OOB Data Information If the received network packet is indicated to the ProtocolReceive function, the driver must copy the received data to the buffer provided by the intermediate layer driver. If the package descriptor related packet OOB data contains specific media information and / or timestamp information, the intermediate layer driver will call NDisgetRecEVePacket and NDIS_GET_ORIGINAL_PACKET to get media information and TimeSent and TimeReceived timestamps (if the low-rise NIC driver provides those information). If the receiving packet is passed to the ProtocolReceivePacket function, the intermediate layer driver must be used in the following manner to save the OOB data information associated with the package: read the media related information with NDIS_GET_MEDIA_SPECIFIC_INFO, write media related information with ndis_set_media_specific_info; use ndis_get_time_sent Read the TimeSent information, write TimeSent information with ndis_set_time_to_send; read TimeReceived information with ndis_get_time_received. The TimeSent timestamp is the time of the remote node NIC sends a packet, if possible, it will be obtained and saved by the low-level NIC driver. The TimeReceiveD timestamp is the time in which the intrinsic packet is received by the low-level NIC driver. 2.8.2 Receiving data for intermediate layer drivers on the next boundary
Connected NIC drivers pass the NDISMindicateRecePacket to indicate the packet, pass the pointer to the pointer of the pointer to the packet descriptor. If the intermediate layer driver is based on the NIC driver, NDIS will then call the ProtocolcorecePacket function of the intermediate layer driver. ProtocolReceivePacket receives a package descriptor pointer describing the full network packet. ProtocolReceivePacket Checks the packet, if it is considered that the package is required, the ownership of the packet will be maintained by returning a non-zero value. If the non-zero value is returned to the package, the intermediate layer driver must call the NDISRETURNPACKETS function with the corresponding package descriptor pointer, and for a specific package descriptor, the number of times the function is called when protocolcorecepacket The number of non-zero values returned by the function. When the intermediate layer driver is called NdisreturnPackets at a specified number, the ownership and associated buffer that initially indicates the labeled comparisher of the received data, so that the intermediate layer driver should call the NDisReturnPackets function as quickly as possible for the corresponding processing. . On the other hand, if the intermediate layer driver returns zero value from NDISRETURNPACKETS, this means that the packets and related resources will be released immediately. For example, if the intermediate layer driver replicates indicating data to its own buffer, and the corresponding processing of data is performed inside the previously driver, the situation will happen.
2.8.2.1 Implementing the ProtocolcorecePacket handler in the Intermediate Layer Driver When the low-level NIC driver indicates that the NDISMCOISMCATERECEVEPACKET function indicates the packet population that may contain OOB data, NDIS calls the ProtocolcorecePacket function of the intermediate layer driver in each package descriptor. In order to obtain an OOB data block state of the associated package, ProtocolcoreceivePacket must call each package descriptor once a NDIS_GET_PACKET_STATUS macro. If the NIC driver is called before calling NDismCoIndicateReceVePacket, the OOB data block status associated with the packet descriptor is set to NDIS_ Status_suCcess, and the NIC driver will temporarily release the ownership of resources associated with the package descriptor. In this case, the NIC driver will rely on the user of these packets to return to some resources in time. In other words, the NIC driver can open the receiving resource operation, such as receiving buffer space in the NIC. When these resources are running, the NIC driver writes NDIS_STATUS_RESOURES identity to the OOB data block associated with the package descriptor, which indicates that the PROTOCOLCORECEPACKET function of the intermediate layer driver immediately copies the package data, not to keep NIC drivers. The package resource allocated by the program. In this case, ProtocolcoreceivePacket must return zero. If the low-level NIC driver does not set an OOB data block (associated with the package descriptor in the packet of the NDISMCoIndicateReceptivePacket), the intermediate layer driver will be allowed to keep the package descriptor and its designated resources. Intermediate layer drivers, high-level protocols, and high-level protocols handle data and return to the package descriptor. 2.8.2.2 Receiving an OOB Data Information Interlayer Driver in the Lower Boundary Connected Intermediate Layer Driver You must save the OOB data information associated with the package with the NDIS macros by NDIS_GET_MEDIA_SPECIFIC_INFO to read media related information with ndis_set_media_specific_info. Media related information; read TimeSent information with ndis_get_time_sent, write TimeSent information with ndis_set_time_to_send; read TimeReceiveD information with ndis_get_time_received. The TimeSent timestamp is the time of the remote node NIC sends a packet, if possible, it will be obtained and saved by the low-level NIC driver. The TimeReceiveD timestamp is the time that the imported packet is received by the low-level NIC driver.
2.8.3 Receiving a data packet to the high-level driver
The connected intermediate layer driver is processed completely received data (which may have been converted into the format required by the high-level driver, and the related data has been copied to the buffer of the package descriptor assigned to the intermediate layer driver. After that, you can indicate the data packet to the adjacent high-level driver by calling the NDISMISMISMINDECEVEPACKET, even if the micro port of the intermediate layer driver is unconnected.
2.9 Transport packets via an intermediate layer driver
In Section 2.3.1, the intermediate layer driver must provide the MiniPortsendPackets function and register with the NDisimRegisterLayeredminIPort function. If the intermediate layer driver is between two NDIS drivers that support multiple packages, the MiniPortSendPackets function can import packet array forwarders. If the border under the driver is unconnected, the forwarding is forwarded by calling the NDISsendPackets; if the border of the driver is connected, the forwarding is forwarded by calling NDisCosndPackets. If the driver is located at a transmitter that can only send a packet with Ndissend, the MiniPortsendPackets function can be transmitted with NDissend or NDIS (CO) SendPackets (there is no negative impact on system performance). The above intermediate driver does not become a bottleneck of performance. If the intermediate layer driver is located to send a package to the MINIPORTSENDPACKETS, the micro-port of the package can only be handled between the micro ports of a package, and the MiniPortsendPackets can be transmitted to the received packet array with NDissendPackets. Ndis first queues the packets in the array, and then when the micro-port can accept the send request, send the packet separately to the miniPortsend function of the low-level micro-port, of course, these operations are transparent to the intermediate layer driver of. Because the call to MiniPortxxx is managed by NDIS, synchronization is guaranteed, so when the high-level driver is generated by the forwarding request of the low-level driver, it is not necessary to make NdisImxxx calls as described in Section 2.5. As the minimum code, you must use the intermediate layer driver's own package descriptor instead of each internal package descriptor. The driver must keep the original descriptor (and link buffer) of the high-level driver. If they are copied to a new buffer, the driver should return to the original package descriptor before the send is completed, returns the high-level driver. And the data buffer for the package. For more information on how to assign package resources, copy information from a package to another package, see 2.5. MiniPortSendPackets receives an array of package descriptor in order, which is determined by NDISSENDPACKETS. In most cases, the intermediate layer driver should maintain the order of the packet descriptor, and the intermediate layer driver is maintained in the middle of the package descriptor. The order of this introduction package arbitrarily can be rearranged when increasing out-of-band information. When passing the packet array to the NDISsendPackets, NDIS will keep the order of the package descriptor pointer. The low-level NIC driver assumes that the packet pointer array hidden package transmitted to the MINIPORTSENDPACKETS function will be sent in the same order. The lower boundary facing the connectionless intermediate layer driver can call NDissend to transfer a single packet with a package descriptor pointer, or by calling ndissendPackets and transmitting a pointer to the pointer arranging pointer to the pointer array of packet descriptors (driver has been assigned) to transmit a single Or multiple packets. The lower boundary facing the intermediate layer driver can transmit a single or multiple packets by calling NDisCOSendPackets and delivering a pointer to the packet descriptor pointer array. Typically, the lower boundary is a unconnected intermediate layer driver developer, which should be used based on the known feature of the driver's own requirements and low levels to the NIC driver, decide whether to use NDissend or the NDISsendPackets function.
The lower boundary facing the unconnected intermediate layer driver can call NDisRequest by NDISQUERYINFOMATION (ReQueryType Type) and OID_GEN_MAXIMUM_SEND_PACKETS to get the maximum number of packets that the low-level driver can accept can accept. If the low-level driver returns value '1' or NDIS_STATUS_NOT_SUPPORTED, then the intermediate layer driver can choose to use Ndissend instead of the NDISSendPackets function. If the low-level driver returns a value greater than '1', the use of the NDISsendPackets function will make the performance of the two drivers better when sending the package array. If the low level returns a value larger than the connected NIC driver, the lower boundary is also available for the MINIPORTSENDPACKETS function that the lower boundary is not connected. In addition, the intermediate layer driver should be in response to the value of the size of the low-level NIC driver to respond to OID_GEN_MAXIMUM_SEND_PACKETS queries. If the OOB data is passed between the intermediate layer driver and the NIC driver, both send functions may be called because in any case, the low-level driver can use the macro read descriptor provided by NDIS. OOB data. If the intermediate layer driver sends a packet exceeding the low-level NIC driver internal resource tolerance: Non-serial or connected NIC driver will queue over its internal queue to the overloaded packet, when the condition is allowed Send them; serial NIC drivers can queurate over the internal queue to the internal queue, and you can return to an over-package with the NDIS_STATUS_RESOURCE state when the condition is allowed. In the latter case, NDIS will save those packets in the internal queue and re-submit these packets when the NDismsendResourceAvailable or NDISMSendComplete next time, the NIC driver. When the next boundary is not connected, the NDISSEND function is called from MiniPortSend, and all the resources of the package descriptor will be transferred in synchronous or asynchronous mode (until the transmission operation is completed). If the status returned by ndissend is not ndis_status_pending, the call is completed in synchronous mode, and the ownership of the NDISSend returns the time package resource will be returned to the intermediate layer driver. The intermediate layer driver should return all high-level drivers allocation to send resources and transmit NDissend calls as the return state of MiniPortSend. If the status returned by ndissend is ndis_status_pending, when the sending operation is complete, the final state of the send operation and the package descriptor will return to ProtocolsendComplete. The intermediate layer driver should call NDissendComplete from the ProtocolsendComplete function to transfer the transmission status to adjacent high-level drivers. When the bottom boundary is not connected, when sending one or more packets to NdissendPackets, or when the intermediate layer driver for the lower boundary is sent by calling NDisCosndPackets, the transmission operation is asynchronous. . Until each package descriptor and the final state sent by the package return to ProtocolCoSendComplete, the values release ownership of these package descriptors. ProtocolcosendComplete must transmit the transmission status of each packet to the adjacent high-level driver as in the previous paragraph. As a conclusion, if the intermediate layer driver sends a data packet in an array with NDISsendPackets, then when NDISSENDPACKETS returns, it cannot be used to read the Status member of the associated OOB data block. The member is used by NDIS to track the process of sending requests in the conversion, which is variable.
The intermediate layer driver can only obtain the status of the transfer request by checking the Status parameters transmitted to the Protocol (CO) SendComplete function. If the intermediate layer driver requests the packet transmission from the upper layer driver before sending, the intermediate layer driver requests the packet transmission of different priority, then the highest priority data is placed in the start position of the array. When these data packages are passed to the MiniPortsend or MiniPort (CO) SendPackets function of the low-level NIC driver, NDIS will remain in this order, even internally to queue some packets. For each NDIS (CO) SendPackets, NDIS will maintain this order. NDIS will never try to queue or check the OOB blocks associated with the package descriptor. Unless the intermediate layer driver has a special understanding of the NIC driver processing package priority, it should be assumed that the NIC driver sequentially sequentially transmits the data packet in the sequence of received, and the order of reception is held. The structure of the private member of the NDIS_PACKET Type Descriptor is opaque to the intermediate layer driver, and allows the macro or function provided by NDIS to read access, in some cases, can also be written. For example, the intermediate layer driver can invoke the NDISS private portion of the NDISSETPACKETFLAGS setting descriptor. These identities are not defined by NDIS, but the protocol and the low-level NIC driver cooperation are defined. 2.9.1 Transfer Media Related Information
The intermediate layer driver can transmit more media related information by an OOB data block associated with each NDIS_PACKET descriptor. The following are definitions OOB data block: typedef struct _ NDIS_PACKET_OOB_DATA {union {ULONGLONG TimeToSend; ULONGLONG TimeSend;}; ULONGLONG TimeReceived; UINT HeaderSize; UINT SizeMediaSpecificInfo; PVOID MediaSpecificInformation; NDIS_STATUS Status;} NDIS_PACKET_OOB_DATA, * PNDIS_PACKET_OOB_DATA; single record buffer. MediaSpecificInformation structure is defined as follows: typedef struct MediaSpecificInformation {UINT NextEntryOffset; NDIS_CLASS_ID ClassId; UINT Size; UCHAR ClassInformation [1];} MEDIA_SPECIFIC_INFORMATION; ClassId NDIS members are defined enumerations (ClassInformation type of information found in [1]). Currently, four Class IDs supporting the media in Microsoft operating systems for Win32: ndisclass802_3priority, ndisclasswirelesswanmbxmailbox, ndisclassirdapacketinfo, and NDisclassatmaalInfo. For more detailed information, please refer to Online "The Network Drivers Reference". If the intermediate layer driver knows the low-level NIC driver that sends a packet to use OOB data, it can set the corresponding OOB structure member. For example, the intermediate layer driver can do the following: By using the ndis_set_packet_time_to_send macro setting TimeTosend member, request the packet to send at a specific time. This macro passes the request time in the system time unit. The driver can call the NdisgetCurrentSystemTime Get the system time and can be used to calculate the request to send time. You can use ndis_packet_set_media_specific_info macros to transfer media related information in the call buffer in MediaspecificInformation. For example, if the intermediate layer driver is bound to the low-level NIC requiring priority, the ClassID member of the MediaSpecificInformation structure can be set as ndisclass802_3priority, and pass the priority related information through the ClassInformation and the character size of the information. 2.10 Processing the PNP event and PM events of the intermediate layer driver
The intermediate layer driver must be able to handle Plug Platform (PNP) events and power management events (PMs). In particular: The intermediate layer driver must set an identity in the AttributeFlags parameter passing to NDISMSetAttributeEx, see Section 2.4.2; the micro-port portion of the intermediate layer driver must handle the OID_PNP_XXX request; the protocol part of the intermediate layer driver must transmit accurate OID_PNP_XXX Request to the low layer micro port. The micro-port portion of the intermediate layer driver must transmit a lower-layer micro-port response to the requested protocol driver; the protocol part of the intermediate layer driver must provide a ProtocolPNPEVENT handler.
2.10.1 Processing OID_PNP_XXX Query and Settings
The upper boundary of the intermediate layer driver must export the MiniPortQueryInformation function and the MiniPortsetInformation function. When the NDISRequest setting and query object information (OID_xxx) that bind to an intermediate layer driver exported, NDIS, NDIS, to call the MiniPortQueryInformation function to implement this function accordingly. NDIS can also call MiniportQueryInformation or MiniportQueryInformation for your own feature. The intermediate layer driver can use NDisRequest (if the boundary of the intermediate layer driver is unconnected) or NDiscorequest (if the boundary is connected under the intermediate layer driver is connected), or sets the OID_XXX saved by the low-layer micro-port. After binding to the low-level NIC, the intermediate layer driver should determine the power management capability of the low-level NIC by querying OID_PNP_CAPABILITIES. If the NIC is able to perform power management, the low-level micro-port returns NDIS_STATUS_SUCCESS to the OID_PNP_CAPABILITIES query. MiniPort can also set NIC wake-up capabilities. If the NIC does not have power management capabilities, the low-level micro-port returns ndis_status_not_supported to the OID_PNP_CAPABILITIES query. The intermediate layer driver handles the query and set the inserted 即 type object information saved on the boundary, depending on whether the low-level NIC has power management capabilities: OID_PNP_CAPAPABILITIES If the low-level NIC has power management capabilities, the intermediate layer driver is OID_PNP_CAPABILITIES The query must return NDIS_STATUS_SUCCESS. In the OID_PM_WAKE_UP_CAPAPABID_PM_WAKE_UP_CAPAPABILITIES structure returned by the OID, the intermediate layer driver must specify the power status of the NDISDEVICESTATEUNSPECIED for each wake-up function. This response indicates that the intermediate layer driver has power management capabilities but cannot wake up the system. If the low-level NIC does not have power management capabilities, the low-level micro-port returns to ndis_status_not_supported to the OID_PNP_CAPABILITIES query. OID_PNP_QUERY_POWER and OID_PNP_SET_POWER The middle layer driver returns NDIS_STATUS_SUCCESS for OID_PNP_QUERY_POWER queries and OID_PNP_SET_POWER settings. The intermediate layer driver cannot pass these OID requests to the low-level micro-port driver. Wake-up OIDs if the lower NIC has power management capabilities, intermediate driver to low-level micro-port transfer (call Ndis (Co) Request) following OID_PNP_XXX wake-up events: OID_PNP_ ENABLE_WAKE_UPOID_PNP_ ADD_WAKE_UP_PATTERNOID_PNP_ REMOVE_WAKE_UP_PATTERNOID_PNP_ WAKE_UP_PATTERN_LISTOID_PNP _WAKE_UP_ERROROID_PNP _WAKE_UP_OK intermediate driver must Transmit the low-level micro port to the response to these OIDs to the upper protocol driver. If the NIC does not have power management capabilities, the intermediate layer driver should return ndis_status_not_supported to these OID queries and settings. 2.10.2 Intermediate Layer Driver ProtocolPnPEVENT Handling
If the operating system issues a plug-and-play IRP or power management IRP, Ndis intercepts the IRP, NDIS, and then calls each bound intermediate layer driver and protocol driver to each bonded intermediate layer driver and protocol driver by calling the driver's protocolpnpevent handler. This event, NDIS transmits a pointer to the NET_PNP_EVENT structure of the PNP event or PM event indicated. Just as indicated by the Net_PNP_Event structure, there are six possible PNP and PM events: NetEventSetPower indicates the power supply setting request, which specifies to transition the NIC to a specific power state. The intermediate layer driver should always be successfully processed by returning NDIS_STATUS_SUCCESS. For more information on processing power settings, please refer to 2.9.3. NetEventQueryPower Indicates the power query request, which queries whether the NIC can transition to a specific power state. The intermediate layer driver should always be successfully processed by returning NDIS_STATUS_SUCCESS. The intermediate layer driver should always be able to successfully execute NetEventQueryPower. The system is not blocked to sleep state by causing NetEventQueryRemoveDevice failure. Note that NetEventQueryPower is always to call NetEventSetPower. NetEventSetPower calls for the current power status of the device are actually equivalent to revoking NetEventQueryPower. NetEventQueryRemoveDevice Indicates that the device deletes the query request, which is queried whether the NIC can delete the NIC without interruption. If the intermediate layer driver does not release the device (for example, because the device is being used), the NetEventQueryRemoveDevice operation must be made in a way that returns ndis_status_failure. NetEventCancelremoveDevice Indicates a cancellation device to delete an operation request, which cancels the NIC's delete operation. The intermediate layer driver should always be successfully processed by returning NDIS_STATUS_SUCCESS. NetEventReconfigure Indicates that the configuration of the network part has changed. For example, if the user changes the IP address of TCP / IP, NDIS indicates the event to the TCP / IP protocol to the TCP / IP protocol. The intermediate layer driver should always complete the event by returning NDIS_STATUS_SUCCESS. NetEventBindList indicates that the bind list is changed to the TDI customer. The bind list is a list of one or more devices exported by the transfer protocol, and the TDI customer can be bound to. NetEventBindComplete indicates that the intermediate layer driver has been bound to all NiCs that can be bound. Ndis does not indicate more NICs unless there is a plug-and-play NIC load system. The buffer member of NET_PNP_EVENT points to the buffer containing a specific information indicated. For more information, please refer to the online DDK "Network Drivers Reference". The intermediate layer driver can complete the protocolpnpevent call asynchronously in ndiscompletepnpevent. 2.10.3 Processing the prescribed power request
The intermediate layer driver handles the power supply setting request depends on whether the low-level NIC has power management capabilities.
2.10.3.1 Power Settings of Sleep Status Request NDIS Call the IM driver and the protocolpnpevent function of the protocol driver that binds to the virtual device (IM driver export). This call specifies NetEventSetPower as a sleep state (D1, D2, D3 network device power status). The bound protocol driver stops sends a packet to the intermediate layer driver and performs OID requests. The intermediate layer driver stops sends a packet and performs OID requests to the lower micro port. NDIS The micro-port (upper edge) of the intermediate layer driver (if the NIC supports power management, the low-layer NIC micro port) issues an OID_PNP_SET_POWER request. When the request is successfully completed, the intermediate layer driver and the low-level micro-port return ndis_status_success. The intermediate layer driver cannot pass the OID_PNP_SET_POWER request to the lower micro port. Normally, the intermediate layer driver does not clear the initialization of the virtual NIC. In particular, if the low-level NIC has power management capabilities and supports wake-up events, the intermediate layer driver cannot clear the initialization of virtual NIC. If the intermediate layer driver calls NDisimdeInitialDeviceInstance Clears the initialization of the virtual NIC, NDIS calls each binding protocol driver's ProtocolunBindAdApter function to release the binding of the virtual NIC. Before the TCP / IP protocol releases the binding, the wake-up mode of all low-level micro-port is cleared by sending OID_PNP_REMOVE_WAKE_UP_PNP_PNP_ROVE_WAKE_UP_PATTERN to the low-layer micro-port, which actually prohibits wake-up matching mode. 2.10.3.2 Power Settings for Working Status If the low-level NIC supports power management, NDIS can issue an OID_PNP_SET_POWER request to set the operating state to the low-layer micro port. NDIS can also issue an OID_PNP_SET_POWER request to the micro port (upper side) of the intermediate layer driver. For power settings, the intermediate layer driver returns only NDIS_STATUS_SUCCESS. The intermediate layer driver cannot pass the OID_PNP_SET_POWER request to the lower micro port. If the intermediate layer driver clears the initialization of the virtual NIC, you must call NdisimInitialDeviceInstance to reinitialize the NIC. In this case, in order to bind the protocol driver to the virtual NIC, NDIS calls the protocolbindadapter function of each upper protocol driver. NDIS calls the IM driver and the protocolpnpevent function of the protocol driver that binds to the virtual device (IM driver). This call specifies NetEventSetPower as a working state (the power state of the D0 network device). The binding protocol driver can begin to send packets and OID requests to the intermediate layer driver. The intermediate layer driver can start to send a packet and perform an OID request to the lower micro port. Note that NDIS can issue the OID setting D0 state before sending OID_PNP_SET_POWER to the low-layer micro-port, NDIS can issue the OID setting D0 state to the intermediate layer driver micro port. NDIS can also invoke the ProtocolPNPEVENT function of the binding protocol to the D0 state before the ProtocolPNpevent function indicating the intermediate layer driver indicates the D0 state. In the above case, the micro port of the intermediate layer driver will function completely represents the NIC, and the intermediate layer driver must have the ability to process this situation, for example, if the binding protocol is driven The program sends a packet to the micro port of the intermediate layer driver, and the intermediate layer driver should immediately queue the package inside until the low-level NIC completes the functions.
2.11 Intermediate Layer Driver Replies 2.12-bit operation
The intermediate layer driver must provide the cancellation capacity of the transmission (low-layer driver unprocessed) due to low-layer NIC reset. Typically, the low-level driver reset NIC is because NDIS calls the MiniPortreset function of the NIC driver when the NDIS queue is timeout or a NIC binding request. If the high-level driver calls NDisReset, the micro-port can also reset the NIC. If the low-level NIC is to reset, NDIS calls the protocolstatus function of each binding protocol and an intermediate layer driver in the NDIS_STATUS_RESET_START status, and then calls the same binding driver's ProtocolStatusComplete function. When the NIC driver reset is completed, NDIS uses ndis_status_reset_end to call the Protocol (CO) Status function again and then call the protocolstatuscomplete function. When NIC reset, if the intermediate layer driver has any transmitted and unprocessed packets, NDIS returns the exact state of these packets to the intermediate layer driver and ends these packets. After the reset is completed, the intermediate layer driver must resend these packets. When the intermediate layer driver receives the NDIS_STATUS_RESET_START state, the following will be made: hang up the send ready-to-use packet until protocol (CO) status receives NDIS_STATUS_RESET_END notification and has called the protocolstatuscomplete function; hangs ready to indicate to high-level driver Receive data package until Protocol (CO) Status receives NDIS_STATUS_RESET_END notification and has called the ProtocolStatusComplete function; clear the internal state and NIC state of the operation in all processes remaining. After Protocol (CO) Status received ndis_status_reset_end and the ProtocolStatusComplete function has been called, the intermediate layer driver can continue to send packets, generate requests, indicate to the high-level driver. Because the intermediate layer driver typically calls NDISMSetAttributeEx when NDIS is called, it is forbidden to send and request timeout, so MiniPortreset is rarely called. If the MiniPortreset is called, it is possible because the high-level driver calls NDisRisreSet, then if necessary, the intermediate layer driver should reset the internal status and set AddressingReset to True before returning. When the low-level NIC is reset, if the low-layer NIC continues to transmit and receive the packet state, NDIS will request MiniPortSetInformation, which is the internal address status of the NIC reset the intermediate layer driver. The MiniPortreset does not have to complete the unprocessed send, NDIS will make the unfinished transmission of the high-level driver in an appropriate manner. However, some relevant states saved by the intermediate layer driver may be cleared. The intermediate layer driver can initiate a reset operation by calling the NDisReset. If the reset request returns NDIS_STATUS_PENDING, the ProtocolReSetComplete is called when the low-level NIC or virtual NIC reset is called and the driver calls protocolmReSetComplete. NdisReSet is rarely called unless the middle layer driver knows that the low-level NIC cannot run normally. For example, if the intermediate layer driver finds that it is not received for a fairly number of empty or requests, if there is enough knowledge about the low-layer NIC, it can be called NDisReset. However, in general, the detection and start of NIC reset requirements are done by using the NDIS and NIC drivers to use timeout logic. 2.13 Intermediate Layer Driver Remove Binding Operation
When the low-level NIC is no longer available, the intermediate layer driver calls NDisCloseadapter from the NDISUNBINDADAPTER function called by NDIS to release the binding from the low-level NIC driver. For example, if the low-level NIC timeout and NDIS call the NIC driver's MiniPorthalt function, then NDIS will call the NDISUNBINDADAPTER function of the upper intermediate layer driver. The intermediate layer driver can also initiate an endless operation. For example, when the GeneralStatus status value received in ProtocolStatus is ndis_status_closing. If an operation is used in the initialization, an adapter is used, for example, the required resource fails, the intermediate layer driver must also be released to the adapter's binding because the network operation cannot be performed when binding. The NDISUNBINDADAPTER function of the intermediate layer driver To call ndiscloseadapter. The intermediate layer driver does not have to release the pre-binding resource unless the NDisCloseadapter function returns NDIS_STATUS_SUCCESS or the driver call NDISCOMPLETEUNBINDADAPTER. If the NDisCloseadapter function returns NDIS_STATUS_PENDING, the intermediate layer driver cannot release the pre-bredified resource (until the NDiscloseAdapterComplete function is called). After all the requests on this binding is processed, NDIS can call NDisCloseadapterComplete. When NdisCloseadapterComplete returns to control, the representative bound ProtocolBindingContext handle that the intermediate layer driver assigned will become invalid. Before you return to NDISUNBINDADAPTER, or before use NDisCompleteunBindadapter to complete the release operation asynchronous, the intermediate layer driver must complete the following: Clear it to bind any status value; release its assignment for establishing binding All resources; call ndiscloseadapter. If the binding that is being completed is mapped to the intermediate layer driver exported device, and the device is initialized by calling NDisimInitializedEviceInstance, the intermediate layer driver can close these devices by calling the NDisimDeinitializedEviceInstance or the NDisimInitializedEviceInstanceEx function. The result of this will result in the transmission and request of the high-level driver, and the virtual NIC of the intermediate layer driver will no longer respond. When the middle layer driver is called NDisCloseAdapter, all send requests of the binding should be invalidated in a suitable error status value. 2.14 Intermediate layer driver status refers to 2.15
The lower boundary is required to provide the ProtocolStatus and ProtocolStatusComplete functions that are required to provide the protocolstatus and protocolstatuscomplete functions. NDIS calls protocolstatus when the low-level NDISMindicateStatus reports the hardware status to the NDISMISMISTATUS that is not connected NIC driver. When the status changes start, Protocolstatus is called. If the operation of the status node indicated when the protocolstatus call is not completed, the low-level NIC driver is tightly followed by NDISMISMINDICATATUSCOMPLETE. When the above situation occurs, call ProtocolStatusComplete to change the post-period operation. Connected intermediate layer drivers are required to provide the Protocolcostus function and the ProtocolStatusComplete function. NDIS calls protocolcostatus when calling NDismCoindicateStatus report hardware status to the connected NIC driver. When the status change begins, Protocolcostatus is called. GeneralStatus examples that were sent to Protocolstatus include: ndis_status_closing discusses the status of this status and protocol (CO) Status in Section 2.11; ndis_status_reset_start and ndis_status_reset_end is like said in Section 2.10, these two states will be given to Protocol (CO) Status and protocolstatuscomplete functions; NDIS_STATUS_LINE_UP This state indicates that the intermediate layer driver is located on the NIC driver that supports WAN features that has been connected to the remote node. For more information on WAN drivers, please refer to Chapter 8; NDIS_STATUS_RING_STATUS provides more detailed information on this status STATUSBuffer, such as a problem with the token ring media. When the intermediate layer driver receives a status indication, if the status indication causes the intermediate layer driver to change its internal state to affect the MINIPORTXXX function operation, it will indicate the state by calling NDISMISMISTATUS to the upper layer driver. That is, if the state indicates to the intermediate layer driver, the transmission or request of the driver is indicated, then the intermediate layer driver can indicate the state to the high-level driver (possibly suspended submit transmission, and request). However, if the intermediate layer driver continues to receive send and requests through internal waiting queues, the status information should not be delivered upwards. 3 load balancing and failure replacement
Load balancing and failure replacement (LBFO) functions can improve the reliability and performance of network adapters of micro-port drivers. The micro-port driver can use LBFO to distribute the workload into its adapter beam, thereby balancing the workload. That is, the micro-port driver can use LBFO to remove tasks from the master adapter to any sub-adapter. For example, suppose a protocol driver requests a micro-port driver to send a package. In order to balance the package, the micro-port driver can use its master adapter to transmit some packets, and unload the transfer of other packets to the secondary adapter. The LBFO feature also allows the micro-port driver to take over the package transfer and information request when the master adapter fails. The following sections describe LBFO and how to implement micro-port drivers that support LBFO: About LBFO Specifies the support of LBFO to implement LBFO on micro-port drivers
3.1 About lbfo
Micro-port drivers can be supported for LBFO. Such a micro-port driver can distribute the workload into its micro-port instance bundle to balance the amount of packet transmission, and can take the package transmission and information request when the master adapter is famed. Micro-port driver management of micro-port instances can include single port and multi-port NIC. NDIS only exposes the main micro port of the micro-port driver to the transport layer. If the transport layer requests the package to send a package to the micro-port driver, or requests the setting or querying the micro-port driver, NDIS passes these requests to the primary micro port. The micro-port instance initialized by the same micro-port driver can be part of the LBFO program. In order for multiple micrograph examples initiated by different micro-port drivers into a part of an LBFO program, an intermediate layer micro-port driver must be implemented to provide LBFO for these micro-port instances. The subtle port can only use the handle of the main micro port to the bound transport layer indicate the package. All information requests generated by the primary microfield processing the transport layer. However, NDIS can send the specified request to the subtle port. For example, NIDS may query media connection of all micro ports (Media Connectivity). The subtle port must be processed and responded to this query. The micro-port driver must specify whether it implements LBFO during installation. In order to specify LBFO support, the micro-port driver information file (* .inf) must contain the buddleID keyword and a string value to identify the adapter bundle of the micro port. The registry is configured with this information. During initialization, the micro-port driver must determine if the micro-port instance being initialized belongs to an existing bundle. To determine if the micro-port is a member of the bundle, the micro-port driver retrieves a string value from the bundleid keyword under the micro-port registry key. Each micro-port instance should copy this buddleID value into the internal structure of the micro-port. The micro-port should then search for the internal structure of all initialized micro ports, find micro ports with the same beam identifier (buddleid) value. If not found, it will become the main micro port of the bundle. The above case occurs when the micro-port is the first initialized micro port in the bundle. If the micro-port found a micro-port with the same beam identifier value, it should set itself as the subtle port corresponding to the primary micro port. The micro-port driver can set multiple sub-ports, that is, there can be multiple sub-ports in one bundle. The micro-port driver must provide appropriate LBFO for package transfer and information requests. An example of a micro-port providing LBFO is described below: The micro-port driver reselects the package transfer and information request to the sub-port. If the primary micrograph of the bundle fails, the micro-port driver can remove the primary micro ports from the bundle and improve the second micro-port to serve as the main task. 3.2 Refers to 3.3 Support for LBFO
The micro-port driver specifies it to implement LBFO at the time of installation. In order to specify support for LBFO, the micro-port driver information file (INF) must contain a bundleid keyword and a string value (REG_SZ). This string value identifies the adapter bundle of the micro-port driver. The beam identifier is also used to configure the registry. The beam identifier value of the micro-port driver must be exposed to the network application as the adapter properties, the control panel application, so if the user changed this property, the NIC will be stopped and then restarted. Users can adjust the dependence of the dependence by changing the beam identifier property. The following is Add-registry-section in a micro-port INF file, which adds the bundleid subkey under the NDI / Params key and sets a string value "bundle1" for bundleid's paramdesc (parameter description). [A1.Params.REG] HKR, NDI / Params / Bundleid, Paramdesc, 0, "Bundle1" Add key and value information to micro-port INF files, see "NDIS NETWORK DRIVERS GUIDE" 1.2.7 Section. Specify information about the adapter configuration parameters and values. See 1.2.7.11 and 1.2.7.12.
3.4 Implementing LBFO on the micro-port driver To support LBFO, the micro-port driver must be able to perform the following: Initializing the working volume of micro-port balance micro-port drivers to increase a sub-port after the main micro-port failure
3.4.1 Initializing the micro-port harness
NDIS Call the miniPortInitialize function of a micro-port driver for each network adapter management of the driver. In order to support LBFO, MiniPortInitialize must determine if the initialized micro port belongs to an existing bundle. In order to determine if the micro port is a member of the bundle, the micro-port first calls the NDisopenConfiguratiom function to obtain the handle of the registry key (stored with the configurable parameters of the micro-port). The micro-port is then called the NDisReadConfiguration function Retrieves its string value (REG_SZ) from the bundleid keyword under the registry keys of the micro-port. Each micro port should be copied to its internal structure. This internal structure is also considered to be a miniportadaptercontext. Each micro-port should also copy its miniportadapterHandle to MiniPortAdApterContext. NDIS uses the MiniPortadapterHandle reference to the associated micro-port. After the micro-port retrieval identifier, the micro port should search all the internal structure of all initialized micro ports, and find micro ports with the same beam identifier value. In order to perform this search, the micro-port checks the miniportadapterContext of each micro-port. The micro-port driver can set this micro-end as a primary micro-port or a subtle port: this micro-port is the first initialized micro port in the bundle. In other words, this micro port does not find micro ports with the same beam identifier value. In this case, this micro port is default a primary micro port. This micro-port looks out to an identical beam identifier value. It should call the ndismsetminiportsecondary function to set itself to the subtle port associated with the main micro port. In this call, the micro-port passes his own handle in the MiniPortadapterHandle parameter, and passes the handle of the primaryized primary port in the primaryminiportadapterhandle parameter. The micro-port retrieves the handle of the master micro-port from the miniPortadapterContext of the primary micro port.
A plurality of micro ports can be present in a bundle. During each instance initialization, the micro-port driver can call NDismSetMiniportSecondary for multiple micro ports, set it to the subtle port associated with the main micro port. Only when the micro-port instance is potentially belonging to an instance beam initialized by the same micro-port driver, it can call NDismSetMiniportSecondary. It cannot be considered part of the bundle before the micro-port instance calls NDismSetMiniportsecondary. The micro-port instance can become part of the bundle only after the NDISMSETMINIPORTSECONDARY is successfully invoked.
3.4.2 Balance the workload of micro-port drivers
A plurality of micro-ports were previously initialized and allowed to be a micro-port driver for members of a bundle, which can use these micro-port balanced drivers. NDIS only exposes the primary micro-port instance to the transport layer. If the transport layer requests to send a package or request query or setting the micro-port driver to the micro-port driver, NDIS should pass these requests to the primary micro-port instance. In order to balance the workload of the micro-port driver, the driver should implement the functionality of uninstalling some requests to the subtle port instance. The micro-port driver can perform these requests to perform the task associated with the requesting sub-port requesting the sub-port request. Regardless of the actual micro-port or the sub-port execution request, the micro-port driver is applied to the handle of the primary microfiler when completing these requests. However, if NDIS sends a request to the second micro port, the subtarty port should use its own handle to complete the request.
3.4.3 Improve a subtle port after the main micro-port failure
A micro-port driver that supports LBFO can increase a second micro-port as the main role when the master adapter is invalid. If the master adapter of the micro-port driver is invalid, the driver can call the NDISMREMOVEMINIPORT function to remove the primary micro portion from the bundle. Then the driver calls the NDISMPROMOMINIPORT function to upgrade the sub-micro port as the main micro port. NDIS should use the new micro-port as the main micrograph to transfer the subsequent request of the transport layer to the micro-port driver. 4 installation network components
This part includes: • Components and file summary on network components • Detail information about creating network components information (INF) files
4.1 Components and files used to install network components
The installation of Windows 2000 network components involves the following aspects: • Class installation and collaboration installer network components are installed by Windows 2000 network installer, or custom class installation created by the vendor. The class installer is a dynamic link library for installation, configuring, or deleting a device. If the network installer does not provide the desired feature, the vendor can write a collaborative installer to customize the installation process. The collaboration installer can be a Win32 DLL that assists the device installation in the Windows 2000 system. Collaboration Setup as a helper or filter of the classes, is called by the device installer. • Information (INF) file Each network component must have an information (INF) file, the network installer can be used to install the components. The network INF file is based on the universal INF file format. Create details of the INF file for the network components, see 1.2 Selected Notification Object Software Components, such as network protocols, customers, or services, can have a notification object. The notification object implements a user interface, notifies the component to the component, so that the component implements the control of a binding process and provides conditional installation and conditional deletion. The notification object is described in Chapter 2. Network adapters can also support a user interface and delete some controls for binding events, conditional installation, and conditional. These are implemented by INF files or collaborative installations. · Optional network porting DLL and related files If the network supplier driver does not release with Windows 2000, the vendor should provide upgrade support for these components. Network Upgrade Processing The parameters of the network component are only driven from Windows NT 3.51 or Windows NT 4.0 to Windows 2000. For more information on upgrading network components, see the sixth section of online DDK "Network Drivers Reference", first chapter. In addition to the above components, the supplier also provides the following documents: • The driver driver of the device is typically constructed by the driver impression (.sys file) and the driver library (.dll file). • Optional Driver Directory file vendor submits the driver to the Windows Hardware Quality Library (WHQL) to test and sign, and then get a digital signature. WHQL returns a directory file (.cat file) with the package. Venters must list all directory files in the INF file of the device. • Optional text mode installation information file (TXTSetup.oem). If the network device requires starting the machine, the operating system package must include the driver, or the device vendor must provide a TXTSETUP.OEM file. The TXTSETUP.OEM file contains some information, in the early stage of the startup process, the system installation component uses this information to install the device (during text mode installation).
4.2 Creating a Network INF file
The network INF file is based on standard INF file format, but also includes network special items such as network specific festivals, descriptions, and values. The following is a description of the network INF file, assuming that the reader has understood the basic INF file. Before trying to create a network INF file, you should read the description of the basic INF file. Microsoft Windows 2000 network INF files are incompatible with Windows NT 4.0 and earlier NT network INF files. To make network components can be installed on Windows 2000 and NT 4.0 platforms, different INF files should be created separately. The same INF file can be used to install network components on Windows 2000 and Windows 95/98. See the INF document of the first volume of Windows 2000 Driver Development Reference. The INF file demand varies depending on the network type. Summary of different types of networks on INF demand, see 1.2.11.4.2.1 Network INFS file name 4.2.2
The file name of the INF file sold with Windows 2000 must not exceed 8 characters. Other INF files are not subject to this limit. All INF file extensions are .inf. All web INF file names begin with NET, used to indicate this file by the network installer. The IRDA device's INF file begins with IR. The rest of the file name is used to indicate network component producers or describe these components. Below is an example of a valid network INF file name: Network INF file name file name component
NETMST NET Manufacturer NetDLC Net Product Description Net999 Net Product Model 4.2.3 Network INF file version of the network INF file version section There are some network unique nature descriptions, as follows: Class class section should include a class, enabling readers easy Determine the category of the network component to be installed by this file. There are 4 networks · net descriptions Physical or virtual network adapters. The NDIS intermediate layer driver is included in the NET class, which outputs a virtual network adapter. · NetTrans Description Network protocol, such as TCP / IP, IPX, connecting to the client or facing the Call Manager. · NetClient description network customers, such as Microsoft Network Customers or NetWare customers. The NetClient component is considered to be a network provider if it provides a network print service, which is also considered a print provider. · NetService Describes network services such as file services or print services. Although the IRDA device is installed by a classes, IRDA is not attributed to any one of the four network classes above. The INF file used to install the IRDA device should have an Infrared Class value. This class includes Serial-IR and FAST-IR devices. The ClassGuid version must contain the ClassGuID item. The network installer determines the installed network component class with the ClassGUID item. There are 4 ClassGUID values, each value corresponds to a network class: network class ClassGUID
Net {4D36E972-E325-11CE-BECl-08002BE10318} NetTrans {4D36E973-E325-11CE-BFCl-08002BE10318} NetClient {4D36E974-E325-11CE-BFCl-08002BE10318} NetService {4D36E975-E325-11CE-BFCl-08002BE10318}
IRDA device's INF file should have a classGUID: {66DDLFC5-81DO-BEC7-08002BE2092F}. The signature and operating system item signature item has three values: $ Windows 95 $ · $ Windows NT $ · Chicago $ If the INF file is only used for Windows 95/98, the correct signature stress $ Windows 95 $. INF files with $ Windows 95 $ cannot run on Windows 2000. As INF is only for Windows 2000, the correct signature is $ Windows NT $. INF file with $ Windows NT $ signed cannot be run on Windows 95/98. If INF is running on Windows 95/98 and Windows 2000, the correct signature is $ Chicago $. Network INF file with $ ChiCago $ must have the following line in version: compatible = 1 If this is not allowed, you cannot run on Windows2000. Version As an example below is the version of the INI file for installing the network adapter: [Version] signature = $ chicago $ compatible = 1class = netclassguid = {4D36E972-E325-11CE-BECL-08002BE0318} provike =% MSFT% Driverver = 08/20 / 1999Provider item indicates who develops INF files, not who develops components installed by INF files. 4.2.4 Network INF file Model Festival Inf file model section is a component of each installation, including items in the following format: [Device-Description = Install-section.name, HW-ID [, compatible-id ...] For the detail description of this item, see the INF documentation of the "Windows 2000 Driver Development Reference" Volume 1 of "Windows 2000 Driver Development Reference". The HW-ID of the network adapter (also known as device, hardware, or component ID) must match the Hardware ID of the adapter to the PNP manager. The HW-ID of the network software component should be composed of the provider name, followed by the underline and manufacturer name or product name. The provider name indicates the provider of the INF file. The manufacturer's name indicates the manufacturer of software components. The product name indicates software components. For example, the following HW-ID contains the provider name of the product name: MS_DLCMS_IBMDLC4.2.5 INF file DDInStall Festival
The DdInstall section of the network INF file has the following network special properties: Characteristics must have a Characteristics item for each DdInstall section. The Characteristics item illustrates a feature of the network component, which may limit the operations made to the component. For example, CHARACTERISTICS can explain whether the component supports the user interface, whether it can be deleted, or hide the child user. The Characteristics item can have 1 or more values (Multi-value should be calculated): Hexadecimal value name description
ox1 NCF_VIRTUAL described assembly is a virtual adapters ox2 NCF_SOFTWARE_ENUMERATED described component is a software simulation adapter ox4 NCF_PHYSICAL described assembly is a physical adapter ox8 NCF_HIDDEN described components do not display a user interface ox10 NCF_NO_SERVICE described assembly No Service (device driver) ox20 NCF_NOT_USER_REMOVABLE Description You cannot be deleted by the user (for example, by the Control Panel or Device Manager) OX40 NCF_MULTIPORT_INSTANCED_ADAPTER Description Components There are multiple ports, each port as a separate device installation. Each port has its own HW_ID (component ID) and can be installed separately, which is only suitable for the EISA adapter OX80 NCF_HAS_UI Description Components Support User Interface (for example, Advanced Page or Customer Properties Sheet) OX400 NCF_FILTER Description Components is a filter below Characteristics The combination of values is not allowed:
· NCF_VIRTUAL, NCF_SOFTWARE_ENUMERATED, and NCF_PHYSICAL are mutually exclusive. · NCF_NO_SERVICE cannot be used simultaneously with NCF_VIRTUAL, NCF_SOFTWARE_ENUMERATED, or NCF_PHYSICAL. Virtual, software simulation adapters or physical adapters must have a related service (device driver). Below is a Characteristics item example of a physical adapter that supports user interfaces: Characteristics = OX84; NCF_PHYSICAL, NCF_HAS_UIBUSTYPE Physical Adapter's DdInstall section must include the Bustype item, which describes bus type (PCI, ISA, etc.). The possible value of the Bustype item is described by the Interface_Type description: Bus Type Value
ISA 1EISA 2Microchannel 3Turbochannel 4pcibus 5VMBus 6Nubus 7pcmciabus 8cbus 9mpibus 10 Mpsabus 11PNPisabus 14PNPBUS 15 If the adapter can be used in a variety of bus types, install the INF file of the adapter should have a DdInstall section for each bus type. For example, if an adapter can be used for ISA bus and PNPISA bus, the INI file should have ISA DdInstall and PNPisa's DdInstall section. Bustype in the DdInstall section describes the bus type of the section. Examples are as follows: [al.isa] bustype = 1 [al.pnpisa] bustype = 14eisacompressedID and AdapterMask Install the DDISTALL section of the IISA network adapter's INF file must include an EisacompRessedID item, which describes the EISA compressed ID and adapter mask. Examples are as follows: eisacompressedID = OX24322432Adaptermask = OxffffportLDeviceNumber and Port1FunctionNumber Install the DDInstall festival of the INF file for multi-port network adapters, including Port1DeviceNumber items or port1functionNumber items. This item illustrates that when the mouse is on the network adapter name or icon, the adapter port information is displayed in the Connection Properties dialog box (this through the network and dial folder). If the adapter port number is mapped to the PCI device number, use the port1DeviceNumber item. Set the port1DeviceNumber to the first PCI device number. For example, if the PCI device number 4 is mapped to port 1, the PCI device number 5 is mapped to port 2, and PCI device number 6 is mapped to port 3. With the following: Port1DeviceNumber = 4 If the adapter port number is mapped to the PCI function number, you should use the port1functionNumber item. Set the port1functionNumber to the first PCI function number. For example, if the PCI function number 2 is mapped to port 1, the PCI function number 3 is mapped to Port2, and the PCI function number 4 is mapped to port 3, and so on. The mapping of the PORT1FUNCTIONNUMBER = 2PCI device number or the PCI function number to the port is considered static. At the same time, the adapter port is also encoded. Port1DeviceNumber and Port1FunctionNumber are excluded. If the two items exist in the same DDInstall section, only the port1DeviceNumber item is used.
4.2.6 Delete Festival
Delete the NetClient, NetTrans, and NetService component support, but do not delete NET components (adapters). The network installer does not track the adapter instance. Deleting section results in deleting files for other instances shared by other network adapters and adapters, making the adapter or adapter instance uncomfortable. If you must delete the driver file used by NET components, you must use the Collaboration Installer to track all drivers using the file. Such a collaboration installer can track multiple instances of the same device, or track the drivers of multiple devices. For more information on collaborative installations, see the INF document of the first volume of "Windows 2000 Driver Development Reference". 4.2.7 ControlFlags Festival
The ControlFlags section typically has 1 or more ExcludeFromSelectEct items. Each ExcludeFromSelect item describes a network component that is not displayed to the end user as an option to manually install. The ControlFlags section must include an ExcludeFromSelect entry: • Each installed plug-and-play adapter • Each software component that is automatically increased by the program (not the user manual increase) is not plug-and-play adapter to be manually increased by the user. Therefore, it should not be listed in the ControlFlags section. For example, the ISA and EISA adapters must be manually installed by the user. The functionality of the ExcludeFromSelect Item and the NCF_HIDEN of the Characteristics item in the DdInstall section are different. The ExcludeFromSelect entries prevent adapters or software components from displaying in the Select Install Component dialog. However, adapters or components can still be listed in the connection dialog. NCF_HIDDEN prevents adapters or components from appearing in any user interface, including connection dialogs. For more information, see the first volume of "Windows 2000 Driver Development Reference".
4.2.8 Add-registry-sections for network INF files
INF has 1 or more add-registry-sections for each installed component. Add-registry-section adds keys and values to the registry. The DDInstall section of INF contains AddReg description that references 1 or more add-registry-sections. See the INF document in "Windows 2000 Driver Development Reference" Volume 1 for Add-Registry-Section and AddREG. Add key and values to the instance key of the component to add key and values to the instance key: • Set static parameters for the component (cannot modify the configuration parameters via the user interface). See 1.2.7.1 · Describe the number of ports (such as channels, circuits, or Bearer channels) See 1.2.7.2, indicating the key and values of the ISDN adapter. See 1.2.7.3 and request the installation of another network component. See Section 1.2.7.4 · Description Supports the value of the custom property page. See 1.2.7.12 Adding key and values to NetClient Components and ADD-Registry-Section of a NetClient component must add a NetWorkProrIder key to the service key of the component. The NetWorkProvider key has 2 values: describes the Name of the network provider name and describe the ProviderPath describing the network provider DLL full path. See 1.2.7.6. Generating NDI keys Each network INF file must include at least one add-registry-section that adds NDI keys for components installed for this file. The NDI button is a special network key, in the instance key of the component. The keys and values added to the NDI key are different depending on the type and compatibility of the network components. The NDI key supports the following information: • The HELPText value is description for NetTrans, NetClient, or NetService components. See 1.2.7.7. • Inform the notification object description value. See 1.2.7.8 · Describe the relevant service values. See 1.2.7.9 · Description Binding Interface. See 1.2.7.10 · Describe the adapter configuration parameters for the advanced page. See 1.2.7.11 • Description of the filter service. See 1.2.7.13. · Try to be ambiguous. See 1.2.7.14 Available in Windows 95/98, see 1.2.7.15.1.2.7.1 for NDI registration keys and values in Window 2000, set static parameter static parameters can only be set once with INF files, The property page is reconfigured. Add-registry-section adds a REG_S2 value as a static parameter to the instance key of the component. Here is an example, add two static parameters to the Component Instance Key. [Al.staticparams.reg] HKR, MediaType, 0, "1" HKR, INTERNALID, 0, "232" Add-registry-section can add some vendor defined static parameters to the component instance key. 1.2.7.2 Description WAN Adapter Description The INF file of the WAN endpoint WAN adapter must add a WANEndpoionTS value to the Adapter Instance key. WanendPoint is a REG_DWORD value indicating the number of endpoints supported by the WAN adapter (eg, channel, circuit, or bearer channels). For example, the WANEndPoints value of the BRI (Basic Rate Interface) ISDN Adapter is 2, and the WANENDPOINTS value of the PRI (main rate) ISDN adapter is 23. Below is an example of add-registry-section, adding Warenerpoionts for a BRISDN adapter, which is 2. [Al.reg] HKR, WANEndPoints, Ox00010001, 21.2.7.3 For ISDN Adapters Description ISDN Adapter In addition to the WANDPoints value (see 1.2.7.2), ISDN adapter's INF file must also add to the Adapter Instance key and Value (via add-registry-section).
The value of this REG_DWORD type of IsDnNumdChannel describes the number of D-Channels supported by the ISDN adapter. IsDNautoswitchDetect (optional) This optional REG_DWORD type value description, whether the ISDN adapter supports automatic exchange detection. Value 1 means support, value 0 does not support. IsdnSwitchType This REG_DWORD values specify the ISDN adapter supports switching type: ISDN_SWITCH_AUTO Auto Detect (NorthAmericalonly) ISDN_SWITCH_AUTO ESS5 (AT & T, NorthAmerica) ISDN_SWITCH_NI1 National ISDN1 (NI_1) ISDN_SWITCH_NI2 National ISDN2 (NI_2) ISDN_SWITCH_NT1 Northern Telecom DMS 100 (NT_1) ISDN_SWITCH_INS64 NTT INS64 ( japan) ISDN_SWITCH_ITR6 Germal National (ITR6). this type is rarely used ISDN_SWITCH_VN3 French National (VN3). this type is rarely used ISDN_SWITCH_NET3 European ISDN (DSS1) ISDN_SWITCH_DSS1 European ISDN (DSS1) ISDN_SWITCH_AUS Australian National this type is rarely used in this ISDN_SWITCH_BEL Belgium National Types rarely use ISDN_SWITCH_VN4 FRENCH National (VN4) ISDN_SWITCH_SWE SWEDISH Nationalisdn_Switch_ita Italian Nationalisdn_Switch_TWN TAIWAN National to illustrate multiple swap types, as long as the swap type value is added. ISDN Wizard (Automatically run when installing ISDN components) Allows users to select the exchange type by ISDNSWITHTYPES. The selected switching type determines the ISDN configuration parameters subsequently displayed. These parameters include telephone numbers, SPID (Service Profile Identifier), subaditors, and multi-user numbers. IsDnNUMBChannels (increasing to D-CHANEL keys) D-channel value is an index of 0 ~ 9 for indicating D-Channel. Isdanumbchannels is a REG_DWORD value that is added to the D-Channel key. ISDNNUMBCHANNELS illustrates the number of B-Channel supported by D-Channel. Here is an example of adding the ISDN key and value to the ISDN Adapter Instance key. Two D-Channels are described, and two B-CHANNELs are described in each D-Channel.
[ISDNadapter, reg] HKR ,, WanEndpoint, Ox00010001,4HKR ,, IsdnNumDChannels, Ox00010001,2HKR ,, IsdnAutoSwitchDetect, Ox00010001,1HKR ,, IsdnSwitchType, Ox00010001, Ox00000004; NI1HKR, 0, IsdnNumBChannels, Ox00010001,2HKR, 1, IsdnNumBChannels, Ox00010001 The 2ISDN wizard itself adds the ISDN key and value to the ISDN Adapter's instance key specified by the user. The ISDN Wizard adds the following keys and values: • IsdnswitchType This REG_DWORD value indicates the user-selected switching type • There is an ISDNMUBSBERNUMBERS value for each D-Channel. This REG_MULTI_S2 value indicates the number of Multi_Subscriber descriptions of the user. Number. · Each B-Channel has a B-Channel key, isDNSPID, ISDNPHONENUMBER, and / or an isDnsubaddress value. • The B-Channel button is an index that indicates the start of B-CHANNEL. The maximum value of the B-CHANNEL key value is 1 for the value of IsDnNumbchannels. · IsdnsPid is an REG_SZ value indicating the SPID. If so, it will be explained by the user. · Isdnphonenumber is a phone number. If there is, the user explains the layout example of the ISDN adapter registration. Each registration button is enclosed by square brackets, for example: [Keyname]. The bold ISDN key and value are added by the ISDN adapter's INF file. Non-bold ISDN keys and values are added by ISDN wizards.
[Enum / emumeratorID / device-instance-id]; ISDN adapter instance key WanEndPoints = 4IsdnNumDChannels = 2IsdnAutoSwitchDetect = 1IsdnSwitchType = Ox4; NationalISDN1 [Enum / emumeratorID / dervice-instance-id / 0]; D-Channel0IsdnNumBChannels = 2IsdnMultiSubscriberNumbers = 123456723456783456789 [Enum / emumeratorID / device-instance-id / 0/0]; D-channel0 the B-Channel0IsdnSpid = 00555121200IsdnPhoneNumber = 5551212IsdnSubaddress = [Enum / emumeratorID / device-instance-id / 0/1]; D-Channel0 the B-Channel1IsdnSpid = 00555121300IsdnPhoneNumber = 5551213IsdnSubaddress = [Enum / emumeratorID / dervice-instance-id / 1]; D-Channel1 bond IsdnNumBChannels = 2IsdnMultiSubscriberNumbers = 867530923901257658156 [Enum / emumeratorId / dervice-instance-id / 1/0]; D-Channel1 the B-Channel0IsduSpid = 00555987600IsdnPhoneNumber = 5559876IsdnSubaddress = [Enum / emumeratorID / dervice-instance-id / 1/0]; D-Channel1 the B-Channel1Isdnspid = 00555876500IsdnPhoneNumber = 5558765IsdnSubaddress = 1.2.7.4 security Multi-protocol WAN NICS multi-protocol WAN NIC provides more than 1 kind of WAN protocol. For example, the NIC may allow users to select ISDN, frame relays, or T1 channels. The user can select the WAN protocol during the installation of the NIC or configure NIC. The vendor of multi-protocol WAN NIC must provide a collaborative installer to install the wizard page. (Collaborative installation details, see "Plug and Play, Power Management, and Setup Design Guide", and "Windows 2000 Driver Development Reference" Volume 1). Wizard page prompts the user to select the WAN protocol. · If the user selects ISDN, the ISDN wizard is displayed. The ISDN Wizard prompts the user to enter the ISDN switched type and other ISDN parameter values. (See 1.2.7.3) • If the user selects the WAN protocol, the wizard adds the showisdnpages value in the instance key of WAN NIC. In this case, the wizard sets ShowisDNPages to 0 to prevent the display of the ISDN wizard. After the WAN NIC is installed, the user can reconfigure the NIC using the NIC's property page.
· If the user converts the protocol from the ISDN to the WAN protocol, the property page adds the showisdnpage value into the instance key of WAN NIC. The property page sets showisdnpages to 0 to block the display of the ISDN wizard. · If the user change the protocol to ISDN, the attribute page of WAN NIC shows a dialog prompting the user to confirm the change. When the user confirms the change, the property page sets ShowisDNPages to 1. When the user opens the property page again, the ISDN wizard is displayed. If the multi-protocol WAN NIC supports ISDN, LowerRange in the binding interface must be set to ISDN (see 1.2.7.10). If the showisdnpage registration value does not exist, the NIC's LowerRanger is set to ISDN, installed, and configured, display the ISDN wizard. If ShowisDNPages are set to 0, the ISDN wizard is not displayed. ShowisDNPage is set to 1, and the ISDN wizard is displayed in NIC configuration. 1.2.7.5 Request to install another network component is normal, and network components may need to install 1 or more other network components. The network INF file describes these dependencies with the requiredall value. The RequireDall value is added to the NDIS button that needs to be installed in the components of the other components. (Via add-registry-section). The following example shows the requiredall entry of add-registry-section: [NDI.REG] HKR, NDI, Requiredall, 0, "Component ID" component ID is the HW-ID of the required network components (see 1.2.3) . If the network component is to install multiple other components, use a RequireDall item for each component, as shown below: [HKR, NDI, RequireAll], 0, "Component2 ID" Requiredall only for installation of those who cannot be installed by the user Network components. This component is not supported by the user interface. The components illustrated by the Requiredall are only deleted after the components that are required to install the component via the Requiredall. For example, if the INF file of the component A uses RequireDall to illustrate the dependence of the component B, the component B can be deleted when component A is deleted. Requiredall is only installed at the component runtime, other components must be required. For example, in the INF file of the NET component (adapter), use the RequireDall to explain the TCP / IP, and the user cannot delete TCP / IP before the adapter is deleted. Since the adapter can do not need TCP / IP, the adapter's INF file should not use Requiredall to explain the dependence of TCP / IP. Description Requiredall-dependent INF file, you must ensure that the INI file of the desired network component is in the INF directory. It usually has a CopyFiles section. For more information on the CopyFiles section, see "Plug and Play, Power Management, And Setup Design Guide", and "Windows 2000 Driver Development Reference" Volume 1. If the network component installed by Requiredall is failed, the network components depend on the component cannot be successfully installed. 1.2.7.6 Description NetClient Components The NetClient Components of the NetClient component and the INF file of the installation NetClient component visible in the user interface must add a NetWorkProvider key to the service key of the component. The INF file adds the NetWorkProvider key by add-registry-section, which is referenced in the service-install section of the component. The NetWorkProvider key has 2 values: a NAME describing the network provider word and describes the ProviderPath describing the network provider DLL.
Below is an example of add-registry-section to add a NetworkProvider key to the Component Instance key. [NWCWORKStation.addReg] HKR, NetworkProvider, Name, 0, "NetWare or Compatible Network" HKR, NetworkProvider, ProviderPath, OX2000, "% 11% / nwprovau.dll" Installing the INF file for the NetClient component does not have to modify the components ... Control The ProviderORDER value under the / network / provider / order key. This is automatically completed by the network installer. 1.2.7.7 Increasing the HelptExt Value NetTrans, NetClient, NetService Network Components The INF files should increase the HelptExt value (Reg_SZ) in the component NDI key. The Helptext value is a string that describes the functionality of the component. For example, the Helptext value of the NetClient component should not simply indicate this customer, but also indicate that the customer allows the user and what connection. In the GENENAL page of the Connection Properties dialog box, when the component is selected, the HelptExt value appears on the bottom of the page. The NET component (adapter) and IRDA components do not support Helptext values. The following is an example of add-registry-section, used to increase the Helptext value to the NDI button: [ms_protocol.ndi_reg] HKR, NDI, HELPTEXT, 0, 0,% myTransport_help% helptext value is a form of a% strkey%, this is in INF Definition in the Strings section of the file. For more information on the Strings section, see "Plug and Play, Power Management, and Setup Design", and "Windows 2000 Driver Development Reference" Volume 1.1.2.7.8 To increase the registration value NetTrans, NetClient or NerService components for notification objects. The object is used to implement the following functions: • Display component user interface • Inform the component to enable components to implement some of the control over the binding process. · Provide conditions installation. See Chapter 2 for details. NET components (adapters) do not support notification objects, which use collaborative installations. For details of the collaborative installer, see the Collaboration Installer documentation of "Plug and Play, Power Management, and Setup Design", and "Windows 2000 Driver Development Reference". If the component provides a notification object, the INF file of this component must add the following two values to the component NDI key. · CLSID illustrates the GUID of the component object. Get the GUID by running uuidgen.exe. See Platform SKD for details. • ComponentDLL illustrates the path to the object DLL. If the DLL is not in the Window / System32 directory, it should be explained as a full path. The following is Add-registry-section examples of adding CLSID and ComponentDLL to NDI keys: [MS_PROTOCOL.NDI.REG] HKR, NDI, CLSID, O, "GUID" HKR, NDI, Componentdll, O, "NotifyObject.dll" The DDInstall section of the component of the notification object must contain a CopyFiles instruction to reference the file-list-section that will notify the object DLL to copy to the Directory Directory described in the DirectionDIRS section.
See "Plug and Play, Power Management, And Setup Design Guide," Plug and Play, and "Windows 2000 Driver Development Reference", please 1.2.7.9 Adding Service Related values to NDI keys If the component has a connected service (device driver), the add-registry-section must add the service value into the NDI key. This value is a REG_SZ value indicating the main services connected to the components. The service value must be consistent with the ServiceName parameters in the Addservice instruction, which references Server-Install-Section (see Section 1.2.8). If the component has 1 or more connected services, the add-registry-section referenced by the DdInstall section must add the Coservices value into the NDI key. The Coservice value is a multi_sz value that illustrates all services installed by the component, including the main service description of the service value. All NetTrans, NetClient, and NetService components require Coservices values. Since only one service can be connected to 1 adapter, the NET component (adapter) should not support the Coservices value. In addition to closing the service, all service-related operations are performed in the order they are listed in Coservices. For example, the service is in reverse order when the service is started in the order listed. Service-related operations can only be performed only when the service is listed in Coservices. If the services listed in Coservices do not want to start when the component is installed, these services should be listed in the ExcludeSetupStartServices value (MULTI_SZ), which is added to the NDI key. Here is an add-registry-section to add service-dependent values to NDI keys: [MS_PROTOCOL.NDI.REG] HKR, NDI, Service, O, "MyT3" HKR, NDI, Coservice, OX10000, "MyT3" "MyT3co" HKR, NDI, ExcludsetupStartService, OX10000, "MyT3CO" 1.2.7.10 Description Binding Interface For each network component of the installed, the network INF file must be an upward and down interface for this component, which can pass to NDI. The button is added to the interface button. The Interface key has at least 2 values: • 1 UpperRange value (REG_SZ) to define the interface that the component can be tied to the upper boundary. • 1 LowerRAGE value (REG_SZ) to define the interface that can be bound to the next boundary. (For physical adapters, this interface is a network medium such as an Ethernet or signaling ring network. The DEFUPPER and Deflower in the Windows 95/98 network INF file are not supported. The following table lists the UPPERRANGE value supported by Microsoft: UpperRange Value Description
NetBIOS NetBiosipx ipxtdi TCP / IP TDI interface NDIS5 NDIS 5.x (NDIS2, NDIS3, and NDIS4 should not be reused). This value for non-ATM network components must be described, such as a non-ATM adapter, its upper boundary and NDIS interface. NDISATM ATM supports NDIS 5.x.x. This value is required in the ATM network component, such as an ATM adapter, its upper boundary and NDIS interface. The upper boundary of the NDiswan WAN adapter. Description of this value causes the operating system to automatically use the WAN adapter for RAS. The upper boundary of the NDISCOWAN WAN adapter is running on the connected NDIS. Noupper all the upper bounds of components that are not exposed to binding purposes. For example, there is a component of a private interface. Winsock Windows Socket Interface NDIS5_ATALK NDIS 5.X NET Components (Adapter) on the upper boundary, only binding the upper boundary of the AppleTalk interface NDIS5_DLC NDIS5.XNET component adapter, only bound DLC interface NDIS5_IP NDis5.xnet The upper boundary of the component (adapter), binds only the upper boundary of the TCP / IP interface NDIS5_IPX NDIS5.XNET component (adapter) in its upper boundary, only bound IPX interface NDIS5_NBF NDIS 5.x Net Components (Adapter) On the upper boundary, only the upper boundary of the NetBeui interface NDIS5_STREMS NDITBEUI interface NDIS5_STREMS NDIS5.XNET component (adapter) is bound, and only bound the Streams interface below is the list of LowerRange values that Microsoft supported: LowerRange Value Description
Ethernet Ethernet adapter's lower boundary ATM ATM adapter's lower boundary tokenring token ring network lower boundary SERIAL Serial adapter's lower boundary FDDI FDDI adapter's lower boundary Baseband Baseband adapter's lower boundary ARCNET ARCINET adapter's lower boundary Localtalk Localtalk Adapter Boundary ISDN ISDN Adapter's Under Border The lower boundary of the WAN WAN Adapter NOLOWER Some components, these components do not expose the lower boundary to binding purposes. NDIS5 NDIS 5.x (NDIS2, NDIS3, NDIS4 is no longer used). Both the next boundary through the NDIS and the non-ATM component interface must be explained. NDISATM is supported by ATM Ndis5.x. All lower boundaries must be explained by the components of the NDIS and the ATM component interface.
UpperRange and LowerRange illustrate the type of interface that can be bound to be bound, not the actual components. The binding engine binds the network component to all components that provide the corresponding interface (in the appropriate boundary). For example, the LowerRange value is the protocol of NDIS5, which is bound to components of all UpperRange values, such as physical or virtual adapters. If the NDIS 5.x Net component (Adapter) and one or more protocols, its UpperaNGE should give one or more protocol values, such as NDIS5_ATALK, NIDS5_DLC, NDIS5_IPX, NDIS5_NBF, or NDIS5_STREAMS. Such NET class components should not assign their UPPERRANGE value to NDIS_5 because this will cause the component to be bound to all protocols that provide NDIS5. INF file developers can use the supplier's specific UPPERRANGE and LOWERRANGE values to the Private binding interface. For example, if the supplier only wants to bind its adapter to its own private protocol driver, the INF file developer can explain the UpperRange of the adapter as XXX, the private protocol LowerRanger description as XXX. The Windows 2000 Binding Engine binds all the UpperRange values for XXX (this example is an adapter) to all LowerRange values (this example is a private protocol). Here's an example of add-registry-section for adding UpperRange and LowerRange for the ATM adapter. [AddReg-Section] HKR, NDI / Interfaces, UpperRregation, 0, "NDISATM" HKR, NDI / Interfaces, LowerRange, 0, "ATM" 1.2.7.11 Configuration Parameter Install NET Components (Adapter) INF files for advanced properties page The adapter configuration parameters can be explained, which will be displayed in the advanced property page of the component. The configuration value described in the Advanced Properties page is written to the root real key of this component. If the adapter supports the advanced property page, the Characteristics item in the DDISTALL section of the Adapter must include the NCF_HAS_UI value. The network INF file indicates the configuration parameters displayed in the Advanced Properties page via add-registry-section, and add-registry-section is referenced in the DDInstall section of the component. This add-registry-section adds one or more sub-keys in the NDI / Params key. The sub-key format of the configuration parameters is NDI / params / subkeyName, and SubkeyName is the REG_SZ value for explaining the name of the supplier parameter. For example, the key of the Transceiver type parameter can be named NDI / Params / Transceivertype. The following keys are reserved and cannot be used as NDI / params / subkeyName. These keys include bundleid, Characteristics, ComponentID, Description, DriverDesc, Infpath, Infsection, Infsectionext, Manufacturer, NetcfgInstanceId, Provider, and ProviderName. The add-registry-section must join the paramdesc (parameter description) and Type value for each parameter subkey that is added to NDI / Params. Add-registry-section can also add default and optional values for this parameter, and if the parameter figures can also increase the min, max, and step values. The following table describes the values in the NDI / Params key: Value name value Description Paramdesc String Description Parameter name Type Int, Long, Word, DWORD, EDIT, or ENUM description type INT, or Enum description Long, Word Description is a digital parameter.
Edit, ENUM description is a text parameter. The Default default value is the parameter description default value. For digital parameters, the default value must be a value (int, long, word or dword). For text parameters, the default value must be a string. The required parameters must set the default value, and the optional parameter should not set the default value. Optional 0 or 1 0 Description parameters are required. 1 Description parameters are optional. In the Advanced Properties page, users can set the optional parameters to Not Present. But for the required parameters, the user must explain a value or use the default value. MIN Number Value Description Number Parameters The maximum value of the Max digit value illustrates the maximum STEP number value of the digital parameters. With the minimum value as the starting point. The value domain of the enum parameter is described by subkey as follows: NDI / params / subskeyname / enum Each enumeration value must be provided. Each Enum subkey describes a numeric value (starting from 0) and a description of the value. Below is an example of add-registry-section, used to increase configuration parameters called TransType. [Al.Params.REG] HKR, NDI / Params / TransType, Paramdesc, 0, "Transeivertype" HKR, NDI / Params / TransType, Type, 0, "Enum" HKR, NDI / Params / TransType, Default, 0, " 0 "HKR, NDI / Params / TransType, Optional, 0," 0 "HKR, NDI / Params / TransType / Enum," 0 ", 0" Auto-Connector "HKR, NDI / params / TransType / Enum," 1 " , 0, "Thick Net (AUI / DIX)" HKR, NDI / Params / TransType / Enum, "2", 0, "Thin Net (BNC / COAX) HKR, NDI / Params / TransTy / Enum," 3 " , 0, "Twisted-Pair (TPE)" 1.2.7.12 For the Network Adapter Description Customization Properties page If the advanced property page does not provide the NET component (adapter) to provide the appropriate configuration selection, you can generate one or more custom property pages, as follows Show: 1. Generate the Microsoft Win32 Properties page. See Platform SDK2. Generate Properties Page Extended DLL, which provides the AddPropsheetPageProc and ExtensionPropSheetPageProc callback function. See Platform SDK. 3. Use add-registry-section to add the EnumProppages32 key to the instance key of the adapter. Enumproppages32 keys have two reg_sz values: output the DLL name of the AddPropsheetPageProc function and the name of the extensionpropsheetpageproc function. Below is an Add-Registry-Section example, used to increase the enumppages32 key: HKR, Enumproppages32, 0, "DLL Name, ExtensSheetPageProc function name" 4. In the adapter's INF file, including a CopyFiles section, extend the property page DLL copy Go to the Windows / Systems32 directory. For details on the CopyFile section, see "Plug and Play, Power Management, And Setup Design Guide," Windows 2000 Driver Development Reference "of the INF document.
5. In the DdInstall section of the adapter, NCF_HAS_UI will be explained as a CHARACTERISTICS value (see Section 1.2.4) to specify a user interface supported by the adapter. 6. When the user confirms that the change in the property page, the property page extension DLL must call setupdigetDeviceInstallParams and set the di_flagex_prorchange_pending flag in the parameter sp_devinstall_params structure, and then use this structure to call SetupDisetDeviceInstallParams, reload the driver, thus reading the change Parameter value. 1.2.7.13 Description Filter Service Value Installing the INF file of the network filter component must explain the filter service value. This section describes how to define a filter service. The network filter assembly includes two parts: • Filter service • Filter device A network filter service and device belongs to the same filter driver. Installing the Network Filter requires both the filter service INF file also requires the filter device's INF file. The filter service INF file must indicate the service value of the filter component under the NDI key. The filter device INF file contains the AddService instruction that references the service-install section where the filter service will be loaded. The ServiceName value of the Addservice instruction must match the service name of the filter component. The ServiceBinary item of the service-install section in the filter device INF file illustrates the binary path of the filter driver. During the filter installation, use the CopyFiles directive of the filter service INF file to the target computer. See Section 1.2.7.9 and 1.2.8. Below is an example of a filter service INF file description of the filter component service name: HKR, NDI, Service, Sfilter This filter component service name is also the name to be submitted to NDIS. The filter component service name does not need to be the same as the binary name of the filter driver, but in general, they are the same. When the INF file adds a filter component service, how does the filter device INF file reference the filter component service name? Examples are as follows: [sfiltermp.ndi.services] addservice = sfilter, 2, sfiltermp.addservice [sfiltermp.addservice] DisplayName =% SFilter_Desc%; "Sample filter Miniport" ServiceType = 1; SERVICE_KERNEL_DRIVERStartType = 3; SERVICE_DEMAND_STARTErrorControl = 1; SERVICE_ERROR_NORMALSericeBinary =% 12% / passthru.sys; filterdriverLoadOrderGroup = Ndi key PNP_TDI filter INF file service must support the following registry entry To define filter services: FilterclassFilterClass illustrates the filter service class. Filter classes can be one of the following: Value meaning
Scheduler package scheduled filter service. This filter class is the highest in the chain. The package scheduler detects 802.1p priority, which is given by the Qossignaling component. The package schedule sends these packages to the low-layer driver based on priority. Loadbalance load balancing filter service. This filter class is between the package schedule and the failure end of the filter. The load balancing filter is assigned to the micro port instance beam, the balanced package transmission. Failover failed over the filter. This filter class is the lowest in the chain. That is to say, no other filter can be between this filter device and adapter.
The FilterClass value determines the location of the filter in the filter stack. Note: Each filter service class has only one filter exists in the filter hierarchy stack. For example, two scheduling filters cannot appear in the stack at the same time. FILTERDEVICEINFFILEFILTERDEVICEINFFILE is the name of the INF file for the filter device. The filter device INF file defines a filter device, which is filtered with a network adapter. Filter devices are a virtual NIC. FilterDeviceInfidfilterDeviceInfID illustrates the identifier of the filter device. The identifier is listed in the Models section of the filter device's INF file. The filter device is a micro-port instance that is initialized by the filter driver for each physical adapter. FilterMediaTypeSfilterMediaType illustrates the media type of filter service filtered. Media Types list, see Microsoft Supported LowerRange Values in Section 1.2.7.10. The filter service INF illustrates these media types in the INTERFCES button under the NDI key. Note: It is critical to filemediatypes to illustrate the appropriate media type. Filter devices can only be installed on this physical adapter, namely the network media connected to the adapter at least one of the filter media types. The LowerRonge item of the physical adapter illustrates the network media such as Ethernet or signaling network. The following is an example of the value INF file defines the service filter filters and services: HKR, Ndi, FilterClass, failoverHKR, Ndi, FilterDeviceInfFile, netsf_m.infHKR, Ndi, FilterDevviceInfId, ms_sfiltermpHKR, Ndi, / Interfaces, FilterMediaTypes, "ethernet, tokenring FDDI "Although other network INF files may be bound to the installed components, the filter service INF file must be explained, it is not exposed to the binding purpose, the lower boundary. The filter service INF file describes this feature in the interface key. Below is an example of this feature: HKR, NDI / Interface, UpperRregation, NOUPPERHKR, NDI / Interface, LowerRange, NOLONER 1.2.7.14 Description Membership INF files installed NET components (physical or virtual adapters) The adapter belongs to the same adapter beam. The NDIS Intermediate Layer Driver and Filter Driver (Output Virtual Network Adapter) are included in the NET class. The NDIS driver balances the load by assigning a workload on the adapter beam. For more information on load balancing, see Chapter 10 of "MiniPort NIC Driver". To illustrate that the adapter belongs to an adapter bundle, the driver INF file of the installation adapter must contain the bundleID key and a case-sensitive string value (REG_SZ). This string value illustrates the driver bundle of the adapter. This registration value is configured with a bundle flag information. Below is an Add-Registry-Section example of a driver INF file, used to add the bundleID sub-key into the NDI / Params key, and assign a string value "bundle1" for the bundleid's paramdesc (parameter description). [Al.Params.REG] HKR, NDI / Params / Bundeid, Paramdesc, 0, "Bundle1" 1.2.7.15 Window 95/98 NDI Values in Window 2000 and NDI registration keys listed below and values listed in Windows 95 Use in / 98, but no longer used in Windows 2000. This information helps developers put the driver from 95/98 to Windows 2000.
· DevLoader · DeviceVxD · DriverDesc · Ndi / DeviceID · Ndi / NdiInstaller · InfFile · InfSelection · Ndi / InstallInf · Ndi / CardType · StaticVxD · Ndi / Interfaces / DefUpper · Ndi / Interfaces / DefLower · Ndi / Interfaces / RequireAny · Ndi / Compability · NDI / INSTALL · NDI / REMOVE · NDI / params / param_key_name / flag · ndi / params / param_key_key / location · ndi / param_key_name / resc · ndi / filename / ... · NDIS / ... Windows 2000 does not support NDI / PARAM_KEY_NAME / RESC and NDI / params / param_key_name / flag value. This means that users cannot configure adapter resources through advanced pages. 1.2.8 DdInstall.Service section The DdInstall.Services section includes one or more Addservice instructions, each instruction references the INF Author-Install-Section, which indicates when the component is driver and how to load it. A DdInstall.Services festival is required in the INF file of the NET component (adapter). That is, this section is optional in the INF file of NetTrans, NetClient, or NetService components. The AddService instruction in the DDINSTALLService section can also reference Error-Log-Install-Section for the component to install the error log. Error logs are optional for all network components. Detail Description of DdInstall.Services section and AddService Directive See "Plug and Play, Power Management, And Setup Design Guide, and" Windows 2000 Driver Development Reference ". The INF file format of Volume 1 is described. The following is an example of DdInstall.Services section, Service-install-section, error-log-install-section, and add-registry-section (ADDREG instruction reference in error-log-install-section): [al.ndi.nt .Services] AddService = a1,2, al.AddService, al.AddEventLog [a1.AddService] DisplayName =% Adapter1.DispName% ServiceType = 1; SERVICE_KERNEL_DRIVERStartType = 2; SERVICE_AUTO_STARTErrorControl = 1; SERVICE_ERROR_NORMALServiceBinary =% 12% / al.sysLoadOrderGroup = NDIS [a1.AddEventlog] AddReg = al.AddEventLog.reg [a1.AddEventlog.reg] HKR ,, EventMessageFile, Ox00020000, "%% SystemRoot %% / system32 / netevent.dll" HKR, TypeSupported, ServiceName Ox00010001,7AddService instruction Parameters (A1 in the first example), must match the NDI / service value of the component. See Section 1.2.7.9. 1.2.9 NetWorkProrider and PrintProvider Days are considered a network provider because the NetClient component provides network services to users.
NetClient components such as Microsoft Client for Networks and NetWare Client. In addition to the network provider, the NetClient component can also be a print provider. The print provider provides print services to user applications in the network. The NetClient component is always installed as a network provider. The INF file for installing the NetClient component does not require the NetWorkProvider section, unless the following conditions are true: • The replacement device name of this component is illustrated. · To use the net view command, specify a short name for the component (see 1.2.9.1). Install the INF file for the NetClient component of the print provider, you must include a PrinterProvider section for the component (see Section 1.2.9.2). The INF file for installing the NetClient component must also include add-registrg-section (referenced by the AddReg instruction in service-install-section) to add a NetWorkProvider key to the component service key (see 1.2.7.6). 1.2.9.1 Include a NetWorkProvider section NetWorkProvider section describes 1 or two information: The replacement device name of the NetClient component and a short name for the Net View command. In order to create a NetWorkProRider section, add the .NetworkProvider extension to DdInstall sections, examples are as follows: [DDInstall]; InstallSECTION [DDINSTALL.NETWORKPROVIDER]; NetworkProvidection Description When a device name is normal, the network installer passes the component's NDI / The service value (see 1.2.7.9) is copied into the NetworkProvider key under the Component Service key to create a network provider's device name. In order to explain the components, different device names are included in the NetworkProvider section, as shown in the following example: [DDInstall-section.networkProvider] DeviceName = "nwrdr" DeviceName is optional, only in the NDI / Service value as a network provider When the device name is not enough, it will be explained. Note A short name is a short name for the network provider to describe the network provider, which will contain a shortname item in the NetworkProvider section, as shown in the following example: [DDInstall-section.networkProvider] ShortName = "NW" below is An example of a short name used by the NET View command: NET View / N: NWSHortName is easy to print more than the full name of the network provider, and it is easy to print. ShortName is optional and will be described only when needed. 1.2.9.2 Inf files that include a printProvider section Installing the NetClient component (here a print provider) must include the PrintProvider section.
To generate a PrintProvider section, adding section DDInstall extension .PrintProvider, in the following example: [DDInstall-section]; InstallSection [DDInstall-section.printProvider]; PrintProvidersectionPrintProvider section must include the following items: · PrintProviderName a printing instructions provided by Non-local string • PrintProviderDLL Print Provider DLL file name · DisplayName Description Print the local string of the provider name. DisplayName can be different from PrintProviderName. PrintProviderName and PrintProviderDLL items provide some information that are used as the input value of the AddPrintProvider function (the provider_info_1 structure). The AddPrintProvider function adds the print provider component as the print provider. For more information on the AddPrintProvider function, see Platform SDK. Here is an example PrintProvider section: [DDInstall-section.PrintProvider] PrintProviderName = "NetWare or Compatible Network" PrintProviderDll = "nwprovau.dll" DisplayName = "% NWC_Network_Display_Name%" 1.2.10 Winsock section provides INF NetTrans Winsock interface component Files must explain the dependence of Winsock. This INF file must contain a WinsockInstall section. In order to create a WinsockInstall section, add the .winsock extension to the DdInstall section name of the protocol. For example, if the DDInstall section is named IPX, the WinsockInstall section of the protocol must be named ipx.winsock. The Winsock installation festival must contain the AddSock instruction. The AddSock Directive Description Supplier Named section, including the value added to the HKEY_LOCAL_MACHINE / TRANSTDDRIVER-NAME / Params / Winsock button in the component. The section named by the supplier referenced by the AddSock instruction must contain the following value: Value name description TransportService Description Protocol service name REG_SZ value. This must be the same as the NDI / Servce value of the protocol. (See 1.2.7.9) HelperDllname A reg_expand_sz value indicating the WindowsSocketshelper (WSH) DLL of the protocol. See Section 3. MaxSockAddlength A REG_DWORD value illustrates the size of the maximum effective SockAddr, in bytes. MinsockAddlength A REG_DWORD value indicates the size of the minimum and effective socketdr, in bytes.
If you illustrate the optional providerid provided by the namespace, the following value must also be explained: Value name describes ProviderID Description GUID's REG_SZ value, used to sign the namespace provider. GUID as the key of all namespace providers. Get the GUID by running uuidgen.exe. See Platform SDK for details. LibraryPath A REG_EXPAND_SX value indicating the full path of the namespace provider DLL. DisplayString A localized string indicates the name of the namespace provider in the user interface. SupportedSpace A REG-DWORD value indicating a name space supported by the namespace provider. The following values are defined in the name space in Winsock2.h: namespace value NS_ALL 0 NS_SAP 1 NS_NDS 2 NS_PEER_BROWSE 3 NS_TCPIP_LOCAL 10 NS_TCPIP_HOSTS 11 NS_DNS 12 NS_NETBT 13 NS_WINS 14 NS_NBP 20 NS_MS 30 NS_STDA 31 NS_CAIRO 32 NS_X500 40 ns_nis 41 ns_wrq 50
Version An optional REG_DWORD value illustrates the version number of the namespace provider. If this value is not explained, the default value (1) is used. See Platform SDK for details on the namespace provider. Winsock section shows an example of the IPX protocol: [Ipx.Winsock] AddSock = Install.IpxWinsock [Install.IpxWinsock] TransportService = nwlinkpipxHelperDllName = "%% SystemRoot %% / System32 / wshisn.dll" MaxSockAddrLength = Ox10MinSockAddrLength = OxeProviderId = "GUID "Librarypath ="% systemroot% // system32 // nwprovaa.dll "DisplayString =% nwlnkipx_desc% supportednamespace = 1version = 2
By including a WinsockRemove section, the INF file deletes Winsock dependence as a protocol. To create a Winsock-Remove section, add the .winsock extension to the REMOVE section name of the protocol. For example, the REMOVE section name of the protocol is IPX.Remove, then the Winsock-Remove section must be ipx.remove.winsock. The Winsock-Remove section contains a delsock directive, which illustrates an Inf-Writer-name. The Inf-Writer-Named section must explain the transfer service you need to delete. ProviderId If already registered, vendor-named section must be deleted ProviderId description shows two sections deleted Ipx Winsock protocol in Example dependent:. [Ipx.Remove.Winsock] DelSock = Remove.IpxWinsockTransportService = nwlinkipxProviderId = "GUID" 1.2.11 Network Components Installation Demand Summary This section summarizes the following types of network component installation requirements: • Network Adapter · Network Protocol Driver · Intermediate Network Driver · Network Filter Driver · Network Customer · Network Service 1.2.11.1 Network Adapter Installation Demand This section summarizes the installation requirements of the network adapter. General Demand INF Document Festival Status Note Version Requires Class = NetClassGuid = {4D36E972-E325-11CE-08002BE10318} SourceDiskSNames and SourceDiskFiles If .. If INF files are not required to be released with Windows 2000. If the INF file is released with Windows 2000, a LayoutFile item must be explained in the Version section and does not have to SourceDiskNames and SourceDiskFiles. DestinationDIRS requires no special network needs. ControlFlags requires an ExcludeFromSelect item in the INF file that installs Plug and Play (PNP) adapter. For non-PNP adapters, there is no need to list. Manufacturer requires no special network requirements Models require HW-ID to match the hardware ID provided by the PNP manager's adapter. DdInstall requires a value of the Characteristics item: NCF_VIRTUAL, NCF_SOFTWARE_ENUMERATED, NCF_PHYSICAL, NCF_MULTIPORT_INSTANCED_ADAPTER, NCF_HAS_UI, NCF_HIDDEN, NCF_NOT_USER_REMOVABLE. NCF_VIRTUAL, NCF_SOFTWARE_ENUMERATED and NCF_PHYSICAL are mutually exclusive. For physical adapters, the Bustype item is required. For the EISA adapter, the eisacompressedID item is required. This item illustrates the EISA compressed ID and adapter mask. Multi-port network adapter requires Port1DeviceNumber or Port1FunctionNumber items.
DdInstall.Services requires no special network requirements add_reg_sections requires: Creating NDI keys Description Service Related Values Description Bind member relationship (LBFO micro port) Description Binding Interface The binding interface available: UpperRange: NDis5, Ndisatm, NDiswan, NDiscowan, noupper, ndis5_atalk, ndis5_dlc, nids5_ip, ndis5_ipx, ndis5_nbf, ndis5_streamsLowerRange: ethernet, atm, tokenring, serial, fddi, baseband, broadbond, arcnet, isdn, localtalk, Wan options: the need to install additional network components for assembly set a static parameter Advanced Properties Page Description Configuration Parameters Generate Custom Properties Page Strings Requires No Special Network Requires WAN Adapter Additional Requirements The following sections describe additional installation requirements of the WAN adapter: • Describe the number of end points (such as channel, circuit, or bearer channels) · For ISDN Adapter Description And value • Install multi-protocol WAN adapter does not support Remove Section Notification Object 1.2.11.2 Network Protocol Installation Requirements This section summarizes the installation requirements of the network protocol INF File Festival Status Note Version needs class = nettransclassguid = {4D36E973-E325-11CE- BFC1-08002BE10318} SourceDiskNames and SourceDiskFiles If .., if the INF file is not required to release the Windows 2000. If the INF file is released with the Windows 2000, a LayoutFile item must be described in the Version section, which does not use SourceDiskNames and SourceDisksfiles. DestinationDirs requires no special network requirements ControlFlags optional No special network demand Manufacturer requires no special network demand Model requires HW_ID by the provider name, underscore, and manufacturer name or product name as: MS_DLC. DDInstall need Characteristics term value: NCF_HIDDEN, NCF_NO_SERVICE, NCF_NOT_USER_REMOVABLE, NCF_HAS_UI DDInstall.Services optional network needs no special need add_reg_sections need: Create Ndi key bindings interface allows explain the binding interfaces: UpperRange: netbios, ipx, tdi, Winsock, noupper LowerRange: NDIS5, NDISATM, NOLOWER Optional: Setting Static Parameters for Components Requires Other Network Components Installation Description Related Service Values Description Helptext Values For a Notification Object Description Remove Optional WinsockSections Optional Winsock Interface, Winsock_Install is The Winsock-Remove section is optional. Strings requires no online special needs
1.2.11.3 Installation Demand for Intermediate Layer Network Drivers This section summarizes the installation requirements of the intermediate network driver. INF Document Festival Status Note Version Requires Class = Net ClassGuid = {4D36E972-E325-11CE-BFC10802BE-10318} SourceDiskNames and SourceDisksFiles, such as .., if INF files are not released with Windows 2000, this section is required. If the INF file is released with Windows 2000, the LayoutFile item in the Version section must be explained, not using SourceDiskNames and SourceDisksfiles section. DestinationDirs requires no special network requirements ControlFlags optional No special network requirements Manafacture requires no special network requirements Models require hw_id by the provider name, underscore, and manufacturer names or product names such as: MS_DLC DDINSTALL Requirements: NCF_VIRTUAL is required. NCF_HIDDIN and NCF_NOT_USER_REMOVABLE are optional. DdInstall.Services requires no network special demand add-reg-sections requires: Creating NDI keys Description Related Service Value Description Binding Interface Available Binding Interfaces: UpperRange: NDIS5, NDISATM, NDISWAN, NDISCOWAN, NOUPPER, NIDS5_ATALK, NDIS5_DLC, NDIS5_IP , NDIS5_IPX, NDIS5_DIS5_DIS5_S5_DIS5_STREAMSLOWERRANGE: Ethernet, ATM, Tokenring, Serial, FDDI, Baseband, Broadband, ARCNET, ISDN, LOCALTALK, WAN Optional: Setting Static Parameters for components To install other network components Strings require no network special requirements 1.2.11.4 Installation Demand for Network Filter Drivers This section summarizes the INF file requirements of the network filter driver. Installing the network filter driver requires 2 INF files: • One is the serviceInf file provided for the filter service (Class = NetService) · One is the serviceInf file for the filter device (Class = NET) network filter driver
INF File Festival Status Note Version Requires Class = NetServiceClassGuid = {4D36E975-E325-11CE-BFC1-08002Be10318} SourceDiskNames and SourceDisksFiles need, if .. If INF does not release with Windows 2000, this section is required. If the INF file is released with Windows 2000, the layoutfile item in the Version section must be described, not using SourceDisnames and SourceDisksfiles section. DestinationDIRS requires no special network requirements ControlFlags optional No special network requirements Manufacturer requires no special network requirements Models require HW_ID by the provider name, underscore and manufacturer names or product names. Such as: MS-DLC DdInstall requires a CHARACTERISTICS item: NCF-Filter is required. NCF_HAS_UI and NCF_NO_SERVICE are optional. Optional DDInstall.Services need: generating a filter Service Key Description Ndi value: FilterClass, FilterDeviceInfFile, FilterDeviceInfId, FilterMediaTypes described binding interfaces: UpperRange: noupperLowerRange: nolower Optional: setting static parameters need to install additional network components described a component value HelpText Note that a value of a notification object Remove can do not special network requirements Network filter driver DeviceInf file INF file section status NetclassGUID = {4D36E972-E325-11CE-BFC1-08002BE10318} ControlFlags requires this section Contains ExcludeFromSelect Item Manufacturer requires no special network requirements Models require HW_ID consisting of the provider name, underscore, and manufacturer name or product name. Such as: ms_dlc. DdInstall needs a Characteristics item: NCF_VIRTUAL is necessary. NCF_HIDDEN and NCF_NOT_USER_REMOVABLE are optional. DdInstall.service requires the serviceName value of the Addservice instruction to match the filter component service value under the NDI key. Add_reg_sections requires: Creating NDI keys Description Service Related Values Optional: Setting Static Parameters for Components Requires Strings for Other Network Components Strings requires no special network requirements
1.2.11.5 Network Customer Installation Demand This section summarizes the installation requirements of Network Customers INF File Festival Status Note Version Requires Class = NetClientClassGuid = {4D36E974-11CE0-BFC1-08002Be10318} SourceDisksNames and SourceDisksFiles need, if .. If INF file is not Windows 2000 is released, which is required. If the INF file is released with Windows 2000, the LayoutFiles item in the Version section must be explained, not using SourceDiskNames and SourceDisksfiles. DestinationDirs requires no special network requirements ControlFlags optional network requirements Manufacturer requires no special network requirements Models require HW_ID by the provider name, underscore, and manufacturer name or product name. Such as: ms_dlc. DDInstall need Characteristics items available values: NCF_HIDDEN, NCF_NO_SERVICE, NCF_NOT_USER_REMOVABLE, NCF_HAS_UI DDInstall.Services optional network needs no special need Add_reg_section need: Create Ndi key Description bound interfaces bound interfaces available: UpperRange: noUpperLowerRange: ipx, tdi, Winsock, NetBIOS, NOLOWER Optional: Setting Static Parameters for Components Required to install other component Description Service Related Values Description Helptext Value Description Notification Objects Remove Optional NetWorkProvider, such as .., is required. This section is required if the network customer's alternative device name is illustrated, or for a short name for the component to use the Net View command. PrintProvider, such as .., you need. If the network customer is a print provider, the section is required. Strings requires no special network needs.
1.2.11.6 Installation of Network Services Requirements This section summarizes the installation request for network services. INF Document Festival Status Note SourceDisksNames and SourceDisksFiles if .. If the INF file is not released with Windows 2000, this section is required. If the INF file is released with Windows 2000, the layoutfile item in the Version section must be explained, not using SourceDiskNames and SourceDisksfiles section. DestionationDIRS requires no special network requirements ControlFlags optional No special network requirements Manufacturer requires no special network requirements Models require HW_ID by the provider name, underscore, and manufacturer name or product name. Such as: ms_dlc. DDInstall need Characteristics items available values: NCF_HIDDEN, NCF_NO_SERVICE, NCF_NOT_USER_REMOVABLE, NCF_HAS_UI DDInstall.Service optional network without special needs add-reg-sections need to need to: create Ndi key bindings description available interfaces bound interfaces: UpperRane: noupperLawerRange: ipx, TDI, WINSOCK, NETBIOS, NOLOWEROPTIONAL: Set static parameters for components Requires additional network components Description Service Related Values Description HelptExt Value Description Notification Objects Remove Optional Strings requires no special network demand xgbing
9CBS certified blog expert
Drive development
ARM development
Embedded hardware
Software and hardware design and development focusing on embedded direction (ASM \ C \ C , RTOS, Linux, Android, Ethernet \ embedded network protocol stack, Bluetooth, WiFi, file system / embedded storage, display \ audio, microcontroller \ DSP \ ARM \ Cortex, Circuit Design \ PCB Board \ Hardware Drive \ Digital Logic CPLD, FPGA \ Niosii), currently engaged in VirtualBox \ QEMU \ KVM virtualization research work.
