Bug#299642: filter expressions not working in tcpdump and tet hereal
Title: RE: Bug#299642: filter expressions not working in tcpdump and tethereal Here's the commands, one unfiltered, the other filtered, and their associated output. In these examples we have a continuous ping running to 150.4.1.70 which is another system on a Cisco switch. We have a monitor session set up mirroring the traffic to and from the port to which 150.4.1.70 is connected to the port connected to eth1 on the Debian system in question. We know the monitor session works fine and capturing traffic on eth1 works because the unfiltered command shows the ICMPs to and from 150.4.1.70. When we add 'host 150.4.1.70' to the end of it, we don't see any of the ICMPs or anything. vsniff02:~# tcpdump -nn -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 19:22:24.340599 IP 150.4.1.249.1985 224.0.0.2.1985: HSRPv0-hello 20: state=active group=11 addr=150.4.1.20 19:22:24.751056 arp who-has 150.4.1.139 tell 150.4.1.5 19:22:25.086560 802.1d config c00b.00:0a:8a:c3:e5:40.8011 root 8000.00:05:5e:34:6e:86 pathcost 3038 age 2 max 20 hello 2 fdelay 15 19:22:25.826276 arp who-has 150.4.1.20 tell 150.4.1.175 19:22:25.826406 arp who-has 150.4.1.20 tell 150.4.1.174 19:22:26.071616 03:00:c7:00:00:ee 00:08:02:b2:dd:89 sap aa test/P len=63 0x: 0300 c700 00ee 0008 02b2 dd89 8100 000b 0x0010: 0042 f300 805f 0002 .B._ 0x0020: 0x0030: 0x0040: .. 19:22:26.290929 IP 172.19.16.69 150.4.1.70: icmp 131: echo request seq 52830 19:22:26.291030 IP 150.4.1.70 172.19.16.69: icmp 131: echo reply seq 52830 19:22:27.089326 802.1d config c00b.00:0a:8a:c3:e5:40.8011 root 8000.00:05:5e:34:6e:86 pathcost 3038 age 2 max 20 hello 2 fdelay 15 19:22:27.328528 IP 150.4.1.249.1985 224.0.0.2.1985: HSRPv0-hello 20: state=active group=11 addr=150.4.1.20 19:22:27.758324 arp who-has 150.4.1.134 tell 150.4.1.249 19:22:27.840783 00:0a:8a:c3:e5:51 00:0a:8a:c3:e5:51, ethertype Loopback (0x9000), length 60: 0x: 0100 0x0010: 0x0020: .. 19:22:28.244921 (NOV-802.2) .00:00:c9:03:82:38.4013 .ff:ff:ff:ff:ff:ff.0452:ipx-sap-nearest-req 0004 0x: c903 8238 8100 000b ...8 0x0010: 0025 e0e0 03ff ff00 2200 1100 00ff .%. 0x0020: ff04 5200 00c9 0382 ..R. 0x0030: 3840 8@ 19:22:28.790820 IP 172.19.16.69 150.4.1.70: icmp 131: echo request seq 53086 19:22:28.790917 IP 150.4.1.70 172.19.16.69: icmp 131: echo reply seq 53086 19:22:29.071486 03:00:c7:00:00:ee 00:08:02:b2:dd:89 sap aa test/P len=63 0x: 0300 c700 00ee 0008 02b2 dd89 8100 000b 0x0010: 0042 f300 805f 0002 .B._ 0x0020: 0x0030: 0x0040: .. 19:22:29.094234 802.1d config c00b.00:0a:8a:c3:e5:40.8011 root 8000.00:05:5e:34:6e:86 pathcost 3038 age 2 max 20 hello 2 fdelay 15 19:22:29.249710 (NOV-802.2) .00:00:c9:03:82:38.4013 .ff:ff:ff:ff:ff:ff.0452:ipx-sap-nearest-req 0004 0x: c903 8238 8100 000b ...8 0x0010: 0025 e0e0 03ff ff00 2200 1100 00ff .%. 0x0020: ff04 5200 00c9 0382 ..R. 0x0030: 3840 8@ 19:22:29.573855 arp who-has 150.4.1.125 tell 150.4.1.5 19:22:29.772743 arp who-has 150.4.2.144 tell 150.4.1.5 19:22:29.810330 IP 150.4.1.40.121 150.4.1.255.121: UDP, length: 22 19:22:30.236465 IP 150.4.1.249.1985 224.0.0.2.1985: HSRPv0-hello 20: state=active group=11 addr=150.4.1.20 19:22:30.260050 (NOV-802.2) .00:00:c9:03:82:38.4013 .ff:ff:ff:ff:ff:ff.0452:ipx-sap-nearest-req 0004 0x: c903 8238 8100 000b ...8 0x0010: 0025 e0e0 03ff ff00 2200 1100 00ff .%. 0x0020: ff04 5200 00c9 0382 ..R. 0x0030: 3840 8@ 19:22:31.097392 802.1d config c00b.00:0a:8a:c3:e5:40.8011 root 8000.00:05:5e:34:6e:86 pathcost 3038 age 2 max 20 hello 2 fdelay 15 19:22:31.270106 (NOV-802.2) .00:00:c9:03:82:38.4013 .ff:ff:ff:ff:ff:ff.0452:ipx-sap-nearest-req 0004 0x: c903 8238 8100 000b ...8 0x0010: 0025 e0e0 03ff ff00 2200 1100 00ff .%. 0x0020: ff04 5200 00c9 0382 ..R. 0x0030: 3840 8@ 19:22:31.287067 IP 172.19.16.69 150.4.1.70: icmp 131: echo request seq 53342 19:22:31.287153 IP 150.4.1.70 172.19.16.69: icmp 131: echo reply seq 53342 19:22:32.071355 03:00:c7:00:00:ee 00:08:02:b2:dd:89 sap
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 only = 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/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299642: filter expressions not working in tcpdump and tet hereal
Title: RE: Bug#299642: filter expressions not working in tcpdump and tet hereal 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/ `-
Bug#299642: filter expressions not working in tcpdump and tet hereal
Tyler West [EMAIL PROTECTED] writes: 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 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. Indeed that is the problem. For some reason, recent libpcap versions do not match on tagged packets anymore. This is Debian bug #267765: URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267765 I guess your setup will work fine if you convince the Cisco switch to untag traffic before sending it to the Debian box. Unfortunately, I don't have convenient access to any VLAN-capable hardware so I cannot debug this properly at the moment. Sorry. Thanks for all the information you provided! -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299642: filter expressions not working in tcpdump and tet hereal
Romain Francoise [EMAIL PROTECTED] writes: 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 Also, does it show the frames if you use the vlan keyword? = tcpdump -n -i eth0 vlan 11 and proto \\icmp -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299642: filter expressions not working in tcpdump and tet hereal
Title: RE: Bug#299642: filter expressions not working in tcpdump and tet hereal My deepest apologies for chasing something that is right there in the man page for tcpdump although I didn't realize the frames were tagged until we got deeper into it. From the Cisco standpoint, older versions of IOS running on Catalyst workgroup switches (this one was specifically a 2950 running 12.1(9)) copy packets to the destination interface with the VLAN tags included by default. At some point in a later release they began supporting the option to copy the frames tagged or untagged. The addition of the vlan keyword worked perfectly. Thank you for your time. Tyler -Original Message- From: Romain Francoise [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 15, 2005 3:35 PM To: Tyler West Cc: [EMAIL PROTECTED] Subject: Re: Bug#299642: filter expressions not working in tcpdump and tet hereal Romain Francoise [EMAIL PROTECTED] writes: 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 Also, does it show the frames if you use the vlan keyword? = tcpdump -n -i eth0 vlan 11 and proto \\icmp -- ,''`. : :' : Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `-
Bug#299642: filter expressions not working in tcpdump and tet hereal
Tyler West [EMAIL PROTECTED] writes: My deepest apologies for chasing something that is right there in the man page for tcpdump although I didn't realize the frames were tagged until we got deeper into it. No apology necessary; there is really a bug. It should match on the VLAN packets nonetheless, and it used to. -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
