Belcarra USBLAN_2 4_2 Manual

Belcarra USBLAN for Windows

Version 2.4.2

OEM Manual

September 2012


OEM Manual Copyright ©2012 Belcarra Technologies (2005) Corp. October 12, 2012

Page 2 www.belcarra.com

Contents

1 Introduction

1.1 References

2 Overview

2.1 Windows Platforms

2.2 Windows Features

2.3 Installation Kit

2.4 Compatibility

2.5 Supported Protocols

2.6 CDC NCM

2.7 CDC EEM

2.8 CDC ECM

2.9 Microsoft RNDIS

3 Architecture

3.1 NDIS

3.2 Station (MAC) Address

3.3 Composite Function

4 Evaluation

5 Customization

5.1 Versioning

5.2 Registry Location

5.3 General Configuration

5.3.1 UseZLP

5.3.2 UseNotifications

5.3.3 UseCyclePort

5.4 DHCP Service Configuration

5.4.1 DHCPDType

5.5 Multi-Frame Protocol Configuration

5.6 EEM Configuration

5.7 NCM Configuration

5.8 RNDIS

5.9 Per Adapter Configuration

6 Common Configuration Issues

6.1 NCM

6.2 EEM

6.3 ECM

6.4 Zero Length versus Null Byte Packets

6.5 DHCP IP Address Allocation

6.6 Notifications

7 Operation

7.1 Station Address

7.2 IP Address Configuration

7.3 Media Status

7.4 Multiple Devices

7.4.1 Installation of Multiple Devices with Serial Numbers

7.4.2 Installation of Multiple Devices without Serial Numbers

8 Installation Kit

8.1 NDIS 5 and 6

8.2 DIF Directed Install

8.3 Repackaging the distribution kit – without re-signing

8.4 Repackaging the distribution kit – with re-signing

8.5 Windows Logo Program – Signature Only

9 Installation Scenarios

9.1 Windows Update

9.2 Pre-Installed

9.3 Directed

9.4 Removal of the driver

10 Debug

APPENDICES

Appendix A - Connection Semantics for CDC-NCM and CDC-ECM Devices

Appendix B - Connection Semantics for Other (non NCM and ECM) Devices

Appendix C - Signing a Modified INF file

Appendix D - EEM Streaming

Appendix E – EEM Echo Response Request Configuration

Appendix F - DIFx Installation Information

Appendix G - Installation Screenshots

Appendix H - Setting a MAC address for a Specific USB Device

Appendix I - Bridging USB Device to another network

Appendix J - INF for Installation of NDIS driver

Appendix K - Sample Configuration Descriptors

Revision Summary




1 Introduction

The Belcarra USBLAN driver is a Windows Driver Model (WDM) and Network Driver Interface Specification (NDIS) driver that supports USB devices using industry standard networking over USB protocols. It allows devices that implement a compatible networking protocol (see below for the most common ones) to be attached to a Windows system. Each device gets a network interface which supports all standard Windows networking functions.

This document describes the architecture, features, installation and configuration of the driver.

1.1 References

This document makes reference to both USB and networking standards and concepts. Formal reference material, as well as other material can be found in the documents listed below, among others.

Universal Serial Bus 2.0 o Single-page backgrounder usb.org/developers/usb20/backgrounder/ o Technical introduction usb.org/developers/usb20/developers/whitepapers/usb_20g.pdf o Full specification usb.org/developers/docs/usb_20_071012.zip (includes the

specification document, errata and adopters agreement)

USB Communication Device Class (CDC) specifications o Universal Serial Bus Communications Class Subclass Specifications for Network Control

Model Devices (CDC-NCM) o Universal Serial Bus Communications Class Subclass Specifications for Ethernet Control

Model Devices (CDC-ECM) o The specifications for the preceding two protocols are contained (among others) in the

following archive www.usb.org/developers/devclass_docs/CDC1.2_WMC1.1_012011.zip

Universal Serial Bus Communications Class Subclass Specifications for Ethernet Emulation Model Devices (CDC-EEM). The specification for this protocol is found in www.usb.org/developers/devclass_docs/CDC_EEM10.pdf

RNDIS Specification: download.microsoft.com/download/B/0/B/B0B199DB-41E6-400F-90CD-C350D0C14A53/%5BMS-RNDIS%5D.pdf

Supplementary documents that may be helpful include:

Dynamic Host Configuration Protocol (DHCP) o The DHCP specification is found here: tools.ietf.org/html/rfc2131 o An overview and links to other reference material can be found in the Wikipedia article

on DHCP: en.wikipedia.org/wiki/DHCP

IEEE 802.3 protocol – general discussion en.wikipedia.org/wiki/IEEE_802.3 o Ethernet II (DIX v2.0) subtype of IEEE 802.3, what is generally known as Ethernet. For

USB networking, mostly we only need the frame format of this protocol, which is described here en.wikipedia.org/wiki/Ethernet_frame

Address Resolution Protocol (ARP) en.wikipedia.org/wiki/Address_Resolution_Protocol

Many other documents in the Developer section at www.usb.org

http://www.usb.org/developers/usb20/backgrounder/

http://www.usb.org/developers/usb20/developers/whitepapers/usb_20g.pdf

http://www.usb.org/developers/docs/usb_20_071012.zip

http://www.usb.org/developers/devclass_docs/CDC1.2_WMC1.1_012011.zip

http://www.usb.org/developers/devclass_docs/CDC_EEM10.pdf

http://download.microsoft.com/download/B/0/B/B0B199DB-41E6-400F-90CD-C350D0C14A53/%5BMS-RNDIS%5D.pdf

http://download.microsoft.com/download/B/0/B/B0B199DB-41E6-400F-90CD-C350D0C14A53/%5BMS-RNDIS%5D.pdf

http://tools.ietf.org/html/rfc2131

http://en.wikipedia.org/wiki/DHCP

http://en.wikipedia.org/wiki/Ethernet_frame

http://en.wikipedia.org/wiki/Address_Resolution_Protocol

http://www.usb.org/




2 Overview

Networking over USB protocols allows a full speed or high speed USB peripheral to implement a network connection to Windows. This in turn allows Windows applications to interact with applications on the USB peripheral using standard network protocols instead of vendor-specific USB protocols, which also requires the application to have administrator privilege, whereas any application can use the networking subsystem. The networking link may terminate at the device1, or the device may bridge the network data to a remote network2.

Applications of networking over USB include:

Connecting an embedded device to a Windows PC

Connecting a Windows PC to the Internet via a phone or cable modem

Connecting to smart devices such as printers or hand held devices

Providing a network connection to an embedded system via Windows

Networking over USB is done according to a variety of protocols, as described in Section 1.1. Belcarra USBLAN supports the standard protocols plus a number of de facto variants used in special situations (e.g. because of hardware issues). CDC ECM is the simplest, which simply sends one 802.3 frame per USB transfer. The other major protocols (CDC-EEM, CDC-NCM Microsoft RNDIS) all support sending and receiving multiple 802.3 frames in a single transfer, although the actual implementations of these protocols vary widely. Use of USBLAN with one of these protocols can achieve 60-70% occupancy of the USB 2.0 bus, for a net throughput of TCP transfers of up to 30 MBbytes/second, with the actual transfer rates constrained by hardware.

