I have a server that is receiving traffic from a mirror port on a switch. The interface that is connected to this mirror port is in promisc mode. When I use just a plain catch all tcpdump on the interface, like

tcpdump -nn -i eth1

I see a ton of traffic. I can even grep this for certain things like, say, port 443.

tcpdump -nn -i eth1 | grep 443

obviously this shows anything that has a 443 in it, not just port 443. I have visually inspected it and I do see stuff like this:

15:08:08.112550 IP > . ack 35124 win 32768

But I want just port 443 so...

tcpdump -nn -i eth1 port 443
0 packets captured

Weird. I am not seeing any traffic when I use a filter. I have tried "ip port", "dst port", and a few other filters. I have also tried filtering by the IP instead of port. Nothing.

eth1      Link encap:Ethernet  HWaddr 00:24:81:A5:AD:7A  
          inet6 addr: fe80::224:81ff:fea5:ad7a/64 Scope:Link
          RX packets:4114781478 errors:0 dropped:1 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2240970313430 (2.0 TiB)  TX bytes:15155497 (14.4 MiB)
          Interrupt:98 Memory:fa000000-fa012800 

This interface has seen a ton of traffic. And my filter is valid, right? Why do I not see anything?

  • 1
    This syntax is working on my system. What is your OS / distribution, tcpdump version? – Khaled Feb 21 '13 at 15:22
  • 1
    Yes, your filter is valid. Are you absolutely sure there is traffic on that port? Have you tried running two instances at the same time, one with the grep, the other one with the filter? – Attila O. Feb 21 '13 at 15:23
  • your syntax is valid, tested it in Ubuntu 11.04 and RHEL 5. Try tcpdump -i any -qnn port 443 for a change. – Daniel t. Feb 21 '13 at 15:36
  • Did you try tcp port 443? – Alexander Janssen Feb 21 '13 at 17:01

A possible reason is that tcpdump has received a packet which is either encapsulated into another protocol or a frame wich for example has been tagged with a VLAN ID.

You do not see this in tcpdump's output as you have not specified any verbosity arguments, but your filter does not match as your port 443 would basically imply not vlan and (proto tcp or proto udp) and port 443.

You also could verify this by dumping the frame in hex using -xx and analyzing the frame data. If you know the VID in question, simply add and vlan <VID> to your filter to get the packets captured.

| improve this answer | |
  • This is most likely the correct answer. For some additional context and ranting I wrote a blog post about it on the Information Security community blog: Misadventures with tcpdump Filters – Scott Pack Feb 21 '13 at 15:42
  • @ScottPack I tend to use the (vlan or not vlan) and <other filters> notion to tcpdump. It is as easy to remember as to be or not to be and does not change the logical syntax of the rest of your filters. – the-wabbit Feb 21 '13 at 16:13
  • Ok, that traffic is tagged on a VLAN and if I use tcpdump and add the "vlan 123" stuff it shows traffic. Awesome. I didn't realize that the tagging actually adds bytes to the header. – MichaelB Feb 21 '13 at 16:51
  • @MichaelBeattie: Oh yeah it's all kinds of fun stuff. As frustrating as that debugging was the research was pretty enlightening. Sometimes you'll also see double-tagging. – Scott Pack Feb 21 '13 at 17:48
  • No need to know the VLAN ID to test. Jusr run 'tcpdump ... vlan and port 443' and, if you see packets, you'll know it was indeed an issue with VLAN tagging. – bortzmeyer Mar 3 '13 at 12:50

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.