Wireless: %DTL-1-ARP_POISON_DETECTED

CSCsm25943 Change label for %DTL-1-ARP_POISON_DETECTED message
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsm25943

Symptom:

A Wireless LAN Controller may emit a message similar to the following:

DTL-1-ARP_POISON_DETECTED: STA [00:01:02:0e:54:c4, 0.0.0.0] ARP (op 1) received with invalid SPA 192.168.1.152/TPA 192.168.0.206

However, when one peruses the entry in the Cisco Wireless LAN Controller System Message Guide, 4.2, for this message, he may find it to be misleading and bereft of useful information.

Conditions:

This message does not necessarily imply that any actual "ARP poisoning" (ARP spoofing) is going on. Rather, it is emitted whenever the following conditions pertain:

- WLAN is configured with DHCP Required
- A client, after associating on that WLAN, transmits an ARP message without first DHCPing

This may be normal behavior - for example, when the client is statically addressed, or when the client is holding a valid DHCP lease from a prior association.

The effect of this condition is that the client will be unable to send or receive any data traffic, until it DHCPs thru the WLC.

In more detail, here is how to interpret the example message above:

DTL-1-ARP_POISON_DETECTED: STA [00:01:02:0e:54:c4, 0.0.0.0] ARP (op 1) received with invalid SPA 192.168.1.152/TPA 192.168.0.206

DTL-1-ARP_POISON_DETECTED
- WLC received an ARP packet from a client in DHCP_REQ state

STA [00:01:02:0e:54:c4, 0.0.0.0]
- the client ("STA" - 802.11 wireless station) has a MAC address of 00:01:02:0e:54:c4, and an IP address unknown to the WLC ("0.0.0.0")

ARP (op 1)
- the offending packet received from client was an ARP request (opcode 1)

invalid SPA 192.168.1.152/TPA 192.168.0.206
- the source IP address (SPA - "sender protocol address") of the ARP request was 192.168.1.152
- the target IP address (TPA - "target protocol address") of the ARP request was 192.168.0.206

Workaround:

1. figure out whether or not you want to force your wireless clients to DHCP first, after associating, before they can send IP packets.



2. If no, then unconfigure DHCP required, and you won't get this problem.



3. If yes, then configure all clients to use DHCP.



4. If the client is configured for DHCP, but still sometimes sends IP packets after associating without re-DHCPing, then:
   
   
   • See if the client eventually does re-DHCP & if so doesn't suffer an unacceptable outage before re-DHCPing. If the outage before re-DHCPing is acceptable, then you can just ignore this message.
   
   
   
   • If the client never does re-DHCP after associating, then it will never be able to pass L3 traffic. So in that case, either figure out how to change the client's behavior so that it always does re-DHCP after associating, or else just accept that this client won't work in this application, or else reconsider your decision to use "DHCP required".

Further Problem Description:

If the source IP address (SPA) of the ARP is an APIPA address (i.e. one in 169.254.0.0 /16), then this may be indicative of the STA's attempting but failing to acquire an address via DHCP. In which case you may want to verify that your DHCP implementation works.

1st Found-In:
4.2(61.0)

Fixed-In:
7.0(63.0)