How do I find out what made CPF shut the connection down ?

If I understood correctly, in certain situations CPF will shut the connection down because suspicious behaviors are going on in the system. I just love that, better safe than sorry, all the time.

However this connection shutdown started to occur often to me, and I can’t find a way to detect what is that makes CPF take that precaution.

It’s quite annoying because the only way I found to reactivate the connection is a system reboot: neither closing and reopening CPF nor disabling and re-enabling the connection do help.

I’m unable to get useful hints from the logs about what’s the cause; I just see the names of the applications that got blocked after the shutdown, but I don’t see anything about the shutdown itself.

For the records, all started when I compiled and ran a program which should synchronize the system time against several time servers on internet; that was the first compile in absolute so of course there were many programming errors, and something the program did with the connection must have made CPF very upset ;D . Now my impression is that the shutdown mostly occurs when I open the code editor I had used to launch the compile from. I did set that editor as a trusted app and I deleted the compiled exe of my program, but the shutdown keeps occurring.
I just need to understand why it keeps shutting the connection down, or how to solve this problem anyway. Any suggestion will be appreciated!

Hopefully your first compile didn’t trash CF…:wink:
First thing is to check application monitor for any blocked rules. Then I would check the component monitor for any blocks.
Remove all block rules.
Blocking svchost in any way, usually gets you in trouble.
A reboot is often required when dealing with system files.
Also, have you checked your settings in windows, for your connection?
Hopefully someone else can help you with this.
A reinstall will probably work… ;D

It would be good if you told us what kind of connection you have.
Lan, ADSL, Cable…

ADSL, connected through ethernet.

Application monitor and component monitor don’t show particular blocks: only the “evil” apps and components look blocked, and svchost or other system components aren’t blocked.

Now, I opened again the code editor (or better, project manager), and this time the connection didn’t get shut down. Instead, CPF said: “Application thunderbird.exe; Lynx.exe {the the project manager} has loaded ehook.dll into the Parent application explorer.exe using a global hook which could be used by keyloggers to steal private information. Lynx.exe may be using explorer.exe to conceal its behaviour in an attempt to connect to the Internet with thunderbird.exe.”.
I selected “remember” and clicked Allow, and so far everything looks ok. I’m sure that Lynx isn’t malicious at all, it must have been my code which looked malicious ;D I’ll have to correct the most gross errors in it and see what the second compile will look like ;D . Thanks for your assistance.

Yes usually it’s something like that, who tend to complicate things…

Good luck with your programming and stuff. ;D
Make it a bit less “malicious”… :o

One thing is that when you change/update a program, CPF will see the cryptographic changes, so you will get a popup for it.

Yes, I’m aware of the crypto changes for CPF on recompiling my apps, that’s good and right, I can live with it, thanks for warning BTW.

I guess what made my first version trigger CPF was that it sequentially attempts to connect to several timeservers (for example time.nist.gov , nist1.datum.com , nist1-dc.glassey.com etc), without a delay between attempts; if one attempt fails, it immediately tries with the next server (this is the first thing I’ll have to change).

When I first ran it, all the connection attemps resulted into “Device I/O error”, probably because CPF prompted me for my app but the app had no timeout management (this is the 2nd thing I’ll have to change). So the app tried all the ~10 servers within a second or two ;D

I guess all this rightly looked to CPF like an app suddenly appeared on the system and attempting a burst of outbound connections… It makes a lot of sense that CPF just shut down the connection! (B)

What I don’t completely understand yet is why, for a period, CPF kept shutting the connection down just as a consequence of me opening the project manager I had launched the compile from; however after some attempts CPF prompted me about the project manager so I could permanently allow it and so far everything is fine.

I’m on a dialup connection, I was running Firefox, and this happened to me. Nothing malicious going on over here, I keep my system pretty clean. I had to reboot to fix it. Then it was working fine, then started acting up again about 5 minutes later. It made World of Warcraft lock up 3 consecutive times before I even saw the login screen (correct rules were set). I think this “feature” is bugged. I think it’s a terrible feature anyhow, cutting me off without warning and then providing no logged detail.

I loved the hour I had with this wall, but if it’s hassling me that much, I can’t keep it.

Well, it keeps happening sometimes here, not only with my messing apps ;D ; last time it has to have been RealPlayer, no other apps were running (AFAIK). Fortunately this is rare.

I’m not sure that that feature is bugged; I think it’s more likely that the criterium CPF uses to decide whether closing the connection is a bit tight; but I don’t know what the criterium is, so I can’t tell whether CPF applies it correctly or not; having to shoot in the dark, I’ll bet on yes :).

BTW I agree 100% that it would help if CPF did make the user aware about the fact that it just closed the connection, and maybe even about the reason, that is which app has caused that. Or maybe just giving a feedback in the logs: I wasn’t able to retrieve any clues in the logs about the occured shutdown of the connection.

Also not having to reboot the PC to get the connection back would be good, but I imagine that if CPF closes the connection in a way that requires a reboot, it’s because this way is safer, kind of it makes it harder for the supposed malicious app to reactivate the connection on its own (shooting in the dark again here).

Hello people,
it seems that i’m not the only one having the connection turned down. This happened two times, and both times the only programs working were Emule and the anti-virus (Avast). Shutting down the connection is a good feature, but for p2p users is not so good. I use to leave Emule working on for the night, but with this feature it doesn’t pay to leave computer on
I hope that someone can tell us how to fix this.
Besides this issue, Comodo is great. I normally say that Comodo fails because it protects too much (shutting down the internet connection)

Welcome to the forum.
Does your firewall log show any blocks at the time when you loose the connection?

I had a connection shutdown right now; the log just shows 4 identical entries:

Severity: Medium
Reporter: Network Monitor
DescriprTon: Outbound Policy Violation (Access Denied, Protocol = IGMP)
Protocol: IGMP Outgoing
Source: 137.112.194.189
Destination: 224.0.0.2
Reason: Network Control Rule ID = 5

The Network Rule with ID 5 is:

BLOCK and LOG IP IN or OUT FROM IP [Any] TO IP [Any] WHERE IPPROTO IS ANY

I don’t know, that sounds a bit tight… ;D But I’m not sure what it actually does, I don’t even think I have set it up myself, BTW up to 5 minutes ago I was connected as usual withouth problems.

The network rules 0 to 4 are all Allows.

After reboot, all the rules are still there like before, and the connection works.

The block rule is default and should be left alone… don’t change or remove it.
The IGMP block is common. If you need multicast (streaming audio/video) on your network, you should allow it.
So it doesn’t work to right click your connection and repair? You have to reboot?

When you have connection problems, you should check that you have svchost allowed in network monitor.
svchost.exe as application and service.exe as parent. Both can be found in windows/system32.

Another thing to try, is go to security/advanced/misc and uncheck “do not show alerts…”, check the “skip loopback…TCP”, and raise the alert level slider to the top.
Reboot. and allow everything with svchost and probably everything.

I would submit a support ticket if I where you. http://support.comodo.com

It seems that your suggestions worked; to be exact, the situation was already like you suggested to set it, except for the ‘check the “skip loopback…TCP”’; I did so; immediately after the reboot, the connection went down, I mean instantly, and I think this has to do with the fact that it was the first reboot with the new setting, because I hadn’t opened any program at all yet.

I rebooted again, and since then - that is in two days - the problem didn’t occur anymore, at all.

If it will, I’ll submit a support ticket as you suggested, but I’m quite optimist that the problem is solved; thanks.

That sounds great. ;D
Hopefully it will continue to work.