# DHCP Never give up (FreeRTOS+TCP) **URL:** \ **Category:** Kernel\ **Created:** [September 25, 2019, 10:55am UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081 "2019-09-25T10:55:42Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [September 25, 2019, 10:55am UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/1 "2019-09-25T10:55:42Z")
**[plek324](https://sourceforge.net/u/plek324/)** wrote on [Wednesday, September 25, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/365d3f254a/#c1f2): 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. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [September 25, 2019, 1:27pm UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/2 "2019-09-25T13:27:05Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, September 25, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/365d3f254a/#c1f2/a8d3): 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). ---
**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\ **Post date:** [September 27, 2019, 7:10am UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/3 "2019-09-27T07:10:08Z")
**[heinbali01](https://sourceforge.net/u/heinbali01/)** wrote on [Friday, September 27, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/365d3f254a/#9a36): 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](https://github.com/aws/amazon-freertos/tree/hein/tcpipv6/libraries/freertos_plus/standard/freertos_plus_tcp_multi) ( 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 ---
**Author:** ![xrstokes](https://avatars.discourse-cdn.com/v4/letter/x/7ba0ec/32.png) [@xrstokes](https://forums.freertos.org/u/xrstokes)\ **Post date:** [July 27, 2020, 3:09am UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/4 "2020-07-27T03:09:23Z")
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 ---
**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\ **Post date:** [July 27, 2020, 1:41pm UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/5 "2020-07-27T13:41:43Z")
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: ```auto #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. ---
**Author:** ![xrstokes](https://avatars.discourse-cdn.com/v4/letter/x/7ba0ec/32.png) [@xrstokes](https://forums.freertos.org/u/xrstokes)\ **Post date:** [July 27, 2020, 11:37pm UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/6 "2020-07-27T23:37:58Z")
Thanks mate, I’ll move on with that. ---
**Author:** ![friesen](https://avatars.discourse-cdn.com/v4/letter/f/c57346/32.png) [@friesen](https://forums.freertos.org/u/friesen)\ **Post date:** [September 23, 2020, 12:37pm UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/7 "2020-09-23T12:37:38Z")
Where are the attached files? ---
**Author:** ![friesen](https://avatars.discourse-cdn.com/v4/letter/f/c57346/32.png) [@friesen](https://forums.freertos.org/u/friesen)\ **Post date:** [September 23, 2020, 12:42pm UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/8 "2020-09-23T12:42:40Z")
> [@htibosch](#): > > FreeRTOS\_NetworkDown() 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. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [September 24, 2020, 3:23am UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/9 "2020-09-24T03:23:07Z")
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). ---
**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\ **Post date:** [September 24, 2020, 8:45am UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/10 "2020-09-24T08:45:55Z")
> [@richard-damon](#): > > 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 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? ---
**Author:** ![friesen](https://avatars.discourse-cdn.com/v4/letter/f/c57346/32.png) [@friesen](https://forums.freertos.org/u/friesen)\ **Post date:** [September 24, 2020, 12:05pm UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/11 "2020-09-24T12:05:13Z")
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. ---
**Author:** ![friesen](https://avatars.discourse-cdn.com/v4/letter/f/c57346/32.png) [@friesen](https://forums.freertos.org/u/friesen)\ **Post date:** [September 24, 2020, 12:11pm UTC](https://forums.freertos.org/t/dhcp-never-give-up-freertos-tcp/8081/12 "2020-09-24T12:11:08Z")
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.