USB TestDrive

Belcarra’s USB TestDrive is a Linux Environment based on the Gumstix Overo hardware development system that uses TI’s OMAP 3530 SOC. The TestDrive system can be used to evaluate USB Networking protocols and implementations such as:
Linux Gadget g-ether network and filestorage function drivers.
Belcarra CDC-NCM, EEM, ECM and mass storage function drivers.
Belcarra’s USBLAN class driver for Microsoft Windows.

The TestDrive kit is complete with ROOTFS, Compiled 2.6.34 kernel and script to create an SD card to boot the Overo device.
Network test tools are installed and ready to use as soon as the system boots. Gadget or Belcarra modules can be loaded and unloaded for testing with a simple shell script.
For more information:

Data Transfer Rates RNDIS vs Belcarra USBLAN for Windows

Measured in MegaBytes per second (MB/s) the graph illustrates gadget CDC-ECM protocol data transfer speed vs. Microsoft's RNDIS protocol using three simple web-related network tests all done with Linux-line tools, on an Overo Gumstix, or on the PC using the Cygwin tools to give a Linux-like environment (see

  • wget (OUT) -- using wget on the device to retrieve a large file.  The traffic measured is in the OUT direction. Output (file retrieved) is discarded.
  • wget (IN) -- using wget on the PC to retrieve a large file. Output is discarded
  • wget OUT- bidirectional
  • wget IN - bidirectional
  • combination of the previous 2

Microsoft's RNDIS vs. Belcarra's USBLAN for Windows - Deployment Costs

RNDIS is Microsoft's solution for providing a networking over USB solution using their proprietary RNDIS protocol.
USBLAN for Windows is Belcarra’s solution for providing a networking over USB solutions using the industry standard protocols CDC-ECM, CDC-EEM and CDC-NCM.
While there are no licensing costs associated with the use of Microsoft’s RNDIS driver this does not mean that the actual cost of deploying a commercial product will be less when RNDIS is implemented.

The Total Cost of Deployment for a USB device using a network over USB solution is composed of multiple items:
  • cost development of the device side protocol support 
  • cost development and testing of the Windows Installation kit 
  • cost of setting up Windows Logo Kit test setup 
  • cost of doing Windows Logo Kit testing 
  • opportunity costs associated with delays while developing the installation kit 
Device Side Implementation Costs
Also support for RNDIS is limited to Windows based systems on the host side. This means that the device must still support another standard (such as CDC-ECM) for compatibility to Linux or Macintosh hosts.

Windows Logo Kit Testing Setup
Windows Logo Kit testing requires:
  • Server 2008 system to run DTM Studio 

Microsoft's RNDIS vs Belcarra's USBLAN for Windows

Zero install solution is a myth
Regardless of protocol (RNDIS or CDC-ECM) you will need to have an INF file somewhere on your Windows system. This INF file can be installed seamlessly from Windows Update (the driver repository part of Windows Update), or it can be copied onto the system by the end user as part of a driver install package. The process is actually identical in both cases. In one case Windows Plug-n-Play support is looking for and downloading the driver installation kit and using it directly while in the other the user downloads the driver installation kit and tells Windows Plug-n-Play where the kit is unpacked.

Whether the RNDIS / USBLAN for Windows driver is from an OEM website download, from a CD, or from Windows Update, the contents of the driver installation kit will be almost identical, namely an INF file, one or more SYS files and a Catalog file (contains the signatures for the INF and .sys files). [The CD / website zip file may optionally have an additional README and possibly a setup.bat to run DPInst.exe.]

USBLAN from Windows Update Installs Seamlessly
For 99% of Windows 7 users who go with the Microsoft default OS setup and have an active internet connection (and a legal, activated copy of Windows!) Plug-N-Play will automatically find and install the Belcarra USBLAN driver. The user will see a small 'New Hardware Found' applet icon in the toolbar. This can be clicked on and will tell that Windows Update is being searched, etc.. No other user interaction should be required

USBLAN and Gadget EEM

The CDC EEM protocol allows multiple network frames to be aggregated into a single CDC-EEM USB Bulk transfer. This allows for higher bus utilization and higher overall network throughput than the more commonly used CDC ECM (Ethernet Control Model) and Microsoft’s proprietary RNDIS protocols.

The CDC-EEM protocol also supports a streaming mode where the sender can send reasonably large CDC-EEM transfers even when the receiver does not know what the maximum size transfer is. This is achieved by ensuring that the CDC-EEM sender always terminates a CDC-EEM transfer with a short or Zero Length packet. The Belcarra USBLAN driver supports both frame aggregation and streaming with the CDC-EEM protocol.

Connecting to an Android device

Belcarra's USBLAN for Windows USB Class Driver (host) is our recommended alternative to RNDIS for networking over USB with an Android device . Simply ensure the USB Gadget Support is correctly configured to use g_ether and ensure RNDIS is not enabled.  To use Belcarra's demo version of USBLAN on your Windows host system (available from Windows Update) setup the device to use 15EC for the Vendor ID and D001 Product ID.

Basic Testing of CDC-ECM

The current rev of the Gingerbread project uses Version 2.6.32 of the Linux kernel. This version contains EEM support with a small (but fatal) bug which we have already documented in earlier work. The Android kernel is patched to disable EEM even if the EEM option is selected. By this it is meant the module parameter use_eem defaults to 0 (it defaults to 1 in other kernels). Since modules are not used much (see below), this means that EEM is not readily available. However, for test purposes, we fixed the EEM bug and changed the default value of the use_eem parameter.

