I had the same problem and solved it by shutting off the "Block all outgoing connections while booting. The problem is, at least in my case, was Comodo is last to load and I have several apps that load before it. As a consequence DHCP gets stepped on my Comodo’s blocking of outgoing connections and the IP’s get hosed because the system can not find the network. As you discovered, WinsockXPFix is not going to help you and may cause problems.
I went through the same thing being told that is was a problem with my NIC and network… Not hardly… it has worked fine for years with Look-N-Stop, KIS 6.0 a trial with Jetico’s FW 2.0, etc.
If you have a recent image (ghost, etc) of your “C” drive you might want to do a restore and then try a fresh install of Comodo.
Fred, this option can be found in SECURITY - ADVANCED - ADVANCED ATTACK DETECTION AND PREVENTION. Deselect “Block all outgoing connections while booting”. Click OK. Reboot the PC and retest.
If this works, accept my apologies, I should have remembered this waaay sooner.
Thanks guys, but that didn’t work. It did seem like the answer, but that option is off by default, so I’ve had it set like that from the beginning.
Is there a way to set CPF to manual start instead of automatically start at boot? I’d like to see if the network works when booted without CPF running. (And turning off CPF after boot won’t work because it’s obviously doing something at boot time.)
I went back to one of your posts where you stated what IP addresses you had on all machines when it works. What I noticed is that the second machine gets an IP which skips 2 IP addresses. What I am curious about is why doesn’t the DHCP server assign x.x.x.101 to the second machine? Is there something else that is using those 2 IP addresses?
Have you tried unplugging the second PC from the hub or unplugging the hub from the router and then plugging the non-working PC directly to the router?
I went back and installed the latest beta, .126, and turned on the boot blocking and it the delayed net access enough on boot to cause the 169.xxx.xxx.xxx problem again on my system. My system, WinXPsp2 -32, running a on a Intel Dual Core processor and 4gb of memory, cold boots in about 15 seconds with Nod32, SSM and Atomic Time Sync loading with Comodo’s Boot Blocking off. With it on the cold boot time goes to 70 seconds! I reported this problem to Comodo’s tech people on a trouble ticket… and have heard nothing since. When I initially encountered the problem I tried to troubleshoot it by first turning everything off, but it didn’t help and the cold boot (restart too) was painfully slow. The only common denominator for me and the slow boot was Comodo’s Boot Blocking. The only other thing I did was to turn the COM/OLE monitoring off because it got to be a nuisance to me and unnecessary because I am running SSM to catch anything trying to get cute and access the net or other processes without my permission.
In my case, I thought the IP change caused and prolonged boot may have been a hardware issue. But I tried Comodo on an older system with an Intel 845 board and a 2.4ghz P4 that is used as a DVR and media server and it caused the same problem with it too. At that point I gave up on it as I was satisfied that the problem was with Comodo’s boot blocking feature and not with my software or hardware.
Comodo has a lot of potential… My only wish was that they try to keep it light… a pure fire wall… and leave, HIPS and such to the individual packages that do it best. Trying to be all things most often doesn’t work as well as the dedicated software packages. Look at KIS 6.0 and Outlook 4.0… the problems that result seem to be expotiential as more features are added (spam blocking, ad blocking, spyware blocking.) they become mediocre… good at nothing…
Yes thats the problem then. It seems the previous installation of a firewall is still there and causing conflicts. DHCP must be handled statefully by CPF and should not have caused any problems. If im anot wrong, Kerio driver is fwnt.sys or fwdrv.sys or something like that. Check the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ for entries of such a driver and delete it if exists.
But be sure you delete the correct key otherwise it will create more problems.
FWIW The problems I had occurred on a clean system… I image my installs without any FW’s AV’s HIPS, etc, so I can test and evaluate software on a clean install and I have something to fall back to if I totally trash my system. IMHO, I think it is a hardware or service conflict that is causing this. Stem talked about this over on Wilder’s when he tried Comodo a month or two ago.
Fred: If you had Kerio installed, do a registry search with regedit for “kerio” The drivers Egemen is referring to are “Legacy” and they are locked. When you find them, there are two iterations of this legacy driver, you will need to unlock them by right clicking>permissions, then select allow. This will allow you to delete the key.
jasper: The other numbers are other machines on the network.
egemen: I checked the registry and couldn’t find anything.
hillsboro: There are no remnants of Kerio, nor were there any when I tried to install it and got the error message from it.
So now I’ve tried everything I can think of, including several things I didn’t post about. So for now I’m back to AVG, unless anyone else has any last minute ideas. Thanks for all the help, it was very much appreciated; I’m only sorry that we couldn’t figure it out to help other people.
I installed comodo and it works great the issue is that if I disable my network and enable it again, I do not get my IP address back but 169.X.X.X If I temporarily disable Comodo and eneble the network, I get my normal IP address. What is going on?
It wont do good. It will block all the connections. You can set CPF to “Allow All” and restart. This will mean disabling everything CPF is doing thus helping you to see if CPF is blocking.
Can you please send us your CPF logs when you have trouble while reacquiring your IP adress? This way we can see whats wrong.
Hmm, didn’t block my connections. But as it turns out, it wouldn’t actually restart, either. Well, it started, but only the Network Monitor was running; everything else was Off.
I guess it’s on Automatic start, or not at all… Sorry about that, Fred; I “assumed” it would work. I guess in a way it did for me, but I had to undo all the changes to get it start again, and that was on a reboot; it wouldn’t start manually. So no quick way to check your settings…
Something is definitely interfering with the DHCP process. When you configured your NIC with a static IP address, mask and def. gateway, did you go over the Comodo logs afterwards? Did you see anything that was being blocked? Did you manage to log your PING attempts? Please post copies of the log if possible
Another thing… I read something about 1394 (FireWire) bridging. Do you connect an external network device using this connection?
