ulrich.prinz at googlemail.com
Mon Apr 29 15:46:16 CEST 2013
Not to fast please, I am still there...
even from a different company ;)
When I took the DHCP code, it wasn't working in larger company
enviroments as it got stuck if the first network reply wasn't the
expected DHCP one. At that time we connected AT91SAM7 based boards to
class A networks with at least 2 local and 3 remote DHCP servers and
roughly around 2000 systems in the network.
After my changes, which where mostly to extend some delays that where
requested by the corresponding RFC and the acceptance for multiple
replies of multiple DHCP servers, the systems worked perfectly in the
When I pushed the changes to the repository, I got some remarks about
style and debug code left inside, but I did not get any comments about
not working DHCP.
Unfortunately the project that required the changes was stopped and I
was set to another project that made me porting STM32 but it is based
on CAN and makes no use of any ethernet.
And then there was a problem, that we never commited to of how to fix
it. DHCP may fail. All our examples since 5 years ago describe that
Nut/OS will fall back to fixed ip address but it never did. The dhcp
request call inherits one or two situations where it can simply
reaturn dead and the ongoing code can only guess what might have
happened. I porposed to split the initializer and the status requestor
so a system can initiate DHCP and then can stay and work while waiting
for the status to change to something that is useable.
My basic intention for that solution was, that I connected a nice OLED
display to EIR and considered it boring that the display hangs until
an IP address is assigned.
So that DHCP is broken at all is something new to me and I cannot
imagine why it should be broken. Only option is that it was not
2013/4/29 Harald Kipp <harald.kipp at egnite.de>:
> Hello 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
>> there. The workaround is to restart the DHCP-Task from the application.
> while checking the mailing list history, there had been a significant
> change almost 3 years ago by Ulrich Prinz. This change had been
> criticized by a few people (including me) and Ulrich promised to look
> into this and that his colleague was already working on an update. Other
> contributors provided patches, which never made it into the trunk or any
> As we haven't heard anything from Ulrich for some time now, I assume
> that we will never see anything and that DHCP is obviously broken. No
> one else seems to feel responsible. So, as the original author of the
> DHCP implementation (better call it a hack) I will take over the task
> trying to fix this. I already have done some work, but I'm also quite
> busy on other projects right now. Anyway, you can expect something
> within a week.
More information about the En-Nut-Discussion