[Top] [All Lists]


To: Andi Kleen <ak@xxxxxxx>
Subject: Re: IFF_PROMISC bug?
From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Wed, 13 Feb 2002 01:30:47 -0500
Cc: "David S. Miller" <davem@xxxxxxxxxx>, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, kuznet@xxxxxxxxxxxxx
Organization: MandrakeSoft
References: <> <> <> <> <>
Sender: owner-netdev@xxxxxxxxxxx
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

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...


Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             -

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