Network Troubleshooting pt.1

A user reports that the Wi-Fi drops a few times an hour, web pages load slowly, and their voice calls sound choppy. In a help desk role, you can't guess, you need a method that links each symptom to a likely cause, then confirms it with safe tests.

CompTIA A+ 220-1101 Objective 5.5 focuses on troubleshooting network issues by spotting common symptoms and narrowing the fault domain (client, access point, switch, router, ISP, or the path between). That includes intermittent wireless connectivity, slow network speeds, limited connectivity, jitter, and poor Voice over Internet Protocol (VoIP) quality. Each points to different root causes, such as weak signal, interference, congestion, bad cabling, DNS problems, duplex mismatch, or buffer issues.

This post frames those symptoms the way the exam expects, while keeping it practical for real tickets. You'll use a repeatable flow: identify, isolate, test, fix, verify, and document. By the end, you should be able to choose the next best step quickly, avoid risky changes, and explain your results in clear support notes.

Start with a fast triage checklist so you don't chase the wrong problem

When a user says "the network is bad," the real issue could be Wi-Fi signal, congestion, DNS, or the ISP. If you jump to fixes too fast, you can waste time or break something that worked. A short triage flow keeps you focused on what changed, who is affected, and where the problem lives (device, local network, or internet).

Use this section as your first pass. The goal is not perfection. The goal is to narrow the fault domain quickly, then run one or two safe tests that confirm your direction.

Rule of thumb: If you can't describe the pattern, you can't pick the right next test.

Ask the right questions and spot patterns in the symptoms

Start by turning a vague complaint into a clear pattern. Patterns point to causes, and causes suggest the next test. Keep questions short, and listen for details like timing, location, and what recently changed.

Focus on four high-value splits:

Time of day
- If issues happen at lunch or after school, suspect peak-hour congestion or an overloaded access point.
- If drops happen every few minutes, suspect roaming, interference, or power-saving behavior on the client.
One user vs many users
- If only one user has jittery calls, the issue often sits on the device, its Wi-Fi adapter, or its location.
- If many users complain at once, suspect the AP, router, switch uplink, or ISP.
One app vs all apps
- If only web browsing fails but chat works, suspect DNS (name lookup) or a browser proxy setting.
- If streaming is fine but VoIP is choppy, suspect jitter, packet loss, or Wi-Fi contention.
One room vs the whole building
- If the problem stays in one conference room, suspect weak signal, physical obstacles (metal shelving, elevator shafts), or local interference.
- If the whole floor struggles, suspect the AP placement, channel overlap, or backhaul saturation.

Also ask what happened right before the problem started. Changes create clues:

New router or access point: Wrong channel plan, poor placement, or old firmware.
OS update or driver update: Wi-Fi adapter driver regression, changed power settings.
VPN installed or enabled: Slow speeds, blocked local resources, DNS changes.
New "smart" devices added: More airtime use, more interference, more DHCP leases.

Quick examples help you map symptom to likely cause:

"Wi-Fi drops when walking between offices" often points to roaming between APs with weak overlap or different security settings.
"Sites take long to start loading, then load fast" often points to DNS delays.
"Signal bars look low in one corner" often points to weak signal or an AP hidden behind walls.

Check the basics first: power, cables, lights, and known-good tests

Basic checks feel simple, yet they solve a large share of tickets. They also protect you from chasing "advanced" causes when the real issue is a loose cable or a hung modem.

Start with physical status:

Confirm the modem, router, and access point have power. Look for fans, heat, and stable LEDs.
Check link lights on the router, switch, and wall jack. No light often means no physical connection.
If you see odd light patterns (rapid blinking, red status), compare them to the vendor's label or quick guide.

Next, use known-good methods. These reduce guesswork:

Swap in a known-good Ethernet cable. A damaged cable can cause slow speeds, drops, or duplex negotiation issues.
Try a different switch port or router LAN port. A single bad port can mimic bigger outages.
Test with a known-good device (a working laptop or phone). If the known-good device works on the same network, the original device becomes the prime suspect.

Then do safe resets in a clean order. Power-cycling works best when you restore the path from the internet inward:

