Date: Thu, 6 Aug 2015 20:06:07 -0700 Subject: Remove obsolete readme.htm files --- network/config/bindview/bindview.htm | 345 ------------ network/modem/fakemodem/fakemodem.htm | 926 -------------------------------- network/ndis/filter/filter.htm | 152 ------ network/ndis/mux/driver/60/mux.htm | 617 --------------------- network/ndis/mux/notifyob/notify.htm | 552 ------------------- network/ndis/ndisprot/6x/ndisprot.htm | 393 -------------- network/ndis/ndisprot_kmdf/ndisprot.htm | 197 ------- 7 files changed, 3182 deletions(-) delete mode 100644 network/config/bindview/bindview.htm delete mode 100644 network/modem/fakemodem/fakemodem.htm delete mode 100644 network/ndis/filter/filter.htm delete mode 100644 network/ndis/mux/driver/60/mux.htm delete mode 100644 network/ndis/mux/notifyob/notify.htm delete mode 100644 network/ndis/ndisprot/6x/ndisprot.htm delete mode 100644 network/ndis/ndisprot_kmdf/ndisprot.htm (limited to 'network') diff --git a/network/config/bindview/bindview.htm b/network/config/bindview/bindview.htm deleted file mode 100644 index c28f6190..00000000 --- a/network/config/bindview/bindview.htm +++ /dev/null @@ -1,345 +0,0 @@ - - - - - - - - -BINDVIEW: Network Configuration/Installation Sample - - - - - - - -

- -

BINDVIEW: Network -Configuration/Installation Sample

- -

SUMMARY

- -

This sample demonstrates -how to use INetCfg APIs to enumerate, install, -uninstall, bind and unbind network components.

- -

The sample compiles -properly for 64-bit systems and builds properly with Microsoft® Visual C® 6.0.

- -

BUILDING THE SAMPLE

- -

To build the sample, type build. This command produces the binary -bindview.exe.

- -

INSTALLING THE SAMPLE

- -

Copy the -binary bindview.exe to the directory from which you want to run the sample.

- -

RUNNING THE SAMPLE

- -

Type bindview.exe at the command prompt to run the program. You can perform the following -operations.

- -

Install a network protocol, - service or client component.
Uninstall a network protocol, - service or client component.
By clicking the right mouse - button on a network protocol, service or client, you can perform the - following operations.

Bind the network component - to another component.
Unbind the network component - from another component that is bound to it.

By clicking the right mouse - button on a binding path, you can perform the following operations.

Disable the binding path if - it is enabled.
Enable the binding path if - it is disabled.

Save the binding information - to a file.

- -

CODE TOUR

- -

File Manifest

- -

File           Description

BINDVIEW.CPP   Contains WinMain and dialog box related functions.

NetCfgAPI.cpp  Contains INetCfg functions.

BINDING.CPP    Contains binding path related functions.

Component.cpp  Contains network component related functions.

RESOURCE.H     Resource header.

BINDVIEW.H     Contains function prototypes.

NetCfgAPI.h    Contains function prototypes for NetCfgAPI.cpp

BindView.rc    Resources for Bindview

BindView.ico   Icon for the sample.

- -

Top of page

- - - - - -

- -

- - - - diff --git a/network/modem/fakemodem/fakemodem.htm b/network/modem/fakemodem/fakemodem.htm deleted file mode 100644 index add195f7..00000000 --- a/network/modem/fakemodem/fakemodem.htm +++ /dev/null @@ -1,926 +0,0 @@ - - - - - - - -UNIMODEM sample controller-less modem driver (fakemodem) - - - - - - - - - -

- -

UNIMODEM sample controller-less modem driver (Fakemodem)

- -

SUMMARY

- -

This -sample demonstrates a simple controller-less modem driver. This -driver supports sending and receiving AT commands using the ReadFile/WriteFile calls or via a TAPI interface using an -application such as HyperTerminal.

- -

BUILDING THE SAMPLE

- -

Click -the Free Build Environment or Checked Build Environment icon under Development -Kits program group to set basic environment variables.

- -

Change -to the directory containing the device source code, such as CD src\wdf\fakemodem. -

- -

Run build --ceZ, or use the macro BLD. This command -invokes the Microsoft make routines to build the components. If the build succeeds, you will find the driver, fakemodem.sys, placed in a platform -specific subdirectory -src\network\modem\fakemodem\$(OBJ_PATH)\$O. If it fails you can find errors and warnings in the -buildxxx.err and buildxxx.err respectively, where xxx is either chk or fre depending on the build -environment.

- -

INSTALLATION

- -

To -install and test this driver, you do not need any real hardware. You can -install this driver either using Devcon.exe (ddk\tools\devcon) utility from the DDK or using toaster bus driver -sample.

- -

To install the bus driver on Windows XP and Windows Server 2003:

- -

Double-click the ‘Add Hardware’ - wizard in Control Panel.
At the 'Welcome to the Add - Hardware Wizard', click ‘Next’.
Select 'Yes, I have already - connected the hardware', then click Next.
Select ‘Add a new hardware - device’ from the list, then click Next.
Select ‘Install the hardware - that I manually select from a list(Advanced),' and then click next.
Select ‘Modems’, then click - Next.
Check the box which says - "Don't detect my modems; I will select it from a list.", then - click Next.
Click 'Have Disk', make sure - that 'A:\' is in the "Copy manufacturer's files from:" box, and - click OK.
Click on the desired entry, and - then click Next.
At 'The wizard is ready to - install your hardware', click Next.
Click Finish at 'Completing the - Add/Remove Hardware Wizard.'

- -

To install the -driver using toaster bus:

- -

