Comment on CPF 2.3.5.62

I want to report my experience in cold-booting after the installation of CPF 2.3.5.62 yesterday. First, as was mentioned in a post of Egemen’s yesterday, there was no alert regarding Fast User Switching or Terminal Services. Evidently the one alert after installation yesterday caused CPF to realize that these services are disabled on this system deliberately.

On the other hand, the log shows an entry this morning : “Application denied access (svchost.exe: 255.255.255.255: bootp(67))” When I boot after a complete power-down situation, my DSL “modem” (Westell WireSpeed 2100) must fetch a new IP address from my ISP (BellSouth). Presumably the bootp call is connected with this operation, part of the DHCP process. I believe CPF should either accept or ignore this event, not deny access, but I don’t see a way to do this at the moment.

Hi pudelein,

I had the same problem at first. it was necessary to go into Network Monitor and create a rule for the DHCP process to work. I don’t remember the exact way I created (not at home now) but after doing so I was able to create a rule in the Application Monitor for svchost, and resolved the problem.

EDIT Here it is:

Allow, UDP Out, Destination ip 255.255.255.255, Port 67,.

I’m pretty sure you also need UDP In and port 68 for bootp response and DHCP server initiated connections.

Hope this helps,
Ewen :slight_smile:

Cprtech and Panic: thaks for your suggestions. However, I have been doing some additional testing and am now entirely confused ???. As I read the network rules and the application rules that I have, svchost.exe should be able to handle the DHCP/BOOTP requests already, with no further additions. The logged message shows that this assumption is not entirely correct, so I decided to see what I have to do to trigger the message. I have tried four things, none of which has yet resulted in a CPF log message about blocking svchost.exe’s request for bootp information. The things that have failed are these:

  1. I logged onto my Westell WireSpeed modem [this logon uses the default browser, FF in my case], disconnected from the Internet, and then reconnected, thus forcing the issuing of a new IP address. I did get the desired new address, but there was no message logged by CPF, perhaps because of doing this through the browser (???).

  2. I did a normal reboot. This does not change the IP address and no CPF log message appears (I knew this already as mentioned in the OP).

  3. I did a “warm” reboot: that is, I shut the machine down, but did not power the modem and other auxiliary gadgets down. Again, nothing occurred on booting again. The IP address was again unchanged.

  4. Finally, I shut down the computer, powered down everything (that is, turned off my surge protector) and waited awhile. Now when I booted the machine, there was a new IP address, but there was nevertheless no message about bootp in the CPF logs.

I am left with the notion that there might be a timing issue here. It is necessary, but not sufficient, that the modem power be switched off: this forces a new IP address to be requested at the next startup. However, there might be a race between CPF (presumably cmdagent.exe) and whatever modules in WinXP are involved in acquiring the IP address from the modem.

If anyone has any ideas, I would welcome them, but I suspect this may be an issue that has to be lived with (easy to do…only one log entry per day or even less if I leave the machine running). It would be nice to understand this, though.

Well, I don’t know about that. I still think you need to create in Network Monitor the port 67 rule, as well as the port 68 rule panic posted, otherwise svchost will be denied when DHCP requests are made.

Thank you panic. I forgot to mention that one :wink: