Week 08 · lesson
Lesson 5: Service and Wi-Fi Failure Challenge
Core path: 42 minutes
Five users can all say "Wi-Fi is broken" while describing five different failures.
Your job is to separate them.
Ticket A: connected, APIPA address
Evidence:
- client associates to SSID;
- signal is strong;
- IPv4 is
169.254.18.42; - expected DHCP configuration is absent.
Focus on DHCP/configuration path, not radio strength.
Ticket B: remote IP works, hostname fails
Evidence:
- valid address and gateway;
- remote documentation IP responds;
portal.testdoes not resolve.
Focus on DNS.
Ticket C: strong signal, no network path
Evidence:
- client associates;
- AP signal is strong;
- AP uplink to switch is disconnected.
A strong radio link does not prove the AP has a usable wired/upstream path.
Ticket D: service on wrong port
Evidence:
- hostname resolves;
- host is reachable;
- documented service expects TCP 443;
- application is listening on another configured port.
Focus on service/listener configuration.
Ticket E: crowded 2.4 GHz room
Evidence:
- wired clients are healthy;
- wireless clients near the AP associate successfully;
- latency/throughput degrade as the room fills;
- channel analysis shows heavy overlap/congestion.
Focus on radio capacity/interference before DNS.
Incident record
Choose three tickets and document:
symptom:
what still works:
first failed/unproven boundary:
strongest theory:
alternative theory:
one controlled test:
expected result:
verification:
Week 8 defense
Explain why each of these statements is wrong:
- "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."
- "443 means every HTTPS implementation must always use only TCP."
- "NAT is the firewall."
The goal is not to memorize networking trivia. It is to know which mechanism to test next.
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.
Read it. Prove it.