7

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 12.34.56.78.1430 > 87.65.43.21.443: . 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
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          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?

Improve this question
4
  • 1
    This syntax is working on my system. What is your OS / distribution, tcpdump version?
    – Khaled
    Feb 21, 2013 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, 2013 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, 2013 at 15:36
  • Did you try tcp port 443?
    – Alexander Janssen
    Feb 21, 2013 at 17:01

1 Answer 1

Reset to default
9

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
6
  • 1
    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, 2013 at 15:42
  • 1
    @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, 2013 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, 2013 at 16:51
  • 1
    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, 2013 at 12:50
  • 1
    Easier than -xx : 'tcpdump -e' If you see "ethertype 802.1Q (0x8100)" instead of "ethertype IPv4 (0x0800)", it means the packet is indeed VLAN-tagged.
    – bortzmeyer
    Mar 3, 2013 at 12:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .