Bug 131722

Summary: tulip driver vith DECchip 21142/43 toggles PROMISC flag instead of setting PROMISC flag
Product: Red Hat Enterprise Linux 3 Reporter: Eric Paris <eparis>
Component: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: christopherreining, davem, linville, peterm, petrides, riel, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-10 18:30:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Eric Paris 2004-09-03 16:08:21 UTC
Description of problem:
The tulip driver with a DECchip 21142/43 nic card will toggle the
PRIOMISC flag off (as reported by ip link show eth0) if it is already
set.  This is a problem is 2 instances of tcpdump (WITHOUT the -p
option) or another program which sets the PROMISC flag are called
simultaneously.  The first call to tcpdump sets the flag and the
second instance of tcpdump unsets the flag.  If the second instance of
tcpdump is stopped the flag is reset.

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

How reproducible:

Steps to Reproduce:
1.  Use the correct NIC/driver
2.  Run two instances of tcpdump simultaneously(without the -p option)
3.  Check ip link show eth0

Actual Results:  the promisc flag is not set and both copies of
tcpdump only see broadcast/traffic destined for the machine

Expected Results:  the promisc flag should still be set and tcpdump
should see all traffic

Additional info:

If either of the isntances of tcpdump are stopped the flag is set
back.  When the first instance is stoped again the flag is unset (as

Comment 4 Neil Horman 2004-09-10 18:30:37 UTC
Yeah, this works on RHEL3 as well.  Its just that the way tcpdump
enables promiscuous mode now doesn't set the interface promisc flag. 
That again might be a bug, or simply misleading, but if the route
table isnt properly set, you will only get broadcast trafic on that
interface with the simple tests we've been doing.  If you reconfig the
route table to force traffic to that interface for that host, you'll
get alot more.

Comment 5 David Miller 2004-09-10 21:02:24 UTC
That's correct and all of this behavior is on purpose.

The promiscuous flag exists only to pacify the older BSD
ioctls on network devices which only allow a binary
"on/off" control of the promiscuous setting.

Whereas the method tcpdump uses via AF_PACKET is reference
count based, so you don't get problems like:

1) start tcpdump instance 1
2) start tcpdump instance 2
3) close tcpdump instance 2
4) oops tcpdump instance 1 stops seeing traffic
   because promisc got turned off by step #3

SO the reference counted promisc setting does not
show up as the promisc flag being set for the
device, as seen by deprecated tools such as ifconfig
and friends.

Things get very complicated if one of the BSD ioctls
to set/clear the binary version of the promisc state
occurs while the refernce counter version is in use.
We make reasonable efforts to provide somewhat sane
behavior here.

This is not a bug and I would close this bugzilla

Comment 6 Chris Reining 2004-09-13 19:59:02 UTC
I don't think the behavior I'm seeing is the way the promisc setting
is supposed to work and is the "correct" way. The problem I am running
into is the following which stray from the way the reference counter
should be working:

1. Start tcpdump #1 - interface goes into promisc
2. Start tcpdump #2 - interface promisc setting becomes unset (and #1
and #2 only see bcasts/ARPs)
3. Stop tcpdump  #2 - interface goes back into promisc setting (and #1
can see all traffic on the wire)


1. Start tcpdump #1 - interface goes into promisc
2. Start tcpdump #2 - interface promisc setting becomes unset (and #1
and #2 only see bcasts/ARPs)
3. Start tcpdump #3 - interface goes into promisc (and #1 #2 and #3
can see all the traffic on the wire)

1) the kernel has a bug in the way PACKET_ADD_MEMBERSHIP is
implemented, in which case it should get fixed 
2) libpcap isn't using PACKET_ADD_MEMBERSHIP correctly, in which case
it should be fixed (and if Redhat fixes it, they should send libpcap
authors the fixes so they can go into a future release of libpcap and
Redhat should update the packet(7) man page to make it clearer how
that stuff is supposed to work.)