Why Does ADcampus Wi-Fi Drop Immediately After Successful Portal Authentication?

null

1. Background & Problem Description

In an enterprise campus wireless network deployment, the infrastructure consists of H3C Wireless Access Controllers (AC) and Fit APs. The admission control mechanism is configured as MAC-prioritized Web Authentication (MAC-Portal / Seamless Web Authentication).

To quickly reclaim IP resources from unauthorized devices, the network engineers implemented a two-stage DHCP addressing policy:

• Pre-Authentication (Quarantine State): When an unauthenticated device connects to the open SSID, MAC authentication initially fails, and traffic is redirected to a Web Portal. The DHCP server assigns a temporary IP with an aggressive 1-minute ultra-short lease.
• Post-Authentication (Authorized State): Once the user enters credentials and passes Portal authentication, the network issues a production IP with a standard 1-day lease.

The Symptom

Users reported that shortly after entering their credentials and successfully logging in via the Portal, the Wi-Fi connection would consistently flap/drop within 30 to 60 seconds (the Wi-Fi icon would disconnect or temporarily disappear). A few seconds later, it would automatically reconnect, acquire the 1-day business IP, and finally provide stable Internet access.

The Debate:

"Is the Windows operating system proactively dropping the Wi-Fi because the 1-minute lease expired? Or is the H3C AP kicking the client off?"

2. Investigation & Log Analysis (The Evidence Chain)

To isolate whether the disconnect was initiated by the client OS, the wireless NIC, or the network infrastructure, we extracted the comprehensive Windows diagnostic report using:

This command compiles an extensive diagnostic log (wlan-report-latest.html) containing all low-level WLAN AutoConfig and NDIS driver events.

Step 1: Cross-Hardware Comparison (Ruling Out Client Hardware/Drivers)

We analyzed reports from two completely different laptop configurations:

Finding 1:
Two fundamentally different Wi-Fi 6 NICs from distinct vendors (Intel vs. MediaTek) exhibited identical, clockwork-like 30-second disconnect loops. This 100% ruled out client-side hardware defects or driver-specific bugs. The behavior was clearly governed by an external protocol or network policy.

Step 2: Decoding Windows WLAN AutoConfig Event Chains

By analyzing the event timelines in the reports, we categorized the disconnections into two distinct behaviors:

Pattern A (85%+ of Occurrences): Clean External Disconnection

• Analysis: Windows experienced zero internal errors and did not trigger any recovery routines. Internet probe was fully successful.
• Under the Hood: The wireless NIC received an over-the-air 802.11 Deauthentication frame transmitted directly by the AP. Complying with 802.11 standards, the miniport driver tore down the link and reported Disconnected by the driver up to Windows.

Pattern B (Remaining Occurrences): OS Self-Healing Failure

In a minority of cases, the log captured:

• Microsoft ETW Definition:
  • Trigger Reason: 5 = IP configuration lost / DHCP lease invalidated.
  • Recovery Type: 4 = Soft reset / restart of the L2 adapter interface.
• Analysis: During the transition, when the 1-minute lease expired or was rejected with a DHCP NAK before the new lease arrived, the Windows IP stack became invalid. Windows initiated its highest-level self-healing routine (Recovery Type: 4), resetting the virtual adapter and intentionally dropping the Wi-Fi connection to trigger a fresh DHCPDISCOVER.

3. Root Cause Unveiled: The Customer's AC Configuration

Armed with these findings, we inspected the customer's H3C Access Controller (AC) configuration and found the exact smoking gun:

Command 1: wlan client reauthentication-period (The Culprit)

• Function: Configures an idle/quiet period before a client triggers MAC re-authentication after passing Web authentication (default is 10 seconds).
• Design Purpose: In MAC-Portal workflows, once a user authenticates via the Web portal, the client must trigger a fresh MAC authentication to transition into the authorized state. However, if the client immediately attempts to re-authenticate while its previous 1-minute temporary IP and session remain active on the server/gateway, the re-authentication frequently fails due to state collision.
• The H3C Internal Mechanism:

  When Web authentication succeeds, the AC intentionally places the client's MAC address into a Dynamic Blacklist for the configured duration (e.g., 10 seconds)!
  During this isolation window, the AC commands the AP to transmit an 802.11 Deauthentication frame, forcefully disconnecting the client to allow time for stale sessions and temporary leases to flush. Once the timer expires, the AC removes the client from the blacklist, allowing it to reconnect and complete official MAC admission.

Command 2: undo wlan dynamic-blacklist active-on-ap (The Amplifier)

• Function: Forces the dynamic blacklist to take effect globally across the entire AC, rather than locally on a single AP.
• Impact: Once blacklisted, every AP managed by the AC simultaneously rejects the client's probe and association requests, ensuring the client cannot associate with any AP in the facility until the quiet period expires.

? 4. End-to-End Workflow Sequence Diagram

Here is the complete sequence of events that explains the exact phenomenon observed on-site:

5. Key Takeaways

1. Why the "1-Minute Lease" is an Anti-Pattern on Windows

While network administrators often use short leases to accelerate IP recycling, in dynamic admission control environments:

• Windows does not support in-flight, zero-downtime IP remapping across different subnets/VLANs on the same wireless association.
• Lease expiration without seamless renewal forces Windows into WLAN AutoConfig Recovery Type 4, triggering client-side interface resets that compound network-side deauthentication.