tcpdump shows traffic until I use a filter

Question

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?

This syntax is working on my system. What is your OS / distribution, tcpdump version? — Khaled, Feb 21 '13 at 15:22
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

score 8 · Accepted Answer · answered Feb 21 '13 at 15:38

8

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.

answered Feb 21 '13 at 15:38

the-wabbit

40,737
13
111
174

This is most likely the correct answer. For some additional context and ranting I wrote a blog post about it on the [security.se] community blog: [Misadventures with tcpdump Filters](http://security.blogoverflow.com/2012/08/misadventures-with-tcpdump-filters/) – Scott Pack Feb 21 '13 at 15:42
@ScottPack I tend to use the `(vlan or not vlan) and ` 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 03 '13 at 12:50
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 03 '13 at 12:51

tcpdump shows traffic until I use a filter

1 Answers1

Linked

Related