[En-Nut-Discussion] DHCP Issues

[Coleman Brumley]

Harald,

Thank you for the reply. I noticed that the later versions of dhcpc.c use a
larger stack space, but only if NUT_THREAD_DHCPSTACK is not previously
defined. Perhaps that's the issue, I'm inadvertently using a smaller stack
space for the value of NUT_THREAD_DHCPSTACK.

Thanks for trying the DHCP test on your network, I hadn't thought of
overriding the renewal time like this. I will do so on my end and see if
it's OK. 

Yesterday, after sending my original email, I rebooted both the Nut/OS based
controller AND my DHCP server and they started working as expected. I feel
that one of the culprits was that another programmer overrode the original
MIN_DHCP_WAIT to something too short (2000 instead of 4000) for my network.
I changed this back to 4000 and the DHCP handshake is working except for the
occasional DHCP_NAK from my DHCP server. There appears to be no fallback
mechanism in place yet to deal with this in dhcpc.c. Even going back to the
INIT state doesn't seem to correct this scenario. I've not been able to
determine the cause of the DHCP_NAK. It only shows up periodically. 

> Quite unlikely, because almost any DHCP server will send options not known
> to our DHCP client.

Please note that is wasn't something sent from my DHCP server. It was sent
from another DHCP client on my network via the local broadcast
(255.255.255.255) address. 

The issue I saw with the crashing was, indeed, due to an overflow but I'm
pretty sure it was caused by the errant DHCP message whose extensions
included text data.

Coleman


> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Tuesday, February 17, 2015 10:35 AM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] DHCP Issues
> 
> Hi Coleman,
> 
> On 16.02.2015 18:25, Coleman Brumley wrote:
> 
> > (NutDhcpClient) isn't automatically issuing a renew based on the
> > renewal period issued by my DHCP server.
> 
> I'm unable to reproduce the problem. Here is what I did:
> 
> Change "#if 0" to "#if 1" to enable local debugging.
> 
>   #if 1
>   /* Use for local debugging. */
>   ...
>   #endif
> 
> Override renewal time (I do not want to change our office DHCP):
> 
>   cfgp->dyn_renewalTime = ntohl(lval);
>   cfgp->dyn_renewalTime = 60;
> 
> Each minute I get the following on stdout:
> 
> [1.DHCP-BOUND 60]
> [1.DHCP-RENEWING 60][DHCP-Send to 192.168.1.1][DHCP-Recv from
> 192.168.1.1][DHCP-Opt-53][DHCP-Opt
> -1][DHCP-Opt-3][DHCP-Opt-6][DHCP-Opt-12][DHCP-Opt-15][DHCP-Opt-
> 28][DHCP-Opt-38]
> [DHCP-Opt-51][DHCP-Opt-54][DHCP-Opt-58][DHCP-Opt-59]
> [2.DHCP-BOUND 0]
> 
> So, renewal takes place as expected.
> 
> 
> > On another note, the DHCP ParseReply seems to be crashing when it
> > receives options that it doesn't know how to parse (options 249, and
> > 252 for example). This is occurring when Microsoft machines are
> > broadcasting DHCP INFORM requests.
> 
> Quite unlikely, because almost any DHCP server will send options not known
> to our DHCP client.
> 
> To
> 
>   /* Total lease time granted. */
>   else if (*op == DHCPOPT_LEASETIME) {
>     cfgp->dyn_leaseTime = ntohl(lval);
>   }
> 
> I appended
> 
>   else {
>     printf("Unknown %u(%u)\n", *op, ol);
>   }
> 
> which results in
> 
>   Unknown 38(4)
> 
> without crashing.
> 
> Not exactly your environment, but I can hardly imagine that this won't
work
> elsewhere. What I assume is, that you are running out of stack space.
Among
> other things, this depends on compiler versions.
> 
> See the software manual
> 
> http://www.ethernut.de/pdf/enswm28e.pdf
> 
> on page 46ff as well as
> 
> http://lists.egnite.de/pipermail/en-nut-discussion/2009-April/024939.html
> 
> Please let us know, if this solved your problem.
> 
> Regards,
> 
> Harald
> 
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion