FreeRTOS+TCP DHCP or Static in runtime


Now i’m using FreeRTOS+TCP with ip static, but i need to switch DHCP or static in runtime.
How can i do this?

Have a look at ipconfigUSE_DHCP_HOOK to see if that meets your needs.

That’s the way to go! In each call-back you can decide to continue or fall back to using the static IP address.


I tried use like @rtel said, but i couldn’t work.
My steps:
First i used with configuration. All dhcpXXX variables with ‘’.

FreeRTOS_IPInit( dhcpIPAddress, dhcpNetMask, dhcpGatewayAddress, dhcpDNSServerAddress, ucMACAddress );

After in xApplicationDHCPHook i wait return a valid IP, but that is called once time and return eDHCPPhase as eDHCPPhasePreDiscover.

In my call back vApplicationIPNetworkEventHook i don’t start my task while my ip isn’t set up.

In my call back vApplicationIPNetworkEventHook i don’t start my task while my ip isn’t set up.

Let me see:

  1. Define your static values: you may retrieve them from a config, they may be the DHCP-settings that you used the last time the device was running. For instance:

    “”, “”, “” etc.

These are passed to FreeRTOS_IPInit().

  1. Enable ipconfigUSE_DHCP

  2. Enable ipconfigUSE_DHCP_HOOK and define the application hook. You have a choice of returning one of these value:

  eDHCPContinue,      /* Continue the DHCP process */
  eDHCPUseDefaults,   /* Stop DHCP and use the static defaults. */
  eDHCPStopNoChanges, /* Stop DHCP and continue with current settings. */

Here is an example of the hook that always returns eDHCPContinue:

eDHCPCallbackAnswer_t xApplicationDHCPHook( eDHCPCallbackPhase_t eDHCPPhase, uint32_t ulIPAddress )
eDHCPCallbackAnswer_t eAnswer = eDHCPContinue;

    const char *name = "Unknown";
    switch( eDHCPPhase )
    case eDHCPPhasePreDiscover:
            /* The library is about to look for a DHCP server. */
            name = "Discover";            /* Driver is about to send a DHCP discovery. */
//          eAnswer = eDHCPUseDefaults;
    case eDHCPPhasePreRequest:
            /* The DHCP server has made an offer to use `ulIPAddress` */
            name = "Request";            /* Driver is about to request DHCP an IP address. */
//          eAnswer = eDHCPUseDefaults;
    FreeRTOS_printf( ( "DHCP %s address %lxip\n", name, FreeRTOS_ntohl( ulIPAddress ) ) );
    return eAnswer;

Can you try this out and see if it works?

Only when the DHCP process is finished ( fail or success ), the network will go up:

    vApplicationIPNetworkEventHook( eNetworkUp );

and that is indeed a good place to create sockets and start tasks that use TCP/IP.

Hi @htibosch,

I done like you said. When i start my application the xApplicationDHCPHook is called, and for me return on phase eDHCPPhasePreDiscover and the IP returned is my static, passed to FreeRTOS_IPInit() .

i’d analyzed where is my problem, and i found my function #define ipconfigRAND32() uxRand() wasn’t seting up the initial value, so it was returning a value 0 when called in FreeRTOS_DHCP by prvInitialiseDHCP for get a socket to require the DHCP from server, so impossible to aquire the socket, but now i solved this problem.

Now my function xApplicationDHCPHook is called many times, but can’t aquire a IP. In function vDHCPProcess runed for many times on DHCPState as eWaitingOffer but can’t pass in if( prvProcessDHCPReplies( dhcpMESSAGE_TYPE_OFFER ) == pdPASS ), inside this function i saw the function FreeRTOS_recvfrom and this is returning the code FREERTOS_EWOULDBLOCK.

If I understand correctly, you are requesting an IP address via DHCP, but never receiving a reply (the reply being the DHCP offer). First can you please verify
that the DHCP request packet is going onto the network (you can do that by viewing the network traffic in Wireshark), and if so, whether or not you see a DHCP offer on the network in reply. If the DHCP request is on the network but you do not see a DHCP reply
on the network then please verify that the network has a working DHCP server.

Hi @rtel,

I’ll check if my board is sending the DHCP packet. But we have other products working with DHCP in our network, so i think the FreeRTOS+TCP can working.

Hi @rtel,

I done like you said, and i get on wireshark the discovery by the board and my router return the offer packet. But after this the board send again the discovery packet, and this repeats until ipconfigMAXIMUM_DISCOVER_TX_PERIOD.

I’ve not read the whole thread, so sorry if this is answered already, but are you receiving any data? If the packet is on the wire, but it is not being processed,
then we need to find where in the stack the packet is lost. It could be that just no packets are being received - which would point to a driver problem. Alternatively maybe the packet is being received but rejected for some reason (bad checksum for example).
Alternatively it could be that it is unable to allocate a nework buffer in the TCP/IP stack, etc.

If we start at the driver - outgoing packets are obviously working so the PHY configuration must be right, but have you seen packets being received before? For
example, if you set a static IP address and have ipconfigREPLY_TO_INCOMING_PINGS set to 1 in FreeRTOSIPConfig.h - are you able to ping your target board? [let me know if this has already been covered in the thread].

Sorry, yes my driver of Network is working, i was using with static IP communication with a web server. Getting ip with FreeRTOS_gethostbyname function success.
On wireshark the DHCP server reply the packet discovery from board with a offer packet.
I think the packet was rejected.

I’m analyzing the driver reception and i put a debug on interruption of RX, but when DHCP server reply the discovery, no happens any interruption. I saw the reply of server is sended for broadcast.

Now works, was the filter of driver ethernet. Was not enabled filter for broadcast.
Now i’ll try do work with dhcp and static whitout restart the board.


I saw this post using the function FreeRTOS_SetAddressConfiguration, i add the function FreeRTOS_NetworkDown before. So, after this, when i configure network i call this functions and the network up again with new configurations.