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.
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.
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.
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 .
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 …
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 ?