Ethernet over USB

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Ethernet over USB has two meanings: Ethernet devices via USB and USB as an Ethernet network. Sometimes, it can also refer to the recycling of damaged USB cables as Ethernet cord-splice patches[citation needed].

Contents

[edit] Ethernet devices via USB

The ability to connect Ethernet devices via USB ports is known as Ethernet over USB. There are many low-cost commercial adapters available to do this. The links below describe the technical details on how the technology works.

[edit] Treat USB as an Ethernet network

The Linux kernel for the iPAQ uses this communications strategy exclusively, since the iPAQ hardware has neither an accessible serial port nor a dedicated network interface.

The usb-eth module in Linux emulates an Ethernet device that uses USB as the physical medium. Once created, this network interface can be assigned an IP address and otherwise treated as though it were ordinary Ethernet hardware. The usb-eth module allows the USB device to "see" a network, ping other IP addresses, and even "talk" DHCP, HTTP, NFS, telnet, and e-mail. In short, any applications that work over real Ethernet interfaces will work over a usb-eth interface without modification, because they can't tell that they aren't using real Ethernet hardware.[1]

On Linux hosts, the corresponding Ethernet-over-USB kernel module is called usbnet. A recently-announced usbnet-style driver for Win32 hosts is called the Bahia Network Driver.[2]

[edit] Protocols

There are numerous protocols de facto and de jure 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 for instance 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 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 USB1.1 systems (current when the protocol was issued) with 64 byte packets but not for USB2.0 systems which use 512 byte packets.

The problem is that Ethernet frames are about 1500 bytes in size—about 3 USB2.0 packets, and 23 USB1.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 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 3 frames can be very costly to throughput.

As USB has gotten faster, devices have also gotten hungrier for data and so there is now demand for sending large amounts of data, either to be stored on the device, or be relayed over wireless links (see 3GPP Long Term Evolution).

Since the new devices, although faster than before, are still much lower in power than desktop PC's, the issue of careful data handling arises, to maximize use of DMA resources on the device and minimize (or eliminate) copying of data (zero-copy). The NCM protocol has elaborate provisions for this. See link below for careful protocol comparisons.

[edit] References

[edit] External links

Personal tools
Namespaces

Variants
Actions
Navigation
Interaction
Toolbox
Print/export