Bug 490047 - pcap filters don't work in F9 as they did in previous releases of Fedora
pcap filters don't work in F9 as they did in previous releases of Fedora
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-12 19:10 EDT by Mike Iglesias
Modified: 2011-06-27 10:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 10:07:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
contents of /proc/interrupts (1.74 KB, text/plain)
2009-04-13 20:12 EDT, Mike Iglesias
no flags Details

  None (edit)
Description Mike Iglesias 2009-03-12 19:10:39 EDT
Description of problem:

We have a HP DL-365 that was running Fedora 7 and argus (from www.qosient.com).  The system was reinstalled with Fedora 9, and the argus pcap filter that worked in Fedora 7 doesn't work in Fedora 9, in that the application receives no network packets at all.  The filter we had was "ip and not icmp".  This filter does not work with wireshark or tcpdump either.  If we change the filter to "not icmp" we get network packets, but the traffic includes ICMP packets, which we do not want.

eth1 is a Broadcom BCM5708 gig interface connected to a switch port that is copying all traffic going thru the switch to the port.

We have an Appro system with Broadcom BCM95704A7 interfaces where this works correctly.  That system uses the tg3 driver for the network, whereas the system with the problem uses the bnx2 driver.  I'm assuming that there is a problem with the bnx2 driver, so I'm reporting this against the kernel.


Version-Release number of selected component (if applicable):

kernel-2.6.27.19-78.2.30.fc9.i686 (HP system)
kernel-2.6.27.19-78.2.30.fc9.x86_64 (Appro system)


How reproducible:

/usr/sbin/tcpdump -i eth1 -lvn ip and not icmp


Steps to Reproduce:
1.
2.
3.
  
Actual results:

No network traffic is passed to tcpdump/wireshark/etc

Expected results:

All network traffic except ICMP packets is passed to tcpdump/wireshark/etc

Additional info:
Comment 1 Mike Iglesias 2009-04-10 11:02:36 EDT
Rolling the bnx driver back to 1.7.6b (available from Broadcom's site) seems to have fixed this issue.  I've only done some limited testing so far.
Comment 2 Mike Iglesias 2009-04-10 11:19:46 EDT
I forgot to mention that the 1.8.2b driver available from Broadcom does not work the same way as the 1.8.0 driver that comes with Fedora 9.
Comment 3 Neil Horman 2009-04-10 13:42:34 EDT
Strange, the filtering happens in the kernel, but without the knoweldge of the driver.  When you use the in-tree bnx2 driver and the "ip and not icmp" filter in wireshark, does the PROMISC flag get set in the driver (you can see this with ifconfig).  Are you using vlans or something else that might cause the location of various data fields to get shifted from their usual locations?

Also, does the problem persist if you use an F-10 or rawhide kernel (I ask because F-9 is approaching end of life, and if F-10 solves the problem, that will likely be the solution).
Comment 4 Mike Iglesias 2009-04-13 18:10:31 EDT
I've never seen PROMISC set in ifconfig output unless I've set it via ifconfig.  I just tried it on my desktop system (which has an Intel NIC) and I don't see it set there either.

In this case, there are kernel messages in /var/log/messages stating that the interface has gone into promiscuous mode.  No vlans are in use on the network being monitored, and if I just use "not icmp" I get all the traffic, including ICMP.

I installed the latest F10 kernel, but there was no difference in behaviour.

The interface that I'm using does not have an IP set on it since it's purely for monitoring the traffic being shoved at it.
Comment 5 Chuck Ebbert 2009-04-13 19:20:55 EDT
Is the adapter using multiple interrupts? (Can you post the contents of /proc/interrupts from that machine?)
Comment 6 Mike Iglesias 2009-04-13 20:12:34 EDT
Created attachment 339399 [details]
contents of /proc/interrupts
Comment 7 Neil Horman 2009-04-14 12:12:36 EDT
It just occured to me that tcpdump uses packet sockets to do capture, and the amount of filtering that gets passed to the kernel amounts to the following:
protocol; /* Physical layer protocol */
ifindex;  /* Interface number */
sll_hatype;   /* Header type */
sll_pkttype;  /* Packet type */
sll_halen;    /* Length of address */
sll_addr[8];  /* Physical layer address */

given that this works with some drivers and not others, but traffic gets through, my current though is that ha_type, ifindex, halen or add isn't getting munged on receive.  This is bnx2 right?  I don't see any changes that would directly affect these values, but I do see some tso fixes that might be relevant.  Are you running TSO?
Comment 8 Mike Iglesias 2009-04-14 12:49:31 EDT
According to ethtool, TSO is turned on for eth1, but that must be the default because I didn't do anything to turn it on.
Comment 9 Bug Zapper 2009-06-09 23:36:44 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Mike Iglesias 2009-06-25 19:17:09 EDT
This problem still exists in Fedora 11, and the 1.7.6b driver does not compile against the 2.6.29.4-167.fc11 kernel so I can't try it to see if it works with that kernel.
Comment 11 Bug Zapper 2010-04-27 09:10:50 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Mike Iglesias 2010-05-24 11:27:03 EDT
This problem is still there in Fedora 12.
Comment 13 Bug Zapper 2010-11-04 07:26:48 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Mike Iglesias 2010-11-12 16:28:51 EST
This issue still exists in Fedora 13.
Comment 15 Neil Horman 2010-11-12 19:25:05 EST
So I've been looking at the packet receive path, and I noted that, despite my previous comment, none of those fields are actually used for input filtering, they're only used for transmit.  The only filtering that the socket does is on device and protocol (which should be ETH_P_ALL for all frames if you're specifying ip and not icmp (the kernel can't filter on that)

Lets do two things:

1) use  stap to instrument packet_do_bindand confirm that we're setting the protocol argument to ETH_P_ALL

2) run a strace of tcpdump while your running your desired trace

My guess is that (1) will show us that we are using ETH_P_ALL and (2) will show tcpdump doing work (instead of blocking waiting for packets). 

My guess is that bnx2 is somehow formatting its received packets in such a way that tcpdump isn't getting all the data it needs to filter them properly.
Comment 16 Mike Iglesias 2010-11-27 12:58:18 EST
This is what I got from an strace of "tcpdump -i eth1 -lvn ip and not icmp"

# strace -p 7903
Process 7903 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)

I'm not familiar with stap so if you give me instructions on how you want it run, I can provide that information as well.
Comment 17 Bug Zapper 2011-06-02 14:12:55 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2011-06-27 10:07:53 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.