OS: WinXP SP 2
Login: Admin
Anti-Virus: AVG Free Edition
Previous firewall: ZoneAlarm Pro
Connection: DSL
I installed Comodo Firewall Pro 2.4 a few weeks ago, and eventually noticed an odd behavior. Whenever I have uTorrent active, and try to view a video (with Media Player Classic and the K-Lite Codec pack), the video/audio will quite often skip or otherwise not play very well.
If I turn off uTorrent and leave CFP on, the video plays fine. If I turn off CFP and leave uTorrent turned on, it also plays fine. It’s only when I have both are running that this issue arises.
I’m concerned that CFP’s monitoring of uTorrent is somehow bogging down my computer; I closed uTorrent, cleared my alert log, started uTorrent again, and the log filled up with lots of alerts. (I also get an alert about incoming IGMP being blocked, no idea what that’s about… and it’s every minute, no matter what I do.) Could that be the case, and if so, how would I go about resolving it?
Ive got a old Compaq 1.3ghz 512mb thats always running Comodo with uTorrent 24/7 and have never experienced this, I also use AVG but I use FFDShow, not K-Lite (:TNG).
I was also getting a bunch of IGMP alerts but after posting in this forum they said its not really something to worry about so I just added a rule to allow them.
Have you looked in ye old task manager to see whats using up the cpu?
K-Lite is a codec pack, so I end up using FFDShow a lot of the time. It depends on how the video was encoded.
MPC uses up around 50 to 70, CFP uses 5 to 10, and uTorrent uses 10 to 20.
Traffic logging with p2p applications frequently bogs stuff down, even if it doesn’t consume CPU directly. The obvious answer is to shut down the p2p app when not needed… 
You also might want to tailor some Network rules to cut down the p2p log entries - either Allowing more types of traffic (a lot of ICMP is involved, I think), or Blocking without Logging if you don’t want to accept the traffic.
Media Player does tend to use a lot of resources, and also generate/receive a lot of IGMP traffic. If you see in the logs that the IGMP is related to MPC stuff, you may find it helpful to create Network rule to Allow it.
LM
I used Spybot and Adaware to make sure there wasn’t anything going on that I might not be aware of. I then took a good long look at the logs, and after creating a few rules to allow traffic that didn’t look terribly dangerous, I resolved the issue.
A lot of the incoming traffic being blocked seemed odd. It specified my own IP as the originating address, and (I think) 255.0.0.1 or something similar as the destination. I’m behind a router, so I wonder if that’s related. That’s mainly the traffic I allowed with the new rules, along with the IGMP and such.
Incidentally, I’m still blocking two types of traffic. Either incoming ICMP with the message UNREACHABLE, or incoming TCP with that Invalid Flag Combination / ACK FIN RST thing. I wonder if those things are significant. They don’t seem to be hacking attempts since I get them very often, every minute (or more).
Glad that’s working better for you, Milkman Dan. I’ll mark the topic as resolved and close it. Should you need it reopened, just PM a Moderator (please include a link back here) and we’ll be glad to do so.
It’s not uncommon to see subnet-related traffic (the 255.x.x.x type of address) as either a source or destination address to or from your computer, if you’re behind a router or otherwise on a LAN. You may see various protocols involved with this as well. There’s a lot of “chatter” that goes on in these scenarios, so it’s not something to raise a red flag, IMO.
I’ve also seen reports from other folks that consistently get ACK FIN RST messages; seems like it’s related (in a lot of cases) to p2p applications. I’d hazard a guess that it’s simply the nature of doing p2p stuff… CFP blocks ACK FIN RST flag combos for a reason (can be a security issue); it is probably best to leave those blocked.
LM