Belcarra USBLAN - 2 4 - 2 Manual

Belcarra USBLAN for Windows
Version 2.4.2
OEM Manual September 2012
Contents
1 Introduction 1.1 2 References 6 Common Configuration Issues 6.1 6.2 6.3 NCM EEM ECM 10 5.9 Per Adapter Configuration 9.2 9.3 9.4 Pre-Installed Directed Removal of the driver
Overview 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Windows Platforms Windows Features Installation Kit Compatibility Supported Protocols CDC NCM CDC EEM CDC ECM Microsoft RNDIS
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
6.4 Zero Length versus Null Byte Packets 6.5 DHCP IP Address Allocation 6.6 7 Notifications
Operation 7.1 Station Address
Architecture 3.1 NDIS
7.2 IP Address Configuration 7.3 Media Status
3.2 Station (MAC) Address 3.3 4 5 Composite Function
Evaluation Customization 5.1 5.2 Versioning Registry Location 8
7.4 Multiple Devices 7.4.1 Installation of Multiple Devices with Serial Numbers 7.4.2 Installation of Multiple Devices without Serial Numbers Installation Kit 8.1 8.2 NDIS 5 and 6 DIF Directed Install
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 5.7 5.8
OEM Manual Page 2
8.3 Repackaging the distribution kit without resigning 8.4 Repackaging the distribution kit with resigning 8.5 Windows Logo Program Signature Only 9 Installation Scenarios 9.1 Windows Update
EEM Configuration NCM Configuration RNDIS
Copyright 2012 Belcarra Technologies (2005) Corp.
October 12, 2012 www.belcarra.com
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-90CDC350D0C14A53/%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
OEM Manual Page 3
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 2
A personal area network (PAN) device An infrastructure device 3 Except IA64 architectures.
OEM Manual Page 4 Copyright 2012 Belcarra Technologies (2005) Corp. October 12, 2012 www.belcarra.com
Belcarra USBLAN for Windows 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 OEMs requirements: Branded with OEM Name Configured with the OEM Vendor ID and Product IDs 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 Microsofts 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
Other protocols: Microsoft RNDIS Belcarra BLAN Belcarra SAFE Gadget Simple / Belcarra Basic Belcarra Basic2
USB Communications Class Standards: CDC NCM CDC EEM CDC ECM
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
OEM Manual Page 5

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.
OEM Manual Page 6
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 Figure 3- 1 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
OEM Manual Page 7

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
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 IDs 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.
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.
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 6
See Section 5.3.2 below See Section 5.3.3 below

Copyright 2012 Belcarra Technologies (2005) Corp. October 12, 2012 www.belcarra.com
OEM Manual Page 9

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 options 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 CDCECM 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
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

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
OEM Manual Page 11
Common Configuration Issues
6.1 NCM
Most NCM configuration is done by using device requests to get the devices 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.)
Belcarra USBLAN for Windows 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 Nth 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 Hex 0 1 2
C0A86401 C0A86409 C0A86411
Host Dotted decimal

192.168.100.1 192.168.100.9 192.168.100.17
Device Hex
C0A86402 C0A8640A C0A86412
Broadcast Hex
C0A86407 C0A8640F C0A86417
Dotted decimal
192.168.100.2 192.168.100.10 192.168.100.18
Dotted decimal
192.168.100.7 192.168.100.15 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.
More precisely a Classless Inter-Domain Routing block of 8 addresses. See http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks

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.
OEM Manual Page 14
Belcarra USBLAN for Windows 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.
OEM Manual Page 15
Installation Kit
Belcarra can provide two types of kits. The default is a kit signed with Belcarras 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

