On 12/04/2014 10:37 AM, Jacob Appelbaum wrote:
> On 12/4/14, Daniel Kahn Gillmor <dkg@???> wrote:
>> I'm not sure i'd characterize a simple DHCP client as "quite straight
>> forward", but certainly minimalist one is more straightforward than one
>> which handles all the possible extensions that have cluttered DHCP over
>> the years.
>
> We've already written the start of very basic non raw socket DHCP
> client - it doesn't yet include the parser and later stages but it
> does fetch leases. It is completely straight forward with the basic
> socket API. It is absolutely not required to use a raw socket but it
> requires some trickery with the rp_filter in the kernel.
I'm happy to hear about your progress! can you point to the code
someplace for people who are interested to review it?
> The parsers for any dhcp client are of course rather annoying and the
> rest of the hooks are too. However - remember the DHCP client that
> talks to the *network* does not need to do anything other than the
> full DHCP lease process. Thus with the right design, a minimal or a
> full client are something in another process anyway.
Getting the thing to a state where it's usable for normal people with
normal computers encompasses the whole scope, so the project will have
to deal with the stickier parts eventually.
> I'd be happy to talk with them. Please do introduce me to them in some way?
done offlist. hopefully we can produce something useful :)
>> * specify the lease renewal behavior algorithm
>
> It seems rather straight forward to use the time offered by the server
> - what else do you think is important to consider?
the time offered by the server tells you when the lease expires. it's
up to the client to decide when to try to renew (t/2 seconds? t - 20
seconds? something else? how does it deal with weird values for t like
very small or very large values?). It's also up to the client to decide
how to deal with the renewal when ACKs are delayed or not forthcoming.
Specifying all of the fiddly optional parameters of the renewal strategy
would help implementations avoid being fingerprintable based on timing
as well as content.
Regards,
--dkg
