new install -> ipconfig issues when booting up

Greetings All !

I just installed Comodo for the first time.

I’ve noticed that when I reboot, the system doesn’t seem to be able to contact the DCHP server to get its IP address assigned. It keeps coming up with some funky IP address of its own. If I do an “ipconfig / release” it releases fine. But when I do “ipconfig /renew”, it can’t get to the DCHP server.

Now, when I initially rebooted it after my first installation, it came up with what apparently was my home network, but it basically named it after my ethernet card. I accepted this. But when I rebooted again, the system basically said it was detecting a NEW network of the SAME name again. (Of course, it wouldn’t accept that same name.)

OK, so after this happened twice, I decided to remove the two duplicate network names and go into the properties of the one listing left (other than the loopback IP listing). I set it to the IP range of 192.168.1.0 - 192.168.1.255. I figured this would contain every possible IP in my home network. Saved it.

I also unchecked the general option to have it locate new networks.

Rebooted.

The system still can’t communicate with the DCHP server.

Of course, if I tell Comodo to disable the firewall and then do my “ipconfig /release”, “ipconfig/renew”, then suddenly I can get to the DCHP server, get assigned my IP address, connect out to the Internet, and post on a forum like this!

I then went back and used the Stealth Ports Wizard and chose the “alert me to incoming connections” option.

Re-enabled the firewall and booted.

And when the system comes up, I still can’t connect to the DCHP server.

Any thoughts?

Thanks!

-= Dave =-

Are you getting any block messages in your log? There have been related issues and a bug report, especially for wireless systems. Main workaround seems to be to use a fixed IP address for your NIC. See https://forums.comodo.com/bug_reports/301730418309_causes_wireless_internet_connection_problems_x32-t19885.0.html and referenced thread, since both wireless and wired now seem connected.

This certainly SEEMS to be the issue.

I am getting errors from app svchost… about blocking UDP traffic from 0.0.0.0 port 68 to 255.255.255.255 port 67.

I tried creating a global rule to allow this. That didn’t seem to work.

Then I tried creating a global rule to allow ALL UDP traffic from 0.0.0.0 to any/any/any as per one post within that thread you pointed to. Neither rules seems to have worked. Logs still show the same error.

Yeah, I could probably try to hard-code the IP address into each of my machines, but why should I have to? The funny thing is, I downloaded and installed Comode onto a second PC in my basement. And it came up fine and got its IP address just fine. No troubles there!

Gonna try to set svchost.exe to a trusted application (I had it set to “web browser”, for some reason) and reboot.

-= Dave =-

Fascinating… (:NRD)… making svchost.exe a Trusted App seems to have resolved the issue!

-= Dave =-

OK, you are blocking outbound packets, and web browsers aren’t allowed to send out UDP. All the global rules do is allow or disallow connection requests from/to the application rules.

Yeah, but what SHOULD svchost.exe be set to?

I can’t remember exactly what they were set to on my primary machine, just prior to me flagging it as being a “trusted application”. But my basement PC, which never had a problem, is set to:

“Custom”

  1. Allow any IP out to any IP where protocol is any
  2. Allow TCP in from IP in (router’s IP / netmask 255.255.255.0) to Any/Any/Any

Gee, no mention of UDP at all here.

-= Dave =-

Allow svchost to sent tcp and udp out. Or don’t make any rules for it. The web browser rules you used end in a block and log and blocked the udp out. I don’t have any rules for svchost and all works fine. What OS are you using? Your first rule allows udp out, btw. And SPI allows the inbound response. :slight_smile:

Yeah, you don’t want to be blocking svchost; it’s vital to your connectivity (as you now see), updates, and other things you may want as well. As for the difference between computers, yeah, they sometimes are, and I can’t tell you why.

Basically to create your connection, the system sends UDP traffic outbound from Source Port 68 to Destination Port 67 on your DHCP server. The traffic comes back Inbound from Source Port 67 to Destination Port 68 on your system. UDP is Stateless, and can sometimes run into trouble without a rule to Allow it In.

On my wife’s system, I don’t have to tailor the network rules for DHCP. On my current system, I do (but not on my old system). I’ve seen in the past on the same system one version of the FW would need special rules, another wouldn’t. Maybe how I was holding my tongue… :wink:

Computers. They’re just not logical…

LM