DHCP from an application perspectiveEdit

To enable DHCP, you must make sure to compile and link in DHCP. You can do this by defining the LWIP_DHCP option in lwipopts.h to 1, which also then adds a field to netif for a pointer to a dhcp struct. The dhcp struct will be allocated during dhcp_start(). In addition, LWIP_UDP must be non-zero, since DHCP is a protocol that runs on UDP.

On a simple setup, you will just call


after initializing your interface. Then, to correctly handle leases, DHCP has a couple timed functions that need to be called. However, since some time ago (1.4.0 ?), you only have to call a single function which will handle all timers for all protocols in the stack, so add this to your main loop or equivalent:


Then, you should check your interface for ->dhcp->state == DHCP_BOUND, then you are ready to go.

For LWIP 2.0 you need to call dhcp_supplied_address(const struct netif *netif) instead

If you would need to handle some drastic physical network changes like, for example, a mobile system that can be unplugged and plugged to a different network, you need to inform the DHCP functions of such a situation. This is normally done by the dhcp_network_changed() function. However, the stack takes care of informing not just DHCP but also AUTOIP and IGMP of link changes, so the right calls are:



You should tie these to your link state change detection for your interface.

If you want to get more involved, here you have more (and probably outdated) information:

To use DHCP on an interface, simply use the following commands:

  • dhcp_start() - start DHCP configuration for an interface.
  • dhcp_renew() - enforce early lease renewal (not needed normally)
  • dhcp_release() - release the DHCP lease, usually called before dhcp_stop()
  • dhcp_stop() - stop DHCP configuration for an interface
  • dhcp_inform() - inform server of our manual IP address

Note: These functions are lwIP core functions. They are not protected against concurrent access. In multithreaded environments, they may be called from the core thread only (aka. the tcpip-thread). When calling from other threads, use the netifapi_dhcp_*() functions defined in the api-module netifapi.c.

One option is to take advantage of the phy auto-negotiation. Most phys will generate an interrupt when the link status changes (a valid auto-negotiation has completed, or the cable has disconnected). Processing of the "phy link status changed" interrupt is passed to the tcpip thread (using, for example, tcpip_callback_with_block( HandlePhyInterrupt, NULL, 0) ). Then in HandlePhyInterrupt, if the link is up, make any necessary hardware register adjustments for the auto-negotiated speed, then call dhcp_start. If the link is down, first call netif_set_down( .. ). The other dhcp functions above may not be needed.

DHCP support history in lwIPEdit


External referencesEdit

  • RFC 1531 "Dynamic Host Configuration Protocol" October 1993, obsoleted by RFC 1541
  • RFC 1541 "Dynamic Host Configuration Protocol" October 1993, obsoleted by RFC 2131
  • RFC 2131 "Dynamic Host Configuration Protocol" March 1997, updated by RFC 3396
  • RFC 3396 "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)" November 2002

See alsoEdit

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.