Exercise 1: Diagnosing a TCP Handshake That Never Completes — Possible Solution
====================================================================

Most direct tool: ss (or netstat), possibly combined with tcpdump for
full confirmation.

Explanation:

Per net1-10's own chapter, "ss -tulpn... shows every listening port...
and every active connection, including its exact TCP state." If Step
3's handshake never completes, running ss on the client machine
attempting the connection would show the connection sitting in a
state other than ESTABLISHED -- most likely SYN_SENT, indicating the
client has sent its own initial SYN and is still waiting for a
SYN-ACK that hasn't arrived. This directly matches net1-7's own
warn-box, referenced again in this chapter's Step 6: "the handshake
could hang on a silently dropped SYN-ACK." Seeing a connection stuck
in SYN_SENT rather than progressing to ESTABLISHED is the direct,
visible confirmation that the handshake itself, specifically, is where
the failure is occurring -- not DNS (which already resolved
successfully, since a destination IP exists to connect to at all),
not routing (traceroute could separately confirm the path itself is
intact), but specifically the handshake exchange.

For full confirmation of exactly what's happening on the wire,
tcpdump could be layered on top of this: per net1-10, tcpdump -i eth0
port 443 would show the client's own SYN packet being sent, and
would make directly visible whether any SYN-ACK response ever arrives
at all -- confirming definitively whether the problem is a dropped
SYN-ACK somewhere in the network path, versus some other client-side
issue.

Why ping and traceroute wouldn't be the right first choice here:

Per this chapter's own Step 6, the failure is specifically located at
the TCP handshake step -- ping only tests ICMP reachability (net1-10's
own limitation, and could easily succeed even while the TCP handshake
itself fails), and traceroute only confirms the routing path is intact,
neither of which would reveal a stuck TCP connection state the way ss
directly would.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies ss as the specific tool that reveals connection state
directly (SYN_SENT vs. ESTABLISHED), ties it to net1-7's own dropped-
SYN-ACK warning referenced in this chapter, and explains why the other
two tools in net1-10's toolkit wouldn't surface this particular
failure as directly.