Welcome, Guest. Please login or register.
October 10, 2008, 09:29:56 PM

Login with username, password and session length

199098 Posts
22882 Topics
54911 Members

Latest Member: ohbewanx1

Search:     Advanced search | Tag Cloud
+  Welcome to the Comodo Forum
|-+  Desktop Security Products
| |-+  Comodo Firewall
| | |-+  Frequently Asked Questions (FAQ) for Comodo firewall
| | | |-+  Problems with acquiring or renewing the IP address
« previous next »
Pages: 1 ... 8 9 [10] 11 12 13 Go Down Print
Author Topic: Problems with acquiring or renewing the IP address  (Read 49013 times)
Little Mac
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 6017



« Reply #135 on: May 29, 2007, 04:23:40 PM »

Toggie can you give the path to Services as I'm in Linux right now and I can't quote it off the top of my head. I think I know what it is but I don't want to get it wrong.
Go to Start/Run, type in "services.msc" (without the quotation marks).  (I'm not Toggie, but I was here...)

LM

Logged

date
dcfldd split=2G conv=noerror hashwindow=0 hash=md5 bs=32768 hashlog=/mnt/sda1/images/hash.log if=/dev/hda of=/mnt/sda1/images/LM.dd
date
cat LM.dd.* | md5sum > verify.log
date
jasper2408
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 651


« Reply #136 on: May 29, 2007, 04:29:37 PM »

Go to Start/Run, type in "services.msc" (without the quotation marks).  (I'm not Toggie, but I was here...)

LM



Excellent! That's the quickest way.

EDIT: Actually I always forget about those shorcuts.    Sad

jasper
« Last Edit: May 29, 2007, 05:25:34 PM by jasper2408 » Logged

CFP 3.0.22.327beta  CMF   Avast Pro  SAS Pro Sandboxie Win XP PRO SP2 (x32)
Topsail
Newbie
*
Offline Offline

Posts: 1


« Reply #137 on: May 31, 2007, 11:23:17 AM »

I chewed on this problem for days. First the client couldn’t acquire or repair the IP address, then when I finally got that to work I found the client had lost its internet access, etc. In the end I gave up and put static IP addresses on the network, and now it works like a dream.

If anyone isn’t sure of the settings for static IP addresses, there’s a good walk-through by ‘Advil’ on the Tech Support Forum here:

http://www.techsupportforum.com/microsoft-support/windows-xp-support/117-windows-xp-home-network-help.html 

Logged
Little Mac
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 6017



« Reply #138 on: May 31, 2007, 12:24:17 PM »

Thanks for the post, Topsail.  Glad that static IPs worked out well for you.  After all that, you could probably use some Advil (ibuprofen) yourself, eh?  Wink

LM
Logged

date
dcfldd split=2G conv=noerror hashwindow=0 hash=md5 bs=32768 hashlog=/mnt/sda1/images/hash.log if=/dev/hda of=/mnt/sda1/images/LM.dd
date
cat LM.dd.* | md5sum > verify.log
date
Eric Cryptid
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 1086


Security Saskquatch


« Reply #139 on: June 02, 2007, 11:44:09 AM »

I finally figured out what was sending out IGMP messages that were being block. It was right under my nose... WINDOWS MEDIA PLAYER 11. I've disabled the IPMG under the NETWORK tab in WMP's settings...

Now if I could only figure out the:
Outbound Policy Violation
ICMP = Port Unreachable - Source: my ip - Destination: My router's DNS address:

DNS 1:  205.188.146.145

It's actually AOL's IP Address - See Below when googling the address:

WHOIS results for 205.188.146.145
Generated by www.DNSstuff.com
Location: United States [City: Reston, Virginia]


Using 15 day old cached answer (or, you can get fresh results).
Hiding E-mail address (you can get results with the E-mail address).


OrgName:    America Online, Inc
OrgID:      AMERIC-59
Address:    22080 Pacific Blvd
City:       Sterling
StateProv:  VA
PostalCode: 20166
Country:    US

NetRange:   205.188.0.0 - 205.188.255.255
CIDR:       205.188.0.0/16
NetName:    AOL-DTC
NetHandle:  NET-205-188-0-0-1
Parent:     NET-205-0-0-0-0
NetType:    Direct Assignment
NameServer: DNS-01.NS.AOL.COM
NameServer: DNS-02.NS.AOL.COM
Comment:   
RegDate:    1998-04-18
Updated:    1998-04-27

RTechHandle: AOL-NOC-ARIN
RTechName:   America Online, Inc.
RTechPhone:  +1-703-265-4670
RTechEmail:  *******[ at ]aol.net

# ARIN WHOIS database, last updated 2007-05-16 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database
 
Eric
« Last Edit: June 02, 2007, 11:46:13 AM by EricEgan » Logged

Cryptid - Any animal or creature that has been reported to have existed, but has not been proven to.

Security Fanatic

Please Read Forum Policy Before Posting - https://forums.comodo.com/new_member_information/forum_policy-t1516.0.html
Toggie
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 1256


"Oh, let me have just a little bit of peril"


« Reply #140 on: June 02, 2007, 03:05:34 PM »

Ericegan.

I'm glad you found the source of the IGMP messages, I had a feeling it was going to be mediaplayer.

With regard to the ICMP messages, you might want to check this thread:

Router messages
Logged

One man alone can be pretty dumb sometimes, but for real bona fide stupidity, there ain't nothin' can beat teamwork.
Little Mac
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 6017



« Reply #141 on: June 03, 2007, 04:59:09 PM »

Probably part of your connectivity, based on AOL being your ISP...  If you've got their software installed (and if it's AOL, you probably do), it may be pinging outbound as part of its process.  CFP is blocking it as you've likely taken such allowances out of the Network Monitor, thus it's a Port Unreachable...

LM
Logged

date
dcfldd split=2G conv=noerror hashwindow=0 hash=md5 bs=32768 hashlog=/mnt/sda1/images/hash.log if=/dev/hda of=/mnt/sda1/images/LM.dd
date
cat LM.dd.* | md5sum > verify.log
date
panic
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 5469


... and I say to myself, "What a wonderful world"


« Reply #142 on: June 04, 2007, 08:37:35 AM »

For Australian users of the "Unwired" wireless broadband :

If you are having constant disconnections when CFP is running, you will need to add additional rules to the Network Monitor to allow your wireless modem to allocate/reallocate an IP address to your PC. You will need to know the IP address of your DHCP server.

This can be determined by opening a command line window (click START - RUN and enter CMD) and entering "ipconfig /all". This will display the current IP configuration, including the DHCP server address. Make a note of this address.

As the firewall has to be turned ON to make changes, but you are getting disconnected when the firewall is on, you will need to set the firewall to ALLOW ALL before connecting to the internet. Once connected to the internet, run the IPCONFIG command shown above and record the DHCP details. Disconnect from the internet by turning the modem off and then set the firewall back to CUSTOM so we can make changes.

The two rules are as follows;

Action : ALLOW
Protocol : TCP or UDP
Direction : IN
Source IP : IP ADDRESS OF YOUR DHCP SERVER
Destination IP : ANY
Source Port : ANY
Destination Port : ANY

Action : ALLOW
Protocol : TCP or UDP
Direction : OUT
Source IP : ANY
Destination IP : IP ADDRESS OF YOUR DHCP SERVER
Source Port : ANY
Destination Port : ANY

These two rules need to be moved to position 0 and 1 in the Network Monitor

You will also need to skip local loopback connections to allow the Unwired supplied "Venturi Configurator" to run. These options are found in SECURITY - ADVANCED - MISCELLANEOUS.

You should now be able to turn the Unwired modem back on and consistently connect to the internet with CFP set to CUSTOM.

Many thanks to rabbit_fighter for his persistence in helping to track this down (and no thanks to the support staff that were supposed to contact me but didn't. Tongue).

Hope this helps,
Ewen :-)

« Last Edit: June 04, 2007, 08:40:35 AM by panic » Logged

As your mums would say, "If you can't play nice with all the other kiddies, go home".
All users are asked to please read and abide by the  Comodo Forum Policy.
If you don't like it, don't use the forum.
Eric Cryptid
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 1086


Security Saskquatch


« Reply #143 on: June 07, 2007, 01:57:46 AM »

Ewen,
    Trying out your rules to see if it resolves my DCHP IP Renewall messages. With the exception of the loopback and using my DNS IP Address 205.188.146.145... Fingers crossed anyway...
Logged

Cryptid - Any animal or creature that has been reported to have existed, but has not been proven to.

Security Fanatic

Please Read Forum Policy Before Posting - https://forums.comodo.com/new_member_information/forum_policy-t1516.0.html
panic
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 5469


... and I say to myself, "What a wonderful world"


« Reply #144 on: June 07, 2007, 02:34:57 AM »

Cool Eric, let me know how they work out.

Ewen :-)
Logged