OEMs 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
OEM Manual Page 16

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 Microsofts sys-dev program. Alternately an OEM can run the Windows logo submission tests and submit new results and complete their own certification.
OEM Manual Page 17
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 IDs (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 devices 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.
OEM Manual Page 18

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
OEM Manual Page 19
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.
OEM Manual Page 20
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.
OEM Manual Page 21
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
OEM Manual Page 22
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.
OEM Manual Page 23
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
0 2 EEM Command bGUID
Size Value
2 16 8014 16 byte GUID bitmask integer
Description
EEM Command specified ECHO DATA with payload of 20 bytes. 0x23, 0x57, 0x1b, 0x05, 0xfd, 0x18, 0x45, 0x81, 0x93, 0x62, 0xa1, 0x6c, 0xee, 0xfc, 0xcc, 0xdf D2: use CRC, D1: multi-datagrams supported, D0: confirmed Maximum number of bytes per transfer, must be a multiple of of the endpoint packetsize.
18 20
bmFlags bMaxTransferSize
2 2
OEM Manual Page 24

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.
OEM Manual Page 25
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/enus/library/ff544838(v=VS.85).aspx Driver Package Installer (DPInst)- http://msdn.microsoft.com/enus/library/ff544842(v=VS.85).aspx Device and Driver Installation Software Tools - msdn.microsoft.com/enus/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/enus/library/ff544838(v=VS.85).aspx Driver Package Installer (DPInst)- http://msdn.microsoft.com/enus/library/ff544842(v=VS.85).aspx Device and Driver Installation Software Tools - http://msdn.microsoft.com/enus/library/ff541185(v=VS.85).aspx
OEM Manual Page 26
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-2 Approve the publisher for DPInst.exe
Figure G-4 Files copying Figure G-3 Click next in the Installation Wizard
Figure G-5 Approve the publisher of the drivers Figure G-6 - Success
OEM Manual Page 27
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-2 Select Properties
Figure H-4 Select Advanced Tab Figure H-3 Select Configure
Figure H-5 Enter an Address
OEM Manual Page 28
Appendix I - Bridging USB Device to another network
Figure I -1
Figure I-2
"Change adapter settings"
Figure I-4 Figure I-3
Hold CTRL and select the two networks to be bridged, then right click and enable bridge.
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
OEM Manual Page 29
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] %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB\VID_15ec&PID_d022 %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB2\VID_15ec&PID_d022 ; ; This INF file WILL MATCH for .NTamd64.5.0 [Belcarra.NTx86.6.0] %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB\VID_15ec&PID_d022 %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB2\VID_15ec&PID_d022 ; ; This INF file WILL MATCH for .NTamd64.5.0 [Belcarra.NTamd64.6.0] %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB\VID_15ec&PID_d022 %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB2\VID_15ec&PID_d022 ;
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] %BTCUsbLan.Manufacturer% = Belcarra, ;
NTx86.5.0, NTamd64.5.0, NTx86.6.0, NTamd64.6.0
OEM Manual Page 30

[SourceDisksFiles] btblan5.sys=1 ; [DestinationDirs] BTCUsbLan.CopyFiles = 12 ; WINDOWS\SYSTEM32\DRIVERS ; [BTCUsbLan.CopyFiles] btblan5.sys ; [BTCUsbLan.AddService] ServiceBinary = %12%\btblan5.sys ; ; This INF file WILL MATCH for .NTx86.5.0 [Belcarra.NTx86.5.0] %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB\VID_15ec&PID_d022 %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB2\VID_15ec&PID_d022 ; ; This INF file WILL MATCH for .NTamd64.5.0 [Belcarra.NTamd64.5.0] %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB\VID_15ec&PID_d022 %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB2\VID_15ec&PID_d022 ; ; This section MUST BE PRESENT to prevent matching for .NTx86.6.0 [Belcarra.NTx86.6.0] ; ; This section MUST BE PRESENT to prevent matching for .NTamd64.6.0 [Belcarra.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] %BTCUsbLan.Manufacturer% = Belcarra, NTx86.5.0, NTamd64.5.0, NTx86.6.0, NTamd64.6.0 ; [SourceDisksFiles] btblan6.sys=1 ; [DestinationDirs] BTCUsbLan.CopyFiles = 12 ; WINDOWS\SYSTEM32\DRIVERS ; [BTCUsbLan.CopyFiles] btblan6.sys ; [BTCUsbLan.AddService] ServiceBinary = %12%\btblan6.sys ; ; This section MUST BE PRESENT to prevent matching for .NTx86.5.0 [Belcarra.NTx86.5.0] ; ; This section MUST BE PRESENT to prevent matching for .NTamd64.5.0 [Belcarra.NTamd64.5.0] ; ; This INF file WILL MATCH for .NTx86.6.0 [Belcarra.NTx86.6.0] %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB\VID_15ec&PID_d022 %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB2\VID_15ec&PID_d022 ; ; This INF file WILL MATCH for .NTamd64.6.0 [Belcarra.NTamd64.6.0] %BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB\VID_15ec&PID_d022
OEM Manual Page 31

