I’ve just noticed a strange behavious with CFP where sometimes my update internet time will work and at others it just will not… these happens right away. For example, I tested this 8 times in the last 10 minutes and it worked 3 times, and failed 5 times.
each times it works, the picture that shows svchosts UPD in/out is displayed (in the activity log)… so in a way, everytime I see UDP in/out show, I know the update will work, but
sometimes, UDP out only will show up… same internet address… but just UDP out… and in that picture as you’ll see, it shows 90 bytes send, but 0 received everytime. It always fails.
So I tried to add the rule UDP out only but CFP didn’t accept it since I already had a rule for UDP in/out that was the same thing. (at least I think that’s why it didn’t add the rule).
Anyone care to comment?
REgards… Rej
P.S. I removed accidently svchost.exe from my app monitor (btw, a dialog asking for confirmation would be nice here :), and now it won’t popup to ask me if I want to add it or not. So right now, if I don’t add the rules myself, I can’t use svchost.exe. I’ll try rebooting and see if it resets, but I’d LOVE To know why it doesn’t ask me (popup) about it when I try using it… right now it always fails when I try to update my time.
Rebooting brought back the popup for svchost.exe (while booting). I then changed the svchost.exe TCP/UDP in out rules to 4 rules of TCP out, TCP in, UDP out, UDP in with same results.
Wondering if the problem might be in my Network Monitor rules, I’ve added the picture as well…
What are, if any, the corresponding CFP Log (Activity tab) entries from time-sync attempts? Also, I’m not sure looking at the Network Connections is the best way to monitor this either… some connections might very transitory & be missed or change depending on other, external, factors. Try using something that has a full history of all the connections (no matter how short) and the data sent/received … a Packet Sniffer (like Wireshark) is ideal for this purpose.
Network Monitor: Could you post another screen shot of the Network Monitor with Rule 4 selected… I’d like to see the detail of that rule. Thanks.
No Logs at all I’m sorry to say. All are checked but nothing happens while I’m trying to synch the time – either it was successful or not.
I’ll check out Wireshark, thanks for the input on this one :). Note that all the 8 tests were done within the same period… no closing of “Date and Time Properties” or Comodo… just hitting the update button 8 times in a row and having it work 3 times out of those 8 times. That’s what has me baffled. Perhaps Wireshark will help… I’ll give you more info on that one once I have any.
here’s the screenshot for ID 4. It’s the port I use with Azureus (and Azureus works perfectly under the current rule set).
Downloaded and installed WireShark (had tried Ethereal a few years back)… Man, I’ll need time to figure this out… a LOT of info there.
Also, I’ve noticed a lot of traffic on my opened port (the one I use for Azureus) even tho I haven’t used Azureus for a few days, so I decided to change the ID 4 to another port… and now the traffic has increased 10 fold hehe. Again, I’ll have to read the FAQ and user guide to get a tiny idea of what I’m doing here.
btw, I tested the update time with wireshark active and the only difference I could see (removed the ARP packets – hope the answer isn’t there) is that I received a NTP server response when it works, otherwise, I don’t get one and Windows probably times out.
BTW, whiel typing this, I decided to try with setting Comodo to ‘Allow all’ and I got the same errors… I’ll uninstall it and try with another firewall to see if I get the same issue… if yes then it might just be the MS servers OR my own setup at home. If so, I apologize for having posted this here thinking it was Comodo while it perhaps isn’t at all :-[
Uninstalled Comodo and reinstalled ZA (yikes) and out of 10 tries, it failed 3 times.
I think it might be the servers that are an issue… that and some timeout issue somewhere. I now consider this NOT a Comodo issue. Just feeling bad thinking that it was Comodo :-[
Anyhow, I’ve got a new toy to play around with (Wireshark) to find out how come my port was soo being targetted (the only one I had left open for Azureus) and it being targetted even though I wasn’t using Azureus and had rebooted on several occasions since I had last used it.
ZA blocks the attemps (as I think Comodo did as well, although I couldn’t see the logs on that… I can see the blocks made by ZA on their logs).
You’ve been busy. No need for the PCAP files… I think you’ve discovered the issues location. With CFPs Security Level set to Allow All CFP is disabled. No blocks or alerts will be issued. This has, to date, has always proved CFP innocent of whatever it is.
The blocks might be because of packets that are being perceived as being unsolicited (ie. not requested). This can happen due to error (less likely) or the dropping of connections by remote servers (more likely)… thus leaving in-transit incoming packets without an existing connection & being viewed as unsolicited as a result.
Just feeling bad thinking that it was Comodo :-[