Behaviour of the DHCP Client

Libraries
1

Hi,

I’ve noticed that in FreeRTOS+TCP V2.4.0 (and also older versions) the DHCP client acts weird in some situations. General setup:

  1. DHCP Server on network (has relatively low lease time of 30 minutes).

  2. Enable DHCP on DUT (STM32H7 target) and connect successfully

  3. Remove the link

  4. Wait until the lease expired (15 minutes) and the DHCP process timed out

After these steps the DHCP process will assign a default network config. Upon reconnecting the link, the stack does not try to reach the remote DHCP server, and uses the previously assigned parameters instead.
Here are the respective logs, which the stack produced:

LVL_INFO xPhyCheckLinkStatus() L763: xPhyCheckLinkStatus: PHY LS now 00
... wait some time ...
LVL_DBG prvSendDHCPRequest() L1139: vDHCPProcess: reply a002086ip
LVL_DBG prvSendDHCPRequest() L1139: vDHCPProcess: reply a002086ip
LVL_DBG prvSendDHCPRequest() L1139: vDHCPProcess: reply a002086ip
LVL_DBG prvSendDHCPRequest() L1139: vDHCPProcess: reply a002086ip
LVL_DBG prvSendDHCPRequest() L1139: vDHCPProcess: reply a002086ip
LVL_DBG prvInitialiseDHCP() L679: DHCP handler start after 250 ticks
LVL_INFO xApplicationDHCPHook() L623: DHCP started
LVL_DBG prvSendDHCPDiscover() L1187: vDHCPProcess: discover
LVL_DBG prvSendDHCPDiscover() L1187: vDHCPProcess: discover
LVL_DBG vDHCPProcess() L369: vDHCPProcess: timeout 10000 ticks
LVL_DBG prvSendDHCPDiscover() L1187: vDHCPProcess: discover
LVL_DBG vDHCPProcess() L369: vDHCPProcess: timeout 20000 ticks
LVL_DBG prvSendDHCPDiscover() L1187: vDHCPProcess: discover
LVL_DBG vDHCPProcess() L369: vDHCPProcess: timeout 40000 ticks
LVL_DBG prvSendDHCPDiscover() L1187: vDHCPProcess: discover
LVL_DBG vDHCPProcess() L369: vDHCPProcess: timeout 80000 ticks
LVL_DBG vDHCPProcess() L386: vDHCPProcess: giving up 160000 > 120000 ticks
... default adressing assigned from now on ...

I found a forum thread, where someone encountered similar problems. However the issue here was, that a link is established, but no remote server is active until a certain point: DHCP Never give up (FreeRTOS+TCP)

I think it should be differentiated between these two situations, where DHCP is enabled:

  • We have a link but can’t reach the server → apply defaults (and poll for DHCP?)

  • We have no link → maintain the current config and hope we can apply it later on

Are there additional configurations for the stack or are these features not yet implemented?

Thanks for your help!

2

Hello @Dweb_2,

Interesting. Yes, I think that the distinction should be made. Maybe every time there is a change in link status (from low to high), we should start the DHCP process. What do you think?

To that end, maybe we can add the below lines here: NetworkInterface.c

vDHCPProcess( pdTRUE, eInitialWait );

Of course this is not the correct way. But it would give us an idea whether this would work. Correct way maybe to send an event (a new type) to the IP task so that it can restart DHCP phase.

3

Actually, as far as I know, the standards behavior in almost all network stack implementations is to mark the interface as “down” at link down time and up and link up time. That should implicitly trigger a new DHCP discover sequence. It is also important for other reasons such as coherent maintenance of routing tables for multiple interface targets.

4

Thanks @RAc and @kanherea for the infos!
@kanherea, your solution seems to work.