Bug 199979

Arpwatch is not part of the arptables_jf package.  I'm redirecting this to the 
correct maintainer. 

Could you describe your problem more? The lines which you pasted here are
different only in:

-          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1

and it looks fine...

When a network card goes into promiscous mode,  it may be a sign that our system
may be cracked by someone.  One way to detect that a network card is in
promiscuous mode is to examine the output of one of the following command and
notice the word PROMISC indicating that the network card is effectively into
promiscuous mode.  

ifconfig

or

ip link show


But when we issue those commands we notice no sign of the fact that the network
card is effectively in promiscous mode.  It's not correct and we cannot use
simple script to detect that fact.

Why The work PROMISC is no more into the report of the network card???

Thanks

It looks like a bug in net-tools and/or kernel...

The following is a vague recollection of mine so please accept it
as a hypothesis rather than a definitive statement.  I tried searching
for an authoritative source, but was unsuccessful.

I recall reading somewhere that the handling of
promiscous mode in the kernel had changed at some point.  Originally,
there was a single flag per interface; if set, the interface was in
promiscous mode.  However, this posed a problem because more than one
application might ask for promiscous mode, e.g. start arpwatch on an
interface, then start tcpdump;  now stopping one of these would ask
for promiscous mode to be turned off, in effect disabling the operation
of the other application.  This was then changed to a counter, I believe;
each request that promiscuous mode be turned on incremented the
counter and each request to turn it off decremented the counter.  
Promiscous mode was then controlled by the counter and the flag became
unused.  However, at the time of this change, ifconfig and friends
were still reporting the status of the unused flag.

Ahhhh.  See here:
  http://seclists.org/bugtraq/2002/Jul/0301.html
  http://seclists.org/bugtraq/2002/Jul/0302.html

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

I can confirm that this is still happening with Fedora 8 and Rawhide.
Promiscuous mode cannot be reliably detected using ifconfig and "ip link".

To reproduce:

1. Put the device into promiscuous mode using a tool like tcpdump:
   # tcpdump -i eth0 &

2. Use ifconfig or "ip link" to show the device, neither of these commands will
show the PROMISC flag:
   # ifconfig eth0
   ...
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   ...

   # ip link show dev eth0
   ...
   2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   ...

The kernel will report the device entering and leaving promiscuous mode (dmesg).
This is the same behavior as reported in this bug by the originator.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

I just confirmed that there is no change in behavior here, neither ifconfig nor
the ip command are reporting an interface as being in promiscuous mode.

I tested on Fedora 8 with no pending updates as of 2008-04-04, kernel
2.6.24.4-64.fc8.  I tested this against both active and UP eth0 and wlan0
interfaces.

Please see comment #10 for steps to reproduce.

I can confirm as well that the problem exists, as described by the original
poster, in an Fedora 8 installation current as of today.  See comment #12 and
comment #10.

Also, visit the links in comment #8 for a likely explanation of the
problem and a possible explanation of what needs to be changed to
change the behaviour of ifconfig.

As confirmation fo the hypothesis in comment #8 I note that if the "promiscuous
mode" flag is changed by "ifconfig eth0 promisc" and "ifconfig eth0 -promisc"
then "ifconfig eth0" properaly shows the PROMISC flag or not.  However, if
the programmatic setting of promiscuous mode is changed by applications 
such as tcpdump and/or arpwatch, then ifconfig does not show the PROMISC
indication, as described in the original bug posting.

I just verified that the same behavior exists on Fedora 9 Beta (rawhide) as of
an updated system 2008-04-04, running kernel 2.6.25-0.195.rc8.git1.fc9.i686.

thanks for your update

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Very old, odd and well known issue. It's kernel related from the one
perspective, but nobody wishes to change anything since 2001. And I would say
nothing changed.

the only way to get the current state is to read /sys/class/net/[net_if]/flags file.

(In reply to comment #17)
> Very old, odd and well known issue. It's kernel related from the one
> perspective, but nobody wishes to change anything since 2001. And I would say
> nothing changed.

As you mentioned, the situation probably stay same for long time. So, the best
solution is change ifconfig check algorithm to that one which reads flags file
instead of checking IFF_PROMISC flag, right?

(In reply to comment #18)
> As you mentioned, the situation probably stay same for long time.

I'm not 100% sure about that. See this message from Alexey Kuznetsov in the
ancient netdev thread (
http://www.uwsg.iu.edu/hypermail/linux/net/0202.1/0044.html ):
  Anyway, ifconfig should show that state which it changes.
  If you want to look at "true" state you may use "ip link". 

This suggest to me that "ip link" used to show the real PROMISC state then.

> So, the best solution is change ifconfig check algorithm to that one which
> reads flags file instead of checking IFF_PROMISC flag, right?

I say no. Why? I agree with Alexey's "ifconfig should show that state which it
changes".
However, if we start talking about "ip link" only then yes, this should be fixed
to show the true state. I believe the fix should be in the kernel where the flag
is passed to ip via netlink.

(In reply to comment #19)
> This suggest to me that "ip link" used to show the real PROMISC state then.

Unfortunately, "ip link" doesn't show "true" state of a card right now. The
situation with ip is same (ip can {un}set promisc mode and it uses IFF_PROMISC
flag).

> > So, the best solution is change ifconfig check algorithm to that one which
> > reads flags file instead of checking IFF_PROMISC flag, right?
> 
> I say no. Why? I agree with Alexey's "ifconfig should show that state which it
> changes".

Hmm, it make a sense, but then neither ip nor ifconfig show "true" state of a card.

In addition - nothing shows true state whether interface in promiscuous mode! It
is impossible at the moment to obtain this info from user land. The only two
ways available, first - is to look into flags file, second - to grep dmesg
messages. :-) Ugly? Yes. But we can't do anything so far,... 

According comments above, I'm closing this bug as WONTFIX.