Interactive Troubleshooter

Published: Sep 26, 2026

No Internet - Test Ping to Router, ISP, and Google

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Isolate network connectivity failures systematically across OSI layers using ICMP echo requests to local gateways, ISP upstream hops, and public DNS servers. This interactive decision tree identifies local interface failures, ARP resolution drops, WAN gateway timeouts, and DNS transport degradation.

Full Diagnostic Tree & Step-by-Step Overview

What are the exact results when you run ICMP ping commands in your terminal?

Ping to local router Gateway (e.g., 192.168.1.1) fails with 'Request timed out' or 'Destination host unreachable'.
Ping to Router succeeds, but pinging Public IP (e.g., 8.8.8.8 or ISP Gateway) fails.
Pinging Public IPs (e.g., 8.8.8.8) succeeds, but pinging Domain Names (e.g., google.com) fails with 'Ping request could not find host'.
All pings succeed, but web browsing fails, or ping packets suffer severe packet loss/high latency.

What specific terminal error or interface status do you observe when pinging the Local Router?

Error reads 'PING: transmit failed. General failure.' or interface lacks an IP address (169.254.x.x APIPA).
Error reads 'Destination host unreachable' and ARP table shows no gateway MAC address.
Error reads 'Request timed out' only when connected over Wi-Fi, but Ethernet works or connects.
Ping fails due to local host firewall or security software blocking ICMP traffic outbound/inbound.

Local TCP/IP Stack Failure or APIPA Address Assignment

Solution:

Root Cause: TCP/IP Stack Corruption or DHCP Allocation Failure (APIPA)

When a terminal returns PING: transmit failed. General failure. or an ipconfig output reveals an IPv4 address in the 169.254.0.0/16 range (Automatic Private IP Addressing), the host operating system has failed to obtain a lease from the local DHCP server. This indicates physical Layer 1/2 disconnect, bound driver corruption, or winsock catalog desynchronization.

# Diagnostic Verification:

1. Open Terminal as Administrator.
2. Query interface IP configuration:

cmd
   ipconfig /all

3. Inspect the Autoconfiguration IPv4 Address and Default Gateway fields for your active network interface card (NIC).

# Step-by-Step Fix:

1. Test Loopback Stack:

cmd
   ping 127.0.0.1

*If loopback fails, the TCP/IP stack driver (tcpip.sys) is damaged.*
2. Reset Winsock Catalog and TCP/IP IP Stack:

cmd
   netsh winsock reset
   netsh int ip reset

3. Flush DNS and Release/Renew DHCP Lease:

cmd
   ipconfig /release
   ipconfig /flushdns
   ipconfig /renew

4. Re-enable the Network Interface:

powershell
   Disable-NetAdapter -Name "Ethernet" -Confirm:$false
   Enable-NetAdapter -Name "Ethernet"

# Prevention & Long-Term Monitoring:

Ensure network drivers are updated directly from vendor chipmakers (Intel, Realtek) rather than default OS updates.

Address Resolution Protocol (ARP) Failure at Local Link Layer

Solution:

Root Cause: ARP Mapping Failure or Layer 2 Isolation

A Destination host unreachable message during a gateway ping test signifies that the client host sent an ARP request asking "Who has 192.168.1.1?", but received no ARP reply from the local gateway MAC address. This stems from VLAN misconfigurations, switch port isolation, physical cable defects, or router freeze.

# Diagnostic Verification:

1. Check the local ARP cache table:

cmd
   arp -a

2. Locate your gateway IP address. If the physical address is listed as 00-00-00-00-00-00 or missing entirely, Layer 2 communication is broken.

# Step-by-Step Fix:

1. Clear the System ARP Cache:

cmd
   netsh interface ip delete arpcache

2. Power Cycle the Local Router/Switch:

Disconnect power from the primary router for 30 seconds.

Reconnect power and allow 2 minutes for core system boot and ASIC initialization.

3. Verify Physical Connection:

Swapping Ethernet cables (cat5e/cat6) or moving to a different LAN port on the switch/router.

