Exam Objective 1.6: Troubleshoot wired and wireless client connectivity (IP configuration, network reachability, and wireless security parameters on Windows, MacOS, and Linux).
This objective pulls together everything from the earlier 1.x topics — IP addressing, DHCP, wireless security — into a practical, client-facing troubleshooting skill. On the exam, expect scenario questions showing actual client OS output (ipconfig, ifconfig, wireless adapter status) and asking you to identify what's broken and which command would confirm or fix it. The three areas tested are IP configuration problems, general network reachability problems, and wireless-specific security parameter problems.
Whether wired or wireless, client connectivity problems are most efficiently diagnosed bottom-up through the OSI layers:
Physical/Link layer — Is the NIC enabled? Is the cable connected or is the wireless adapter associated to an SSID?
IP configuration layer — Does the client have a valid IP address, subnet mask, default gateway, and DNS servers?
Local reachability — Can the client reach devices on its own subnet (including the default gateway)?
Remote reachability — Can the client reach devices beyond its own subnet (the internet or other sites)?
Name resolution — Can the client resolve hostnames to IP addresses, even if raw IP connectivity works?
Working through these layers in order prevents wasted time — there's no point troubleshooting DNS if the client doesn't even have a valid IP address yet.
Windows:
ipconfig — quick view of IP address, subnet mask, and default gateway for each adapter
ipconfig /all — full detail including DNS servers, DHCP status, lease information, and MAC address
ipconfig /release then ipconfig /renew — releases the current DHCP lease and requests a new one, useful when a client is stuck with a stale, incorrect, or APIPA address
ipconfig /flushdns — clears the local DNS resolver cache, useful when a hostname was recently repointed to a new IP but the client is still using cached (stale) resolution data
MacOS:
ifconfig — displays interface configuration including IP address and status, though largely superseded by newer tools on recent macOS versions
System Settings/Preferences > Network — GUI view of the current IP configuration, DHCP vs. static assignment, and connection status
networksetup -getinfo [service name] — command-line way to view detailed configuration for a specific network service (e.g., Wi-Fi or Ethernet)
sudo dscacheutil -flushcache — clears the local DNS cache on macOS
Linux:
ip addr show (or the shorter ip a) — the modern replacement for ifconfig, displays IP addresses and interface status
ifconfig — still present on many distributions though considered legacy/deprecated in favor of the ip command suite
nmcli (NetworkManager command-line interface) — used on distributions running NetworkManager to view and control network connections
resolvectl status or systemd-resolve --status — displays DNS resolver configuration on systemd-based distributions
Exam Alert: You are not expected to be a full command-line expert on every OS, but you should recognize ipconfig /all (Windows), ifconfig / ip addr show (Linux/macOS), and know that release/renew or an equivalent action forces a fresh DHCP lease request.
APIPA address (169.254.x.x) — as covered in objective 1.3, this indicates the client could not reach a DHCP server and self-assigned a link-local address. The client can talk to other APIPA devices on the same physical segment but nothing else.
Incorrect static configuration — a client manually configured with the wrong subnet mask, gateway, or an address outside the correct subnet will show symptoms identical to a misconfigured router interface: partial or complete loss of connectivity depending on exactly what's wrong.
Stale DHCP lease / IP conflict after a lease change — a client that was disconnected for a long period, or moved between networks, may hold onto an IP configuration that's no longer valid for the network it's currently connected to; a release/renew resolves this.
Missing or incorrect DNS servers — connectivity to IP addresses works, but connectivity to hostnames fails; distinguishing this from a true reachability problem is a key troubleshooting skill (ping the IP directly to confirm the network path is fine, then ping the hostname to confirm whether DNS itself is the problem).
Disabled or disconnected network adapter — sometimes the simplest explanation is correct: the adapter itself may be administratively disabled in the OS, or physically disconnected (unplugged cable, Wi-Fi radio switched off), and no amount of IP-layer troubleshooting will help until the adapter itself is active.
ping — the fundamental Layer 3 reachability tool, available identically (with largely the same syntax) across Windows, macOS, and Linux. Best practice troubleshooting order:
Ping the loopback address (127.0.0.1) to confirm the local IP stack itself is functioning
Ping the client's own configured IP address to confirm the NIC and IP stack are bound correctly
Ping the default gateway to confirm local-subnet reachability
Ping a known-good remote IP address (not a hostname) to confirm routing beyond the local subnet
Ping a known-good remote hostname to confirm DNS resolution is also working
traceroute (Linux/macOS) / tracert (Windows) — shows the hop-by-hop path a packet takes to reach a destination, useful for pinpointing exactly which hop along the path is failing or introducing excessive latency, rather than just knowing that the destination overall is unreachable.
nslookup or dig — directly queries a DNS server to test name resolution independent of a ping test, useful for confirming whether a DNS problem is specifically a resolution failure versus a broader reachability failure.
Exam Alert: The ping progression (loopback, self, gateway, remote IP, remote hostname) is a core troubleshooting methodology tested both directly and embedded in scenario questions — know it as a sequence, not just as isolated facts.
Wireless adds an entire additional layer of potential failure points beyond what wired clients face, since a wireless client must first associate with an access point before any IP-layer troubleshooting is even relevant.
Checking wireless association status:
Windows — the network icon in the system tray, or Settings > Network & Internet > Wi-Fi, shows the currently connected SSID and signal strength; netsh wlan show interfaces provides detailed command-line output including SSID, signal percentage, radio type, and authentication/cipher in use
MacOS — holding the Option key while clicking the Wi-Fi menu bar icon reveals detailed information including RSSI, channel, and PHY mode; the same networksetup command-line tool can also query Wi-Fi-specific settings
Linux — nmcli device wifi list shows available SSIDs and their signal strength; iwconfig (legacy) or iw dev [interface] link (modern) shows current association details
Common wireless-specific problems:
Wrong SSID selected or SSID not visible — a client may be attempting to connect to (or auto-connect to) an incorrect or outdated SSID, especially after network infrastructure changes; a hidden SSID also requires the client to be manually configured with the exact network name since it won't appear in a normal scan.
Wireless security parameter mismatch — the client is configured for a different security protocol or passphrase than what the access point is actually using (for example, client configured for WPA2-Personal while the AP now requires WPA3-Personal or an 802.1X Enterprise login). This is one of the most common wireless connectivity failures and typically prevents association entirely rather than allowing a partial connection.
Expired or incorrect credentials in Enterprise (802.1X) mode — since Enterprise mode authenticates each user individually against a RADIUS server, an expired password, revoked certificate, or incorrect username will block that specific user while other users on the same SSID remain unaffected — a useful clue that the problem is user-specific rather than AP-wide.
Band-steering or client capability mismatch — some enterprise wireless deployments broadcast a single SSID across both 2.4 GHz and 5 GHz, using band-steering to push capable clients toward 5 GHz; occasionally a client's driver mishandles this and fails to associate properly, or associates on an unexpectedly weak band.
MAC filtering — if the wireless network uses MAC address filtering (allow-list or deny-list), a client with a MAC address not on the allow-list (or present on the deny-list) will be refused association regardless of correct credentials.
Captive portal issues — on networks requiring a captive portal login (common in guest wireless), a client may show as associated and even have a valid IP address, yet still be unable to reach the broader internet until the portal authentication step is completed in a browser.
Exam Alert: A wireless security parameter mismatch (wrong PSK, wrong security protocol type, or expired Enterprise credentials) is far more likely to be tested than an actual RF/hardware failure, since this objective specifically calls out "wireless security parameters" by name. Expect scenario questions where a client fails to associate and you must identify a security-configuration mismatch as the cause.
Symptoms more specific to wired clients:
Link light status directly indicates a physical/cabling problem (see objective 1.1)
Duplex/speed mismatch degrades a wired connection without breaking it outright
Symptoms more specific to wireless clients:
Association/authentication failures happen before any IP-layer troubleshooting is even relevant — a client that never associates will never get an IP address regardless of DHCP health
Signal strength (RSSI) and interference directly affect wireless performance in a way that has no wired equivalent
Roaming between access points (moving from one AP's coverage area to another while maintaining the same SSID) can introduce brief connectivity gaps that are normal in small amounts but disruptive if roaming is poorly tuned
Symptoms common to both:
IP configuration problems (APIPA, wrong static settings, DNS issues) behave identically once a wired link is up or a wireless client has associated
Reachability testing (ping progression, traceroute) works the same way regardless of the underlying media
Confirm the physical/link layer — for wired, check cable/link light; for wireless, confirm the client shows as associated to the correct SSID with reasonable signal strength.
For wireless specifically, confirm the security protocol and credentials configured on the client match what the AP/SSID actually requires.
Check the client's IP configuration (ipconfig /all, ifconfig, or ip addr show) for a valid address, correct subnet mask, and correct default gateway; watch specifically for an APIPA address.
If addressing looks wrong or stale, release and renew the DHCP lease.
Run the ping progression: loopback, self, gateway, remote IP, remote hostname, to isolate exactly which layer is failing.
If IP connectivity works but hostnames fail, focus on DNS server configuration and try flushing the local DNS cache.
For wireless, if IP configuration and DNS both look correct but browsing still fails, consider a captive portal requiring a login step.
If only one specific user/device is affected while others on the same network are fine, suspect device-specific misconfiguration, expired Enterprise credentials, or MAC filtering rather than an infrastructure-wide problem.
Q1. A Windows laptop shows an IP address of 169.254.45.12 after connecting to the wired network. What should be checked first?
A. The DNS server configuration
B. Whether the DHCP server is reachable from that network segment
C. The wireless security protocol
D. The default gateway's MAC address
Answer: B. A 169.254.x.x address is an APIPA address, indicating the client could not reach a DHCP server. The first troubleshooting step is confirming DHCP server reachability — whether the server itself is up, whether a relay/ip helper-address is correctly configured if the client is on a different subnet, and whether the local switchport/VLAN is correctly configured.
Q2. A user can successfully ping 8.8.8.8 but cannot browse to www.example.com. What does this indicate?
A. The default gateway is misconfigured
B. The client has an APIPA address
C. DNS resolution is failing while general IP reachability is working
D. The wireless security parameters are mismatched
Answer: C. Successfully pinging a remote IP address confirms that routing and general reachability are functioning correctly. The failure to reach a hostname points specifically to a DNS resolution problem rather than a broader connectivity issue, since the underlying IP path has already been proven to work.
Q3. A wireless client fails to associate with an SSID that recently had its security settings changed by the network administrator. Other users report the same issue. What is the most likely cause?
A. A duplicate IP address conflict
B. The client is configured for an outdated or mismatched wireless security protocol/passphrase
C. The client's DNS cache is stale
D. The access point's MAC address changed
Answer: B. Since multiple users are affected right after a security-setting change, and the failure occurs at the association stage (before any IP-layer issue would even be relevant), a mismatch between the client's configured security protocol/passphrase and the AP's current requirement is the most likely cause.
Q4. Which command would a Windows user run to force the release and renewal of a DHCP-assigned IP address?
A. ipconfig /flushdns
B. ipconfig /release followed by ipconfig /renew
C. netsh wlan show interfaces
D. tracert
Answer: B. ipconfig /release releases the current DHCP lease, and ipconfig /renew requests a fresh lease from the DHCP server. This is the standard fix for a client stuck with a stale or incorrect IP configuration, including an APIPA address caused by a temporary DHCP outage that has since been resolved.
Q5. A single user on an 802.1X Enterprise wireless network cannot connect, while all other users on the same SSID connect normally. What is the most likely explanation?
A. The access point's channel is misconfigured
B. That specific user has expired or incorrect credentials being validated against the RADIUS server
C. The SSID is broadcasting on the wrong band
D. A duplicate IP address exists on the network
Answer: B. In 802.1X Enterprise mode, each user authenticates individually against a backend RADIUS server. A problem affecting only one user, while everyone else on the same SSID connects fine, points to that individual's credentials (expired password, revoked certificate, incorrect username) rather than an infrastructure-wide issue like channel or SSID configuration.
Q6. What is the correct order of the standard ping-based troubleshooting progression for verifying client connectivity?
A. Default gateway, loopback, remote IP, remote hostname
B. Loopback, self IP address, default gateway, remote IP, remote hostname
C. Remote hostname, remote IP, default gateway, loopback
D. Self IP address, remote hostname, loopback, default gateway
Answer: B. The standard progression starts with the loopback address (127.0.0.1) to confirm the local IP stack works, then the client's own IP to confirm the NIC/stack binding, then the default gateway to confirm local-subnet reachability, then a remote IP address to confirm routing beyond the subnet, and finally a remote hostname to confirm DNS resolution is also functioning. This order isolates failures layer by layer rather than jumping straight to the most complex test.