Firmware Release Note: Updating Default USB Network Protocol to CDC-NCM

USB Network Protocol Transition Guide: Changing Default to CDC-NCM Guideline

 

1. Purpose & Background

The purpose of this guide is to outline the technical details and verification procedures for transitioning the system firmware's virtual USB network port (USB Gadget / USB NIC) from the legacy RNDIS/CDC-ECM protocols to the new default CDC-NCM (Network Control Model).

• Why Switch to CDC-NCM?

  • Superior Cross-Platform Native Support: MacOS, iOS, and most modern Linux kernels (such as those used on dedicated hardware transcoding platforms) have built-in native support for CDC-NCM, eliminating the need for third-party driver installations.

  • Higher Throughput: Compared to legacy ECM, NCM supports packet aggregation, which significantly reduces CPU overhead during large file transfers.

  • Mitigating RNDIS Deprecation: Microsoft has actively restricted and phased out legacy RNDIS security drivers in Windows 11. Shifting to NCM ensures long-term, out-of-the-box connectivity across modern operating systems.

Starting from the July 2026 1BMC release, the default USB Network Protocol will change from CDC-ECM to CDC-NCM.

Projects that explicitly specify CDC-ECM or CDC-NCM in their configuration files will not be affected.

Only projects without a protocol setting in their configuration file will follow the 1BMC default behavior and may automatically switch to CDC-NCM after upgrading to a newer 1BMC version. Compatibility verification is recommended before deployment.

2. 1BMC/BMC Config 

Decision Matrix

Case 1: JSON Does Not Specify a Protocol

Json does not specify
Use 1BMC default

Behavior

1BMC Version	Protocol Used
Previous Versions	CDC-ECM
July 2026 and Later	CDC-NCM

Impact

• The protocol may change from ECM to NCM after a BMC upgrade.
• Compatibility issues may occur if the customer environment relies on CDC-ECM.
• Upgrade impact assessment is recommended.

Recommended AE Response

If the project configuration does not explicitly specify a USB Network Protocol, the system will follow the 1BMC default setting.

Since the default protocol will change from CDC-ECM to CDC-NCM in future 1BMC releases, upgrading the BMC may result in a protocol change.

---

Case 2: JSON Specifies CDC-ECM

Json specify ECM

Behavior

1BMC Version	Protocol Used
Previous Versions	CDC-ECM
Future Versions	CDC-ECM

Impact

• Not affected by the 1BMC default change.
• CDC-ECM remains in use after BMC upgrades.

Recommended AE Response

This project explicitly specifies CDC-ECM in its configuration file. Therefore, upgrading to a newer 1BMC version will not affect the USB Network Protocol.

---

Case 3: JSON Specifies CDC-NCM

Json specify NCM

Behavior

1BMC Version	Protocol Used
Previous Versions	CDC-NCM
Future Versions	CDC-NCM

Impact

• Not affected by the 1BMC default change.
• CDC-NCM remains in use after BMC upgrades.

Recommended AE Response

This project explicitly specifies CDC-NCM in its configuration file. Therefore, upgrading to a newer 1BMC version will not affect the USB Network Protocol.

---

Quick Reference Flow for AEs

    Inquiry
       │
       ▼
Check Project JSON Configuration
       │
 ┌─────┼─────┐
 │     │     │
 ▼     ▼     ▼
None  ECM   NCM
 │     │     │
 ▼     ▼     ▼
Follow Fixed Fixed
1BMC   ECM   NCM
Default
 │
 ▼
May change from
ECM to NCM after
1BMC upgrade

---

Platform Categories

Type 1 Platform

Supports CDC-ECM only.

Even if the BMC configuration is changed to CDC-NCM:

Not Supported

Recommended AE Response

This platform supports CDC-ECM only. CDC-NCM is not supported due to platform limitations.

---

Type 2 Platform

Supports both:

CDC-ECM
CDC-NCM

The active protocol is determined by the BMC configuration.

Recommended AE Response

Both CDC-ECM and CDC-NCM are supported. The protocol used by the system depends on the project configuration.

---

Type 3 Platform

Both the platform and 1BMC fully support CDC-NCM.

CDC-NCM

Recommended AE Response

This platform fully supports CDC-NCM and can operate with CDC-NCM as configured.

---

Structural and Specification Differences Between Network Protocols 

