[En-Nut-Discussion] Bug in dhcpc.c

[Harald Kipp]

Peter,

I can confirm both. You discovered a bug and provided a good
solution. I'll apply it to the CVS.

There may be better solutions, but why make the fix better than
this hacked DHCP client. :-)

Many thanks,
Harald

At 16:41 29.06.2006 +0200, you wrote:
>Hi,
>
>I believe that I have found a bug in module dhcpc.c porting the ethernut 
>network stack to our proprietary AVR platform.
>
>In method DhcpKick(), global variable dhcpApiTimeout is set to the timeout 
>value specified by the application or main task. It is never reset to an 
>infinite value, even after DhcpKick() has returned. I suppose that the 
>thread NutDhcpClient is intended to run independently, sleeping most of 
>the time and renewing or rebinding as necessary. However, in the beginning 
>of the thread loop, where the comment "Keep track of the API timeout" 
>stands, dhcpState will be set to DHCPST_IDLE, as soon as the loop starts 
>over again. This happens after the first nap in state DHCPST_BOUND has 
>ended! Thus DHCP will never be able to renew or rebind its lease. I solved 
>this issue by resetting dhcpApiTimeout to infinite when DHCPST_BOUND is 
>entered...
>
>        /*
>         * Maintain lease time.
>         */
>        else if (dhcpState == DHCPST_BOUND) {
>            ucRetryCnt = 0;
>            os_set_event( &evDhcpDone );
>            // API timeout no longer needed. Let DHCP work unattended.
>            dhcpApiTimeout = OS_NOTIMEOUT;