Power off the modem and router (and separate AP, if used).
Power on the modem first, then wait for it to fully sync.
Power on the router next, then wait for WAN and LAN to come up.
Power on the AP last, then confirm SSID broadcast and client joins.

On the client side, use quick wireless resets before deeper changes:

Toggle airplane mode on, wait a few seconds, then off.
Forget the Wi-Fi network and re-join it, then re-enter the password carefully.
Confirm the user joined the correct SSID (staff vs guest networks often look similar).
If available, temporarily turn off and re-enable the Wi-Fi adapter.

Gotcha: "Connected, no internet" often comes from joining the wrong SSID, a captive portal, or a stale DHCP lease, not a dead ISP link.

Prove where the failure is: device, local network, or the internet

After the basics, move to isolation. You want to answer one question: is the failure on the device, inside the local network, or upstream on the internet? You can prove this with a few fast comparisons, without advanced tools.

Start with local versus internet access:

Try an internal resource (printer web page, file share, internal website). If internal works but external sites fail, suspect ISP, DNS, or firewall rules.
Try a well-known external site by name. If it fails, try by public IP. If IP works but names fail, suspect DNS.

If you can run simple commands, keep them optional and plain:

ping <gateway> checks whether the device can reach the local router. Failure suggests a local Wi-Fi or LAN problem.
ping 8.8.8.8 (or another public IP) checks internet reachability without DNS. Failure suggests an upstream issue.
ping <known internal server> helps confirm local routing.

Comparative tests are often faster than commands:

Wired vs wireless: If Ethernet is stable but Wi-Fi drops, focus on signal strength, interference, channel overlap, or AP load. If both are bad, focus on router, switch, DHCP, or ISP.
Same Wi-Fi, different device: If a second device works fine on the same SSID in the same room, the first device likely has a driver, configuration, or hardware issue.
Cellular hotspot test: If the problem device works fine on a phone hotspot, the issue is probably in the local network, not the device's apps.

Interpret results in simple terms:

Can't reach gateway: local link problem (Wi-Fi association, weak signal, wrong password, bad cable, bad port, or adapter issue).
Can reach gateway but not public IP: router WAN issue, modem sync issue, ISP outage, or upstream routing problem.
Public IP works but websites fail: DNS server issue, wrong DNS settings, or VPN forcing DNS elsewhere.
Only VoIP is poor: likely jitter, packet loss, or Wi-Fi contention, not "no internet."

These quick splits keep your next step targeted, which matters on both the exam and real tickets.

Document what you changed and verify the fix

Troubleshooting without notes is like trying to retrace steps in the dark. Documentation prevents repeat work, supports escalation, and protects you when a "fix" later causes side effects. It also helps the next technician avoid repeating the same tests.

Write down changes as you make them. Even small actions matter, like swapping a cable or forgetting a network. Then verify success using the same test that failed. If the user complained about choppy calls, don't stop at "Wi-Fi connected." Make a test call. If the issue was slow speeds, run the same speed test method used earlier, ideally from the same spot.

Use verification that matches the symptom:

Slow speeds: run a speed test on the same device, same connection type (wired or Wi-Fi), and similar time of day.
Wi-Fi drops: stay connected for a set window (for example, 10 to 15 minutes), then watch for disconnects while moving as the user moves.
Limited connectivity: confirm a valid IP address, gateway, and DNS, then open a few known sites.
Jitter or poor VoIP: place a short VoIP call and listen for gaps, delays, or robotic audio.

Record a short, repeatable set of facts. These are the details that make tickets actionable:

Time and date, plus duration of the issue
Location (room, floor, or nearest AP, if known)
SSID and whether it was staff or guest Wi-Fi
Signal indicator (bars or percentage) and whether the user was moving
IP details (IP address range, default gateway, DNS servers) when relevant
Steps tried, in order, and what changed
Outcome, including how you verified the fix

Clear notes turn a one-off fix into a reusable playbook. Just as important, they give you a baseline if the problem returns.

Intermittent wireless connectivity, why Wi-Fi drops and how to pin down the cause

