CompTIA A+ 220-1101: How to Troubleshoot Wired and Wireless Network Problems

Introduction

When I coach CompTIA A+ candidates on network troubleshooting, I keep coming back to one idea: most network problems stop looking mysterious once you classify the symptom correctly. For 220-1101, nobody’s grading you on how well you can react when somebody bursts out with, “the internet is down.” Honestly, that phrase gets thrown around for everything from a bad cable to a DNS issue, so the trick is to stay calm and figure out what’s actually broken. You are being tested on whether you can separate no connectivity, limited connectivity, intermittent connectivity, and slow performance, then choose the best next step.

That matters because the same user complaint can point to very different causes. If a device has no link at all, my first thought is usually cable, port, dock, or adapter trouble. That’s where I’d start every single time before I go chasing anything fancier. When I see a 169.254.x.x address, I’m usually thinking DHCP failure or the device can’t reach DHCP anymore. A device that reaches IP addresses but not hostnames strongly suggests DNS trouble. A device that is “connected” to Wi-Fi but slow in one room may be dealing with weak signal, interference, congestion, or poor roaming. And sometimes the device is on the wrong network entirely, such as a guest SSID that intentionally blocks internal resources.

For the exam and for real support work, the goal is simple: define the symptom, isolate the fault domain, test the least invasive thing first, and only then make changes.

Official CompTIA A+ Troubleshooting Process

CompTIA A+ uses a 6-step troubleshooting model. Know the order, but also know how to apply it under pressure:

1. Identify the problem
2. Establish a theory of probable cause
3. Test the theory to determine cause
4. Establish a plan of action and implement the solution
5. Verify full system functionality and, if applicable, implement preventive measures
6. Document findings, actions, and outcomes

On the exam, “best next step” usually means the simplest test that gives you the most useful information without creating new variables. If the wired link is down, I’d check the cable, the port, and the adapter first. DNS is way down the list at that point. If Wi-Fi says it’s connected but websites still won’t load, I’d check gateway reachability and DNS before I even think about reinstalling drivers. If a desk move happened right before the outage, physical path issues should move to the top of your theory list.

Preventive measures matter too. After a fix, good support practice includes things like labeling jacks after moves, documenting bad ports, updating saved Wi-Fi profiles after SSID changes, and noting recurring dock or adapter failures.

Use a Layered Workflow Without Misusing the OSI Model

The OSI model is most useful as a troubleshooting map, not as a memorization exercise. For A+ network troubleshooting, think in this order:

• Layer 1: cable, radio, signal, physical connectivity, power
• Layer 2: link, MAC-level connectivity, switch behavior, VLAN membership clues, wireless association
• Layer 3: IP address, subnet mask, default gateway, routing
• Layer 4: TCP/UDP port reachability
• Layers 5–7: session/application behavior, browser access, service logon, name-based access, captive portals, proxies

That layered thinking helps you avoid bad assumptions. A successful ping does not prove the application works. ICMP might be allowed while TCP or UDP traffic is still blocked, so don’t let a good ping fool you into thinking everything’s fine. A browser failure does not always mean the network path is broken; it could be DNS, proxy settings, certificate problems, content filtering, or a captive portal.

Here is a practical decision flow:

• No link or no SSID visible: stay at physical/radio basics.
• Link is up but no valid IP: think DHCP, wrong VLAN, bad path, or adapter issue.
• Valid IP but cannot reach gateway: think local subnet, port, VLAN, or host firewall/path issue.
• Gateway reachable but no internet IP: think upstream routing, NAT, firewall, WAN, VPN, or ISP problem.
• Internet IP reachable but hostname fails: think DNS first.
• DNS works but browser still fails: think proxy, captive portal, certificate warning, application filtering, or service issue.

Troubleshooting Wired Network Problems

Wired problems are often easier to isolate because the path is more concrete: device, cable, wall jack, patch panel, switch port, uplink. The exam expects you to recognize common symptom patterns quickly.

Physical path failures