4. Verify Static IP Configuration:

If using a static IP, ensure the subnet mask matches the router (typically 255.255.255.0).

# Prevention & Long-Term Monitoring:

Configure static ARP entries on critical infrastructure nodes or verify switch port security / MAC filtering settings.

Wi-Fi Association Failure or Wireless Medium Degradation

Solution:

Root Cause: IEEE 802.11 Authentication Dropped or Channel Interference

When wireless pings fail while local physical connectivity exists, the client device has experienced 802.11 frame loss, key re-handshake failure (WPA2/WPA3 enterprise/personal), or extreme RF noise on shared 2.4GHz / 5GHz channels.

# Diagnostic Verification:

1. Check WLAN interface state in PowerShell:

powershell
   netsh wlan show interfaces

2. Check Signal, Radio type, and State. Confirm state displays connected.

# Step-by-Step Fix:

1. Reset Wireless Interface Profile:

cmd
   netsh wlan delete profile name="YourSSID"

2. Reconnect to Wireless Network and re-authenticate.
3. Reset WLAN AutoConfig Service:

services
   net stop wlansvc
   net start wlansvc

4. Disable Band Steering or Split SSIDs on Router:

Access router management console (http://192.168.1.1).

Separate 2.4 GHz and 5 GHz / 6 GHz network SSIDs to prevent channel-hopping disconnects.

# Prevention & Long-Term Monitoring:

Use a Wi-Fi analyzer to select non-overlapping channels (1, 6, 11 on 2.4 GHz; lower/upper clean bands on 5 GHz).

Host-Based Firewall or Security Software Blocking ICMP

Solution:

Root Cause: Local Packet Filtering of Echo Request / Reply Frames

Third-party endpoint protection, VPN firewall hooks, or aggressive Windows Defender Firewall rules can block outgoing ICMP Type 8 (Echo Request) or incoming ICMP Type 0 (Echo Reply) packets, creating a false impression of network downtime.

# Diagnostic Verification:

1. Attempt to ping gateway using explicit interface binding or test raw socket connection via PowerShell:

powershell
   Test-NetConnection -ComputerName 192.168.1.1 -Port 80

2. If TCP Port 80/443 responds but ICMP ping fails, firewall filtering is actively dropping ICMP traffic.

# Step-by-Step Fix:

1. Enable ICMPv4-In Echo Requests in Windows Firewall:

cmd
   netsh advfirewall firewall add rule name="Allow ICMPv4 In" protocol=icmpv4:8,any dir=in action=allow

2. Temporarily Disable Third-Party Security Suites / VPN Kill Switches:

Disable active VPN adapters (e.g., OpenVPN, WireGuard, ExpressVPN drivers).

3. Reset Windows Defender Firewall Rules to Default:

cmd
   netsh advfirewall reset

# Prevention & Long-Term Monitoring:

Ensure network profile is set to Private instead of Public for trusted local networks.

How far do trace packets travel when attempting to reach public internet destinations?

Tracert stops immediately at the local router address (192.168.1.1) with line timeouts.
Tracert passes local router, reaches ISP gateway hop, then fails continuously.
Router WAN port displays no IP address or reports PPPoE / DHCP lease failure.
Ping works to ISP hop, but fails specifically for external public IPs due to MTU size issues.

Router WAN Gateways Drop / Modem Offline

Solution:

Root Cause: WAN Interface Link Loss or Cable/Fiber Transceiver Disconnect

The local LAN router is functioning correctly, but its WAN interface cannot forward packets out to the Next-Hop routing switch. This points to a disconnected coaxial/fiber connection, down DOCSIS cable modem, or unauthenticated ONU/ONT device.

# Diagnostic Verification:

1. Run path tracing to a public IP address:

cmd
   tracert -d 8.8.8.8

2. Observe Hop 1 (Local Router) returning normal latency (e.g., <1ms), followed by repeating * * * Request timed out for Hop 2.

# Step-by-Step Fix:

1. Inspect Router Status Dashboard:

Check WAN Status / Internet Connection Status.

2. Verify Physical WAN Link State:

Confirm the LED indicator for Internet/WAN on your router/modem is solid green/white.

If red/amber/off, check physical coaxial, fiber patch cable, or Ethernet WAN connections.

3. Perform Sequential Cold Boot Power Cycle:

Power off both standalone Modem/ONT and Router.

Turn on Modem/ONT first; wait 3 minutes for optical/RF sync lights to stabilize.

Power on Router second; allow WAN DHCP handshake to complete.

# Prevention & Long-Term Monitoring:

Monitor modem signal-to-noise ratios (SNR) and power levels via modem diagnostic page (commonly http://192.168.100.1).

ISP Service Outage or Upstream Routing Black Hole

Solution:

Root Cause: Autonomous System (AS) Upstream Outage or BGP Routing Failure

Packets successfully exit your local premises, reach your Internet Service Provider's edge router (Edge Point of Presence - PoP), but are dropped due to upstream fiber cuts, peering failures, or regional ISP infrastructure outages.

# Diagnostic Verification:

1. Execute trace route to identify where packet degradation occurs:

cmd
   tracert 8.8.8.8

2. Note the last responding IP address in the trace list (e.g., Hop 3 or 4 within your provider's domain like be-10-100-cbr01.isp.net).

# Step-by-Step Fix:

1. Verify Remote Hop Domain:

Perform WHOIS or reverse lookup on the last responding IP to confirm it belongs to your ISP.

2. Check Service Provider Status Portals:

Check status reports via mobile cellular network or contact ISP technical support.

Provide support personnel with the exact last responding hop IP address from your tracert output.

3. Release and Renew Public WAN IP:

In router admin GUI, click WAN Release then WAN Renew to force assignment to a different node/subnet if available.

# Prevention & Long-Term Monitoring:

Implement secondary WAN failover (e.g., 5G/LTE backup router) if continuous uptime is required.

Router WAN Protocol Failure (PPPoE Authentication / DHCP Drop)

Solution:

Root Cause: Authentication Dropped or Upstream DHCP Lease Timeout

In fiber/DSL configurations utilizing PPPoE or ISP-managed dynamic IP assignments, the router fails to establish a virtual point-to-point tunnel or refresh its public WAN IPv4 address lease.

# Diagnostic Verification:

1. Check the WAN status section of your router interface.
2. Look for errors such as PPPoE Authentication Failed, CHAP authentication failed, or WAN IP: 0.0.0.0.

# Step-by-Step Fix:

1. Verify PPPoE Credentials:

Navigate to Router WAN / Internet setup page.

Re-enter your ISP-provided account username and password.

2. Adjust WAN MTU Settings:

For PPPoE connections, ensure WAN MTU (Maximum Transmission Unit) is set to 1492 (or 1480) to accommodate the 8-byte PPPoE header.

3. Clone MAC Address (If Required by ISP):

Some cable ISPs bind connection access to the specific MAC address of the original device/router.

Select Clone Computer MAC Address inside the WAN settings tab.

# Prevention & Long-Term Monitoring:

Save offline backups of router configuration files whenever credentials or custom network configurations are modified.

Path MTU ICMP Fragmentation Black Hole

Solution:

Root Cause: Packet Fragmentation Drop due to PMTU / Don't Fragment (DF) Bit

Network packets larger than the Maximum Transmission Unit (MTU) of an intermediate link are silently dropped if the packet has the "Don't Fragment" (DF) flag set and intermediate routers block ICMP "Fragmentation Needed" messages.

# Diagnostic Verification:

1. Execute ping tests with custom payload sizes and Don't Fragment flag enabled:

cmd
   ping 8.8.8.8 -f -l 1472

2. If this fails with Packet needs to be fragmented but DF set, lower payload size incrementally (e.g., 1450, 1420, 1400) until pings succeed.

# Step-by-Step Fix:

1. Calculate Correct MTU Size:

Take the largest successful ping payload size and add 28 bytes (20 bytes IPv4 header + 8 bytes ICMP header).

Example: 1464 + 28 = 1492 MTU.

2. Change Interface MTU in Windows via Netsh:

View active interfaces:

cmd
     netsh interface ipv4 show subinterfaces

Set optimal MTU on your local network adapter:

cmd
     netsh interface ipv4 set subinterface "Ethernet" mtu=1492 store=persistent

# Prevention & Long-Term Monitoring:

Avoid setting network MTU above standard Ethernet frame limits (1500) unless Jumbo Frames are configured across all local switches.

What specific error message or resolution behavior occurs when attempting DNS pings?

Ping command instantly outputs 'Ping request could not find host google.com'.
nslookup resolves domain names fine, but pinging FQDNs still fails.
DNS ping fails only for specific domains, while resolving others correctly.
DNS queries time out due to rogue local proxy, malware, or third-party VPN DNS leaks.

Misconfigured or Unresponsive Primary DNS Resolvers

Solution:

Root Cause: Unreachable Upstream Domain Name Servers

The client device can send and receive raw IPv4 packets to public destinations (e.g., 8.8.8.8), but its configured DNS servers are either unreachable, timing out, or returning SERVFAIL responses, preventing domain-to-IP translation.

# Diagnostic Verification:

1. Test DNS lookup manually using nslookup:

cmd
   nslookup google.com

2. Note if the server times out or fails to resolve address details.
3. Query public DNS directly:

cmd
   nslookup google.com 1.1.1.1

# Step-by-Step Fix:

1. Change Network Adapter DNS to Anycast Public Resolvers:

Open PowerShell (Admin) and set static DNS servers (Cloudflare & Google):

powershell
     Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","8.8.8.8")

2. Flush DNS Resolver Cache:

cmd
   ipconfig /flushdns

3. Restart DNS Client Service:

powershell
   Restart-Service -Name "dnscache"

# Prevention & Long-Term Monitoring:

Refer to Microsoft Official Support Guide for complete TCP/IP reset command flows.

Configure fallback secondary and tertiary DNS servers in primary router DHCP options.

Corrupted Windows Hosts File or Local DNS Cache Misconfiguration

Solution:

Root Cause: Local Static Name Resolution Override in Hosts File

The Windows DNS client checks local resolution sources prior to sending external queries. An altered or corrupted hosts file redirects domain name queries to invalid loopback addresses (0.0.0.0 or 127.0.0.1), causing applications and ping to fail.

# Diagnostic Verification:

1. Check host file contents via PowerShell:

powershell
   Get-Content C:\Windows\System32\drivers\etc\hosts

2. Look for static mapping lines pointing domains like google.com to 127.0.0.1.

# Step-by-Step Fix:

1. Reset the Local Hosts File to Default:

Open Notepad as Administrator.

Open C:\Windows\System32\drivers\etc\hosts.

Clear non-standard entries and restore default structure:

text
     # Copyright (c) 1993-2009 Microsoft Corp.
     #
     # 127.0.0.1       localhost
     # ::1             localhost

Save file encoding as UTF-8.

2. Clear Local Cache:

cmd
   ipconfig /flushdns

3. Reset NetBIOS Name Resolution:

cmd
   nbtstat -R
   nbtstat -RR

# Prevention & Long-Term Monitoring:

Lock the hosts file permissions to prevent unauthorized modifications by third-party tools.

Selective Domain Name Hijacking / DNS Suffix Misconfiguration

Solution:

Root Cause: Incorrect Connection-Specific DNS Suffix or DNS Filtering

When DNS pings succeed for some endpoints but fail for specific corporate or external domains, an incorrect DNS Search Suffix append rule or active DNS sinkhole (e.g., Pi-hole, Cisco Umbrella, Quad9) is dropping queries for designated domain records.

# Diagnostic Verification:

1. Query specific domain resolution with full FQDN trailing dot:

cmd
   nslookup google.com.

2. Inspect active DNS suffixes:

cmd
   ipconfig /all

Check the DNS Suffix Search List entry.

# Step-by-Step Fix:

1. Clear Connection-Specific DNS Suffixes:

Press Win + R, type ncpa.cpl, hit Enter.

Right-click active adapter > Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties > Advanced.

Under the DNS tab, set to Append primary and connection specific DNS suffixes.

2. Bypass Local Filtering for Diagnostics:

Test resolution against an unfiltered public server:

cmd
     nslookup domain.com 9.9.9.9

# Prevention & Long-Term Monitoring:

Ensure corporate VPN client software cleanly unbinds custom DNS search suffixes upon disconnection.

Rogue Proxy, Security Agent, or VPN Tunnel DNS Hijack

Solution:

Root Cause: Dead Proxy Server Settings or Virtual Adapter Bind Interruption

Security software or stale VPN virtual adapters inject local proxy loopbacks (127.0.0.1:8080) into Windows Internet Settings (WinINet). When the proxy service stops running, outgoing network traffic is routed to a closed local socket.

# Diagnostic Verification:

1. Query active system proxy configuration via PowerShell:

powershell
   Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable, ProxyServer

2. Verify if ProxyEnable returns 1 while no local proxy service is active.

# Step-by-Step Fix:

1. Disable System Proxy Settings via Command Line:

cmd
   reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 0 /f

2. Reset WinHTTP Proxy Configuration:

cmd
   netsh winhttp reset proxy

3. Flush Network Virtual Adapters:

Open Device Manager (devmgmt.msc).

Expand Network adapters.

Right-click and uninstall stale TAP/TUN or VPN network drivers, then reboot.

# Prevention & Long-Term Monitoring:

Use clean VPN uninstallation utilities when removing security clients to prevent orphan virtual adapters.

What type of performance degradation occurs during packet transit?

Ping responses show high packet loss percentage (>20%) across all hops.
Ping latency spikes intermittently (e.g., 15ms jumps to 500ms+ every few seconds).
Pings succeed completely, but HTTP/HTTPS web pages fail to load in all browsers.
IPv4 pings fail entirely, while IPv6 pings succeed (or vice-versa).

High Packet Loss Across Local or External Hops

Solution:

Root Cause: Physical Layer Degradation, Duplex Mismatch, or Bufferbloat

Sustained packet loss across ICMP traffic indicates bad physical media (damaged copper wire, dirty fiber connector), electromagnetic interference, or severe bufferbloat/saturation on low-bandwidth upload channels.

# Diagnostic Verification:

1. Run extended ping to local gateway and public server simultaneously in separate terminal windows:

cmd
   ping 192.168.1.1 -n 50
   ping 8.8.8.8 -n 50

2. Compare loss statistics:

If gateway shows 0% loss but 8.8.8.8 shows 30% loss: Issue is ISP / WAN path.

If gateway shows >5% loss: Issue is local cable, Wi-Fi, or switch port.

# Step-by-Step Fix:

1. Check Port Speed and Duplex Settings:

In Device Manager, right-click network adapter > Properties > Advanced.

Set Speed & Duplex to Auto Negotiation (or force 1.0 Gbps Full Duplex).

2. Disable Energy Efficient Ethernet (EEE) / Green Ethernet:

Under Advanced properties, disable Energy Efficient Ethernet and Power Saving Mode.

3. Test for Local Network Saturation:

Pause high-bandwidth upload tasks (torrents, cloud backups) that starve the ACK return path.

# Prevention & Long-Term Monitoring:

Enable Smart Queue Management (SQM) or Quality of Service (QoS) on your router to eliminate bufferbloat.

Intermittent Latency Spikes (Jitter / Bufferbloat)

Solution:

Root Cause: Background Background Scans, Roaming Aggression, or Wi-Fi Spikes

Periodic ping latency spikes (e.g., ping hovering at 10ms, jumping to 600ms every 10 seconds) are usually caused by wireless network cards periodically scanning for alternative Access Points (WLAN Roaming Aggression) or localized buffer queuing.

# Diagnostic Verification:

1. Run pathping to measure per-hop latency jitter:

cmd
   pathping 8.8.8.8

2. Note which hop introduces the latency variance.

# Step-by-Step Fix:

1. Disable WLAN Background Scanning (Windows Wi-Fi):

Open Command Prompt as Administrator.

Disable auto-configuration scanning on active Wi-Fi adapter:

cmd
     netsh wlan set autoconfig enabled=no interface="Wi-Fi"

*(Note: Enable this setting back when switching location/networks).*
2. Adjust Wireless Adapter Roaming Aggressive Value:

Device Manager > Network Adapters > Right-click Wi-Fi card > Properties > Advanced.

Set Roaming Aggressiveness to 1. Lowest.

3. Enable QoS on Router for Latency-Sensitive Traffic:

Reserve upstream priority for ICMP, VoIP, and gaming traffic.

# Prevention & Long-Term Monitoring:

Switch critical desktop workstations from Wi-Fi connections to dedicated Cat6 Ethernet cabling.

ICMP Traffic Succeeds but Application Layer (HTTP/HTTPS) Blocked

Solution:

Root Cause: Application-Layer Gateway (ALG) Interception or TLS/SSL Inspection Block

When layer 3 pings and layer 4 socket tests pass, but web browsers display ERR_TIMED_OUT or SSL_ERROR_UNKNOWN, application traffic is being inspected or dropped by an upstream firewall, web filtering proxy, or corrupted web browser extensions.

# Diagnostic Verification:

1. Test raw TCP connection to port 443 of a web server via PowerShell:

powershell
   Test-NetConnection -ComputerName google.com -Port 443

2. If TcpTestSucceeded : True is returned, transport layer is functional and failure exists at Layer 7 (Application).

# Step-by-Step Fix:

1. Test in Clean Browser / Incognito Mode:

Open browser without extensions enabled (chrome.exe --disable-extensions).

2. Clear Browser Socket Pools & SSL State:

Open Chrome URL: chrome://net-internals/#sockets and click Flush socket pools.

Open Windows Control Panel > Internet Options > Content tab > Click Clear SSL State.

3. Verify Local Date and Time Synchronization:

Incorrect system time breaks TLS/SSL certificate validation.

Resync clock in PowerShell:

powershell
     w32tm /resync

# Prevention & Long-Term Monitoring:

Keep root certificate stores updated via Windows Update to maintain proper TLS handshake trust chains.

Dual-Stack Dual-Protocol Binding Failure (IPv4 vs IPv6)

Solution:

Root Cause: IPv6 Transition Tunneling Drop or Broken Dual-Stack Routing

When an ISP or router advertises IPv6 capabilities but lacks a working upstream IPv6 default route, modern operating systems prefer IPv6 (Happy Eyeballs algorithm) and timeout for 20+ seconds before failing over to functional IPv4.

# Diagnostic Verification:

1. Ping public endpoint explicitly forcing IPv4 and IPv6 protocols:

cmd
   ping -4 google.com
   ping -6 google.com

2. If -4 succeeds immediately while -6 times out, IPv6 routing is broken.

# Step-by-Step Fix:

1. Prefer IPv4 over IPv6 in Windows Prefix Policies:

Configure Windows to prefer IPv4 natively via PowerShell (Admin):

powershell
     New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters' -Name 'DisabledComponents' -PropertyType DWORD -Value 0x20 -Force

2. Disable IPv6 on Active Adapter (If ISP lacking IPv6 support):

powershell
   Disable-NetAdapterBinding -Name "Ethernet" -ComponentID ms_tcpip6

3. Restart Adapter:

powershell
   Restart-NetAdapter -Name "Ethernet"

# Prevention & Long-Term Monitoring:

Verify router supports Native Dual-Stack IPv6 (DHCPv6 / SLAAC) before enabling IPv6 on local interfaces.

Related Diagnostic Guides

SharePoint Online Access Denied Even as Owner

Interactive: Game Crashes - Overheating, Driver, or Corrupted Files?

Intune Device Compliance Failed: Conditional Access Fix

Entra ID Sync Error: Duplicate Proxy Address

Power Automate Flow Failed: Connector Timeout Diagnostic

Subscribe to StepDiag

Embed Guide on Your Website