emo/ndhc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Be less harsh to udhcp in HISTORY... there was no better choice among the

Browse Source 
considered options at the time.
This commit is contained in:
Nicholas J. Kain 2011-07-24 18:02:25 -04:00
parent 7f6721bb82
commit fe85e52a4b
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
README
View File

@ -255,12 +255,12 @@ be used with resource-constrained or embedded systems, and was thus very
small. ISC dhclient was another alternative, but it is an extremely large small. ISC dhclient was another alternative, but it is an extremely large
program, and it would have been very hard to audit it for correctness. program, and it would have been very hard to audit it for correctness.
udhcpc was not all that great of a choice, since it was designed to be small at udhcpc was not did not really fit my requirements well, since it was designed
all costs, sacrificing correctness when necessary. The code was hard to to be small at all costs, sacrificing correctness when necessary. The code was
follow, and had many quirks. Bounds-checking was rare, type aliasing common, hard to follow, and had many quirks. Bounds-checking was rare, type aliasing
and state transitions were convoluted. Not all of the client was asynchronous, common, and state transitions were convoluted. Not all of the client was
and no precautions were taken against conflicting peers. ARP was not used at asynchronous, and no precautions were taken against conflicting peers. ARP was
all. not used at all.
However, it was small. With a lot of work, I ripped out the script-calling However, it was small. With a lot of work, I ripped out the script-calling
mechanisms and replaced them with ifchd requests. Bounds-checking was mechanisms and replaced them with ifchd requests. Bounds-checking was