The following describes Ethernet over USB
The Remote Network Driver Interface Specification (RNDIS) is a
Microsoft proprietary protocol used mostly on top of USB. It provides
a virtual Ethernet link to most versions of the Windows, Linux, and
FreeBSD operating systems. A partial RNDIS specification is available
from Microsoft, but Windows implementations have been observed to
issue requests not included in that specification, and to have
The protocol is tightly coupled to Microsoft's programming interfaces
and models, most notably the Network Driver Interface Specification
(NDIS), which are alien to operating systems other than Windows. This
complicates implementing RNDIS on non-Microsoft operating systems, but
Linux,2 FreeBSD,3 NetBSD4 and OpenBSD implement RNDIS
The USB Implementers Forum (USB-IF) defines at least three
non-proprietary USB communications device class (CDC) protocols with
comparable "virtual Ethernet" functionality; one of them (CDC-ECM)
predates RNDIS and is widely used for interoperability with
non-Microsoft operating systems, but does not work with Windows.
[PATCH] USB: usbnet (8/9) module for RNDIS devices
There are numerous protocols for Ethernet-style networking over USB. The main motivation for these protocols is to allow application-independent exchange of data with USB devices, instead of specialized protocols such as video or MTP. Even though USB is not a physical Ethernet, the networking stacks of all major operating systems are set up to transport IEEE 802.3 frames, without caring much what the underlying transport really is.
The main industry protocols are (in chronological order): Remote NDIS (RNDIS, a Microsoft vendor protocol), Ethernet Control Model (ECM), Ethernet Emulation Model (EEM), and Network Control Model (NCM). The latter three are part of the larger Communications Device Class (CDC) group of protocols of the USB Implementers Forum (USB-IF). They are available for download from the USB-IF (see below). The RNDIS specification is available from Microsoft's web site. Regarding de facto standards, some standards, such as ECM, specify use of USB resources that early systems did not have. However, minor modifications of the standard, so-called subsets, make practical implementations possible on such platforms. Remarkably, even some of the most modern platforms need minor accommodations and therefore support for these subsets is still needed.
Of these protocols ECM is by far the simplest—frames are simply sent and received without modification one at a time. This was a good strategy for USB 1.1 systems (current when the protocol was issued) with 64 byte packets but not for USB 2.0 systems which use 512 byte packets.
The problem is that Ethernet frames are about 1500 bytes in size—about 3 USB 2.0 packets, and 23 USB 1.1 packets. According how the USB system works, each packet is sent as a transfer, a series of maximum-length packets terminated by a short packet or a special ZLP (zero-length packet). After this, there is bus latency, where nothing is sent until another transfer can be initiated. This reduces bus occupancy, meaning that nothing is sent for considerable fractions of bus time. A gap every 23 frames is not noticeable, but a gap every three frames can be very costly to throughput.
The following were answered superuser
Ethernet over USB drivers are included into Linux. The relevant
host-size drivers are CDC_ETHER and RNDIS. Their slave-size
counterparts (that essentially emulate an USB-Ethernet bridge in
software) are USB_ETH, USB_ETH_RNDIS. USB_G_ANDROID also supports
RNDIS protocol, which is great in my case, since the devices in
question use Android kernel, so the driver is enabled by default.
The measured bandwidth of the USB bridge using the USB_G_ANDROID
driver is ~130Mbps from host to slave and ~90Mbps the other way round.