[En-Nut-Discussion] DCHP issues

[Antonio Arena]

I have upgraded an Ethernut 2.1b project from Nut/OS 4.8.3 to 4.10.2
and noticed some DHCP behavior differences that I would like to get
guidance on.

The most obvious one is that instead of Discovery-Offer-Request-Ack,
I'm only seeing Discovery-Offer. I believe this is the result of
http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/pro/dhcpc.c?r1=2966&r2=2982
which Harald Kipp had already flagged in a thread from December 3rd,
2011, when he wrote:

> 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;
>}

My knowledge of DHCP is very limited, but this patch looks wrong
because it causes Ethernut to bind to the offered IP address without
sending a request:

  if (retries++ > MAX_DCHP_RETRIES) {
1644	 	                 if( dhcpConfig) {
1645	 	                     /* Ulrich says: we got at least one valid
offer from a DHCP server */
1646	 	                     reply = 0;
1647	 	                     leaseTime = aqsTime;
1648	 	                     dhcpState = DHCPST_BOUND;
1649	 	                 }

IMHO, this could cause the server to offer the same address to another
unit because the first Ethernut unit never explicitly requested it.

A smaller issue is with some of the debugging statements.

For example this one de-references dyncfg pointer which could be NULL:

1302	/*!
1303	 * \brief Check a new offer.
1304	 *
1305	 * \param dyncfg Current configuration, may be NULL.
1306	 * \param ip     DHCP server IP address.
1307	 * \param bp     DHCP offer message.
1308	 * \param len    DHCP message length.
1309	 *
1310	 * \return Updated configuration.
1311	 */
1312	static DYNCFG *CheckOffer(DYNCFG * dyncfg, BOOTP *bp, size_t len)
1313	{
1314	    DYNCFG *offer;
1315	
1316	#ifdef NUTDEBUG
1317	    if (__tcp_trf & NET_DBG_DHCP) fprintf(__tcp_trs, "\n[chkoffer
%s ", inet_ntoa( dyncfg->dyn_yiaddr));
1318	#endif

But the main issue that I have not figured out yet is why, about half
of the times, the first UDP packet (Discover or Request depending on
cdn_cip_addr) does not appear on the bus even though the debug
statements suggests that it was sent out (and then Ethernut times out
on receiving).

I realize UDP is unreliable by definition, but I only have a Linux
laptop connected by cross-over cable to the Ethernut and there is no
other traffic: I reboot the Ethernut and expect to see the packets on
tcpdump. But the first packet is often missing. I'm inclined to think
this is not a DHCP issue as much as a device driver issue (lanc111)
and somewhat triggered by something specific to my application.

But I have seen an old post from Paolo Simoncelli ("Slight problem
with UDP"), so I thought I would ask the mailing list before investing
more time debugging it.

Best regards,
Antonio