dhcpcd-discuss

Hi,

>> Well, the use case for disabling features seems to be really small.
>> E.g. my use case is to make current dhcpcd binary-(packet-)compatible
>> with older version. So I think the default behavior can be kept as it
>> is now, i.e. on by default, off if requested - like e.g. "noarp".

>Why do you need that?
>A RFC2131 compliant DHCP server *should* ignore any options it doesn't
>understand, and all the sent options are structured like any other.

That's true. I need binary compatibility for a privacy-enhancing project where a client wants to reduce its DHCP "fingerprint" (and networking fingerprint overall) - so that it isn't possible to track it based on this. Usually people bother to spoof their MAC and think they're all good, but that is really naive. The project is undisclosed yet but will be open-source for sure once v0.1 is kind of ready.

At maximum I need an ability to construct arbitrary DHCP messages, or, even more, an ability to replicate known DHCP clients behavior, including their specifics... Extremely ambitious, not for v0.1 for sure :)

>OK, lets rock with a patch to allow them to be turned off via nooption.
>Can you do that please and post here? I'm very time constrained right
>now with my day job.

Of course, I understand all that; and I'll work on a patch myself - but for the beginning, to speed up the release of v0.1 I'll keep it as a workaround (i.e. not good to be included in the upstream).