Detected conflict by ARP response - multiple IP addresses to the same MAC address

RouterOS General
1

Hi all, I have this problem on my home network where one device (Galaxy S23, android-dhcp-15) is not renewing its DHCP lease, instead it’s asking for a new address at seemingly random. It is the only device on the network with this behaviour.

The relevant network map is the following:

network map
network map1349×731 9.99 KB

All ports of the RB5009 (except eth1 which is WAN and eth2 which is for VOIP) are in one bridge.

The cAP ac and hAP ac2 are used exclusively as access points and are managed by CAPSMAN on the RB5009, their basic configs are identical (all interfaces in one bridge). Wireless devices may move from one AP to the other, the S23 is usually connected to the cAP ac.

I’ve read multiple threads on the forum and all point to proxy-arp which I don’t seem to have on my network; all the interfaces use the default arp=enabled and the Netgear switch has no options for ARP.

This is an extract from the logs:

logs
logs902×338 60.7 KB

I’ve captured some packets with packet sniffer:


Columns: TIME, INTERFACE, SRC-ADDRESS, DST-ADDRESS, IP-PROTOCOL, SIZE, CPU
 #  TIME        INTERFACE  SRC-ADDRESS                DST-ADDRESS                  IP-PROTOCOL  SIZE  CPU
 0  486.319     VLAN-lan   192.168.10.43:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    0
 1  486.321     VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.43:68 (bootpc)    udp           342    0
 2  1386.459    VLAN-lan   192.168.10.43:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    0
 3  1386.46     VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.43:68 (bootpc)    udp           342    1
 4  2286.526    VLAN-lan   192.168.10.43:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    0
 5  2286.527    VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.43:68 (bootpc)    udp           342    1
 6  3186.565    VLAN-lan   192.168.10.43:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    0
 7  3186.566    VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.43:68 (bootpc)    udp           342    0
 8  4086.61     VLAN-lan   192.168.10.43:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    0
 9  4086.612    VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.43:68 (bootpc)    udp           342    0
10  32848.217   VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
11  32849.237   VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
12  32849.741   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.42:68 (bootpc)    udp           342    3
13  32849.768   VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           358    0
14  32849.768   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.42:68 (bootpc)    udp           342    3
15  33749.926   VLAN-lan   192.168.10.42:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
16  33749.928   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.42:68 (bootpc)    udp           342    3
17  34651.128   VLAN-lan   192.168.10.42:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
18  34651.13    VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.42:68 (bootpc)    udp           342    3
19  35551.212   VLAN-lan   192.168.10.42:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
20  35551.213   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.42:68 (bootpc)    udp           342    0
21  36452.103   VLAN-lan   192.168.10.42:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
22  36452.105   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.42:68 (bootpc)    udp           342    0
23  83918.616   VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
24  83919.678   VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
25  83920.195   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.41:68 (bootpc)    udp           342    1
26  83920.225   VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           358    0
27  83920.226   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.41:68 (bootpc)    udp           342    1
28  84820.339   VLAN-lan   192.168.10.41:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    3
29  84820.34    VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.41:68 (bootpc)    udp           342    0
30  85720.419   VLAN-lan   192.168.10.41:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    3
31  85720.421   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.41:68 (bootpc)    udp           342    2
32  86620.507   VLAN-lan   192.168.10.41:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    3
33  86620.509   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.41:68 (bootpc)    udp           342    3
34  110199.563  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
35  110200.507  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
36  110201.011  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.40:68 (bootpc)    udp           342    0
37  110201.024  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           358    0
38  110201.025  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.40:68 (bootpc)    udp           342    0
39  111101.08   VLAN-lan   192.168.10.40:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    1
40  111101.082  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.40:68 (bootpc)    udp           342    0
41  117013.116  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
42  117014.126  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
43  117014.63   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.39:68 (bootpc)    udp           342    1
44  117014.646  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           358    0
45  117014.646  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.39:68 (bootpc)    udp           342    1
46  124497.177  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
47  124498.255  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
48  124498.768  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.38:68 (bootpc)    udp           342    3
49  124498.786  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           358    0
50  124498.786  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.38:68 (bootpc)    udp           342    3
51  125398.872  VLAN-lan   192.168.10.38:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    3
52  125398.873  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.38:68 (bootpc)    udp           342    3
53  126298.936  VLAN-lan   192.168.10.38:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    3

I see duplicates in the ARP table:

arp_table
arp_table868×257 34 KB

Wireless logs during a change of IP of the device, note that it has not roamed to the other AP, nor it changed frequency (cap-wifi2 is 5GHz):

wireless
wireless1024×117 22.2 KB

I do not know what the problem could be, do you have any ideas?

2

MAC address randomization ?

3

It’s the same MAC address for all entries. I have two other phones (Galaxy S9 and Galaxy A30s) that use MAC randomization and do not have this problem: they show their previously used MAC address to the Mikrotik and dhcp server hands out the IP address they already used. The Galaxy S9 for example has had 192.168.10.74 for months even if I disconnect it for days and it does not have a static reservation.

