Diagnose and resolve wireless and wired network issues using layered troubleshooting. Master ipconfig, ping, and DNS commands every help desk tech needs to know.
Network connectivity is one of the most common issues you will troubleshoot. The key is knowing where in the stack the failure lives — a physical cable problem looks different from a DHCP failure, which looks different from a DNS outage. Jumping straight to "reinstall the driver" wastes everyone's time.
Most connectivity issues at Tier 1 fall into one of four buckets: physical layer problems, IP addressing failures, gateway/router issues, or DNS failures. The OSI model gives you a framework to test each layer methodically.
| Layer | What It Controls | Common Failure Signs | First Test |
|---|---|---|---|
| Physical (L1) | Cable, NIC, Wi-Fi radio | No link light, "unidentified network" | Reseat cable / toggle Wi-Fi |
| Data Link (L2) | MAC address, switch port | Connected but no internet | Check adapter in Device Manager |
| Network (L3) | IP address, routing, DHCP | 169.254.x.x APIPA address | ipconfig /all |
| Transport (L4) | TCP/UDP ports | Some apps work, others don't | Firewall / port check |
| Application (L7) | DNS, HTTP, app protocols | Browser says "server not found" | ping 8.8.8.8 then nslookup |
Every device on a network needs an IP address to communicate. When you run ipconfig you will see an IPv4 address, subnet mask, and default gateway. Understanding these three values tells you a lot about the problem.
IP starts with 10.x.x.x, 172.16–31.x.x, or 192.168.x.x. Gateway is populated. Device has a lease from the DHCP server.
HealthyIP starts with 169.254.x.x. Windows assigned this when DHCP failed. No gateway means no internet — DHCP is the problem.
DHCP FailedManually set by IT or user. Can cause conflicts if the wrong address is used, or no internet if gateway is wrong.
Check ConfigMany techs see an APIPA address and assume the network is down. The physical connection may be fine — Windows just cannot reach the DHCP server to get an address. Always run ipconfig /release and ipconfig /renew first before escalating.
Wired connections are binary — either the cable works or it doesn't. Wi-Fi has more variables: signal strength, band selection, authentication, driver issues, and interference all play a role.
| Cause | Symptom | Fix |
|---|---|---|
| Wrong password / bad profile | Authentication failed, can't join | Forget network, reconnect fresh |
| Driver outdated or corrupt | Adapter missing from Device Manager | Reinstall driver via Device Manager |
| IP conflict | Connected but limited access | ipconfig /release, /renew |
| DNS misconfigured | Ping by IP works, browser fails | Set DNS to 8.8.8.8 or flush DNS cache |
| Router / AP issue | All devices on network affected | Reboot router; escalate if persistent |
| Wi-Fi disabled in BIOS/settings | No adapter visible in OS | Check Fn key, Device Manager, BIOS |
| Captive portal not completed | Connected to Wi-Fi but no internet | Open browser, complete login page |
These five commands handle 90% of Tier 1 network troubleshooting. Run them in order — it's a systematic test from the inside out.
| Command | What It Does | What to Look For |
|---|---|---|
ipconfig /all | Shows full IP config for all adapters | IP address, gateway, DNS servers, DHCP enabled |
ipconfig /release | Releases current DHCP lease | Run before /renew when APIPA appears |
ipconfig /renew | Requests a new IP from DHCP server | Should get a valid 10.x or 192.168.x address |
ipconfig /flushdns | Clears DNS resolver cache | Fixes stale or corrupt DNS entries |
ping 8.8.8.8 | Tests connectivity to Google DNS by IP | If this works but browser fails, DNS is broken |
ping google.com | Tests DNS resolution | If this fails but ping 8.8.8.8 works, DNS issue confirmed |
nslookup google.com | Queries DNS server directly | Confirms DNS server address and resolution |
netsh wlan show profiles | Lists saved Wi-Fi profiles | Find corrupt profiles to delete |
Ping 127.0.0.1 first (loopback) → confirms TCP/IP stack works. Then ping gateway (from ipconfig) → confirms local network. Then ping 8.8.8.8 → confirms internet. Then ping google.com → confirms DNS. Each step narrows down the layer where the failure lives.
Use this procedure for any ticket where a user reports inability to access the internet, network shares, or company resources. Work from Layer 1 upward. Document every command output.
Ask: Is this one device or multiple? Wired or wireless? Does anything work (can they ping the gateway)? What changed recently? If multiple devices are affected, the problem is likely the router or ISP — escalate immediately rather than chasing individual devices.
For wired: confirm link light is on at both ends of the cable. Try a different cable and a different port on the switch. For wireless: confirm Wi-Fi is enabled (check the Fn key, airplane mode toggle, and Device Manager). Look for yellow exclamation marks on the adapter.
Open Command Prompt and run ipconfig /all. Check: Does the adapter have a valid IP (not 169.254.x.x)? Is the Default Gateway populated? Are DNS servers listed? Screenshot the output for your ticket notes.
If the IP is 169.254.x.x or missing: run ipconfig /release followed by ipconfig /renew. Run ipconfig /all again to confirm a valid address was obtained. If still no valid IP, move to step 5.
Run: ping 127.0.0.1 (loopback) → ping [gateway IP] → ping 8.8.8.8 → ping google.com. The first step that fails tells you the layer. If ping 8.8.8.8 works but google.com fails, DNS is broken. Document exactly which step failed.
Run ipconfig /flushdns. Then run netsh int ip reset and netsh winsock reset in an elevated Command Prompt. Restart the computer after winsock reset — it will not take effect without a reboot.
For wireless issues: go to Settings → Network & Internet → Wi-Fi → Manage known networks. Select the network and click Forget. Reconnect fresh with the correct credentials. This clears any corrupt profile or cached bad password.
Open Device Manager. Expand Network Adapters. Right-click the Wi-Fi or Ethernet adapter → Update driver. If device has a yellow exclamation: right-click → Uninstall device → reboot. Windows will reinstall the driver automatically. If that fails, download the driver from the OEM website.
| Command | Purpose | Expected Output |
|---|---|---|
ipconfig /all | Full IP configuration | IP, subnet, gateway, DNS, DHCP state |
ipconfig /release | Drop DHCP lease | IP address cleared |
ipconfig /renew | Get new DHCP lease | New valid IP assigned |
ipconfig /flushdns | Clear DNS cache | "Successfully flushed the DNS Resolver Cache" |
ping 127.0.0.1 | Test TCP/IP stack | 4 replies with 0ms latency |
ping 8.8.8.8 | Test internet (no DNS) | Replies confirm internet access |
ping google.com | Test DNS resolution | Resolves to IP and replies |
nslookup google.com | Query DNS directly | Returns DNS server and IP for domain |
netsh winsock reset | Reset network stack | "Winsock reset completed" (reboot required) |
Fill in this ticket template for Scenario 01 above. Good documentation is what separates professional techs from hobbyists.
| Field | Your Entry |
|---|---|
| User Reported | |
| Initial Findings | |
| Root Cause | |
| Steps Taken | |
| Resolution | |
| Verification |
"Walk me through how you would troubleshoot a computer that is connected to Wi-Fi but can't access the internet."
Start by scoping the issue — is it one device or many? If multiple, the problem is likely the router or ISP. For a single device, I run ipconfig /all to check the IP address. An APIPA address (169.254.x.x) means DHCP failed, so I run /release and /renew. Once a valid IP is confirmed, I run a layered ping test — gateway first, then 8.8.8.8, then google.com. If 8.8.8.8 succeeds but google.com fails, I flush DNS with ipconfig /flushdns. If everything pings but the browser still fails, I check proxy settings. I document every command and output in the ticket.
"What does a 169.254.x.x IP address mean and how do you fix it?"
A 169.254.x.x address is an APIPA address — Automatic Private IP Addressing. It means Windows tried to get a DHCP lease and couldn't reach the DHCP server, so it self-assigned a fallback address. The fix is to run ipconfig /release to drop the current state, then ipconfig /renew to request a new lease. If it persists, I check the physical connection and look at whether other devices on the same network can get IPs — if not, the DHCP server itself may be down, which means escalation.
"What is the difference between pinging 8.8.8.8 and pinging google.com, and why does that distinction matter?"
Pinging 8.8.8.8 tests internet connectivity without using DNS — it goes directly to Google's DNS server by IP. Pinging google.com requires DNS resolution first, converting the name to an IP, then sending the ping. If 8.8.8.8 works but google.com fails, DNS is broken even though the internet connection itself is fine. This matters because many users think "the internet is down" when actually their TCP/IP works perfectly — they just have a DNS issue, which is a much faster fix than a connectivity problem.