IFF_PROMISC again

IFF_PROMISC again

[Martín Ferrari]

Hi, for the nth time I send this email, hoping that majordomo won't eat
it again.


I know this has been extensibly discussed circa 2001, but I found that
there's still problems: in debian (at least) neither ifconfig nor ip
can tell that the interface is in promiscuous mode.

I know about the deprecation of IFF_PROMISC, but I couldn't find out
which is the current way of knowing the real state of the interface. I
want to fix ifconfig, so this is not an issue of
PACKET_(ADD|REMOVE)_MEMBERSHIP, I need to query the real device state.

Also, it's unclear to me what happens when you set/reset IFF_PROMISC
and then libpcap fiddles with membership. Is this documented
somewhere?

It has been said many times that ip should give this information. I
cannot see this:

$ sudo tcpdump -ni eth2 port 3333 &
$ dmesg |tail -2
device eth2 entered promiscuous mode
audit(1175904782.767:40): dev=eth2 prom=256 old_prom=0 auid=4294967295
$ ip link show eth2
4: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
   link/ether 00:18:de:81:24:a2 brd ff:ff:ff:ff:ff:ff
$ ip -V
ip utility, iproute2-ss060323

I think that is a problem for user tools to not know about this, and I
want to fix them. I don't know how. Can anyone give me a pointer?

Thanks, Martín.

-- 
Martín Ferrari <martin.ferrari@gmail.com>

Re: IFF_PROMISC again

[Ben Greear]

Martín Ferrari wrote:
> Hi, for the nth time I send this email, hoping that majordomo won't eat
> it again.
> 
> 
> I know this has been extensibly discussed circa 2001, but I found that
> there's still problems: in debian (at least) neither ifconfig nor ip
> can tell that the interface is in promiscuous mode.
> 
> I know about the deprecation of IFF_PROMISC, but I couldn't find out
> which is the current way of knowing the real state of the interface. I
> want to fix ifconfig, so this is not an issue of
> PACKET_(ADD|REMOVE)_MEMBERSHIP, I need to query the real device state.

I have the same problem.  I think you can tell by looking at bit 0x100
in /sys/class/net/[ethX]/flags

Not exactly fun to use, but it seems to work.

Anyone know the reasoning for masking out the PROMISC flag
in dev_get_flags() ?

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: IFF_PROMISC again

[David Miller]

From: Ben Greear <greearb@candelatech.com>
Date: Tue, 22 May 2007 17:08:18 -0700

> Anyone know the reasoning for masking out the PROMISC flag
> in dev_get_flags() ?

Because promiscuous status is a counter, not a binary
on-off state.

You can't expect to just clear it and expect all the
other promiscuous users to just "go away" and be ok
with the device leaving promiscuous mode.

Since you can't sanely "set" it, we don't provide it
either.

Re: IFF_PROMISC again

[Ben Greear]

David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Tue, 22 May 2007 17:08:18 -0700
> 
>> Anyone know the reasoning for masking out the PROMISC flag
>> in dev_get_flags() ?
> 
> Because promiscuous status is a counter, not a binary
> on-off state.
> 
> You can't expect to just clear it and expect all the
> other promiscuous users to just "go away" and be ok
> with the device leaving promiscuous mode.

Yes, I understand why you wouldn't let a user set promisc in this
manner.

> Since you can't sanely "set" it, we don't provide it
> either.

What harm is there letting the user know if their hardware is PROMISC
or not, regardless of how it got that way?

Also, it seems you *can* at least turn it on with ifconfig, and
you can decrement at least once with ifconfig as well.  If nothing
else has promiscuity set, then this will indeed toggle the state, right?

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: IFF_PROMISC again

[Martín Ferrari]

Hi David,

On 5/22/07, David Miller <davem@davemloft.net> wrote:

> > Anyone know the reasoning for masking out the PROMISC flag
> > in dev_get_flags() ?
>
> Because promiscuous status is a counter, not a binary
> on-off state.
>
> You can't expect to just clear it and expect all the
> other promiscuous users to just "go away" and be ok
> with the device leaving promiscuous mode.

Yes, this is fully understood.

> Since you can't sanely "set" it, we don't provide it
> either.

I think it's cleaner how is done now, but the needed information is
hidden, not having a proper way of querying the counter or the real
(binary) promiscuous state is a problem for userspace. Do you think
the patch I suggested is not a good idea?

Do you think there is a acceptable way of exporting that info to
userspace? (as I just said to Ben, the /sys/.../flags file doesn't
seem a very clean way of checking it).

-- 
Martín Ferrari

Re: IFF_PROMISC again

[Martín Ferrari]

Hi Ben,

On 5/22/07, Ben Greear <greearb@candelatech.com> wrote:

> > PACKET_(ADD|REMOVE)_MEMBERSHIP, I need to query the real device state.

> I have the same problem.  I think you can tell by looking at bit 0x100
> in /sys/class/net/[ethX]/flags
>
> Not exactly fun to use, but it seems to work.

Wow, I searched for this a lot! It could be all I need, although it
doesn't seem very robust to look at the bitmap driectly, is it?

Maybe it would be cleaner to add an "promiscuity" file to that structure?

-- 
Martín Ferrari

Re: IFF_PROMISC again

[Martín Ferrari]

Stephen, I think your mail didn't make it to netdev. Majordomo seems
to be working badly with special charsets (my mails used to be totally
ignored because of charset and/or encoding issues).

On 5/27/07, Stephen Hemminger <shemminger@linux-foundation.org> wrote:

> > Wow, I searched for this a lot! It could be all I need, although it
> > doesn't seem very robust to look at the bitmap driectly, is it?
> >
> > Maybe it would be cleaner to add an "promiscuity" file to that structure?

> /sys/class/net/ethX/flags was an interface mistake. Don't depend on it.
>
> I added it back when sysfs was first starting. Most of the files in /sys/class/net/ethX
> are really meant only for debugging. There was no debugfs at the time.
>
> The problem is it exports bit values as ABI that shouldn't be nailed down.

Great that you point it out. Then, we're back to the initial
situation, there is no reliable way of polling promisc state, and I am
looking for a way to do that. Ways I think it could be done:

- Exporting /sys/class/net/ethX/promiscuity as a counter (I have a
working patch for this)
- Exporting /sys/class/net/ethX/promisc as a binary value, from dev->flags.
- ORing the two IFF_PROMISC flags in dev_get_flags() (the patch I sent)
- Dropping gflags altogether, as there doesn't seem to be any real use
case for it, and keep using dev_get_flags().

Any suggestion?

-- 
Martín Ferrari

Re: IFF_PROMISC again

[Martín Ferrari]

Stephen,

On 5/28/07, Stephen Hemminger <shemminger@linux-foundation.org> wrote:

> > Great that you point it out. Then, we're back to the initial
> > situation, there is no reliable way of polling promisc state, and I am
> > looking for a way to do that. Ways I think it could be done:
>
> Back to the original question. Why should an application care?

Not an application, but the sysadmin do cares about it. And most
rootkit detectors don't have any other way of checking if a
tcpdump-like tool is running.

I don't see the usefulness of keeping the current toggle via gflags,
which is confusing for users. But I see a benefit in exporting
promiscuity as a read-only value, and I think it's pretty trivial to
provide it.

-- 
Martín Ferrari