My bad .. There are too many devices on market. 1st world problems
But the issue is the same.
Keep in mind, you are assigning a random MAC for the same hostname. I don't know how the DHCP implementation of D-Link handle this, if the hostname is important here.
The DHCP is defined in RFC2131: RFC 2131 - Dynamic Host Configuration Protocol
At first contact, the client asks a DHCPDISCOVER with its own MAC per broadcast (MAC FF:FF:FF:FF:FF:FF) to UDP port 67 at the interface. The DHCP server answers with a DHCPOFFER, to tell the client which IP is free and the LEASETIME, how long this offer will be valid. The client will choose the offer with a DHCPREQUEST. The DHCP server could answer with a DHCPACK (okay) or a DHCPNACK (not okay).
After the lease is over, the client will ask the server a DHCPREQUEST, if he could play a little longer with the IP.
The server will store this information in the lease 'database' (or file).
Some DHCP Server are also using the hostname, that is optional transmitted in the request (see optional parameter in RFC 2132).
Most of the time we are only seeing 'Client connects to Wifi, Client gets IP (optional Gateway) and we can see cat videos', because the process is so fast, that more then one DHCP will lead to raced condition.
Most of the time you will connect a client to the Wifi, and get wrong data ... In case of an mobile phone it will down rate this Wifi (as 'no Internet available, using other Wifi or mobile data') and search for a new connection. In other cases, the client will get an IP, but no or the wring Gateway without routing ...
Long story short: Make sure you've got only one DHCP server in your network. Except you know exactly what you are doing. But in this case I wouldn't write this text.
One easy way to get on the ground of this issue is a little hand work.
At first you need a client, which is already in the LAN. Wireless or wired should not matter.
Take a look at Wireshark · Download ... could install it at windows, but in my experience it performs better at Linux.
Choose your network card. For example wifi0 or wlan0 or at a Microsoft Surface mlan0, and click 'start capture' ... Wow, this are a lot of packages.
Click with the right mouse button at the row 'protocol' and choose 'use as filter -> selected' ... At the top row the filter will appear, for example: _ws.col.protocol == "TCP"
. Change TCP to DHCP ...
When your Beryl will connect to the WLAN, it will ask the DHCP Server for an address. And you should be able to see the dialoge above.
Most likely you need administrator privilege at your system to switch the network card in promiscuous mode (which means something like: capture all packages, don't drop packages for another MAC).
Using a hub is much better, because also a switch won't route the packages to your interface ... But you will get at least the broadcasts, maybe not the DHCP(N)ACK.
I am pretty sure you will see the request is send and the D-Link will take quite a time to answer. And a workaround could be to remove the lease from the dhcp entry in the configuration at the D-Link. But we can tell more, if we definetly know this is what happens there.
Or wait 4 to 7 days and I could take a look at the local logs at the Beryl, how the steps are processed there. I am on the road right now.