Option 1) I did that with no luck. The computer still requests (DHCP Discover) during the boot process.
Option 2) Yes, the would solve the problem but why should I have to buy 24 NIC cards for the DG43NB and another 24 cards for the DP43TF motherboards if the problem can be solved with an updated BIOS or driver?
Has there been a resolution to this problem? The BIOS is still sending DHCP request packets during the bootstrap process. The following BIOS settings has NOT fixed the problem:
After Power Failure: Stay off
Wake on LAN from S5: Stay off
Wake system from S5: Disable
Wake on PS/2 Keyboard from S5: Stay off
Boot to Network: Disable
and for good measure
XD Technology: Disable
Intel VT: Disable
I just updated the BIOS to the most recent version with no luck:
These motherboards are taking up DHCP resources in a LAN environment.
I have a similar problem, with just DP43TF boards (and have a post on that). Only a few PCs with the boards require static IP addresses, but which time the PC is booted (after patches, etc.), the NIC sends a DHCP request, gets DHCP assignment which updates DNS static entry for that PC (all of this happens before the Operating System loads). When the operating system loads, the PC will use the static IP. The static IP differs from the entry in DNS. Applications which use DNS forward and reverse lookup get the wrong address resolved. As a result, several applications fail or produce erroneous conditions (Windows Remote Desktop/Terminal Services), eEye Retina Network Security Scanner, Dameware NT Utilities and Remote Control, and several security related DNS reverse lookup conditions.
-Install BIOS upgrade with a fix for PXE requesting DHCP address, even when not enabled (if released by Intel).
-Install a separate NIC and disable the built-in NIC. Gets to be expensive and redundant, why pay for a board with a built-in NIC and then go out an buy another?
-Don't use PCs with the DP43TF or DG43NB, etc. boards for workstations which require static IP assignment. Gets to be expensive and stupid, bulk buy of multiple PCs then means splitting the buy to get a different motherboard. Common drivers go out the window, etc.
-Create a larger DHCP scope and use reservations to assign the desired static IP addresses in the desired range and exclude the addresses in the desired range which don't need a static assignment, yet. Starts to become an adminstrative nightmare, especially when the application which needs to use static IP addresses should be in a contiguous block, not scattered throughout the DHCP scope.
In my opinion, the only viable fix is a BIOS change.
I've called Intel a number of times and started a service ticket. I've even sent them my packet information showing them that the computer is asking for an IP and not the operating system. (I had the hard drive removed to prove my point.) No one from Intel has replied to my service request with a solution. It's as if they don't think there's a problem so they're not going to look into it. I don't know what else to do. Anyone else have any suggestions? I believe we need a BIOS upgrade.
We are having the exact same issue with 25 of our computers in a classroom setting. We have been tearing our hair out trying to isolate this issue. Who would have thought motherboard? Anyway, we are going to try the ALT-P BIOS changes tomorrow and see what happens. INTEL IF YOU ARE READING THESE POSTS this issue needs to be corrected with a BIOS update or something. All of our students are issued laptops and these crazy motherboards are pulling from our DHCP pool.
We have the same problem here and produced a temporary solution.
What we did is we got the MAC addresses of these computers.
We noted which IP is statically assigned for each mac address (eg. ComputerA: 001234567890 = 192.168.1.2)
We went to the DHCP Server and reserved the correct ip for each mac address based on the list, what happens now is:
1. When the computer prepares to boot up it asks for a DHCP address
2. The DHCP Server gives then him the reserved IP (e.g. 192.168.1.2)
3. Computer boots into the OS and uses the statically assigned ip 192.168.1.2
Not a perfect solution but somehow works for us.