IssueTracker

Speculation: Perhaps the Android does what Cisco calls "gratuitous arp" when the WiFi hotspot is enabled (on a Cisco, this is a feature that allows misconfigured machines - no default gateway - to reach the Internet)? Perhaps this feature is activated (by mistake) even when not in hotspot mode?

Just a thought...

Note that the "gratuitous arp" should be considered very obsolete - at least in my mind.

CORRECTION: The Cisco feature in question is "proxy arp". The "gratuitous arp" feature is something completely different. My bad.

Note to other victims of this problem: The MAC address of the offender is not mentioned in the IP Address conflict message itself, but you can find it in the corresponding Event Log entry (in the System log).

We have the exact same problem in our office... Now that we have a large number of android phones in the office it is bringing down our key servers on a regular basis.

We have to run 'arp -a' to find the mac of the offending device. Then switch wifi on and off on that phone to fix the problem.

Workarounds I think think of are:
1) Moving our servers to the opposite end of available host addresses ( i.e. from 1 and up to 255 and down )
2) Mandating each android user change their home wifi network subnet / host to something that won't conflict with the office network.

It would be good to get some acknowledgement from google that the problem can be replicated and ideally schedule a fix into a later firmware.

Perhaps you are experiencing issue 36903750 or #3 described in
http://code.google.com/p/android/issues/detail?id=11236

Check DHCP server logs to see if the Android device was leased
the IP address in the past.  You'll know it's issue 36903750 if the
Android device attempts to RENEW or INIT-REBOOT for the
stolen IP address (even though your DHCP server refuses to grant
the requested lease).   Take note that issue 36903752 can arise
days, weeks, even months after the original lease expired.

Yes Irwin that is exactly what we are experiencing. We have a number of Samsung Galaxy S II running 2.3.3 that all suffer from this problem.

Btw, you did an excellent job diagnosing the problem. I hope google/vendors will be able to release a fix soon!

Same problem.
Issue resolved by moving all Android phones to different AP/subnet.

We had similar problems on our network. A samsung galaxy II phone was grabbing low numbered ip addresses of our servers, rendering them unusable until we took the samsung off the network

[Comment deleted]

(edit) Also ran into this on a network I support. It took us days to figure out what was breaking our company email, but we traced it back to a Samsung Droid that was somehow associating itself with the Exchange server's IP address. Checking the ARP table on several machines revealed that the Droid's MAC was tied to what was suppossed to be the Exchange Server's IP address. The solution was blocking the phone's MAC address with a MAC filter on the WAPs.

We also have confirmed this same issue with a Samsung Galaxy phone - please fix.

You may want to add that to the original bug report:
http://code.google.com/p/android/issues/detail?id=11236

I'm not sure it's the same bug. The address conflicts in this report are on addresses that aren't in the DHCP scope and have never been assigned to the phone.

