[En-Nut-Discussion] DHCP

[Ulrich Prinz]

Hi,

Am 02.12.2011 15:12, schrieb Harald Kipp:
> Hi Michael,
> 
> On 02.12.2011 00:26, Michael Hellwig wrote:
>> In earlier tests I already increased NUT_THREAD_DHCPSTACK to 512,
>> but it didn't help. Though I have a little relief now, because our
>> network guys
> 
> I made a few more tests and got strange results like endless loops
> etc. In the end it turned out that almost all of them vanished, after
> I changed
> 
> #define NUT_THREAD_DHCPSTACK    384
> 
> to
> 
> #define NUT_THREAD_DHCPSTACK    512
> 
> for the ARM platform. (I'm testing on the EIR.)
> 
> Then I applied
> 
> http://lists.egnite.de/pipermail/en-nut-discussion/2009-March/010484.html
>
>  not one to one, but in the same way.
> 
> Next I checked the trunk for more patches, where
> 
> http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/pro/dhcpc.c?r1=2966&r2=2982
>
>  seems to be the most significant. This was a real challenge, because
> the patch also contains a mixture of valid and invalid cosmetic
> changes and additional debug output handling. It took me a while to
> figure out the relevant things and I hope I got it right.

Harald, could you please give me some hints via PM what you mean with
"invalid changes". Cause without looking at that patch I am pretty sure
it was my one. I added 'some' debug to DHCP to check if all needed
options are booked and 'why the hack' the DHCP crashes the stack
completely if there is a streaming server running in the neighborhood.
The non ANSI-C style debug was needed to be able to switch it off simply
by not wasting any additional byte.

> 
> I also found
> 
> http://lists.egnite.de/pipermail/en-nut-discussion/2009-November/011392.html
>
>  and got the same problem here. But this went away after increasing
> the stack. Michael Jones criticized the weird code and tried to
> understand how it works. Same here. Although I'm the author of a
> major part, I'm not able to follow this funny stuff anymore. What a
> hack is this?!
> 
> Anyway, I committed my result to the 4.8 branch
> 
> http://ethernut.svn.sourceforge.net/viewvc/ethernut/branches/nut-4_8-branch/pro/dhcpc.c?revision=3677&view=markup
>
>  May be you can give it a try? Renewals seem to work here again.
> 
> In general I'm not convinced that this will fix all issues. 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; }
> 
> I agree with Michael Jones' view. Although the code cries for a
> complete rewrite, we better try to understand how it works first and
> then carefully patch it step by step.
> 
When I checked that code, it was a bit of work to understand it, but
then it looked logical. I did not check what came in last year as I was
out in the Cortex world. I will get back to that when porting EMACs for
STM32F1/2/3/4.
So please give me an update via PM what your thought's about the DHCP
issue are, or give me a phonecall. Cause it doesn't make sense to fix
and patch and wrestle with it, if it is easier to rewrite it in parts or
completely. If you already dived into network it doesn't harm to swim
another round :)

Best regards
Ulrich