none
How to change ARP offload setting when IP lease expires when client PC in sleep?

    Question

  • In most cases, DHCP is used in network environment. DHCP server sends out Lease Expiration Time to DHCP client when assigning DHCP IP. If the lease time expires when the PC is in sleep mode, ARP offload seems still working and will respond to DHCP server’s ARP request wrongly, because the original IP of the PC has expired and been marked as available at DHCP server.

     Question: how could a PC and who in the PC should change the ARP offload settings in this case?

    Thanks.
    Friday, December 14, 2012 6:38 AM

Answers

All replies

  • Hi,

    Maybe the Link wasn’t described clearly. Please check the following KB article.

    Network adapter responds to ARP or NS requests for incorrect IP addresses in Windows 7
    http://support.microsoft.com/kb/2655087

    Best Regards,
    Aiden

    If you have any feedback on our support, please click here


    Aiden Cao
    TechNet Community Support

    Monday, December 17, 2012 7:27 AM
  • Hi,

    How are things going? I just want to check if the information provided was helpful. If there is any update or concern, please feel free to let us know.

    Best Regards,
    Aiden

    If you have any feedback on our support, please click here


    Aiden Cao
    TechNet Community Support

    Thursday, December 20, 2012 4:56 AM
  • I just wanted to pop in to say that we have this same problem with Intel NICs.  It is not resolved by the May 2012 update.  I have heard of the same issue with Broadcom, but newer drivers from Broadcom supposedly resolve the issue.  This problem is much more promenant in areas with shorter lease times.  The lease time must be shorter than the amount of time a computer would sleep in order to experience this problem.  If your lease time is something like 2 weeks,  then a computer would need to be asleep for longer than two weeks before the problem manifests.  Similarly, this problem is very pronounced in an area with short lease times - say 4 hours.  Where DHCP address space is tight, the number of IP addresses being marked bad can cause the DHCP pool to be oversubscribed.

    Consider this scenario to illustrate the problem.

    Machine A requests and receives an IP address 192.168.10.2 which expires in 4 hours.

    Machine A is used for 2 hours and then sleeps.

    2 hours pass by. The lease on 192.168.10.2 for machine A expires.

    Machine B is turned on and does a DHCP request.

    DHCP returns 192.168.10.2. 

    Machine B does an ARP request on that IP address to make sure it is not in use.

    Machine A responds (incorrectly) to the ARP request.

    Machine B displays an IP address conflict and sends a bad IP report to the DHCP server.

     DHCP marks that IP address as Bad.

    ----

    The problem is that Machine A's ARP offload engine should have stopped responding to the ARP requests when the DHCP lease expired.  Instead, Machine A continutes to respond erroniously that it is still using the IP address after the lease expires.

    This is not the same circumstance as the error described in the May KB.  In that case the machine, while sleeping, is responding to an incorrect IP address rather than an expired one.  In the error we are describing in this thread, the ARP offload is incorrectly responding to an expired lease.  It SHOULD respond to ARP requests up until the time the lease expires, it is incorrectly responding to ARPs AFTER the lease is expired.  The ARP offload pays no attention to the lease expiration time.

    I have an active case open with Dell (our hardware vendor) and Intel - the OEM.  So far they have been able to duplicate the problem, but have not provided a solution aside from disabling ARP offloading.  This is not ideal since the drivers ship with ARP offload enabled by default.  A step needs to be taken after the driver is installed to disable ARP offloading.





    • Edited by ToddMiller Thursday, January 10, 2013 8:17 PM Spelling errors
    Monday, January 07, 2013 11:21 PM
  • I have received confirmation from Intel Engineering via a Dell support case that Intel NICs will continue to respond to ARP while sleeping even after the lease on the IP address expires.  According to Intel, this is "by design."  This means that unless ARP offloading is disabled you will run into problem with IP collisions in areas where you have Intel network cards.  Clients that are sleeping will hold on to IP addresses without renewing them and mark IP addresses as BAD in your DHCP pool. 

    You wil need to disable ARP offload on all Intel NICs to avoid this problem.

    Thursday, January 17, 2013 4:31 PM
  • I received some more clarification from Intel on this issue.  Intel says that it is not their responsibility to renew the DHCP lease or stop responding to ARP while the computer is sleeping.  It is the responsibility of Windows and the TCP stack to renew.  Windows puts the computer to sleep and Intel is set to respond to ARP requests while the computer is asleep.  Intel says that at DHCP lease half-life, Windows should wake the computer and perform a DHCP renewal, then go back to sleep.  They say that in earlier versions of Windows, the computer wakes from S3 to renew DHCP address leases, but in Windows 7 it doesn't.  So Intel is placing the blame for this problem at Microsoft's.  It is Window's job to maintain the DHCP lease, and S3 sleep is allowing (incorrectly) the lease to expire.  
    Sunday, March 03, 2013 2:47 PM
  • Todd -- Thank you for your posts here and on the Intel forums (http://communities.intel.com/thread/31990). We've been struggling with this issue for a long time. We have a procedure to disable ART offloading manually on each computer we deploy, but we occasionally miss some systems. You mentioned you wrote a VB script for disabling ART offloading. We've been wanting to push that setting out via group policy but haven't found a way yet. Would you mind sharing the VB script? Perhaps we could call it from a GPO, unless there is a better way. Thanks!
    Tuesday, April 23, 2013 10:02 PM
  • Here is a code snippint.  I do this as part of a larger script so there may be variables in this code that need to be defined.  It should give you the general idea anyway.  We have the same problem with broadcom (3COM) drivers so there is a section of this code for 3COM too.  It is obvious in the code which is for intel and what is for 3COM...  I am also setting values to enable WOL which is often not set correctly in the driver default

    'Setting the correct settings of the power management tab of the NIC
    Set objInstance = Nothing
    const HKEY_LOCAL_MACHINE = &H80000002
    strComputer = "."
    Set StdOut = WScript.StdOut
     
    Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ 
    strComputer & "\root\default:StdRegProv")
     
    strKeyPath = "SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}"
    oReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys
     
    For Each subkey In arrSubKeys
        strKeyPath = "SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\" & subkey
        oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"BusType",intBusType
        oReg.GetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,"Characteristics",intCharacteristics
        If intBusType = "5" and intCharacteristics = 132 then
    	'wscript.echo "Found the NIC at " & strKeyPath & ". Setting WOL Value."
    	intBusType = Null
            intCharacteristics = Null
            oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,"PnPCapabilities",288
        	szPMARPOffload = "999"	
        	oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"*PMARPOffload",szPMARPOffload
        	If szPMARPOffload = "1" then
        		oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"*PMARPOffload","0"
        	end if
    	szEnablePME = "999"	
        	oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"EnablePME",szEnablePME
        	If szEnablePME = "0" then
        		oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"EnablePME","1"
        	end if
    	oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"DriverDesc",strDriver
    	if left(strDriver,4) = "3Com" then
    		oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"RWUARP","ENABLE"
    		oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"RWULink","DISABLE"
    		oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"RWUMagic","ENABLE"
    		oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"RUPING","DISABLE"
    	end if
        end if
        
    Next

    Wednesday, May 01, 2013 9:57 PM
  • You might consider using PSEXEC to execute the VBScript on a remote machine instead of adding it to GPO. 

    There are pros and cons of each.  PSEXEC requires the computer to be on at the time that you want to "fix" the remote computer.  On the other hand, if you put a GPO startup script to do this then it is going to run at every boot.  Adding a VBScript to Startup will add about 10 seconds (estimate pulled from thin air) to the boot process.  I would rather reach out to a machine once via PSExec than to make all machines run a GPO startup script at every boot.

    GPO is probably more reliable, but it does come at a cost of longer boot time. I wish there was a way to set a script to run once in GPO.  I don't think there is.

    Thursday, May 09, 2013 5:34 PM
  • Todd -- Thank you so much for the code and the suggestion about PSEXEC.  We experimented both ways, and the code worked across several hardware platforms.  We're inclined to use a GPO despite the startup delays, just because it will capture reimaged machines, machines with updated drivers, etc., but perhaps we'll just enable the GPO once/month or something. It is very nice to have an automated way to address this problem!
    Friday, May 10, 2013 11:16 PM