The conflicts we saw (haven't tested recently) were for example server addresses - it seemed more like the phone answered to ARP and ICMP to any address in the network, thus disrupting even server operations. A lot worse than just keeping old DHCP addresses.

Jentlemen, is there a workaround yet? Looks like this bug still persists even for android 4.1

I have found no workarounds and am very interested if more of you are experiencing this problem. I have this problem more with iPhones, though I do get it occasionally with androids too.

I'd love to know how we can prevent this if anyone has any ideas, aside from possibly moving our entire subnet.  

We have one iPhone that does it and one Android device (HTC) - they both get listed on the arp cache as 192.168.0.3 (which happens to be the IP for our primary domain controller and since it serves up printers, causes printing problems for everyone).  Incidentally that server is Windows 2003 and is also the DHCP server.  

When you look at the IP address on the affected device however, it always has a different IP in the correct range that it got from the DHCP server.  Basically it's like it maybe had an IP of .0.3 in the user's home, joins our network, spits out a gratuitous ARP broadcast saying "I'm on 192.168.0.3 over here" and then picks up the correct IP address from DHCP but doesn't then rebroadcast the correct ARP.  I'm currently waiting with Wireshark for it to happen again to verify.

Since it only affects mobiles I'm wondering if it might be related to this in some way:
http://cafbit.com/entry/rapid_dhcp_or_how_do
But wouldn't know how to turn it off.

We too see this issue. This time with stock HTC Sensation and also ASUS Eee Pad Transformer TF101.
To move round this problem I will setup another subnet with WiFi just for these mobile devices.

We also see this issue quite often, and the symptoms we experience are IP address conflicts with our router interface addresses.  We have investigated dozens of these incidents, and every time it has turned out to be a HTC Android device causing the ARP table problems.  Here is another example from a few minutes ago:

759: Jan 22 10:20:16.829: %IP-4-DUPADDR: Duplicate address 10.138.4.1 on GigabitEthernet0/0.8, sourced by 1887.96xx.xxxx

18:87:96

Htc Corporation
No. 23, Xinghua Rd.,
Taoyuan City 330
Taiwan, Republic Of China

You may want to add that to the original bug report:
http://code.google.com/p/android/issues/detail?id=11236

This is a VERY different issue than 11236. They MAY be related in some round-about sort of way, but this bug has NOTHING with DHCP to do (as it seems).

THIS bug report is about Android devices claiming (possibly through ARP responses) addresses that are not (and never were) in any DHCP scope (also, the network in question was fairly unique - not 192.168.1 etc). Thus disrupting other network services (clients start using the Androids MAC address for server IP addresses etc).

Issue 36903752 in http://code.google.com/p/android/issues/detail?id=11236 can cause the behavior you are describing.  

Possibly that issue is due to a problem with the use of ARP Offload.  It causes the device to resume claiming (via ARP) an IP address the device was using in the past, even on a different network.  In my environment, I could verify that some of the IP address were ones which had been leased via DHCP to the device in the past (old expired leases) by my own DHCP server.   I don't know if it can also affect IP addresses the device obtained in the past via a mechanism other than DHCP.  

If the bug is due to the DHCP client failing to inform ARP Offload to remove the IP address from ARP Offload, then I suppose the bug is in the DHCP client.  If the bug is not due to the DHCP client failing to inform ARP Offload, then I suppose the bug is elsewhere (outside the DHCP client).  

But take note that Google believes they've fixed all of this in 11236.  (I've continued to see devices malfunction in this way.)

Happened again this morning and I managed to capture it, Wireshark text export attached.  In this case the conflict went away after a moment.

I don't see DHCP OFFERs in the log, I think because I was running the capture on my machine, non promiscuous, so can only see the chatter over Broadcast and directly to mine.

My interpretation of the log (not an expert, and excluding the ipv6 entries and LLC) is:
- Requests 192.168.0.3 via a DHCP REQUEST (frame 6696)
- Declares via ARP REPLY to Broadcast (but non gratuitous?) that it's on 192.168.0.3, which is picked up as a duplicate (frame 6951)
- (Irrelevant) My machine attempts to continue an ongoing RDP session I had with the server on 192.168.0.3, mistakenly sending the packets to the HTC device (frames 6953-6981)
- A repeat request for 192.168.0.3 is sent (frame 7086)
- Finds it can't have that IP and so sends a DHCP DISCOVER (frame 7554)
- Learns it can have 192.168.0.113 and sends a DHCP REQUEST for 192.168.0.113 (frame 7557)
- Sends GRATUITOUS ARP REQUEST for 192.168.0.113 (frame 7998)
- ARP asks who's really on 192.168.0.3 (frame 8185)
- ARP asks who's on gateway IP 192.168.0.8 (frame 8326)
- Sends another DHCP REQUEST for 192.168.0.113 (frame 16177)
- Verifies that 192.168.0.113 is available via ARP requests (frames 16196-27258)
- Sends another GRATUITOUS ARP REQUEST for 192.168.0.113 (frame 27757)
- ARP checks 192.168.0.3 again (frame 27797)
- ARP checks 192.168.0.8 again (frame 27863)
- Continually broadcasts ARP REPLY to default gateway 192.168.0.8 declaring that it has IP address 192.168.0.113 (frames 28798 onwards, indefinitely)

192.168.0.113 is a valid IP that it gets from DHCP.

