You are not logged in.
I wanted to lock the MTU to 1500 for my Internet port so I made the following changes:
In rc.local I placed the command
ifconfig eth0 mtu 1500
In /etc/conf.d/dhcpcd I added:
nohook mtu eth0
Note that the eth0 port is set up to use dhcp in rc.conf.
So it boots correctly, MTU is set to 1500, and Internet access is fine. Sometime during the day the MTU changes to 576.
Does anyone know what process is doing this? Is it something I can change?
Thanks in advance.
Mark
Offline
Hi Mark,
I have the exact same problem.
I haven't tried the nohook option to my setup, but I will give that a try and report back. I have this problem on a router (old desktop) on the external NIC which then appears to cause some networking problems.
Walter
Offline
I had this problem and found a fix that worked for me.
It turned out that the dhcpcd client was setting the MTU automatically whenever it renewed my Comcast cable modem's given IP address. Mine's a best-buy purchased one (motorola SB6120) and either it or Comcast's dhcp server for the local area was giving 576 as a default.
In the /etc/dhcpcd.conf, there was an option called "option interface_mtu" that by default was active (i.e., not commented out.) I commented this out, restarted the network & that fixed it. I only had to set the MTU for the interface once again (back to 1500) and it's stayed ever since.
Offline
Hi train_wreck,
Thanks for that tidbit, I will give that a try as well and report back.
Walter
Offline
Hi train_wreck,
I spoke with someone else regarding this issue and he said to double-check the cable modem and make sure it is configured properly. Comcast should not be requesting an MTU of 576 as that would dramatically slow down their network.
Walter
Offline
576 as that would dramatically slow down
MTU is a can of worms - I've played with it, to try to get my ADSL modem reliable, and now do:
ip route replace default via 192.168.1.1 mtu 1460
So now for me this works:
ping -s 3000 www.dslreports.com
576 is the *safest* value, AFAICT, because all IPV4 networks need to support it, as a minimum. And increasing the MTU is a trade-off between responsiveness and throughput, with the risk that MTU negotiation (via ICMP) can fail.
It would be interesting to know the rationale. Maybe it's a case of, "if you have to ask for the MTU, we'll answer with the safest MTU value."
Offline