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.test does 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.

Technician topology

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.

1. predict2. run3. inspect4. compare

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
  1. Client IP configGateway: route remote traffic
  2. GatewayDNS: name lookup
  3. DNSDestination host: resolved address
  4. GatewayDestination host: IP reachability
  5. Destination hostApplication listener: service port
Ghostty terminal simulation

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.

Commands worth trying
  • ping -c 2 192.0.2.20
  • ss -lnt
  • curl -I http://192.0.2.20:8080
  • systemctl --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.

Lesson knowledge checks

Answer from the lesson you just completed. Results stay in this browser and are not submitted.
Knowledge check 1

A server responds to ping but its web application does not answer on the expected port. What does that prove?

Knowledge check 2

A Wi-Fi client associates to the AP but cannot reach the default gateway. Which conclusion is strongest?