# [SOLVED] Unable to automatically set the MTU

## POSIX_ME_HARDER

I'm experiencing network issues between two computers connected by ethernet LAN (and yet no internet issues, it's just when they want to talk to each other).

Those seem to disappear when changing the MTU settings to a lower value, 1400 instead of 1500, but I'm having trouble getting this done automatically.

Indeed, every time I reboot the computer it goes back to 1500 (considering this greatly impedes SSH, it gets quite annoying).

Following instructions from a thread concerning a similar problem, I tried:

Setting the MTU from /etc/dhcpcd.conf:

I Added the following line to the top of /etc/dhcpcd.conf:

```
static interface_mtu=1492
```

And added dhcpcd to the default boot level:

```
rc-update add dhcpcd default
```

Which looks like this:

```
               binfmt | boot                         

             bootmisc | boot                         

                devfs |                       sysinit

               dhcpcd |      default                 

                dmesg |                       sysinit

                 fsck | boot                         

             hostname | boot                         

              hwclock | boot                         

              keymaps | boot                         

            killprocs |              shutdown        

    kmod-static-nodes |                       sysinit

                local |      default                 

           localmount | boot                         

             loopback | boot                         

              modules | boot                         

             mount-ro |              shutdown        

                 mtab | boot                         

             netmount |      default                 

               procfs | boot                         

                 root | boot                         

            savecache |              shutdown        

                 sshd |      default                 

                 swap | boot                         

            swapfiles | boot                         

               sysctl | boot                         

                sysfs |                       sysinit

         termencoding | boot                         

         tmpfiles.dev |                       sysinit

       tmpfiles.setup | boot                         

                 udev |                       sysinit

              urandom | boot  

```

Yet, after rebooting, the MTU setting is still set to 1500:

```
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000

    link/ether 02:99:03:41:ec:c2 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.202/24 brd 192.168.1.255 scope global eth0

       valid_lft forever preferred_lft forever

```

And dmesg tells me:

```
[   14.551074] stmmaceth 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

[   17.491319] eth0: must be stopped to change its MTU

```

Seems like dhcpcd is too late to the party, preventing it from setting the MTU.

Setting the MTU from /etc/conf.d/net:

I set /etc/conf.d/net file to:

```
config_eth0="dhcp"

mtu_eth0="1400"

```

I added net.eth0 to the default boot level, and got:

```
[   12.549967] eth0: must be stopped to change its MTU

[   14.301067] stmmaceth 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

```

The MTU still is 1500, and "ip addr" gives me the same as with the other method.

Setting the MTU manually:

```
ip link set eth0 down; ip link set dev eth0 mtu 1400; ip link set eth0 up
```

The MTU setting is correctly set and everything runs smoothly.

Any idea why the first two methods are not working and how to fix it?Last edited by POSIX_ME_HARDER on Mon Aug 31, 2015 1:39 pm; edited 3 times in total

----------

## kurly

Smells like bug 555974... does using >=net-misc/dhcpcd-6.9.2 fix the problem?

My apologies if this winds up being a dead end or non-solution.

----------

## POSIX_ME_HARDER

Thank you for the suggestion. Sadly, using dhcpcd 6.9.2 did not solve the issue.

In the bug report you linked, dhcpcd seems to be able to change the MTU, but restores it to its previous value right away.

In my case, it seems dhcpcd can't set the MTU because the interface is already up.

Is there perhaps a way to tell dhcpcd that it's OK to turn eth0 off to edit the MTU?

My best solution so far is adding a script in /etc/local.d/, but the fact that it doesn't work the way it's supposed to bothers me a bit.

----------

## krinn

Sorry, the best thing to do is looking why your two computers have trouble at 1500 MTU.

MTU are standards values, for eth2 it's 1500 (no more, and no less, exactly that value), pppoe use 1492 (because 1942 for eth2 datas + 8 for ppp headers = 1500 the standard MTU of eth2)

Getting out the of the standard you are not solving your issue like you think, you are adding trouble to your trouble, and you lesser to get any help from anyone and you'll be alone to handle this ; even i know the symptoms of someone silly doing that, i have no clue howto myself handle that, except getting back to the standard ; but if you know someone that understand the MTU mechanic deeply, that must include, how any devices (including the device you have no control over) receiving the packets can be alter to handle it with your non standard way, better make friend with it asap!.

Here's symptoms example, and you can see this user did like you lowering MTU to prevent the MTU trouble his router was doing.

Back to 1500 and really dig at who was causing problem, it has fix it. https://forums.gentoo.org/viewtopic-t-935256-highlight-mtu.html

Another one, if you like to see where your "i'm altering the MTU because i can" way will drive you : https://forums.gentoo.org/viewtopic-t-566869-highlight-mtu.html

