Diagnosing a Connectivity Scenario

Restart the computer. Restart the router. Restart everything. Hope. That's not a troubleshooting method — it's a coin flip with extra steps. Restarting can be a legitimate action, but if you restart before understanding the problem, you may destroy the evidence that would have told you what actually broke.

Start with the symptom

"It doesn't work" isn't a symptom — it's a shrug. The first real question is: what exactly doesn't work? The game doesn't launch. The game launches but doesn't log in. Websites don't load. Voice fails. All network access fails. Only one workstation fails. These are all genuinely different symptoms, and each one points somewhere different.

Symptom versus cause

The symptom — "game cannot connect" — is what you observe. The cause could be the application, the account, the computer's configuration, the local network, DNS, the router, the internet, or the remote service. Don't confuse the two; a symptom is a starting point, not an explanation.

Troubleshooting is elimination

Eight possible causes. One test eliminates three. Another eliminates two more. A third narrows what's left. Eventually one explanation fits the evidence better than any other — which is a completely different process than clicking random settings until something changes.

Start wide: how large is the failure?

One device? Think local — that workstation, its cable, its configuration, its account, its port.

Several nearby devices? Think shared dependency — a switch, a shared connection, a network segment.

Everyone? Think further upstream — the router, the internet connection, a shared service. But don't assume; test it.

This is a clue, not a rule. If one computer fails, could a remote service still be involved somehow — say, that specific account hitting a service-side issue? Sure, possibly. Systems are messy, and scope gives you a starting point, not a guarantee.

The first question worth asking: what still works?

A student reports the game doesn't connect. Does the computer turn on? Yes. Does the operating system work? Yes. Can it open local applications? Yes. Can it reach another local device? Maybe. Can it reach a website? Maybe. Can another station reach the game? Maybe. Every answer reshapes the hypothesis a little.

The troubleshooting ladder

Nine steps: observe, define scope, check simple dependencies, test, compare, narrow, act, verify, document.

Observe. Not "internet bad." Instead: "PC-04 launches the game but can't reach login while PCs 01-03 can." Specific and useful.

Define scope. Who's affected — one station, one section, the whole lab, only one service?

Check simple dependencies. Power, cable, connection, correct network, device enabled. Don't overcomplicate before ruling out the obvious.

Test. A good test answers a question — for example, "can this computer reach another known-working service," or "is all network connectivity failing, or only the game service?"

Compare. Compare the failing system with something that still works. This is one of the most useful moves available: failing PC versus working PC — what's actually different between them?

If PC-01 works and PC-02 doesn't, and they share a router, internet connection, and service, that makes those shared components somewhat less suspicious — not impossible, just less suspicious than they were before the comparison.

Narrow. Remove hypotheses the evidence doesn't support.

Act. Only now do you actually change something — reconnect a cable, correct a setting, restart a specific application, swap a known-good peripheral, or escalate a service outage.

Verify. Don't stop at "looks fixed" — test the original function. If the problem was "cannot join match," then join a match.

Document. Record the symptom, the test, the result, the cause, the action, and the verification. Future you (or the next technician) will need it.

Scenario 1

PC-06 can't access any network service; other PCs work fine. Test: move the Ethernet cable from PC-06 to a known-good laptop. The laptop also fails on that cable. What did we learn? The problem probably isn't PC-06 — the likely focus shifts to the cable, the switch port, or the upstream path tied to that connection.

Scenario 2

Every PC can browse websites, but nobody can log into the game. Test: check official service status, which reports an authentication outage. Do you restart every computer? No — the problem is remote, and restarting local machines wouldn't touch it.

Scenario 3

PC-02 can reach websites, the game works, but voice chat doesn't — while other students' voice works fine. The scope here is already very narrow: microphone, audio input, voice application, or permissions/settings. This might not be a network problem at all.

Scenario 4

Six computers suddenly lose connectivity, all six connected through Switch-A; stations on Switch-B still work. The strongest clue is the shared dependency: Switch-A or something upstream of it specifically.

Scenario 5

A PC can reach a fictional service by IP address but not by name, while other stations work normally. DNS becomes the natural suspect.

Scenario 6

All stations reach local resources fine, but no station can reach anything external. Local is functioning; the external path is failing somewhere further upstream — router status becomes a reasonable next test.

Don't overclaim

A cable swap fixes the problem — can you now conclude the original cable had definitely failed internally? Maybe, but another real possibility is that the original cable simply wasn't seated correctly. Document what the evidence actually supports, not the most technical-sounding explanation available.

Hypothesis board

Build a table with rows for PC hardware, cable, switch port, router, DNS, and remote service, and columns for evidence for, evidence against, and next test. This is a much stronger foundation than guessing.

The minimum-change rule

When testing, change one meaningful thing at a time whenever practical. If you swap the cable, the switch port, the settings, the application, and the account all at once and it starts working — what actually fixed it? No idea, and you've learned nothing useful for next time.

This is the same experimental thinking from Weeks 5, 6, and 10: hypothesis, test, observation, revision. It keeps showing up because it works.

Diagnostic challenge

Symptom: PC-04 cannot connect to the game. You may choose only three tests from: check whether other PCs work, check website access, check local network access, check game service status, swap the cable, check the account on another PC, or restart everything. Which three give you the most information, and in what order? Defend your sequence — that's the real challenge, not picking the "right" three tests in isolation.

Before you leave

Complete: the most useful troubleshooting question is not "what should I restart?" It is __________. Explain how that question actually narrows the system.

Source note

This lesson implements Middle Township Unit 5 expectations around system reliability, network relationships, maintenance, repair, and systematic evaluation of integrated systems.

The troubleshooting ladder, failure-scope model, known-good comparison, hypothesis board, and diagnostic scenarios are original Robotnix Academy instructional components.