Hi Kevin, thanks for your reply. First of all, I have to apologize... I posted wrong screenshots. The bulbs really don't get a different mac adress, but the problem was indeed in the RE300. Whenever router restarted, they would assign an IP adress to all the smart things. Now, when I disabled the "auto" dhcp option on repeaters it seems to work well. Thanks for your assistance!

@1nfinity 

 

In case you're not already aware, you should know that the AX73/AX5400 is limited to a maximum of 64 DHCP IP reservations.  Although you're currently under that limit, it seems your smart home network relies on wifi devices, which in turn rely on fixed IP addresses.  If your needs grow in the future, you may encounter issues with the 64 reservation limit.

 

As such, you may want to consider migrating to a separate DHCP server outside of your AX73 router.  In other words, disable DHCP on the AX73 and stand up a separate DHCP service on your network.  The initial migration will be painful as you'll need to manually replicate every single reservation.  But it may save you from future grief (unless TP-link increases the limit or removes the limit altogether in a future firmware revision) .

 

If you do follow this route, then I should also warn you about another limitation regarding DNS.  Ignore the below if you are using your internet provider's DNS or any other public DNS.

 

If you have your own DNS however, you will need to also be aware that the AX73 does not play nice with external DHCP servers if the same IP hosting the DHCP server is also running DNS and you configure the AX73 to use that IP address for DNS.  Under such circumstances, the AX73 will misinterpet the other IP address as a duplicate gateway on the intended subnet and then reconfigure itself to a different IP subnet.  For example, if you attempt to set up the AX73 on 192.168.1.1 and a Pihole server with DHCP and DNS on 192.168.1.2, then you must not attempt to configure the AX73 to use DNS on 192.168.1.2.  It will work fine if you set up the AX73 to use any other DNS (obtain automatically from your ISP or manually configure to google DNS, cloudfare DNS, etc).  But the moment you attempt to configure the AX73 to use your own DNS on 192.168.1.2, it will treat that IP as a conflicting gateway on the 192.168.1.x network and reconfigure itself to be a gateway on a different network (e.g. 192.168.0.x).  You can configure all other devices on your network to use your private DNS (via the settings you assign in your DHCP server), but you just cannot configure the AX73 to use your private DNS.

 

Apologies for the long-winded rambling, but wanted to let you and others know in case this applies to your current or future environment.

@MikeS21 Hello Mike, thanks for adressing this. I'm quite aware of the limit which is the reason why I got my own RasPi server and quite a massive zigbee network by now relying on a USB stick in the raspi an the aqara M2 hub (since a lot of my stuff is Aqara).

 

Good thing you mentioned it! It might save someone a bit of a head-ache!

@1nfinity 

Indeed, this undocumented "feature" was a massive headache until I stumbled upon the root cause and workaround. 

 

@tplink 

To be fair, I understand the intention was probably to protect non-technical consumers from wreaking havoc on an existing network by having the AX73 check for a conflicting gateway.  But it's invalid to assume the presence of DHCP and DNS services on another host always indicates a duplicate gateway/subnet conflict.  Such a combination could legitimately exist via a local server, pi device, NAS, etc.

 

Ideally, a future firmware could provide a configuration option to disable this "auto-detection".  This would serve to: 

 

1. Inform users that this hidden behavior exists so such conflicts don't force users to spend hours investigating why the router keeps changing its subnet.
2. Allow users to override the auto-detection and configure their network via whatever DNS/DHCP configuration they prefer. 

 

To summarize, the issue only occurs when both DHCP and DNS are detected on a single, separate IP, but its impact is very severe (disables entire network).  As for the workaround, being forced to direct the router to use an alternate DNS prevents DNS queries made via the gateway from being routed to the private DNS.  This creates a gap in resolving internal hostnames, overriding lookups, blocking domains, etc.  So such a workaround isn't a fully functional, valid solution.

 

	AX73 DNS	Private DNS
AX73 DHCP	OK	OK
Private DHCP	OK	NOT OK

 

NOT OK = "To avoid IP conflict with the front-end device, your routers IP address has been changed to X.X.X.X"