%BTCUsbLan.DeviceDesc% = BTCUsbLan.ndi, USB2\VID_15ec&PID_d022 ;
Appendix K - Sample Configuration Descriptors

1) CDC-ECM
Device descriptor bcdUSB bDevice[Class,Sub,Pro] bMaxPacketSize0 idVendor idProduct bcdDevice bNumConfigurations iManufacturer iProduct iSerialNumber Configuration descriptor wTotalLength bNumInterfaces bConfigurationValue iConfiguration bmAttributes bMaxPower [ ] [ 2] [ 4] [ 7] [ 8] [ 10] [ 12] [ 17] [ 3:18 ] [ 4:34 ] [ 5:46 ] [1 [ [ [ [11:16 [ [ ] 4] 4] 5] ] 7] 8] 12 01 00 02 02 06 00 40 ec 15 21 f0 00 01 03 04 05 01 0200 02 06 00 40 15ec f021 0100 01 Belcarra Belcarra CDC-ECM 0202020202020020202021 09 02 50 00 02 01 0b e0 01 50 02 01 cdc-ecm e0 Self-Powered Remote-Wakeup 01 09 04 00 00 00 01 02 06 00 Belcarra 05 24 00 0d 24 0f 05 24 06 07 05 82 00 01 02 06 00 0c
Interface descriptor [1:0:0 ] bInterfaceNumber [ 2] bAlternateSetting [ 5] bNumEndpoints [ 5] bInterface[Class,Sub,Pro][ 5] iInterface [12:52 ] Class descriptor [1:0:1 ] Class descriptor [1:0:2 ] Class descriptor [1:0:3 ] Endpoint descriptor [1:0:0:1] Interface descriptor [1:1:0 bInterfaceNumber [ bAlternateSetting [ bNumEndpoints [ bInterface[Class,Sub,Pro][ iInterface [13:68 ] 2] 5] 5] 5] ]
USBLAN - CDC/ECM 10 01 06 00 00 00 00 ea 05 00 00 00 00 01 03 10 00 01
09 04 01 00 00 0a 00 00 0d 01 00 00 0a 00 00 Belcarra USBLAN - CDC/ECM No Data 09 04 01 01 01 02 0a 00 00 Belcarra 07 05 01 07 05 81 01 02 0a 00 00 0e
Interface descriptor [1:2:0 ] bInterfaceNumber [ 2] bAlternateSetting [ 5] bNumEndpoints [ 5] bInterface[Class,Sub,Pro][ 5] iInterface [14:62 ] Endpoint descriptor [1:2:0:1] Endpoint descriptor [1:2:0:1] LangID String String String String String String String String [ 0 [ 3:18 [ 4:34 [ 5:46 [ 6:26 [ 7:16 [ 8:52 [ 9:68 [10:62 ] ] ] ] ] ] ] ] ]
USBLAN - CDC/ECM Data 02 00 02 00 02 00 02 00
4: 3 0904 Belcarra Belcarra CDC-ECM 0202020202020020202021 02c35d8325bf cdc-ecm Belcarra USBLAN - CDC/ECM Belcarra USBLAN - CDC/ECM No Data Belcarra USBLAN - CDC/ECM Data
OEM Manual Page 32

