A problem with dhcp on embedded device that we encountered is that for instance after a power outage they boot faster than the dhcp server. This means the FreeRTOS device will fail to get a dynamic IP, and fall back on a static IP. After that it will never request an IP again.
For us this is not desired. It may takes minutes, hours or even days, but once the DHCP server is back, we want our device to get a proper IP address.
To get this done I made a few small modifications to FreeRTOS_DHCP.c. See the modified file attached. dhcpRETRY_AFTER_FAILURE_PERIOD can be set to a value in milli seconds after which the device will try again to request an IP. The static IP will be used in the meantime.
Another way is to set dhcpNEVER_GIVEUP to 1. In that case the device will also keep trying to get an IP, but without falling back to a static IP.
Maybe there is a better way to get this kind of behaviour, but I couldn’t find it. If so I surely would like to know.
And for anyone interested in what I did, see the attached file.
Peter, thanks for this idea and for the modifications. I will see if there is a current method, and / or whether your changes integrate well. In the IPv6 release ( under development), we face the same problem, and I’d like a similar solution in both branches.
I will come back to this.
I think that FreeRTOS_NetworkDown() is what you are looking for, It will reset and restart the DHCP-negotiation.
In case you haven’t done it, it may be useful to define:
#if( ipconfigUSE_DHCP_HOOK != 0 )
/* Prototype of the hook (or callback) function that must be provided by the
application if ipconfigUSE_DHCP_HOOK is set to 1. See the following URL for
uint32_t ulIPAddress );
#endif /* ( ipconfigUSE_DHCP_HOOK != 0 ) */
This user-provided application hook will be called at essential moments in the DHCP negotiation and lets you decide what to do.
Won’t this method interfere with network activity on a continual basis until DHCP is a success? A more robust method could rather be built into the DHCP source. I’d suggest perhaps that if eAnswer is returned as something like eDHCPRetry that it would queue a timer to rety after some pre set period.
About DHCP though, typically a DHCP client doesn’t just roll over and die and use a fallback IP. I still suggest a bit more robust scheme, or more mainstream way to go about this. I think the scenario mentioned above about the router boot time is real, and in my mind opinion the place to deal with it is the TCP stack, rather than user code.