Multiple devices can be connected simultaneously.

The driver is available fully tested and qualified as a ready-to-use Microsoft ”Signature Only installation kit.

2.1 Windows Platforms

USBLAN has separate NDIS5 and NDIS6 versions, which are packaged as a single kit supporting Microsoft operating systems from Windows XP and later3.

The NDIS6 version of USBLAN is used to support the following:

Windows 8

Windows 7

Windows Server 2008 R2

Windows Server 2008

Windows Vista

The NDIS5 version of USBLAN is used to support the following:

Windows Server 2003

Windows Server

Windows XP

The driver supports both 32 bit and 64 bit architectures.

1 A personal area network (PAN) device

2 An infrastructure device

3 Except IA64 architectures.




2.2 Features

Plug and Play – drivers are installed automatically for each device attached, either from a local driver store or via the Internet from Windows Update

Power Management – The driver supports Windows power management allowing the host to enter standby, sleep and hibernation modes.

Station (MAC) Address – Can be assigned from the device or with a configurable default

IPv6 – Fully supported

IPv4 – address can be assigned via DHCP, Auto-IP or can be a static IP address

DHCP Service – an optional built-in DHCP server can be used to co-ordinate and assign the IPv4 address of both the host and device network interfaces

Composite function – the USBLAN driver is fully compatible with Windows USB composite function support. See Section 3.3 for details.

WHQL – drivers are fully compatible with Microsoft Windows Hardware Quality Labs (WHQL) tests and procedures

Multiple devices – Sixteen devices may be connected simultaneously

2.3 Installation Kit

The driver is provided as a complete and ready-to-use installation kit customized to the OEM’s requirements:

Branded with OEM Name

Configured with the OEM Vendor ID and Product ID’s

Signed driver – the drivers are cross-signed to be compatible with all versions of Windows

Signed installation – the installation kit is provided with a signed catalog file to allow installation in all versions of Windows

WHQL – the installation kit can optionally be provided with a Microsoft signed catalog file for silent installation

Windows Update – the drivers can be made available via Microsoft’s Windows Update service

2.4 Compatibility

The USBLAN driver supports USB 2.0 and the Enhanced Host Controller Interface (EHCI) Driver in all supported versions of Windows.

2.5 Supported Protocols

USB Communications Class Standards:

CDC NCM

CDC EEM

CDC ECM

Other protocols:

Microsoft RNDIS

Belcarra BLAN

Belcarra SAFE

Gadget Simple / Belcarra Basic

Belcarra Basic2

Protocol recognition is done on a per-device basis. Multiple devices with different protocols can be attached at the same time.

2.6 CDC NCM

The CDC Network Control Model (CDC NCM) is the most recent network standard. It is based on the semantics of the USB Communications Device Class Ethernet Control Model (CDC ECM) with a new data




plane encapsulation that is optimized for high performance with current high speed network technologies and retains the control plane design (with minor changes) from CDC-ECM.

2.7 CDC EEM

The CDC Ethernet Emulation Model (CDC EEM) eliminates the semantics of the control plane from CDC ECM and NCM. It is optimized to simply move network frames across the USB bus.

2.8 CDC ECM

The CDC Ethernet Control Model (CDC ECM) was the first networking over USB protocol standard issued by the USB Implementers Forum. It has a control plane that allows the device to notify the host of network characteristics (connection status and speed) and a data plane that can be enabled or disabled by the host. The network frames are sent as simple BULK data transfers terminated with a short or zero length packet.

2.9 Microsoft RNDIS

The Microsoft RNDIS protocol was defined by Microsoft before other Network over USB standards were created. It has a less complex set of interfaces; specifically it does not require the CDC ECM/NCM style of data interface. This protocol does use a series of extended commands that are sent to the device using the CDC Send Encapsulated Command device request. The device must implement the Notification endpoint to signal when the command response is available.

The primary advantage for using RNDIS is to support existing devices that have implemented it.

The Belcarra RNDIS implementation fully supports the multiple frame capability specified by the protocol and provides a robust implementation capable of supporting multiple devices.




3 Architecture

Figure 3-1 (below) outlines where the Belcarra USBLAN driver fits into the Windows WDM and NDIS driver architecture.

Windows Networking Application – Any Windows application that uses the standard Windows Networking interfaces.

Windows NDIS – the Windows networking stack, this implements the Windows Networking interfaces and all associated networking protocols such as IPv4, IPv6, UDP, TCP etc.

USBLAN – the Belcarra WDM NDIS driver that implements the required NDIS interface on its upper edge and conforms to the required USB Driver Interface on its lower edge to allow it to implement networking over USB

USBCCGP – the Windows composite support driver, this allows a device that has a composite function with a CDC network protocol to use the Belcarra USBLAN driver. The USBCCGP driver creates a virtual function consisting of one or more interfaces of a function and looks for matches of the virtual function to available drivers. If the interface group supports a networking protocol then USBLAN can support the virtual device.

USBD – the default Windows USB Bus Driver that controls USB devices connected to the USB.

USBHUB – the Windows USB Hub driver controls the USB ports and any USB Hubs attached to the Windows system.

Enhanced HCI – the Windows Host Controller Driver interfaces the USB Bus Driver to the USB Host Controller hardware.

3.1 NDIS

Microsoft provides different versions of the NDIS API and model. The Belcarra USBLAN driver implements NDIS 5.1 on Windows XP, Server and Server 2003. USBLAN implements NDIS 6.0 on newer versions of Windows, including Windows Server 2008, Windows Vista and Windows 7.

3.2 Station (MAC) Address

For CDC-ECM, CDC-NCM and RNDIS devices, the USBLAN driver will attempt to get the MAC address from the device. In particular, RNDIS has the optional OID_802_3_PERMANENT_ADDRESS query. For CDC EEM there is no provision for the device to specify the MAC address used by the host (PC). In any case, retrieving a MAC address from the device may fail.

In these cases either a randomly generated or pre-defined configurable MAC address can be used. Note that in the former case the Locally Administered bit is set and the MAC address cannot be guaranteed to be unique. See Section 7.1 for more information.

3.3 Composite Function

The Belcarra USBLAN driver is fully compatible with the Windows Generic Parent driver (USBCCGP driver in Figure 3-1 (above)) and supports devices that have implemented a set of network interfaces for one of the supported protocols. Note that for protocols that use 2 interfaces (ECM, NCM, RNDIS) this requires that the device correctly implement its composite configuration with an Interface Association

Figure 3- 1




Descriptor (IAD) and that the network interface be specified in the INF file. The EEM protocol uses a single interface and therefore does not need an IAD descriptor.4

4 Evaluation

The Belcarra USBLAN driver is available from Windows Update for evaluation. This evaluation version will run for one hour at a time. It must be re-plugged to continue use after one hour.

To use the Version 2.4.2 evaluation driver the device should offer Vendor and Product ID’s as follows:

Vendor ID 0x15ec (Belcarra)

Product ID 0xd031

To get the driver, simply ensure that the Windows system is connected to the Internet, plug the device in and let Windows search Windows Update. The protocol (CDC-ECM, CDC-EEM, CDC-NCM, RNDIS) is automatically detected. The INF file of the USBLAN evaluation driver creates global variables in the registry using Service name BelcarraDemoUSBLAN (see Section 5.2). These parameters can be modified later using Regedit.

