I having a problem on new computers running Windows 7 64bit with the Intel 82579LM network device.
These computers, when sleeping, are responding to gratuitous ARP requests even after their DHCP lease expores.
Computer A gets a DHCP lease for 192.168.1.30 that expires in 1 day.
The computer goes to sleep.
1 day pases. DHCP marks the IP adress as available.
Computer B turns on and requests an IP address
DHCP assings 192.168.1.30.
Computer B does a gratuitous ARP request on that IP address to see if it is in use
Comnputer A responds to the ARP request (incorrectly - the lease is expired and Computer A did not renew while sleeping)
Computer B receives the ARP response from Client A and notifies the DHCP server the IP address is BAD - In Use.
Computer B receives another IP address.
Computer A wakes up and does a refresh and is assigned a new IP address.
We are getting a lot of IP address conflict errors on our network because the Intel NIC is holding on to IP addresses while sleeping. It is not refreshing the DHCP record while sleeping and is responding to ARP even after the lease expires.
Does anyone have any insite into the problem? Broadcom devices were also having this issue and it was fixed in a newer driver.
Sorry, I should have mentioned that the machines are running driver version 22.214.171.124 from 3/15/2012 although I suspect the problem is also in earlier drivers.
I am going to see if there are newer drivers.
The latest driver version is 126.96.36.199 dated 08/10/2012. You can get them from http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=18713 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 188.8.131.52 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.
http://www.intel.com/support/network/sb/CS-028693.htm Network Connectivity - How do I save and restore adapter and team configuration settings?
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 http://www.intel.com/support/network/sb/CS-029966.htm 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 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 184.108.40.206 (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.