>> I see the same, but don't know what the behavior should be. If you set
>> mtu on say eth0 then advertised tcp mss will be affected (which in a way
>> is setting mtu plus mru for tcp) - maybe the route setting really just
>> does mtu alone, which in a way is what you asked for
> That would not be very good at all, because it breaks PMTUD. I would
> obviously want the MTU to match the route.
It doesn't break PMTUD as such - if someone sends you a larger packet
with DF set than your ISP can send, then your ISP should send a frag
needed. The trouble is it may never reach the sender so it's best to
avoid the situation arising (for tcp) by advertising a smaller mss.
>> If you want to fix up your wan use iptables mss clamping on the gateway
>> if you can.
> I had a quick look through the router configuration settings and I could not
> see such an option, so I guess that this facility is not provided.
Ahh, I see now you don't have shell access. It may be clamping anyway as
noted elsewhere. Some routers will clamp to the mtu on the wan/ppp
connection by default, or maybe your ISP is doing some clamping.
I would see if the test upload works after you set mtu on the machines
nic rather than the route.
>> Using ping to try and work out isp behavior can be misleading - you may
>> just be seeing the settings of the server/network you are pinging and
>> the pings may get fragged/re-assembled without you knowing.
> With PMTUD enabled, the Don't Fragment flag is set though, isn't it? So this
> would mean that we have a single datagram end to end.
A quick test on my box shows that df is only set for ping when < mtu.
If the ping is larger it gets fragged and reply is also fragged.
Assuming iputils ping you can force no frag with ping -M do .....
If you have set mtu low with route/on nic this will just refuse to send
> than that, so to test you need to set higher mtu, and of course be
aware that what you see may just depend on the settings/net of the
target rather than your ISP.