Alternatively, common operations, like enable or disable DHCP, can be performed by installing the appropriately named INF file in a supplementary package of INF files (available on request). For example, to enable the DHCP feature do the following

right-click on the file dhcpd-enable.inf in Windows Explorer

select the method Install

If a problem is encountered, Belcarra may request you to capture Debug log information. This is captured with the standard utility after setting Debug Level to 3 or 4 (see Section 5.3 below). Note that this DWORD key is not present by default and needs to be added using RegEdit.

4 The Gadget implementation of ECM, found in f_ecm.c does not include the required IAD descriptor. Thus, the g_multi module, which incorporates this function, does not have an IAD descriptor for the ECM group of interfaces. Therefore the ECM component of g_multi does meet the requirements of USBCCGP. However, it is easy to fix this by adding an IAD descriptor to all the USB lists: fs_eth_function (full speed), and

hs_eth_function (high speed, USB2.0). Suitable sample code is found in other places such as the NCM code (f_ncm.c), which has an appropriate IAD descriptor and shows how to add it to the function descriptor lists.




5 Customization

The Belcarra USBLAN driver can be customized to suit the OEM requirements, including the following:

Driver branding – manufacturer name

Driver name

Driver behavior

Most of the driver behavior configuration is controlled through registry entries. These can be preset via the installation INF file or after installation through a custom Windows application, registry editing or interactively using the Windows regedit application.

The driver kit supplied to the OEM will have a complete installation kit customized to the OEM requirements. This will have cross-signed drivers and a signed catalog file. Optionally it may also have a Microsoft signed catalog file and be made available from Windows Update.

The OEM may also modify the INF file, but in that case it would need to be re-signed with the OEM Authenticode certificate and if required re-qualified in with WHQL testing to obtain a Microsoft signed catalog file.

5.1 Versioning

The driver distributions are properly versioned with a Windows Plug and Play version number. This allows for driver updates to install correctly when there are previously installed versions.

5.2 Registry Location

The registry configuration is stored in:

HKM\System\CurrentControlSet\Services\OEMNAMESERVICE

The typical format of the service name is Xyz USBLAN

N.B. Global options are common across all installed USB devices. Per device configuration is not done here.

5.3 General Configuration

USBLAN registry keys are mostly DWORDs (32 bit values). However MAC addresses are QWORDs (64 bit values)

DebugLevel – controls the debug level when the CHK driver (Section 10) is used

UseZLP – if non-zero then a Zero Length Packet (ZLP) will be used to terminate transfers, otherwise a Null Byte Packet (NBP) is sent if a short packet is required to terminate a transfer.

UseNotifications – control if USBLAN will use network notifications to indicate Media state.5

DefaultMacAddress – a default MAC address to use if the device does not provide one.

RandomMacAddress – if set to non-zero a random MAC address will be generated if the device does not provide one (default behavior).

UseCyclePort – if set to non-zero value, the USBLAN driver will use the USB CyclePort6 for remedial action

5 See Section 5.3.2 below

6 See Section 5.3.3 below




5.3.1 UseZLP

A Zero Length Packet (ZLP) is used to terminate a BULK data transfer that would otherwise be a multiple of the endpoint packet size (typically 64 bytes for Full Speed devices and 512 bytes for High Speed devices.) Some devices are not able to properly recognize a Zero Length Packet.

If UseZLP is set to zero then USBLAN will use a Null Byte Packet instead of a ZLP. This is a single null byte (two for CDC-EEM devices) that is sent to terminate any BULK transfer that would otherwise be a multiple of the endpoint packet size.

This option’s value defaults to zero (use NBP).

5.3.2 UseNotifications

Controls how the USBLAN driver will indicate the remote connection status by setting the Media status of the Network interface.

0x0 (zero, default) – use network notifications to indicate Media state for CDC-NCM and CDC-ECM protocols, do not use for other protocols (e.g. CDC-EEM).

0x1 (one) – use network notifications to indicate Media state for any configuration that includes an INTERRUPT endpoint.

0x2 (two) –do not use network notifications to indicate Media state for any configurations, the Media Connection status will always be Media connected.

5.3.3 UseCyclePort

If the USB Device stops accepting data for more than four seconds the USBLAN driver will drop the network frames. If the UseCyclePort7 global option is set (non-zero) then it will use the USB CyclePort

operation to cause a re-enumeration of the device. The default setting (zero) disables this option.

5.4 DHCP Service Configuration

DHCPDType –controls if the built in DHCP service is enabled,

NetworkLIP – the network starting IP address for DHCP assignment

MinLeaseDHCP – the minimum allowed lease time (seconds)

MaxLeaseDHCP – the maximum allowed lease time (seconds)

AddDhcpRoute – if set to one (default) then add a route

The parameters NetworkLIP, NetworkSIP and NetworkMask are all IP addresses. These parameters should be specified in byte-reversed format. For example the DWORD value of NetworkLIP matching 169.254.1.0 is 0x0001FEA9.

5.4.1 DHCPDType

0x0 (Zero, default) – disabled for CDC-NCM and CDC-ECM devices, enabled for all other configurations. This value is implicit if this key is not present.

0x1 (One) – enable for all configurations

0x2 (Two) – disable for all configurations

5.5 Multi-Frame Protocol Configuration

MaxDatagramsSend – maximum number of network frames to send in a single transfer, default 32

7 CyclePort is part of a six-step procedure to clear clogged USB pipes. The complete procedure is described here: http://msdn.microsoft.com/en-us/library/windows/hardware/hh968307(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/hardware/hh968307(v=vs.85).aspx




MaxDatagramsRecv – maximum number of network frames to tell the device to send in a single transfer, default 32

MaxTransferSend – maximum USB transfer size for sending, default 32kbytes

MaxTransferRecv – maximum USB transfer size for receiving, default 32kbytes

MaximumFrameSize – MTU, default 1500 . If this key is not present, a higher frame size can still be negotiated according to standard rules. The RNDIS protocol has a way to interrogate the preferred MTU of the device.

MaximumTotalSize – minimum size for MTU from remote size, default 9000

5.6 EEM Configuration

EEMSendCRC – enable CRC generation for EEM transfers

5.7 NCM Configuration

NCMCRC – enable CRC generation for NCM transfers

5.8 RNDIS

MaxPacketsSend – the maximum number of 512 byte packets in an RNDIS OUT Bulk transfer

MaxPacketsRecv – the maximum number of 512 byte packets in and RNDIS IN Bulk transfer.

5.9 Per Adapter Configuration

Each USB Device is allocated its own NDIS Network interface and there is per adapter configuration available through the Windows Network configuration menus. See the Appendix G for more information on setting a Network MAC Address.

Currently the following is supported:

NetworkAddress – overrides all other MAC address configuration mechanisms




6 Common Configuration Issues

6.1 NCM

Most NCM configuration is done by using device requests to get the device’s required configuration. The maximum send transfer and minimum receive transfer sizes can be set but these may be overridden by the device settings.

The NCMCRC option can be used to enable CRC but this will only be used if the device allows CRC.

The UseZLP option can be used to allow the host to send Zero Length packets to terminate a transfer. The default is to send a Null Byte packet.

