Problems with acquiring or renewing the IP address

[Guest]

[Little Mac]

No problem at all, Alex; glad to help.  Let us know if you need any info or help in continuing to iron this out.  If your ISP gives you some clue to what's going on, we may be able to help with a work-around, of not an actual solution.

LM

[Capinha413]

  Another guy with the same problem.
My Experince was in past week, my ICS PC refuse the delivery of IPs to the rest of lan.
So read this post I tryed:
- The rule "Allow, UDP, In/out, Any, Any, 67-68, 67-68";
- Disable Protocol Analysis;
- The combination of the two;
 An nothing.

Then I verify when i restart the pc this problem was fixed for +- 2 hours.
Next I discover that turn OFF-On Network Monitor I had the same result when I restarted the PC, for +- 2 hours.

This  instalation was 6 month updated, windows updated.
Next chalanged is  reinstall comodo firewall and then i Will Post here the result.
Thanks!

[Little Mac]

This  instalation was 6 month updated, windows updated.
Next chalanged is  reinstall comodo firewall and then i Will Post here the result.
Thanks!

When you reinstall the FW, it would be a good idea to do so in Safe Mode, so as to avoid conflict with other applications.

LM

[hazzamanazz]

Hi people.

I have this issue with version 2.1 and stop the using the firewall.
Yes, kinda lame, if you ask me...

I was an Agnitum Outpost Firewall happy user, but since they choose to follow the same path of Ahead and turn a very fine piece of code in a junkless bloatware, like Nero, I decide to give Comodo a second chance.

Gladly, this issue was solved, but there times when I need to renew my IP address manually and I have the same problem of you.
I solve this creating two rules for svchost:

First Rule
Application: svchost.exe
Destination: <your local network IP address for the modem> (you can find it in Comodo Logs, in the item "Inbound Policy Violation for DHCP" port (68))
Port:68
Protocol: TCP/IN
Permission: Allow

Second Rule
Application: svchost.exe
Destination: Zone <my network card>
Port:67
Protocol: TCP/OUT
Permission: Allow

Comodo is telling me the rules are safe.
Do you people agree?

Don't have more problems to change and renew my IP adress, since my ISP uses four DHCP servers and will be a lot of trouble creating a rule for each one of them.

[ ]'s

[Little Mac]

It's safe enough, but they won't work, I'm afraid... DHCP uses UDP, not TCP. 

Personally, I wouldn't focus on Application Monitor if you have a problem with your IP renewal, other than to make sure svchost.exe is Allowed IN/OUT UDP (past that, I personally don't take the time to define IP addresses or ports there).

The majority of the problems occur because Network Monitor needs an Inbound rule (ONLY IF you're having problems; otherwise, the rule is not needed), such as this:
Action:  Allow
Protocol:  UDP
Direction:  In
Source IP:  Any
Destination IP:  Any
Source Port:  67
Source Port:  68

By default, there is a NetMon rule to Allow TCP/UDP OUT for Any Source/Destination IP/Port.  This will allow the necessary outbound UDP to start the IP lease/renewal process.

LM

[allkatraz]

Well, it seems that many of us have this annoying DHCP problem. I just joined the club

I have an ADSL connection (USB SpeedTouch modem, not ethernet) shared with my brother's computer which can't acquire an IP address when Comodo is on. I tried every solution found here, nothing worked. I reinstalled Comodo with standard settings, i disabled protocol analysis and still nothing. When i click Repair on my brother's computer, the Activity tab shows sometimes

192.168.0.1:137 - 192.168.0.255:137
192.168.0.1:138 - 192.168.0.255:138

and sometimes    0.0.0.0:68 - 255.255.255.255:67

The log is always empty and the rules cover the IP and ports range (ANY)
Is there any way to solve this problem?

[Little Mac]

I have an ADSL connection (USB SpeedTouch modem, not ethernet) shared with my brother's computer which can't acquire an IP address when Comodo is on.

Welcome to the forums, alkatraz; sorry you're in the "club."

If you're sharing an internet connection, you first need to establish some communication capabilities between the two computers.  You do this by going to Security/Tasks/Create a Zone.  Define the IP range as needed.  Then, also in Security/Tasks, run the Network Wizard - Define a New Trusted Network.  Use the Zone you just created.  This will create two rules at the top of Network Monitor which will allow the two computers to communicate properly.  One will Allow IP Out from Any to Zone; the 2nd will Allow IP In from Zone to Any.

Given the potentially cranky nature of DHCP, you may find it helpful to add two more rules to the very top of Network Monitor (these will be done manually), in this fashion:

Right-click Rule ID 0, and select Add/Add Before.  Build the rule like this:

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

Repeat the step in blue above, and build the next rule like this:
Action:  Allow
Protocol:  UDP
Direction:  Out
Source IP:  Any
Destination IP:  Any
Source Port:  68
Destination Port:  67

Now reboot, just to clear any temporary memory and make sure the new rules are properly set.

That should resolve the DHCP issue for you.

LM

PS:  If you have CFP on both computers, those steps will need to be done on both machines.

[misog]

I have similar problems with aquiring the  IP address with Zone Alarm as well as Comodo firewalls. I have had this on different Pc's running different software and using wired or wireless connections. The only thing that has not changed is the Motorola Cable modem!!!

[Little Mac]

The only thing that has not changed is the Motorola Cable modem!!!

Welcome to the forums, misog! 

A high-speed cable connection can be a very odd thing, from what I've seen.  Many cable ISPs essentially form a kind of network comprised of various users (based on log traffic), and the user is almost forced to turn it into a Trusted Network in order to resolve conflicts (which is not good, IMO).

If you have gone through the steps in my post above, and also identified your ISP's servers to create custom rules for, you may want to temporarily try disabling "Do Protocol Analysis" to see if that helps.  Sometimes...

LM

[jjb3]

Well, it seems that many of us have this annoying DHCP problem. ...

192.168.0.1:137 - 192.168.0.255:137
192.168.0.1:138 - 192.168.0.255:138

and sometimes    0.0.0.0:68 - 255.255.255.255:67

The log is always empty and the rules cover the IP and ports range (ANY)
Is there any way to solve this problem?

Joined the club too. CF is giving an Application Monitor Waring on svchost.exe:bootp(67) with source ip 192.168.1.34 and svchost.exe(68) with ip 192.168.1.254, BUT in the Connetions tab it shows svchost.exe 0.0.0.0:67. Adding the Network Monitor rules like above will work.

Right-click Rule ID 0, and select Add/Add Before.  Build the rule like this:

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

Repeat the step in blue above, and build the next rule like this:
Action:  Allow
Protocol:  UDP
Direction:  Out
Source IP:  Any
Destination IP:  Any
Source Port:  68
Destination Port:  67

Using CF version 2.4.18.184. Problem only occures on a wireless pc, the wired pcs works fine.

jjb3

[Little Mac]

Using CF version 2.4.18.184. Problem only occures on a wireless pc, the wired pcs works fine.

Welcome to the forums, jjb3 ~

Wireless should work a little differently than wired, unfortunately, just to make it more confusing.  I'm going to PM another Mod who should be able to explain better than I.

LM

[panic]

[at] jjb3 and misog,

Can you both please clear the firewall logs, reboot and then attempt to reconnect wirelessly to the Motorola modem. Once the connection attempt has failed, export the logs and attach them to a reply to this topic.

Also, the following info may help us out;

What model Motorola is it?
Who is your ISP (just looking for some common ground)?
What is the internal IP of the modem (the internal LAN address, NOT the IP that connects to your ISP)?

Cheers,
Ewen :-)