As your mums would say, "If you can't play nice with all the other kiddies, go home".
All users are asked to please read and abide by the  Comodo Forum Policy.
If you don't like it, don't use the forum.
ocasional
Newbie
*
Offline Offline

Posts: 3


« Reply #145 on: July 09, 2007, 07:47:03 PM »

Hello!

I've read all this thread, since this is my problem saw no need opening a new topic, hope I did right.
CPF is installed in this machine since January and always run perfectly with standard settings till 2weeks ago.
At first I thought it was an ISP problem, connection going down frequently (each one or two hours) and difficult reconnection after, or at system startup. But my ISP assures if there is a problem, it is in my PC.
I have a direct connection through net plate/cable modem. If I switch off cable modem after system shutdown, reconnecting becomes more difficult afterwards. IP release/renew or repair connection is useless, all I can do is wait till connection aquires itself. Allow All or shutting down CPF doesn't work as well, but noticed that disabling Protocol Analysis helps reconnecting after reboot. Although I am not so comfortable disabling Protocol Analysis, is it safe? Added one new rule allowing DHCP and DNS IP servers in or out, on UDP connections to port 67-68, but did not seem to work, and I'm not comfortable with that either, not knowing if it's a safe rule.
I send my log (did not add the rule yet) and it seems to me the problem relies in that IGMP access denied (don't know what it is). You can see at 19:06:31 hours and afterwards, the time I caught income traffic and got my IP and access.

Could you please help me configure CPF correctly?
Is it right to disable Protocol Analysis since I didn't have any trouble till now?
Should I try reinstall CPF?
Please ask for any other information you might need.
Sorry for my bad English.

Any help is appreciated, thank you.

Best regards,

Alex
Logged
Little Mac
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 6017



« Reply #146 on: July 10, 2007, 10:07:59 AM »

Welcome to the forums, ocasional  Wave

Since you have been using CFP for a while, my guess is that your ISP may have changed something on their end so that the process is a little bit different now.  You could ask them, but there's a good chance the answer would not be very revealing... Wink

If you shut the modem off after you shut down the system, it will take a while for it to come back online after reboot; the modem has to recalibrate each aspect of the connection; I don't find that to be unusual.  This process can take a few minutes (I have to go thru this as well), and until it's done, there isn't anything you can do to connect (because the connection isn't active yet).  But that only addresses the bootup issue.