· -Install the toaster bus driver. -Information on how to install the toaster bus driver is given in src\general\toaster\toaster.htm readme file.

- -

· -Run the notify.exe (src\general\toaster\exe\notify) and choose Plug In a device -in the Bus menu.

- -

· -In the plug in dialog, specify -{b85b7c50-6a01-11d2-b841-00c04fad5171}\fakemodem as -the Hardware Id and click okay.

- -

The bus driver will enumerate a -device with the hardware id provided by the application. At this point:

- -

On -Windows XP and later:

- -

"Found New Hardware Wizard" - dialog box will appear. Here select the radio button labeled "Install - from a list of specific location (Advanced)" and then hit the - "Next" button.
In the following screen select the - radio button labeled " Search the best driver in these - locations" and then select "Include this location in the search - path" and specify the target media or the directory where the KMDF - coinstaller (wdfcoinstallerMMmmm.dll), INF and SYS files are copied and - then hit the "Next" button.
The system will scan the directory and - pick up the matching INF and start the installation. You will get a - Hardware Installation Warning dialog stating that your driver has not - passed Windows Logo Testing. Hit "Continue Anyway" button.
The system will copy the driver, INF - file, load the driver and start the device. If every thing goes fine, you - will get "Completing the Found New Hardware Wizard". Hit the - "Finish" button and the installation is complete.
You should be able to see the device - in the Device manager under "Modems"

- -

On -Windows 2000:

- -

"Found New Hardware Wizard" - dialog box will appear with the description of the device. Here click - "Next" button.
In the following screen "Install - Hardware Device Driver", select the radio button labeled "Display - a list of known drivers for this device..." and then click - "Next" button.
In the following dialog on - "Hardware Type", select "Other Devices" from the list - and click "Next".
In the dialog on "Select a Device - Driver", click on "Have Disk".
Specify the target media or the - directory where the KMDF coinstaller (wdfcoinstallerMMmmm.dll), INF and - SYS files are copied and then hit the "Okay" button.
Select "OSR" in the - Manufacture section selection and click "Next".
Click "Next" on the - "Start Device Driver Installation" dialog.
Click Finish at 'Completing the - Add/Remove Hardware Wizard.'

- -

Note that if you get a warning dialog with -regards to Windows Logo, or unsigned drivers, testing then click on continue.

- -

USAGE

- -

Once -installed, you can talk to the fakemodem driver -through HyperTerminal, or via ReadFile/WriteFile calls. The -AT command set supported by fakemodem includes:

- -

AT returns OK
-
- ATA returns CONNECT

- -

ATD<number> returns CONNECT

- -

CODE -TOUR

- -

File -Manifest

- -

File           Description

readwrit.c    Routines for receiving and sending text. This includes processing AT commands.

Driver.c              Fakemodem driver initialization entry points and for handling Plug & Play events.

ioctl.c               Routines to handle IOCTL messages.

mdmfake.inf   INF file for installing the fakemodem driver

- -

Top -of page

- - - - - -

- -

- - - - diff --git a/network/ndis/filter/filter.htm b/network/ndis/filter/filter.htm deleted file mode 100644 index 998c5b49..00000000 --- a/network/ndis/filter/filter.htm +++ /dev/null @@ -1,152 +0,0 @@ - - - - - -NDISLWF - - - - -

NDISLWF.SYS - Sample NDIS 6.0 Filter Driver

- -

Note: the sample driver contains some extra code for demonstration purposes. -You should remove unneeded optional sections from a production driver.

- -

SUMMARY

- -

Ndislwf NDIS 6.0 Filter Driver

- -

The Ndislwf sample is currently a do-nothing pass-through NDIS 6 filter -driver that demonstrates the basic principles underlying an NDIS 6.0 Filter -driver. The sample is a replacement of NDIS 5 Sample Intermediate -Driver (Passthru driver).

- -

Although the filter driver is a Modifying filter driver, the filter driver -currently doesn’t modify any packets and it only re-packages and sends down all -OID requests. You may easily update this filter driver to change packets -before passing them along. Or you may use the filter to originate new packets -to send or receive. For example, the filter could encrypt/compress outgoing and -decrypt/decompress incoming data.

- -

BUILDING THE SAMPLE

- -

Run the build command from this directory to build the -sample—it creates the binary Ndislwf.sys.

- -

To install this driver on Windows Vista (or above), use netlwf.INF also -found in this DDK.

- -

INSTALLING THE SAMPLE

- -

Ndislwf is installed as a service (called “NDIS Sample LightWeight Filter” -in the supplied INF). To install, follow the steps below:

- -

Prepare a an installation directory that contains these files: netlwf.inf -and ndislwf.sys.
On the desktop, click Start, then open Control Panel, then -open Network and Internet Connections, then open Network -Connections, then right-click on the relevant Local Area Connection icon -and choose Properties.
Click Install, then Service, then Add, then Have -Disk.
Browse to the drive/directory containing the files listed above. Click -OK. This should show “NDIS Sample LightWeight Filter” in a list of -Network Services. Highlight this and click OK. This should install the -Ndislwf filter driver.
Click OK or Yes each time if the system prompts with a warning -regarding installation of unsigned files. This is necessary because binaries -generated via the LDK build environment are not signed.

- -

CODE TOUR

- -

File Manifest

- - - - - - - - - - - - - - - - - - - - - - - - - - - -

File	Description
makefile	Used during compilation to create the object and sys -files
filter.c	Filter driver entry points and related functions in -the Ndislwf filter driver
netlwf.inf	Installation INF for the service
device.c	Virtual device related routines such as registering a -device and handling IOCTLs
filter.h	Prototypes of all functions and data structures used -by the Ndislwf driver
filter.htm	Documentation for the filter driver (this - file)
filter.rc	Resource file for the Ndislwf driver
precomp.h	Precompile header file
flt_dbg.c	Debug-related code
flt_dbg.h	Debug code definitions and structures
sources	List of source files that are compiled and linked to -create the ndislwf driver.

- -

Programming Tour

- -

Basic steps in attaching and detaching of Ndislwf driver:

- -

During DriverEntry, the ndislwf driver registers as a NDIS 6 filter -driver.
Later on, NDIS calls Ndislwf FilterAttach handler, for each underlying NDIS -adapter on which it is configured to attach.
In the context of FilterAttach Handler, filter driver call NdisFAttribute -to register its filter module context with NDIS. After that, filter driver can -read its own setting in registry by calling NdisOpenConfigurationEx, and calls -NdisXXX functions.
After FilterAttach successfully returns, NDIS restarts the filter later by -calling FilterRestart handler. FilterRestart should prepare to handle -send/receive data. After restart return successfully, filter driver should be -able to process send/receive.
All requests and sends coming from overlying drivers for the Ndislwf filter -driver are repackaged if necessary and sent down to NDIS, to be passed to the -underlying NDIS driver.
All indications arriving from an underlying NDIS driver are forwarded up by -Ndislwf filter driver.
NDIS call FilterPause handler when NDIS needs to detach the filter from the -stack or there is some configuration changes in the stack. In processing the -pause request from NDIS, the Ndislwf driver waits for all its own outstanding -requests to be completed before it completes the pause request.
NDIS calls the Ndislwf driver’s FilterDetach entry point when NDIS needs to -detach a filter module from NDIS stack. FilterDetach handler should free all -the memory allocation done in FilterAttach, and undo the operations it did in -FilterAttach Handler.

- -

- - - - diff --git a/network/ndis/mux/driver/60/mux.htm b/network/ndis/mux/driver/60/mux.htm deleted file mode 100644 index 8a590061..00000000 --- a/network/ndis/mux/driver/60/mux.htm +++ /dev/null @@ -1,617 +0,0 @@ - - - - - - - - -MUX Intermediate Miniport Driver Help - - - - - - - - - - - - -

- -

MUX.SYS - Sample NDIS -MUX Intermediate Driver

- -

SUMMARY

- -

MUX Intermediate Miniport Driver

- -

The MUX Intermediate -Miniport (IM) driver is an NDIS 6.0 driver that demonstrates the operation of -an “N:1” MUX driver, i.e. one which creates multiple -virtual network devices on top of a single lower adapter. Protocols bind to -these virtual adapters as if they are real adapters. Examples of Intermediate Miniport drivers that can use this -framework are Virtual LAN (VLAN) drivers.

- -

This sample implements -IEEE 802.1Q VLAN tagging, which is enabled by changing the default VLAN ID to a -non-zero valid value (see “Configuring VLANs” below).

- -

Operation

- -

The driver binds to -Ethernet (NdisMedium802_3) adapters as a protocol, and exposes one or more -virtual Ethernet devices over each lower adapter, based on its configuration. -The term “VELAN” is used to denote a Virtual Ethernet LAN adapter implemented -by this driver.

- -

When it binds to a lower -adapter, MUX reads the standard “UpperBind” key to obtain a list of VELANs -configured over this adapter. For each such VELAN, it calls NdisIMInitializeDeviceInstanceEx() -to instantiate the NDIS miniport for the VELAN. NDIS then calls the driver’s -MiniportInitialize (MPInitialize) routine to start the VELAN miniport.

- -

The MUX driver supports -configuring the MAC address for each VELAN miniport using the standard -“NetworkAddress” key that it reads from its MiniportInitialize routine. If this -is not configured, it computes a “locally significant” MAC address for the -VELAN using the MAC address of the lower adapter. The MUX driver sets its lower -adapter to promiscuous mode in order to be able to receive frames directed to -any of the VELAN MAC addresses. However it does implement -packet-filtering (and multicast address filtering) logic for all its VELAN -miniports so that it only passes up relevant frames on each VELAN. This -aspect of the driver may be modified if, for example, your driver design uses -the same MAC address as that of the lower adapter on all VELANs. With such a -modification, it is not required to set the lower adapter to promiscuous mode -and incur the costs of receiving all packets on the network.

- -

It supports dynamic -addition and deletion of VELANs in conjunction with its -notify object (related sample). If a VELAN is deleted, the virtual device -corresponding to the VELAN is stopped and removed, which in turn results in -NDIS halting the miniport instance for the VELAN (see MPHalt). If a -VELAN is added, NDIS sends a global reconfiguration event to the protocol edge -of this driver. The handler function for this event, PtPNPHandler, goes through -all lower adapters to see if any new VELANs have been added, i.e. if any of the -“UpperBind” keys have been modified.

- -

Since the driver -implements a virtual device, it does not simply pass through most NDIS -queries/sets. It keeps its own device view that is reflected in its responses -to queries/sets. However it does pass through queries/sets for certain OIDs -that are best handled by the lower adapter driver.

- -

The driver supports Power -Management in the sense that it allows Wake-On-LAN and related functionality, -if supported by the lower adapter, to continue to function. It does so by -appropriately forwarding OID_PNP_XXX queries/sets to the lower adapter.

- -

IEEE -802.1Q VLAN Operation

- -

The driver supports -configuring a VLAN ID on each VELAN. It then inserts a tag header containing -this VLAN ID on all outgoing frames. For incoming frames that contain a tag -header, it verifies that a matching VLAN ID is present before indicating it up -to protocols. It removes the tag header, if present, from all indicated frames. -In all cases, received frames that do not contain tag headers are always handed -up to protocols.

