The latest driver version is 22.214.171.124 dated 08/10/2012. You can get them from Download Center.
If the latest drivers do not resolve the issue, try disabling the ARP offload in the network connection properties to confirm that is the feature that is causing your issue. If you disable the offload and the issue still happens, then you might want to check for management engine updates in case the ARP is coming from there.
If you have Intel(R) PROSet installed, then you can uncheck Respond to ARP requests without waking system in the Power Managementtab. If you do not have Intel PROSet installed, then you can uncheck Protocol ARP Offload in the adanced tab.
The same suggestions apply to NS requests for IPv6.
I have updated the drivers to 126.96.36.199 and the problem persists. My network team is telling me that the client is still responding to ARP requests past the client's DHCP lease expiration. Once the client's DHCP lease expires - if the client has not renewed its DHCP lease, the client should stop responding in the affirmative to ARP requests for that IP address since the client no longer "owns" the IP after lease expiration.
I will try next to disable ARP offloading, however I think that it is still an issue if you are setting drivers by default to respond incorrectly to ARP requests for expired IP addresses. If you offloaded ARP requests are being responded to incorrectly by the device, then at a minumum, the default setting should be switched to disable this function.
It is also unclear to me how I would set the ARP offload to "off" on 5000+ systems we have with this NIC. I have client managment tools (System Center Config Manager) to deploy software/settings to clients. Does Intel have any guidnace on setting this value programmatically outside the GUI?
I agree with you that the network connection should not be responding to ARP requests on expired leases. I want to find out if the issue goes away when the offloading is turned off so I can pass the information on to our software engineering team. When I asked
Some command line tools are available that you might be able to use in scripts to deploy configuration changes if that is what you decide to do.
You could possibly use the script described on the link below to save the configuration you want to deploy and then "restore" the same configuration to all the devices. That might be the easiest way.
There is also a command line version of Intel(R) PROSet that you could probably call from within your scripts, but that is probably more complicated than using the save and restore script above. See Network Connectivity - Configuring Advanced Features in Windows Server Core Installations.
You could also use WMI, to make configuration changes. The documentation is at http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=9405.
Let me know if disabling ARP offloads makes any difference.
Sorry for taking so long to get back to you on this issue.
We set up a test enviornment in the following way.
We created a network with two computers both with the Intel 82579LM running driver version 188.8.131.52 (Dell optiplex 9010 running Win7x64 Enterprise)
We created a DHCP pool with a single address and set the lease time to 5 minutes.
We powered on Computer A and it received the IP address in the lease pool - lets call it 192.168.100.50
Then we put computer A to sleep.
After 10 minutes, we turned on Computer B.
Network traces show that Computer B received the 192.168.100.50 that was now available since the lease from computer A had expired. Computer B then did an ARP to see if the IP address was available.
Computer A responded to the ARP request even though its lease had expired and it no longer owned that IP address. Computer B sent a response to the DHCP server that the IP address was bad and notified the user that an IP conflict existed.
Next we disabled ARP offloading on Computer A and computer B, cleared the DHCP server of errors and repeated the scenario.
We turned on Computer A and it received the IP address 192.168.100.50
Then we put Computer A to sleep. Then we waited 10 minutes.
Then we turned on Computer B. Computer B received the IP address 192.168.100.50 from the DHCP server. Network traces revealed that Computer B performs an ARP request to see if the IP is in use. This time, sleeping Computer A did not respond to the ARP request and Computer B functioned normally without error and without notifying the user of an IP conflict.
This scenario, which should be easily repeatable at Intel shows a fairly serious bug in the driver/hardware. Either the NIC should be renewing the IP address while the computer is asleep or the NIC should stop responding to ARP requests once the lease is expired. The NIC should not be responding to ARP requests after the lease is expired - the device no longer owns that IP once the lease expires without renewal.
Disabling ARP offloading is a workaround to the problem. We don't install IntelProSet so lots of the solutions for programatically changing the setting across our systems won't work. I will check out the WMI idea and see if I can make that work. We have > 7000 computers with this NIC chip so it is a significant undertaking. It is surprising that this error would go undetected by customers. I suppose people with very long lease times may seldome run into it. The computer needs to be asleep for longer than the DHCP lease time for the problem to show. You shoudl feel free to share my contact information with your driver developers.
I have some contacts within Intel from working on some issues with the wireless drivers. I wonder if I should start looking through some additional channels for support, or will this contact here in the forums get the ball rolling?
Uh oh. Looks like the WMI solution also requires ProSet to be installed. We don;t have Proset installed on a single one of our systems. I will need to look for some other way to disable that setting.
Do you think intel would supply me with a custom signed driver where ARP offloading is disabled?
I really am averse to installing ProSet on our client systems.
Thanks for the information.
RE: The NIC should not be responding to ARP requests after the lease is expired. When I spoke to a developer about this issue, he was surprised that the NIC was responding to ARP requests on an expired lease. So I am going to escalate this issue to the developers.
However, with all built-in network connections, the device behavior is also dependent on the NVM or BIOS settings that support the network connection. At this point I don't know if this might turn out to be a driver bug or something in the settings on your computer systems. You might want to raise this issue with whoever manufactures your computer systems, e.g. Dell, just in case this involves more than a driver update.
RE: I will need to look for some other way to disable that setting.
I am only familiar with the methods I posted about earlier.
I have been able to write a VB script that can disable ARP offloading.
This is a workaround to the problem rather than a solution. I still think it is a problem you would want to correct in that the driver as shipped has ARP offload enabled and so would cause a problem for the majority of your customers - assuming I do not have a problem that is unique to our environment. I would also rather avoid pushing out a VBScript to change driver settings as it is somwhat risky.
I have done as you suggested and opened a case with Dell enterprise support. My technical account lead will escallate it within Dell Engineering. Do you happen to have any ticket or case information on Intel's side that Ican provide to Dell engineering? I have given them a link to this forum topic for reference.
Dell has received a response from Intel engineering and the case has been closed.
Intel engineering states the hardware is fuctioning as designed.
" The Intel driver stores TCP/IP address during S3/S4. This causes client to reply to ARP request while in S3 even if lease has expired."
So, as far as Intel engineering is concerned it is not a problem that the NIC continues to respond to ARP for an IP address that the client no longer has a lease for. Totally BS, but whatta ya going to do?
The only workaround for this problem is to disable ARP offload, which is on by default.
I have not experienced this problem with other NIC vendor's implementation of ARP offloading. And I note in google searches additional Intel customers are experiencing issues with problems related to this issue.
I was curious as to why this issue could not be fixed via a simple driver update. I asked and got an explanation from one of the driver engineers.
Windows* is supposed to wake the system at some point before the DHCP lease expires and renew the lease. In previous versions of Windows this worked properly. Sometimes users were surprised by systems waking up to renew the DHCP lease, because the users were not aware of why the system woke up.
Here are a few more details that help explain why this is not simply something that can be fixed with a driver change.
The TCP/IP stack is responsible for obtaining and maintaining the information received via DHCP. None of this process is offloaded into the controller, so if the operating system does not wake up the system to renew the lease, then the old information stored by the network connection will be stale.
In low-power states the network connection is working in a very low-power mode and only responds to pre-defined events. The configuration of these events is programmed by Windows before the system enters the sleep state. These events can include responding to ARP and NS packets in a keep-alive mode, Wake-On-LAN packets, and changes in the connection state between the system and the link partner. In this mode, the network driver is not active and no information is passed between the Network adapter and Windows until the system wakes.
Renewing the DHCP lease requires that the TCP/IP stack be awake and active because everything can change. The new DHCP address can come from a different DHCP server and the default gateway, DNS servers, WINS servers, etc. can change.
I know this does not resolve the issue for you, but I thought you and other readers might be interested in knowing what was behind the issue.
Message was edited by: Mark H @ Intel to fix a typo.