Intermittent Wi-Fi drops feel random, yet they usually follow a pattern. The key is to separate link problems (signal, interference, roaming) from network problems (DHCP, IP conflicts) and client problems (drivers, power saving, security). Once you label the pattern, you can test one variable at a time and avoid "fixes" that only mask the issue.

A practical approach is to observe when the drop happens (movement, peak hours, microwave use), then confirm whether the device loses Wi-Fi association or only loses internet access. Those two outcomes point to different root causes.

Signal and interference problems you can spot in minutes

Many "Wi-Fi drops" start with simple physics. Distance reduces signal strength, and obstacles absorb or reflect radio energy. Drywall weakens a signal a bit; brick, concrete, and tile weaken it more. Metal is worse because it reflects and blocks, so filing cabinets, elevator shafts, and ductwork can create dead zones. Even the user's body can attenuate signal, especially at 5 GHz and 6 GHz.

Interference adds another layer. The 2.4 GHz band travels far, but it is also crowded. Microwaves, older cordless phones, and many nearby routers compete for the same airtime. Bluetooth usually causes only minor interference because it hops frequencies, yet it can still contribute in dense environments (for example, conference rooms full of headsets).

Start with checks that take minutes and don't require admin access:

Move closer to the access point (AP): If drops stop within a few meters, suspect weak signal or obstruction, not DHCP or DNS.
Rotate or reposition the device: A small change can shift the antenna pattern and improve stability.
Check signal strength (RSSI) if available: Many clients show RSSI in dBm. As a rough guide, stable use often needs about -67 dBm or better. Voice and video usually need stronger and steadier signal.
Switch bands when possible: Try 5 GHz or 6 GHz for less congestion and higher throughput. If 5 GHz drops but 2.4 GHz holds, range or obstruction may be the issue.
Change the Wi-Fi channel: On 2.4 GHz, prefer 1, 6, or 11 to reduce overlap. On 5 GHz, avoid sitting on the same channel as nearby APs.
Relocate the AP: Place it higher, away from metal, and closer to users. Avoid hiding it in a cabinet or behind TVs.

If a user reports drops only when the microwave runs, treat it as interference first, not a "bad router."

Roaming and band steering issues that look like random drops

Roaming problems often appear "random" because the user triggers them by moving, even slightly. This is common in homes with extenders and mesh systems, and it is also common in offices with many APs. In both cases, the device decides when to leave one AP and join another. If that handoff goes poorly, the user sees a brief disconnect, app timeouts, or a call that cuts out.

A classic sign is drops that line up with movement. For example, the connection fails when walking from a desk to a conference room, or when moving between floors. Another sign is a "sticky client." The device stays connected to a far AP with weak signal, even though a nearer AP is available. Band steering can add confusion because the network nudges the client between 2.4 GHz and 5 GHz. Some clients handle that well; others bounce between bands and appear unstable.

Look for these practical indicators:

Drops at the same doorway or hallway: That often marks an overlap or coverage gap.
Good signal bars, yet brief disconnects: That can happen during a handoff, especially for real-time apps.
Problems started after adding an extender: Many low-cost repeaters add latency and can destabilize roaming.

Fixes focus on consistency and coverage design:

Update firmware on the router, mesh nodes, and APs. Roaming improvements often ship in updates.
Use consistent SSID and security settings across APs (same SSID, same WPA mode, same password). Mixed settings can break fast reassociation.
Adjust AP placement to create clean overlap. Too little overlap causes drops; too much overlap causes clients to cling to the wrong AP.
Reduce channel overlap by planning channels across nearby APs. If adjacent APs share the same channel, clients fight for airtime.
Avoid cheap repeaters when possible. A wired backhaul AP or quality mesh node usually behaves better.

In exam terms, think of roaming issues as a coverage and configuration problem, not an internet problem.

DHCP, IP conflicts, and lease problems that break Wi-Fi even with a strong signal

Sometimes Wi-Fi stays connected, signal looks strong, and the user still loses access. That points away from RF conditions and toward addressing. DHCP assigns IP settings, including the IP address, default gateway, and DNS servers.