The UseNotifications option can be used if the device does not properly indicate network connection status using Network Notifications.

6.2 EEM

The EEM protocol does not specify a mechanism for setting a maximum transfer size. Two common schemes are in use:

Support transfers of any length and guarantee that all transfers are terminated by a short packet, Zero Length packet or Null Byte packet.

Set an agreed maximum transfer size.

Current versions of the Linux Gadget EEM implementation follow the second scheme and require a maximum transfer size set to 1536 bytes. This is done with the MaxPacketsSend and MaxPacketsRecv global options. Operation of the EEM protocol without setting these values correctly will result in poor transfer speeds as data is dropped by the device.

The EEMSendCRC option can be used to enable CRC. If set the CRC is computed and appended to the network frames. If not set the CDC-EEM standard option is to send the constant 0xdeadbeef instead of the computed CRC.

By default the USBLAN driver will default to the following:

CRC – disabled

Max Datagrams – 1

Max Transfer – 1536

These can be changed with the above registry settings.

The driver also implements the Belcarra EEM Echo Response Configuration Request (see appendix). This allows it to query the device, once connected, to determine the devices actual operating parameters. If the device does not support this, then it is merely another ECHO request. See Appendix E – EEM Echo Response Request Configuration for more information.

6.3 ECM

The UseZLP option can be used to allow the host to send Zero Length packets to terminate a transfer.

The default is to send a Null Byte packet.

The UseNotifications option can be used to if the device does not properly indicate network connection status using Network Notifications.

6.4 Zero Length versus Null Byte Packets

Some USB devices do not properly support Zero Length packets.

The UseZLP option can be used to allow the host to send Zero Length packets to terminate a transfer. The default is to send a Null Byte packet. Note that for CDC-EEM two NULL bytes are sent (as this is a legal EEM command.)




6.5 DHCP IP Address Allocation

The USBLAN built-in DHCP service can optionally be used to coordinate IP address assignment between the host and multiple devices.

Each device that is attached will get its own NDIS network interface so the requirement is for every network interface and every device to be assigned a distinct IP address.

This is done by allocating /298 networks out of a non-routable network. e.g. 192.168.100. Each IP address is assigned offsets from NetworkLIP (See Section 4.4 above) according to the following scheme for the N’th device:

Wire address (N-1)*8

Host: (N-1) * 8 + 1

Device: (N-1)*8 + 2

DHCP server (N-1)*8+3

Broadcast address (N-1)*8+7

The DHCP reply includes a route that properly describes the allocated sub-network so that the host and device can properly route network traffic.

In hex the base address (NetworkLIP) is C0A86400 with the following assignments for the first three devices

Device Index

Host Device Broadcast

Hex Dotted decimal Hex Dotted decimal Hex Dotted decimal

0 C0A86401 192.168.100.1 C0A86402 192.168.100.2 C0A86407 192.168.100.7

1 C0A86409 192.168.100.9 C0A8640A 192.168.100.10 C0A8640F 192.168.100.15

2 C0A86411 192.168.100.17 C0A86412 192.168.100.18 C0A86417 192.168.100.23

Note that NetworkLIP must always be a multiple of 256 (hex 0x100), i.e. the last byte is ignored. So specifying NetworkLIP value C0A86408 is the same as value C0A86400. Finally, the NetworkLIP value is entered into the registry byte-reversed order: 0064A8C0

6.6 Notifications

The CDC-NCM and CDC-ECM protocols require the device to send notifications to the host representing the current network speed and connection status.

The host uses the network connection status to enable or disable the data endpoints and to indicate to Windows NDIS a CABLE CONNECTED or DISCONNECTED status.

Some devices do not properly implement this part of the CDC protocols.

To work around this the UseNotifications configuration option is available. Setting UseNotifications to two (0x2) will disable the use of Notifications for CDC ECM and CDC NCM devices.

N.B. The UseNotifications option is ignored for RNDIS devices. The RNDIS protocol uses a different style of Notification to signal when an RNDIS query is complete. The device must implement the RNDIS notification for RNDIS to function correctly.

8 More precisely a Classless Inter-Domain Routing block of 8 addresses. See http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks

http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks




7 Operation

7.1 Station Address

The Station Address (MAC address) of the Network interface will be set according to the following rules:

Use what the device provides, typically CDC-NCM and CDC-ECM devices specify a USB string containing the MAC address as part of the CDC Ethernet Networking Descriptor iMACAddress field.

Generate a Random address with the locally administered bit set if the UseRandomAddress global option is set to a non-zero value.

Use the contents of the DefaultMacAddress if non-zero.

7.2 IP Address Configuration

Windows can configure the IPv4 address using:

DHCP o USBLAN internal DHCP o DHCP on device o DHCP on Windows separate from USBLAN

Static

Auto-IP – self-assigned temporary IP address matching 169.254.x.x, guaranteed to be distinct from other addresses on the segment but otherwise random.

This is done via the standard Windows networking configuration.

Note that DHCP address configuration can be done with the built-in DHCP service or with a DHCP server located elsewhere. If another host DHCP server is used it must be local (run on the same Windows system) or it must be bridged to the USBLAN-created Network interface where the DHCP server will satisfy DHCP requests. This can be difficult since the interface is transient – disappears when the device is not connected.

7.3 Media Status

The USBLAN driver will indicate the correct Media Status, one of the following:

Media connected

Media disconnected.

The USBLAN driver will indicate the response to Management Network Notifications from the USB Device if the device:

Uses the CDC-NCM or CDC-ECM protocols and the UseNotifications option is set to zero or one

If the device uses a configuration that includes an Interrupt endpoint and the UseNotifications option is set to one.

uses the RNDIS protocol

This allows the device to control the configuration of the host (PC) network interface and when (or if) Windows applications can use it.

In all other cases USBLAN will indicate the Media status as Media connected for the duration of the connection.

N.B.: RNDIS devices indicate Media Connected when the OID_GEN_CURRENT_PACKET_FILTER_REQUEST is sent.




7.4 Multiple Devices

Multiple supported USB devices can be used at the same time. Each will have its own Network interface.

7.4.1 Installation of Multiple Devices with Serial Numbers

The first time a USB device is connected that can be uniquely identified (vendor ID, product ID and device serial number) Windows installs the drivers for that device. Regardless of which USB port the device is plugged into Windows continues to use the drivers and configuration associated with the device.

A similar device (same vendor ID and product ID) with a different USB serial number will require installation of drivers and will have a separate network configuration even if plugged into the same USB port.

Likewise, plugging a device with a unique serial number into a different serial port maintains the same driver.

7.4.2 Installation of Multiple Devices without Serial Numbers

USB devices that do not have USB serial numbers are associated with specific USB ports to which they are connected. This has two side effects:

The same device plugged into a different USB port needs to have drivers installed for the new port and will have a separate network configuration.

Another device with the same vendor and product ID, but with no serial number plugged into

the same port previously used for another device will not require driver installation and will use

the network configuration associated with that USB port.




8 Installation Kit

Belcarra can provide two types of kits. The default is a kit signed with Belcarra’s Software Publishing Certificate. The installation kit provided includes everything needed to do a DIF based pre-install of the driver on a Windows system (see Section 8.2 below).

