This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP state of incoming packets - tcpdump

0

Is there anyway to capture the sate of ONLY incoming packets to the sender (like the tcpprobe does) using either tcpdump or wireshark (or tshark)? I tried with the following command but i am not getting the right packets. This only captures packets with length of less than the MTU (outstanding bytes). I am sending an iperf traffic from the client (10.0.0.1) to the server (10.0.0.2).

sudo tcpdump -i eth1 tcp and dst host 10.0.0.1 -w test.pcap

asked 15 May '17, 07:38

armodes's gravatar image

armodes
16181923
accept rate: 0%

edited 15 May '17, 07:47

Can you clarify? A "sender" is someone sending, so it's outgoing, not incoming. Do you mean a "server"? Not really sure what you're trying to get... using the "dst host" part should make sure you only get one direction.

(15 May '17, 13:31) Jasper ♦♦

yes the sender is someone sending Jasper and its ip is 10.0.0.1

(16 May '17, 03:21) armodes

Then dst host 10.0.0.1 will capture packets sent to the "sender". See my answer.

(16 May '17, 11:17) Guy Harris ♦♦

One Answer:

0

Both Wireshark/TShark/dumpcap and tcpdump capture packets, not "state", so I assume you mean that you only want to capture packets going in one direction. If the "sender" is the host sending the perf traffic, i.e. 10.0.0.1, you would want a filter of

tcp and src host 10.0.0.1

I.e., you want packets with the sender's IP address as the source (src), not as the destination (dst).

As for "packets with length of less than the MTU", I presume you mean "less than or equal to" - there's nothing that should prevent full-MTU-size packets from being captured - and the "M" in "MTU" stands for "maximum", so the only way you should ever see packets with a length greater than the MTU is if packets are being handed to the capture mechanism after TCP reassembly, for example, if the network adapter is doing TCP reassembly (TCP reassembly offloading) or if the kernel is not directly handing received packets to the capture mechanism but is, instead, handing the results of TCP reassembly to the capture mechanism.

answered 15 May '17, 19:00

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

but that's not how tcpprobe works.

(16 May '17, 08:04) armodes

"probe" and "dump" are different words; why does the way that tcpprobe work matter here?

(16 May '17, 11:17) Guy Harris ♦♦

because i want to infer the congestion window of the sender from the traffic that we capture

(17 May '17, 17:58) armodes

Then you definitely need something that works differently from tcp_probe, because the tcp_probe kernel module works by "inserting a hook into the tcp_recv processing path" on the machine on which you're running it - if you want to infer the congestion window purely from network traffic, you need something different. (It's like trying to diagnose a medical disorder without actually being able to do tests on the patient.)

I.e., the tcp_probe kernel module has access to the connection state on that machine - it can just get the congestion window from the kernel TCP code's data structure. Programs that capture network traffic do NOT have access to kernel state information, so they must infer it. It's literally impossible for tcpdump or TShark or Wireshark or any other network analyzer to work like a Linux kernel module such as tcp_probe.

So you'll have to capture whatever traffic is needed for whatever code you're going to use to read the capture and infer the congestion window (the congestion window is not something that's transmitted over the wire!), and, if you're going to use a capture filter, you'll have to use a capture filter that captures the traffic you need. tcp and dst host 10.0.0.1 will capture packets sent to 10.0.0.1; tcp and src host 10.0.0.1 will capture packets sent from 10.0.0.1; tcp and host 10.0.0.1 will capture packets sent to or from 10.0.0.1.

(17 May '17, 18:21) Guy Harris ♦♦