BUG? WinXP SP2: Sporadic "Limited or no connectivity" due to Comodo v2.4.18.184

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.

  1. Have others experienced this? If so, what were the workarounds,?
  2. Why may this be occuring (is there a security ‘feature’ that is causing this?
  3. 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.

Any responses are appreciated.

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.


For this DHCP problem, how about adding OUT UDP 68? As i know, you computer connects from udp port 68 to target machine (ex. your router)'s 67.

Thanks for your responses.

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)?

This sounds like a bug to me.


There’s a patch for this which you can download from Microsoft, details in the “Overview”.

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.


you might disable block in out bound connections while booting in misceanellous (if i ever learn to spell it).

i think that affects auto dhcp, meaning assign ips.

let know if that helps.

And its no bug, hence it protectes a single dialup pc basicly by design.


PS: wild idea, for might freeze stop comodo in work mode long idle, i did check skip tcp udp loopback onitor.

hence the basic designed setup for absolute beginners :slight_smile:

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.

Thanks for the replies.

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.

Does anyone around here actually work for Comodo?

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.

  1. Works fine on your home LAN.
  2. Works at some remote locations
  3. 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


Action: Allow
Protocol: UDP
Direction: In
Source IP: Any
Destination IP: Any
Source Port: 67
Destination Port: 68

Might try that.



Thanks for your extensive reply.

Do you feel this still applies, if it:

  • generally works fine on the home lan, but on occasion (e.g. 2x per week or 2x per day) encounters the issue (on either computer, not at the same time)
  • generally works fine at the office, but on occasion encounters the issue
  • generally works fine at the lab, but on occasion encounters the issue?


My apologies, Avery, for 2 things:

  1. 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.
  2. 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 to, 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:

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.

Hope that helps,


Alright. Thanks for the clarification. I will give this a shot and report back after testing.