# [Solved, with caveat] MTU and dhcp

## Corona688

say I have the following lines in /etc/conf.d/net:

```
config_wan=( "dhcp" )

mtu_wan="1500"
```

 These seem to be mutually exclusive;  when it uses DHCP, it sets the MTU to what it pleases(which ends up being wrong in my case).  How can I force it to use a given MTU?

----------

## Corona688

bump

----------

## lonex

You just have to add the following line, so that dhcpcd doesn't set the MTU to what the dhcp server says:

```
dhcpcd_wan="-M"
```

----------

## Corona688

I cannot find that '-M' dhcpcd flag documented anywhere at all.  Are you sure you're not thinking of some other DHCP clilent?

----------

## lonex

I've read man dhcpcd ... and there it is?

 *Quote:*   

> -M     Prevents dhcpcd from setting the MTU provided by the DHCP server.

 

That's with dhcpcd-3.1.5, that is.

----------

## Corona688

Ah, so the unstable dhcpcd is required.  Small price to pay I suppose.  Great!  Thanks.

----------

## UberLord

3.1.5 is stable on most arches, and has been for a while now.

----------

## Corona688

I'm kind of running my own tree right now, maintaining a bunch of near-identical servers, so naturally the official tree and mine don't quite match.  It can't have been THAT long ago, my tree's not THAT old either.

I'm quite suprised they made it stable already though, since I noticed a few issues when I went and tested it's behavior on timeout!  I don't see anything about these issues in the changelog either, Gentoo's or dhcpcd's, so I presume they still stand.

zeroconf is enabled by default!  If it times out, it will autoconfigure to some bizzare address in 169.x.y.z(anyone else remember this headache from the Windows 98 days?) instead of using your failovers in /etc/conf.d/net .  Give dhcpcd the "-L" flag to stop it doing this.

If it still has a lease in cache, when it times out, it will use that lease instead of using your failovers in /etc/conf.d/net .  There's no "please don't use cache" commandline flag, and the "please delete cache" flag doesn't work unless dhcpcd is already running, so you have to just go and delete the cache yourself before dhcpcd gets run.  Putting it in the preup() function in /etc/conf.d/net was fairly convenient, like so:

```

# Disable zeroconf(-L) and don't mung wan's MTU(-M)

dhcpcd_wan="-M -L"

# Remove cache for interface!  arrrggh!!!!

preup() {

        if [[ "${IFACE}" == "wan" ]]

        then

                # Destroy cache so it can't interfere with fallbacks!

                if [[ -f "/var/run/dhcpcd-${IFACE}.pid" ]]

                then

                        einfo "Clearing dhcpcd cache for ${IFACE} ..."

                        dhcpcd -k ${IFACE} 2> /dev/null > /dev/null

                        eend

                fi

                if [[ -f "/var/lib/dhcpcd/dhcpcd-${IFACE}.info" ]]

                then

                        einfo "Burning dhcpcd cache for ${IFACE} ..."

                        rm -f /var/lib/dhcpcd/dhcpcd-${IFACE}.info

                        eend

                fi

        fi

}
```

 Rather obnoxious when you're trying to maintain servers over satellite links...

----------

## UberLord

 *Corona688 wrote:*   

> 
> 
> [list][*]zeroconf is enabled by default!  If it times out, it will autoconfigure to some bizzare address in 169.x.y.z(anyone else remember this headache from the Windows 98 days?) instead of using your failovers in /etc/conf.d/net .  Give dhcpcd the "-L" flag to stop it doing this.

 

zeroconf is a good idea.

When I implemented it I was unsure to enable it by default or not. I decided to enable it. No-one has complained about this until now.

 *Quote:*   

> [*]If it still has a lease in cache, when it times out, it will use that lease instead of using your failovers in /etc/conf.d/net .

 

That's a bug which may have been fixed in 3.1.6, but has for sure in my svn repo.

----------

## serial_penguin

 *UberLord wrote:*   

>  *Corona688 wrote:*   
> 
> --- CUT ---
> 
>  *Quote:*   [*]If it still has a lease in cache, when it times out, it will use that lease instead of using your failovers in /etc/conf.d/net . 
> ...

 

