Bug 199979 - eth0 enter into promiscuous mode whitout being report by ifconfig or "ip link show"
eth0 enter into promiscuous mode whitout being report by ifconfig or "ip link...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: net-tools (Show other bugs)
9
i686 Linux
medium Severity urgent
: ---
: ---
Assigned To: Radek Vokal
Ben Levenson
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-24 14:49 EDT by Yvan Chouinard
Modified: 2008-08-21 03:45 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-21 03:45:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yvan Chouinard 2006-07-24 14:49:17 EDT
Description of problem:

When I start arpwatch, the Ethernet card eth0 goes into promiscuous mode and I
cannot see it wit ifconfig eth0 or ip link show.  The only way I can see it is
when I looked at dmesg.

Version-Release number of selected component (if applicable):
arpwatch 2.1a13

How reproducible:
always

Steps to Reproduce:
1. service arpwatch start
2. ifconfig eth0
3. ip link show
  
Actual results:

Link encap:Ethernet  HWaddr 00:0B:DB:95:BC:7A
          inet adr:192.168.1.103  Bcast:192.168.1.255  Masque:255.255.255.0
          adr inet6: fe80::20b:dbff:fe95:bc7a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:135881 errors:0 dropped:0 overruns:0 frame:0
          TX packets:120195 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:107785865 (102.7 MiB)  TX bytes:10599182 (10.1 MiB)
          Interruption:11

Expected results:

 Link encap:Ethernet  HWaddr 00:0B:DB:95:BC:7A
          inet adr:192.168.1.103  Bcast:192.168.1.255  Masque:255.255.255.0
          adr inet6: fe80::20b:dbff:fe95:bc7a/64 Scope:Lien
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:135881 errors:0 dropped:0 overruns:0 frame:0
          TX packets:120195 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:107785865 (102.7 MiB)  TX bytes:10599182 (10.1 MiB)
          Interruption:11




Additional info:

I think that a problem with libcap ???
Comment 1 Jay Fenlason 2006-07-24 14:59:22 EDT
Arpwatch is not part of the arptables_jf package.  I'm redirecting this to the 
correct maintainer. 
Comment 2 Martin Stransky 2006-07-25 00:26:05 EDT
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...
Comment 3 Yvan Chouinard 2006-07-25 08:51:12 EDT
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
Comment 4 Martin Stransky 2006-07-25 09:05:57 EDT
It looks like a bug in net-tools and/or kernel...
Comment 7 John DeDourek 2006-08-03 08:16:14 EDT
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.
Comment 9 Christian Iseli 2007-01-22 06:35:32 EST
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.
Comment 10 Mike Loseke 2007-12-10 18:37:27 EST
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.
Comment 11 Bug Zapper 2008-04-03 13:50:44 EDT
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.
Comment 12 Mike Loseke 2008-04-04 12:08:13 EDT
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.
Comment 13 John DeDourek 2008-04-04 13:06:24 EDT
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.
Comment 14 Mike Loseke 2008-04-04 15:56:02 EDT
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.
Comment 15 John Poelstra 2008-04-15 20:51:00 EDT
thanks for your update
Comment 16 Bug Zapper 2008-05-13 22:15:15 EDT
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
Comment 17 Anton Arapov 2008-07-09 06:44:02 EDT
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.
Comment 18 Zdenek Prikryl 2008-07-09 09:02:52 EDT
(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?
Comment 19 Michal Schmidt 2008-07-09 09:20:27 EDT
(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.
Comment 20 Zdenek Prikryl 2008-07-09 09:51:08 EDT
(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.
Comment 21 Anton Arapov 2008-07-09 10:01:05 EDT
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,... 
Comment 22 Zdenek Prikryl 2008-08-21 03:45:03 EDT
According comments above, I'm closing this bug as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.