[En-Nut-Discussion] DHCP

[Ulrich Prinz]

Hi all,

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 the project was stopped - restarted -- stopped in a 14 day
frequency for some unbelievable political reasons. Big companies, you
know....
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.

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.
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
or detects some of the failing conditions.
The second lockup was, that the web server demo tried to do a
three-step solution. Try DHCP first, if it fails, take user programmed
data from network config of EEPROM and if that fails, use hardcoded
value #defined at the beginning of the code. But the demo messed
something up in the piorities. So with DHCP failing you cannot set up
network config and with missing network config it failed to select
hard coded defaults.

So there where some DHCP modifications needed:
1) correct behaviour on receiving multiple answers of multiple servers.
1a) Btw. the DHCP client should select the offer that matches most
closely to the previous offer he got.

2) Instead of blocking the caller, DHCP should be run as a thread from
the very beginning, not locking up at any time.
2a) A state request function should be installed that any other system
module can use to request current DHCP state.

3) DHCP must stay active as a thread cause the client has to request a
new lease or a renew of the current lease at several situations of
normal network conditions. Normal conditions are in that case the
timout of the lease time or the disconnect of the cable while
running...
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.

While writing this, I remember that I had a different bug in the TCP
stack that made a lot of trouble. Therefore the DHCP debugging printf
is somehow cryptic...
I had some multimedia systems running at home, sometimes flooding the
network with multicasts. In that situation the DHCP process failed and
the system locked up completely. Even using the system without DHCP
didn't work as the system died milliseconds after start, sometimes not
even the boot message made it completely through the uart.
Using DHCP and adding just some debug, slowing down the network setup
a bit, solved the problem completely...

Best regards
Ulrich


2013/5/8 Harald Kipp <harald.kipp at egnite.de>:
> Hi Joerg,
>
> On 15.04.2013 10:30, Joerg Wiegelmann wrote:
>
>> perhaps there is a DHCP Problem? After receiving an IP address from the
>> DHCP Server the DHCP Task is asking periodically if the IP Adress is
>> valid. If this fails the DHCP-Task goes to the IDLE state and stucks
>
> That doesn't look wrong to me. If the lease time expires, the client
> should stop all activity on that interface. However, the Nut/OS DHCP
> client will not stop the IP traffic, it will just stop it's own activity.
>
>
>> there. The workaround is to restart the DHCP-Task from the application.
>> The NutOS-Version is 4.10.2.1
>
> This is no work-around, but the intended procedure. An application
> should periodically call NutDhcpStatus(). It it returns DHCPST_IDLE,
> then the application needs to decide about any further action. It may,
> for example, configure a fixed IP address, shut down, inform the
> operator, or whatever. It may also decide to restart DHCP by calling
> DhcpKick().
>
> Regards,
>
> Harald
>
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion