A switch or AP that won't register onto iMaster NCE-Campus fails in one of two places — the link to the controller never forms at all, or it forms and the controller actively rejects the device with a specific, documented reason. This is the reference for both: the checks that come before any error code exists, and the exact English error strings the controller returns — 13 for switches, 14 for cloud-managed APs — with what each one means and the fix.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
register-fail-record hands you the reason in plain English — read that first, because re-checking configuration that was already correct is the single biggest time sink in this fault.
A switch or AP that won't register onto iMaster NCE-Campus is one of the most common onboarding tickets, and almost all of it collapses into two questions: did the device ever manage to establish a link to the controller at all, and if it did, what reason did the controller give for rejecting it. The first question is a plain reachability problem — DHCP, DNS, a blocked port, a bad address. The second has an exact answer sitting in a register-fail-record, in English, waiting to be read.
What follows is the fault tree this splits into, the display commands for each stage, the 13 controller-side rejection codes documented for switches and the 14 documented for cloud-managed APs, and a handful of gotchas and FAQ answers pulled from real onboarding cases.
Every registration failure is either a device that never reached the controller, or a device the controller saw and turned away for a specific, documented reason.
Placing the symptom on this tree first tells you whether you're chasing a network problem or reading an error-code table — they need completely different fixes.
Diagram labels are kept in English for engineering clarity.
Everything in the left branch is a plain reachability or trust problem in another feature — DHCP, DNS, routing, a certificate, a blocked port — chased down in its own context. Everything in the right branch has an exact, documented English reason already sitting in the device's or the controller's own log.
A handful of checks before you ever get to an error-code table, then the two tables themselves.
If display netconf connect-status shows an empty Controller address source, don't go looking for a registration error yet — there isn't one to find.
<HUAWEI> display netconf connect-status
------------------------------------------------------------------------------
Netconf status : enable
------------------------------------------------------------------------------
Controller address source : --
Controller IP address : --
Controller port : --
Management VLAN : --
Register phase : --
Register status : --
------------------------------------------------------------------------------
// all blank -> no controller address yet, this is before stage 2, not a rejection
<HUAWEI> display netconf register-fail-record
-------------------------------------------------------------------------------
Time Error Info
-------------------------------------------------------------------------------
2026-07-10 09:02:15 Failed to apply IP address
2026-07-10 09:03:40 Controller certificate authentication failed
-------------------------------------------------------------------------------display cloud-mng info and display cloud-mng online-fail-record diagnostic-information are the AP-side equivalents of the switch commands above.
<HUAWEI> display cloud-mng online-fail-record diagnostic-information
Time Fail Reason
-------------------------------------------------------------------
2026-07-10 09:14:22 AP can't obtain address
2026-07-10 09:15:47 Register Fail: The device is not added to the controller
-------------------------------------------------------------------
<HUAWEI> display tcp status
-----------------------------------------------------------------------------------
Cid SocketID Local-Addr:Port Foreign-Addr:Port State
-----------------------------------------------------------------------------------
0x80C804B7 1 0.0.0.0:23 0.0.0.0:0 LISTEN
-----------------------------------------------------------------------------------
// no ESTABLISHED session toward the controller's port 10020 -> the SSH/TLS link itself never formed
[HUAWEI] diagnose
[HUAWEI-diagnose] display ssh server error
2012-05-02 13:46:41 Failed to login through SSH. (ServiceType=sftp, UserName=root, IPAddress=127.0.0.1, FailedReason=Sftp server functionality is disabled.)
2012-05-02 13:46:11 Failed to login through SSH. (ServiceType=unknown, UserName=test, IPAddress=127.0.0.1, FailedReason=User does not exist.)display controller register-fail-record on a V600 switch returns one of these English strings once the link is up and the controller has actively turned the device away.
<HUAWEI> display controller connect-status
Management VLAN : 100
Controller IP address : 172.16.1.1
Controller port : 10020
Register phase : RegisterFail
Last registration failure reason : The device is not added to the controller| Error Code (verbatim) | Meaning | Fix |
|---|---|---|
| Failed to obtain basic device information | The controller timed out waiting for the device's basic information, or the device's reply failed. | Retry registration; if it fails again, collect logs and open a support case. |
| The structure of the basic device information packet is invalid | The basic device information packet the controller received is malformed. | Collect logs and open a support case — this isn't something to fix from the CLI. |
| The device is not added to the controller | The device's ESN has not been added to any site on the controller. | Add the device's ESN to the site in iMaster NCE-Campus, then retry registration. |
| The device license is not authorized or has expired | The device's license on the controller is unauthorized or has expired. | Check the license assigned to the device on the controller; apply and load a new license if it has expired. |
| The device does not report the device model | The device did not report its model information during registration. | Collect logs and open a support case. |
| The device model reported by the device does not match the ESN | The model the device reported doesn't match what its ESN implies. | Collect logs and open a support case. |
| The device does not report the MAC address or the MAC address format is incorrect | The device didn't report a MAC address, or the format it sent is invalid. | Collect logs and open a support case. |
| The device is online | The controller already considers this device online. | Collect logs and open a support case — check for a duplicate or stuck session first. |
| The device is not in the whitelist | The device's ESN is not in the controller's registration whitelist. | Ask the controller administrator to add the device's ESN to the whitelist. |
| The reported device model is inconsistent with that on the controller | The device's actual form factor (standalone, stack, or cluster) doesn't match what's configured on the controller — a common case is the device running as a stack while the controller expects a standalone unit. | Check display stack configuration all (box switches) or display css configuration all (chassis switches) and align it with the design on the controller. |
| The token does not exist or the verification fails | The onboarding token is missing or fails verification — mainly seen in DHCP-based onboarding. | In a DHCP onboarding scenario, check that the token in the upstream device's DHCP client configuration is correct. |
| The device ESN does not match the controller ESN | The device's own ESN doesn't match the ESN record the controller has for it. | Confirm with the controller administrator that the ESN on the device matches the ESN configured on the controller. |
| An online device with the same ESN exists | Another device already registered online is using the same ESN. | Collect logs and open a support case — this usually means a duplicated ESN or a stuck stale session. |
display cloud-mng online-fail-record diagnostic-information returns these once the AP's link to the controller is up and the registration itself is rejected.
| Error Code (verbatim) | Meaning | Fix |
|---|---|---|
| AP can't obtain address | The AP could not get an IP address. | Check the DHCP server and confirm the AP can actually obtain an address. |
| DNS failed | The AP could not resolve the controller's address through DNS. | Check the DNS server and confirm it resolves the cloud management platform's address correctly. |
| Connect to controller failed | The AP failed to establish a connection to the controller. | Check network reachability and confirm the AP can reach the controller's port 10020. |
| Register Fail: Internal error, the controller is not already | The controller hasn't finished starting up, or is still determining its deployment scenario. | Contact the cloud management platform administrator and confirm the platform is running normally. |
| Register Fail: Get the device's information timeout or the device returns fail | The controller failed to get the device's information in time. | Collect logs and open a support case. |
| Register Fail: Illegal device's information format | The information the device reported has an invalid format. | Collect logs and open a support case. |
| Register Fail: The device is not added to the controller | The AP's ESN has not been added to the controller. | Add the AP's ESN to a site on the cloud management platform. |
| Register Fail: License is not authorized or expired | The AP's license is unauthorized or has expired. | Make sure the cloud management platform has enough license resources assigned. |
| Register Fail: Distribution controller node failure | The controller failed to assign the AP to a controller node. | Collect logs and open a support case. |
| Register Fail: The device unreports device models | The AP did not report its model information to the controller. | Collect logs and open a support case. |
| Register Fail: The device model do not match with esn | The model information the AP reported doesn't match its ESN. | Collect logs and open a support case. |
| Register Fail: The device unreports MAC | The AP didn't report a MAC address, or it doesn't follow the expected format. | Collect logs and open a support case. |
| Register Fail: The cloud APs cannot add to AC site | A cloud-managed AP is being onboarded into a site that's configured as an AC-managed (WAC) site. | Add the device to a site configured for AP-type (cloud) management instead. |
| Register Fail: The ESN is not in allow rule | The device is not in the controller's whitelist. | Ask the cloud management platform administrator to add the device's ESN to the whitelist. |
The table tells you what the controller said. These six are the cases where the real fix takes one more step than the table implies.
SYMPTOMregister-fail-record or online-fail-record shows The device is not added to the controller, or separately The device is not in the whitelist / The ESN is not in allow rule.
CAUSEiMaster NCE-Campus won't onboard a device it doesn't already know about, and it checks that in two separate places. Not added to the controller means the ESN was never entered against any site at all. Not in the whitelist / not in allow rule means the ESN was entered, but a separate whitelist gate in the registration path is still rejecting it. Clearing one doesn't mean you've cleared the other.
FIXAdd the device's ESN to the correct site, and separately confirm the same ESN is present in the controller's registration whitelist — check both, not just whichever one the current error string points at.
SYMPTOMThe device license is not authorized or has expired (switch), or License is not authorized or expired (AP).
CAUSEThe controller enforces licensing as part of the registration itself — it's checking the license resource assigned to this device's ESN on iMaster NCE-Campus, not whatever license state the device believes it has locally.
FIXCheck the license assigned to the device's ESN on the controller and confirm it hasn't expired; on WAC-managed APs, display cloud license shows what the controller currently holds for that device. If it's expired, apply and load a new license. See our switch license activation troubleshooting note for the device-side half of this same problem.
<WAC> display cloud license
// confirms whether the controller currently holds a valid license for this device's ESNSYMPTOMThe reported device model is inconsistent with that on the controller.
CAUSEThis isn't usually the wrong product model — it's the device's actual form factor not matching what the controller's site design expects. The most common real case: the switch is physically running as a stack, or a chassis switch is running as a cluster, while the controller has the site configured for a standalone unit.
FIXCheck display stack configuration all on box switches or display css configuration all on chassis switches, and align the device's actual form factor with what's designed on the controller — undo css enable disables clustering, reset stack configuration clears stack membership.
<HUAWEI> display stack configuration all
<HUAWEI> display css configuration all
[HUAWEI] undo css enable
<HUAWEI> reset stack configurationSYMPTOMThe token does not exist or the verification fails, seen mainly in DHCP-based zero-touch onboarding.
CAUSEDHCP-based onboarding carries a registration token through the upstream device's DHCP client configuration. If that token is missing or doesn't match what the controller expects, registration is rejected outright even though every network path involved is completely healthy.
FIXIn a DHCP onboarding scenario, check the token configured in the upstream device's DHCP client settings against the value the controller actually issued for this deployment, rather than re-checking reachability that was never the problem.
SYMPTOMregister-fail-record shows Controller certificate authentication failed, even though the certificate and the onboarding configuration both look correct.
CAUSEPKI certificate validation is time-bound. If the switch's own system clock falls outside the certificate's issued validity window, authentication fails purely on that basis — the certificate itself can be perfectly valid and still get rejected.
FIXCompare display pki certificate ca realm default against display clock; if the device's clock sits outside the certificate's validity period, set clock datetime to bring it back inside that window before touching the certificate configuration at all.
<HUAWEI> display pki certificate ca realm default
<HUAWEI> display clock
// if the device clock is outside the certificate's validity window, that alone explains the rejection
[HUAWEI] clock datetime HH:MM:SS YYYY-MM-DDSYMPTOMFailed to apply IP address in the register-fail-record, even though the DHCP server itself is healthy and reachable elsewhere on the same network.
CAUSEA switch sitting between the device and the DHCP server has dhcp snooping enable configured, but the uplink port facing the DHCP server was never marked trusted. Snooping then silently discards the DHCP server's own reply packets as untrusted, and the device never receives an address to register with in the first place.
FIXConfirm dhcp snooping trusted is applied on the uplink interface facing the DHCP server — enabling snooping itself is not enough on its own.
[Switch] dhcp snooping enable
[Switch-GigabitEthernet0/0/1] dhcp snooping trustedPulled straight from the field — the ones worth having an answer ready for.
They're two separate gates in the same registration path. Not added means the ESN has never been entered against any site on the controller at all. Not in the whitelist means it has been entered, but a separate allow-list check still isn't passing it. Fixing one doesn't automatically fix the other — check both.
That means the device never got a controller address to register against in the first place — there's no error to read yet. Go back to Stage 0/1: check DHCP option 148, DNS resolution of the controller's URL, or the static configuration, before you go anywhere near the error-code tables.
The two device types report through different commands — display netconf ... on switches, display cloud-mng ... on APs — and the exact wording of the reason strings isn't identical. But they cover the same underlying categories: ESN registration, license, whitelist, model/ESN match, and basic network reachability.
No. A WAC-managed (Fit AP) onboarding failure is a different fault path entirely — it's almost always a missing or expired license on the WAC itself, or a missing FitAP-to-WAC binding, checked with display cloud license and the AP list under the WAC's device details in the controller, not the cloud-mng codes in this note.
Usually it was a timing or timeout condition rather than a misconfiguration, and a clean retry is a reasonable outcome. If it recurs on every attempt, or across more than one device at the same site, that pattern is worth escalating rather than continuing to retry.
An empty failure reason next to RegisterFail usually means the SSH/TLS session to the controller never actually established in the first place. Check display tcp status for an ESTABLISHED session toward the controller's port, and display ssh server error for the specific handshake failure, before assuming the controller rejected the registration itself.
This note is built around iMaster NCE-Campus's NETCONF-based switch onboarding and cloud-mng AP onboarding error-classification models, plus the field cases behind them. If your APs are managed through a WAC (Fit AP mode) instead, or you run a different controller platform entirely, the exact commands and error strings change, but the underlying registration logic — reachability, certificate/token validation, ESN/license/whitelist checks — carries over directly. It doesn't cover WAC-managed FitAP onboarding failures in depth, or third-party controller platforms.
Tell us the exact error string from register-fail-record or online-fail-record, plus whether it's a switch or an AP, and we'll help you read it.