I'm running the following command on my backbone to monitor multicast traffic. I'm new to tcpdump usage and looking for some help:

sudo tcpdump -i eth1 -n -p multicast

I see a output like this - this is only part of it. I really don't know how to interpret this output. Can someone shed some light please. The first few lines I see seem to be normal traffic, but then I see the rest and I don't know what to make of it. And why is it only showing ARP? Sorry if some of those questions seem basic. Thank you in advance.

22:18:22.038264 ARP, Request who-has tell, length 46
22:18:22.244856 ARP, Request who-has tell, length 46
22:18:22.245149 ARP, Request who-has tell, length 46
22:18:22.888851 b4:99:ba:02:18:66 > Broadcast, ethertype Unknown    (0xcafe), length 90:
        0x0000:  0500 0100 0900 0000 0100 ffff 0c00 0002  ..... ...........
        0x0010:  4c00 0000 0000 0000 8300 0080 0000 0000  L...............
       0x0020:  0000 0000 4a59 7a55 ffff ffff 0000 0000  ....JYzU........
       0x0030:  8002 c000 0620 b499 ba02 1866 0103 0300  ...........f....
       0x0040:  0101 0402 515d 7303 7cda ca52            ....Q]s.|..R
       22:18:22.888860 b4:99:ba:02:18:66 > Broadcast, ethertype Unknown (0xcafe), length 90:
        0x0000:  0500 0100 0961 0200 0100 ffff 0c00 3a02  .....a........:.
        0x0010:  4c00 0000 0000 0000 8300 0080 0000 0000  L...............
        0x0020:  0000 0000 4a59 7a55 ffff ffff f74a 1789  ....JYzU.....J..
        0x0030:  5010 c000 0614 b499 ba02 1866 0a0a 0a00  P..........f....
        0x0040:  0101 0402 0000 0000 7cda ca52            ........|..R
  • Do you by any chance have Veritas?
    – Ron Trunk
    Jul 12, 2015 at 16:36
  • Why the flag -p Don't put the interface into promiscuous mode. ?
    – Pieter
    Jul 12, 2015 at 18:27
  • Hi no I do not have Veritas - not sure why it does not do that Jul 12, 2015 at 21:11
  • Interesting. This looks just like LLT, which is used by Veritas. See wiki.wireshark.org/LLT
    – Ron Trunk
    Jul 12, 2015 at 21:47
  • I can probably help. I've already begun preparing a potential answer for you.. What exactly is your question though? What are you trying to do? Are you just exploring or do you have a specific task or goal in mind? I have a few different ideas for you to try out.
    – voices
    Oct 12, 2015 at 11:40

2 Answers 2


Basic information about how to interpret tcpdump output can be found in the tcpdump man page. Just do man tcpdump on your machine and read (and make some notes, there's a lot of stuff there). Next, you may find google and query tcpdump tutorial helpful, as again - a lot of information shown by tcpdump will be protocol-specific. Couple of good, introductory tutorials:

You may also find Wireshark, an GUI tool built on tcpdump fundamentals a good resource to use in daily work and as a base reference for protocol decoding.

Answering your specific question: why you're trying to monitor multicast on this specific node? If you want to monitor multicast in core of the network, you should SPAN/RSPAN your traffic to this host and then sniff it using favorite tool - be it tcpdump. If that's a switched network you're connected to, you'll see few if any multicast packets - your station doesn't have (by default) means to become active destination of all multicast traffic unless it registers to be it (and that requires additional work, besides running sniffer alone).

  • Thanks for the information you provided. I will look the documents up in due course. The Server that ran the above tcpdump command on has joined the multicast group, Still no one seems to answer my question that I have posed directly. Jul 13, 2015 at 16:05
  • You didn't enable the promiscious mode, so whatever tcpdump reports is getting to your network interface card just because it was directed to it. First three lines show ARP traffic, last two seems to be something identified as broadcast for Veritas. Jul 13, 2015 at 19:46

First edition of TCP/IP Illustrated is also very helpful. You can know about protocols and their behavior also.

An Example -

1023873914.125606 fulton.ssh > spider.1145: P 3066603742:3066603806(64) ack 1646168

4510 0068 7e87 4000 4006 3862 c0a8 011e

c0a8 0128 0016 0479 b6c8 a8de 621e 87db


is the time the packet came across our network card (not part of the packet)

fulton.ssh > spider.1145

is the source & source port and destination & destination port of the communication taking place


is TCP flag


is the byte sequence/ range

A typical IP header is 20 bytes in length and TCP is another 20 bytes. And 2 digits in hex is equivalent to one byte. So that means that the headers lie within the first 20 chunks of hex.

c0 = (12 x 16) + (0 x 1) = 192

a8 = (10 x 16) + (8 x 1) = 168

01 = ( 0 x 16) + (1 x 1) = 1

28 = ( 2 x 16) + (8 x 1) = 40

For more details please check this link.



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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