For the frequently-dropped connection, I would expect that as part of the changes, there is a new level of interaction between your computer and ISP's servers, regarding your connection.  If disabling Protocol Analysis doesn't make a clear and immediate difference in your connection issues, I would not personally disable it; too much reduction in protection for not enough increase in connectivity = not a good trade-off.  Wink

You may need to create some specific network monitor rules to allow DHCP to take place.  One of the default network rules is Allow TCP/UDP Out Any Source/Destination IP/Port.  That should take care of the outbound request.  However, you may need to create a specific In rule for DHCP.  If the IP address of the DHCP server is a single static IP, I would start this way...

Open Network Monitor.  Right-click the top rule (Rule ID 0) and select Add/Add Before.
Action:  Allow
Protocol:  UDP
Direction:  In
Source IP:  (the DHCP server IP address) - if it's not static, you may set to 'Any'
Destination IP:  Any
Source Port:  67
Destination Port:  68

Another option with the DHCP server IP address is to find out from your ISP if they have a series of servers (ie, a Range of IP addresses that are in use).  Then instead of a single IP, or Any in that rule, you would select a Range of IPs to use (which would encompass the addresses they give you).

Hope that helps,

LM

Logged

date
dcfldd split=2G conv=noerror hashwindow=0 hash=md5 bs=32768 hashlog=/mnt/sda1/images/hash.log if=/dev/hda of=/mnt/sda1/images/LM.dd
date
cat LM.dd.* | md5sum > verify.log
date
ocasional
Newbie
*
Offline Offline