- -

With the default -configured VLAN ID of zero, the driver does not insert tag header information -on sent packets, except for sent packets that contain non-zero Ieee8021QInfo -per-packet information, for which the driver does insert corresponding tag -headers. Receive-side filtering on VLAN ID is enabled only with a non-zero -configured VLAN ID, in which case only received frames containing a matching -VLAN ID are passed up. With the default configured VLAN ID of zero, the driver -does not check the VLAN ID on received frames.

- -

BUILDING THE SAMPLE

- -

Run the build -command from this directory to build the sample—it creates the binary mux.sys. -To disable IEEE VLAN support, comment out the following line in the sources -file before building:

- -

C_DEFINES=$(C_DEFINES) -–DIEEE_VLAN_SUPPORT=1

- -

To install this driver on -Windows® codename Whistler, use the MUX sample notification object and INFs, -also found in this DDK.

- -

INSTALLING THE SAMPLE

- -

MUX is installed as a -protocol (called “Sample Mux-IM Protocol Driver” in -the supplied INFs/notification object). To install, follow the steps below.

- -

Prepare a floppy disk (or -installation directory) that contains these files: muxp.inf, -mux_mp.inf, mux.sys and mux.dll (notification object -DLL, built in this DDK at network\ndis\mux\notifyob).

- -

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

- -

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

- -

Click Install, -then Protocol, then Add, then Have -Disk.

- -

Browse to the -drive/directory containing the files listed above. Click OK. This should -show “Sample Mux-IM Protocol Driver” in a list of -Network Protocols. Highlight this and click OK. This should install the -MUX driver.

- -

Click OK or Yes each time the system prompts with a warning -regarding installation of unsigned files. This is necessary because binaries -generated via the DDK build environment are not signed.

- -

Two .INF files are needed -rather than one because MUX is installed both as a protocol and a miniport.

- -

Configuring -VLANs

- -

The VLAN ID for each -VELAN (virtual miniport) can be configured as follows. Right-click on the -virtual miniport Local Area Connection icon and choose Properties. Click on the Configure -button to bring up the Device Manager UI for the virtual device. Select the Advanced property sheet – this should -contain a “VLAN ID” parameter that is configurable to the desired VLAN ID. -Choosing a value of 0 (zero) disables receive-side filtering based on VLAN ID.

- -

CODE TOUR

- -

File Manifest

- -

File           Description

Makefile       Used during compilation to create the object and sys files

Miniport.c     Miniport related routines for the MUX driver

Mux.c          DriverEntry routine and any routines common to the MUX miniport and protocol

Mux.h          Prototypes of all functions and data structures used by the MUX driver

Mux.htm        Documentation for the MUX driver (this file)

Mux.rc         Resource file for the MUX driver

Muxp.inf       Installation INF for the service (protocol side installation)

Mux_mp.inf     Installation INF for the miniport (virtual device installation)

Precomp.h      Precompile header file

Protocol.c     Protocol related routines for the MUX driver

Sources        List of source files that are compiled and linked to create the MUX driver. This can be modified to create binaries that operate on previous Windows versions (e.g. Windows 2000).

- -

Programming Tour

- -

When it loads, i.e. from its DriverEntry -function, the MUX driver registers as an Intermediate miniport driver and as a -protocol, in that order.

- -

Binding and VELAN Creation

- -

NDIS calls MUX’s BindAdapter -function, PtBindAdapter, for each underlying NDIS adapter to which it is -configured to bind. This function allocates an ADAPT structure to represent the -lower adapter, and calls NdisOpenAdapter to set up a binding to it. In the -context of BindAdapterHandler, after successfully opening a binding to the -underlying adapter, the driver queries the reserved keyword -"UpperBindings" to get a list of device names for the virtual -adapters that this particular binding is to expose – see PtBootStrapVElans -for more details. Note that the MUX driver does not create bindings (i.e. call -NdisOpenAdapter) from any context other than its BindAdapter function – this is -recommended behavior for all drivers of this type.

- -

For each device name specified in -the “UpperBindings” key, the MUX driver allocates a VELAN data structure to -represent the virtual miniport, calls NdisIMInitializeDeviceInstanceEx. In -response, NDIS eventually calls the MUX miniport’s MiniportInitialize entry -point, MPInitialize, for each VELAN. After MPInitialize -successfully returns, NDIS takes care of getting upper-layer protocols to bind -to the newly created virtual adapter(s).

- -

Unbinding and Halting

- -

NDIS calls MUX’s UnbindAdapter -handler, PtUnbindAdapter, to request it to unbind from a lower adapter. -In processing this, MUX calls NdisIMDeInitializeDeviceInstance for each VELAN -instantiated on the indicated adapter – see PtStopVElan for details. -This call results in NDIS first unbinding any protocols bound to the indicated -VELAN, and then calling the MiniportHalt routine, MPHalt, for that -VELAN. MPHalt waits for any outstanding receives/sends on the VELAN to -finish before unlinking the VELAN from the ADAPT.

- -

PtUnbindAdapter itself blocks until all VELANs -associated with the ADAPT structure have been unlinked from it. This is to make -sure that no thread running in the context of a miniport-edge entry point for a -VELAN will ever access an invalid lower binding handle. Once all VELANs have -been unlinked, PtUnbindAdapter closes the lower binding by calling -NdisCloseAdapter. Note that the MUX driver does not close its lower binding -from any context other than its UnbindAdapter function – this is recommended -behavior for all drivers of this type.

- -

MPHalt may also be called if the VELAN -device is disabled, e.g. from the Network Connections Folder. There is no -special code within MPHalt to handle this condition. However, PtUnbindAdapter -takes care to not attempt to deinitialize a VELAN miniport (via -NdisIMDeInitializeDeviceInstance) that has already been halted.

