harald.kipp at egnite.de
Wed May 8 10:52:58 CEST 2013
Today I spent some time to verify the current implementation against RFC
2131 in more detail.
On 29.04.2013 15:46, Ulrich Prinz wrote:
> 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
> described enviroment.
The changes are
Nearly all of the changes are done to add more debug code. Some of them
add superfluous brackets to if-expressions.
One change starting at line 1644 changes the behavior significantly.
During renewal, it switches back to the BOUND state when the number of
retries are exhausted. This is definitely not according to the RFC and
may introduce other problems.
Further down at line 1694 the original version clears the retry counter
and changes to SELECTING, while the patch sets the retry counter above
the maximum. In fact, this patch disables any retries in the SELECTING
state. This may cause a severe problem. Possibly this one, reported by
Bernd a few months later
Ulrich, it looks to me that the fixes done in your former company never
made it into the repository. Instead, r2982 may introduce new problems.
At least I cannot see that it will fix anything. I'd vote for removing
More information about the En-Nut-Discussion