Cedric Blancher a écrit :
Le lundi 26 février 2007 à 16:34 +0100, Pascal Hambourg a écrit :
Also, wouldn't it be useful to do it in both directions to avoid
fragmentation if host (b) does not use path MTU discovery ?
No, because you don't want to clamp inbound traffic to your MTU, but to
your peer MTU.
I want to clamp both, so TCP segments length does not exceed 1452 in
either direction.
It's your peer job to advertise correctly its own MSS.
Yes, but the MSS advertised by the peer may not be the best one : if it
exceeds the PPP link MTU - 40 (typically 1492 - 40 = 1452) and host
(b)'s MTU (typically 1500) exceeds the PPP link MTU and host (b) does
not use path MTU discovery, then host (b) may send TCP datagrams bigger
than the PPP link MTU that the server/router would need to fragment. So
IMO it would be better that host (b) always see peers' MSS not bigger
than the PPP link MTU - 40.
Now, if you look more closely, you'll see you clamp MSS against
destination PMTU. As PMTU from your firewall to your server is most
probably ethernet MTU, you will clamp it to 1500.
You mean "from the server/router to host (b)" ?
Yes, you have a point. It's useless.
So, if your peer
advertise 1452 as MSS, you will overwrite it to a higher value of 1460
and break everything.
Actually "clamp" means "decrease if bigger", the MSS is clamped only
when it is bigger than PMTU - 40. So it won't break anything. It will
just have no effect.
What about :
iptables -t mangle -A FORWARD -o eth1 -p tcp --tcp-flags SYN,RST SYN \
-m tcpmss --mss 1453: -j TCPMSS --set-mss 1452