- -

Handling Queries

- -

MPRequest is the MUX driver’s function that -handles queries for OID values on VELAN miniports. Most of the “Ethernet” type -information for the virtual miniport is stored in the VELAN structure itself, -and the driver returns information from this structure. The queries that are -forwarded are OID_GEN_MEDIA_CONNECT_STATUS, OID_PNP_CAPABILITIES and -OID_PNP_WAKE_UP_PATTERN_LIST. See “Handling Power Management” below for more -information about the latter two OIDs.

- -

Handling Sets

- -

MPRequest handles setting OID values on -VELAN miniports. Data management OIDs handled by the MUX driver are -OID_802_3_MULTICAST_LIST and OID_GEN_CURRENT_PACKET_FILTER. The multicast list -is handled entirely within the MUX driver – it just stores the set of multicast -addresses in the VELAN structure, for reference during receive-side data -processing. The packet filter is handled in a different way – the MUX driver -combines the packet filter settings (bitwise OR) of all VELANs associated with -the same lower adapter. If the combined packet filter is non-zero, MUX sends a -Set request with a value of NDIS_PACKET_TYPE_PROMISCUOUS for -OID_GEN_CURRENT_PACKET_FILTER to start receives on the lower adapter. If the -combined packet filter is zero, MUX sets the lower adapter’s packet filter to 0 -(turns off all receives if there aren’t any interested protocols).

- -

Note that setting the lower -adapter to promiscuous mode is only done here in order to be able to receive unicast frames directed to multiple MAC addresses. If, for -example, all VELANs are assigned the same MAC address (which is identical to -the address of the lower adapter), then the MUX driver should only pass down -the combined (bitwise OR) setting of packet filter settings of all VELANs.

- -

Some power management OIDs are -forwarded to the lower miniport. See “Handling Power Management” below for -details.

- -

Sending Data

- -

Data sent down on a VELAN miniport -is forwarded to the lower adapter. The MUX driver itself does not generate any -data of its own. The MUX driver clones a NET_BUFFER_LIST for each NetBufferList passed to its MPSendNetBufferLists -function, and saves a pointer to the original NET_BUFFER_LIST in the reserved -area of the NET_BUFFER_LIST structure. When the lower adapter completes the -send (PtSendNBLComplete), MUX picks up the -original packet and calls NdisMSendNetBufferListsComplete -to complete the original send request.

- -

If a non-zero VLAN ID is -configured for the VELAN, and/or the packet has non-zero Ieee8021QInfo -per-packet information, then the MUX driver inserts an NDIS buffer containing a -tag header to the front of the packet before sending it down – see function MPHandleSendTagging for details.

- -

Receiving Data

- -

Data received from a lower adapter -is indicated up on zero or more VELANs. The PtReceiveNBL -function is called for each NetBufferList received -from the lower adapter. The received data is checked for matches with the -packet filter and multicast list for each VELAN associated with the adapter -(see PtMatchPacketToVElan). Whenever a match is found, a new NET_BUFFER_LIST -is allocated and set to point to the received data. A pointer to the original -received NET_BUFFER_LIST (if any) is also stored in the new NET_BUFFER_LIST’s -reserved area. This packet is indicated up via NdisMIndicateReceiveNetBufferLists -to all interested protocols on that VELAN.

- -

The driver’s MPReturnNetBufferLists -function is called either by NDIS or by MUX itself when protocols are done with -a received NET_BUFFER_LIST. This function returns the original NET_BUFFER_LIST -indicated by the lower driver, if any, by calling NdisReturnNetBufferLists.

- -

The driver indicates up received -frames that do not have an IEEE 802.1Q tag header in them – see function PtHandleRcvTagging. It always strips off -tag headers, if present, on received frames. If a non-zero VLAN ID is -configured, then it checks received frames that contain tag headers for -matching VLAN Ids – only matching frames are indicated up to protocols. Any -VLAN/priority information present in incoming frames is copied to per-packet -information fields of indicated NET_BUFFER_LIST structures.

- -

Status Indications

- -

The only status indications that -are forwarded up by MUX are media connect status indications. See PtStatus -for more details.

- -

Handling Power Management

- -

During initialization (MPInitialize), -the MUX miniport sets the attribute NDIS_ATTRIBUTE_NO_HALT_ON_SUSPEND in -its call to NdisMSetMiniportAttributes. When the MUX -miniport is requested to report its Plug and Play capabilities -(OID_PNP_CAPABILITIES), the MUX miniport forwards the request to the underlying -miniport. If this request succeeds, then the MUX miniport overwrites the -following fields before successfully completing the original request:

- -

NDIS_DEVICE_POWER_STATE MinMagicPacketWakeUp = -NdisDeviceStateUnspecified;

- -

NDIS_DEVICE_POWER_STATE MinPatternWakeUp= -NdisDeviceStateUnspecified;

- -

NDIS_DEVICE_POWER_STATE MinLinkChangeWakeUp=NdisDeviceStateUnspecified

- -

See PtPostProcessPnPCapabilities -for details.

- -

OID_PNP_SET_POWER and -OID_PNP_QUERY_POWER are not passed to the lower adapter, since the lower layer -miniport will receive independent requests from NDIS.

- -

NDIS calls the MUX driver’s -ProtocolPnPEvent function (PtPNPHandler) whenever the underlying adapter -is transitioned to a different power state. If the underlying adapter is -transitioning to a low power state, the driver waits for all outstanding sends -and requests to complete.

- -

