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: Always 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 expected)
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.
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 entry.
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) OR 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) Either 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.)