Changing TCP MSS under LINUX - Networking

This is a discussion on Changing TCP MSS under LINUX - Networking ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Changing TCP MSS under LINUX

  1. 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


  2. Re: Changing TCP MSS under LINUX

    oleksandr kalinin wrote:
    > Hi All,


    > Is it is possible to change TCP default send MSS under LINUX somehow?


    man iptables, search for TCPMSS ?

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

  3. Re: Changing TCP MSS under LINUX

    Hello,

    oleksandr kalinin a écrit :
    >
    > 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.


    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.

    > 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.


    - 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 [-s ] \
    -p tcp --tcp-flags SYN,RST SYN --mss 1401: -j TCPMSS --set-mss 1400

  4. Re: Changing TCP MSS under LINUX

    oleksandr kalinin wrote:
    > 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.


    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.

    > 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.


    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...

  5. Re: Changing TCP MSS under LINUX

    On 22 Mai, 19:21, Rick Jones wrote:
    > oleksandr kalinin 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.
    >


    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.

    > > 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.

    >
    > 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.


    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


  6. Re: Changing TCP MSS under LINUX

    oleksandr kalinin wrote:
    > 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,


    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.

    > 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."


    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...

+ Reply to Thread