Queries/sets received on a VELAN -miniport that are to be forwarded to the underlying adapter are queued on the -VELAN if the underlying adapter is at a low power state. These are picked up -for processing on receiving a notification that the underlying adapter is back -to a powered-up state.

- -

Handling Global Reconfiguration

- -

All modifications to VELAN -configuration are accompanied by PnP reconfigure notifications, i.e. -NetEventReconfigure events passed to the MUX’s PnPEventHandler, PtPNPHandler. -This driver takes a broad approach to handling reconfiguration, which is to -simply re-examine all the “UpperBindings” keys for all currently bound -adapters, and start off VELANs for any that do not exist – see PtBootStrapVElans -for details.

- -

Canceling Sends: MUX propagates send -cancellations from protocols above it to lower miniports.

- -

Top of page

- - - - - -

- -

- - - - diff --git a/network/ndis/mux/notifyob/notify.htm b/network/ndis/mux/notifyob/notify.htm deleted file mode 100644 index 6fe84b68..00000000 --- a/network/ndis/mux/notifyob/notify.htm +++ /dev/null @@ -1,552 +0,0 @@ - - - - - - - - -Mux.dll - Sample Notify Object - - - - - - - - - - -

- -

MUX.DLL – Sample Notify Object

- -

SUMMARY

- -

MUX Notify Object

- -

This sample demonstrates -how to write a notify object for installing and configuring an NDIS MUX intermediate -miniport (IM) driver that implements an N:1 relationship between upper and -lower bindings, i.e. it creates multiple virtual network devices on top of a -single lower adapter. Protocols bind to these virtual adapters as if they are -real adapters. Examples of Intermediate - Miniport drivers that can -use this type of notify object are Virtual LAN (VLAN) -drivers.

- -

Operation

- -

During installation, the -notify object performs the following operations.

- -

· -It -creates one virtual adapter for each physical adapter the MUX protocol edge -binds to.

- -

· -It -disables the bindings of other protocols such as TCP/IP to physical adapters if -it has been compiled with DISABLE_PROTOCOLS_TO_PHYSICAL defined in the Sources -file. This is the most commonly desired behavior for N:1 MUX drivers.

- -

· -It -disables the bindings of the protocol edge of the MUX IM driver with all its -virtual adapters.

- -

The notify object -provides a custom property page for the MUX IM driver. The custom property page -allows the user to add one or more virtual adapters on top of a physical -adapter or delete an existing virtual adapter.

- -

When the MUX IM driver is -uninstalled, or binding is disabled, or the user deletes all the virtual -adapters on top of a physical adapter, the notify object restores the bindings -of other protocols to the physical adapter if it has been compiled with the -preprocessor flag DISABLE_PROTOCOLS_TO_PHYSICAL defined in the Sources file.

- -

Windows 2000 Specific

- -

During the installation, -the notify object copies the INF file for the virtual adapter from the -installation media to the system INF directory by using the SetupCopyOEMInf -function. This is done because Windows 2000 does not support the CopyINF directive to copy INF files from another INF file.

- -

BUILDING THE SAMPLE

- -

To -build the sample, type build -ceZ. This command produces the binary -mux.dll, which is the sample notify object.

- -

The sample compiles -properly for 32-bit and 64-bit systems, and builds properly with Microsoft® -Visual C® 6.0.

- -

Preprocessor Flags:

- -

DISABLE_PROTOCOLS_TO_PHYSICAL

- -

When this flag is defined -in the Sources file, the notify object disables the bindings of other protocols -such as TCP/IP to the physical adapters during the installation. When all the -virtual adapters are removed either through the custom property page or as a -result of uninstalling the MUX driver, the notify object re-enables those -bindings.

- -

PASSTHRU_NOTIFY

- -

This flag is defined to -allow the MUX driver to be used in a passthru mode. When this flag is defined, -the notify object:

- -

1) -Creates -only one virtual miniport for every physical adapter the MUX protocol edge -binds to.

- -

2) -Disables -the property page to prevent adding of additional virtual miniports.

- -

3) -Stores -the device name of the virtual adapter in REG_SZ registry value under -HKLM\System\CurrentControlSet\Services\muxp\Parameters\Adapters\{PhysicalAdaptersInstanceGuid}\UpperBindings, -because there is one to one binding. In the MUX mode (when this flag is not -defined), the notify object stores the device name in a REG_MULTI_SZ registry -value as there could be more than one virtual miniports.

- -

You -can also use this notify object with the Passthru driver by doing the -following:

- -

1) -Change -the protocol name in file src\network\ndis\passthru\passthru.c -from PASSTHRU to MUXP.

- -

2) -Change -the driver name from Passthru to MUX in the sources file.

- -

3) -Rebuild -the driver to obtain a mux.sys driver binary.

- -

4) -Build -the MUX notify object with PASSTHRU_NOTIFY defined.

- -

5) -Use -the MUX inf files, muxp.inf and mux_mp.inf, to -install the driver and dll.

- -

The benefit of using -techniques in the MUX notify object for a 1:1 intermediate driver (e.g. -Passthru) is to be able to exercise higher level of control over the bindings -of MUX with other components in the system, which is not possible with the IM -filter driver.

- -

CUSTOM_EVENTS

- -

When this macro is -defined, the notify object shows how to send custom events to the MUX IM driver -when a virtual miniport is added or removed.

- -

CODE TOUR

- -

File Manifest

- -

File           Description

Dllmain.cpp    File containing implementations of DLL entry point and exports.

Implinc.cpp    File including source code for ATL utilities.

mux.htm        The documentation for this sample.

Pch.h          Pre-compiled header file.

Resource.h     The resource header.

notify.cpp     Notify object implementation.

virtual.cpp    Virtual adapter class implementation.

