Re: [lwip-users] Strategy Question for DHCP

[Zach Smith]

Use the auto ip feature of lwip which I believe is the proper way to handle this situation. With this feature enabled, after a certain number of dhcp timeouts the device will fail over to an “auto ip” address. The auto ip address is an address the device chooses for itself in the range 169.254.x.x. It will perform a quick check to see if any other device out there has the address. If so, it chooses another one and checks again. Upon finding a free address it self-configures with that address. dhcp discover messages continue to go out at some defined interval and if a dhcp server ever responds then the assigned address overwrites the previously assigned auto ip address.

 

Check out autoip.c (it does all this for you) and the following defines:

 

#define LWIP_AUTOIP                                              1  

#define LWIP_DHCP_AUTOIP_COOP                  1 //defines auto ip to work with dhcp

#define LWIP_DHCP_AUTOIP_COOP_TRIES    6 // controls how many dhcp discovers to try before timing out to an auto ip address

#define LWIP_AUTOIP_CREATE_SEED_ADDR     //lets you control the first auto ip address the device will try

 

From: lwip-users-bounces+address@hidden [mailto:lwip-users-bounces+address@hidden On Behalf Of Robert Deschambault
Sent: Thursday, May 14, 2015 11:18 AM
To: Mailing list for lwIP users
Subject: [lwip-users] Strategy Question for DHCP

 

I would like to know what is a good approach when developing an application for an embedded device that has it's IP address assigned by DHCP.  We only have the Ethernet link and a circuit breaker for power, no other reset buttons are available.

 

We currently wait for a number of DHCP timeouts and if we don't get configured, we failover to a static IP address.  The only way to get DHCP to assign an IP address after this is to drop the link.  The other problem is that all the devices failover to the same static IP address and we can have up to 12 devices on a managed switch.

 

Is that a good approach?  What if DHCP services appear later after the DHCP timeouts have occurred?  Can we detect something that could tell us to renegotiate the link without dropping the link?

 

Thanks,

Bob

 

--

Bob Deschambault

---

Confidentiality Notice: This e-mail may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive from the recipient), please contact the sender by reply e-mail and delete all copies of the message.