[jjb3]

I dont have moterola, my wirelesscard is a Intel PRO/Wireless 2200BG and my wireless router is an Zyxel P-2602HW-D1A.

Weirdest thing has happend, after logging in today the ip address of svchost.exe just changed. But otherwise the ip address in the logs also changed.
First the log were showing normal ip adresses (192.168.1.34) and the Activity Monitor showed 0.0.0.0 and 255.255.255.255, but now its the other way around.

Router/Modem/Wirelessstation: ZyXel P-2602HW-D1A
ISP: Tiscali NL
Internal IP Router: 192.168.1.254
Internal IP Laptop: 192.168.1.34






(PS attaching the files wont work... Upload folder is full, total kb: 53)

[pepoluan]

Cable modems are sure one hell of a *****. Let me tell you what happened when connecting with a cable modem.

At first, your PC has no IP address. So it sent a DHCP Request to the Cable Modem.

At the same time, the Cable Modem sends a DHCP Request to the Cable ISP.

While waiting for the Cable ISP to give the Modem an IP Address, the Cable Modem will temporarily assign an IP Address (usuallly in the 192.168.1.0/24 network) to the PC, with a very short expiration (usually 30-60 seconds).

When the Cable Modem receives the IP Address from the ISP, it will wait until the temporary IP address expires; according to DHCP standards, the PC must ask for a "lease extension" to the Cable Modem, and at this time, the Cable Modem assigns the IP Address given by the ISP to the PC. Afterwards, the Cable Modem acts as a bridge for the PC to connect to the ISP using the ISP-given IP Address.

Thus, a rule allowing all traffic IN/OUT of 67/68 is necessary.

[panic]

G'day again,

You're in luck. I've got a Zyxel 2602 HWL as well. Although I don't use it for wireless now, I did when it was first set up (I've disabled wireless on the 2602 and added a DLink wireless access point. Zyxels wireless strength and accuracy sucks big time!). As follows are the two rules I originally used on the 2602;

Before adding these rules, please go through the application monitor and remove ALL BLOCK settings for SERVICES.EXE and SVCHOST.EXE, as these are both required to allow DHCP calls to be sent.

**********************************************

This rule needs to be rule ZERO (top of the Network Monitor rules list). This rule allows your PC, regardless of its IP address, to broadcast to port 67, which is used for DHCP request.

Action:  ALLOW
Protocol:  UDP
Direction:  OUT
Source IP:  ANY
Destination IP:  ANY
Source Port:  68
Destination Port:  67

**********************************************

This next rule needs to be rule ONE (second top of the Network Monitor rules list). This rule allows the incoming DHCP reply from the server to be received on port 68.

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

**********************************************

In explanation, a DHCP server is listening on port 67 for requests from the local LAN for an IP allocate request. For the request to be sent, port 68 needs to be opened for outbound access in CFP (this is what the new rule ZERO does). The request contains the current IP of the requesting device, in this case, your PC. The DHCP server then does a lookup of its allocation table and checks for the next available address in its pool. This valid LAN address is then sent to the IP address contained in the original request. The traffic goes from port 67 on the DHCP server to port 68 on the requesting device. To be able to receive this data, CFP has to allow incoming traffic on port 68 and this is what the new rule ONE accomplishes (hopefully).

Let us know how this works out.

Hope this helps,
Ewen :-)
 

[Tags:]