Changing TCP MSS under LINUX

Hi All,

Is it is possible to change TCP default send MSS under LINUX somehow?
In particular network, engineers use some fancy feature which adds
some extra header bytes to a frame. The implication is that when LINUX
sends a TCP segment of MSS size, it gets lost 'somewhere' in the
network.

For cases like this, I would like to have a possibility for
workaround, to decrease send MSS so that outgoing frames fit into MTU
bottleneck.

I know following MSS manipulation mechanisms under LINUX :

- Setting a static route with particular MSS. Alas, that only changes
TCP receive MSS, the one which is announced to remote peer during TCP
handshake. It does not affect send MSS.

- setsockopt(TCP_MAXSEG) - well, that would work fine in case program
code would be under my control. But unfortunately that is not the
case.

E.g. on AIX there is network option called tcp_mssdflt, and it is
actually being used for both send and receive directions. Is there
anything similar on LINUX?

Many thanks for your comments,
Regards,

Oleksandr

oleksandr kalinin <alexka79@googlemail.com> wrote:[color=blue]
> Hi All,[/color]
[color=blue]
> Is it is possible to change TCP default send MSS under LINUX somehow?[/color]

man iptables, search for TCPMSS ?

--
Clifford Kite
/* "PPPoE has many advantages for DSL service providers, and
practically none for DSL consumers."
- David F. Skoll */

Hello,

oleksandr kalinin a écrit :[color=blue]
>
> Is it is possible to change TCP default send MSS under LINUX somehow?
> In particular network, engineers use some fancy feature which adds
> some extra header bytes to a frame. The implication is that when LINUX
> sends a TCP segment of MSS size, it gets lost 'somewhere' in the
> network.[/color]

AFAIK an IP packet is not supposed to simply get lost 'somewhere' just
because it's too big. If this happens, then the network is broken
'somewhere'.
When a packet is too big and has the DF (Don't Fragment) flag cleared,
it gets fragmented. If it has the DF flag set, it is dropped but an ICMP
Destination Unreachable - Fragmentation Needed error message containing
the maximum acceptable size is sent back, so the sender can adjust the
path MTU for the destination.
[color=blue]
> I know following MSS manipulation mechanisms under LINUX :
>
> - Setting a static route with particular MSS. Alas, that only changes
> TCP receive MSS, the one which is announced to remote peer during TCP
> handshake. It does not affect send MSS.
>
> - setsockopt(TCP_MAXSEG) - well, that would work fine in case program
> code would be under my control. But unfortunately that is not the
> case.[/color]

- decrease the MTU of the network interface. Of course it will affect
all comunications, including on the LAN.

- use an iptables rule with the 'TCPMSS' target and the 'tcpmss' match
in the mangle/PREROUTING chain. E.g. to clamp the MSS to 1400 :

iptables -t mangle -A POSTROUTING -i <interface> [-s <destination>] \
-p tcp --tcp-flags SYN,RST SYN --mss 1401: -j TCPMSS --set-mss 1400

oleksandr kalinin <alexka79@googlemail.com> wrote:[color=blue]
> Is it is possible to change TCP default send MSS under LINUX
> somehow? In particular network, engineers use some fancy feature
> which adds some extra header bytes to a frame. The implication is
> that when LINUX sends a TCP segment of MSS size, it gets lost
> 'somewhere' in the network.[/color]

Someone else points-out that this should not happen. What should
happen is one of two things:

a) The IP datagram carrying the TCP segment has the DF bit set in the
IP header. At the point where the packet becomes too large, that
router is required to return an ICMP Destination Unreachable, Datagram
Too Large message back to the source, which will then perform some
PathMTU discovery magic and reduce the Path MTU to that destination.
That will cause TCP to send smaller segments to avoid fragmentation.

b) The DF bit is not set in the header of the IP datagram carrying the
TCP segment - the device is supposed to fragment the IP datagram into
pieces which do fit and send them on their way.

If the fancy feature in the network cannot do either of these things
then it is fundamentally flawed and should be removed from the
network.

Now, some complications:

1) For case "a" if anything between the wacky device and the source is
filtering ICMP datagrams in the name of security, Path MTU discovery
will break. You then get a "black hole" and now depend on the sender
to detect that and kludge around it.

2) For case "b" if any one of the IP datagram fragments are lost, the
entire IP datagram is toast.

3) Others too numerous to mention here.
[color=blue]
> For cases like this, I would like to have a possibility for
> workaround, to decrease send MSS so that outgoing frames fit into
> MTU bottleneck.[/color]
[color=blue]
> I know following MSS manipulation mechanisms under LINUX :[/color]
[color=blue]
> - Setting a static route with particular MSS. Alas, that only
> changes TCP receive MSS, the one which is announced to remote peer
> during TCP handshake. It does not affect send MSS.[/color]

I thought that static routes had Path MTUs associated with them. That
would in turn influence the MSS TCP advertises. It was my
understanding that the MSS used was the smaller of the two advertised
during connectoin establishment.

You might peruse the output of sysctl -a

rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On 22 Mai, 19:21, Rick Jones <rick.jon...@hp.com> wrote:[color=blue]
> oleksandr kalinin <alexk...@googlemail.com> wrote:
> Someone else points-out that this should not happen. What should
> happen is one of two things:
>
> a) The IP datagram carrying the TCP segment has the DF bit set in the
> IP header. At the point where the packet becomes too large, that
> router is required to return an ICMP Destination Unreachable, Datagram
> Too Large message back to the source, which will then perform some
> PathMTU discovery magic and reduce the Path MTU to that destination.
> That will cause TCP to send smaller segments to avoid fragmentation.
>
> b) The DF bit is not set in the header of the IP datagram carrying the
> TCP segment - the device is supposed to fragment the IP datagram into
> pieces which do fit and send them on their way.
>
> If the fancy feature in the network cannot do either of these things
> then it is fundamentally flawed and should be removed from the
> network.
>[/color]

Agreed with that completely, and I have already indicated that to
people who control the faulty network. Unfortunately, making correct
statement does not necessarily mean that network fix will become true
soon, that is 'real world' of global private networks... Until network
is fixed, I would like to have some workaround in place.
[color=blue][color=green]
> > For cases like this, I would like to have a possibility for
> > workaround, to decrease send MSS so that outgoing frames fit into
> > MTU bottleneck.
> > I know following MSS manipulation mechanisms under LINUX :
> > - Setting a static route with particular MSS. Alas, that only
> > changes TCP receive MSS, the one which is announced to remote peer
> > during TCP handshake. It does not affect send MSS.[/color]
>
> I thought that static routes had Path MTUs associated with them. That
> would in turn influence the MSS TCP advertises. It was my
> understanding that the MSS used was the smaller of the two advertised
> during connectoin establishment.[/color]

route utility contains -mss option, which may be used to force
changing TCP MSS on particular route.

In case I set static route with -mss 1300, LINUX will advertise
MSS=1260, but for outgoing MSS it will use the value advertised by
remote peer and that is what creates a problem. Indeed, RFC 879 ch. 3
says :

"The MSS can be used completely independently in each direction of
data flow. The result may be quite different maximum sizes in the two
directions."

RFC does not seem to recommend using smaller MSS out of two, so LINUX
behaves correctly in this case.

Thanks for your comments, anyway!

Regards,
Oleksandr

oleksandr kalinin <alexka79@googlemail.com> wrote:[color=blue]
> route utility contains -mss option, which may be used to force
> changing TCP MSS on particular route.[/color]
[color=blue]
> In case I set static route with -mss 1300, LINUX will advertise
> MSS=1260,[/color]

That tells me the -mss option is misnamed and should be -mtu. The MSS
is (typically) 40 bytes less than the MTU. The TCP MSS change is a
side-effect of the path MTU change.
[color=blue]
> but for outgoing MSS it will use the value advertised by remote peer
> and that is what creates a problem. Indeed, RFC 879 ch. 3 says :[/color]
[color=blue]
> "The MSS can be used completely independently in each direction of
> data flow. The result may be quite different maximum sizes in the two
> directions."[/color]

Can, but my understanding was that no stack actually did - do you have
the tcpdump showing that?

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...