This does appear to have been corrected with dhcpcd 3.1.6

----------

## Corona688

 *UberLord wrote:*   

> zeroconf is a good idea.

  Yes, it is, if you want to use it, and only if you want to use it.  If someone didn't enable it themselves or doesn't know what it is, they probably didn't want it. *Quote:*   

> When I implemented it I was unsure to enable it by default or not. I decided to enable it. No-one has complained about this until now.

  You really ought to mention to users, and perhaps the baselayout people, that failovers no longer work as advertised.  I'd put in an e-notice and maybe even announce it in the newsletter.  Not a lot of people use failovers, but those that do probably think they're important.

Bottom line, it's a behavior change, the sort of thing one tries to keep to a minimum in baselayout stuff even in a rapidly-changing distro like gentoo.  It's also unannounced;  an e-notice might have saved me hundreds of klicks of driving.  Third, it's a silent change;  surely I'm not the only one using failovers, just the first one that's noticed.  People that're using failovers may not be aware they're broken until the rare event that needs one occurs, i.e. once it's too late.

----------

## UberLord

Did you know that I maintain baselayout as well?

Also, moaning on the forums doesn't make me want to change anything. Most devs don't read the forums, so you need to file a bug to get their attention.

Maybe you want to file a bug against dhcpcd to add warnings about zeroconf and the -L option.

Maybe you want to file a bug against baselayout to document this in net.example.

----------

## Corona688

 *UberLord wrote:*   

> Did you know that I maintain baselayout as well?

  You, and nobody but you?  No other devs that might need to know this?  *Quote:*   

> Also, moaning on the forums doesn't make me want to change anything.

  Noting legitimate problems and their solutions in a forum devoted to such is "whining" now.  Good to know.  If I was demanding gas money from you, I'd be whining.  I'm not.  I deployed, I face the consequences. *Quote:*   

>  Most devs don't read the forums, so you need to file a bug to get their attention.

  Most devs don't, sure.  Lots of users do, and they're the ones that need to know if this behavior isn't changed back.  I didn't think a behavior change in baselayout qualified as a bug either, given your past responses.  Since you now claim it can, I shall.

[edit] #196067

----------

## UberLord

One other dev aside from me currently contributes to baselayout, but I do around 99% of the work.

http://sources.gentoo.org/viewcvs.py/baselayout/trunk/

Sorry, it was your tone that I was referring to. Forums are a perfectly legit place to note problems and their solutions.

No, it's a behaviour change in dhcpcd. baselayout thinks dhcpcd succeeded when dhcp fails and it gets a local link address. But then, with a zeroconf implementation it will never fail, so it will always "work" from baselayouts view.

Now, dhcpcd is NOT a Gentoo project as such I didn't feel a massive need to inform the world about this "behaviour" change. Even if I did then it would be to the dhcpcd mailing list subscribers.

Now hands up how many people run ~ARCH or unstable dhcpcd? I ask as it's been there for two months, and you're the first to complain about this specific feature.

Maybe more people should help test.

----------

## UberLord

I just saw your bug. OK, so jakub our sometime over zealous bug-wrangler marked it as a dupe. Maybe a better bug would be as follows

 *Quote:*   

> dhcpcd-3.1 now ships with zeroconf support. I don't think this should be enabled by default as it changes prior behaviour. Please supply a USE flag to control this or at least a warning in the ebuild.

 

----------

## Corona688

 *UberLord wrote:*   

> Now, dhcpcd is NOT a Gentoo project as such I didn't feel a massive need to inform the world about this "behaviour" change. Even if I did then it would be to the dhcpcd mailing list subscribers.

  If not you, then whom?  You seem to maintain the dhcpcd ebuild too, and the testers aren't likely to catch a change that only matters if your DHCP server breaks down.  *Quote:*   

> Maybe more people should help test.

  I don't think anyone's going to argue with that.   :Smile: 

----------

## UberLord

I failed to maintain that I am upstream for dhcpcd, baselayout and maintain both ebuilds as well. I also lead the Gentoo/FreeBSD effort and currently preside on the Gentoo Council.

I also maintain the other DHCP v4 ebuilds.

Now, we'll move this conversation to the bug  :Smile: 

----------

