CPU USAGE GOES TO 100% with new 2.4 [Resolved in version 3]

[Guest]

[Little Mac]

Welcome to the forums, D.G.K. 

I'm glad you've gotten the CPU usage down.  What you've done basically (to me) sounds like what you should do to grant a p2p application access through the layered defenses that Comodo FW offers.  Although it does sound like there's some other problem as well... if you changed the Application Monitor rule for utorrent to Block, and it's still getting through, that's not the way it should be.  Was the application running while you changed the rule (rule won't take effect while it's running)?  Did you perchance restart the firewall after changing the rule?  Or reboot?  I'd like to see the results after such, just to make sure any resident memory is cleared out...

It may help you understand how the layered rules (different monitors) work by reading this explanation:
http://forums.comodo.com/faq_for_comodo_firewall/tutorials_a_compiled_resource-t6167.0.html;msg45545#msg45545

LM

[D.G.K.]

Thanks for the link. I see that the network monitor is king and the rest are peasants. I'm sure there's a good reason it's setup that way but it seems like it'd be easier if application monitor was the king. Or maybe let the app monitor be an advisor to the king and be able to append some of the rules. It just doesn't make sense to me if you set an app to allow all access, that it's still possible for the access to be blocked. There's almost no point to the app monitor if you can control everything through the net monitor. Reminds me of setting the access lists on cisco routers.  Don't get me wrong. I like access lists. CPF could use a better implementation though. But I digress.

I did some restarting and it turns out it was a resident memory issue. I did have uTorrent running at the time but the application monitor finally started blocking it like it was supposed to. I did find another interesting post on this topic. I thought it was the actual filtering that increased the CPU usage but it turns out it could be the logger itself. If it writes every event to disk as they come up then that could explain it. Maybe they can change it so CPF caches the disk writes and writes them every 2 min. like the way uTorrent writes data after it downloads.

Also I'm still wondering if the net monitor can really be turned off? It didn't work when I set it to off. If I can use CPF the how I described I wanted, by turning off the net monitor, then that solves it all for me.

Thanks Lil' Mac. Glad to be here. Keep up the good work. (B)

[Little Mac]

It just doesn't make sense to me if you set an app to allow all access, that it's still possible for the access to be blocked. There's almost no point to the app monitor if you can control everything through the net monitor.

It's not quite exactly like that....  Think of it this way:

NetMon controls traffic (similar to a router, but with a different purpose)
AppMon controls applications (this is all the "ordinary" firewall is)
ABA + CompMon controls interprocess relations (the way things work behind the scene)

Your normal firewall controls an application's ability to connect In or Out.  And that's pretty much where it stops.  It doesn't care how to any extent.  Is the app allowed?  Ok, that's all we need to know.  Don't care how the app was run, where it's connecting to, what it's doing, etc.  Only if that application has been allowed.

CFP has added two layers to that, to increase the security and level of user control.

Let's use a river scenario (maybe not the best, but it illustrates my point).  The river itself is NetMon.  The canoe on it is AppMon.  The two guys in the canoe are ABA+CompMon.  The canoe can only go in the direction NetMon points it.  If the Canoe (or the two guys in it) want to go upriver, that's just not going to happen.

If you take NetMon out of the picture, you don't have a river, you have a lake.  The canoe (or the two guys in it) can go wherever they like, whenever they like, for any purpose they like.   No "external" control.

All firewalls have a form of NetMon, so it can to some degree stop unsolicited inbound traffic.  The problem is, the user has little or no control over this.  CFP's setup is very different, I agree, and takes some getting used to.  And yes, I support the way it works, because I think it is the best there is right now.  If you want a demonstration of why this layered defense is so crucial, check out Matousec Security's leaktest results.  Comodo firewall is far and away at the top of the list... 

If you give it some time and make a serious effort to understand it rather than wanting it to be something it's not, you may come to appreciate it as well.  That's not meant as a derogatory comment in any way; a lot of people new to Comodo have said very similar things to what you're saying, but I think those that chose to stick it out have largely changed their opinions.

Hope you enjoy it!

LM

PS:  In v3, you can create custom rulesets (of multiple rules) for either application or network, name them, and do so in such a way that they're kind of linked together.  Probably more like what you're looking for, as far as the "advisor to the king" scenario

[D.G.K.]

it's not like I'm ready to jump onto a new canoe. I been running canoes for a long time and finally found the canoe with the best features. The only problem I have with the canoe is that it's not that comfortable of a ride. Albeit far from the command line but I suppose I'm just spoiled by the ease of use found in competing products. Looking forward to v3. Maybe you can add a database people can submit app configs that can be downloaded and enabled through the v3 client. Save time vs. learning mode or manual config. Already can't wait to try it. I saw something about an alpha but I'll wait til beta I think.

[Soyabeaner]

Let's recall the cpu issue here (per the thread title).  Has anyone here (besides LM) noticed any cpu issues with v3 alpha?

[kail]

Yes, usually when CFP is detecting new things. But, shouldn't this be in one of the V3 topics?

[Soyabeaner]

I know.  Just wanted to see if the issue is fixed in the next version so that we can possibly end this thread or see the light at the end of the dark tunnel

[Tags:]