# Prove it on the wire Source: https://ai.techclick.in/blog_wireshark_interview Markdown: https://ai.techclick.in/blog_wireshark_interview.md Publisher: Techclick Infosec Pvt Ltd Wireshark interview questions and answers (2026): eight production scenarios on the 3-way handshake, capture vs display filters, TCP flags, latency vs loss, and Follow TCP Stream — plus a scored quiz. Say this out loud A capture filter decides what is written to disk. A display filter only hides what I already have. The handshake is SYN, SYN-ACK, ACK. If I see SYN retransmits and no SYN-ACK, the listener or the path never answered — that is not TLS. Retransmits plus duplicate ACKs are loss . A high iRTT with a clean SEQ/ACK tree is latency . Zero Window is the receiver pausing me. I Follow the stream after I know which TCP conversation I own. ## 1. Ticket hook — ERP times out at 09:12 Finance says SAP GUI “hangs.” NOC already bounced the WAN circuit. A junior dropped Wireshark on their laptop, typed tcp.port == 3200 into the capture-filter box, hit Start, and captured nothing useful. Another junior captured every VLAN on a 10 Gb/s SPAN until the disk filled. A third opened Follow TCP Stream on the first HTTP conversation they saw and declared “the app is fine.” That is the interview. Wireshark has two filter languages . The handshake is three packets, not a vibe. tcp.analysis.flags is how you prove loss. tcp.analysis.initial_rtt is how you prove delay. Follow Stream reconstructs application bytes — it does not invent a root cause. Hero · who talks to whom Notice: you only see the packets that reach the NIC you are listening on. A switched unicast to someone else never lands here without a SPAN or TAP. Hard words, once Capture filter — libpcap / BPF expression set before Start; it limits what is written to the file and cannot be widened later. Display filter — Wireshark field language; every packet stays in the file; you only change the view. 3-way handshake — SYN, SYN-ACK, ACK (RFC 9293). TCP flags — SYN, ACK, FIN, RST, PSH, URG (plus ECN bits). iRTT — tcp.analysis.initial_rtt , the handshake RTT for that flow. tcp.time_delta — time since the previous frame in the same TCP stream. Retransmission / Dup ACK — loss or reordering signals under SEQ/ACK analysis. Zero Window — receiver advertised window is 0; the sender must pause. Follow TCP Stream — Analyze → Follow; applies tcp.stream eq N and shows the reconstructed bytes. SPAN / TAP — how you see another host on a switched network. ## 2. Mental model: capture → decode → prove Interviewers mix “filter,” “stream,” and “analysis flag” on purpose. Keep them on different layers. Wireshark does not create timestamps — libpcap / Npcap gets them from the kernel. It does not see traffic that never reached this NIC. It does add SEQ/ACK analysis once, in packet-list order, when the file is opened. #### What the capture owns Interface, promiscuous bit, capture filter, ring buffer, the pcapng file. Wrong place or a BPF typo means the evidence was never written. You cannot “display-filter” packets that are not on disk. #### What the analyst owns Display filter, time-display format, TCP analysis fields, Follow Stream, the sentence that says latency versus loss versus application delay. The dashboard color is not the proof. Place the tap first. Client NIC proves what the client sent and received. Server NIC proves the other end. A mid-path SPAN or TAP proves what crossed that hop. Promiscuous mode on a switched access port still only sees that port plus broadcasts. That is why “I put Wireshark in promiscuous mode” is not a SPAN. Path · three handshake panels Notice: SYN-ACK is the server speaking. No SYN-ACK means the listener or the path never answered. That is not an HTTP 500 and not a TLS alert. ## 3. Handshake and filter decision Flowchart first. You do not open Follow Stream first. You prove the conversation exists, then you decide whether you are looking at setup, flags, delay, or loss. Flow 1 · 3-way handshake and the missing reply TCP 3-way handshake: SYN, SYN-ACK, ACK, and what a missing SYN-ACK means - Client 10.20.4.88 : 51422 Server 10.50.1.12 : 443 1 · SYN seq=x 2 · SYN-ACK seq=y ack=x+1 3 · ACK ack=y+1 No SYN-ACK SYN retransmits · no listener or filter / path drop RST after SYN port closed or policy reset tcp.flags.reset == 1 Handshake complete tcp.completeness == 7 then look at data / TLS Read left → right, then the three outcomes. tcp.completeness==7 is SYN + SYN-ACK + ACK (1+2+4). Data, FIN, and RST add more bits. Source: Wireshark User’s Guide §7.5 and RFC 9293. Flow 2 · capture filter versus display filter Capture filter writes fewer packets; display filter only hides rows Wire / SPAN all frames on NIC Capture BPF / libpcap pcapng file on disk · frozen Display Wireshark syntax View Capture filter · before Start host 10.0.0.5 tcp port 443 and host 10.0.0.5 tcp port 23 and not src host 10.0.0.5 Cannot change mid-capture. Packets that miss the BPF are gone. Source: User’s Guide §4.10. Display filter · after / during view ip.addr == 10.0.0.5 tcp.port == 443 tcp.analysis.flags All packets stay in the file. Change on the fly. Source: Wiki CaptureFilters + §6.3. Wiki wording: tcp port 80 is a capture filter. tcp.port == 80 is a display filter. They are not interchangeable. ## 4. How to choose: filter, flag, latency vs loss Say the language out loud. Capture filters are libpcap primitives joined with and / or / not . Display filters compare protocol fields. Mixing them is the most common fail in the room. Job Use Write this Do not write Keep the file small; only host 10.0.0.5 Capture (BPF) host 10.0.0.5 ip.addr == 10.0.0.5 in the capture box Only TCP/443 to or from that host Capture (BPF) tcp port 443 and host 10.0.0.5 tcp.port == 443 — that is display syntax Hide noise in an existing pcap Display tcp.port == 443 or http A new capture. The packets are already on disk. Show only this conversation Display / Follow tcp.stream eq 14 (Follow applies it) A BPF on a file you already captured Surface TCP trouble Display tcp.analysis.flags Scrolling until something is red Exclude an address (display) Display !(ip.addr == 10.43.54.65) ip.addr != 10.43.54.65 — classic gotcha before 3.6 Decision · latency or loss Path A is delay with a clean SEQ/ACK tree. Path B is retransmits and duplicate ACKs. They are different tickets. What you see Field / flag It means First sentence SYN, then SYN again ~1s, 2s, 4s. No SYN-ACK. tcp.flags.syn==1 && tcp.flags.ack==0 plus tcp.analysis.retransmission Handshake never completed Listener, ACL, or path — not the application body SYN, then RST tcp.flags.reset==1 / tcp.connection.rst Someone aborted. Closed port or a device reset. Who sent the RST — client, server, or middlebox Handshake OK. Large gap before HTTP response. No analysis flags. tcp.analysis.initial_rtt , tcp.time_delta , tcp.analysis.ack_rtt Latency or a slow server. Not loss. Delay sits after ACK. Look at the application, not the WAN drop counters. Retransmissions + duplicate ACKs tcp.analysis.retransmission , .fast_retransmission , .duplicate_ack Loss or severe reordering A segment did not arrive in order. That is a path or capture-point story. Window advertised as 0, no SYN/FIN/RST tcp.analysis.zero_window Receiver flow control. Sender must pause. The receiving app or stack is full — not “the link is down.” Graceful close tcp.flags.fin==1 / tcp.connection.fin Orderly teardown FIN is not RST. Do not call a FIN an abort. Common miss tcp.analysis.lost_segment is labeled Previous segment(s) not captured . That is common at the start of a file or when your SPAN missed a packet. It is not automatic proof that the network dropped the segment. Pair it with retransmissions on the same stream before you blame the WAN. ## 5. Do: place → filter → follow → classify Primary sources for this block: Wireshark User’s Guide §4.10 (capture filters), §6.3 / wiki DisplayFilters (display), §7.2 (Follow Stream), §7.5 (TCP analysis), §7.6 (timestamps). The menu names below are from those pages. ### Side A — Place the tap and write the capture filter #### Pick the NIC that can see the symptom Client NIC for “my session fails.” Server NIC for “nobody can connect.” SPAN or TAP for a third host on a switch. Do not capture over a USB dongle if you care about iRTT — the User’s Guide §7.6 warns USB NICs stamp late. - #### Write BPF in Capture Options, not in the display bar Example from the guide: tcp port 23 and host 10.0.0.5 . For this ticket: host 10.20.4.88 and tcp port 443 . Capture filters cannot be widened after Start. If you are unsure what you need, capture wider and display-filter later — unless the SPAN will fill the disk. - #### Start, reproduce once, stop Mark the reproduce time. Save pcapng. A 20-minute unfiltered 10 Gb/s SPAN is not a lab; it is a storage incident. Capture → Options → Input · Filter (libpcap) Training mock · not live Capture / Options / Input ### Capture filter (BPF) Interface eth0 · 10.20.4.88 · promiscuous Link-layer header Ethernet Capture filter host 10.20.4.88 and tcp port 443 Not a display filter Do not type tcp.port == 443 here — that box is libpcap. Training mock. Field language follows User’s Guide §4.10 and wiki CaptureFilters. Example primitive shape matches tcp port 23 and host 10.0.0.5 . ### Side B — Display-filter the conversation, then read flags - #### Set time so deltas mean something View → Time Display Format. For a single flow, Seconds Since Previous Displayed Packet plus the column for tcp.time_delta (time since the previous frame in this TCP stream). iRTT lives under SEQ/ACK analysis as tcp.analysis.initial_rtt . - #### Prove the handshake before you blame HTTP Display tcp.flags.syn==1 or look at tcp.completeness . tcp.completeness==7 is SYN + SYN-ACK + ACK only. If completeness never reaches 7, stop talking about TLS or the app. - #### Turn on the analysis overlay Display tcp.analysis.flags . Then name the specific child: retransmission, fast retransmission, duplicate ACK, zero window, window update, previous segment not captured. Those labels are added under “SEQ/ACK analysis” (§7.5). Display filters you should be able to type in the room ip.addr == 10.20.4.88 && tcp.port == 443 tcp.flags.syn == 1 && tcp.flags.ack == 0 tcp.completeness == 7 tcp.analysis.flags tcp.analysis.retransmission || tcp.analysis.fast_retransmission tcp.analysis.duplicate_ack tcp.analysis.zero_window tcp.stream eq 14 ### Side C — Follow the stream, then classify - #### Select one packet in the conversation Analyze → Follow → TCP Stream (or the packet-list context menu). Wireshark applies a display filter for that stream and opens the reconstructed bytes. Client → server is red; server → client is blue (theme colors). - #### Read the application, then decide Close vs Back ASCII / UTF-8 for HTTP. HEX Dump for binary. Close leaves tcp.stream eq N in place. Back restores the previous display filter. People open Follow just to isolate the stream and immediately Close — that is documented, not a hack. - #### Say the class out loud Incomplete handshake. RST. Loss (retrans + dup ACK). Latency (high iRTT / high tcp.time_delta , clean analysis tree). Receiver stall (Zero Window). Application error (HTTP 500 inside a healthy TCP stream). Those are different owners. Analyze → Follow → TCP Stream · tcp.stream eq 14 Training mock · not live Analyze / Follow / TCP Stream 14 ### Reconstructed bytes No. Time Flags Info Analysis 18 0.000 SYN 51422 → 443 seq=x — 19 0.042 SYN, ACK 443 → 51422 seq=y ack=x+1 iRTT 42 ms 20 0.042 ACK ack=y+1 completeness=7 41 1.810 PSH, ACK HTTP GET /invoice time_delta 1.76 s 88 1.911 ACK len=0 win unchanged Dup ACK #2 89 1.918 ACK seq rewind Fast retransmission Handshake is healthy (iRTT 42 ms). The GET is late, then the path shows Dup ACK + fast retransmission. Name both. Do not pick one and ignore the other. ## 6. Runtime path after the pcap is open Once the file exists, the interesting tickets are almost always wrong capture point , BPF typed in the display bar , or Follow Stream on the wrong conversation — not “Wireshark is broken.” Flow 3 · open pcap → classify the symptom After the pcap is open: handshake, then latency versus loss versus application - Open pcapng analysis runs once Find the stream ip / port / Follow Handshake == 7? tcp.completeness NO Setup / RST / drop do not Follow HTTP yet YES analysis.flags? retrans / dup ACK / 0-win Latency high iRTT / time_delta SEQ/ACK tree clean path delay or slow app Loss retransmission + dup ACK or capture miss — confirm with a second tap if needed Application Follow Stream ASCII HTTP 500 / SMB error TCP was not the patient TCP analysis is computed once when the file opens, in packet-list order (§7.5). A later display filter does not rewrite those flags. Ops · proof desk Close the ticket with the stream index, the flags, and the field names — not with “looks slow on the screenshot.” ## 7. Eight interview scenarios Each one is a production ticket. Answer with the direct line, then the evidence. Weak answers reboot the firewall, paste Expert Info, or Follow the first stream they see. ### Q1 · Scenario — SYN, SYN, SYN, no SYN-ACK Client 10.20.4.88 opens TCP/443 to 10.50.1.12. You see three SYNs about one second apart. No SYN-ACK, no RST. The app owner says “certificate problem.” What do you say first? Direct answer The handshake never completed. TLS has not started. Either the SYN is not reaching the listener, the listener is not bound, or a device is silently dropping the SYN or the SYN-ACK. Recapture at the server NIC or the last L3 hop. Name tcp.flags.syn==1 && tcp.flags.ack==0 and tcp.analysis.retransmission . Why production cares RFC 9293 setup is three packets. A missing SYN-ACK is a path or listener ticket. Certificate and HTTP live after ACK. Weak answer / trap “Check the TLS version” or “Follow Stream and look for the alert.” There is no stream payload yet. #### Strong framing (say this) I do not debug TLS on an incomplete handshake. I move the tap until I see who never sent SYN-ACK. #### Evidence to name tcp.flags.syn , tcp.flags.ack , tcp.analysis.retransmission , tcp.completeness still below 7, capture point (client vs server). ### Q2 · Compare — capture filter versus display filter You must capture only traffic to or from 10.0.0.5 overnight without filling the disk. A teammate types ip.addr == 10.0.0.5 into Capture Options. What is wrong, and what do you write instead? Direct answer That is display-filter syntax. Capture Options wants libpcap: host 10.0.0.5 . The wiki is explicit: tcp port 80 is capture; tcp.port == 80 is display. Capture filters are set before Start and cannot be modified during the capture. Display filters only change the view; the file still holds every accepted packet. Why production cares A rejected BPF either captures nothing or, if someone “fixes” it by clearing the box, captures the entire SPAN. Both ruin the change window. Weak answer / trap “They are the same language” or “I will display-filter after the 40 GB file lands.” #### Strong framing (say this) Capture decides what exists tomorrow. Display decides what I stare at tonight. #### Evidence to name User’s Guide §4.10 example tcp port 23 and host 10.0.0.5 ; wiki CaptureFilters; §6.3 “all packets remain in the capture file.” ### Q3 · Evidence — which fields prove the handshake A lead says “I see TCP, so the session is up.” What do you put in the ticket so a second analyst can replay the proof? Direct answer Three frames with flags SYN; SYN,ACK; ACK. Quote tcp.seq / tcp.ack (seq=x, syn-ack seq=y ack=x+1, ack=y+1). Quote tcp.completeness==7 if you want the analyzer’s summary. Name tcp.stream , both ports, and iRTT. “Protocol column says TCP” is not a handshake. Why production cares Half-open sessions, port reuse, and RSTs all still “look like TCP.” Completeness bits exist so you can filter conversations that actually opened. Weak answer / trap Pasting a colored Expert bar, or citing only tcp.port == 443 . #### Strong framing (say this) If I cannot point at SYN, SYN-ACK, and ACK on one stream index, I do not have a session yet. #### Evidence to name tcp.flags.syn , tcp.flags.ack , tcp.seq , tcp.ack , tcp.completeness (1+2+4=7), tcp.stream , tcp.analysis.initial_rtt . ### Q4 · Troubleshoot — latency versus loss Users say the portal is slow. Capture at the client shows iRTT 38 ms, then a 1.8 s gap before the HTTP response, then later a burst of duplicate ACKs and a fast retransmission. A junior wants to “tune the WAN QoS.” First check? Direct answer Split the timeline. The 1.8 s gap with no tcp.analysis.flags is delay — server think time or an upstream hop, not a drop. The later Dup ACK + tcp.analysis.fast_retransmission is loss or reordering on that stretch. They can both be true. Do not treat iRTT as the page-load time, and do not treat one retransmit as the 1.8 s stall. Why production cares QoS will not shrink a 1.8 s application gap. Retransmits will not explain a clean SEQ/ACK pause. Wrong owner costs a week. Weak answer / trap “Anything red in Expert Info is packet loss” or “high RTT means we are dropping.” #### Strong framing (say this) I name the quiet gap and the loss flags as two findings. iRTT is the handshake, not the GET. #### Evidence to name tcp.analysis.initial_rtt , tcp.time_delta , tcp.analysis.ack_rtt , tcp.analysis.duplicate_ack , tcp.analysis.fast_retransmission . ### Q5 · Architecture — draw the handshake and the tap “Walk the packets from the client click until you have a pcap we can trust.” They want order and a capture point, not a product tour. Direct answer Client sends SYN (seq=x). Server should send SYN-ACK (seq=y, ack=x+1). Client sends ACK (ack=y+1). Data follows. I capture on the NIC that must see those three: client for “my PC,” server for “the listener,” SPAN/TAP for a third host because a switch will not flood unicast to my port. BPF limits the file. After open, Wireshark runs TCP analysis once in list order and I display-filter the stream. Why production cares Promiscuous mode is not a mirror. USB NICs lie about time. The wrong tap manufactures a “lost segment” that the network never dropped. Weak answer / trap “Wireshark sees the whole VLAN if I check promiscuous” on a switched access port. #### Strong framing (say this) SYN, SYN-ACK, ACK. I can point at the hop that should have copied those frames. #### Evidence to name RFC 9293 handshake; SPAN/TAP vs access port; §4.10 BPF; §7.5 analysis-once; §7.6 USB timestamp warning. ### Q6 · Troubleshoot — Follow Stream on an HTTP 500 Handshake is complete. iRTT 12 ms. No retransmits. The user still sees an error. A teammate is already graphing TCP throughput. What do you do first? Direct answer Follow TCP Stream on that tcp.stream . Read the ASCII: request line, status code, server header. An HTTP 500 on a healthy TCP session is an application ticket. Close leaves the stream filter on so you can jump back to the packets that carried the body. If the payload is TLS and you do not have keys, say so — Follow will not decrypt it for you (wiki TLS). Why production cares Throughput graphs on a 12 ms, lossless stream waste the change window. The error is in the bytes. Weak answer / trap Following stream 0 because it is first, or hitting Back and losing the filter before you screenshot the 500. #### Strong framing (say this) TCP already did its job. I Follow, I quote the status line, I hand it to the app owner. #### Evidence to name Analyze → Follow → TCP Stream; tcp.stream eq N ; Close vs Back; client red / server blue; HTTP status in ASCII. ### Q7 · Compare — RST versus FIN versus Zero Window Three pcaps land on your desk. A: server sends RST after the GET. B: both sides exchange FIN. C: server packets show window 0, then a window update two seconds later. A junior calls all three “the connection dropped.” Separate them. Direct answer RST ( tcp.flags.reset / tcp.connection.rst ) aborts — closed port, application reset, or a middlebox. FIN is an orderly close. Zero Window ( tcp.analysis.zero_window ) is flow control: the receiver advertised it cannot take more data; the sender must pause until a window update. The User’s Guide even notes a printer pausing a job as a normal Zero Window. Why production cares You escalate RST to the device that sent it. You do not reboot a WAN circuit for a receiver that filled its buffer. You do not treat FIN as an outage. Weak answer / trap “RST means the firewall is blocking” without checking which IP set the flag, or calling Zero Window “packet loss.” #### Strong framing (say this) RST aborts. FIN finishes. Zero Window asks me to wait. I say which IP set the bit. #### Evidence to name tcp.flags.reset , tcp.flags.fin , tcp.analysis.zero_window , tcp.analysis.window_update , tcp.window_size == 0 && tcp.flags.reset != 1 . ### Q8 · Unsafe shortcut — capture the whole SPAN, decrypt later Someone enables a 10 Gb/s SPAN to their laptop, no BPF, “we will display-filter in the morning,” and asks for the production TLS private key so Follow Stream is readable. What do you undo? Direct answer Stop the SPAN or apply a capture filter now ( host … and tcp port … ). Ring-buffer the file if the window must stay wide. Do not copy a production private key onto an analyst laptop — that is a key-compromise ticket, not a pcap trick. If TLS visibility is required, use an approved decrypt point or session keys the client already exported, following the wiki TLS process. Hunt the overnight file only if the disk survived; otherwise the evidence is gone. Why production cares Unfiltered SPAN fills disks and can degrade the mirrored switch. Private keys do not belong in a ticket attachment. Weak answer / trap “Display filters are powerful enough, capture everything,” or pasting the server key into Wireshark preferences on a shared PC. #### Strong framing (say this) I filter on the way in. I decrypt only with an approved key path. I do not steal the certificate’s private key to pass an interview demo. #### Evidence to name §4.10 capture filter; ring buffer / multiple files; wiki TLS key log; who owns the cert private key. ## 8. Traps and proof checklist Trap What you see Safer next step Display syntax in the capture box tcp.port == 443 rejected or captures nothing Write tcp port 443 (BPF) Promiscuous = whole VLAN Only your host plus broadcasts Ask for SPAN or a TAP TLS debug on SYN-only Retransmitted SYNs, completeness ## Knowledge check Six judgment items. Each maps to a promise bullet. Check answers, then reset and re-read the traps table if you miss any. Q1 You must write only traffic to or from 10.0.0.5 to disk on an overnight SPAN. What goes in Capture Options? ip.addr == 10.0.0.5 host 10.0.0.5 tcp.stream eq 0 Leave the box empty and display-filter in the morning Correct: b . Capture filters are libpcap. host 10.0.0.5 is the wiki example. ip.addr == is display syntax. Re-read choose table + scenario Q2. Q2 Client sends SYN, then two SYN retransmits. No SYN-ACK, no RST. What is already ruled out? A TLS certificate or HTTP 500 — the handshake never completed A silent ACL or a down listener — those cannot cause this The need to recapture at the server tcp.completeness still being below 7 Correct: a . No SYN-ACK means no TLS and no HTTP body. Re-read handshake SVG + scenario Q1. Q3 Which pair is the honest signature of loss rather than delay? High tcp.analysis.initial_rtt and a clean SEQ/ACK tree tcp.time_delta of 1.8 s with no analysis flags tcp.analysis.retransmission (or fast retransmission) plus tcp.analysis.duplicate_ack tcp.analysis.zero_window Correct: c . Retransmits + Dup ACKs are loss/reorder. High iRTT or a quiet gap is latency. Zero Window is the receiver pausing. Re-read choose table + Q4. Q4 You select a packet and choose Analyze → Follow → TCP Stream. What did Wireshark just do? Installed a new capture filter so later packets never hit disk Applied a display filter for that stream and opened the reconstructed bytes (client red, server blue) Rewrote tcp.analysis flags for the whole file Decrypted TLS automatically Correct: b . User’s Guide §7.2: Follow applies a display filter and shows the stream. Close keeps it; Back restores the previous filter. Re-read Side C + Q6. Q5 Server packets show window 0, no SYN/FIN/RST, then a window update. What is true? Receiver flow control — the sender must pause until the window opens The server aborted the connection the same way a RST would This is identical to tcp.analysis.lost_segment The handshake is incomplete Correct: a . §7.5 Zero Window: receive window is zero and SYN/FIN/RST are not set. Re-read Q7 + flags table. Q6 iRTT is 40 ms. After the ACK there is a 2 s gap, then an HTTP 200, and tcp.analysis.flags never fires. Best first sentence? Packet loss — Expert Info would have been red if I had scrolled RST from the firewall hid the drops Zero Window on the client Latency or server think time — the SEQ/ACK tree is clean, so this is not loss Correct: d . A quiet gap with no analysis flags is delay. iRTT is only the handshake. Re-read runtime SVG + Q4. Check answers Reset ## Sources - Wireshark User’s Guide §4.10 — Filtering while capturing (libpcap / BPF; tcp port 23 and host 10.0.0.5 ) - Wireshark Wiki — CaptureFilters (capture is not a display filter; host 172.18.5.4 ) - pcap-filter man page — capture-filter primitives and TCP flag bytes - Wireshark User’s Guide §6.3 — Filtering packets while viewing (file contents unchanged) - Wireshark User’s Guide §6.4 — Building display filter expressions - Wireshark Wiki — DisplayFilters ( tcp.port == 80 ; Zero Window example; ip.addr gotcha) - wireshark-filter(4) — display filter language - Display Filter Reference — Transmission Control Protocol ( tcp.flags.* , tcp.analysis.* , tcp.stream , tcp.completeness , tcp.time_delta ) - Wireshark User’s Guide §7.2 — Following protocol streams (filter, colors, Close vs Back) - Wireshark User’s Guide §7.5 — TCP analysis (retransmission, Dup ACK, Zero Window, completeness bits) - Wireshark User’s Guide §7.6 — Time stamps (from libpcap/OS; USB NIC warning) - RFC 9293 — TCP (3-way handshake and flags) Related: SOC analyst interview · Linux interview · CCNA interview · VAPT interview · Interview hub --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt