Client Connectivity Checks by Operating System

Client Connectivity Checks

Client checks should be consistent even when operating systems look nothing alike. Start by confirming the expected access method (wired, Wi-Fi, cellular, or VPN) and that the interface is enabled and connected. Inspect IP settings: IP address, subnet mask or prefix length, default gateway, DNS servers, and whether the address came from DHCP or was set statically. Then test in layers: local link or Wi-Fi association, gateway reachability, DNS name resolution, and finally the application. The same five-layer sequence works on every platform; only the tools differ.

Windows

The Settings app shows Ethernet/Wi-Fi status, known networks, adapter properties, IP and DNS assignment, and proxy or VPN settings. Device Manager exposes adapter and driver state. At the command prompt:

• ipconfig /all lists IP, mask, gateway, DNS, DHCP server, and MAC for every adapter
• ping <gateway> tests Layer 3 reachability to the router
• tracert <host> shows the hop-by-hop path
• nslookup <name> tests DNS resolution directly

Common trap: an address in the 169.254.x.x range is an Automatic Private IP Addressing (APIPA) self-assigned address, which means DHCP failed; the host can talk only on its local link, not to the gateway.

Linux

Tools vary by distribution and desktop, but the essentials:

Interface names look like eth0, ens33, enp0s3, or wlan0; match the name to the active adapter before reading its address.

macOS

System Settings shows Wi-Fi, Ethernet, VPN, and per-service details; the Details button reveals TCP/IP, DNS, proxy, the hardware address, and the private-Wi-Fi-address setting. In Terminal: ifconfig for interfaces, netstat -rn or route -n get default for routing, scutil --dns for DNS, plus ping and traceroute. Wireless Diagnostics offers deeper Wi-Fi analysis, but basic CCST work focuses on association, addressing, DNS, and reachability.

Android

Under Network and Internet (or Connections), confirm Wi-Fi on/off, the connected SSID, signal, IP details, Private DNS, VPN status, airplane mode, hotspot/tethering, and whether mobile data is enabled. Android randomizes the Wi-Fi MAC per network by default; if the network uses MAC-based controls, confirm whether the device shows a randomized or hardware MAC per site policy.

iOS and iPadOS

Wi-Fi settings show the SSID, IP details, router, DNS, Private Wi-Fi Address, Low Data Mode, and any HTTP proxy. Cellular settings show mobile-data status, roaming, SIM/eSIM lines, Personal Hotspot, and per-app cellular permissions. VPN and Mobile Device Management (MDM) profiles can override routing, DNS, and certificate trust, so a device may join Wi-Fi yet be blocked by a captive portal, wrong password, expired certificate, or management policy.

Capture State, Then Decide

Across all platforms, change one thing at a time and capture the current state first, especially static IP, DNS, proxy, VPN, and managed-profile values. Interpret the evidence:

• APIPA / self-assigned address or no gateway → DHCP problem
• Can ping the gateway but names will not resolve → DNS problem
• Names resolve but one app fails → capture the app error and destination

The best CCST technician makes the engineer's next step obvious by recording accurate, layered observations rather than randomly toggling settings.

The Universal Five-Step Workflow

No matter which operating system is in front of you, the same five steps apply, and memorizing them is more valuable than memorizing any single command:

1. Interface - confirm the correct adapter is enabled and connected (wired, Wi-Fi, cellular, or VPN).
2. Addressing - read the IP, mask/prefix, gateway, DNS, and whether the address came from DHCP or was set statically.
3. Gateway - ping the default gateway to prove local Layer 3 connectivity.
4. DNS - resolve a known name (nslookup, resolvectl, or the host's resolver) to prove name resolution.
5. Application - test the actual service and capture the exact error if it fails.

Each step gates the next; there is no point testing DNS if the host has no gateway, and no point blaming an application if DNS never resolved its name.

Mobile Privacy Settings That Break Corporate Networks

Android and iOS introduce two privacy features that routinely cause tickets on managed networks, and the exam expects awareness of both. Private (randomized) MAC addresses present a different hardware address per SSID, which defeats MAC allow lists, captive-portal remembered devices, and DHCP reservations; the fix is usually to disable randomization for the corporate SSID or to register the randomized MAC. Private DNS and per-app VPNs can route name resolution or traffic outside the local network's resolver, so a device that joins Wi-Fi correctly still cannot resolve internal hostnames.

Add Mobile Device Management profiles, which can override DNS, install proxies, and pin certificate trust, and you have several ways for a perfectly associated device to fail. Always check these settings on a mobile endpoint before assuming the wireless network or server is at fault, and record their values so the engineer knows what policy is in effect.