If there is no wired connection, start with the physical path. If you’ve got LEDs to look at, a missing link light is a really strong clue. That said, a lot of modern laptops are sitting on docks or USB Ethernet adapters, so you won’t always get a nice obvious NIC LED to help you out. In those cases, use the OS, dock indicators, or switch-side evidence if available.

Common physical causes include:

• Unplugged or damaged Ethernet cable
• Bad wall jack or bad termination
• Mispatched patch panel after a desk move
• Bad or disabled switch port
• Failed dock or USB Ethernet adapter
• Disabled NIC or bad NIC driver

A clean support workflow is to swap in a known-good patch cable, try a known-good port if allowed, bypass the dock if possible, and verify adapter status in Windows. If the laptop works on Wi-Fi but not through the dock, that is a strong clue that the dock, USB NIC, cable, or switch path is the problem rather than the whole system.

How to test the wired path end to end

For a desk-side outage, this sequence works well:

1. Check cable seating and visible damage.
2. Swap to a known-good patch cable.
3. Check whether the network adapter is enabled in Windows and visible in Device Manager.
4. Bypass the dock or USB adapter if the system allows it.
5. Test another known-good wall jack or switch port.
6. If available, verify patch panel to switch patching in the closet.
7. Use a cable tester if you suspect bad termination.

A cable tester can help identify open pairs, shorts, crossed pairs, or split pairs. That’s especially useful after office moves, renovations, or somebody’s homemade cable run that looked fine until it didn’t. It proves cable continuity and pairing, but it does not prove DHCP, switch configuration, or internet access.

DHCP, APIPA, and wrong network symptoms

If the link is up but the device shows 169.254.x.x on Windows, that usually means the host could not obtain a DHCP lease. At A+ level, treat that as a DHCP failure clue first. The root cause may be the DHCP service itself, a broken path to DHCP, a wrong VLAN, a disabled port, or a bad adapter.

At a support level, it helps to remember DHCP’s basic process: DORA — Discover, Offer, Request, Acknowledge. If that conversation fails anywhere, the client may self-assign a link-local IPv4 address instead of receiving a valid lease.

Useful Windows recovery commands:

ipconfig /release
ipconfig /renew
ipconfig /all

If /renew fails while another known-good device works on the same jack, suspect the endpoint or adapter. If multiple devices on the same area fail to renew, suspect infrastructure such as the switch port, VLAN assignment, DHCP scope, or relay path and escalate with evidence.

A wrong VLAN after a desk move can be especially deceptive. The device may get a valid IP address, but from the wrong subnet. That means “valid IP” does not always mean “correct network.” If the address range, gateway, or DNS servers do not match what that location should receive, document it and escalate.

Wrong subnet mask, gateway, and duplicate IP

These three create different patterns:

• Wrong subnet mask: some hosts that should be local appear unreachable or traffic is sent the wrong way.
• Wrong default gateway: local resources may work, but remote networks or the internet fail.
• Duplicate IP: intermittent access, conflict warnings, or unstable connectivity.

Duplicate IP issues are most commonly caused by static misconfiguration, rogue DHCP, overlapping scopes, or stale reservations, not just “DHCP made a mistake.” If you suspect a conflict, compare the affected client with a known-good client and, if needed, use:

arp -a

That will not solve the problem by itself, but it can help you view local IP-to-MAC entries and gather evidence before escalation.

Performance problems on wired links

“Slow network” is not one symptom. It might be latency, bandwidth limits, packet loss, or jitter—different problems, same complaint. On wired links, I’d look for bad cables, failing docks, overloaded links, driver issues, or speed and duplex negotiation problems. Duplex mismatch is more common on older or forced configurations; on modern Gigabit Ethernet, auto-negotiation is typically expected for proper operation.

If the problem is intermittent, ask whether it happens when the dock is touched, after sleep/wake, or only on one desk. Those clues often expose cable strain, USB power management, bad dock firmware, or a flaky port.

Troubleshooting Wireless Network Problems

Wireless troubleshooting is where “connected” can mislead you. A client can see the SSID, associate to the AP, authenticate successfully, and still fail later because of DHCP, captive portal restrictions, DNS, poor signal, or security policy.

Association vs authentication vs DHCP vs captive portal

Keep these stages separate:

• Association: the device joins the access point at a basic wireless level.
• Authentication: the device proves identity or matches the required security settings.
• DHCP/addressing: the client receives usable IP configuration after connecting.
• Captive portal/access control: the client is connected but still restricted until login or acceptance occurs.

That distinction helps with exam questions. If the SSID is visible but the password keeps failing, I’d think authentication first. If the device says it’s connected but doesn’t have a usable IP, think DHCP. If it has a valid IP but browsing redirects to a login page, think captive portal.

SSID, profile, and security issues

Common wireless connection failures include:

• Wireless adapter disabled or airplane mode enabled
• Wrong SSID selected
• Wrong saved password or stale profile
• WPA2/WPA3 mismatch
• PSK vs Enterprise mismatch
• Older client trying to join a WPA3-only SSID
• Hidden SSID configuration problems

On Windows, these commands can help:

netsh wlan show interfaces
netsh wlan show profiles

Use them to confirm signal, radio type, and saved wireless profiles. If needed, forget and rejoin the profile through the GUI or rebuild the saved profile. WPA3 transition mode can help mixed environments, but older clients may still fail on WPA3-only networks.

Also remember that the “wrong SSID” problem is not just a typo problem. A user might connect to a guest network that intentionally blocks internal printers, file shares, or domain services. That can look like “the network is broken” when the real issue is segmentation by design.

Bands, channels, and interference

At A+ level, know the practical tradeoffs:

• 2.4 GHz: longer range, more interference, fewer non-overlapping channels. In many regions, channels 1, 6, and 11 are the key non-overlapping choices.
• 5 GHz: higher throughput, less interference than 2.4 GHz, shorter range.
• 6 GHz: newer and less congested, but requires compatible hardware and is not universal in older environments.

Do not confuse weak signal with interference. Weak signal usually means distance, attenuation, or obstacles caused low RSSI. Interference means the signal may still be there, but performance is getting hammered because of poor signal-to-noise ratio or too much contention on the channel. Microwaves, Bluetooth, neighboring APs, and crowded channels can all reduce performance even when the client still shows “connected.”

If Wi-Fi is slow in one room only, compare performance in another location. If it improves dramatically, suspect attenuation, interference, channel congestion, or roaming behavior rather than a general ISP outage.

Core IP, DNS, and Service Troubleshooting

Most entry-level support mistakes happen when people skip the addressing and name-resolution checks. Keep your logic chain clean.

Useful IPv4 private ranges to recognize:

• 10.0.0.0/8
• 172.16.0.0–172.31.255.255
• 192.168.0.0/16

A common A+ environment is a /24 network, where a host like 192.168.1.25 with mask 255.255.255.0 expects the local gateway to be in 192.168.1.x. If the client receives 10.0.50.20 instead, that may indicate the wrong VLAN or rogue DHCP rather than a healthy lease.

DNS troubleshooting

If you can reach an IP address but not a hostname, DNS is the first suspect. But be careful, because that pattern strongly suggests DNS, but it doesn’t prove every browser problem is DNS. Modern websites may rely on correct host headers, encrypted session negotiation, redirects, or content filtering, so browser behavior can differ from ping behavior.

Useful commands:

nslookup example-hostname
```bash
nslookup example-hostname
nslookup internal-hostname 10.10.1.10
ipconfig /flushdns
```
ipconfig /flushdns

ipconfig /flushdns clears the local DNS resolver cache. It helps when the local cache is stale, but it does not fix a bad DNS server, wrong DNS assignment, or an upstream resolution outage.

Also watch for wrong DNS servers received from DHCP, manually configured DNS values, or suffix/search-domain issues that affect internal name resolution.

Localhost, gateway, and internet testing

A practical test order is:

1. Ping 127.0.0.1 if you need a quick local stack check
2. Check ipconfig /all
3. Ping the default gateway
4. Ping a known public IP if policy allows
5. Ping or resolve a hostname