I'm not really sure what this proves, if anything, just that it declares 192.168.0.3 over ARP (which it surely shouldn't do) in the middle of its DHCP negotiation where it learns that it's not actually available.  In this case it only happened once and so only caused one IP conflict message to pop up on the server, but other times in the past it's continued to conflict.

I've been debugging what looks like a very similar (if only very repeatable) problem here.

I'm using a HTC Desire HD (ace) phone, and with the stock firmware I haven't noticed any ARP problems. Also ICS based ROM's (4.0.4 tested) appear to be OK, or at least have less frequent problems.

However, I've tried 4 different JellyBean (4.1.2/4.2) ROMs (cfx, JellyTime, AOKP and CM10.1 based) and they all have the same problem:

When my phone goes to sleep, it sends out an ARP message claiming to be owning one of a series of IP addresses every 15.1 seconds. I've looked at the wireshark dump in #21, and have seen the very same time delta between the bogus ARP messages being sent there (multiples of 15.1 seconds between the ARP messages), so I figure there might be a connection between "my" problem and the ones above!

The IP addresses appear to be from roughly the same list of around 150 IP messages, some of which appear a bit "odd".

However, this set of IPs are only used when on one AP here on the network. When the phone is moved to another AP in my network, it sends out bogus ARP messages with the IP address 0.0.0.0 instead, every 15.1 seconds!

I've also seen a few cases of truncated ARP messages where only the first 28 bytes (IIRC) are included.

I can reproduce the problem here, and have multiple pcap's saved that shows the problem. It happens EVERY TIME the phone goes to sleep with WiFi enabled.

I've also tried to do a pcap with the help of tcpdump on the device in question. It does NOT capture the bogus ARP messages being sent, so it must somehow happen below the capture layer.

I can upload/mail pcaps to anyone interested in helping to debug this issue and/or do further experiments with this.

At first, I had assumed this could have been caused by some of the "adaptation" to legacy drivers used on the ace JB versions, but the problem looks very much like the ones reported here, so I guess it might as well be caused by the AOSP base code, possibly introduced somewhere between ICS and JB (but I cannot say for sure -- just that on ICS it is at least very infrequent compared to JB).

I can confirm that behaviour on Desire HD with custom Jelly Bean ROMs. However it happens only on network with ZyXEL ZyWALL 5 router. On my second network running on D-Link IR-025 with OpenWrt firmware is not affected by bogus ARP queries.

Thanks for confirming, DanP...@gmail.com! Very interesting to hear your response. Might try OpenWrt on one of my APs too.

I've got a ZyXEL here on my network as my secondary router, but it is not wirelessly connected in any way, and does not appear to be sending any traffic to the phone -- but I'll test what happens if it is removed.

The Wireless AP's I have here are a Netgear CG3000 (which causes the bogus IP addresses) and a LinkSys WRT320N (that causes the IP 0.0.0.0 to be sent). Both with stock FW.

[Comment deleted]

I can confirm that I am seeing this issue on my HTC MyTouch 4G, running android 4.1.2. The issue only happens when my phone goes to sleep, with the screen on the issue vanishes. I can toggle it on and off by allowing my phone to go to sleep and then waking it back up.

I am experiencing same issue on my HTC Raider since its ROM upgraded from CM7(ICS4.0.3) to CM10(JB4.1.2). Two Windows XP PCs report the "IP address conflicts with phone's MAC" in event log at same time, but another Windows 7 PC in the same LAN does't have any error log.  No problem reports if the phone's WIFI was turned off.

I attempted to 1.change router DHCP setting to bind IP address with PC's MAC addresses; 2.change phone's WIFI setting to static IP; both didn't work and the issue still exists

I am attaching a promiscuous-mode pcap of one of the IP conflict incidents occurring today.  I have the pcap filtered for only the offending MAC address (HTC device).  Here is a text breakdown:

- LLC protocol chatter
- DHCP Discover
- DHCP Request (HTC device requests 10.186.12.237)
- ARP (Who has 10.186.8.1 Tell 25.0.49.191)  - who has subnet gateway, tell some IP address in a RIPE block? (no idea why this address)
- ARP (Who has 10.186.8.1 Tell 10.186.12.237) - who has subnet gateway, tell DHCP IP for HTC device (ok, that looks correct)
- ARP (0.0.0.0 is at HTC device) - wtf?
- ARP (10.186.10.101 is at HTC device) - possibly a previously-leased IP
- ARP (10.186.13.92 is at HTC device) - possibly a previous-leased IP (conflict flagged)
- ARP (10.186.4.1 is at HTC device)  - outside DHCP scope, router subinterface IP conflict flagged)
- ARP (212.196.229.190 is at HTC device) - wtf?  (another RIPE block address)
- ARP (33.112.168.177 is at HTC device) - wtf?   (this is a DoD block address)
- ARP (4.2.0.0 is at HTC device) - wtf? (address at Level-3, no way valid)
- ARP (212.196.229.190 is at HTC device) - wtf?  (duplice RIPE block address)
- ARP (10.186.13.240 is at HTC device) - possibly a previously-leased IP (conflict flagged)

Is there any hope of this behavior being patched?  Maybe if the FTC and ACLU lawsuits against mobile carriers force them to patch their faulty devices:

http://www.ftc.gov/opa/2013/02/htc.shtm
http://yro.slashdot.org/story/13/04/17/185217/aclu-asks-ftc-to-force-carriers-to-patch-or-replace-android-devices

Would a developer from Google care to comment on this issue?  We see this occur daily on our network, and our current recourse is to ban the offending HTC Android device from our wireless network.  Thank you for looking into this.

I want to add my information to this ticket from my new issue "58842"...

//-------------------------------------//

The last 14 bytes of an ARP reply are not included in the frame sent over the network.  This results in a frame size of 28 bytes instead of 42 bytes.

"Sender IP address", "Target MAC address", and "Target IP address" are missing from all reply packets.

This is possibly due to code within line 107 and 127:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/net/arp/ArpPeer.java

//-------------------------------------//

OS: Android 4.2.2 - AOKP and Cyanogenmod 10.1 are affected
Device: HTC EVO3D

No.     Time           TCP.Time_Delta Source                Destination           Protocol Calc'd Win Size Host      
  81455 3.194429000                   Htc_12:34:56          Broadcast             ARP                                 [Malformed Packet]

Frame 81455: 28 bytes on wire (224 bits), 28 bytes captured (224 bits) on interface 0
Ethernet II, Src: Htc_12:34:56 (d8:b3:77:12:34:56), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
[Malformed Packet: ARP/RARP]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Message: Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

0000   ff ff ff ff ff ff d8 b3 77 12 34 56 08 06 00 01
0010   08 00 06 04 00 02 d8 b3 77 12 34 56

//-------------------------//

A valid reply would be:

0000   ff ff ff ff ff ff d8 b3 77 12 34 56 08 06 00 01
0010   08 00 06 04 00 02 d8 b3 77 12 34 56 0a 00 00 a4
0020   ff ff ff ff ff ff 0a 00 00 01

has anyone seen this on a non-HTC device? i.e. is there some reason to believe that this is a bug in AOSP rather than buggy HTC kernels?

I see the same issue, having the phone getting an IP but responding to arp for another one with a Samsung Galaxy S2

xxx:~$ arping -I eth2 192.168.1.11
WARNING: interface is ignored: Operation not permitted
ARPING 192.168.1.11 from 192.168.1.145 eth2
Unicast reply from 192.168.1.11 [00:00:74:xx]  0.827ms
Unicast reply from 192.168.1.11 [14:7D:C5:xx]  114.064ms
Unicast reply from 192.168.1.11 [14:7D:C5:xx]  36.036ms

00:00:74:... is the network printer (correct)
14:7D:C5:... is the Samsung Galaxy S2

We find only one case; thus, we just asked the user to disable / enable wifi when arriving to the office, which seems to solve the problem.

I get arpwatch mails with reports related to GSM/3G IPs. So apparently something causes the phone to send out arps about its 3G ip on the Wifi interface. My phone is a Galaxy S3 GT-I9300 running 4.1.2. Luckily my provider issues official IPs so there is no IP conflict on my network caused by the phone. But if the provider issues RFC1918 addresses one could see conflicts as reported by others.

Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO.