Problems with acquiring or renewing the IP address

[Eric Cryptid]

What is the Solution to all of this? I get the same problem if my laptop goes into standby and occasionally when online using AOL or even IE7 I get disconnected from the wireless and then it reconnects as (Unsecured) and then bumps me off again a few times before it eventually after much hassle goes back to Secure connection. I'd hate to have to find another firewall if this problem persists and I don't know of any firewall good enough to compare to comodo. I have got a copy of ZA Pro and Webroot Firewall but I don't like either. Help Us!

[Eric Cryptid]

Sorry if the last message sounded a bit in a panic. I'm just fed up of my wife complaining every other day that she's been bumped off AOL and then my Wireless message says - "Connected to Sleepy Hollow (Unsecured) and then she's let online again and then bumpted off two minutes later and this repeats a few times before it connects properly again.

Eric

[Little Mac]

Ultimately, I dont' think you should need any Network Rules for DHCP, as long as you've kept the default rules.  The default rules will allow Outbound UDP, from Any IP to Any IP, on Any Port, and that's what you need.  The return contact is Allowed as an Inbound response to an Outbound request.

The key may be that you have Application Monitor rules for svchost.exe with parent services.exe to Allow the application Inbound traffic to Destination Port 68, and another rule to Allow Outbound to Destination Port 67.

That works fine for me.

LM

[Methuselah]

Greetings all.
Joined the forum to join in this "fray" . . . migrating from other firewalls, seemed pretty good until this "disconnection" thing.  Bummer.

In my case, Comodo is on WinXp Pro SP2 operating as database and mail server for home LAN.
External firewall and DHCP is provided by another old machine running M0n0wall.

Internet Connection comes up disabled/limited functionality after some hours.
IP has changed - I know this because m0n0wall is setup to assign static IP using MAC address.
Trying a repair to get a correct IP fails - log shows all the same things you are reporting.

What does work is to close Comodo / go to allow all, repair the connection and restart/reset.
Funky workaround.

I have uninstalled - will retry shortly with all default options.

Anyone with any other bright ideas they want to try - this environment is not live, so you can play.



Robin
Jhb, South Africa.

[Little Mac]

Robin,

If switching to Allow All works to repair the connection, then 99% it's a Network Monitor Rules issue.  Other 1% is Application Monitor.

If you'll post a screenshot (taken at full screen) of your Network Monitor (you can attach under Additional Options), that will help.

LM

[pepoluan™]

Ultimately, I dont' think you should need any Network Rules for DHCP, as long as you've kept the default rules.  The default rules will allow Outbound UDP, from Any IP to Any IP, on Any Port, and that's what you need.  The return contact is Allowed as an Inbound response to an Outbound request.

Isn't UDP a connection-less protocol? Therefore any replies to the outbound UDP has no correlated inbound packets, unlike TCP which is a connection oriented protocol.

That said, remember that DHCP replies (from the DHCP server to the DHCP client) is addressed to 255.255.255.255. I've seen some occasions which use 224.x.x.x, but I'm not quite sure why. Nevertheless, both address can be aggregated into an IP address/mask combination of 224.0.0.0/224.0.0.0.

[Methuselah]

Unfortunately I had already removed prior to taking screenshot of troubled system.
Have reinstalled with all defaults - as per "N00B install video".

Now we wait . . . will only add the tweaks I added after some hours.
One step at a time.


[attachment deleted by admin]

[Eric Cryptid]

Hi all... IT's occurred to me that it might just be an AOL connectivity issue in my case instead of a Comodo problem. I know that AOL runs at a specific MTU so perhaps if I try changing the MTU from !500 to 1450 or whatever AOL Specifies that might fix the issued. Also, for some reason AOL really only likes WEP for it's wireless security. I've been runing WPA-PSK TKIP instead of the suggested WEP by aol because I have about 7 neighbours with Wireless routers in range of where I live and a Signals Engineer living across the street. What I hate is that my Linksys WAG354G Wireless Internet Gateway doesn't support WPA2!

Will keep you posted if problems persist.

Thanks for your patience.

Eric

[Little Mac]

Therefore any replies to the outbound UDP has no correlated inbound packets, unlike TCP which is a connection oriented protocol.

Within the context of the DHCP lease renewal, the client computer will send a request to the host/server, and there's a back-and-forth process that then occurs on those two ports.  I have seen it logged as starting from 0.0.0.0, going to 255.255.255.255, as well as from the client IP to the host/server IP, and some other odd ones as well.  Beats me as to why, but that's what I've seen cause the renewal problems.  There may be other things as well.

But in the context of Network Rules, all that should be needed is that default Outbound UDP rule (it's actually a TCP/UDP rule...).  Then just make sure svchost.exe is allowed to communicate on those ports (Application Monitor).

LM

[pepoluan™]

Within the context of the DHCP lease renewal, the client computer will send a request to the host/server, and there's a back-and-forth process that then occurs on those two ports.  I have seen it logged as starting from 0.0.0.0, going to 255.255.255.255, as well as from the client IP to the host/server IP, and some other odd ones as well.  Beats me as to why, but that's what I've seen cause the renewal problems.  There may be other things as well.

But in the context of Network Rules, all that should be needed is that default Outbound UDP rule (it's actually a TCP/UDP rule...).  Then just make sure svchost.exe is allowed to communicate on those ports (Application Monitor).

Yes, you are right, re the UDP interaction between the client and the server.

What I was trying to say is:

TCP is connection oriented; you can easily differ between an attempt to open a connection -- which has the SYN bit set to 1 in TCP's header -- with ongoing communication -- which has the SYN bit reset to 0 and ACK bit set to 1. Furthermore, TCP packets have sequence numbers which indicates explicitly that it is part of a long string of TCP packets to be reassembled at the receiver (excepting extremely short communication which fits into a single TCP packet).

UDP is connectionless; every packet is treated as a monolithic unit of data. It depends on the application using the UDP to determine if a UDP packet is only part of a communication. There is no SYN, ACK or sequence number in the header of a UDP packet.

Therefore, even though there's a back-and-forth communication between client and server in DHCP, there is no way for a computer to determine that a certain UDP packet is the reply of a prior UDP packet that it sent out; a computer must always assume that a received UDP packet is finished in its entirety, and has no relation whatsoever to prior UDP packets. It's the job of the application to determine such relationship (which, in this case, the DHCP client daemon/service).

So, the only way to positively allow incoming DHCP packets from a DHCP server is by allowing Incoming UDP to port 67 (or 68, I keep forgetting which is which). Merely allowing Outbound UDP is not enough.

[Methuselah]

No problems after clean re-install.

Seems like a definite PEBKAC error, guys . . . hastened by my lack of RTFM of course 

Trying to be the hero, I did not take the automated offerings route, preferring to see what was being detected, defined etc.  I can't quite remember what I did to break it, but I think it may have been the definition of the Trusted Zone.
I had one entry for both In and Out - the Wizard splits it into two.

I'm off to run that backup script before I do any further tweaks.

[Little Mac]

UDP is connectionless; every packet is treated as a monolithic unit of data. It depends on the application using the UDP to determine if a UDP packet is only part of a communication. There is no SYN, ACK or sequence number in the header of a UDP packet.

Okay, but if you watch the process occur on something like Wireshark, you will see the flags on each part of the transaction, including ACK. 

Now, the internal workings of such things is not anything I know much about, but if it works exactly as you say, it seems to me that CFP would be blocking pretty much all communication, then (well, not all, but a whole lot).  There must be something more to it than that...

At any rate, I have no UDP In rules in the Network Monitor, and DHCP lease works just fine.  The only time I've had difficulty with it was when I tried to define to/from IP addresses for the process.  And yes, I get confused on which port is which too, as it seems to work a little differently than other similar processes.  All I know is for AppMon, svchost has DestPort 68 In, DestPort 67 Out.

LM

[pepoluan™]

Okay, but if you watch the process occur on something like Wireshark, you will see the flags on each part of the transaction, including ACK.

Then what you are seeing is a TCP transaction, as UDP's header has no field for any flags whatsoever. See here.

Now, the internal workings of such things is not anything I know much about, but if it works exactly as you say, it seems to me that CFP would be blocking pretty much all communication, then (well, not all, but a whole lot).  There must be something more to it than that...

At any rate, I have no UDP In rules in the Network Monitor, and DHCP lease works just fine.  The only time I've had difficulty with it was when I tried to define to/from IP addresses for the process.  And yes, I get confused on which port is which too, as it seems to work a little differently than other similar processes.  All I know is for AppMon, svchost has DestPort 68 In, DestPort 67 Out.

well I am a certified Cisco trainer so I am required to know such things

Here's a nice, succinct illustration of how DHCP works:

http://www.linklogger.com/UDP67_68.htm

In summary:
- Port 67 is the DHCP server's port, used to receive DHCP requests and send DHCP 'offers'.
- Port 68 is the client's port, used to send DHCP requests (to the server) and receive DHCP offers (from the server)

I guess DHCP still works because AppMon has svchost DestPort 68 In allowed, and my guess is AppMon is prioritized over NetMon. As long as NetMon has no Deny rule that includes Port 68 In, DHCP will work. In other words:

- See NetMon and AppMon. Is port blocked? If yes, block. If not...
- See NetMon and Appmon. Is port allowed? If yes, allow. If not...
- Default block (i.e. the generic IP In/Out Deny rule as the last NetMon rule)

Thus, if your computer is not a DHCP server, you should be able to safely block port 68. But port 67 must be opened for Outbound & Inbound traffic, either explicitly through NetMon or by specifying the DHCP client through AppMon.

[Little Mac]

Then what you are seeing is a TCP transaction, as UDP's header has no field for any flags whatsoever.

Check out this post; see the 2nd attachment, where you'll see what I'm talking about.  It may not be a header in the same sense, but it's still the ACK...  http://forums.comodo.com/index.php/topic,6345.msg47408.html#msg47408  And we know (right?) that it's UDP because that's how svchost communicates for the DHCP lease.

I guess DHCP still works because AppMon has svchost DestPort 68 In allowed, and my guess is AppMon is prioritized over NetMon. As long as NetMon has no Deny rule that includes Port 68 In, DHCP will work. In other words:

In CFP NetMon has ultimate authority.  You can allow an application till you're blue in the face, but if it's trying to access the internet in a way not authorized by NetMon, it's still a No-Go.  If it were any other way, you'd have no security.  The In aspect of AppMon simply means that an application is allowed to accept an Inbound communication, if allowed by NetMon.

Header aside, there is some (there has to be) means of the system identifying the return/response and it is that which allows the Inbound UDP response from the DHCP server to the client.  Otherwise, CFP would block the snot out of it.

LM

(the

[pepoluan™]

Check out this post; see the 2nd attachment, where you'll see what I'm talking about.  It may not be a header in the same sense, but it's still the ACK...  http://forums.comodo.com/index.php/topic,6345.msg47408.html#msg47408 

Ahh... that's not UDP's ack. It's a special DHCP packet called "DHCPACK" (spaces added for clearer presentation). UDP has no ack. See:

http://support.microsoft.com/kb/169289
http://www.oucs.ox.ac.uk/network/dhcp/firewall.xml.ID=ack

And we know (right?) that it's UDP because that's how svchost communicates for the DHCP lease.
In CFP NetMon has ultimate authority.  You can allow an application till you're blue in the face, but if it's trying to access the internet in a way not authorized by NetMon, it's still a No-Go.  If it were any other way, you'd have no security.  The In aspect of AppMon simply means that an application is allowed to accept an Inbound communication, if allowed by NetMon.

Header aside, there is some (there has to be) means of the system identifying the return/response and it is that which allows the Inbound UDP response from the DHCP server to the client.  Otherwise, CFP would block the snot out of it.

Well, since you put it that way... is it possible that Advanced Protocol Analysis allows it before NetMon blocks it?

Because there is absolutely no way for a system to determine that a UDP packet is a reply to a prior UDP packet, unless the content of the packet is analyzed.