[En-Nut-Discussion] DHCP

[Harald Kipp]

Hi Ulrich,

On 08.05.2013 15:17, Ulrich Prinz wrote:
> I checked the code in the meanwhile. Harald, you're right. The final
> code never made it into the repository. But there are some different
> codes on my harddrive that I have to sort out first. The problem was

That explains a lot. I removed the related changes and tried to fix all
known errors. Please check the current trunk. There will be a fix for
4.10 and 5.1 later.

> For the analysis of the behaviour and the alignment to the appropriate
> RCF a lot of debug was added. But the debug was locally controllable
> so it didn't affect the compile process or blow up the code for normal
> users.

I generally recommend to remove all debug messages, which are not
essential for a basic function check. Depending on the specific bug you
are currently looking for, you need specific debug output and don't want
the output of a previous bug hunting. For this reason, some other
projects demand to remove _all_ debug output before committing
code...yeah well, there are pros and cons.


> The original behaviour of the web-server demo using DHCP was a double
> bug thing. First the DHCP could reach several states that he never
> came out again. The lockup states could be reached by sending
> different DHCP offers from different DHCP servers to the DHCP client
> or by sending unknown serives packets that lock up the TCP stack.

Not exactly. In fact there were the following problems:

#1 DHCP reaches IDLE too early or starts sending a lot of requests or
becomes blocked by very long timeouts. All this was caused by a wrong
calculation of timeouts.

#2 The REBINDING was handled incorrectly. The code was simply copied
from RENEW.

Note, that both problems will never appear in the initial configuration.
Only the renewal failed.


> The root cause of the problem could be (sorry but it is over 2 years
> since I was in that code) that the dhcp process is doing most of the
> work as a function and only after getting valid data it 'forks' as a
> thread. So it locks up the calling process until it gets a valid offer

Much more than 2 years, Ulrich. In fact, DHCP is completely handled in a
thread.


> So there where some DHCP modifications needed:
> 1) correct behaviour on receiving multiple answers of multiple servers.

On busy networks there is another problem. In order to allow UDP (note
UDP, not TCP) with minimal buffer space, any incoming packet replaces a
previously received packet. It is likely to lose more packets, the
slower the application reads, or the more packets (broadcasts etc.) are
received.

For historical reasons UDP buffers must be explicitly configured, using

 uint16_t max_ms = MAX_DHCP_BUFSIZE;
 NutUdpSetSockOpt(sock, SO_RCVBUF, &max_ms, sizeof(max_ms));

This is done in the DHCP client, but on large networks with sufficient
RAM, the default of 1728 bytes may be increased.


> 1a) Btw. the DHCP client should select the offer that matches most
> closely to the previous offer he got.

The local CheckOffer() does this already.


> 2a) A state request function should be installed that any other system
> module can use to request current DHCP state.

Use NutDhcpStatus().


> 3a) There should be a link between DHCP status and other network
> services as if the lease was renewed with a different IP address (
> some networks do not allow renewal with the same address multiple
> times) all server sessions have to be closed and or restarted.

That's why NutDhcpStatus() had been implemented many years ago.

I tested renewal and rebinding with the current trunk on AVR and it
seems to work as intended.

Regards,

Harald