TotalGriffLock / udmp-jumbo-frames-ppp

Shell script to configure and monitor the baby jumbo frame configuration on the UDM Pro WAN interface
7 stars 2 forks source link

Not setting MTU on ppp interface #3

Closed bdavj closed 1 year ago

bdavj commented 2 years ago

``Using a UDM-SE

The ethernet interface MTU gets set to 1508, and the ppp config file updated to mtu 1500, however the link itself (ip link list ppp0) doesnt get set to 1500 MTU.

I have added a script in /etc/ppp/ip-up.d to run the following as a band-aid. Should this be set by the pppd?

#!/bin/sh
# based on script from ddclient package

# # These variables are for the use of the scripts run by run-parts
# PPP_IFACE="$1"
# PPP_TTY="$2"
# PPP_SPEED="$3"
# PPP_LOCAL="$4"
# PPP_REMOTE="$5"
# PPP_IPPARAM="$6"

echo "Interface $PPP_IFACE"
if [ "$PPP_IFACE" = "ppp0" ]; then
    ip link set ppp0 mtu 1500
    echo "Set PPP MTU"
fi
TotalGriffLock commented 2 years ago

Am looking into this - I've noticed this on my own UDM SE as well. It definitely worked when I wrote it. Unfortunately calling ip link set mtu on an existing PPP link doesn't do anything other than update the number that the ip command shows you, if you do some ping tests with the DF bit set you will see your MTU is still 1492. MTU can only be set on PPP links at link negotiation time.

bdavj commented 2 years ago

I'm not sure thats the case (or indeed I may well be testing wrong!) - When I change the ppp mtu using ip link I see the "Frag needed and DF set" warning: image

bdavj commented 2 years ago

Did you gain any more clarity on this? I’m not convinced my way is working consistently either, nor whether my ping test is accurate. I’ve used a couple of test tools online and get different results to my ping test depending on the order in which I do things on the UDM

TotalGriffLock commented 1 year ago

I did, I think. From what I can work out in my testing, if you set the MTU in the UDM shell once the link is established, it sets it for your end of the link, so the UDM starts being able to transmit frames of 1500 bytes, so your local tests from behind the UDM will appear to work. What it doesn't do is change it at your ISPs end of the link, so the packets that come to you from the internet are still limited, so that means online tests of your MTU such as http://www.letmecheck.it/mtu-test.php fail even with the UDM showing the correct MTU.

In other news I think I've figured out why the script was misbehaving in your case, and have refactored it a little bit. I have tested it on my UDM-SE and it works great, but I still have an outstanding issue where I'm relying on bash which doesn't exist on the UDM-Pro. Just needs an if statement in it to determine the platform.

TotalGriffLock commented 1 year ago

I believe this is resolved now - please update and retest

bdavj commented 1 year ago

Never came back to this - been working great - thanks!