Phil
When I simulate with the recording I don't have any problem but I do see that your DHCP client is not sending the correct source address in the request.
Compare the normal DHCP discovery request compared with the one that your board is doing (attached image). You will see that normally the discovery is sent as a broadcast (which yours is doing) but with a 0.0.0.0 source address. I believe that versions pre-2013 may have done this if the user didn't clear the IP address before starting the DHCP server. If using an old version do the following before calling:
uMemset(&network.ucOurIP[0], 0, IPV4_LENGTH);
This is a violation of the specification but not a reason for it to not work - also in the recording the server does accept it.
In both cases there is an offer received - it is offering you the address 192.168.1.160 - but your board is ignoring it. It looks like it is not accepting broadcast receptions, although this would only be possible if it were expressly disabled - which is very unlikely.
Check therefore whether the DHCP client's UDP call back is being reached:
static int fnDHCPListener(USOCKET SocketNr, unsigned char ucEvent, unsigned char *ucIP, unsigned short usPortNr, unsigned char *data, unsigned short usLength)
If it is, step though the code to see whether any checks cause it to be rejected. I did the same in the simulator and all was accepted so didn't see what it could be.
Finally check the DHCP version in the latest release against yours to verify that there are no changes that may be of importance. Apart from some new options I don't in fact find anything critical.
Regards
Mark