tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Retiring dhclient



On Nov 24, 2011 9:33 AM, "Roy Marples" <roy%marples.name@localhost> wrote:
>
> On 24/11/2011 06:35, David Young wrote:
>>
>> On Wed, Nov 23, 2011 at 10:57:48PM +0000, Roy Marples wrote:
>>>
>>> On Fri, 2011-11-18 at 09:58 -0600, David Young wrote:
>>>>
>>>> This is one of those cases where the DHCP client should use a hook to
>>>> decide.  You definitely don't want to hard-code the policy.
>>>>
>>>> (I like dhcpcd a lot, really, but sometimes it has hard-coded a policy
>>>> where there was already precedent for different people setting different
>>>> policies.)
>>>
>>>
>>> Can you give examples of these hard coded policies?
>>> I'd to take the challenge of providing a dhcpcd.conf entry to make it
>>> work how you like, or patch dhcpcd to make it so :)
>>
>>
>> For example:
>>
>> On Wed, Nov 23, 2011 at 10:30:48PM +0000, Roy Marples wrote:
>>>
>>> I don't know if you covered it, but currently dhcpcd by default requests
>>> an MTU from the DHCP server and if given and valid, sets it.
>>
>>
>> :-)
>
>
> All too easy! In dhcpcd.conf that ships you can find this entry
>
> # Respect the network MTU.
> option interface_mtu
>
> Simply comment it out or remove it.
>
> You could also set
> nooption interface_mtu
>
> Which would strip it from the DHCP message if the server forces it on you as 
> well.
>
> It's harcoded in the same why that a US keyboard is by default. Although you 
> could argue that a
> typical end user should neither know nor care about MTU. I am loath to change 
> it, as a lot of other
> OSes ship with it default to request and set.

Maybe there could be an interface characteristic that dhcpcd (or other
userland tools) could query, so it could default it on for known good
interfaces only.


Home | Main Index | Thread Index | Old Index