String String String String CDC-EEM Device descriptor bcdUSB bDevice[Class,Sub,Pro] bMaxPacketSize0 idVendor idProduct bcdDevice bNumConfigurations iManufacturer iProduct iSerialNumber Configuration descriptor wTotalLength bNumInterfaces bConfigurationValue iConfiguration bmAttributes bMaxPower [11:16 [12:52 [13:68 [14:62 ] ] ] ] cdc-ecm Belcarra USBLAN - CDC/ECM Belcarra USBLAN - CDC/ECM No Data Belcarra USBLAN - CDC/ECM Data 12 01 00 02 02 0c 07 40 ec 15 21 f0 00 01 03 04 05 01 0200 02 0c 07 40 15ec f021 0100 01 Belcarra Belcarra CDC-EEM 0202020202020020202022 09 02 20 00 01 01 08 e0 01 20 01 01 cdc-eem e0 Self-Powered Remote-Wakeup 01 09 04 00 00 00 02 02 0c 07 Belcarra 07 05 01 07 05 81 00 02 02 0c 07 09
[ ] [ 2] [ 4] [ 7] [ 8] [ 10] [ 12] [ 17] [ 3:18 ] [ 4:34 ] [ 5:46 ] [1 [ [ [ [ 8:16 [ [ ] 4] 4] 5] ] 7] 8]
Interface descriptor [1:0:0 ] bInterfaceNumber [ 2] bAlternateSetting [ 5] bNumEndpoints [ 5] bInterface[Class,Sub,Pro][ 5] iInterface [ 9:38 ] Endpoint descriptor [1:0:0:1] Endpoint descriptor [1:0:0:1] LangID String String String String String String String CDC-NCM Device descriptor bcdUSB bDevice[Class,Sub,Pro] bMaxPacketSize0 idVendor idProduct bcdDevice bNumConfigurations iManufacturer iProduct iSerialNumber Configuration descriptor wTotalLength bNumInterfaces bConfigurationValue iConfiguration bmAttributes bMaxPower Interface descriptor [ [ [ [ [ [ [ [ 0 3:18 4:34 5:46 6:16 7:38 8:16 9:38 ] ] ] ] ] ] ] ]
- CDC/EEM 02 00 02 00 02 00 02 00
4: 3 0904 Belcarra Belcarra CDC-EEM 0202020202020020202022 cdc-eem Belcarra - CDC/EEM cdc-eem Belcarra - CDC/EEM 12 01 00 02 02 0d 00 40 ec 15 21 f0 00 01 03 04 05 01 0200 02 0d 00 40 15ec f021 0100 01 Belcarra Belcarra CDC-NCM 0202020202020020202023 09 02 56 00 02 01 0b e0 01 56 02 01 cdc-ncm e0 Self-Powered Remote-Wakeup 01
[ ] [ 2] [ 4] [ 7] [ 8] [ 10] [ 12] [ 17] [ 3:18 ] [ 4:34 ] [ 5:46 ] [1 [ [ [ [11:16 [ [ [1:0:0 ] 4] 4] 5] ] 7] 8]
] 09 04 00 00 01 02 0d 00 0c
OEM Manual Page 33