adapter.cpp    Physical adapter class implementation.

common.cpp     Global functions, variables and macro definitions.

mux.def        The sample's linker definition file.

mux.h          The header file for mux.cpp.

virtual.h      Virtual adapter class declaration.

Adapter.h      Physical adapter class declaration.

notify.rc      The resource file.

notify.rgs     Script-based registry.

notifyn.idl    The notify object's .idl file.

setupdi.cpp    Functions to copy the miniport INF file to the system.

- -

Top of page

- - - - - -

- -

- - - - - \ No newline at end of file diff --git a/network/ndis/ndisprot/6x/ndisprot.htm b/network/ndis/ndisprot/6x/ndisprot.htm deleted file mode 100644 index 3e854693..00000000 --- a/network/ndis/ndisprot/6x/ndisprot.htm +++ /dev/null @@ -1,393 +0,0 @@ - - - - - - - - -Sample NDIS connection-less protocol driver sample - - - - - - - -

- -

NDIS connection-less protocol driver -sample

- -

SUMMARY

- -

This sample demonstrates -a connection-less NDIS 6.0 protocol. The driver supports sending and receiving -raw Ethernet frames using ReadFile/WriteFile calls from user-mode. It only -receives frames with a specific EtherType field. As an NDIS protocol, it -illustrates how to establish and tear down bindings to Ethernet adapters, i.e. -those that export medium type NdisMedium802_3. It shows how to set a -packet filter, send and receive data, and handle plug-and-play events.

- -

BUILDING THE SAMPLE

- -

From the -Free or Checked Build environment, execute build -ceZ in the ndisprot -directory.

- -

INSTALLATION

- -

The driver is installed -using the INF file ndisprot.inf, which is provided in the driver directory. In -Network Connections UI, select an adapter and open Properties.

- -

Click Install, -then Protocol, then Add, and then Have disk. Then point to -the location of the .inf and driver.

- -

Select Sample NDIS -Protocol Driver and click OK. After installing the protocol, copy -over the test application prottest.exe to a convenient location. Please note -that the driver service has been set to manual start in the INF file. As a -result, it doesn't get loaded automatically when you install.

- -

USAGE

- -

To start -the driver, type

- -

Net start ndisprot

- -

To stop -the driver, type

- -

Net stop ndisprot

- -

To test -the driver, run prottest. For help on usage, run prottest -?

- -

usage: PROTTEST [options] <devicename>

options:

       -e: Enumerate devices

       -r: Read

       -w: Write (default)

       -l <length>: length of each packet (default: 100)

       -n <count>: number of packets (defaults to infinity)

       -m <MAC address> (defaults to local MAC)

- -

Prottest exercises the IOCTLs supported -by NDISPROT, and sends and/or receives data on the selected device. In order to -use prottest, the user must have administrative privilege. Users should pass -down a big enough buffer in order to receive the entire received data. If the -length of the buffer passed down is smaller than the length of the received -data, NDISPROT will only copy part of the data and discard the rest when the -given buffer is full.

- -

Use the –e option to enumerate all -devices to which NDISPROT is bound:

- -

C:\prot>prottest -e

 0. \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}

     - Intel-Based 10/100 Ethernet Card

- -

The -following command sends and receives 2 packets on a device). Since these packets are sent to -the local MAC address (default), both packets are received. The device -name parameter to prottest is picked up from the output of prottest –e (see -above).

- -

C:\prot>prottest -n 2 \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}

DoWriteProc: finished sending 2 packets of 100 bytes each

DoReadProc finished: read 2 packets

- -

For -security reasons, this driver does not allow packets with fake MAC addresses to -be sent from usermode applications.

- -

TIPS

- -

With a checked version of -ndisprot.sys, you can control the volume of debug information generated by -changing the variable ndisprotDebugLevel. Refer to debug.h for more -information.

- -

CODE TOUR

- -

File Manifest

- -

Directory: Test

-

-

File             Description

prottest.c       User-mode test application

Directory: Sys

-

-

File             Description

debug.c          Routines to aid debugging

debug.h          Debug macro definitions

macros.h         Spinlock, event, referencing macros

ndisbind.c       NDIS protocol entry points to handle binding/unbinding from adapters

ndisprot.h       Data structure definitions

ndisprot.inf     INF file for installing NDISPROT

ntdisp.c         NT Entry points and dispatch routines for NDISPROT

protuser.h       IOCTL and associated structure definitions

recv.c           NDIS protocol entry points for receiving data, and IRP_MJ_READ processing

send.c           NDIS protocol routines for sending data, and IRP_MJ_WRITE processing

- -

Top of page

- - - - - -

- -

- - - - diff --git a/network/ndis/ndisprot_kmdf/ndisprot.htm b/network/ndis/ndisprot_kmdf/ndisprot.htm deleted file mode 100644 index 88dc4d38..00000000 --- a/network/ndis/ndisprot_kmdf/ndisprot.htm +++ /dev/null @@ -1,197 +0,0 @@ - - - -Sample NDIS connection-less protocol driver sample - - - - -

- -

NDIS connection-less protocol driver sample

- -

SUMMARY

- -

This sample demonstrates a connection-less -NDIS 5.0, 5.1 or 6.0 protocol driver. The driver supports sending and receiving raw Ethernet -frames using ReadFile/WriteFile calls from user-mode. As an NDIS protocol, it illustrates how to -establish and tear down bindings to Ethernet adapters, i.e. those that export medium type -NdisMedium802_3. It shows how to set a packet filter, send and receive data, and handle -plug-and-play events.

- -

The sample works on Windows 2000 and later -platforms.

- -

The sample also demonstrates how to write -a Notify Object dll. The Notify Object is used for calling into the Wdf Coinstaller to install -and load the framework library.