1. Json does not specify, use 1BMC default	2. Json specify ECM	3. Json specify NCM
./asmb817.json ./asmb956_sky7232d3e.json ./asmbh90.json ./asmbh90_rongx.json ./fwa3034.json ./fwa60h2.json ./sky712v4.json ./sky712v4_sku1.json ./sky7132d.json ./sky722v4.json ./sky722v4_sku1.json ./sky7232d-2p.json ./sky7232d-3p.json ./sky7260d.json ./sky7260s.json ./sky8134du.json ./sky8134s_11.json ./sky8134s_11_remote_heatsink.json ./sky8134s_11_sku2.json ./sky8136s.json ./sky8136s_brcm.json ./sky821e3.json ./sky8232d-sku1.json ./sky8232d-sku2.json ./sky8232d-sku3.json ./sky8260s_sku0.json ./sky8260s_sku1.json ./sky8260s_sku2.json ./sky8260s_sku3.json	./asmb840_smartlogic.json ./asmb956_sky7632.json ./asmbh90_sugon.json ./fwa1013.json ./fwa1013_20c_dragos.json ./fwa1013_dragos.json ./fwa1013_parker.json ./fwa2013.json ./fwa2013_forcepoint.json ./fwa3051.json ./fwa3051_forcepoint.json ./fwa3051_vmware.json ./fwa5072.json ./fwa5072_vmware.json ./fwa6072.json ./fwa60h2_sangfor.json ./fwa6171.json ./fwa6172.json ./fwa6172_cdb.json ./fwa6172_forcepoint.json ./fwa6172_ibm.json ./fwa6172_sangfor.json ./mic8330_cohesity.json ./mic8340_cohesity.json ./mic8340_standard.json ./mic8340_standard_su.json ./sky712e3_cohesity.json ./sky712e3_standard_e3s.json ./sky712e3_standard_u2.json ./sky7232d-evertz.json ./sky8134du_kla.json ./sky8134du_std.json ./sky8234d3_cohesity.json ./sky8234d3_standard.json ./sky8234d3_veritas.json ./sky8236mu_micron.json ./sky8260s_sku9_a101-1.json	./aimbh72.json ./asmb262.json ./asmb561.json ./asmb561i.json ./asmb610.json ./asmb610v3.json ./asmb610v3_amat.json ./asmb787.json ./asmb788.json ./asmb789.json ./asmb807.json ./asmb808.json ./asmb817_board-id0.json ./asmb817_board-id10.json ./asmb817_board-id13.json ./asmb817_board-id2.json ./asmb817_board-id5.json ./asmb817_board-id8.json ./asmb817_board-id9.json ./asmb817_univista.json ./asmb818.json ./asmb818i.json ./asmb831.json ./asmb928.json ./asmb928i.json ./asmb977s.json ./asmb977si.json ./asmb978.json ./asmb978i.json ./asmb981.json ./asmb981i.json ./fwa1081.json ./fwa3052.json ./fwa3052_hpe.json ./fwa3052e.json ./fwa3080.json ./fwa5082.json ./fwa6083.json ./fwa60h2_hillstone.json ./fwa6173.json ./fwa6173_ibm.json ./fwa6183.json ./ipmi2000.json ./nvs811_avigilon.json ./sky602e3.json ./sky621v4.json ./sky622g4.json ./sky641e3.json ./sky642e3.json ./sky721e3.json ./sky721e3_10xgenomics.json ./sky721e3_evertz.json ./sky721e3_t24r.json ./sky820v3_pacbio.json ./sky820v3_x16.json ./sky820v3_x8.json ./sky821e3_hiper.json ./sky821e3_keysight.json ./sky821e3_keysight_gemini_1p.json ./sky821e3_turin.json ./sky8234d.json ./vega7030.json ./vegadca100.json

3. Protocol Transition Overview

Item	Legacy Setup	New Default
Default USB Network Protocol	RNDIS / CDC-ECM	CDC-NCM
Linux Driver Module	g_ether (default params) / cdc_ether	cdc_ncm
Windows Support	Requires manual assignment of RNDIS drivers (prone to failure on Win11)	Native driver support in Windows 10 (1709+) / 11
Primary Transfer Advantage	Packet-by-packet transfer, high CPU utilization	Packet aggregation; ideal for high-speed streaming and multimedia transfers

4. Verification Steps per OS

When the hardware is flashed with the new firmware and connected to a host via USB, follow these verification steps depending on the host operating system:

4.1 Verification on a Linux Host

1. Check the Loaded Kernel Driver Module:

   When the device is plugged in, the kernel log (dmesg) should explicitly load the cdc_ncm driver:

   Bash

    

   dmesg | grep -i "ncm"
   

   Expected Output:

   Plaintext

    

   usb 1-2.5: Product: Management Serial Gadget / CDC-NCM
   cdc_ncm 1-2.5:1.0: usb0: register 'cdc_ncm' at usb-0000:73:00.4, CDC NCM Device
   

2. Check the Network Interface:

   Run ip link or ifconfig to verify that a new network interface named usb0 (or a predictable interface name like enp0s...) has been created and its state is UP.

4.2 Verification on a Windows Host

1. Open the Device Manager.

2. Expand the Network adapters category.

3. Confirm Device Name: The device, which might have previously shown up as RNDIS Gadget, should now be automatically recognized by Windows as Usbncm Device or USB Network Control Model (NCM) Device.

4. Right-click the device, select Properties, and confirm that the driver provider is Microsoft, requiring no external .inf file installation.

5. Troubleshooting

Q1: The network interface is missing on an older Linux host.

• Cause: Some legacy Linux kernel distributions (such as older embedded filesystems) might not have included CONFIG_USB_NET_CDC_NCM during kernel compilation.

• Solution: Try manually loading the module using sudo modprobe cdc_ncm. If the system states the module cannot be found, the host OS kernel will need to be recompiled or updated.

Q2: Windows 11 still recognizes the hardware as an old RNDIS or an "Unknown Device."

• Cause: Windows caches USB descriptors internally. It might still be trying to bind the old driver profile based on cached Vendor ID/Product ID (VID/PID) mappings.

• Solution: In Device Manager, right-click the faulty/unknown device, choose Uninstall device, and check the box for "Attempt to remove the driver for this device." Afterward, unplug the USB cable and plug it back in to force Windows to re-enumerate the device and apply the native NCM driver.