Week 09 · lesson
Lesson 4: Complete Network Symptom Lab
A network can fail completely.
It can also remain technically connected while becoming unstable, slow, delayed, noisy, or unusable for one specific application.
Those cases are harder because the user may still say the same thing:
"The network is bad."
Today we work the full symptom set as evidence patterns, not vocabulary.
All stations use supplied or simulated evidence. No live scanning, packet capture, credential testing, or school-network changes are required.
Station 1: intermittent wireless connectivity
Evidence:
association: drops several times per hour
signal: fluctuates sharply
wired clients on same network: stable
neighboring-channel activity: highStronger theories include interference, marginal coverage, client or AP radio behavior, and channel design.
A complete provider outage becomes weaker because wired clients stay healthy.
Useful evidence includes supplied Wi-Fi analyzer data, AP or client logs, location comparisons, and channel or band information.
Station 2: slow network speed
"Slow" can come from several places:
endpoint resource limits
negotiated link speed
Wi-Fi congestion
local network saturation
high latency
remote service bottleneck
provider pathCompare local and remote behavior.
If a large local transfer is fast while one remote site is slow, the evidence points away from the local Ethernet path.
If every local and remote transfer from one client is slow while nearby clients are normal, the problem may be client-specific.
Scope is evidence.
Find a wrong default gateway
Local addressing and the router interface work, but the default route points to the wrong subnet. Use route evidence, correct one simulated value, and verify remote reachability.
Ghostty Web renders the terminal, but this lesson still uses a controlled Robotnix command engine. No unrestricted operating-system shell is connected.
ip addrip routeping -c 2 192.168.10.1ping -c 2 203.0.113.10ip route replace default via 192.168.10.1
Read a deterministic terminal transcript
This fallback runs the same bounded Robotnix simulation against the suggested command sequence. It does not connect to an operating-system shell or network.
Robotnix gateway diagnosis simulation
All addresses are documentation/simulated values. No packets leave the browser.
$ ip addr
2: eth0: <UP> mtu 1500
inet 192.168.10.25/24 brd 192.168.10.255
$ ip route
default via 192.168.20.1 dev eth0
192.168.10.0/24 dev eth0 scope link
$ ping -c 2 192.168.10.1
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.7 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.8 ms
$ ping -c 2 203.0.113.10
From 192.168.10.25 icmp_seq=1 Destination Host Unreachable
2 packets transmitted, 0 received, +1 errors, 100% packet loss
$ ip route replace default via 192.168.10.1
Default route replaced in simulated state.Station 3: limited connectivity
Evidence:
Wi-Fi association: good
IPv4: valid
same-subnet printer: reachable
gateway: unreachableThe client is not offline.
It has local connectivity.
The failure begins at the gateway boundary.
Station 4: jitter and poor VoIP quality
Real-time voice and video care about more than average bandwidth.
Jitter is variation in packet delay.
packet 1: 20 ms
packet 2: 22 ms
packet 3: 95 ms
packet 4: 24 ms
packet 5: 120 msThe connection may move plenty of data overall while irregular arrival timing damages real-time audio.
Symptoms can include choppy audio, gaps, robotic speech, and unstable call quality.
A speed-test number alone can miss this problem.
Station 5: port flapping
Supplied switch log:
14:01:02 port 8 up
14:01:19 port 8 down
14:01:24 port 8 up
14:01:41 port 8 downThe link repeatedly transitions between states.
Possible boundaries include damaged cable, loose connector, failing NIC, failing switch port, physical movement, or power instability.
Do not change DNS while the physical link is repeatedly disappearing.
Station 6: high latency
Evidence:
gateway: 1 ms
provider edge: 12 ms
remote service: 240 msConnectivity exists.
Response time is high toward the remote end.
Useful questions:
- Is the delay consistent?
- Does it begin at a particular path segment?
- Do multiple remote services show it?
- Do local services remain fast?
Latency is a timing problem. Treat it like one.
Station 7: external interference
Evidence:
signal: strong
association: stable
wired uplink: healthy
performance: degrades when nearby interfering source is activeA strong signal does not mean clean spectrum.
The Wi-Fi analyzer data becomes useful because the failure concerns radio conditions, not missing IP configuration.
Station 8: authentication failure
Evidence:
SSID: visible
radio association process: reaches authentication stage
credentials/policy: rejected in supplied fictional logThe radio exists.
The client reached an identity or policy boundary.
Do not diagnose signal strength when the system is explicitly rejecting authentication.
Possible categories include wrong credentials, expired credentials or certificate, account state, unsupported authentication method, and policy mismatch.
Do not use real credentials in this course.
Station 9: intermittent internet connectivity
Evidence:
LAN switching: stable
local printer: stable
router LAN interface: stable
router WAN/provider state: repeatedly dropsThe local network remains healthy while the upstream path changes state.
That separates the incident from intermittent Wi-Fi or local switch instability.
Station 10: DNS-only failure
Evidence:
remote IP: reachable
gateway: reachable
hostname lookup: failsDo not call it complete connectivity loss.
Name resolution is the failed responsibility.
Station 11: DHCP and APIPA failure
Evidence:
link: up
expected DHCP: yes
observed IPv4: 169.254.x.xStay near address acquisition.
The signal can be excellent and the application can still be unusable because the client never received expected local configuration.
Station 12: service failure with healthy network path
Evidence:
DNS: resolves
host: reachable
expected service endpoint: no listener / refusedThis is a service-layer incident.
Replacing the cable because "the app is down" ignores the surviving network evidence.
Compare degradation and failure
| Pattern | Operational meaning |
|---|---|
| no link | connectivity failure at physical or radio boundary |
| APIPA | expected configuration acquisition failed |
| gateway unreachable | local path may work while off-subnet path fails |
| DNS failure | IP path can work while names fail |
| high latency | path works but delay is high |
| jitter | packet delay varies, harming real-time traffic |
| port flapping | link repeatedly changes state |
| interference | radio environment degrades performance or stability |
| authentication failure | identity or policy boundary rejects access |
| service refusal | host path works but application endpoint is unavailable |
Use the table to decide what evidence matters next, not as a memorization checklist.
Build six incident records
For six different stations, document:
user-visible symptom
scope: one client / many / wired / wireless / local / remote
last proven-good boundary
first failed or uncertain boundary
best tool or evidence source
strongest theory
competing theory
controlled next action
verification
remaining uncertaintyPick cases from different symptom families. Do not choose six versions of "no connection."
Before you move on
A good technician can distinguish loss of connectivity, intermittent connectivity, degraded speed, high latency, jitter, radio interference, physical link instability, authentication failure, and service failure.
The user may use one sentence for all of them.
Your evidence should not.
Read it. Prove it.