Interpret results carefully. Failure to ping localhost points to a local stack, binding, or firewall/security issue, but it doesn’t automatically mean TCP/IP is broken. Failure to ping a public IP doesn’t automatically prove there’s no internet access, because ICMP might be blocked. Gateway success plus browser failure can still point to DNS, proxy settings, VPN routing, captive portal restrictions, or application-layer filtering.

Essential Commands and What They Really Tell You

Tracert example logic: if the first hop fails, start local. If the trace reaches the gateway and dies farther out, I’d suspect upstream routing, WAN, ISP, or filtering. Also remember that Windows tracert uses ICMP Echo, and some devices deprioritize or block those replies, so hop latency does not always equal application latency.

Netstat example: if a user says a local web service is down, netstat -an can help you see whether the host is listening on the expected port. That does not prove clients can reach it through the network, but it helps separate local service failure from path failure.

Security and Access Problems That Look Like Connectivity Problems

Not every “network issue” is accidental. Some symptoms are caused by security design or even malicious infrastructure.

• Rogue or evil twin SSID: user joins a lookalike network and loses expected access.
• Captive portal phishing: a fake or unexpected login page may be harvesting credentials.
• Rogue DHCP/DNS: clients receive valid-looking but incorrect gateway or DNS settings.
• Guest isolation: internet works, but internal printers and file shares are intentionally blocked.
• VPN/proxy changes: routing or DNS changes make local browsing fail or internal resources disappear.

For hybrid workers especially, VPN clients can change DNS and routing in ways that mimic local network failure. If the internet works before VPN but fails after VPN, or internal resources only work on VPN, that is a useful support clue rather than random behavior.

Scenario Walkthroughs

1. APIPA after plugging into a wall jack

Symptoms: Link appears up, but ipconfig /all shows 169.254.x.x and no usable gateway.

Best next steps: Swap cable, test known-good jack, run ipconfig /release and /renew, compare with a known-good client on the same area.

Likely causes: bad path to DHCP, wrong VLAN, disabled port, DHCP outage, bad adapter.

Escalation clue: if multiple users on the same area fail the same way, collect outputs and escalate as infrastructure.

2. Can ping a public IP but cannot browse by name

Symptoms: Gateway reachable, public IP reachable, hostname resolution fails.

Best next steps: run nslookup, verify DNS servers in ipconfig /all, use ipconfig /flushdns if appropriate.

Likely causes: wrong DNS server, DNS outage, stale local cache, VPN/DNS policy issue.

3. Wi-Fi slow only in one conference room

Symptoms: Connected to the correct SSID, but performance is poor only in one location.

Best next steps: compare signal and performance in another room, check band and signal details, ask whether many users are present, look for interference sources.

Likely causes: attenuation, congestion, interference, poor roaming, overloaded AP.

Exam Tips: What CompTIA Expects You to Recognize

Also remember these exam cautions:

• Successful ping does not prove application health.
• Failed ping does not always prove no connectivity.
• Valid IP does not always mean correct network.
• “Connected” does not guarantee internet access.

Best Next Step Drill

1. A user moved desks and now has no wired link. Best next step: test cable and jack before checking DNS.

2. A laptop joins Wi-Fi but gets 169.254.x.x. Best next step: verify association succeeded, then troubleshoot DHCP.

3. A user can print locally but cannot browse websites by name. Best next step: test DNS with nslookup.

4. A client gets a valid IP, but it is from the wrong subnet after a desk move. Best next step: document the unexpected IP/gateway and escalate likely VLAN or rogue DHCP issue.

5. A user says the internet is down, but only the browser fails; VPN was just enabled. Best next step: check VPN/proxy/DNS routing effects before replacing hardware.

Final Review

For CompTIA A+ 220-1101, strong network troubleshooting comes down to pattern recognition and disciplined sequence. Use the official 6-step process. Work from physical connectivity to link behavior to IP configuration to gateway reachability to DNS to application access. Recognize the high-yield clues: 169.254.x.x points to DHCP failure, IP works but hostname fails points to DNS, no link points to physical path or adapter issues, and Wi-Fi problems in one area usually point to signal, interference, or roaming.

Stay calm, test the least invasive thing first, and document what you found. That is how you pass the exam, and it is also how you become the support tech people trust when the user insists the whole network is down.