Secondly a Microsoft “signature-only” kit is an available option. The advantage of a Microsoft signed kit is it will enhance the user experience with a “silent install” (i.e. will not ask if the user trusts the publisher, or similar dialogue boxes). The Microsoft signed driver kit may be made available to end users via Windows Update using the Windows Driver Distribution Center (DDC).

8.1 NDIS 5 and 6

This kit contains NDIS 5 drivers to install on Windows XP, Server and Server 2003 and NDIS 6 drivers that will install on all newer versions of Windows, Server 2008, Vista and Windows 7.

The kit will contain the following files (possibly with different file names to match the OEM branding in place):

./setup.bat

./driver5/belcarrademo.cat

./driver5/belcarrademo.inf

./driver6/belcarrademo.cat

./driver6/belcarrademo.inf

./driver5/amd64/btblan.sys

./driver6/amd64/btblan.sys

./driver5/i386/btblan.sys

./driver6/i386/btblan.sys

./DPInst/MultiLin/amd64/DPInst.exe

./DPInst/MultiLin/x86/DPInst.exe

./README-INSTALL.txt

./README-USBLAN.txt

The end user can pre-install the drivers using the setup.bat file. This in turn runs the appropriate version

of DPInst.exe which will cache the drivers where Windows can find them when a device is plugged in.

8.2 DIF Directed Install

The setup and uninstall bat files use the DPInst.exe program to pre-install or remove the USBLAN driver. This will allow installation of the drivers when the USB device is enumerated. The setup.bat and uninstall.bat files can be run by clicking on them or by running from the DOS command line.

Refer to Appendix E for further information on how to do this in Windows 7.

N.B. the DPInst software is owned and licensed by Microsoft which allows re-distribution for this purpose.

8.3 Repackaging the distribution kit – without re-signing

OEM’s can repackage the installation kit into their software installation package. The files in the driver000 directory are the minimum required. Note that these are signed files and cannot be modified without re-signing.

8.4 Repackaging the distribution kit – with re-signing

The INF file can be modified if required. The OEM must have the appropriate tools from the Windows DDK to do code signing and will require an Authenticode Code Signing certificate.

The DDK tools needed are:

Inf2Cat.exe

SignTool.exe




The Inf2Cat program is used to generate the new catalog files.

The SignTool program is used in conjunction with the OEM Code Signing certificate to re-sign the catalog files.

If you are re-signing the catalog file you may wish to also obtain and re-sign the DPInst.exe files. These are available in the Windows WDK and should be signed with your Authenticode certificate.

If necessary you can obtain current copies of the DPInst program from Microsoft (in the current DDK). These should be signed using your own certificate prior to distribution.

It should not be necessary to re-sign the driver .sys files.

See the Appendix for specific information on running these tools.

8.5 Windows Logo Program – Signature Only

The USBLAN driver can be made available with a Microsoft digital signature. There are various avenues for pursuing this option.

First is whereby Belcarra makes available their own Windows “Signature –only” release. These can be modified (INF file only), provided with a re-signed catalog file and submitted through the Microsoft DUA (Driver Update Acceptable) process.

Secondly is where Belcarra would do a resell of their submission to an OEM that is registered with Microsoft’s sys-dev program.

Alternately an OEM can run the Windows logo submission tests and submit new results and complete their own certification.




9 Installation Scenarios

9.1 Windows Update

Internet-connected Windows systems have access to the Windows Update service. When permitted by local policy (this includes consumer editions of Windows), when an unknown device is plugged into a Windows system it will use the device information (in the case of a USB device the Vendor ID and Product ID) to search in Windows Update for a matching driver. If a matching driver is found then it is downloaded and installed.

The requirements for this type of installation are:

The driver kit must be put through Windows Logo Kit (WLK or HCK) testing and received a verification report and Microsoft digital signature for the version of Windows to be supported.

For each version of Windows to be supported the accepted submission must be released for downloading from the Driver Distribution Center.

9.2 Pre-Installed

Pre-installation is way to install a driver on a Windows machine for later use when a matching device is connected. Windows, as distributed, has many drivers for various devices which may or may not be actually connected to the machine. The first time a new device is connected, the New Hardware Wizard attempts to find a match from the driver store. The pre-installation simply adds the USBLAN driver to the driver store with matching hardware ID’s (Vendor ID/Product ID pairs) supplied by the OEM.

The driver kit can be distributed to end users, for example as a ZIP file or on a CD.

The end user is instructed to unpack the ZIP file or insert the CD into his system. Then the setup bat file must be run as part of an AutoStart sequence from a CD, by clicking on it or by running it from the DOS command line explicitly or via Windows Explorer. Refer to Appendix F for an example of doing this in Windows 7.

When a new USB device is found Windows will attempt to find the device’s hardware ID in Windows Update. If this fails (or the user skips this step) then Windows will look in the local driver store and find the driver. Installation will then proceed. In certain environments, group policy (security policy) blocks Windows Update, even when the Internet is available. In these environments, a pre-installation from a local source is the best alternative.

9.3 Directed

The driver can be installed directly from a directory. If Windows fails to find the driver (not in Windows Update, not found in the local driver store) then it will mark the USB device as not installed. Windows will create an entry for it the device manager, but with a yellow triangle indicating that no driver was found. The user can then direct the Device Manager to use a driver from a specific directory --- the location where the USBLAN ZIP file has been unpacked. Windows XP requires the user to navigate to the exact directory containing the matching driver. Windows Vista and Windows 7 match on any directory containing a matching driver, i.e. the top-level directory of the extracted USBLAN ZIP archive.

Once a matching driver directory is found, Windows will then allow installation to proceed. If the same driver has already been installed, then Windows will issue a message that no better driver is available.

9.4 Removal of the driver

Removal of the driver is a two-step process. First any USB devices using the driver must be removed. This is done via the Device manager (via the Windows Control Panel). Connect each device in turn, find its entry in the Device Manager tree, and use the Device manger to Uninstall the device.




Second if the driver was installed using the setup bat script DPInst will have added an entry to the Programs and Features in Control Panel to allow removal of the driver package. Users can select this entry within Programs and Features to remove the driver package. If a user removes a driver package the package is removed from the DIFx driver store, the corresponding INF file is removed from the system INF file directory, and all the devices that were previously supported by the package are updated with the next best available driver.

N.B. In versions of Windows earlier than Windows Vista, DPInst added the entry for the driver package to Add or Remove Programs in Control Panel.

10 Debug

The OEM kit may contain (by request) a debug version of the Belcarra USBLAN driver. This is commonly referred to as the “chk” version. If this is installed debug trace messages can be viewed using the Sysinternal Tool DbgView.

The level of debugging is controlled by the follow USBLAN configuration variable DebugLevel from the registry (cf Section 5.2ff above):

DebugLevel

This registry key is a DWORD. The possible debug levels are:

0x0 - Minimal (assumed if this parameter is not specified) – driver loading and unloading announcements

0x1 - Default - configuration

0x2 - Medium – some additional information on data transfers

0x3 - High – detailed information on data transfers

0x4 - Maximum – everything in detail




APPENDICES

Appendix A - Connection Semantics for CDC-NCM and CDC-ECM Devices

This is the default behavior for CDC-NCM, CDC-ECM devices. It is also used for devices that have an INTERRUPT endpoint if the UseNotifications global flag is set to one.

