[En-Nut-Discussion] DHCP

Harald Kipp harald.kipp at egnite.de
Fri Dec 2 15:12:50 CET 2011

Hi Michael,

On 02.12.2011 00:26, Michael Hellwig wrote:
> In earlier tests I already increased NUT_THREAD_DHCPSTACK to 512, but it 
> didn't help. Though I have a little relief now, because our network guys 

I made a few more tests and got strange results like endless loops etc. In the end it turned out that almost all of them vanished, after I changed




for the ARM platform. (I'm testing on the EIR.)

Then I applied


not one to one, but in the same way.

Next I checked the trunk for more patches, where


seems to be the most significant. This was a real challenge, because the patch also contains a mixture of valid and invalid cosmetic changes and additional debug output handling. It took me a while to figure out the relevant things and I hope I got it right.

I also found


and got the same problem here. But this went away after increasing the stack. Michael Jones criticized the weird code and tried to understand how it works. Same here. Although I'm the author of a major part, I'm not able to follow this funny stuff anymore. What a hack is this?!

Anyway, I committed my result to the 4.8 branch


May be you can give it a try? Renewals seem to work here again.

In general I'm not convinced that this will fix all issues. For example we have now

/* Change to REQUESTING state if we got a valid offer.
   Otherwise we stay in SELECTING state. */
else if (dhcpConfig) {
    /* Wait for at least one period for other DHCP servers to offer */
    retries = MAX_DCHP_RETRIES + 1;

but I cannot figure out, how this will put the client into SELECTING state again. It may be a left-over comment, but the original version did that

/* Change to REQUESTING state if we got a valid offer.
   Otherwise we stay in SELECTING state. */
else if (dhcpConfig) {
    retries = 0;
    dhcpState = DHCPST_REQUESTING;

I agree with Michael Jones' view. Although the code cries for a complete rewrite, we better try to understand how it works first and then carefully patch it step by step.

> made an exception for the ethernuts, it would be cool to have dhcp 
> working. Next I will setup an own dhcp-server with a short lease-time 
> for testing and see if the problem persists.

This is not really required. Instead, you can override the option values from the server, e.g.

/* Renewal time. */
else if (*op == DHCPOPT_RENEWALTIME) {
    cfgp->dyn_renewalTime = ntohl(lval);
    cfgp->dyn_renewalTime = 60;
/* Rebinding time. */
else if (*op == DHCPOPT_REBINDTIME) {
    cfgp->dyn_rebindTime = ntohl(lval);
    cfgp->dyn_rebindTime = 120;
/* Total lease time granted. */
else if (*op == DHCPOPT_LEASETIME) {
    cfgp->dyn_leaseTime = ntohl(lval);
    cfgp->dyn_leaseTime = 180;



More information about the En-Nut-Discussion mailing list