To do our tests, we disabled the Android gadget and enabled the g_ether gadget with and without the EEM option.
NOTE: a patch is available  for our customers to use to make EEM work.
Benchmarking Tools.

In the Belcarra TestDrive environment, we used 3 main tools:
  • ping
  • wget (HTTP)
  • iperf
None of these were available in the Gingerbread rootfs. Therefore, we used netperf. A netperf client is included in the Gingerbread/Rowboat standard rootfs. Using netperf requires finding a netperf server for

Linux Gadget VID/PID Patch for USBLAN Evaluation

Linux Ethernet Gadget (g_ether) has built-in Vendor/Product ID pairs which are used if the module parameters idVendor and idProduct are not provided. Two of these pairs are used for the CDC protocols (CDC-ECM and CDC-EEM), while the remaining pair is used for RNDIS.

These patches (download here) modify the Linux Ethernet Gadget default CDC Vendor and Product ID to match the Belcarra USBLAN Evaluation kits available from Windows Update.

This allows the g_ether (Ethernet) Gadget to be used in conjunction with Belcarra USBLAN without using module parameters (idVendor and idProduct).
Very useful for Android which uses Gadget built into the kernel (module parameters are not available).

Linux Gadget EEM DEADBEEF Fix

Early versions of Gadget EEM (in the Linux 2.6.32 kernel) set BIT 14 (the sentinel bit) in the EEM header of transmitted data packets, falsely signifying that the data frame had a computed CRC instead of the fake 0xDEADBEEF value that SHOULD used when the bit is NOT set. This patch (available here) fixes this by modifying a single line.

Android Gingerbread Rowboat Project - Enable EEM

Download this patch to modify the Overo Android defconfig to enable the EEM protocol .

Applicable to the Gingerbread Rowboat project on the Gumstix Overo using the Linux 2.6.32 kernel. Very similar steps can be used on other Android projects.

CDC-EEM vs. CDC-ECM Protocols - Improvements in TCP Throughput

The CDC-EEM protocol is intended as an alternative to the CDC-ECM protocol for applications that do not require a Control Plane. The CDC-EEM protocol simplifies some of the requirements of the USB Configuration (no control plane) and allows for multiple network frames to be sent as part of a single USB Transfer. This study will provide some indication of the benefits of using the features of CDC-EEM to allow for multiple network frames to be coalesced into a single USB Transfer. 

NOTE:  the newer CDC-NCM protocol is another alternative to CDC-ECM that retains the Control Plane. The CDC-NCM encapsulation is different in structure from EEM but has similar capabilities to CDC-EEM for sending multiple datagrams per transfer. CDC-NCM throughput numbers will be very similar to CDC-EEM for most devices.


The USB implementations impose problems when trying to get maximum throughput for other protocols such as TCP. TCP requires low Round Trip Times (RTT) and high bandwidth to get good throughput. As originally designed TCP is very good at measuring effective throughput and only offering enough data to the network that will fit without frames being dropped. Modern networking stacks (e.g. current Linux or Windows or Mac OSX) implement various TCP extensions that allow this to happen even on very fast networks (i.e. > 100Mbit/s).

While the USB has a reasonably high speed (> 400Mbit/s) the effective speed is lower due to various constraints in the design. These have the effect of increasing latency which impacts RTT which tends to reduce effective throughput for TCP. The primary constraint is in how the network frames are encapsulated and sent across the USB. ECM has a simple strategy of one network frame for each transfer. EEM allows multiple network frames per transfer.

We show that using EEM’s ability for sending multiple frames in a single USB Transfer can increase throughput by 50%. Our best case uni-directional test measured about 11 Mbytes/s for ECM and up to 26.5 MBytes/s for EEM. Our best case bi-directional test measured about 8 Mbytes/s x 2 for ECM and 14.5 Mbytes/s x 2 for EEM.

Demo on Windows Update

An evaluation version of the Belcarra USBLAN driver is available in Windows Update. By configuring your target device with the correct Belcarra USB Vendor ID and Product ID the evaluation version of the driver will be downloaded and installed allowing you to verify that your target device correctly inter-operates with the Belcarra USBLAN driver.
For more information ...
Belcarra's USBLAN class driver for Windows is a Microsoft Windows-based networking-over-USB solution compatible with both CDC-ECM and CDC-EEM protocols as well as the more recent and higher performance CDC-NCM protocol. USBLAN is available for Microsft Windows XP, Vista and Win 7, 32 and 64 bit versions. The driver is implemented as a Windows-based NDIS Miniport driver with the upper half being a standard NDIS driver and the lower half a WDM driver to access the USB peripherals. For smart devices an integrated bridge supports implementation of a virtual LAN between multiple smart devices. The implementation also includes built in servers for DHCP, RARP and Time of Day which optionally allow for simple configuration of both the host and connected devices.

A typical desktop Windows networking environment that might be called upon to use USB to connect to network devices meets two distinct types of USB networking devices:

  • Smart (PDA) devices which will source and sink network data
  • Infrastructure (Bridge/Router) devices that will act as an Ethernet packet bridge between the Windows system, its own local devices,and another 802.3 (Ethernet) based network, and/or route Internet Protocol packets to another IP based network.

Each type of device implements a distinct type of network connection and must interact with the host in a correspondingly distinct fashion. The USBLAN driver recognizes the type of device by the type of configuration presented by the device during enumeration.