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: [email protected] 
[mailto:[email protected]] 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.
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to