How to Inspect NetworkStack Diagnostics and Captive Portal Probes on Android Using ADB dumpsys network_stack

In the Android operating system architecture, establishing reliable IP connectivity involves numerous coordinated protocol negotiations: obtaining an IPv4 address via DHCP, stateless address autoconfiguration (SLAAC) over IPv6, performing duplicate address detection (DAD), verifying DNS resolver availability, and validating full internet reachability through HTTP/HTTPS captive portal probes.

Historically bundled inside the monolithic system server, Google decoupled these low-level networking components in Android 10 into an updatable Mainline APEX module known as the NetworkStack. The NetworkStack module coordinates the internal DHCP client, IPv6 router discovery, network link monitoring, and captive portal detection. When devices experience “Connected, no internet” warnings, DHCP address acquisition timeouts, or failing captive portal redirect prompts on enterprise or hotel Wi-Fi networks, the dumpsys network_stack command via the Android Debug Bridge (ADB) provides high-resolution protocol telemetry and event timelines.

Architecture of the Android NetworkStack Module

The NetworkStack operates as an isolated, privileged system application (com.google.android.networkstack) running in its own process. Its primary internal subsystems include:

• NetworkMonitor: Constantly tests network quality and internet validation state by transmitting lightweight HTTP and HTTPS probes to well-known endpoints (e.g. connectivitycheck.gstatic.com/generate_204). If an intermediate gateway intercepts the probe and returns an HTTP redirect (302) or login page (200), NetworkMonitor flags the network as a Captive Portal.
• DhcpClient: The user-space DHCP state machine handling Discover, Offer, Request, and Ack (DORA) handshakes, lease timers, and gateway options.
• IpClient: Integrates IPv4 DHCP and IPv6 Neighbor Discovery protocol (NDP) states, passing validated link configuration parameters down to netd and the Linux kernel.
• ApfFilter: Android Packet Filter engine that executes bytecode inside the Wi-Fi firmware to drop unsolicited multicast and broadcast packets while the device screen is off, preserving battery life.

Querying NetworkStack Diagnostics via ADB

To inspect active network stack operations, connect your target Android smartphone, tablet, or test device with USB debugging enabled.

Open a terminal prompt on your workstation and execute:

adb shell dumpsys network_stack

This command dumps comprehensive diagnostic tables from the active NetworkStack process, detailing:

• Registered network interfaces and link properties (e.g. wlan0, rmnet_data0).
• Active and historical Captive Portal detection probes, response codes, and probe latency.
• DHCP handshake packet exchanges, lease renewal timestamps, and server IP identifiers.
• APF program status and dropped packet counters.

Analysing Captive Portal Detection and Validation Probes

Inside the diagnostic report, locate the NetworkMonitor section. For each active network (such as Network 100 on Wi-Fi), NetworkMonitor logs every probe attempt:

NetworkMonitor/100:
  Validation state: VALID
  Captive portal state: NOT_CAPTIVE_PORTAL
  Last validated: 2026-11-08 05:40:12
  Probe timeline:
    [2026-11-08 05:40:11] PROBE_HTTP: https://connectivitycheck.gstatic.com/generate_204 -> HTTP 204 (Latency: 48ms)
    [2026-11-08 05:40:11] PROBE_HTTPS: https://www.google.com/generate_204 -> HTTP 204 (Latency: 62ms)
    [2026-11-08 05:40:12] PROBE_DNS: dns.google -> Success (Latency: 18ms)

Review the essential evaluation states:

• HTTP 204 No Content: The probe reached Google’s validation servers unimpeded. The network is marked as valid with full internet access.
• HTTP 302 / 307 Redirect: The local gateway intercepted the probe and redirected the connection to a splash page. NetworkMonitor flags the network as CAPTIVE_PORTAL and triggers the system login notification.
• Connection Timeout / SSL Failure: If intermediate firewalls or DNS filtering block the validation endpoints without redirecting, NetworkMonitor marks the network as NO_INTERNET, prompting Android to display an exclamation mark next to the Wi-Fi icon.

Auditing DHCP Client Handshakes and Lease States

When investigating network dropouts or slow connection acquisition, inspect the DhcpClient log within dumpsys network_stack:

DhcpClient/wlan0:
  State: BOUND
  Current lease:
    IP address: 192.168.1.145/24
    Gateway: 192.168.1.1
    DNS servers: [192.168.1.1, 8.8.8.8]
    DHCP server: 192.168.1.1
    Lease duration: 86400s
  Handshake history:
    [05:39:10] DHCPDISCOVER sent (XID: 0x4a12bcde)
    [05:39:10] DHCPOFFER received from 192.168.1.1 (Offered IP: 192.168.1.145)
    [05:39:11] DHCPREQUEST sent
    [05:39:11] DHCPACK received (Lease granted)

If the handshake history shows repeated DHCPDISCOVER packets without matching DHCPOFFER responses, the access point or upstream DHCP pool is exhausted or dropping broadcast packets.

Testing Captive Portal Probes Dynamically

You can force the NetworkStack to re-evaluate network validation and trigger immediate captive portal probes directly from ADB:

# Force immediate network validation probe on all active networks
adb shell cmd connectivity reevaluate --all

To inspect custom captive portal URLs configured via device global settings:

# Inspect custom HTTP validation URL
adb shell settings get global captive_portal_http_url

# Inspect custom HTTPS validation URL
adb shell settings get global captive_portal_https_url

If enterprise devices operate in isolated intranets without public internet access, administrators can point these global settings to an internal web server returning HTTP 204 to prevent false “No internet” alerts on corporate fleets.

Auditing the Android Packet Filter (APF) Engine

The NetworkStack compiles an APF filter program uploaded to the Wi-Fi chipset firmware to filter background broadcast packets.

In dumpsys network_stack, locate the ApfFilter statistics:

ApfFilter:
  Program length: 842 bytes
  Packets received: 14210
  Packets dropped: 11840 (83.3%)
  Packets passed: 2370

A high drop percentage (typically 70% to 90%) indicates healthy APF operation, confirming that the Wi-Fi chip successfully drops background ARP and mDNS chatter before waking the main application processor.