Bug 450923
| Summary: | Running ettercap in daemon mode with -o option opens text interface | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dmitry Burstein <dmitryburstein> |
| Component: | ettercap | Assignee: | Gwyn Ciesla <gwync> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 0.7.3-26.fc8 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-06-26 08:29:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. Patched with AlOr's blessing, wants all our current patches as well. Works. Will build for rawhide. . . Built. 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. I see, it's affected by flag order, but the new patch fixes that. Thanks. Built in rawhide. Thanks again. This time it worked like a charm. Consider this bug squashed :-) 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. 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.
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. 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. 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. Nope. Neither that, nor bracketing the other loop in it, works. 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!
It does! Built for rawhide, please test. http://koji.fedoraproject.org/koji/buildinfo?buildID=52808 Works for me - with no noticeable side effects. I think this time we've finally nailed the bugger :-) ettercap-0.7.3-26.fc9 has been submitted as an update for Fedora 9 ettercap-0.7.3-26.fc8 has been submitted as an update for Fedora 8 Thanks for all your help! 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 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. 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. |
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 :-)