bInterfaceNumber [ 2] bAlternateSetting [ 5] bNumEndpoints [ 5] bInterface[Class,Sub,Pro][ 5] iInterface [12:52 ] Class descriptor [1:0:1 ] Class descriptor [1:0:2 ] Class descriptor [1:0:3 ] Class descriptor [1:0:4 ] Endpoint descriptor [1:0:0:1] Interface descriptor [1:1:0 bInterfaceNumber [ bAlternateSetting [ bNumEndpoints [ bInterface[Class,Sub,Pro][ iInterface [13:68 Interface descriptor [1:2:0 bInterfaceNumber [ bAlternateSetting [ bNumEndpoints [ bInterface[Class,Sub,Pro][ iInterface [14:62 Endpoint descriptor Endpoint descriptor LangID String String String String String String String String String String String String ] 2] 5] 5] 5] ] ] 2] 5] 5] 5] ] 00 00 01 02 0d 00 Belcarra 05 24 00 0d 24 0f 05 24 06 06 24 1a 07 05 82
USBLAN - CDC/NCM 10 01 06 00 00 00 00 ea 05 00 00 00 00 01 00 01 29 03 10 00 01
09 04 01 00 00 0a 00 01 0d 01 00 00 0a 00 01 Belcarra USBLAN - CDC/NCM No Data 09 04 01 01 02 0a 00 01 0e 01 01 02 0a 00 01 Belcarra USBLAN - CDC/NCM Data
[1:2:0:1] 07 05 01 02 00 02 00 [1:2:0:1] 07 05 81 02 00 02 00 [ 0 [ 3:18 [ 4:34 [ 5:46 [ 6:26 [ 7:16 [ 8:52 [ 9:68 [10:62 [11:16 [12:52 [13:68 [14:62 ] ] ] ] ] ] ] ] ] ] ] ] ] 4: 3 0904 Belcarra Belcarra CDC-NCM 0202020202020020202023 4238adc4899b cdc-ncm Belcarra USBLAN - CDC/NCM Belcarra USBLAN - CDC/NCM Belcarra USBLAN - CDC/NCM cdc-ncm Belcarra USBLAN - CDC/NCM Belcarra USBLAN - CDC/NCM Belcarra USBLAN - CDC/NCM
No Data Data
No Data Data
2) Basic
Device descriptor bcdUSB bDevice[Class,Sub,Pro] bMaxPacketSize0 idVendor idProduct bcdDevice bNumConfigurations iManufacturer iProduct iSerialNumber Configuration descriptor wTotalLength bNumInterfaces bConfigurationValue iConfiguration bmAttributes bMaxPower Interface descriptor OEM Manual Page 34 [ ] [ 2] [ 4] [ 7] [ 8] [ 10] [ 12] [ 17] [ 3:18 ] [ 4:38 ] [ 5:46 ] [1 [ [ [ [ 8:20 [ [ [1:0:0 ] 4] 4] 5] ] 7] 8] 12 01 00 02 02 0a 00 40 ec 15 21 f0 00 01 03 04 05 01 0200 02 0a 00 40 15ec f021 0100 01 Belcarra Belcarra NET-BASIC 0202020202020020202033 09 02 27 00 01 01 08 e0 01 27 01 01 net-basic e0 Self-Powered Remote-Wakeup 01
] 09 04 00 00 03 ff 01 01 09 October 12, 2012 www.belcarra.com

bInterfaceNumber [ 2] bAlternateSetting [ 5] bNumEndpoints [ 5] bInterface[Class,Sub,Pro][ 5] iInterface [ 9:34 ] Endpoint descriptor [1:0:0:1] Endpoint descriptor [1:0:0:1] Endpoint descriptor [1:0:0:1] LangID String String String String String String String [ [ [ [ [ [ [ [ 0 3:18 4:38 5:46 6:20 7:34 8:20 9:34 ] ] ] ] ] ] ] ] 00 00 03 ff 01 01 Belcarra 07 05 01 07 05 81 07 05 82
- BASIC 02 00 02 00 02 00 02 00 03 10 00 01
4: 3 0904 Belcarra Belcarra NET-BASIC 0202020202020020202033 net-basic Belcarra - BASIC net-basic Belcarra - BASIC
3) CDC-NCM-MSC This demonstrates composite configuration with IAD descriptors.

