Yes, any sort of conflict will cause problems and likely generate some system log dnsmasq error messages. See my post here where I show some example error messages when there is a conflict:When I was experimenting with dnsmasq-x.conf.add (one of the approaches mentioned above) I did have a conflict whereby it didn’t work until I deleted the duplicate values in GNP manually assigned IPs first [see EDIT 3].
If this conflict logic applies equally to any pair of the three methods dnsmasq/GNP Manual/YazDHCP, wondering if there’s some legacy assignment entries anywhere (including in /jffs/nvram/dhcp-list which might be holding yours up? Just a thought.
https://www.snbforums.com/threads/y...of-dhcp-reservations.94827/page-4#post-971519
It cannot be stressed enough that one cannot just update to YazDHCP 1.2.0 and walk away expecting things to work without carefully either reading the YazDHCP CLI carefully to understand the changes and how conflicts can happen. Or not read both of Martinski posts on the v1.2.0 release. People need to pay particular attention to the Notes section in the second post link below.
https://www.snbforums.com/threads/y...of-dhcp-reservations.94827/page-4#post-971788
https://www.snbforums.com/threads/y...of-dhcp-reservations.94827/page-4#post-971789
Also, it's very important to make sure you remove all IP address reservations from your custom files that have been transferred to YazDHCP to prevent dnsmasq from getting duplicate entries/directives, which is bound to cause some issues when restarting the dnsmasq process.