1 Enumeration

a) Host Configuration

Set Configuration

Set Interface – No-Data

b) Device Enable INTERRUPT endpoint

Send Notifications (CDC-ECM devices)

c) Host Set Interface – Data

d) Device Enable DATA endpoints

Send Notifications (CDC-NCM devices)

e) Host Indicate Media status (match received network notification)

2 Device notifies disconnected to connected transition

a) Device Send Notifications

b) Host Indicate Media connected

Device notifies connected to disconnected transition

c) Device Send Notifications

d) Host Indicate Media disconnected

N.B. USBLAN will only issue the set interface device requests for devices that have a separate setting for the data interface.




Appendix B - Connection Semantics for Other (non NCM and ECM) Devices

This is the default behavior for non CDC-NCM or CDC-ECM devices that have an INTERRUPT endpoint or for CDC-NCM and CDC-ECM devices and if the UseNotification global is set to two.

1) Enumeration a) Host

Configuration

Set Configuration

Set Interface – No-Data

Set Interface – Data

Indicate Media status connected

b) Device Enable DATA endpoints

Send Notifications (CDC-NCM devices)

2) Device notifies disconnected to connected transition a) Device Send Notifications

b) Host ignored

3) Device notifies connected to disconnected transition a) Device Send Notifications

b) Host

4) ignored

N.B. USBLAN will only issue the set interface device requests for devices that have a separate setting for the data interface.




Appendix C - Signing a Modified INF file

Requirements:

Authenticode Code Signing Certificate

Inf2Cat.exe

Signtool.exe

The following lines show the commands required to regenerate the catalog files and re-sign them. Inf2Cat.exe /os:XP_X86,Server2003_X86,Vista_X86,XP_X64,Server2003_X64,Vista_X64 "/driver:."

Signtool.exe sign /f yourcert.pfx /p yourpasswd /t http://timestamp.verisign.com/scripts/timestamp.dll OEMNAME5.cat

Signtool.exe sign /f yourcert.pfx /p yourpasswd /t http://timestamp.verisign.com/scripts/timestamp.dll OEMNAME56.cat




Appendix D - EEM Streaming

USB Devices that implement CDC-EEM can achieve much higher throughput by implementing EEM streaming. CDC-EEM does not define a maximum transfer size and allows a sender to continue to append and send EEM conforming data until a Short Packet is transferred.

Most USB implementations do not support unlimited bulk transfers. However, EEM streaming may still be implemented if the following rules are followed on the device implementing EEM.

Rules for receiving data:

Set up a receive transfer with a multiple of the endpoint packet size as the maximum transfer size.

Parse the received data for EEM frames, forwarding them to the network layer as they are found.

If the transfer is not terminated by a Short Packet (i.e. it is the full size of your transfer buffer) then a valid network frame may extend past the end of the transfer. In this case save the partial frame and wait for the next receive data transfer.

When a data transfer arrives, check if you have a partially completed network frame, if that exists then get the rest of the network frame from this transfer.

Note that this process can continue indefinitely.

Rules for sending data:

When sending a data transfer, pad the transfer to a multiple of the packet size by using the EEM ZLP (two null bytes).

When the last data transfer has completed send a ZLP (Zero Length Packet) or ZLE (EEM short transfer, two NULL bytes) transfer to ensure that the receiver terminates the current receive transfer and processes any completed frames.

The MaxDatagramsSend and MaxDatagramsRecv global options must be set to zero (the default settings)

to allow EEM streaming with the USBLAN driver.




Appendix E – EEM Echo Response Request Configuration

The CDC-EEM protocol is capable of aggregating multiple network datagrams into a single Bulk Data transfer.

The standard does not implement a mechanism to allow the host and device to determine an appropriate size for Bulk transfers. While implementing EEM without this information is possible, it complicates the implementation. If the Host and Device know what the capabilities of the other end are (WRT to transfer size especially) then the driver implementations can be significantly simpler and easier to implement.

This has led to many implementations only allowing for a maximum of 1536 byte transfers (based on Ethernet MTU of 1510 bytes.) and a single datagram per transfer. Other implementations require administrative configuration to configure one or more of the operating parameters.

The result is that the only safe configuration that can support unknown hosts or devices is:

CRC - disabled bMaxDatagrams - 1 bMaxTransferSize - 1536

This extension described herein can be used by an EEM Class driver on the host to send configuration data to the device and receive configuration data from the device. The EEM Configuration Extension Descriptor is sent to the device as Echo Data command data.

If the device is non-conforming (does not support this extension), it will either ignore or send the command back unchanged (specifically the D0 flag of the bmFlags field will remain reset.) In this case the host will continue to use the default configuration.

Conforming devices will send the command back, but will fill in the configuration fields. If the device receives this command it can assume that the host will use the information to operate with. Otherwise they will operate with the default configuration. Conforming devices MUST SET the D0 bit of the bmFlags field to indicate that they have recognized this configuration request and are responding with valid values.

Table E-1 EEM Configuration Extension Descriptor

Offset Field Size Value Description

0 EEM Command 2 8014 EEM Command specified ECHO DATA with payload of 20 bytes.

2 bGUID 16 16 byte GUID

0x23, 0x57, 0x1b, 0x05, 0xfd, 0x18, 0x45, 0x81,

0x93, 0x62, 0xa1, 0x6c, 0xee, 0xfc, 0xcc, 0xdf

18 bmFlags 2 bitmask D2: use CRC, D1: multi-datagrams supported, D0: confirmed

20 bMaxTransferSize 2 integer Maximum number of bytes per transfer, must be a multiple of of the endpoint packetsize.




EEM Command - this is an EEM Echo Data command with a payload length of 20 bytes. bmFlags - if the host supports CRC it will set the D2 bit. The device can return the flag set if it wants to support CRC or reset it to tell the host not to use CRC. The D1 bit is set if the host supports receiving transfers with multiple datagrams. The device must set or reset the D1 bit to show its support for multiple datagrams. The host must send the D0 bit reset. The device will always set the D0 bit to indicate that it recognized and is using the configuration data.

D0 - Confirmed - set if device recognized this request and is responding with valid data D1 - Multiple Datagrams Supported - multiple datagrams per EEM Bulk transfer allowed D2 - CRC is supported

bMaxTransferSize - the host sends the maximum number of bytes (a multiple of the endpoint packet size) in an IN transfer. In reply, the device sends the maximum for an OUT transfer.




Appendix F - DIFx Installation Information

For more information on DIFx installation procedures see the following pages from Microsoft:

Driver Install Frameworks (DIFx) - http://msdn.microsoft.com/en-us/library/ff544838(v=VS.85).aspx

Driver Package Installer (DPInst)- http://msdn.microsoft.com/en-us/library/ff544842(v=VS.85).aspx

Device and Driver Installation Software Tools - msdn.microsoft.com/en-us/library/ff541185(v=VS.85).aspx

How to Get the WDK - msdn.microsoft.com/en-us/windows/hardware/gg487463.aspx

Driver Install Frameworks (DIFx) - http://msdn.microsoft.com/en-us/library/ff544838(v=VS.85).aspx

Driver Package Installer (DPInst)- http://msdn.microsoft.com/en-us/library/ff544842(v=VS.85).aspx

