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).
asked 15 May '17, 07:38  armodes edited 15 May '17, 07:47 |
One Answer:
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 I.e., you want packets with the sender's IP address as the source ( 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 Harris ♦♦ 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. (17 May '17, 18:21) Guy Harris ♦♦ |
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.
yes the sender is someone sending Jasper and its ip is 10.0.0.1
Then
dst host 10.0.0.1will capture packets sent to the "sender". See my answer.