DHCP semaphore timeout[Help]

Help for v3
1

Borrowing the words of one Viper pilot, “this ought to be different”.

Installed CFP v3 on one of the machines in the local LAN herd, using typical install with all the defaults.
Reboot per install. The machine comes up, and is isolated. DHCP did not get an address. Go to Control-Panel → Network Connections, and disable then enable the LAN connection, watching the packets with tcpdump from another machine. DHCP packets never showed up on the wire.

Checked the Windows Event log, under System there are these two messages:

`
Event Type: Warning
Event Source: Dhcp
Event Category: None
Event ID: 1003
Date: 2007-11-21
Time: 18:04:56
User: N/A
Computer: SOMEBOX
Description:
Your computer was not able to renew its address from the network (from the DHCP Server) for the Network Card with network address 001122334455. The following error occurred:
The semaphore timeout period has expired. . Your computer will continue to try and obtain an address on its own from the network address (DHCP) server.

For more information, see Help and Support Center at Microsoft Support.
Data:
0000: 79 00 00 00 y…

Event Type: Warning
Event Source: Dhcp
Event Category: None
Event ID: 1007
Date: 2007-11-21
Time: 18:05:05
User: N/A
Computer: SOMEBOX
Description:
Your computer has automatically configured the IP address for the Network Card with network address 001122334455. The IP address being used is 169.254.46.77.

For more information, see Help and Support Center at Microsoft Support.
Data:
0000: 00 00 00 00 …
`

Did a reboot, watching traffic from an outside machine. DHCP DISCOVER packets do not appear on the wire at all. Change CFP to allow everything, and use Network Connections to disable then enable the LAN. No effect. I tried watching the sequence with some of the Sysinternals tools, but too many things happening and I’m not clear on which ones to be looking at.

Uninstall CFP v3 for comparisons. Reboot. DHCP packets on the wire by the time the WinXP Welcome Screen comes up. (Which means doing a logon to debug is proving a tad awkward, as it’s already well after the fact.)

The LAN herd is not the typical consumer configuration. It’s a workgroup, no Domain Controller. However, the machines are fairly well locked down using Local Security Policies set thru MMC. There are local custom policies in effect, and permissions throughout are fairly well ■■■■■■■ down and welded in place.

I’m suspecting there is a conflict between CFP v3 and one or more of these local security settings. Just no clue as to which one. CFP v3 seems to recognize something amiss, as the status is reported with a big red circle with a white X. Yet the diagnostics check says the installation is good. I’m not calling this a bug, as the machine setup is way too atypical.

I’m a little short on ideas, and on spare cycles just now. Anybody have any thoughts, or investigation strategies? Take your time, as I’m offline till Friday 1800 GMT thereabouts.

2

Some progress in getting something to work. Here’s what’s happened so far:

Uninstalled CFP v3.00.12.266. Downloaded sysinternals.com procmon, which is a combined monitoring tool, which has a boot-time logging capability. Ran procmon thru a normal DHCP boot, just to see what a normal operation sequence looks like. Warning to anybody who tries this: it produces a lot, and I do mean, a lot, of output.

Installed CFP 3.0.12.266. Rebooted to complete the installation. Same situation as before. Reboot again, with procmon recording the DHCP boot. It’s different, and I haven’t finished going thru the results just yet. Some preliminary observations though:

Of about 900 000 recorded events, the DHCP operation occurs about event 82 000. The CFP cmdagent service seems to load about event 404 000, which is well after the DHCP has supposedly taken place. That would mean that something else taking place. There seems to be a driver “inspect.sys” that is involved somehow. More research is needed, as it takes a while to compare two 900 000 long lists of bits.

Uninstalled CFP v3. Change the machine configuration to use a static address. Confirm operation as all good and working.

Installed CFP v3.0.12.266, taking all defaults. Watching traffic on the LAN wire from another machine, shows initial outbound arp per normal boot. Then the wire goes dark. Changed CFP settings to be fully disabled: firewall off and Defense+ turned off. Reboot the machine. And now live on the wire.

Some progress… The machine can ping and be pinged.

Run CFP Update, which updates to CFP v3.0.13.268. CFP is still showing the summary page with the big red circle with white X saying there is some kind of problem. Run CFP diagnostics, which fixes something. But the problem is still present, whatever that problem is.

Navigating thru some of the CFP screens, this shows up: Defense+ → Active Process List, is empty but for the message “There are no items to show”. Odd, as Windows Task Manager, sysinternals Process Explorer, and WinPatrol active tasks, are all showing a very busy machine.

So something in the CFP install didn’t install quite right. I don’t know if the process list being empty is related to the DHCP problem, but I’m suspecting that it is.

3

Some more bits into the fray…

Another member of the LAN herd got CFP 3.0.13.268 installed. This is a more typical near out-of-the-box configuration machine. CFP installed and is working just fine. That now gives me something to compare against.

The first machine, which I’ll now refer to as machine Alpha, is still not working properly. I’ve been going thru the MMC Local Security Policy, reverting settings back to their unconfigured status. It hasn’t helped. With the second machine working (machine Bravo), I’ve been able to compare directory structures and permissions.

Permissions seem to be the same on the Comodo directories. However, there are some differences. Machine Alpha, in the “AllUsers” DB\ADB directory, its an empty directory. On machine Bravo, there are two subdirectories: EXE and SYS. A procmon trace shows that DB\ADB is created by cmdagent, but no failures are recorded by procmon. No information in the Windows event log either. Nor have I found any kind of installation log.

One interesting thing of note: if CFP 3 is set for simply “disabled”, things don’t work. If Defense+ is set to “permanently disable”, things seem to work (meaning I can ping other machines on the LAN).
Whatever the difference between disable, and permanent disable, it seems to be a key difference.

It’s going to be a few more days before I can get back to this. For the moment, machine Alpha is back to running 2.4, with no apparent difficulty.