Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

XP sending DHCP release on 'wrong' interface

Hello all,

I have a PC that is connected to a LAN network. When i turn on WIFI, it gets an DHCP address on the wifi interface also (different subnet). No problems.

Then when i shutdown wifi, i see that my PC is sending a "DHCP Release" message for the WIFI IP address on my LAN interface ?

This release message generates a "%DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL: DHCP_SNOOPING drop message because the chaddr doesn't match source mac, message type: DHCPRELEASE"

error message on our switches.

OS is Windows XP professional (i guess SP3)

Is this normal behaviour ?

And the question is: what is the best behaviour ? drop the release message (even if it is on the 'wrong' interface). This will keep the lease going until expiration in the DHCP server, or allow this message and properly remove the DHCP binding for the wifi side from the database......




XP sending DHCP release on 'wrong' interface

The release message is a unicast. It cannot be sent over wlan because this is no longer available. This is why windows has to send it over the LAN. There is no harm in simply passing the message on to the dhcp server.

On the other hand, probably it is not a huge problem either when the lease is not returned directly.

This means you are likely to receive the same ip address when re-activating wifi.

The only issue I can foresee is when the dhcp range for wifi becomes overbooked due to the leases not being released in time. You can also work around this problem by reducing the lease time.




XP sending DHCP release on 'wrong' interface

RFC 2131 clearly states:

3.6 Use of DHCP in clients with multiple interfaces

   A client with multiple network interfaces must use DHCP through each
   interface independently to obtain configuration information
   parameters for those separate interfaces.

So for me , a PC should never send any DHCP packet (offer, request, release) on other interfaces as the one for which it is mentioned. If an interface is unexpectatly shutdown, you can't send a release any more. This is just how it works. Sending the release anyway on any other interface that still might be active, is non-RFC2131 behaviour and might trigger error messages like the one i mentioned above. The behaviour does not work very well with DHCP snooping feature. Of course, i can always disable source mac adress verification with "no ip dhcp snooping verify  mac-address", but it will lower security.

I wonder if Windows 7 behaves the same



CreatePlease to create content