A private hub, a private router, or someone sharing a phone's Wi-Fi off a wall port — every one of these should trip an alert on a properly configured access switch, and most of the time they don't because one specific piece of the detection chain is missing. This is the detection logic behind each of the three private-connection types, the exact diagnose-view commands to run, and the five reasons detection comes back empty even when the rogue device is sitting right there.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A hub gives itself away by repetition, a router or shared hotspot gives itself away by contradiction — treating all three as one detection problem is why so many of these tickets stall.
Huawei's private-connection detection covers three distinct unauthorized devices behind a single access port: a private hub, sharing one port among several MAC addresses; a private router, translating one legitimate address into several devices behind it; and Wi-Fi sharing, a phone or laptop bridging its own hotspot onto the wired network. Each of the three is its own feature — unauthorized-hub, unauthorized-router and wi-fi-sharing detection — with its own detection mechanism, and its own reason for coming back empty even when the rogue device is genuinely there.
What follows is the detection logic behind each type, the fault tree for placing a "no result" symptom on the right branch, the diagnose-view commands for each stage, the five root causes that explain most of these tickets, and five FAQ answers pulled from real field cases. Confirming a device even reaches the switch's identification pipeline in the first place is a related but separate question — see terminal-identification-troubleshooting.html if the port itself seems to be reporting nothing at all.
Before running a single command, decide which of three questions you're actually asking — the diagram below is the fastest way to do that.
unauthorized-hub asks whether the same MAC keeps reappearing behind one port; unauthorized-router and wi-fi-sharing ask whether one port's traffic contains contradictory device fingerprints; the ARP active probe asks a narrower, confirming question once a hub is already suspected.
Diagram labels are kept in English for engineering clarity.
None of the three detection types has to be enabled together — each is switched on independently with its own uap enable uap-type command, and a "no result" on one doesn't say anything about the state of the other two.
Three detection types, three different commands to read first — and the report-path check that applies to all of them.
unauthorized-hub, unauthorized-router and wi-fi-sharing are independent features — confirm all three are actually switched on before assuming any one of them is broken.
[HUAWEI] uap enable uap-type unauthorized-hub
[HUAWEI] uap enable uap-type unauthorized-router
[HUAWEI] uap enable uap-type wi-fi-sharing
// each type is independent -- enabling one says nothing about the other twoA hub only gets flagged once the same MAC address shows up twice behind the same port — a single sighting proves nothing.
<HUAWEI> diagnose
[HUAWEI-diagnose] display uap profiling interface
Interface Ip-address MAC Vlan Online-time
10GE1/0/1 192.168.137.3 607d-095a-ee83 4094 2024-01-25T06:29:59+00:00
// same MAC repeating on the same interface is what actually gets a port flagged
[HUAWEI-diagnose] display cpu-defend statistics packet-type ntid-http all
PacketType Total Passed Total Dropped
ntid-http 658 0
// Total Passed = 0 means the switch never received a reply packet at all
[HUAWEI-diagnose] debugging host packet 0a010101 slot 1 number 10
// capture by source-IP hex if the report path itself is in questionThis isn't a signature match — it's a logic check for two things that shouldn't both be true behind the same port.
[HUAWEI-diagnose] display uap profiling mac
MAC Ip-address Interface TTL Dns-feature Http-feature Tcp-feature
fe51-6735-3c5f 192.168.137.130 10GE1/0/1 64/0_1_0 - - ios
0055-c055-0102 2.2.2.205 10GE1/0/1 64/63/1_1_0 - Windows6.1 -
// two different TTLs, or an illegal repeat like 63, is what actually flags a port here
[HUAWEI-diagnose] display uap feature
Interface MAC Type Value
10GE1/0/1 0055-c055-0102 UAP_HTTP_UA 0,64,2.2.2.205,Mozilla/5.0 (Windows; U; Windows NT 6.1...)
// thin traffic in this table produces a thin, inconclusive profile aboveThis probe only runs against terminals that came online after arp snooping was enabled — and it only counts as a hub on a specific ratio, not just any extra reply.
[HUAWEI-diagnose] display arp snooping all
VLAN/CEVLAN IP ADDRESS MAC ADDRESS INTERFACE EXPIRE(S)
1/0 10.2.0.167 4ce1-7345-1fe5 GE1/0/7 866
// only terminals listed here were even eligible for the ARP probe
[HUAWEI-diagnose] display uap arp-detection
Interface Vlan IP-Address MAC-Address Send-Count Recv-Count Is-HubUa
GE1/0/7 1 10.2.0.167 4ce1-7345-1fe5 2 4 true
GE1/0/8 1 10.2.0.168 4ce1-7345-1fe6 2 0 false
// Is-HubUa only reads true once Recv-Count is at least 2x Send-Count
[HUAWEI] display cpu-defend statistics packet-type arp-reply all
PacketType Total Passed Total Dropped
arp-reply 1427 2
// Total Passed = 0 means no ARP replies are being received from that port at allOnce the checks above have told you where the problem sits, these five explain most of what's actually wrong.
SYMPTOMdisplay uap detection-results comes back empty for a device type you can see plugged in right in front of you.
CAUSEunauthorized-hub, unauthorized-router and wi-fi-sharing are three independent features, each switched on with its own uap enable uap-type command. Enabling one says nothing about the state of the other two, and it's easy to assume all three are on because one of them clearly is.
FIXConfirm all three types are actually enabled with display current-configuration before troubleshooting further — don't assume detection is broken when it was simply never switched on for that specific device type.
SYMPTOMdisplay uap arp-detection shows a non-zero Recv-Count, but Is-HubUa still reads false.
CAUSEThe ARP probe only classifies a port as a hub once Recv-Count reaches at least twice Send-Count within one detection cycle. A single legitimate reply per probe — the normal, non-hub case — never crosses that ratio, no matter how many cycles run.
FIXRead Recv-Count against Send-Count as a ratio, not as a yes/no presence check — a 1:1 or 2:2 pattern is exactly what a single, honest device behind the port looks like.
SYMPTOMA hub that's been sitting behind a port for weeks never shows up in display uap arp-detection, while a new one connected today gets caught almost immediately.
CAUSEThe ARP active probe is triggered off arp snooping, and only terminals that came online after arp snooping was enabled get registered for probing. A device that was already up and running before the feature was turned on is invisible to this specific check, even though the hub itself hasn't changed at all.
FIXCheck display arp snooping all for the terminal's entry before assuming the probe should be catching it. If it's missing, the terminal came online too early for this feature — a port flap, or a scheduled re-check, brings it back into scope.
SYMPTOMdisplay uap profiling mac shows a TTL that looks a little unusual, but the port never gets flagged as a private router or shared hotspot.
CAUSEThe logic isn't whether a TTL looks wrong — it's specifically two different TTL values behind the same port, or one value repeating at an illegal number, 63 or 127. A single, internally consistent TTL, even an unusual one, describes one device behind that port, which is exactly the case the detection is designed to leave alone.
FIXRead the TTL field for variety, not oddity. If every packet from that port shows the same TTL, that's not a partial detection — it's the mechanism correctly deciding there's nothing to flag.
SYMPTOMEvery profiling and probing command above returns empty or zero, across every detection type, on a port you're certain has traffic on it.
CAUSEunauthorized-hub, unauthorized-router and wi-fi-sharing detection all depend on the same underlying delivery path — an ACL programmed into hardware, and a microcode entry that actually forwards the matching packet up to the UAP service. When that path breaks, commonly an ACL that failed to program, every detection type looks identical from the outside — quiet, with nothing to show, regardless of what's actually plugged in.
FIXCheck display cpu-defend statistics packet-type ntid-http all for Total Passed, and the matching NTID cause-ID counters under display forward information. If none of them are incrementing, this is a delivery problem underneath detection itself, worth a HOST-side debug capture and escalation rather than more profiling commands.
Pulled straight from the field — the ones worth having an answer ready for.
Run display uap detection-results in any view. It lists every flagged interface, MAC, IP address, the specific unauthorized type — hub, router, or Wi-Fi sharing — and when it was detected.
display uap profiling mac shows the actual evidence: the TTL field tells you whether it's an outright hub-style repetition, while the Dns-feature, Http-feature and Tcp-feature columns show which operating-system fingerprints were seen — two different OS signatures, or two versions of one, behind the same port points to a router or shared hotspot rather than a plain hub.
They're fully independent — enable only unauthorized-hub, only unauthorized-router, only wi-fi-sharing, or any combination, with separate uap enable uap-type commands. There's no dependency between them, and no shared threshold that changes based on which others are on.
Confirm the same MAC has actually repeated behind that port first — a single sighting isn't enough. If it has repeated and detection is still empty, check whether the profiling and feature-cache commands show any data at all for that port; if they're both empty too, the issue usually sits below detection entirely, in whether the relevant packets are reaching the service in the first place.
Profiling is passive — it reads what a device's normal traffic already reveals about it: TTL, and OS fingerprints from DNS, HTTP and TCP. The ARP probe is active — the switch deliberately sends ARP requests and counts how many replies come back, which is specifically how a suspected hub gets confirmed, since a hub causes one probe to reach multiple real devices and generate more replies than a single device ever would.
This note is built around the private-connection detection fault-locating guidance and field cases in Huawei's S-series campus switch maintenance manual — S1720, S5700, S6700, S6730, S7700 and related models. It covers the switch's own detection logic and diagnose-view commands; it doesn't cover cloud-managed campus controller-side alerting or automated port-disable policy, and it doesn't address wireless-side rogue-AP detection, which is a separate WLAN feature with its own detection mechanism.
Tell us which type you're chasing — hub, router, or Wi-Fi sharing — plus the display uap profiling and display uap detection-results output, and we'll help you read it.