1. DHCP client broadcasts a DHCP Discover message. The message contains a Requested-IP (50) field which contains an IP which apparently has been previously offered by the server and accepted by the client.

2. The DHCP server broadcasts a NACK message with the client's MAC address as Client-ID (61), with the message "Lease expired for request message".

At this point the DHCP protocol already seems to be broken by the server as a NACK message only seems to be appropriate following a DHCP Request message. The server's NACK message is apparently being sent as a response to the client's Discover message, but this doesn't seem to follow the DHCP protocol as specified in RFC2131. The client is only sending Discover and no other DHCP message types. 

The client, which justifiably disregards the inappropriate NACK message, again broadcasts a Discover message containing the same Requested-IP as in step 1. Server responds as in step 2. Repeats ad infinitum. Client never receives an offer and hence never completes the DHCP protocol execution.

This seems to be a server bug. RFC2131 shows Discover - Offer - Request - ACK|NACK, as a valid protocol execution path. The DHCP server on this TP-Link switch seems to believe Discover - NACK is a valid protocol execution path, which RFC2131 doesn't seem to support. 

The correct behavior would be that the server makes an Offer, which may or may not contain the Requested-IP in the client's Discover message, that's up to the server. From then on the client could continue with a Request to which the server can ACK or NACK. Basically, the server shouldn't change protocol behavior because a client sent a Requested-IP along in its Discover message. 

Discover != Request