3

In Ubuntu 12.04 I can use the tcpdump command to see network packets in real time. A typical invocation could look like this: tcpdump -pni eth0

In Ubuntu 14.04 the exact same command no longer displays packets in real time. When I run the command nothing happens for the first second. After a second it prints out all the packets transferred during the last second and then stops again.

Having packets in the packet capture show up out of order compared to other output I am looking at makes it harder to debug networking problems.

Is there any way I can get tcpdump to behave like it used to and display the packets as soon as they are transferred instead of waiting up to a second each time?

No, I cannot use WireShark as I have to debug machines that are on the Internet, not on the same LAN.

Fabby
  • 34,341
  • 38
  • 97
  • 191
kasperd
  • 1,659
  • 3
  • 17
  • 37
  • When I am debugging any network related issue, I open two xterm windows in which I run tcpdump on each end of the connection (through ssh for at least one of them). With those two xterm windows taking up only a fraction of my screen, I can easily test some actions and see in real time what packets are triggered at each end of the connection. This works great to get an initial understanding of cause and effect among the packets and to get an idea of where in the flow the problem shows up. – kasperd Jan 08 '15 at 10:18
  • @Fabby But in 14.04 tcpdump started inserting delays of up to one second before packets are being displayed on screen. This means it is no longer immediately obvious whether a packet is triggered by my action. And I can also not tell if either end of the connection was waiting for some time in the protocol I am trying to debug. It is also difficult to understand cause and effect, when delays are inserted independently at each end of the connection causing packets to sometimes be shown on screen out of order. – kasperd Jan 08 '15 at 10:20
  • 1
    @Fabby That suggestion wouldn't work for me since many of the problems I debug only happen when the machines are communicating across the internet and not when they are on the same LAN. – kasperd Jan 08 '15 at 12:14
  • Entered last comment into your question. I can't help you any further, but would advise you to [edit] your question and add the important bits of your comments into the question. Upvoting your question as it's a good one! – Fabby Jan 08 '15 at 12:19
  • I've had a similar issue, although I could live with it. I usually just use tcpdump if it's an ad-hoc troubleshooting I'm doing but out of curiousity, I checked and Wireshark acts the same way. What's common? They're both compiled against libcap - I don't have the time now but maybe something has changed in libpcap between the current and previous version available in Ubuntu (http://www.tcpdump.org/libpcap-changes.txt)? – Marcin Kaminski Jan 10 '15 at 22:45
  • Related: http://serverfault.com/questions/592127/one-second-delay-before-tcpdump-returns-packets – kasperd Jan 11 '15 at 14:26
  • @MarcinKaminski I found these two posts, which appear relevant: http://seclists.org/tcpdump/2014/q4/54 and http://permalink.gmane.org/gmane.os.openbsd.tech/40063 But after reading them I still can't say with absolute certainty whether the problem was introduced by a change in libpcap or tcpdump. – kasperd Jan 11 '15 at 14:37
  • It doesn't look to be accepted and currently the -b flag of tcpdump means: `Print the AS number in BGP packets in ASDOT notation rather than ASPLAIN notation.` so I don't think this code is in. – Marcin Kaminski Jan 11 '15 at 14:51
  • @MarcinKaminski Everything I can find suggests that patch is not in Ubuntu. But it gives some hint about where the problem lies. It might be the only option is to compile `tcpdump` myself using either the sources from 12.04 or by patching the 14.04 sources. – kasperd Jan 11 '15 at 15:06

0 Answers0