Bug 450923 - Running ettercap in daemon mode with -o option opens text interface
Running ettercap in daemon mode with -o option opens text interface
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ettercap (Show other bugs)
9
i386 Linux
low Severity low
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-11 14:54 EDT by Dmitry Burstein
Modified: 2008-06-26 04:33 EDT (History)
0 users

See Also:
Fixed In Version: 0.7.3-26.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-26 04:29:19 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 Dmitry Burstein 2008-06-11 14:54:33 EDT
Description of problem:
Running ettercap with '-o' option errorneously implies text interface
disregarding the '--daemon' running mode

Version-Release number of selected component (if applicable):
ettercap NG-0.7.3

Additional info:
Reviewing the code shows that the text interface to be opened whenever the
'only-mitm' (-o option) mode is required:

VVVVVVVVVVVVVVVVVVV ec_parser.c VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

         case 'o':
                  GBL_OPTIONS->only_mitm = 1;
                  select_text_interface();
                  break;

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and later in the same file:

VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

   /* force text interface for only mitm attack */
   if (GBL_OPTIONS->only_mitm) {
      if (GBL_OPTIONS->mitm)
         select_text_interface();
      else
         FATAL_ERROR("Only mitm requires at least one mitm method");
   }

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This behaviour contradicts the specific requirement for some other type of
interface - daemon in my case - and, being undocumented in man pages, or help
prompt, is considered errorneous.

Actually, I wasn't quite sure whether to report it as a bug, but as I was unable
to find any incentive to such a behaviour, I can't consider it to be a feature :-)
Comment 1 Gwyn Ciesla 2008-06-12 10:04:27 EDT
I guess I'm not sure why mitm needs an interface at all.  There's other code
that makes sure an interface or -D are present, and I wonder if just commenting
out that second part would suffice.  I'll check upstream, see what they think.
Comment 2 Gwyn Ciesla 2008-06-12 14:13:59 EDT
Patched with AlOr's blessing, wants all our current patches as well.  Works. 
Will build for rawhide. . .
Comment 3 Gwyn Ciesla 2008-06-12 14:46:51 EDT
Built.
Comment 4 Dmitry Burstein 2008-06-12 15:08:47 EDT
Thanks, but you probably have to comment out also the "select_text_interface();"
line of the first part: I've just tried your new build, and the text interface
has still opened.
Comment 5 Gwyn Ciesla 2008-06-12 16:15:11 EDT
I see, it's affected by flag order, but the new patch fixes that.  Thanks. 
Built in rawhide.
Comment 6 Dmitry Burstein 2008-06-12 16:56:23 EDT
Thanks again. This time it worked like a charm. Consider this bug squashed :-)
Comment 7 Dmitry Burstein 2008-06-12 17:26:26 EDT
Sorry, I was celebrating too early. Just noticed that now, running in the daemon
mode, the CPU usage got to 100%! Running in the text mode is still fine - almost
zero CPU usage, as usual.
This time I have no clue as to what caused such a behaviour. The log file
revealed nothing suspicious.
Comment 8 Dmitry Burstein 2008-06-12 17:45:14 EDT
Actually, I have a clue: the "only_mitm()" function in ec_mitm.c file has the
following loop inside it: 

VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

   /* wait for user to exit */
   while (ch != 'q' && ch != 'Q') {
      /* if there is a pending char to be read */
      if ( ec_poll_in(fileno(stdin), 1) || ec_poll_buffer(GBL_OPTIONS->script) ) {
         /* get the input from the stdin or the buffer */
         if (ec_poll_buffer(GBL_OPTIONS->script))
            ch = getchar_buffer(&GBL_OPTIONS->script);
         else
            ch = getchar();
      }
   }

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

when daemonized, the stdin is redirected to the /dev/null, and the
abovementioned piece of code is probably trying to read infinitely and
constantly, thus hogging the CPU.
Hope I'm right and it's this simple.
Comment 9 Gwyn Ciesla 2008-06-13 10:17:12 EDT
I patched it, commenting out from /* if ther is a pending. . ., leaving only ch
= getchar();, and is still goes to %100.  Not putting that in CVS.
Comment 10 Dmitry Burstein 2008-06-14 12:10:58 EDT
I'm not entirely sure, but I guess the while loop on the getchar() *is* the 
reason for the 100% CPU. Have you tried to replace the whole loop by while(1) 
(only for daemon interface)?
When running in daemon mode the only way to end the program is to send some 
signal to it (SIGKILL works fine), so infinite reading from /dev/null, waiting 
for 'q' to appear is meaningless anyway.
If the while(1) will solve the problem, we'll just have to ensure that catching 
the SIGKILL (or SIGHUP or whatever) signall will cause graceful program 
terminarion.
Comment 11 Dmitry Burstein 2008-06-15 13:20:26 EDT
I suppose inserting

while(GBL_UI->type == UI_DAEMONIZE);

immediately before the while loop mentioned in Comment #8 should solve the
problem, as graceful termination will be (hopefully) taken care of through
catching the SIGTERM signal by signal_TERM() function.
Comment 12 Gwyn Ciesla 2008-06-16 10:02:25 EDT
Nope.  Neither that, nor bracketing the other loop in it, works.
Comment 13 Dmitry Burstein 2008-06-16 14:11:01 EDT
My bad entirely: the empty while loop takes 100% of CPU - just like the original
code fragment. We should try something like:

if (GBL_UI->type == UI_DAEMONIZE)
    LOOP {
        sleep(1);
    }

This should work!
Comment 14 Gwyn Ciesla 2008-06-16 15:30:31 EDT
It does!  Built for rawhide, please test.
http://koji.fedoraproject.org/koji/buildinfo?buildID=52808
Comment 15 Dmitry Burstein 2008-06-16 17:34:50 EDT
Works for me - with no noticeable side effects.
I think this time we've finally nailed the bugger :-)
Comment 16 Fedora Update System 2008-06-17 09:06:16 EDT
ettercap-0.7.3-26.fc9 has been submitted as an update for Fedora 9
Comment 17 Fedora Update System 2008-06-17 09:07:34 EDT
ettercap-0.7.3-26.fc8 has been submitted as an update for Fedora 8
Comment 18 Gwyn Ciesla 2008-06-17 09:11:09 EDT
Thanks for all your help!
Comment 19 Fedora Update System 2008-06-17 23:13:43 EDT
ettercap-0.7.3-26.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ettercap'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-5400
Comment 20 Fedora Update System 2008-06-26 04:29:16 EDT
ettercap-0.7.3-26.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2008-06-26 04:33:01 EDT
ettercap-0.7.3-26.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

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