- -

BUILDING THE SAMPLE

- -

From the Free or Checked Build environment, -execute build -ceZ in the ndisprot directory.

Depending on the build environment, the 50 -subdirectory produces either NDIS5.0 or NDIS 5.1 compatible driver. If built in the Windows 2000 -build environment, it will produce NDIS 5.0 compatible driver. If it's built in the Windows XP or -Window Server 2003 build environment, it will produce NDIS 5.1 compatible driver.

The 60 subdirectory can be built only in the -Windows Vista build environment. The sample built in this sub directory will be NDIS 6.0 compatible -and will work on Windows Vista and later operating systems.

- - -

INSTALLATION

- -

The driver is installed using the INF file -ndisprot.inf, which is provided in the driver directory. In Network Connections UI, select an -adapter and open Properties.

- -

Click Install, then Protocol, -then Add, and then Have disk. Then point to the location of the .inf and driver.

- -

Select Sample NDIS Protocol Driver and -click OK. After installing the protocol, copy over the test application files uiotest.exe and -protest.exe to a convenient location. Please note that the driver service has been set to manual -start in the INF file. As a result, it doesn't get loaded automatically when you install.

- -

USAGE

- -

To start the driver, type
- Net start ndisprot

- -

To stop the driver, type
- Net stop ndisprot

- -

To test the NDIS 5.x driver, run uiotest. -For help on usage, run uiotest -?

- -

-usage: UIOTEST [options] <devicename>
-options:
-       -e: Enumerate devices
-       -r: Read
-       -w: Write (default)
-       -l <length>: length of each packet (default: 100)
-       -n <count>: number of packets (defaults to infinity)
-       -m <MAC address> (defaults to local MAC)

- -

To test the NDIS 6.0 driver, run prottest. -For help on usage, run prottest -?

- -

-usage: PROTTEST [options] <devicename>
-options:
-       -e: Enumerate devices
-       -r: Read
-       -w: Write (default)
-       -l <length>: length of each packet (default: 100)
-       -n <count>: number of packets (defaults to infinity)
-       -m <MAC address> (defaults to local MAC)

- -

Uiotest/Prottest exercises the IOCTLs supported by -NDISPROT, and sends and/or receives data on the selected device. In order to use uiotest/prottest, the -user must have administrative privilege. Users should pass down a big enough buffer in order to receive -the entire received data. If the length of the buffer passed down is smaller than the length of the -received data, NDISPROT will only copy part of the data and discard the rest when the given buffer is -full.

- -

For NDIS 5.x driver, use the –e option on uiotest -to enumerate all devices to which NDISPROT is bound:

- -

-C:\uio>uiotest -e
- 0. \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
-     - Intel-Based 10/100 Ethernet Card

- -

The following command sends and receives 2 packets -on a device. Since these packets are sent to the local MAC address (default), both packets are received. -The device name parameter to uiotest is picked up from the output of uiotest –e (see above).

- -

-C:\uio>uiotest -n 2 \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
-DoWriteProc: finished sending 2 packets of 100 bytes each
-DoReadProc finished: read 2 packets

- -

For NDIS 6.0 driver, use the –e option on prottest -to enumerate all devices to which NDISPROT is bound:

- -

-C:\prot>prottest -e
- 0. \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
-     - Intel-Based 10/100 Ethernet Card

- -

The following command sends and receives 2 packets -on a device. Since these packets are sent to the local MAC address (default), both packets are received. -The device name parameter to prottest is picked up from the output of protest –e (see above).

- -

-C:\prot>prottest -n 2 \DEVICE\{9273DA7D-5275-4B9A-AC56-68A49D121F1F}
-DoWriteProc: finished sending 2 packets of 100 bytes each
-DoReadProc finished: read 2 packets

- -

For security reasons, this driver does not allow -packets with fake MAC addresses to be sent from usermode applications.

- - -

TIPS

- -

With a checked version of ndisprot.sys, you can -control the volume of debug information generated by changing the variable ndisprotDebugLevel. Refer to -debug.h for more information.

- -

CODE TOUR

- -

File Manifest

- -

Directory: 50, 60
-File             Description
-debug.c          Routines to aid debugging
-debug.h          Debug macro definitions
-excallbk.c       Handles load order dependency between this sample and NDISWDM sample
-macros.h         Spinlock, event, referencing macros
-ndisbind.c       NDIS protocol entry points to handle binding/unbinding from adapters
-ndisprot.h       Data structure definitions
-precomp.h        Contains the  precompiled headers
-protuser.h       Has the definitions of ioctls issued by protuser.exe application used on NDIS 6.0  
-nuiouser.h       Has the definitions of ioctls issued by nuiouser.exe application used on NDIS 5.0  
-ndisprot.inf     INF file for installing NDISPROT
-ntdisp.c         NT Entry points and dispatch routines for NDISPROT
-recv.c           NDIS protocol entry points for receiving data, and IRP_MJ_READ processing
-send.c           NDIS protocol routines for sending data, and IRP_MJ_WRITE processing

- -

Directory: NotifyOb
-File             Description
-Common.hpp       Header file containing the common include files for the project
-dllmain.cpp      Handles loading/unloading of Wdf Coinstaller and the notify object dll
-ProtNotify.cpp   Handles loading/unloading the WDF loader during the device installation/removal
-ProtNotify.idl   Defines the interfaces for the notify object dll
-ProtNotify.def   Defines the exports of notify object dll
-
-ProtNotify.rc    Resource file for the notify object dll
-resource.h       Defines the resource ids used by the notify object

- -

Top of page

- - - - - -

- -

- - - - - - -- cgit v1.3.1