Ettercap / ettercap

Ettercap Project
http://www.ettercap-project.org
GNU General Public License v2.0
2.33k stars 488 forks source link

Make it possible to enable/disable ec_conntrack and ec_profile from CLI, and possibly dynamically #213

Open justfalter opened 11 years ago

justfalter commented 11 years ago

While profiling ettercap with valgrind, I noticed that ec_conntrack and ec_profile constitute a significant portion of Ettercap's process time. By manually disabling the both of these, I was able to reduce the number of function calls in my tests from ~42 million down to ~15 million. I don't know the exact impact w.r.t performance, but I can see how eliminating 65% of the function calls might be beneficial.

AFAICT, the two are probably most useful in those cases when you are performing recon, and need to know what hosts and connections are flying by on the network. However, if you have already moved beyond recon and simply want to manipulate traffic, there's no need to incur the performance impact of ec_conntrack and ec_profile.

I propose adding the ability to enable/disable conntrack and profiling from the CLI. Further, I don't see why we shouldn't be able to enable/disable it dynamically once the process is running.

thoughts?

brav0hax commented 11 years ago

Any place we can get a performance gain without sacrificing functionality is an absolute win.

In reading your explanation, my question is would this impact a scenario where the user has set it to automatically ARP poison new hosts that appear on the wire. I believe this is a plugin or switch, but not 100% sure about how it determines new hosts added, etc.

I do like the idea of enable/disable on the fly. Honestly, I have already done my recon, etc and have a clear set of hosts I want to target before I even start poisoning.

On Sun, Apr 28, 2013 at 10:49 PM, Mike Ryan notifications@github.comwrote:

While profiling ettercap with valgrind, I noticed that ec_conntrack and ec_profile constitute a significant portion of Ettercap's process time. By manually disabling the both of these, I was able to reduce the number of function calls in my tests from ~42 million down to ~15 million. I don't know the exact impact w.r.t performance, but I can see how eliminating 65% of the function calls might be beneficial.

AFAICT, the two are probably most useful in those cases when you are performing recon, and need to know what hosts and connections are flying by on the network. However, if you have already moved beyond recon and simply want to manipulate traffic, there's no need to incur the performance impact of ec_conntrack and ec_profile.

I propose adding the ability to enable/disable conntrack and profiling from the CLI. Further, I don't see why we shouldn't be able to enable/disable it dynamically once the process is running.

thoughts?

— Reply to this email directly or view it on GitHubhttps://github.com/Ettercap/ettercap/issues/213 .

eaescob commented 11 years ago

Hrm, I believe that is doable. We just have to make sure that the GUIs don't pull any profile data, I know some dissectors (like DNS) also add data to the hosts list profiles.

justfalter commented 11 years ago

FWIW, here are some stats:

Before:

Bottom Half packet rate : worst:    50150  adv:   176913 p/s
Top Half packet rate    : worst:   200803  adv:   854569 p/s
Bottom Half thruoutput  : worst: 12603833  adv: 123106767 b/s
Top Half thruoutput     : worst:  2350000  adv: 545060043 b/s

After:

Bottom Half packet rate : worst:   112866  adv:   205604 p/s
Top Half packet rate    : worst:  1136363  adv:   3130154 p/s
Bottom Half thruoutput  : worst: 17053061  adv: 143071672 b/s
Top Half thruoutput     : worst: 19583332  adv: 1996469398 b/s

Ratio of (After / Before):

Bottom Half packet rate : worst:   2.25x  adv:   1.16x p/s
Top Half packet rate    : worst:  5.65x  adv:   3.66x p/s
Bottom Half thruoutput  : worst: 1.35x  adv: 1.16x b/s
Top Half thruoutput     : worst: 8.33x  adv: 3.66x b/s
LocutusOfBorg commented 10 years ago

so @justfalter do you have any pull for this?