Address Management and Device Discovery

Belcarra Technologies Technical White Paper • Architecture and Best Practices for TCP/IP over USB

Overview

This paper describes how to build and manage a TCP/IP network for USB devices.

Ethernet-style networking can very simply be extended to attached USB devices. Belcarra's USBLAN for Windows built-in DHCP server for address assignment, management, and device discovery solutions has been implemented to fit within network paradigm requirements. USBLAN for Windows implements USB-IF (www.usb.org) Communications Device Class protocols (CDC-NCM, CDC-EEM, CDC-ECM, and others) and creates an Ethernet-style networking segment for each attached USB device.

The Shift to Smart Devices

Networking-over-USB protocols such as CDC-ECM, Microsoft RNDIS, and CDC-NCM were originally designed to provide USB-mediated access to an external network, where address management was delegated to the external network segment (which usually supplied an external DHCP server).

Now, however, the great majority of USB devices using these protocols are smart devices that use a network-style command channel (such as a local REST API or web interface) but do not provide access to an external network medium. Therefore, the network segment terminates at the device, and there are only two nodes on the network: the USB host (Windows) and the device. The DHCP service within Belcarra USBLAN for Windows is a specialized service designed specifically for such point-to-point network segments.

The following sections describe how network-layer (IPv4) addresses can be seamlessly established on top of the link layer, alongside pointers and strategies for OEM software running on Windows co-operating with the device to enable network-based device discovery.

Link Layer

At the lowest level, a Windows network interface created by USBLAN is an NDIS interface, using Ethernet-like (IEEE 802.3) framing. The associated network segment consists strictly of the new Windows interface and the attached USB device.

The two devices (Windows and the attached USB device) can send network (Ethernet/802.3) frames between each other, but that traffic will not be routed or bridged to anywhere else (unless the user explicitly takes action to bridge the new interface with other network adapters).

IP Address Assignment and Management

For the device to be accessible via TCP/IP protocols such as HTTP, the network interfaces of the devices must also have IP addresses assigned to them, and this needs to match the address the device uses (be on a common subnet).

• Manual Setup: If addresses are pre-arranged (simple but inflexible), the IPv4 properties of the new interface (IP address and netmask) can be configured by hand. This requires user intervention and administrative privileges.
• On-Device DHCP Server: Another approach is to have the device operate a simple DHCP server that sends configuration to the Windows side. While this avoids manual setup on Windows, it will fail in the case of address conflicts from another device—especially if a second device of the same type is concurrently active.
• Belcarra Host-Side DHCP Server: Belcarra's USBLAN driver provides an internal DHCP server that transparently configures both sides without conflicts or administrative rights.

Belcarra USBLAN for Windows DHCP Server

To gracefully and transparently assign IP addresses to both the Windows interface and the device, Belcarra's USBLAN for Windows includes an optional DHCP server, visible only to the ends of the new network segment. The DHCP server operates within the USBLAN driver stack, but does not inter-operate with network facilities for other non-USB network interfaces, in particular other DHCP servers or clients that might be operating.

Features of Belcarra USBLAN Internal DHCP Service

• Zero Configuration: Neither the device nor the Windows end-user needs to participate in device setup.
• Configurable Lease Times: DHCP lease times are configurable (default: 10 minutes). When a device receives a lease and is subsequently disconnected and reconnected within the lease window, it can request the same IP address without waiting for a new DHCP Offer. If the lease time has expired, this request fails and falls back to requesting a fresh lease.
• Up to 32 Concurrent Devices: Up to 32 devices can be connected concurrently without address collisions.
• Active Device Discovery: The Windows host can readily discover which device(s) are active (and by implication which previously active devices are absent) purely by network operations.
• Runtime Registry Control: The server is optional. Customer kits enable or disable the service according to customer requirements. At runtime, the server is enabled if an associated registry key is set. In normal end-user operation, this key would not be changed (and therefore administrator access is not required).

As such, this is a true plug-and-play solution: no action on the device or on the Windows side is needed to maintain coordinated address assignment and device discovery.

Automatic Address Assignment for Concurrently Active Devices

This feature allows up to 32 devices to be concurrently connected. Each device is assigned a tiny sub-block as a private network consisting of the Windows interface, the DHCP server's address within that block, and the device. Standard rules of sub-networking require the line address and the broadcast address to be reserved, meaning a 5-address sub-network is needed. Therefore, Belcarra's internal DHCP service allocates a block of 8 addresses (CIDR /29) for each concurrent device.

The addresses used are subdivided from a master block of 256 addresses (a /24 subnet), which is configurable in the Windows registry via NETWORKBASE (default base: 169.254.1.0/24).

Table 1: DHCP Subnet Setup per Device (/29 Block)

Table 2: First 8 Device Address Allocations

Device discovery is described in detail below, but for many purposes, it suffices to note the list of possible device addresses. The table below shows the first 8 DHCP address assignments using the default base of 169.254.1.0:

Note: The DHCP server normally uses the network mask 255.255.255.248 (/29), but can allow devices the wider value 255.255.255.0 (/24) if required by embedded IP stacks.

Network-Based Device Discovery

Given that one or more USBLAN network devices are attached, Table 2 provides a deterministic method to locate devices in the form of a concise list of addresses. The base of the list depends on the single registry value NETWORKBASE, which is the line address of Device 0 (see Table 1). At any given time, some subset of those addresses will be active. The key to communicating with all these devices, without prior knowledge of which are connected, is sending UDP packets to the possible addresses.

The list of possible network addresses, as returned by Windows network calls, includes non-USB network interfaces, but their address blocks will not match the configured USB network base. With this in mind, a simple and robust discovery architecture is implemented as follows:

Process One on Windows (Discovery Initiator)

1. Get a list of active network interfaces via Windows networking APIs.
2. For each interface matching the network base (filtering out non-USB adapters), add the interface to the multicast group.
3. Send a multicast UDP request to address 226.1.1.1:2000. This is delivered to all active devices.
4. In a companion listener thread (Process Two), listen for responses. Because UDP is connectionless, a link may occasionally drop a packet. Therefore, the Windows host concludes after 2 or 3 unacknowledged queries that the device is not responding. Similarly, when compared to a previous poll, Windows concludes that a no-longer-responding device has been disconnected.
5. Branch off Process Two and repeat periodically (e.g. every 5–10 seconds).

Thread / Process Two on Windows (Response Listener)

1. Bind a UDP socket to port 2001.
2. Listen asynchronously for incoming reply packets from devices.

Thread / Process on Device (Firmware Responder)

1. Add the USB network interface to multicast group 226.1.1.1.
2. Bind a UDP socket to port 2000.
3. Listen for incoming host discovery queries.
4. When a request arrives, extract the regular unicast IP address of the sender, and send a UDP reply to port 2001 at that source IP.
5. Return to listening for subsequent requests.