Comodo & Azureus

I’ve been using Comodo for a while, and i’m quite happy with it.

My big complain is with cpu usage: sometimes it can get ridicolously high.

For example, while using Azureus. cpf.exe can easily climb up to ~60% cpu usage. After playing around a little with various prefs & tweaks, i’ve finally discovered the way to circumvent this: disabling “Monitor dll injections”. Just untick it and, hey, smooth as silk.

Ok, it’s not that good (since it decreases local security), but at least your computer will be usable again.

PD: Sorry about bad english, spanish here.

Welcome to the forum.
Thank’s for the tip.

Azureus itself does tend to hog your computer.
It’s java based and it’s a bit “heavy” on the PC, so it gets kind of “heavy” for the firewall to control it too.
I switched to uTorrent and it’s much “lighter” on my computer.

I have had the same experience as AOwl in that switching from Azureus to uTorrent speeds things up quite a bit. Seems more stable in general as well.

Yes, uTorent is faster than Azureus, and takes less resourses :slight_smile:

Greetz, Red.

you try running 20-30 torrents on a 20/20Mbit/s line and see what uTorrent
does to your HDD . Just make sure you have a backup and a new drive around first …

Is it possible to disable logging on a pr. application basis ?
I don’t have any reason to log p2p-traffic and I’m certain it consumes a lot of resources
and makes unneeded writes to disk .

Are you referring to logging in CPF?

If so, open your p2p rules in the Network Monitor, uncheck the box for “Create an alert if this rule is fired.” If you’re getting a lot of blocked traffic related to p2p, that you don’t need, create a new rule in the network monitor that defines that protocol (ie, ICMP port unreachable, etc), set it to Block, don’t create the alert (same as before), and put it before the bottom block rule.

That way, as traffic is filtering down thru the rules, it will get blocked prior to the bottom block rule, and you won’t get an alert.

Hope that helps,


Yes, that did the trick.
Thank you for the excellent support you are giving your product.
I don’t know if this is mentioned elsewhere ( haven’t read everything yet ) but if you
have DHT enabled and/or want to use a UDP-tracker in Azureus you will need to make a rule
that allows ICMP.
I’m not certain if you need to allow all types of ICMP however… but if you don’t do
it you will get hundreds of “medium” alerts and the annoying “DHT Firewalled” warning .
You won’t be able to join a swarm by entering the info-hash either .

Good, I’m glad that worked for you.

TNX for the tip, too. The activity logs should show the exact type of ICMP traffic that’s being blocked (provided it’s being blocked), so that the necessary rule(s) can be created to allow it.

It has been previously noted that for some p2p apps, ICMP Host Unreachable needs to be allowed in order to get the green light. Apparently (even with the same p2p application) this is not necessary for all users.


on closer inspection, doing what you suggested does not solve the problem,
it just hides it .
The problem seems to be the way DHT works and how Comodo treats it …
UDP is treated by the packet-inspector as Fake, malformed or fragmented UDP packets and are
thus blocked. Setting my client (Azureus,latest beta) as “trusted” and “allow all activity for this application” doesn’t help .
I think you need to look in to this issue and find a way to fix it.
The bit-torrent FAQ doesn’t seem to have any solution to this problem
and since it cripples speed and blocks perfectly valid and needed data a real solution is needed .
I am looking in to the matter and when ( if ?) I find the solution I will post it …
unless you beat me to it that is … but still a great firewall despite this …

If you go to security/advanced/advanced attack detection and prevention/misc tab, and try to uncheck “block fragmented IP datagrams” and/or “do protocol analysis”, and try if that works.
Let us know.

Yes, already did that and it works fine.
I still get blocks but only when the client isn’t running.
I suspect that those blocks are caused by “ghost-packets”.
(peers that don’t know the client has been stopped)
Should I re-enable the options once I stop Azureus or is there
some way to achieve the same by making application-rules ?

I would re-enable them when I didn’t use Azureus.

the only thing you can do in application monitor, is to check the “skip advanced security checks” on the misc tab.