RNDIS (Windows Embedded CE 6.0)
1/6/2010
Remote Network Driver Interface Specification (RNDIS) is a Microsoft Windows specification for remote devices to implement the NDIS miniport driver requirements.
The current implementations on Windows 2000, Windows Server 2003, and Windows XP support the USB packet-based I/O bus. There is no provision for changing the IP address or other parameters.
The miniport driver manages the network adapter as follows. The miniport driver uses NDIS to communicate with its hardware resources. It provides an interface for protocol drivers like TCP/IP to configure, send and receive packets over the network. ActiveSync and Desktop Pass-Through (DTPT) control the IP address of the adapter.
A typical network driver implementation in Windows is described below.
The following illustration shows the miniport driver that manages the network adapter that is installed on the platform. At the lower edge, the miniport driver uses NDIS to communicate with its hardware resources. At the upper edge, the miniport driver provides an interface for protocol drivers like TCP/IP to configure, send and receive packets over the network. The color legends show the hardware and different software modules delivered by Microsoft and the device manufacturers. ActiveSync and Desktop Pass-Through (DTPT) control the IP address of the adapter. The registry on the client side defines a specific IP address that is used to reach the host by some components. For this reason, users should not change the IP address, or use Internet Connection Sharing (ICS) or bridge on the adapter.
The miniport driver maintains information about its capabilities and status, and also information about the Network Interface Controller (NIC) that it controls. An Object Identifier (OID) identifies each type of information. NDIS and higher layer drivers can query and set information using these OIDs.
For a typical miniport driver implementation that manages its hardware resources via a USB serial bus, the device manufacturer implements the proprietary protocol between the miniport driver and the device firmware. The end user must install the miniport driver before using the network device.
The following figure illustrates a typical miniport driver implementation that manages its hardware resources via a USB serial bus. In this example, the device manufacturer implements the proprietary protocol between the miniport driver and the device firmware. The end user must install the miniport driver before using the network device.
The RNDIS specification replaces the OEM miniport driver on the host machine with the standard RNDIS miniport. The miniport uses the RNDIS protocol to proxy the implementation of the original OEM miniport driver to the OEM hardware.
The figure below illustrates this architecture with the standard RNDIS Miniport driver and the bus-specific RNDIS USB transport driver, which can potentially be substituted for other bus drivers like Bluetooth or IrDA.
This solution has several important advantages. First, the manufacturer only needs to implement the firmware conforming to the RNDIS protocol, which simplifies the development of the driver for the network device. Second, RNDIS eliminates the requirement to install the OEM’s driver on the host machine, thus improving user experience.
The complete RNDIS specification can be downloaded from the following Microsoft Web site.
**The protocol driver calls the NdisRequest function to query or set information. NDIS in turn calls the MiniportQueryInformation or MiniportSetInformation functions, which are implemented by the miniport driver.
The Miniport driver calls NDIS to indicate that packets of information have been received, and provides the MiniportSend function for the protocol driver to send packets.
Remote NDIS framework leaves the implementation of these functions to the external device.**
See Also
Concepts
USB RNDIS in ActiveSync 4.0
RNDIS USB Client
ActiveSync using RNDIS solution
Connection issues with RNDIS
Brief summary of the RNDIS protocol