[TriLUG] tcpdump src matching problem

[Aaron Joyner]

Ryan Leathers wrote:

>So, tcpdump isn't matching what I want it to.
>
>Quick requirement:
>
>I want tcpdump to capture the first frame it sees of a certain multicast
>type.  I don't want it to match on a frame with a particular source
>address.  Sound simple enough?
>
>Problem:
>
>frames from the unwanted src MAC are being matched anyway
>
>
>More detail:
>
>I want to see a CDP packet from the Cisco switch I am connected to.  I
>don't care to run this 24x7.  I just need an answer-on-demand where I
>run the script and see which switch and port I am connected to.
>
>I have some parsing lines in a bash script to make the output pretty.
>I don't want to parse more than the first match I see, since that makes
>the parsing tougher, however, since I also send CDP packets out to
>advertise my Linux host to the Cisco switch, I also need to make sure
>that my own CDP multicast is not being matched or the results will be
>useless.
>
>I use this line to find my MAC address:
>export lowestmac=`ifconfig | grep HWaddr -m 1 | awk '{print $5}'`
>
>I use this line to match the frame:
>tcpdump -c 1 -tvs 1500 ether dst 01:00:0c:cc:cc:cc and not ether src
>$lowestmac > $cdpdata
>
>Then I parse the stuff in $cdpdata
>
>The trouble is the "not ether src $lowestmac" doesn't seem to be
>observed and I get matches from my Linux host anyway.
>
>Any thoughts on this?
>  
>
You're doing something screwy?  I tested as follows:

In the first terminal window:

-----8< SNIP 8<-----
asjoyner:~$ sudo arp -s 10.0.12.41 01:00:0c:cc:cc:cc
Password:
asjoyner:~$ arp -a

asjoyner:~$ arp -an
? (10.0.12.41) at 01:00:0C:CC:CC:CC [ether] PERM on eth1
asjoyner:~$ ping 10.0.12.41
PING 10.0.12.41 (10.0.12.41) 56(84) bytes of data.
<left running indefinitely>
-----8< SNIP 8<-----

In the second terminal window:

-----8< SNIP 8<-----
asjoyner:~$ sudo tcpdump -eni eth1 ether dst 01:00:0c:cc:cc:cc and not 
ether src 00:10:18:0D:20:83
tcpdump: listening on eth1

0 packets received by filter
0 packets dropped by kernel
asjoyner:~$ sudo tcpdump -eni eth1 ether dst 
01:00:0c:cc:cc:cc                                   
tcpdump: listening on eth1
09:21:01.407840 0:10:18:d:20:83 1:0:c:cc:cc:cc ip 98: 10.0.12.1 > 
10.0.12.41: icmp: echo request (DF)
09:21:02.407875 0:10:18:d:20:83 1:0:c:cc:cc:cc ip 98: 10.0.12.1 > 
10.0.12.41: icmp: echo request (DF)
09:21:03.407897 0:10:18:d:20:83 1:0:c:cc:cc:cc ip 98: 10.0.12.1 > 
10.0.12.41: icmp: echo request (DF)

3 packets received by filter
0 packets dropped by kernel
asjoyner:~$ sudo tcpdump -tvs 1500 -c 1 -eni eth1 ether dst 
01:00:0c:cc:cc:cc and not ether src 00:10:18:0D:20:83
tcpdump: listening on eth1
<control C>
0 packets received by filter
0 packets dropped by kernel
asjoyner:~$ sudo tcpdump -tvs 1500 -c 1 -eni eth1 ether dst 
01:00:0c:cc:cc:cc
tcpdump: listening on eth1
0:10:18:d:20:83 1:0:c:cc:cc:cc ip 98: 10.0.12.1 > 10.0.12.41: icmp: echo 
request (DF) (ttl 64, id 0, len 84)
1 packets received by filter
0 packets dropped by kernel
-----8< SNIP 8<-----

As you can see, it works like a charm for me, both with your tcpdump 
args (and a little extra -eni for my debugging and environment) and with 
out.  I don't know what's flaky about your system or setup that's 
causing the abnormal behavior.  Are you sure you have the MAC address 
right?  My testing (contrary to my previous understanding) showed that 
my current version of tcpdump isn't sensitive to case in the MAC 
address, but I could have sworn I've played with versions that insisted 
on lower-case letters in the MAC, so that might be something to check.  
If config outputs upper case, use `| tr A-Z a-z` to be sure.

Let me know what it is if you figure it out, sounds like a curious and 
fun problem,
Aaron S. Joyner