----------

## NeddySeagoon

POSIX_ME_HARDER,

The MTU is unlikely to be your problem.  In any case, if its sub optimum, things mostly still work but you get extra packets sent over the link as they need to be broken up.  This increases the overhead ... until you get a packet with the do not fragment flag set, so it cannot be sent at all.

First, use ping with various packet sizes and the do not fragment flag set to determine the MTU over the link.

If its 1500 (including headers) the MTU is not your issue.

Its rare to need to change the MTU manually.  A few old brain dead domestic routers, don't do PPPoE properly and for them, forcing a MTU of 1492 helps.

----------

## POSIX_ME_HARDER

Sure, let's try something else   :Very Happy:  . I focused on the MTU because it seemed to solve the problem but it could indeed be caused by something else.

I think I'll have to give more information about the connection issues then:

My local network has three computers. Two of which (200 and 202) are connected through ethernet and one (201) using WiFi.

200 and 202 have a hard time talking to each other (trying to connect through SSH will hang at "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY"  and distcc gets stuck).

They have no issue communicating with 201 however.

Just in case this could be linked (no pun intended), the modem router connecting them gets its Internet from PPPoE (with a 1492 MTU setting), to get to the Internet the modem-router goes through a second router that will handle packet tagging in and out of the VLAN used by my ISP (it's not optimal, but the modem-router can't do it by itself).

Here are the results of my ping tests:

200 <-> 202: If I go higher than 1459 (meaning 1487 total size), there are no replies.

200 <-> 201: I can go up to the maximum size (1500 total, as expected).

201 <-> 202: Same here.

200 <-> Internet: It tells me the maximum MTU is 1492 (as expected? considering how the router is configured...).

The command I used is:

```
ping -v -s SIZE -M do IP
```

From what I've found so far, most people having issues with wrong MTU settings seem to get issues while using the Internet, yet I've only noticed issues in my local network, my Internet works just fine.

It worked just fine when 202 was running Arch Linux ARM (the other two were already using Gentoo), it only started when I installed Gentoo on 202 (it also got an U-Boot update).Last edited by POSIX_ME_HARDER on Sun Aug 30, 2015 2:22 pm; edited 1 time in total

----------

## NeddySeagoon

POSIX_ME_HARDER,

On the face of it

```
200 <-> 202: If I go higher than 1459 (meaning 1487 total size), there are no replies.
```

is broken.

Post the routing tables from both systems with 

```
route -n
```

and tell how the ethernet links that link 200 <-> 202 are set up.

If you do it using /etc/conf.d/net post both net files.

As a test connect 200 <-> 202 with no router in the middle. Just an ethernet cable.

You may need to do some manual set up at each end to get the ethernet link up but getting an MTU of 1500 would show that its not the  200 <-> 202 systems and we can start looking at your router setup.

----------

## POSIX_ME_HARDER

Here are the current routing tables:

200:

```
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
```

201:

```
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         192.168.1.1     0.0.0.0         UG    303    0        0 wlan0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

192.168.1.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0
```

202:

```
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         192.168.1.1     0.0.0.0         UG    2      0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 eth0
```

I'll try connecting 202 to 200 directly and post the results ASAP (it may take a while).

----------

## grosgood

Curious that the observed problem coincides with the transition from Arch --> Gentoo on 202. Could this have involved physical movement of the machine? A general cleaning of hardware? Vacuuming out dust bunnies? Pulling and reinserting of network cables? A dirty RJ45 plug can host all kinds of network gremlins that don't wake up until the cable is physically disturbed and dust gets in between those little wires.

When you do Neddy Seagoon's test, don't be surprised if the problem disappears. Or maybe put a fresh set of shiny new cables in your present setup and rerun your tests. I've fixed network problems doing nothing more than that.

Good luck!

----------

## NeddySeagoon

POSIX_ME_HARDER,

Your wired ethernet network topology is a 'V' shape, with 200 and 202 on the top of the arms and the router at 192.168.1.1  at the bottom of the 'V'

Its a bit scary that 201 is using WiFi on the same subnet as wired, both from a security point of view and and a routing pount of view.  It can be made to work though.

There is nothing there to contribute to your problem.

grosgood,

Its called 'wiping the contacts'.  If this is the issue, ifconfig should show errors.

----------

## POSIX_ME_HARDER

Sorry for the delay, I had never linked two computers directly. 

Yup, as you both expected, the problem does not appear when connecting 200 and 202 to each other directly, the MTU is indeed 1500.

I'm surprised the local network topology is considered weird (what I consider weird about my network is the router whose sole role is to tag packets), it's what most ISPs boxes do, right? encrypted WiFi + ethernet.

And yes, I cleaned up 202 just before installing Gentoo. I'll do it again, just in case there's dust in the RJ45 port (it's indeed possible, as the board was quite dusty).

Edit:

 :Laughing:  Yup, cleaning up 202 again resolved the problem. Thank you very much to you guys for your time, glad to see this forum actively helps its members. I'll now procede to laughing out loud for a few more minutes about the hours spent trying to fix what was actually just some dust.

----------

## NeddySeagoon

POSIX_ME_HARDER,

That leaves your cables and your router at 192.168.1.1.

I'm supposed to use Big Thiefs Network Termination Equipment as I'm the UK.

Thats a transparent VDSL to PPoE bridge.  I don't need to set the VLAN as its in BTs NTE. 

However, if use my own VDSL modem, I need to set the VLAN or I don't get any data.

There is a lot to be said for using my own VDSL modem but as my data rate is at the system provided maximum, I don't bother. Not often anyway.

----------

## POSIX_ME_HARDER

I should have done a better test than a simple SSH connection: turns out the reason it works is because 202 rebooted after I cleaned it up and reapplied the local script (I forgot about) to set a 1400 MTU. Now I'm confused, why did it allow 1500 MTU pings earlier (when connecting 200 and 202 directly), despite the fact that the script was still there, I have no idea.

Still, I'll redo the test once more, just to be sure.

I've connected 201 to the network using ethernet instead. Surprise: it suffers the same issue as the others, so clearly the computers on my local network can't communicate using both ethernet and MTU 1500.

Now, let's get to the modem... (although I don't understand why a modem problem would not appear when I was using Archlinux ARM).

It's a "TP-Link ADSL2+ Gigabit Double Bande AC1750", with the firmware "0.9.1 0.12 v002d.0 Build 150514 Rel.33266n", the ISP is "Orange" (France).

I'm connected using EWAN (PPPoE), with a MTU of 1492.

I have no idea what we're looking for.

----------

## NeddySeagoon

POSIX_ME_HARDER,

The routing table from the router would be good

When I first got ADSL, my bandwidth over my network suddenly dropped.

All my local traffic was getting sent over my ADSL link to my ISP and bacK.

Oops.  It took me a few days to discover that :)

Even then, a MTU of 1492 should work. Is your router one of these?

----------

## POSIX_ME_HARDER

Yes, it is. I have an optic fiber though (I doubt it changes anything concerning this issue).

I tried using Windows on 200 to ping 202, same results. I don't understand how it could work with Arch before. yet I know it did.

I'll create a thread on TP link's forums as well.

Oh, and since I forgot to do the tests before:

200 <-> modem: 1500 MTU max.

202 <-> modem: 1500 MTU max.

----------

## NeddySeagoon

POSIX_ME_HARDER,

Try tracert and see where the traffic goes.

It should go to the router then to the other PC.

Fibre and only ADSL2+ Ewww.

----------

## POSIX_ME_HARDER

```
>tracert 192.168.1.202

Tracing route to 192.168.1.202 over a maximum of 30 hops

1   <1 ms   <1 ms    <1ms    192.168.1.202

trace complete.
```

Seems to go directly to the other PC.

I don't understand the comment about using ADSL2 with an optic fiber.   :Confused: 

It uses a gigabit ethernet port to connect to "the internet" (more like, a second router which will tag its packets), which could actually be causing the issue, I'm guessing, because it says it creates a VLAN to do so. Meaning the speeds are as good as they can be.

----------

## NeddySeagoon

POSIX_ME_HARDER,

I used to get 4Mbit/sec over ADSL2+ without fibre.

I now get 80Mbit/sec with fiber to the cabinet.  The last 40m uses the phone line for VDSL.

All the hardware is 100Mbit/sec capable but BT won't let us use it even for money.

While your router is ADSL2+ capable, you are not using the  ADSL2+ port for the internet connection. That was confusion on my part.

Sorry about that.

The VLAN may increase your latency but it will not affect youl data rate.

I expected to see your router listed there too.

----------

## krinn

 *Quote:*   

> the modem router connecting them gets its Internet from PPPoE (with a 1492 MTU setting)

 

1492 is invalid (always) for a router. It's 1500.

1492 should only be use with pppoe (modem/dialup), if it is connect to an ethernet card, in this case the eth card gets 1492 MTU too, but the card is not directly connect to your lan, you must use a bridge.

So if you are using a real modem, 1492 is fine for it, if it's a modem/router, it must be set to 1500.

----------

## NeddySeagoon

krinn,

A router has two sides an upstream side (WAN) and a downstream side (LAN).

If the WAN port is a PPPoE endpoint then 1492 is correct on the WAN.

As you say, the LAN side should be 1500.

Route MTU discovery will use 1492 going to the WAN and 1500 to the LAN.

The router may have both 1492 and 1500 MTUs configured on the WAN/LAN.

----------

## POSIX_ME_HARDER

I tried changing the setting for the PPPoE, 1492 is the maximum value (the interface won't let me go higher), setting it to a lower value does not affect the MTU between PCs of the local network (it does however lower it when testing towards the Internet, as expected).

The router between the TP-Link and the ONT is a "Netgear GS108E v3", it's configured to tag packets comming from the TP-Link and untag those coming from the ONT.

----------

## krinn

And jumbo frames support is disable?

----------

## gordonb3

May I assume that you have the ethernet connected machines hooked up to the TP-Link router? How about using the netgear switch instead? You probably only use 3 of its 8 ports for NT (tagged), internet (untagged) and television (untagged). Simply create a new VLAN ID (e.g. 100) and let the remaining ports be a member of this VLAN ID only. These will now act as a 5(?) port switch that you can use for your LAN.

----------

## UberLord

 *POSIX_ME_HARDER wrote:*   

> I'm experiencing network issues between two computers connected by ethernet LAN (and yet no internet issues, it's just when they want to talk to each other).
> 
> Those seem to disappear when changing the MTU settings to a lower value, 1400 instead of 1500, but I'm having trouble getting this done automatically.
> 
> Indeed, every time I reboot the computer it goes back to 1500 (considering this greatly impedes SSH, it gets quite annoying).
> ...

 

Ah, that would be my fault.

dhcpcd-6.9.x changed from setting the MTU directly on the interface and instead sets it on each route.

This allows IPv4 and IPv6 to have different MTU's (IPv6 has always set MTU per route) without stamping on each other and works around buggy interface drivers who reset PHY on MTU change.

What I forgot to do was to allow setting the MTU statically rather than just using what was in the DHCP message.

This is fixed here:

http://roy.marples.name/projects/dhcpcd/vpatch?from=19ce3a9e82013deb&to=024f77d3102931ab

Now, I cannot say (or really support) if that fixes the root issue you seem to be having that you're all talking about above - just fixing a dhcpcd bug  :Smile: 

----------

## POSIX_ME_HARDER

I'm unsure how to check for the jumbo frames.

202 can only go up to 100MBit/s, jumbo frames can only be used on gigabit ethernet, right?

I tested on 200 by setting the MTU to 2000 and pinging the modem-router. I can send packets of (total) size up to 1505 bytes, so I'm guessing that means jumbo frames aren't enabled.

 *gordonb3 wrote:*   

> May I assume that you have the ethernet connected machines hooked up to the TP-Link router? How about using the netgear switch instead? You probably only use 3 of its 8 ports for NT (tagged), internet (untagged) and television (untagged). Simply create a new VLAN ID (e.g. 100) and let the remaining ports be a member of this VLAN ID only. These will now act as a 5(?) port switch that you can use for your LAN.

 

I'll try that ASAP.Last edited by POSIX_ME_HARDER on Mon Aug 31, 2015 10:41 am; edited 1 time in total

----------

## UberLord

 *NeddySeagoon wrote:*   

> krinn,
> 
> A router has two sides an upstream side (WAN) and a downstream side (LAN).
> 
> If the WAN port is a PPPoE endpoint then 1492 is correct on the WAN.
> ...

 

Some firewalls block ICMP which stops Route MTU discovery from working.

This is why I clamp TCP MSS to 1452 on my router. Why 1452? Well, this allows head room for extra packet overhead, such as the PPPoA->PPPoE bridge I have in place.

If your router won't do that, you may need to stick another router in front of it which does allow it - or try the dhcpcd-9999 ebuild to get the above change  :Smile: 

----------

## gordonb3

 *POSIX_ME_HARDER wrote:*   

> 202 can only go up to 100MBit/s, ....
> 
> 

 

Those different network speeds may in fact be causing your issues. Not all switches and alike do handle that correctly - I've even seen a Cisco switch once dropping overall speed to far below 10Mbit because it couldn't cope with both 100M and Gigabit devices being connected to it.

----------

## POSIX_ME_HARDER

Configuring a second VLAN on the switch (which I kept calling a router, my bad) too waaaay longer than expected (Windows only software + can't configure it if it's between the ONT and the modem + faulty RJ45 cable), but it's done.

And everything seems to work (I tested the pings this time  :Rolling Eyes:  ).

It's more avoiding the issue than solving it, but I'll take it.

Thank you very much for your help. I'm impressed by how friendly this forum is.   :Smile: 

----------

