More captures below which will include the Ethernet addresses you asked for...
vsniff02:/proc/net# tcpdump -O -i eth1 -nn -e | grep icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
20:43:54.919506 00:08:7c:d3:76:c2 > 00:08:02:8d:39:80, ethertype 802.1Q (0x8100), length 169: vlan 11, p 0, ethertype IPv4, IP 172.19.16.69 > 150.4.1.70: icmp 131: echo request seq 42883
20:43:54.919601 00:08:02:8d:39:80 > 00:00:0c:07:ac:0b, ethertype 802.1Q (0x8100), length 169: vlan 11, p 0, ethertype IPv4, IP 150.4.1.70 > 172.19.16.69: icmp 131: echo reply seq 42883
20:43:55.931458 00:08:7c:d3:76:c2 > 00:08:02:8d:39:80, ethertype 802.1Q (0x8100), length 169: vlan 11, p 0, ethertype IPv4, IP 172.19.16.69 > 150.4.1.70: icmp 131: echo request seq 43395
20:43:55.931551 00:08:02:8d:39:80 > 00:00:0c:07:ac:0b, ethertype 802.1Q (0x8100), length 169: vlan 11, p 0, ethertype IPv4, IP 150.4.1.70 > 172.19.16.69: icmp 131: echo reply seq 43395
20:43:56.927513 00:08:7c:d3:76:c2 > 00:08:02:8d:39:80, ethertype 802.1Q (0x8100), length 169: vlan 11, p 0, ethertype IPv4, IP 172.19.16.69 > 150.4.1.70: icmp 131: echo request seq 43907
20:43:56.927610 00:08:02:8d:39:80 > 00:00:0c:07:ac:0b, ethertype 802.1Q (0x8100), length 169: vlan 11, p 0, ethertype IPv4, IP 150.4.1.70 > 172.19.16.69: icmp 131: echo reply seq 43907
33 packets captured
33 packets received by filter
0 packets dropped by kernel
vsniff02:/proc/net# tcpdump -O -i eth1 -nn -e proto \\icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
vsniff02:/proc/net#
vsniff02:/proc/net# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:10:18:0C:0F:1A
inet addr:150.4.1.68 Bcast:150.4.255.255 Mask:255.255.255.0
inet6 addr: fe80::210:18ff:fe0c:f1a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16283 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6046961 (5.7 MiB) TX bytes:398 (398.0 b)
Interrupt:169
vsniff02:/proc/net#
As you can see I turned off the optimizer and tried to isolate the traffic by icmp but to no avail. My Debian box is not configured as a bridge (something I've wanted to try but never have done) so that should not be an issue. I also confirmed eth1 entering and leaving promiscuous mode as expected, filter or not, in /var/log/messages.
The one thing that stood out to me is that the Cisco switch is including the 802.1q information in the Ethernet header when it is mirroring. When I did my capture on eth0 of traffic actually destined for my Debian machine there is no 802.1q information because that is removed prior to the packet exiting the Cisco switch. Could the offset created by the 802.1q field additions be affecting the filter's ability to properly match the packets?
Tyler
-----Original Message-----
From: Romain Francoise [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 15, 2005 2:29 PM
To: Tyler West
Cc: [EMAIL PROTECTED]
Subject: Re: Bug#299642: filter expressions not working in tcpdump and tet hereal
Tyler West <[EMAIL PROTECTED]> writes:
> We did find something else interesting. The eth0 interface is our
> "management" interface for the Debian system through which we access the
> box. It is addressed as 150.4.1.69. If we do continuous pings to
> 150.4.1.69 and run 'tcpdump -nn -i eth0 host 150.4.1.69' it displays the
> ICMP packets.
Hmm, so basically the bug occurs only on the eth1 interface, which
receives mirrored traffic from your switch. What are the Ethernet
addresses of the packets coming from that port (source/destination)?
(And of eth1?)
It might be that some part of the chain (libpcap/kernel) tries to
optimize things and drop packets that do not match the hardware address
of your card when you use a host filter. Or something.
Please also try the following:
- capture icmp traffic tcpdump -i eth1 proto \\icmp
- disable pcap filter optimization => tcpdump -O -i eth1
Also, I see STP traffic on the interface... Do you have a bridge
configured on the Debian host? That might make a difference.
> Is it possible that something is screwing with promiscuous mode when
> the filters are used because the filter will display packets that are
> directed to the Debian system itself?
I think the problem lies in your network configuration. The fact that
the capture works as intended on your eth0 interface proves that the
software itself is functional.
Thanks,
--
,''`.
: :' : Romain Francoise <[EMAIL PROTECTED]>
`. `' http://people.debian.org/~rfrancoise/
`-