Forgot to add that all Mikrotik products are running ROS 7.20.6 (stable).

4

The S23 seems to be particularly subject to these issues, and your S9 and A30s behaviour confirms that It Is not a generic Samsung or Android incompatibility.

Most similar reports I could find revolve around MAC address randomization or
WPA3 settings, but It could be a number of other reasons, and though It could be originated by some settings on the Mikrotik side, It seems to me more probable that the problem Is in something on the Samsung side.

Only as an example, see:
https://www.phonerepair.co.uk/guides/samsung-galaxy-s23-wi-fi-keeps-disconnecting-expert-troubleshooting-repair-guide

5

You're actually hiding the most important stuff. In the logs where the dhcp server detects the conflict, are the mac addresses the same. Is it the mac (original or randomized) of the phone?

Anyway, just untick "conflict detection" on your dhcp server.

6

It is always the same randomized MAC address.

I’m pretty sure at this point it’s a device problem, but if I untick conflict detection, will I have more problems down the line?

7

If you want the flippant answer, having been in IT for a long time, yes, you will definitely have more problems down the line. :slight_smile:

On a more serious note. Your logs show that the device answers ARP for addresses that, at that point in time, it shouldn't. It's also a possibility that it's emitting spurious gratuitous ARPs. There's probably some weird bug in their software somewhere. What you see in your host table is only a result of this, not the cause.

The sort of "conflict detection" that Mikrotik does by default (essentially doing an ARP ping on the address before assigning it) is entirely optional, and in fact not many DHCP servers do it anymore. So this is not disabling any necessary/mandatory/recommended feature.

The proper fix would probably be for Samsung (or Google) to fix whatever the root cause around this is, but good luck with that. I have a faint suspicion that in fact this may be intentional, because randomized mac addresses are a bit of a subversion of established networking practices.

8

I see. Since it’s a default Mikrotik setting, I’d leave it as-is.

What if I give the phone a static IP? Dirty workaround but still a workaround perhaps?

9

I understand your issue. It’s an IT nightmare with cell phones using random mac addresses.

You’ll have to change somewhere in the Security and or privacy settings and disable random mac address or use static mac address. Something along those lines. It’s different with setting depending on the manufacture and os. But google the device and find where to make those changes. They make it sometimes hard to find! You may have an advance settiing for wifi and change it there.

All cell phones on my network use static mac addresses. It makes it impossable to do mac access control with random mac addresses. In example kid control ( should be called time access IMHO )

10

Either turning off mac randomization or giving the phone a static ip (but only if the static ip is set on the phone itself) has a high likelihood of helping.

Turning off arp conflict detection is actually a proper solution. Just because something is a default setting doesn't mean it's the only way, or even that it's the preferred one.

1 Like
11

It doesn't seem to be caused by MAC address randomization. As far as I can observe from the Android devices I have access to, turning that on gives the device different MAC addresses, but per SSID each device will have the same long term MAC address that doesn't change. As far as what concerns each SSID, the device has one unique SSID that stays unchanged for years.

Of all the devices in my networks, I can see the same warning message with a single device, that is my wife's Samsung Galaxy S25 Ultra. The message appears once every day when she comes back home and her phone joins the WiFi network. Her previous Samsung device, which was a Note 10+, never had the issue. The other Samsung device in the household is an older Galaxy Tab S7 FE that has also never caused the problem. But those two devices run/ran older Android (12 and 14) than the one that has the conflict (16).

A normal renewal (my DHCP lease time is very short, only 10 minutes) does not cause the router to broadcast the ARP for duplicate address detection, otherwise the warning would appear every 5 minutes when my wife's home. In this case the bug is clearly on the Samsung side (with newer Android versions), because it answers the ARP query for an address it doesn't currently own.

1 Like
12

Well, the OP log messages are also hours apart, the Mikrotik DHCP server (for whatever reasons, as said likely originated on the Samsung side) gives at each iteration a different IP, lowering by one each time:
.43-.42-.41-.40-.39-.38 in the log snippet posted.

But if the device works and all the issue is the log entries (and the polluted ARP table), one could ignore the log entries and periodically run a script to clkear the ARP, llike:

/ip/arp/remove [find where !complete]

see:
ARP entries building up

13

I knew I wasn’t crazy, the MAC, although randomized (i.e. does not return a vendor), is always the same.

How did you manage the problem?

My idea is to set whatever address it has now as static on the Mikrotik side but someone before said to set the static IP on the device itself which is not ideal.

Questionable, the user of the device lamented random hangs on loading websites that last only a few seconds which I assume is due to the change of IP address. Do note that it does not change IP after every lease expiration, so it’s a problem hard to debug. The logs and packet captures are hours apart because the device would happily renew the address for some time.

14

Yep, but what is in the logs you posted shows that between the detected conflict and the new assigned IP it takes 1-2 seconds, even amplified by the client reaction it can be what? 3 or 4 seconds.

And this happens with what frequency ? Two-three times per day?

I will however rephrase it as "if the device substantially works ..." :slightly_smiling_face:.

Anyway trying disabling conflict detection and see what happens cost nothing.

15

Yeah, the MAC address doesn't move (unlike iPhone). I use UniFi APs and the controller allows assigning icons/pictures to devices based on their MAC address:

image
image237×115 6.49 KB

That's why I know that the "random" MAC addresses stay the same even after years for each SSID. When a device changes its MAC address, I would notice it right away, because it reverts to a dummy icon.

The devices have different MAC addresses when connected to other SSIDs on the same access points.

I just ignore the problem, because it currently affects one device and normally only once per day, when my wife's phone returns home. So there is no network interruption due to IP address change. The phone doesn't seem to have issue with disconnection, and it also doesn't seem to need to issue new DHCP requests when roaming between the access points, so I don't see as many messages in the log as from your screenshot.

According to your screenshot, the device seems to lose connection to the APs every few hours? Is that due to roaming? Or did the device leave the location?

Edit: I just went ahead with your idea and assigned a static IP address to my wife's phone. Let's see what happens tomorrow when it rejoins the network.

16

Versions of android 11+ can set to non-persistent randomized mac through developer options as the default. But it will cause issues if you want mac addresses to be consistent on the same SSID.

https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior

This link has some useful troubleshooting tips (some Meraki specific) but has generally useful info, including info about IOS and Android. Also effects of mac randomization (one being Duplicate Client IP Address Reporting). I says this can happen when a device changes its randomized mac, but still remembers the previous ip address it got from dhcp. So when reconnecting, the phone has new mac, but dhcp requests the ip it previously had, but that ip is still leased to another mac address (the previous mac address used by the same phone).
https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Troubleshooting_and_Support/Troubleshooting/Meraki_and_MAC_Address_Randomization

This suggests that this can be set on a per network basis (per SSID?) so it may be possible to set globally to "non-persistent" (so stores can't see you as the same customer?) but then set it as persistent randomized (or device mac) for your home/work/other places that recognize your mac, so for those SSIDs the randomized mac will be consistent for the SSID (e.g. randomized once per SSID)

Disclaimer. I use the default which allows my phone to always show up on my network SSID with the same mac address (so reserved ip addresses work), but it is not using the "hardware" mac of the phone.

I don't know how you can see the mac address associtated with each SSID. Or if it is forgotten if you "forget" the SSID. It would also suggest that for example, McDonald's could track you between locations if you connect to "McDonald's Free Wi-Fi" SSID with persistent mac

17

I get that, but if the IP address changes when searching stuff on the web the content won’t load for those 4 seconds and the user did notice it.

No and no. I do not know if the device was turned off, if the user manually disconnected from the wifi or if there is a Samsung power saving mode that just disconnects the phone if there is no activity for X amount of time.

I’ll update you on what I find with setting a static IP. If that does not solve it I guess the only way is to disable conflict detection.

18

So, with this experiment, there was no "Detected conflict by ARP response" anymore in the log when my wife arrived home yesterday.

However, it might not apply to your setup. My VLANs have ARP mode set to reply-only, and the DHCP server instances have the add-arp=yes setting.

19

As a final update, setting a static IP to the device on the Mikrotik’s side solved the problem.

New packet capture:

 #  TIME       INTERFACE  SRC-ADDRESS                DST-ADDRESS                  IP-PROTOCOL  SIZE  CPU
 0  87.547     VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
 1  87.548     VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
 2  988.718    VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
 3  988.719    VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
 4  1888.788   VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
 5  1888.789   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
 6  2789.665   VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
 7  2789.665   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    1
 8  3690.65    VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
 9  3690.651   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
10  4591.666   VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
11  4591.667   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
12  5492.62    VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
13  5492.621   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
14  6393.607   VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
15  6393.607   VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
16  14276.897  VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           348    0
17  14276.899  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    3
18  14276.95   VLAN-lan   0.0.0.0:68 (bootpc)        255.255.255.255:67 (bootps)  udp           358    0
19  14276.951  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    3
20  15177.013  VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
21  15177.014  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    3
22  16078.491  VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
23  16078.492  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
24  16978.572  VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
25  16978.572  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    0
26  17878.643  VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
27  17878.644  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    2
28  18778.796  VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
29  18778.797  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    0
30  19678.909  VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
31  19678.909  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    3
32  20579.011  VLAN-lan   192.168.10.70:68 (bootpc)  192.168.10.1:67 (bootps)     udp           346    2
33  20579.011  VLAN-lan   192.168.10.1:67 (bootps)   192.168.10.70:68 (bootpc)    udp           342    0

And the logs:

1

There are no duplicates on the ARP table and as far as I know the user no longer experiences random loading hangs on websites.

Thanks all for the hints!