Windows 10 - NdisDeviceType Flag

August 2015

Windows Vista and newer systems (NDIS 6.0) support a flag called *NdisDeviceType. This flag indicates that the network implemented by a driver connects to a device that is an endpoint and does not connect to a network.

For more information see here.
*NdisDeviceType
The type of the device. The default value is zero, which indicates a standard networking device that connects to a network. Set *NdisDeviceType to NDIS_DEVICE_TYPE_ENDPOINT (1) if this device is an endpoint device and is not a true network interface that connects to a network. For example, you must specify NDIS_DEVICE_TYPE_ENDPOINT for devices such as smart phones that use a networking infrastructure to communicate to the local computer system but do not provide connectivity to an external network.
Note  Windows Vista automatically identifies and monitors the networks a computer connects to. If the NDIS_DEVICE_TYPE_ENDPOINT flag is set, the device is an endpoint device and is not a connection to a true external network. Consequently, Windows ignores the endpoint device when it identifies networks. The Network Awareness APIs indicate that the device does not connect the computer to a network. For end users in this situation, the Network and Sharing Center and the network icon in the notification area do not show the NDIS endpoint device as connected. However, the connection is shown in the Network Connections Folder.

Windows 10 - Edge Browser


One of the side effects of setting the *NdisDeviceType flag is that the new Edge Browser in Windows 10 cannot (will not?) connect to a web server on those devices.

It is unknown at this time if this is the intended behavior or something that was added inadvertently in the implementation of the new browser. Other browsers such as Internet Explorer or Chrome do not have this limitation.

Workarounds:
  1. Install and use Chrome or Firefox 
  2. Use Internet Explorer (IE 11 works fine) 
  3. Do not set the *NdisDeviceType flag

WLK/HCK/HLK


One of the limitations of an endpoint device is that there is no way to connect through it to another network. Some of the required WLK/HCK/HLK tests for network devices require a test setup that requires and tests network connectivity via the tested device to another test Windows system that is then routed back through a local network connection to complete the test. This cannot be done for endpoint devices and requires setting the *NdisDeviceType flag.

If your device needs to have the *NdisDeviceType flag set and you also need to have your customers access web pages using the Edge Browser there is a problem. Contact Belcarra and we will help with a work around for testing.

Address Management and Device Discovery

Overview

This paper describes how to build and manage a TCP/IP network for USB devices.
Ethernet-style networking  can very simply be  extended to attached USB devices. Belcarra’s USBLAN for Window’s built-in DHCP server for address assignment, management and device discovery solutions has been implemented to fit within the network paradigm requirements. USBLAN for Window’s implements USB-IF (www.usb.org) Communications Device Class protocols (CDC-NCM, EEM, ECM and others) and will create an Ethernet-style networking segment for each attached USB device.
Networking over USB protocols such as CDC-ECM, Microsoft RNDIS, CDC-NCM, were originally designed to provide USB-mediated access to an external network, and address management was seen as a matter for the external network segment.  On such external segments, a DHCP server was usually available.
Now, however, the great majority of USB devices using these protocols are smart devices which use a network style command channel, but do not provide access to an external network medium.  Therefore, the network segment terminates at the device, and there are only two nodes on the network: the USB host (Windows) and the device.  The DHCP service within Belcarra USBLAN for Window’s is a special service for such network segments.
The following describes how the network layer (IP) addresses can be seamlessly set up on top of the link layer and some pointers and strategies on OEM software running on Windows co-operating with the device to enable network-based device discovery.

USBLAN v2.4.6 released

An evaluation version of Belcarra's USBLAN is now available from Windows Update for Windows 8/8.1 users.

To use this demo version of USBLAN for Windows the device will need to offer Vendor and Product ID’s as follows:
  • Vendor ID 0x15ec (Belcarra)
  • Product ID 0xd041 (DHCP on for all protocols, overriding the DHCPDType flag), or 0xd042 (DHCP always off, see section 5.4.1 of the OEM manual)
To get the driver, simply ensure that the Windows system is connected to the Internet, plug the device in (configured with the correct VID/PID) 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. These parameters can be modified later using RegEdit (see Section 5.2ff in the OEM Manual).  As noted above, the parameter DHCPDType in the demo is inferred from the Product ID and in particular setting it in the registry has no effect.

Please note this is an evaluation version only and will run for one hour at a time. It must be re-plugged to continue use after the one hour expires.

Windows Embedded Standard 7

Windows Embedded Standard 7 (WES7), is a componentized version of Microsoft’s Windows 7 operating system that can be easily configured to use Belcarra's USBLAN Networking over USB solutions.

The Belcarra USBLAN driver  is available from Windows  Update for evaluation (see manual).  Whereas for a standard Windows 7 system connected to the Internet, simply attach a device that offers the appropriate Hardware ID's (VID: 0x15ec / PID: 0xd031), allow the system to search Windows Update and install.  For WES7, the driver must be downloaded separately from Windows Update (download also available) and added to the WES7 image.  

Note: the evaluation version will run for only one hour and then must be replugged to continue use.

Should you need assistance acquiring the .cab file or wish to receive an evaluation version that does not have the time limitation please contact us.

Microchip PIC32 USBLAN Demo

The Microchip PIC32 Microcontroller allows for implementation of a Full Speed USB Device.

Implementing a Networking over USB solution allows a PIC32 based design to connect to a Microsoft Windows system and use TCP/IP network connections using the Belcarra Windows USBLAN Class driver



Belcarra’s implementation of Networking over USB for the Microchip PIC32 is a very low cost networking solution for PIC32 projects, eliminating the need to add an Ethernet chip while using less Flash and RAM resources.

Full details (.pdf) and demonstration kit download link available here.

Using a data proxy for web access

Belcarra USBLAN for Windows allows a small 2-node private network to be established over a USB link from a device to a Windows host.

If the device has a need to access the Internet for WEB requests, then the simplest solution to satisfy the competing concerns of security and ease-of-use is a proxy server on the Windows machine. After a link is established, the device sends web requests to the Proxy Service on the Windows machine. The Proxy Service on the Windows side listens for such requests, and acts and an agent for the USB Device fetching the web pages and content and returning them to the USB Device.

Where is the proxy?

From the viewpoint of the device, the Windows server is the Proxy Server (implemented as a Windows Service). We assume that the application on the device can discover the IP address of the Windows side of the USB link.
For example the Windows System might be at 192.168.100.1 whereas the device itself is at 192.168.100.2. To avoid conflicts an alternate port is used for the Proxy Service, e.g. 8080.

Favourites