Posts: 3


« Reply #147 on: July 10, 2007, 05:49:15 PM »

Thank you Little Mac, sincerely, I think once more it is an ISP issue, because other users are complaining about the same thing, although I seem to be the only one in my area cell.
Enabled Protocol Analysis back on, today I've waited almost 50 minutes to get connection and that item was disabled so, it wasn't a solution after all.
Most of the times I shut off the modem after the PC, and turn it on before the PC. Usually the leds take no more than 15 seconds to stop blink and stabilize, and when all (43)processes are finally running there used to be already a valid IP.
Changed my rule for your rule, I had DHCP server IP as Destination IP, not source IP, my mistake. I think it's static, it's been the same for quite some time but I'll check it out with ISP as well as if there was any change on their end. I believe answer won't be revealing at all (we have outer world ISP's stuff, no matter which ISP  Embarrassed ), but it's worth the try. I'm just afraid to call in the technicians, cause if they detect that everything is ok, the cost will be high at the end of the month for calling them.
I know I should have tried a system start-up with CFP service disabled, that will be tested tomorrow. Just considering all the possibilities, and if new rule does not solve, next I'll "take a look" at net plate drivers, just in case. I'll share results afterwards.

Once again, thanks very much  Comodo Rocks

Best regards,  Smiley
Alex
Logged
Little Mac
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 6017



« Reply #148 on: July 10, 2007, 09:00:45 PM »

Alex,

I realize I did not comment on this in my reply, but should have... you noted earlier that changing the FW Security Level to Allow All did not change the connection/DHCP scenario. 

Typically this indicates that it is not an issue with CFP, as Allow All pretty much disables any protection the FW might offer, thus taking it out of the picture entirely.

I would suspect a previous firewall having left residual traces that were interfering, or some active security software running during install, except that you have been using it successfully up until this point. 

This then points to some other change... Have you had any updates or changes, especially to hardware, drivers, etc?  NIC firmware update, or your modem?  There has to have been some event which triggered this problem.  Most likely it's local, although it could be remote (ie, something on your ISP's end).  And I agree; don't want to call the techs in if you don't have to - they will surely find some way to 'prove' it's not their problem, and leave you holding the bill...

LM

 
Logged

date
dcfldd split=2G conv=noerror hashwindow=0 hash=md5 bs=32768 hashlog=/mnt/sda1/images/hash.log if=/dev/hda of=/mnt/sda1/images/LM.dd
date
cat LM.dd.* | md5sum > verify.log
date
ocasional
Newbie
*
Offline Offline

Posts: 3


« Reply #149 on: July 11, 2007, 07:24:41 PM »

Hi Little Mac,
Yes, Allow All does not help to establish connection. And today I started the system with CFP start-up disabled so, definitely I guess it's not a firewall issue. Took 10 minutes to acquire IP. I posted here because I saw this topic, sorry I was wrong. Anyway, I'll leave the new rule untouched for the time being, and wait for ISP's technical support contact.

Had no updates of hardware or drivers, no new software, just updates to Anti-Virus and Anti-Spy/Anti-Malware software (lucky, never caught one). I know that the ISP injects a jar file in the system (or in the modem, don't know) with configuration settings (like up/downstream bandwidth), but that is done silently and I have no idea where the file is allocated, or when they last updated it. And that's it.

ISP is making changes in their lines, and number of users with the same problem is increasing (haven't read of anyone in my area yet though). They usually do this kind of work without any warnings, and tend not to take responsibility when clients get hanged. I'll have to wait and hope situation gets back to normal on short time. Number of times connection drops-out decreased a lot, that's already a good sign  Smiley

Thank You very much for your help support LM  Cheers

Best regards,
Alex
Logged
Tags:
Pages: 1 ... 8 9 [10] 11 12 13 Go Up Print 
« previous next »
Jump to:  

SSL Firewall
Page created in 2.522 seconds with 19 queries.
Powered by SMF 1.1.5 | SMF © 2006, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks
Design by 7dana.com