LFCS Networking Practice Question
Exhibit
Refer to the exhibit. $ tcpdump -i eth0 -c 5 'port 80' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:11:11.111111 IP 10.0.0.1.12345 > 192.168.1.1.80: Flags [S], seq 123, win 29200, options [mss 1460], length 0 11:11:11.222222 IP 192.168.1.1.80 > 10.0.0.1.12345: Flags [S.], seq 456, ack 124, win 28960, options [mss 1460], length 0 11:11:11.333333 IP 10.0.0.1.12345 > 192.168.1.1.80: Flags [.], ack 457, win 29312, length 0
Based on the tcpdump output in the exhibit, what can be concluded about the TCP handshake?
⚠ Common exam trap
The trap here is that candidates may mistakenly think a three-packet handshake is incomplete or failed, when in fact the TCP three-way handshake is defined as exactly three packets, and the final ACK from the client completes it.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The TCP three-way handshake completed successfully.
The TCP three-way handshake completes successfully when three packets are exchanged: SYN, SYN-ACK, and ACK. The tcpdump output shows exactly these three packets, confirming a successful handshake. The presence of the final ACK from the client to the server's SYN-ACK indicates that the connection is established.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The connection attempt failed because only three packets are shown.
Why it's wrong here
A three-packet capture is the complete SYN, SYN-ACK, ACK exchange, so the handshake succeeded; packet count alone proves nothing about failure. It is tempting because a truncated capture can indicate a dropped connection, but here the sequence itself shows establishment, and the conclusion must follow the flags and sequence numbers shown.
- ✗
The connection was reset by the remote host.
Why it's wrong here
A reset would appear as a packet with the RST flag set, which the exhibit does not show; the captured flags indicate normal handshake progression instead. It is tempting because RST terminates connections abruptly, but no RST is present, so the conclusion contradicts the actual flags displayed.
- ✗
The handshake is incomplete because there is no ACK from the server.
Why it's wrong here
The server's SYN-ACK is itself the acknowledgement of the client's SYN, so a separate server ACK is not expected; the client's final ACK completes the handshake. It is tempting because the three-way handshake is often misremembered as four packets, but the SYN-ACK combines the server's SYN and ACK.
- ✓
The TCP three-way handshake completed successfully.
Why this is correct
The capture shows SYN, SYN-ACK and ACK exchanged in sequence between the hosts, confirming the three-way handshake completed and the connection entered ESTABLISHED state. This satisfies the exhibit evidence, ruling out a reset, refused connection or incomplete handshake.
Visual reference
About these practice questions
Courseiva writes every LFCS question from scratch — 406 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.