DHCP Never give up (FreeRTOS+TCP)

plek324 wrote on Wednesday, September 25, 2019:

Hi,
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.

rtel wrote on Wednesday, September 25, 2019:

Hi - thanks for this - I will talk with Hein to see how we can get this
built into the stack (if there is no current method).

heinbali01 wrote on Friday, September 27, 2019:

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.
Thanks, Hein

Is there a way to trigger DHCP to try again. I can deduct in a watcher thread that DHCP has failed and has been for some time. can i send a dhcp event or something and make it restart?

Thanks

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
	usage information:
	http://www.FreeRTOS.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCP_IP_Configuration.html#ipconfigUSE_DHCP_HOOK
	*/
    eDHCPCallbackAnswer_t xApplicationDHCPHook(
         eDHCPCallbackPhase_t eDHCPPhase,
         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.

Thanks mate, I’ll move on with that.

Where are the attached files?

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.

I think the idea is that if you are supposed to configure yourself with DCHP, then there isn’t much network activity that you COULD be doing (since you don’t have an assigned IP address).

I think so too. When doing DHCP, the sender address of your device is 0.0.0.0.

What you want is a possibility to ask DHCP for a IP-address, while you keep on using the existing static address for other purposes?

Essentially yes, I’d like the possibility to use the static address if the first go around fails. I’ll have to think about this.

The issue is that if the device is set to DHCP and is put on a non dhcp network, it basically takes some special mode to get it talking to the web ui.

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.