I am running Windows XP SP2, Comodo Firewall v2.4.18.184
I have had issues on a new PC since I received it, by which I have sporadic connectivity. For instance: after sitting all night this morning I could not connect to the internet. I attempted to use ipconfig to /release and /renew, but the renew times out. It then displays the yellow triangle of horror over the system tray network connection icon.
“Limited or no connectivity”
Sometimes, it will occur in the middle of the day for no reason. The seemingly only way to resume network connectivity was to reboot the pc.
Upon recommendation of the hardware vendor, the NIC drivers had been updated and when the issue persisted, the mother board had been replaced (integrated NIC). This did not resolve the issue. I long-since thought this was OS related.
This morning, I came to the conclusion it may be the firewall. After right clicking the icon in the system tray and setting it to “Allow all” I could refresh my ip. I was then able to set it back to “Custom” and proceed as normal.
Have others experienced this? If so, what were the workarounds,?
Why may this be occuring (is there a security ‘feature’ that is causing this?
Is this a bug? If so, is it resolved in later versions?
In hind sight, my laptop (also running the same version) may have experienced this issue previously, but not as frequently.
Comodo is blocking the udp bootp protocol used to do dhcp. What is curious is that I don’t see alerts to let me allow it. The problem does not occur on my own network as I allow all activity for that network (only). But I am in a hotel room, and it is blocking dhcp. Looks to me like a default configuration bug where dhcp is not allowed. Sigh.
You would have to make a new Trusted Zone for each location that you use a different IP address. What I do is to allow the full range of IP addresses x.x.x.1-x.x.x.255 and then block anything in between that isn’t needed with block rules above the allow rules at the top of the Network Monitor list. What I do is just leave the rules in place and change the IP addresses according to what the IP is at the particular location that I am working. Takes about 5 minutes to set them up once I check the log to see what is being blocked.
jasper2408 – If what you are proposing is correct, then why would this issue happen intermittently? I.E, 95% of the time I have no issue. That doesn’t sound right to me, if the product is functioning correctly. My laptop goes all over the place, and I’m not about to take 5 minutes to change my firewall settings for every place I go.
Arkangyal – Same question. How come this would be an intermittent issue? That doesn’t sound right to me, if the product is functioning correctly. Aren’t ports blocked per the rules, which do not change upon reboot of the firewall (which then allows traffic)?
If that doesn’t work, try resetting your winsock32 file from a command prompt by running: netsh winsock reset
A reboot is necessary after you run this command.
This does sound like a hardware problem, but obviously not in your PC since you’ve done a hardware swap. So that leaves whatever your PC connects to, and what it connects thru as being the possible source of the problem.
I’m presuming you are connecting to a router. Is it in the mid-afternoon sun? Is it hot to the touch, or just simply warm? The Windows message of “limited or no connectivity” can mean that electrically things have gotten disconnected. I have had routers, and hubs, fail under similar circumstances.
More uncommon, and a real pain to run down, is a bad Ethernet cable. I’ve had that happen too.
Typically the PC NIC and the router have an indicator light that says there is a working electrical connection. If that indicator light isn’t lit, its definitely a hardware problem.
Zito, I read the MS KB article. This applies to loopback address issues. Why would that be my issue, if the issue is reset by setting the firewall to “allow all” “ipconfig /renew” then setting back to “custom”? That seems like a firewall thing, not an OS issue.
Mike, your recommendation doesn’t make sense to me because it works fine upon bootup. It’s randomly after 12, 15, 24, etc hours that the connectivity drops, unpredictably.
Grue155, this is definitely not a hardware issue. If so, it would not happen across multiple PCs on multiple independent networks, both wireless and wired in totally different physical locations. And, of course, changing comodo to ‘allow all’ and back to ‘custom’ fixes everything. Again – not a hardware symptom. Though initially, I did think this too and replaced all cables, removed routers, etc.
I give 99% chance this is a Comodo firewall bug, that is not functioning as it was designed.
It does sound like Comodo is blocking something. If it is doing so, the key is in the logs. You’ll have to monitor those closely (a pain, I know) since the problem occurs so randomly. Here’s my take, though, based on your mobility with the computer.
Works fine on your home LAN.
Works at some remote locations
Stops working suddenly at other locations
I think it’s an issue of DHCP configuration (not under your control) at some locations. I have found that some combination of network & computer configuration require two rules like this to be added to the top of Network Monitor (Rules ID 0 & 1):
Action: Allow
Protocol: UDP
Direction: Out
Source IP: Any
Destination IP: Any
Source Port: 68
Destination Port: 67
and
Action: Allow
Protocol: UDP
Direction: In
Source IP: Any
Destination IP: Any
Source Port: 67
Destination Port: 68
Not realizing you had the issue at home; I thought I read that it worked fine there and acted up only when you were travelling.
Getting a whole bunch of duplication in my post; I have edited that (not sure how that happened).
I would try those two rules, myself. I have had issues on occasion in the past when I had slightly more restrictive/defining Network rules, and it seemed to always cause problems.
Technically speaking, we shouldn’t need an In rule for DHCP, as it’s in response to our initiated Outbound request. However, UDP is a stateless protocol, meaning it isn’t as easily identified as a response when coming back in. It’s also difficult to define IP addresses or Zones for it to work in, because of the way it connects (ie, from 0.0.0.0 to 255.255.255.255, or from the 0 address to the DHCP Server addy, then …); it’s all over my pay grade, but you can confuse yourself more about it by reading here: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
Anyway, once I implemented the rules I gave you, I have had no problems with DHCP at any point in the process. Separate rules are important (IMO) because of the reversal of ports for Destination and Source depending on the direction of traffic. The local computer (ie, you) always uses 68 whether sending or receiving the DHCP traffic; the remote computer (ie, the server/router) always uses 67 whether sending or receiving (just to add to the confusion.
