- Which action would most directly allow inspection of that file-transfer traffic?
Answer: Capture from a configured switch mirror port or an appropriately placed network tap.
Whenever you see a question about capturing traffic on a switched network, the core concept to understand is how switches handle unicast frames differently from hubs. A switch is intelligent — it learns which MAC addresses live on which ports and forwards unicast frames only to the intended destination port. This is fundamentally different from a hub, which broadcasts every frame out every port.
This is why C is correct. Even with promiscuous mode enabled, your adapter can only capture frames that physically arrive at your port. On a standard access port, the switch delivers your own traffic and broadcasts, but the file-transfer frames between two other hosts never reach your NIC at all — they're forwarded directly between those two ports. To capture that traffic, you need either a mirror port (also called SPAN — Switch Port Analyzer), where the switch is explicitly configured to copy designated traffic to your monitoring port, or a network tap, a passive hardware device inserted inline that duplicates traffic without disrupting the flow.
Choice A reflects a common misconception: Wireshark display filters only hide or show packets already captured — they cannot request or pull packets from the switch. The switch has no such interface. Choice B is backwards; promiscuous mode causes your adapter to accept frames not addressed to it, so disabling it would make things worse, not better. Choice D misunderstands the problem entirely — the frames aren't being dropped by a buffer; they simply never arrive at your port in the first place.
As a study tip, remember: promiscuous mode fixes the NIC problem; mirror/SPAN or a tap fixes the switch problem. They solve different layers of the capture challenge.
- What does the client's acknowledgment number indicate?
Answer: The client received all data through byte 600 and expects the next segment to begin at byte 601.
Whenever you see a question about TCP acknowledgment numbers, anchor yourself to this rule: the acknowledgment number tells the sender what byte the receiver expects next, which is always one more than the last byte successfully received.
In TCP, sequence numbers track bytes of data. Here, Wireshark shows relative numbers, so the server's segment starts at sequence number 1 and carries 600 bytes of payload. That means the segment occupies bytes 1 through 600 (inclusive). Once the client receives all of those bytes intact, it sets its acknowledgment number to 1+600=601, signaling: "I have everything up through byte 600; send me byte 601 next." That's exactly what B describes, making it correct.
A has the logic completely backwards. An acknowledgment number of 601 confirms receipt up to and including byte 600 — it does not mean the client is missing bytes 1 through 600 and only has byte 601.
C introduces a false arithmetic rule. The acknowledgment number is not counting a total of bytes received from zero; it reflects the next expected byte offset in the stream. The client received 600 bytes, not 601.
D is a category error. Acknowledgment numbers operate at the data-stream layer and reference byte positions, never port numbers. Port 601 has no relevance to this calculation.
As a study habit, remember the phrase: "ACK = last byte received + 1." On exam questions involving sequence and acknowledgment numbers, sketch the byte range the segment covers, then add one — that's always your acknowledgment number. - Which explanation is most consistent with both observations?
Answer: Checksum offloading lets the network adapter fill in checksums after the local capture point observes packets.
When you see a question pairing a local capture tool showing errors with a remote device showing valid packets, think about where in the packet's journey the observation is being made — this is the key to unlocking the scenario.
Modern operating systems use TCP checksum offloading to improve performance. When your OS hands a packet to the network adapter, it intentionally leaves the checksum field blank or zeroed, letting the NIC hardware compute and insert the correct checksum at the last possible moment before transmission. Wireshark, however, captures packets at the OS/kernel level — before the NIC fills in the checksum. This is why Wireshark flags those checksums as invalid locally, while a monitoring device downstream sees perfectly valid checksums: the NIC did its job, just after the local capture point. This makes C the correct explanation — it perfectly accounts for both observations without requiring any unusual behavior.
A is wrong because TCP has no mechanism to "repair" incoming checksums — if a corrupt packet arrives, the receiving host simply discards it. Silent repair doesn't exist in the protocol.
B is wrong because promiscuous mode affects which packets Wireshark sees (all traffic vs. only traffic addressed to the host), not how it calculates or validates checksums. These are completely independent functions.
D is wrong because TCP checksums are not optional at any stage of the connection. The three-way handshake has nothing to do with whether checksum validation is enforced — it always is.
As a study tip, remember that checksum offload is the go-to explanation any time you see Wireshark reporting checksum errors on a machine that's otherwise functioning normally. It's one of the most common "gotcha" scenarios in network troubleshooting questions.
- Which conclusion is best supported by this result?
Answer: The DNS packets were probably not captured, so changing the display filter cannot recover them.
Wireshark operates with two distinct filtering layers, and confusing them is one of the most common mistakes analysts make. Capture filters (written in BPF syntax) run before packets are stored — they act as a gatekeeper, deciding what traffic even enters the capture buffer. Display filters run after capture, letting you slice and reorganize data that's already been saved. The critical implication: if a capture filter excludes certain traffic, no display filter can ever recover it, because those packets were never written to memory in the first place.
In this scenario, the analyst used tcp port 443, which captures only TCP traffic on port 443 (HTTPS). DNS queries typically travel over UDP port 53 — a completely different protocol and port. Because the capture filter blocked all non-HTTPS traffic from being recorded, applying the dns display filter afterward finds nothing. That's why B is correct: the DNS packets were almost certainly never captured, and changing the display filter cannot retrieve what was never stored.
A is wrong because there's no "precedence rule" where capture filters hide packets until a file is reopened — packets excluded at capture time are permanently gone. C is wrong on two levels: display filters use Wireshark's own syntax (e.g., dns or udp.port == 53), not BPF syntax, and the real problem is absence of data, not a syntax mismatch. D is wrong because Wireshark can absolutely capture multiple protocol types simultaneously — that's a fabricated limitation.
For the exam, remember this rule: **capture filters decide what you keep; display filters decide what you see.** If the data was never captured, no display filter can save you.
- What is the best next step to make Wireshark dissect the traffic as HTTP?
Answer: Use Decode As to associate the relevant TCP conversation or port with the HTTP dissector.
When Wireshark captures traffic on a nonstandard port, it won't automatically know which application-layer protocol to apply — it just labels everything as raw TCP. The key concept here is protocol dissection: Wireshark separates capturing packets from interpreting them, and you can manually tell it how to interpret a conversation after the fact.
The right move is D — Decode As. This built-in Wireshark feature lets you right-click a packet (or navigate to Analyze → Decode As) and map a specific port number or conversation to a dissector, like HTTP. Once applied, Wireshark re-parses all matching packets through the HTTP lens, giving you full field-level decoding instead of raw bytes. The readable text you already found via "Follow TCP Stream" confirms the traffic is HTTP — you just need to tell Wireshark's dissector engine that.
A is wrong because you cannot edit packet headers inside Wireshark to change how packets are classified — Wireshark is a read-only analysis tool. Changing a display value doesn't alter the underlying capture or trigger re-dissection.
B is wrong because capture filters run at collection time and filter which packets are saved — they don't re-decode packets you've already captured. There's also no valid Wireshark syntax like http port 8088 that retroactively changes dissection.
C is wrong because the question explicitly tells you the traffic is plaintext — you can already read the HTTP request in plain text. TLS decryption is only relevant when traffic is encrypted (e.g., HTTPS).
Study tip: On Wireshark questions, watch for the distinction between capture filters (what you collect) and display filters/Decode As (how you interpret it). "Decode As" is always your tool for nonstandard port dissection.
- What can the analyst most reasonably infer from this capture?
Answer: The client likely requested store.example, but the exact HTTP path and response body are not visible.
When analyzing TLS traffic in Wireshark, the key framework to apply is understanding exactly what TLS protects and what it intentionally leaves visible. TLS encrypts the application-layer payload — the HTTP request, headers, path, and response body — while certain handshake fields, including the Server Name Indication (SNI) extension in the ClientHello, are transmitted in plaintext so that network infrastructure can route traffic correctly.
This means the analyst can confidently identify which server the client intended to reach (here, store.example) because SNI is unencrypted. However, without session keys or a decryptable private key, everything after the handshake — the encrypted application-data records — is opaque. The analyst sees that data was exchanged, but not what was exchanged. Answer A correctly captures this boundary: the destination hostname is knowable, but the HTTP path, method, and response body are not.
Answer B is wrong because "definitely downloaded the home page" introduces a false certainty. The client could have requested any resource — an API endpoint, an image, a checkout page — not necessarily the home page. You cannot infer the specific resource from SNI alone.
Answer C is wrong because while traffic analysis (using record sizes and timing) can produce probabilistic inferences in research contexts, it does not reconstruct the exact HTTP request. That claim overstates what metadata reveals.
Answer D is wrong and describes the opposite of reality. SNI exposes the hostname in plaintext; it does not encrypt it. The HTTP path is inside the encrypted application data, not "readable."
Study tip: On TLS questions, always mentally separate the handshake (partially visible) from application data (fully encrypted). SNI = visible; HTTP content = hidden.
- Which Wireshark display filter most precisely meets the requirement?
Answer: ip.addr == 10.0.0.8 && tcp.port == 443
When filtering network traffic in Wireshark, you need to think carefully about two things: which host you're targeting and which direction(s) of traffic you want to capture. HTTPS runs over TCP port 443, so any filter must account for both the IP address condition and the port condition simultaneously.
To see both directions of every HTTPS conversation involving 10.0.0.8, you need packets where that host appears as either source or destination, restricted to port 443 traffic. The field ip.addr matches either direction (source or destination), and tcp.port matches port 443 on either end of the connection. Combining them with && (AND) gives you exactly what's needed: D — ip.addr == 10.0.0.8 && tcp.port == 443 — captures every HTTPS packet touching that host, inbound or outbound, without over-selecting.
A fails immediately because ip.src == 10.0.0.8 only captures outbound packets from that host — you'd miss all the returning HTTPS responses. B is logically broken: requiring ip.src == 10.0.0.8 AND ip.dst == 10.0.0.8 simultaneously means a packet must originate and terminate at the same host, which no normal packet does — this filter returns nothing. C uses OR (||) instead of AND, which is far too broad: it shows every packet from 10.0.0.8 (on any port) plus every port-443 packet in the capture regardless of host, pulling in all those other HTTPS conversations you're trying to exclude.
A reliable study tip: when you need bidirectional traffic for a single host and protocol, always pair ip.addr (not ip.src/ip.dst) with && and the port field — OR logic almost always over-captures on these exam questions.
- What is the most accurate interpretation of the destination fields?
Answer: The frame is addressed to the gateway for local delivery, while the IP packet is addressed to the remote host.
Whenever you see a question involving both Ethernet (Layer 2) and IP (Layer 3) destination fields, remember that these two layers serve different scopes. Ethernet handles local, hop-by-hop delivery, while IP handles end-to-end delivery across the entire network path. These goals are deliberately separate, and a captured packet will almost always show different destination addresses at each layer when traffic is leaving the local network.
In this scenario, the workstation needs to reach 198.51.100.20, which is an external (non-local) host. The workstation knows it can't deliver that packet directly, so it wraps the IP packet inside an Ethernet frame addressed to the default gateway's MAC address (00:aa:bb:cc:dd:ee). The gateway receives the frame, strips the Layer 2 header, reads the IP destination, and forwards the packet onward. This is exactly what C describes — the frame targets the gateway locally, while the IP packet targets the remote host end-to-end. C is correct.
A has it completely backwards. 198.51.100.20 is the IP destination (the remote application endpoint), not an Ethernet hop identifier. The gateway is the Ethernet destination, not the "application destination."
B is incorrect because Wireshark doesn't fabricate or resolve one destination into another. The two addresses belong to different protocol layers and are both real; no tool is "resolving" one from the other.
D introduces a false threat narrative. Differing Layer 2 and Layer 3 destinations are completely normal and expected for any traffic leaving a local subnet — not evidence of tampering.
Study tip: Always ask yourself, "Which layer am I looking at?" When traffic crosses a router, the MAC destination changes at every hop, but the IP destination stays constant all the way to the final host. That distinction is a frequent exam target.
- Which explanation best accounts for the 14-byte difference?
Answer: The IPv4 Total Length excludes the 14-byte Ethernet header but includes the IP header and its payload.
When analyzing packet captures, you need to think in terms of protocol layers — each layer adds its own header, and length fields are defined relative to that layer only.
An Ethernet frame wraps an IP packet. The standard Ethernet header consists of 6 bytes (destination MAC) + 6 bytes (source MAC) + 2 bytes (EtherType) = 14 bytes. The IPv4 "Total Length" field counts only what belongs to the IP layer and above — the IP header plus its payload (TCP/UDP/etc.). It deliberately excludes the Ethernet header because Ethernet is a lower layer that IP has no reason to count. So when Wireshark reports a frame length of 1514 bytes, that's the full Ethernet frame; the IPv4 Total Length of 1500 bytes is that same data minus the 14-byte Ethernet header sitting in front of it. Answer A captures this exactly and is correct.
Answer B is wrong on two counts: TCP headers are typically 20–60 bytes (not 14), and IPv4 Total Length certainly doesn't include Ethernet addressing — that's the opposite of how layering works. Answer C describes a fictional Wireshark behavior; promiscuous mode simply allows the NIC to capture all frames on the wire — it doesn't duplicate or pad data in memory. Answer D misunderstands fragmentation; fragmented packets are split at the IP payload level and reassembled, which has nothing to do with a consistent 14-byte offset tied to an Ethernet header.
As a study tip, memorize the standard Ethernet header size (14 bytes) and remember that each protocol's length field counts only its own layer and above — this pattern appears repeatedly in packet-analysis questions.
- Which packet is the best candidate for the corresponding DNS response?
Answer: A resolver-to-client packet with ID 0x41a2, the response flag set, and an answer for portal.example.
When a DNS resolver responds to a client's query, three fields must match the original request exactly: the transaction ID, the direction (response flag set), and the query name. Think of the transaction ID as a ticket number — the response must return that same ticket to prove it belongs to your question.
Option A satisfies all three conditions: the transaction ID is 0x41a2 (matching the query), the response flag is set (confirming it's a reply, not another question), and the answer is for portal.example (the name that was actually queried). This is your correct answer.
Option B fails on the transaction ID — 0x41a3 is off by one. This mismatch is the hallmark of a DNS spoofing attempt, where an attacker floods a resolver with forged responses hoping one lands before the real reply. A properly implemented resolver will silently drop any response whose ID doesn't match the outstanding query.
Option C fails in two ways: it's a client-to-resolver packet with the query flag set, meaning it's another outgoing question, not an incoming answer. Responses always flow from resolver to client.
Option D has the correct ID and response flag, but answers for mail.example instead of portal.example. A mismatched query name — even with a matching transaction ID — indicates either a misconfiguration or a forged packet, and should be discarded.
Study tip: DNS response validation is a favorite exam topic because it directly ties to cache poisoning attacks. Always check all three fields — ID, direction flag, and query name — as a complete unit.
