Week 08 · lesson
Lesson 5: Service and Wi-Fi Failure Challenge
Five users can say:
"Wi-Fi is broken."
and describe five completely different failures.
One client may never receive DHCP configuration. Another may have working IP connectivity but broken DNS. A third may have perfect radio association to an access point whose Ethernet uplink is disconnected. A fourth may reach the server but fail at the application port. A fifth may simply be competing for airtime in an overcrowded channel.
The symptom is vague.
The evidence is not.
Use the service path
Work through this model:
System process animation
Packet to service: prove each boundary
Use a layered test path from link through the application response.Technician question: Which test proves reachability but not application health?
The first failed boundary changes the diagnosis.
Case A: strong Wi-Fi, APIPA address
Evidence:
SSID: associated
signal: strong
IPv4: 169.254.18.42/16
expected DHCP network: 192.168.50.0/24
gateway: noneThe client can see and associate with the access point.
Expected IP configuration is missing.
The strongest investigation moves toward the DHCP client state, DHCP scope or service, VLAN placement, AP uplink, and the DHCP path.
Changing DNS will not assign the missing address and gateway.
Separate network reachability from service reachability
Trace configuration, gateway, DNS, destination host, and application listener as separate dependencies. A successful ping is not proof that the service is healthy.
What do you expect to keep working, and where do you think the path will stop?
Read the topology as text
- Client IP config: address, mask, gateway
- Gateway: remote path
- DNS: name → address
- Destination host: reachable IP endpoint
- Application listener: TCP/UDP service port
- Client IP config → Gateway: route remote traffic
- Gateway → DNS: name lookup
- DNS → Destination host: resolved address
- Gateway → Destination host: IP reachability
- Destination host → Application listener: service port
Separate host reachability from service reachability
The host responds, but the application port is closed. Inspect listening sockets, start one simulated service, and verify the application path.
Ghostty Web renders the terminal, but this lesson still uses a controlled Robotnix command engine. No unrestricted operating-system shell is connected.
ping -c 2 192.0.2.20ss -lntcurl -I http://192.0.2.20:8080systemctl --user start helpdesk-demo
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 service-port simulation This is deterministic lesson state, not a real host or service. $ ping -c 2 192.0.2.20 64 bytes from 192.0.2.20: icmp_seq=1 ttl=64 time=0.9 ms 64 bytes from 192.0.2.20: icmp_seq=2 ttl=64 time=0.8 ms $ ss -lnt State Recv-Q Send-Q Local Address:Port LISTEN 0 128 127.0.0.1:22 $ curl -I http://192.0.2.20:8080 curl: (7) Failed to connect to 192.0.2.20 port 8080: Connection refused $ systemctl --user start helpdesk-demo Started helpdesk-demo.service in simulated state.
Case B: remote IP works, hostname fails
Evidence:
IP configuration: valid
gateway: reachable
remote documentation IP: reachable
portal.training.test: name lookup failsEnough IP routing exists for that destination.
The failed responsibility is name resolution.
Inspect the configured DNS server, its reachability, supplied query result, and expected record.
Do not replace the access point because a hostname failed.
Case C: strong radio, broken AP uplink
Evidence:
SSID: visible
association: successful
signal: strong
AP power: normal
AP Ethernet uplink: disconnectedThe radio side of the AP is healthy enough to advertise and accept the client.
The AP is isolated from the rest of the network.
This is why the Wi-Fi icon is not an internet-health indicator.
After restoring the approved uplink, verify client address acquisition, gateway access, and the required user service.
Case D: host reachable, service endpoint wrong
Evidence:
DNS: correct
host IP: reachable
expected application endpoint: TCP/443
supplied application state: listening on TCP/8443 insteadBasic network reachability works.
The application or listener configuration does not match the documented endpoint.
Do not rewrite firewall rules until the listener configuration is understood.
Case E: crowded 2.4 GHz environment
Evidence:
wired clients: normal
wireless association: normal
signal near AP: strong
three clients: acceptable performance
twenty-five clients: severe slowdown
channel data: heavy neighboring overlapThe symptom scales with wireless load.
Radio capacity, airtime, interference, channel selection, channel width, AP capacity, and client distribution become stronger hypotheses than DNS.
Do not call a full provider outage when the wired path is healthy.
Case F: VPN fails while ordinary internet works
Evidence:
client IP configuration: valid
DNS: working
normal approved websites: reachable
VPN connection: failsThe local path and general internet connection work.
The failure belongs to the VPN-specific path, configuration, authentication, or remote endpoint.
Turning Wi-Fi off and on may change nothing because Wi-Fi is not the failed layer.
Case G: guest VLAN reaches staff network unexpectedly
Evidence:
guest client: valid guest address
internet: works
staff resource: reachable despite stated isolation requirementThis is not a connectivity failure.
It is a segmentation or policy failure because communication exists where the design says it should not.
Success is not always "packet got through."
Sometimes the correct result is denial.
Case H: HTTPS transport works, application fails
Evidence:
DNS: correct
TCP/443 handshake: succeeds
web application: returns dependency error
database service: unavailable in supplied architectureDo not call the port closed.
Transport worked.
The failure moved higher into the application dependency chain.
Separate observation from conclusion
For each case, write:
observation:
interpretation:
claim not yet supported:Example:
observation: client has 169.254.18.42 and no gateway
interpretation: expected DHCP configuration was not obtained
claim not yet supported: DHCP server itself is definitely downWhy is the last claim too large?
Because the failure could also be client-specific, VLAN-specific, or somewhere along the DHCP path.
This is the same evidence discipline we used with hardware.
Build three incident records
Choose three different cases and document:
user-visible symptom
what definitely works
first failed / unproven boundary
strongest theory
competing theory
one controlled test
expected result
correction if supported
verification
one higher layer still not provenThe incident is not finished because one ping succeeds or one cable gets plugged back in.
Verification should return to the user's actual required function.
Challenge the bad statements
Explain why each statement is technically weak:
Strong Wi-Fi bars mean the internet works.
A private IP address means the network is secure.
DNS and DHCP are basically the same thing.
Port 443 proves HTTPS is working.
NAT is the firewall.
Each statement turns one narrow fact into a much larger claim.
What Week 8 should change in your head
A useful network is a dependency stack.
The user sees the final application.
The technician sees the layers underneath it:
signal
link
address
route
name
transport
serviceDo not restart everything because the top layer failed.
Prove the lower layers, find the first failed responsibility, and make the smallest justified correction.
Next week we turn that model into an actual troubleshooting toolbox and learn what each physical and software tool can prove.
Read it. Prove it.