Connection issues with RNDIS (Windows Embedded CE 6.0)
1/6/2010
ActiveSync 4.0 utilizes RNDIS architecture, which emulates an Ethernet interface for the USB connection. As an Ethernet interface it is exposed to other networking components not just ActiveSync. A number of connection issues can arise in this regard. The issues can range from port blocking by firewall software to 3rd party configuration applications and VPN software interfering with ActiveSync operation.
The NDIS IM (Intermediate) driver is a layered NDIS driver, which emulates the miniport driver functionalities at its upper edge and protocol driver characteristics at its lower edge. This driver is usually ‘sandwiched’ between a standard protocol driver like TCPIP and an underlying miniport driver like RNDIS and other networking drivers in the host machine. The implementations of NDIS IM driver that have been observed to interfere with ActiveSync operation are in areas like network utilities, for example the utility that manages connectivity between Wifi and RNDIS, and VPN clients, for example IPSEC driver.
One such utility automatically shuts down the Wifi connection when Windows Embedded CE-based device is connected to it. This essentially disconnects the host from the network it is connected to causing the server sync to fail. ActiveSync 4.1 resolves this issue by the selective binding of the RNDIS miniport driver to the protocol drivers that matter to it, for example TCPIP and TCPIP6, hence bypassing the NDIS IM drivers.
Many firewalls are implemented as TDI filter drivers. In one case it was determined that the 8 Kbytes MTU (Maximum Transfer Unit) used by the RNDIS miniport driver caused the TDI driver to fail ActiveSync. The 8 Kbytes MTU was chosen to improve the needed throughput boost for media capable devices (for example music downloads).
The solution for this issue is to reduce the MTU through a registry setting on the Windows Embedded CE-based device, HKLM\Drivers\USB\FunctionDrivers\RNDIS\MTU, as the filter expects a standard 1514 bytes.
Most of these cases are due to the firewall performing proper port blocking which results in ActiveSync connection failures. To solve these issues, Microsoft provides information to guide end users on how to open up the ActiveSync server ports. This information can be found at the following Web site.
The next category of issues is related to Winsock LSPs (Layer Service Provider). Winsock LSPs provide extensions to the transport provider, for example, quality of service over the TCP/IP protocol stack, URL filtering, anti virus software. It was determined that the main issue with these LSP implementations is their failure in handling WSADuplicateSocket API which is used by the ActiveSync server application to share socket handles with different processes. ActiveSync 4.1 solves this issue by bypassing the LSPs and binding directly to the base provider msafd.dll, the Windows Socket 2.0 service provider for TCPIP.
In addition to these we have also observed the following causes:
Note
This list is non exhaustive, the purpose is to illustrate potential issues that may be encountered when trouble shooting an issue.
The VPN (Virtual Provider Network) client security software changes the IP routing table to bypass the RNDIS interface. This causes sync to fail. In one of the VPN implementations, there is a 'split tunneling' mode, which bypasses the local subnet. It is recommended that this mode be used to allow sync to work. Microsoft does not currently provide a solution to bypass the VPN software.
Network management utilities, for example the ConfigFree utility which is enabled by default in Toshiba laptops, perform automatic shut down on adapters, which may cause sync to fail. Our recommendation is for the user to disable such utilities when attempting to perform sync.
There have been a few cases where using a laptop docking station or external USB Hub can cause ActiveSync connectivity issues. The symptoms for such cases are as follows:
ActiveSync recognizes Windows Embedded CE–based device but fails to start Sync & keeps spinning.
Sometimes if Windows Embedded CE–based device is connected, then removing USB cable does NOT propagate surprise removal to Host system leading to the issue where RNDIS Host interface stays on the Host even when Windows Embedded CE–based device is removed.
Investigation on one case revealed that the issue was on the USB stack on the host system, which at one point stops polling the Interrupt End point (see appendix 1 for a full description of the USB end point). The current workaround is to avoid using the Laptop docking station or external USB Hub if you experience such connectivity issues.
With ActiveSync 4.1, ActiveSync installation ensures that RNDIS Host interface when comes up gets bound to only TCP/IP & TCP/IPv6 protocols. We have seen one VPN client which when it finds out that RNDIS host interface is not bound to its own NDIS IM driver, unbinds RNDIS Host interface from TCP/IP & TCP/IPv6.
The result is when the end user connects Windows Embedded CE–based device to Host; ActiveSync on Host does not see the device. Unfortunately the current workaround is to manually rebind TCP/IP & TCP/IPv6 protocols back to RNDIS Host interface. This can be done in the following way
Start button --> Control Panel --> double click on Network connections.
Right click on a Local area connection named Windows Embedded CE -based Device #nn and select Properties
Select the checkboxes for Internet Protocol (TCP/IP) and Microsoft TCP/IP version 6
In summary, problems with synchronization over ActiveSync 4.0 can result from third party applications, utilities, or drivers installed in the host machine affecting RNDIS. Some of the problems with synchronization, result from port blocking. Microsoft encourages software vendors to automatically open ActiveSync server ports.
Problems with synchronization that can be bypassed are resolved in the ActiveSync 4.1 release. More information can be found at the following Web site.
If none of the above resolves the issue, the OEM or mobile operator may choose to roll back to the ActiveSync 3.x architecture. In this case, the RNDIS client driver needs to be replaced with the serial client driver. There is sample code on how this can be accomplished. One requirement here is that OEM needs to provide their own installation file (INF) matching their serial product and vendor IDs information.
In the ActiveSync 3.x architecture, the ActiveSync application owns the USB serial port emulation on the desktop and hence bypasses all the issues described in this topic. For this solution ActiveSync has a complete protocol stack allowing it to communicate with the device. As we mentioned, the RNDIS solution eliminates the need for this private protocol stack and provides a better stability and a faster non Point-to-Point Protocol (PPP) based transfer.
See Also
Concepts
USB RNDIS in ActiveSync 4.0
RNDIS USB Client
ActiveSync using RNDIS solution
Brief summary of the RNDIS protocol