Device descriptor bcdUSB bDevice[Class,Sub,Pro] bMaxPacketSize0 idVendor idProduct bcdDevice bNumConfigurations iManufacturer iProduct iSerialNumber Configuration descriptor wTotalLength bNumInterfaces bConfigurationValue iConfiguration bmAttributes bMaxPower IAD descriptor bFirstInterface bInterfaceCount bFunction[Class,Sub,Pro] iFunction [ ] [ 2] [ 4] [ 7] [ 8] [ 10] [ 12] [ 17] [ 3:18 ] [ 4:28 ] [ 5:66 ] [1 [ [ [ [14:28 [ [ ] 4] 4] 5] ] 7] 8] 12 01 00 02 ef 02 01 40 ec 15 5d c0 00 01 03 04 05 01 0200 ef 02 01 40 15ec c05d 0100 01 Belcarra CDEMO NCM+MSC 0123456789ABCDEF0123456789ABCD18 09 02 7d 00 03 01 0e e0 01 7d 03 01 cdemo-ncm-msc e0 Self-Powered Remote-Wakeup 01
[1:0 ] 08 0b 00 02 02 0d 00 0f [ 2] 00 [ 3] 02 [ 4] 02 0d 00 [15:52 ] Belcarra USBLAN - CDC/NCM 09 04 00 00 00 01 02 0d 00 Belcarra 05 24 00 0d 24 0f 05 24 06 06 24 1a 07 05 82 00 01 02 0d 00 10
Interface descriptor [1:0:0 ] bInterfaceNumber [ 2] bAlternateSetting [ 5] bNumEndpoints [ 5] bInterface[Class,Sub,Pro][ 5] iInterface [16:52 ] Class descriptor [1:0:1 ] Class descriptor [1:0:2 ] Class descriptor [1:0:3 ] Class descriptor [1:0:4 ] Endpoint descriptor [1:0:0:1] Interface descriptor bInterfaceNumber bAlternateSetting bNumEndpoints OEM Manual Page 35
USBLAN - CDC/NCM 10 01 06 00 00 00 00 ea 05 00 00 00 00 01 00 01 29 03 10 00 01
[1:1:0 ] 09 04 01 00 00 0a 00 01 11 [ 2] 01 [ 5] 00 [ 5] 00 Copyright 2012 Belcarra Technologies (2005) Corp. October 12, 2012 www.belcarra.com