Device and Driver Installation Software Tools - http://msdn.microsoft.com/en-us/library/ff541185(v=VS.85).aspx

http://msdn.microsoft.com/en-us/library/ff544838(v=VS.85).aspx






http://msdn.microsoft.com/en-us/windows/hardware/gg487463.aspx










Appendix G - Installation Screenshots

This shows how to install the drivers in Windows 7 using the setup.bat script

Figure G-1 – Find and Open Setup.bat

Figure G-3 – Click next in the Installation Wizard

Figure G-5 – Approve the publisher of the drivers

Figure G-2 – Approve the publisher for DPInst.exe

Figure G-4 – Files copying

Figure G-6 - Success




Appendix H - Setting a MAC address for a Specific USB Device

The following illustrates finding and setting a specific Network Station Address (also known as a MAC address). Note that locally administered bit must be set (bit 2 in first octet)

Figure H-1 – Locate the network interface

Figure H-3 – Select Configure

Figure H-2 – Select Properties

Figure H-4 – Select Advanced Tab

Figure H-5 – Enter an Address




Appendix I - Bridging USB Device to another network

Figure I -1

Figure I-3

Hold CTRL and select the two networks to be bridged, then right click and enable bridge.

Figure I-2

"Change adapter settings"

Figure I-4

At this point there is (typically) no requirement to set an IP address for the Windows NDIS interface.

DHCP requests from the USB Device will be sent to the other network




Appendix J - INF for Installation of NDIS driver

1) INF for Installation of NDIS5 driver for all types of Windows The NDIS5 driver can be installed for all versions of windows (newer than WinXP SP2). This requires that a single INF file present matching rules for the appropriate versions of windows.

This example shows the parts of the belcarrademo.inf file that are required: [Version]

CatalogFile = belcarrademo.cat

;

[Manufacturer]

%BTCUsbLan.Manufacturer% = Belcarra, NTx86.5.0, NTamd64.5.0, NTx86.6.0, NTamd64.6.0

;

[SourceDisksFiles]

btblan.sys=1

;

[DestinationDirs]

BTCUsbLan.CopyFiles = 12 ; WINDOWS\SYSTEM32\DRIVERS

;

[BTCUsbLan.CopyFiles]

btblan.sys

;

[BTCUsbLan.AddService]

ServiceBinary = %12%\btblan.sys

;

; This INF file WILL MATCH for .NTx86.5.0

[Belcarra.NTx86.5.0]

%BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB\VID_15ec&PID_d021

%BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB2\VID_15ec&PID_d021

;

; This INF file WILL MATCH for .NTamd64.5.0

[Belcarra.NTamd64.5.0]



;





;





;

2) Multiple INF files for Installation of NDIS5 or NDIS6 driver To install the NDIS5 driver on older versions of Windows and the NDIS6 driver on compatible newer versions of Windows requires two INF files. These must both be in the driver000 directory and have separate names.

The first INF file is setup to match older versions of windows (version 5 or newer) but not the most recent (version 6 or newer). The second INF file is setup to match only newer versions.

a) This example shows the parts of the driver5/belcarrademo.inf file setup to match only the older versions of Windows and install the NDIS5 driver: [Version]

CatalogFile = belcarrademo5.cat

;

[Manufacturer]


;




[SourceDisksFiles]

btblan5.sys=1

;

[DestinationDirs]


;


btblan5.sys

;


ServiceBinary = %12%\btblan5.sys

;





;





;

; This section MUST BE PRESENT to prevent matching for .NTx86.6.0


;

; This section MUST BE PRESENT to prevent matching for .NTamd64.6.0


;

b) This example shows the parts of the parts of the driver6/belcarrademo.inf file setup to match only the newer versions of Windows and install the NDIS6 driver: [Version]

CatalogFile = belcarrademo6.cat

;

[Manufacturer]


;

[SourceDisksFiles]

btblan6.sys=1

;

[DestinationDirs]


;


btblan6.sys

;


ServiceBinary = %12%\btblan6.sys

;

; This section MUST BE PRESENT to prevent matching for .NTx86.5.0


;

; This section MUST BE PRESENT to prevent matching for .NTamd64.5.0


;





;








;

Appendix K - Sample Configuration Descriptors

1) CDC-ECM Device descriptor [ ] 12 01 00 02 02 06 00 40 ec 15 21 f0 00 01 03 04 05 01

bcdUSB [ 2] 0200

bDevice[Class,Sub,Pro] [ 4] 02 06 00

bMaxPacketSize0 [ 7] 40

idVendor [ 8] 15ec

idProduct [ 10] f021

bcdDevice [ 12] 0100

bNumConfigurations [ 17] 01

iManufacturer [ 3:18 ] Belcarra

iProduct [ 4:34 ] Belcarra CDC-ECM

iSerialNumber [ 5:46 ] 0202020202020020202021

Configuration descriptor [1 ] 09 02 50 00 02 01 0b e0 01

wTotalLength [ 4] 50

bNumInterfaces [ 4] 02

bConfigurationValue [ 5] 01

iConfiguration [11:16 ] cdc-ecm

bmAttributes [ 7] e0 Self-Powered Remote-Wakeup

bMaxPower [ 8] 01

Interface descriptor [1:0:0 ] 09 04 00 00 01 02 06 00 0c

bInterfaceNumber [ 2] 00

bAlternateSetting [ 5] 00

bNumEndpoints [ 5] 01

bInterface[Class,Sub,Pro][ 5] 02 06 00

iInterface [12:52 ] Belcarra USBLAN - CDC/ECM

Class descriptor [1:0:1 ] 05 24 00 10 01

Class descriptor [1:0:2 ] 0d 24 0f 06 00 00 00 00 ea 05 00 00 00


Endpoint descriptor [1:0:0:1] 07 05 82 03 10 00 01

Interface descriptor [1:1:0 ] 09 04 01 00 00 0a 00 00 0d




bInterface[Class,Sub,Pro][ 5] 0a 00 00

iInterface [13:68 ] Belcarra USBLAN - CDC/ECM No Data

Interface descriptor [1:2:0 ] 09 04 01 01 02 0a 00 00 0e





iInterface [14:62 ] Belcarra USBLAN - CDC/ECM Data



LangID [ 0 ] 4: 3 0904

String [ 3:18 ] Belcarra

String [ 4:34 ] Belcarra CDC-ECM

String [ 5:46 ] 0202020202020020202021

String [ 6:26 ] 02c35d8325bf

String [ 7:16 ] cdc-ecm

String [ 8:52 ] Belcarra USBLAN - CDC/ECM

String [ 9:68 ] Belcarra USBLAN - CDC/ECM No Data

String [10:62 ] Belcarra USBLAN - CDC/ECM Data




String [11:16 ] cdc-ecm

String [12:52 ] Belcarra USBLAN - CDC/ECM

String [13:68 ] Belcarra USBLAN - CDC/ECM No Data

String [14:62 ] Belcarra USBLAN - CDC/ECM Data

CDC-EEM

Device descriptor [ ] 12 01 00 02 02 0c 07 40 ec 15 21 f0 00 01 03 04 05 01

bcdUSB [ 2] 0200

bDevice[Class,Sub,Pro] [ 4] 02 0c 07


