DHCP IP Address Conflicts on Reboot
DHCP IP Address Conflicts on Reboot
I recently upgraded from an ER605 v2 to ER7206 v 2.26. I removed the ER605 and adopted the ER7206. Router is setup with a 192.168.1.1/24 (default) and 192.168.2.1/24 (IoT network) interfaces. DHCP assignments are 192.168.1.100 - 192.168.1.254 and 192.168.2.100 - 192.168.2.254, respectively.
On reboot, I am getting about 10 - 15 IP address conflicts: An IP conflict detected. Warning. Router client[MAC Address] client[Mac Address] used conflicted ip: 192.168.1.102.
I don't have a second DHCP server on my network. I wasn't getting these errors on the ER605.
Any ideas what's going on? Is it possible I didn't do the migration correctly? I know I had a few areas in my initial migration where the WAN port was defaulting to the SFP/WAN1 when my WAN port was actually WAN2. I updated the config and things seemed to work fine. Outside of that, the migration appeared to go smoothly without error.
Any help would be very apprecated!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
@CoffeeAndTech I believe I have solved the issue:
I installed an SFP RJ45 adapter and changed the WAN port from WAN2 to WAN1/SFP. I've rebooted twice and am not getting any errors. Fingers-crossed. I'll monitor over the next few days and post back if the errors start up again.
- Copy Link
- Report Inappropriate Content
After a lot of reasearch, I determined this was a result of a few smart TVs that were holding on to their IP leases and not requesting a new IP from the server even after their lease was up. No problem with the router or setup. I forced an IP renewal on these TVs and it solved the problem. Thank you for all your help!
- Copy Link
- Report Inappropriate Content
Thanks for posting in our business forum.
It could be a problem with the migration. If this only occurs after you migrate to the new router.
Delete the entry, IP-MAC binding, or reservation, and create it again.
WAN2 is the Ethernet WAN, it is not enabled by default. You need to manually turn it on. But that should not pose a problem.
- Copy Link
- Report Inappropriate Content
@Clive_A Thank you for the response! The issue is happening on the DHCP side of my IP range and not on my static-assigned addresses.
Clive_A wrote
Thanks for posting in our business forum.
It could be a problem with the migration. If this only occurs after you migrate to the new router.
Delete the entry, IP-MAC binding, or reservation, and create it again.
WAN2 is the Ethernet WAN, it is not enabled by default. You need to manually turn it on. But that should not pose a problem.
- Copy Link
- Report Inappropriate Content
@CoffeeAndTech I started looking at logs. Here is what the DHCP server is doing (read bottom up):
| TIME | CONTENT |
| 2025-02-18 07:31:45 AM | [gateway:MAC ID] client[MAC ID CLIENT 1] client[MAC ID CLIENT 2] client[MAC ID CLIENT 3] used conflicted ip: 192.168.1.107. |
| 2025-02-18 07:32:10 AM | DHCP Server allocated IP address 192.168.2.107 for the client[MAC: MAC ID CLIENT 4]. |
| 2025-02-18 07:32:06 AM | DHCP Server received DHCP Decline from client 192.168.1.107. IP address MAC ID CLIENT 2 is not available. |
| 2025-02-18 07:32:04 AM | DHCP Server allocated IP address 192.168.1.107 for the client[MAC: MAC ID CLIENT 2]. |
| 2025-02-18 07:32:02 AM | DHCP Server allocated IP address 192.168.1.107 for the client[MAC: MAC ID CLIENT 2]. |
| 2025-02-18 07:32:01 AM | DHCP Server allocated IP address 192.168.1.107 for the client[MAC: MAC ID CLIENT 2]. |
| 2025-02-18 07:32:01 AM | DHCP Server allocated IP address 192.168.2.107 for the client[MAC: MAC ID CLIENT 4]. |
| 2025-02-18 07:32:01 AM | DHCP Server allocated IP address 192.168.1.107 for the client[MAC: MAC ID CLIENT 2]. |
| 2025-02-18 07:31:56 AM | DHCP Server received DHCP Decline from client 192.168.1.107. IP address MAC ID CLIENT 1 is not available. |
| 2025-02-18 07:31:53 AM | DHCP Server allocated IP address 192.168.1.107 for the client[MAC: MAC ID CLIENT 1]. |
- Copy Link
- Report Inappropriate Content
In trying to sovle this issue, I set Legal DHCP = 192.168.1.1, rebooted, and I didn't see these errors. Rebooted a second time and they are back.
- Copy Link
- Report Inappropriate Content
@CoffeeAndTech I believe I have solved the issue:
I installed an SFP RJ45 adapter and changed the WAN port from WAN2 to WAN1/SFP. I've rebooted twice and am not getting any errors. Fingers-crossed. I'll monitor over the next few days and post back if the errors start up again.
- Copy Link
- Report Inappropriate Content
Thanks for posting in our business forum.
CoffeeAndTech wrote
In trying to sovle this issue, I set Legal DHCP = 192.168.1.1, rebooted, and I didn't see these errors. Rebooted a second time and they are back.
That's strange. Legal DHCP is only used when there is an illegal server. Your original post stated that you ruled out that the second DHCP server existed.
For the accuracy in troubleshooting, you can use the Wireshark to find out what might be wrong.
So far, I suspect there is a DHCP server in your network without your acknowledge or awareness. You might double-check. Some devices may support DHCP but you are not aware of it. That could cause problem like that.
- Copy Link
- Report Inappropriate Content
Thank you for responding! I turned on Legal DHCP to rule out a second DHCP server. As I mentioned, it seemed to solve the problem for 1 reboot but then the problem returned.
I've used NMAP to rule out if I have a second DHCP server on my network and it returned the following:
sudo nmap --script broadcast-dhcp-discover -e eth0
[sudo] password for XXXXX:
Starting Nmap 7.94SVN at 2025-02-19 01:10 UTC
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 1:
| Interface: eth0
| IP Offered: 192.168.1.103
| DHCP Message Type: DHCPOFFER
| Server Identifier: 192.168.1.1
| IP Address Lease Time: 7d00h00m00s
| Renewal Time Value: 3d12h00m00s
| Rebinding Time Value: 6d03h00m00s
| Subnet Mask: 255.255.255.0
| Broadcast Address: 192.168.1.255
| Router: 192.168.1.1
| Domain Name: lan
|_ Domain Name Server: 8.8.8.8, 8.8.4.4
Based on my logs I posted earlier today, it appears that the DHCP server on the TP-Link router is handing out the same IP address to two different MAC IDs. Seems like an error to me.
- Copy Link
- Report Inappropriate Content
Thanks for posting in our business forum.
CoffeeAndTech wrote
Thank you for responding! I turned on Legal DHCP to rule out a second DHCP server. As I mentioned, it seemed to solve the problem for 1 reboot but then the problem returned.
I've used NMAP to rule out if I have a second DHCP server on my network and it returned the following:
sudo nmap --script broadcast-dhcp-discover -e eth0
[sudo] password for XXXXX:
Starting Nmap 7.94SVN at 2025-02-19 01:10 UTC
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 1:
| Interface: eth0
| IP Offered: 192.168.1.103
| DHCP Message Type: DHCPOFFER
| Server Identifier: 192.168.1.1
| IP Address Lease Time: 7d00h00m00s
| Renewal Time Value: 3d12h00m00s
| Rebinding Time Value: 6d03h00m00s
| Subnet Mask: 255.255.255.0
| Broadcast Address: 192.168.1.255
| Router: 192.168.1.1
| Domain Name: lan
|_ Domain Name Server: 8.8.8.8, 8.8.4.4
Based on my logs I posted earlier today, it appears that the DHCP server on the TP-Link router is handing out the same IP address to two different MAC IDs. Seems like an error to me.
What is the device you use? What devices face this problem?
Does it happen to the phones?
Your lease time is set to be 7 days?
Since the last few years I have been testing with Omada, I have not faced a problem like this.
- Copy Link
- Report Inappropriate Content
These warnings are coming wireless devices. Here are two examples:
1) Conflict between a Macbook Air (connected to EAP_1) and an iPad (connected to EAP_2)
2) Conflict between an iPhone (connected to EAP_3) and an unknown MAC ID (suspect an iPhone) (connected to EAP_2).
What is interesting is that they are on different TP-Link EAPs (EAP650s).
I tried setting my lease to 2 hours and then also to 7 days. Either option didn't seem to make an impact on the problem.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 231
Replies: 13
Voters 0
No one has voted for it yet.