bInterface[Class,Sub,Pro][ 5] 0a 00 01 iInterface [17:68 ] Belcarra USBLAN - CDC/NCM No Data Interface descriptor [1:2:0 ] bInterfaceNumber [ 2] bAlternateSetting [ 5] bNumEndpoints [ 5] bInterface[Class,Sub,Pro][ 5] iInterface [18:62 ] Endpoint descriptor [1:2:0:1] Endpoint descriptor [1:2:0:1] IAD descriptor bFirstInterface bInterfaceCount bFunction[Class,Sub,Pro] iFunction 09 04 01 01 01 02 0a 00 01 Belcarra 07 05 01 07 05 81 01 02 0a 00 01 12
USBLAN - CDC/NCM Data 02 00 02 00 02 00 02 00
[1:3 ] 08 0b 02 01 08 06 50 13 [ 2] 02 [ 3] 01 [ 4] 08 06 50 [19:68 ] Belcarra Mass Storage - Bulk Only 09 04 02 02 00 02 08 06 50 Belcarra 07 05 02 07 05 83 00 02 08 06 50 14
Interface descriptor [1:3:0 ] bInterfaceNumber [ 2] bAlternateSetting [ 5] bNumEndpoints [ 5] bInterface[Class,Sub,Pro][ 5] iInterface [20:92 ] Endpoint descriptor [1:3:0:1] Endpoint descriptor [1:3:0:1] LangID String String String String String String String String String String String String String String String String String
String
Mass Storage - Bulk Only - Alternate 02 00 02 00 02 00 02 00
[ 0 [ 3:18 [ 4:28 [ 5:66 [ 6:26 [ 7:28 [ 8:52 [ 9:52 [10:68 [11:62 [12:68 [13:92 [14:28 [15:52 [16:52 [17:68 [18:62 [19:68
] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
4: 3 0904 Belcarra CDEMO NCM+MSC 0123456789ABCDEF0123456789ABCD18 da8db632c0b5 cdemo-ncm-msc Belcarra USBLAN - CDC/NCM Belcarra USBLAN - CDC/NCM Belcarra USBLAN - CDC/NCM No Data Belcarra USBLAN - CDC/NCM Data Belcarra Mass Storage - Bulk Only Belcarra Mass Storage - Bulk Only - Alternate cdemo-ncm-msc Belcarra USBLAN - CDC/NCM Belcarra USBLAN - CDC/NCM Belcarra USBLAN - CDC/NCM No Data Belcarra USBLAN - CDC/NCM Data Belcarra Mass Storage - Bulk Only
[20:92 ] Belcarra Mass Storage - Bulk Only - Alternate
OEM Manual Page 36
Revision Summary
Revision History
2.4 2.4.1 2.4.1 2.4.2
Date
July 2011 Oct 2011 Nov 2011 Oct 2012
Revision Class Comments

Initial 2.4 version. 2.4.1 - RNDIS 2.4.1 EEM Configuration Request, kit contents 2.4.2 RNDIS update, USB3, changes to registry settings
OEM Manual Page 37

Belcarra USBLAN - 2 4 - 2 Manual

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Belcarra USBLAN - 2 4 - 2 Manual

Загружено:

Авторское право:

Доступные форматы

Belcarra USBLAN for Windows

OEM Manual September 2012

Belcarra USBLAN for Windows

Operation 7.1 Station Address

Architecture 3.1 NDIS

7.2 IP Address Configuration 7.3 Media Status

3.2 Station (MAC) Address 3.3 4 5 Composite Function

Evaluation Customization 5.1 5.2 Versioning Registry Location 8

EEM Configuration NCM Configuration RNDIS

Copyright 2012 Belcarra Technologies (2005) Corp.

October 12, 2012 www.belcarra.com

Belcarra USBLAN for Windows

OEM Manual Page 3

Copyright 2012 Belcarra Technologies (2005) Corp.

October 12, 2012 www.belcarra.com

Belcarra USBLAN for Windows

Belcarra USBLAN for Windows 2.2 Features

2.3 Installation Kit

2.6 CDC NCM

OEM Manual Page 5

Copyright 2012 Belcarra Technologies (2005) Corp.

October 12, 2012 www.belcarra.com

Belcarra USBLAN for Windows

2.7 CDC EEM

2.8 CDC ECM

2.9 Microsoft RNDIS

OEM Manual Page 6

Copyright 2012 Belcarra Technologies (2005) Corp.

October 12, 2012 www.belcarra.com

Belcarra USBLAN for Windows

3.2 Station (MAC) Address

3.3 Composite Function

OEM Manual Page 7

Copyright 2012 Belcarra Technologies (2005) Corp.

October 12, 2012 www.belcarra.com

Belcarra USBLAN for Windows

Belcarra USBLAN for Windows

5.2 Registry Location

5.3 General Configuration

See Section 5.3.2 below See Section 5.3.3 below

OEM Manual Page 9

Belcarra USBLAN for Windows

5.4 DHCP Service Configuration

5.5 Multi-Frame Protocol Configuration

Belcarra USBLAN for Windows

5.6 EEM Configuration

5.7 NCM Configuration

5.9 Per Adapter Configuration

OEM Manual Page 11

Copyright 2012 Belcarra Technologies (2005) Corp.

October 12, 2012 www.belcarra.com

Belcarra USBLAN for Windows

Common Configuration Issues

6.4 Zero Length versus Null Byte Packets

Belcarra USBLAN for Windows 6.5 DHCP IP Address Allocation

Host Dotted decimal

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

Belcarra USBLAN for Windows

7.1 Station Address

7.2 IP Address Configuration

7.3 Media Status

OEM Manual Page 14