idVendor [ 8] 15ec





iProduct [ 4:34 ] Belcarra CDC-EEM

iSerialNumber [ 5:46 ] 0202020202020020202022

Configuration descriptor [1 ] 09 02 20 00 01 01 08 e0 01




iConfiguration [ 8:16 ] cdc-eem


bMaxPower [ 8] 01

Interface descriptor [1:0:0 ] 09 04 00 00 02 02 0c 07 09




bInterface[Class,Sub,Pro][ 5] 02 0c 07

iInterface [ 9:38 ] Belcarra - CDC/EEM



LangID [ 0 ] 4: 3 0904


String [ 4:34 ] Belcarra CDC-EEM

String [ 5:46 ] 0202020202020020202022

String [ 6:16 ] cdc-eem

String [ 7:38 ] Belcarra - CDC/EEM

String [ 8:16 ] cdc-eem

String [ 9:38 ] Belcarra - CDC/EEM

CDC-NCM

Device descriptor [ ] 12 01 00 02 02 0d 00 40 ec 15 21 f0 00 01 03 04 05 01

bcdUSB [ 2] 0200

bDevice[Class,Sub,Pro] [ 4] 02 0d 00


idVendor [ 8] 15ec





iProduct [ 4:34 ] Belcarra CDC-NCM

iSerialNumber [ 5:46 ] 0202020202020020202023

Configuration descriptor [1 ] 09 02 56 00 02 01 0b e0 01




iConfiguration [11:16 ] cdc-ncm


bMaxPower [ 8] 01

Interface descriptor [1:0:0 ] 09 04 00 00 01 02 0d 00 0c







bInterface[Class,Sub,Pro][ 5] 02 0d 00

iInterface [12:52 ] Belcarra USBLAN - CDC/NCM




Class descriptor [1:0:4 ] 06 24 1a 00 01 29


Interface descriptor [1:1:0 ] 09 04 01 00 00 0a 00 01 0d





iInterface [13:68 ] Belcarra USBLAN - CDC/NCM No Data

Interface descriptor [1:2:0 ] 09 04 01 01 02 0a 00 01 0e





iInterface [14:62 ] Belcarra USBLAN - CDC/NCM Data



LangID [ 0 ] 4: 3 0904


String [ 4:34 ] Belcarra CDC-NCM

String [ 5:46 ] 0202020202020020202023

String [ 6:26 ] 4238adc4899b

String [ 7:16 ] cdc-ncm

String [ 8:52 ] Belcarra USBLAN - CDC/NCM

String [ 9:68 ] Belcarra USBLAN - CDC/NCM No Data

String [10:62 ] Belcarra USBLAN - CDC/NCM Data

String [11:16 ] cdc-ncm

String [12:52 ] Belcarra USBLAN - CDC/NCM

String [13:68 ] Belcarra USBLAN - CDC/NCM No Data


2) Basic Device descriptor [ ] 12 01 00 02 02 0a 00 40 ec 15 21 f0 00 01 03 04 05 01

bcdUSB [ 2] 0200

bDevice[Class,Sub,Pro] [ 4] 02 0a 00


idVendor [ 8] 15ec





iProduct [ 4:38 ] Belcarra NET-BASIC

iSerialNumber [ 5:46 ] 0202020202020020202033

Configuration descriptor [1 ] 09 02 27 00 01 01 08 e0 01




iConfiguration [ 8:20 ] net-basic


bMaxPower [ 8] 01

Interface descriptor [1:0:0 ] 09 04 00 00 03 ff 01 01 09







bInterface[Class,Sub,Pro][ 5] ff 01 01

iInterface [ 9:34 ] Belcarra - BASIC




LangID [ 0 ] 4: 3 0904


String [ 4:38 ] Belcarra NET-BASIC

String [ 5:46 ] 0202020202020020202033

String [ 6:20 ] net-basic

String [ 7:34 ] Belcarra - BASIC

String [ 8:20 ] net-basic

String [ 9:34 ] Belcarra - BASIC

3) CDC-NCM-MSC

This demonstrates composite configuration with IAD descriptors. Device descriptor [ ] 12 01 00 02 ef 02 01 40 ec 15 5d c0 00 01 03 04 05 01

bcdUSB [ 2] 0200

bDevice[Class,Sub,Pro] [ 4] ef 02 01


idVendor [ 8] 15ec

idProduct [ 10] c05d




iProduct [ 4:28 ] CDEMO NCM+MSC

iSerialNumber [ 5:66 ] 0123456789ABCDEF0123456789ABCD18

Configuration descriptor [1 ] 09 02 7d 00 03 01 0e e0 01

wTotalLength [ 4] 7d



iConfiguration [14:28 ] cdemo-ncm-msc


bMaxPower [ 8] 01

IAD descriptor [1:0 ] 08 0b 00 02 02 0d 00 0f

bFirstInterface [ 2] 00

bInterfaceCount [ 3] 02

bFunction[Class,Sub,Pro] [ 4] 02 0d 00

iFunction [15:52 ] Belcarra USBLAN - CDC/NCM

Interface descriptor [1:0:0 ] 09 04 00 00 01 02 0d 00 10




bInterface[Class,Sub,Pro][ 5] 02 0d 00

iInterface [16:52 ] Belcarra USBLAN - CDC/NCM




Class descriptor [1:0:4 ] 06 24 1a 00 01 29


Interface descriptor [1:1:0 ] 09 04 01 00 00 0a 00 01 11








iInterface [17:68 ] Belcarra USBLAN - CDC/NCM No Data

Interface descriptor [1:2:0 ] 09 04 01 01 02 0a 00 01 12





iInterface [18:62 ] Belcarra USBLAN - CDC/NCM Data



IAD descriptor [1:3 ] 08 0b 02 01 08 06 50 13

bFirstInterface [ 2] 02

bInterfaceCount [ 3] 01

bFunction[Class,Sub,Pro] [ 4] 08 06 50

iFunction [19:68 ] Belcarra Mass Storage - Bulk Only

Interface descriptor [1:3:0 ] 09 04 02 00 02 08 06 50 14




bInterface[Class,Sub,Pro][ 5] 08 06 50

iInterface [20:92 ] Belcarra Mass Storage - Bulk Only - Alternate



LangID [ 0 ] 4: 3 0904


String [ 4:28 ] CDEMO NCM+MSC

String [ 5:66 ] 0123456789ABCDEF0123456789ABCD18

String [ 6:26 ] da8db632c0b5

String [ 7:28 ] cdemo-ncm-msc





String [12:68 ] Belcarra Mass Storage - Bulk Only

String [13:92 ] Belcarra Mass Storage - Bulk Only - Alternate

String [14:28 ] cdemo-ncm-msc





String [19:68 ] Belcarra Mass Storage - Bulk Only

String [20:92 ] Belcarra Mass Storage - Bulk Only - Alternate




Revision Summary

Date

Revision History

Revision Class

Comments

July 2011 2.4 Initial 2.4 version.

Oct 2011 2.4.1 2.4.1 - RNDIS

Nov 2011 2.4.1 2.4.1 – EEM Configuration Request, kit contents

Oct 2012 2.4.2 2.4.2 – RNDIS update, USB3, changes to registry settings

Documents

Belcarra USBLAN_2 4_2 Manual