@Alta-Jeff
additional information.
The devices are on the same password
So that is confirmed. IP conflicts are on same VLAN and same password.
And the DHCP pool is more than big enough 230 available addresses and maximal 40 devices connected.
So that is confirmed. IP conflicts are on same VLAN and same password.
And the DHCP pool is more than big enough 230 available addresses and maximal 40 devices connected.
1 Like
There are more and more conflicts
and this is how it looks like in the device view.
Just for info
Just an idea. Are the disconnected devices always removable? I have had cases where the disconnected device is sort of pseudo-active, where I could not properly remove the device, with the trash bin button, as it re-appeared as a wired device. Though, the conflict disappears as the re-appeared device looses its IP. Though, not entirely sure this is always the case. If so, that may or may not be related to this issue.
@ebuckland81
The devices are all removable items such as PC, phones, IPTV boxes, printers and other items that will be turned off.
I had not the same issue as you have seen. If I press on the forget button the disconnected device disappears. If the device is operating again it gets a new IP address and no IP conflict (if not an other device is disconnected on that IP).
I have not seen them connected again on the wired network.
So there I have been lucky. But still the IP conflict is not real in my case because it is always towards disconnected wireless devices.
The good thing is that all connected devices are working fine even with the IP conflict message.
1 Like
Ah, good. 
I’ll PM.
I am sure this only started happening to me when I made the Route 10 “DHCP Guard = Auto” I have reverted to Disabled and will see what happens
1 Like
@Astina14 I got the invite, but haven’t seen the conflicting IP alert yet. It does look like you have a very short DHCP lease time of 10 minutes, which seems to trigger this issue much more quickly than the default lease time of 1 day, and would potentially cause real connectivity issues for being so short. Is there any reason you need the lease time to be so short?
For me the lease time made no difference. I tried to flush all the leases by setting it to 300. Then back to 3600. I think it may be due to the DHCP Guard = Auto as i did not see it until I enabled this parameter. Now running with this parameter disabled and lease time of 3600. I have no other device on my home network capable of replying to DHCP requests. So for me DHCP Guard setting is not critical.
1 Like
I get an IP conflict error also but my situation is a little different. This is for two Roku TVs on the same VLAN with VLAN isolation enabled. When they go to sleep, they both show a 172.24.243.225 address in the dashboard. This IP is not in any scope in my system. If isolation is not enabled they still show a 172.x.x.x adress but one may have 225 and the other will be 226 on the fourth octet. As soon as they are powered on for use they show the correct VLAN IP address and the conflict notice clears.
Correction. They are no longer getting a different IP if isolation is disabled. They will still get a 172.24.243.225 address. This must be their own IP scheme used for miracast connections or for the WiFi remote and these APs are just picking it up as a client address. These addresses will not respond to any connection attempts and are not in ARP.
1 Like
So, for whatever reason there is a dormant conflict, between an active or disconnected device and a disconnected device, it is still picked up as an active conflict and the warning is issued.
@Alta-Jeff, seems like the main bug here is found in how the conflict is identified, not what causes the dormant conflict, cause there seems to be various reasons for that. Neither are relevant as disconnected devices should not be considered for an IP conflict?!
@ebuckland81 We need to reproduce the issue easily enough to understand where the conflict is coming from, whether the source is FDB, ARP, or DHCP. For example, if a device is using an IP (even if it was assigned by DHCP), but that IP is still in the DHCP table for another MAC, it’s definitely something we should flag. So it’s unfortunately not a clear-cut issue from our perspective. If there is a natural, non-contrived method of reproducing, that would be helpful, but the issue seems very fleeting at best.
@don.mclean
Route 10 “DHCP Guard” where to find this parameter?
In the absent of the User Manual where all this is described I look forward to your guidance.
@Alta-Jeff
There is no specific reason for 10 minutes lease time except that I want to see if the dormant/disconnected devices disappear from UI faster. And conflicts now normally disappear after the lease time runs out. If I put it on 1 hour the conflict will be 1 hour at least.
But that has not really something to do with this issue, has it? Disconnected devices should be deleted from the DHCP table so other devices can use that IP address with no conflict.
I just thinking.
For me the DHCP table is like a hotel room. When you check out the room is available for others and there should not be conflict or even the old guests reservation that hold the reservation for a few days.
Am I wrong in that?
@Alta-Jeff
It is strange that you can not reproduce the IP conflict message.
I get it every day with 1 to 3 devices. So this is not any sporadic message that shows up sometime it is every day.
The good thing for me is that it looks like there is no disturbance in the connection. The device connected works good even with a IP conflict message presented in the UI.
I just noticed another oddity. Mine shows active for both devices vs active/inactive for everyone else. Why are these APs reporting these oddball IPs on these two Roku TVs when they go to sleep?
Its located Under Settings/system/Advanced.
Hopefully you have no other device that is performing a DHCP function.
I am also very disappointed with the lack of a User Manual.
@don.mclean
Thank you for the information.
I can confirm that there is only one DHCP server in the system and that is Route 10.
The DHCP Guard is disabled.
So we will see what the Alta team find out how to solve this issue because this issue with IP conflicts has been seen approximately 2 or 3 upgrades. There was non before and now I have conflicts at least every day.
I hope that the Alta Team will find the reason and solve it on a new upgrade.
1 Like
@Astina14, have you tried to force or remedy the conflicts in any way, like electrically turning on/off, reconnecting device in devices list, removing devices, unplugging and reattaching network cables?
I have found two rather similar ways to, repeatedly, force a conflict.
One is for a home cinema receiver which has a primary Ethernet connection and fallback WLAN connection. WLAN and LAN connections are set to DHCP with separate IPs, but when on WiFi, and re-attaching the network cable, a conflict emerges, though the WiFi is supposedly disconnected. The DHCP Guard setting didn’t matter for this case.
The other is for a LG TV, also with a WLAN and LAN connection, on Static IP. Where a cable is connected and the WLAN is then connected as a second connection. For a brief moment the device list shows the LAN connection on the same IP as the WLAN, but then settles on its own IP.
Neither seem to be similar in any way to your experience.
Other than that, I can’t seem to be able to force new conflicts, and it’s been kind of silent for the last two-three days now.
One thing I have noted for the earlier seemingly spontaneous conflicts is that the conflicts have always been located at the highest IP used in the range. However, that does not seem to be the case for you either, @Astina14.
@Alta-Jeff, there is certainly more to it. We’ll continue to keep our eyes open. Maybe the hypothesis that it is a false positive with one end always being a disconnected device could at least be one end to start digging from. At least it seems like a very common issue here. Not sure where to go from there though.
Edit: LG TV on Static IP and not DHCP.
1 Like
@ebuckland81
Are you able to confirm different MAC address for each of the interfaces on the device?
Wondering if the conflicts seem to be on IoT style devices (made at a price point), where they have the same MAC on both WLAN and Ethernet, on assumption both will never be used?