2

I'm trying to capture data with tcpdump like so:

$ sudo tcpdump -Xi eth0

I have the device and the PC connected to each other. On both sides I launch a simple test application that sends a message to the other.

The problem is that although both sides get the messages, tcpdump didn't print anything. Only an ARP requests sometimes is seen (an ARP requests for another PC which is not currently connected to the LAN).

$  ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0f:ea:62:ce:d6  
          inet addr:10.5.57.197  Bcast:10.5.255.255  Mask:255.255.0.0
          inet6 addr: fe80::20f:eaff:fe62:ced6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:66497 errors:0 dropped:4334 overruns:0 frame:0
          TX packets:3785 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6539170 (6.5 MB)  TX bytes:553828 (553.8 KB)
          Interrupt:21 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:529 errors:0 dropped:0 overruns:0 frame:0
          TX packets:529 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:71721 (71.7 KB)  TX bytes:71721 (71.7 KB)
  • Can you show that your app is listening on either 0.0.0.0 or specifically on the IP above? Use netstat -tapn and look for the port that it's listening on to confirm. – slm Sep 16 '14 at 13:37
  • It seems like a network problem. Can you please show the other machine ifconfig too? – Fale Sep 16 '14 at 13:41
  • @Fale, no, it wasn't the network problem, it is a problem with the «tcpdump», see my comment to the accepted answer. – Hi-Angel Sep 16 '14 at 14:40
3

I suggest you capture the packets and write them to a file with the <file>.pcap extension, and then open with wireshark.

For example, in CentOS, to capture the packets:

$ tcpdump -i eth0 -s 1500 -w /root/<filename.pcap>
  • Hmm… I have no idea why, but the «tcpdump» prints a packets only with the -w option. Your answer is the correct. – Hi-Angel Sep 16 '14 at 14:37
  • 2
    Use -n with tcpdump to stop it trying to resolve IP addresses to names, which can take a long time. – wurtel Sep 16 '14 at 14:41
  • @wurtel yeah! Now it works! So this was the problem! – Hi-Angel Sep 16 '14 at 14:46
  • @vallikkv can one captures the packets on the link-local interface ? – Bionix1441 Nov 13 '17 at 12:34
2

Something else must be up. The following test works fine for me. I'm using socat as both the client and server and I'm running tcpdump on my local system that I'm sitting at.

1. Setup socat server (listener)

$ socat - TCP-LISTEN:2222,crlf

2. Setup socat client

$ socat - TCP:192.168.1.80:2222

3. Now I run tcpdump:

$ sudo tcpdump -Xi wlp1s0 src 192.168.1.3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp1s0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:04:27.977900 ARP, Request who-has 192.168.1.149 tell client.mydom.net, length 46
    0x0000:  0001 0800 0604 0001 0019 d1e8 4c95 c0a8  ............L...
    0x0010:  0103 0000 0000 0000 c0a8 0195 0000 0000  ................
    0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
10:04:29.206642 ARP, Request who-has 192.168.1.149 tell client.mydom.net, length 46
    0x0000:  0001 0800 0604 0001 0019 d1e8 4c95 c0a8  ............L...
    0x0010:  0103 0000 0000 0000 c0a8 0195 0000 0000  ................
    0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
10:04:29.337077 IP client.mydom.net.49878 > server.mydom.net.EtherNet/IP-1: Flags [P.], seq 1391164406:1391164421, ack 2721007444, win 46, options [nop,nop,TS val 535977938 ecr 956529523], length 15
    0x0000:  4500 0043 8218 4000 4006 34f9 c0a8 0103  E..C..@.@.4.....
    0x0010:  c0a8 0150 c2d6 08ae 52eb 7bf6 a22f 4754  ...P....R.{../GT
    0x0020:  8018 002e 964f 0000 0101 080a 1ff2 5fd2  .....O........_.
    0x0030:  3903 7b73 5468 6973 2069 7320 6120 7465  9.{sThis.is.a.te
    0x0040:  7374 0a                                  st.

In the above scenario I typed the message "This is a test" on the client side and it showed up on the server's socat instance as well as within the output of tcpdump.

Client output:
$ socat - TCP:server.mydom.net:2222
This is a test
Server output:
$ socat - TCP-LISTEN:2222,crlf
This is a test
  • The «tcpdump» start capture a packets only with the -w option. I don't know why, but that is. – Hi-Angel Sep 16 '14 at 14:38
  • 1
    @Hi-Angel - Can you do a sudo strace -s 2000 -o tcpdump_strace.log tcpdump -Xi eth0? Something is inhibiting tcpdump from performing. It's likely something in your environment, would be my guess. – slm Sep 16 '14 at 14:48
  • @wurtel just told the real reason. – Hi-Angel Sep 16 '14 at 14:59
  • @Hi-Angel - yeah you should either write that up as an A or have wurtel do it. The one you marked isn't really the appropriate A to your issue, IMO. – slm Sep 16 '14 at 18:13
  • @Hi-Angel - the strace I suggested would've bared this out BTW 8-) – slm Sep 16 '14 at 18:14
2

For anyone who comes across this one another good answer is here https://stackoverflow.com/questions/3130911/tcpdump-localhost-to-localhost, if the traffic that isn't showing up is localhost->localhost traffic. I feel like in other situations I haven't had to do that, but at least a few times I've had to.

  • You could also do sudo tcpdump -i any, thus capturing from all existing interfaces. – Hi-Angel Jul 23 '16 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.