netdev
[Top] [All Lists]

Re: IFF_PROMISC bug?

To: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Subject: Re: IFF_PROMISC bug?
From: Andi Kleen <ak@xxxxxxx>
Date: Wed, 13 Feb 2002 07:46:04 +0100
Cc: Andi Kleen <ak@xxxxxxx>, "David S. Miller" <davem@xxxxxxxxxx>, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, kuznet@xxxxxxxxxxxxx
In-reply-to: <3C6A0817.B50EFC74@xxxxxxxxxxxxxxxx>
References: <3C69C7F5.C196F6BB@xxxxxxxxxxxxxxxx> <20020212.204308.111207103.davem@xxxxxxxxxx> <3C69F19E.4FF14164@xxxxxxxxxxxxxxxx> <20020212.205809.70219775.davem@xxxxxxxxxx> <20020213071933.A22699@xxxxxxxxxxxxx> <3C6A0817.B50EFC74@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.3.22.1i
On Wed, Feb 13, 2002 at 01:30:47AM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> > 
> > On Tue, Feb 12, 2002 at 08:58:09PM -0800, David S. Miller wrote:
> > >    From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
> > >    Date: Tue, 12 Feb 2002 23:54:54 -0500
> > >
> > >    Since netlink flags and dmesg show promisc mode, and promisc mode 
> > > works,
> > >    and SIOCGIFLAGS used to return IFF_PROMISC, I made the assumption that
> > >    the problem was elsewhere :)
> > >
> > > Can you trace the value of dev->gflags for me through all of these
> > > actions?  It should contain IFF_PROMISC when set by this bit of code:
> > 
> > David, it is not a bug, but more a FAQ.
> > 
> > Newer libpcap uses the PACKET_ADD_MEMBERSHIP to PACKET_MR_PROMISC socket
> > options. They have an reference count instead of
> > the old broken non ref counted bit.  packet calls dev_set_promiscuity 
> > directly.
> > 
> > Turning on/off the flag virtually when the reference count is >0 would
> > break compatibility so it is not done.
> 
> Net stack should not call net driver to enable promisc when it is
> already enabled, or disable promisc when it is already disabled, agreed?
> Further, we have a lock guaranteeing that dev->set_multicast_list call
> atomicity.
> 
> Given that there is a clear point when promisc is enabled or disabled, I
> do not see why IFF_PROMISC cannot be managed properly.
> 
> Please help me understand the compatibility issues that prevent this,
> given what I've just described...

The issue is not on the driver level interface, but on the user API.

The problem is that there are two incompatible user interfaces. One 
is essentially a reference count (PACKET_ADD_MEMBERSHIP/PACKET_DROP_MEMBERSHIP).
The other is a single bit in a bitmask that was managed by saving the old
state and resetting it on program exit (via SIOG[CS]IFFLAGS).
Mapping the single bit toggling properly to the reference count doesn't work
especially when the bit is modified so it is not tried.

What ifconfig could do is to check the reference count and tell the user
that the interface is in promisc mode anyways. Problem is just that the
reference count is not user visible currently.


-Andi


<Prev in Thread] Current Thread [Next in Thread>