6

I have there a OpenVPN VPN network connection, where the MSS size 60 gets send out for some reason (don't know why yet). EDIT: Reason: OpenVPN mssfix was mistakenly set to 1

36  92.064383   10.102.0.43 10.1.151.50 TCP 52  49991 → 63760 [SYN] Seq=0 Win=65535 Len=0 MSS=60 WS=128 SACK_PERM=1
37  92.064763   10.1.151.50 10.102.0.43 TCP 52  63760 → 49991 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1

There are two devices on this network, which behave different.

  • Win 10 PC with Filezilla FTP Server
  • Embedded device (PLC) based on VxWorks with internal FTP server

The PC sets the MSS size to 536, but the PLC sets it down to 60 like requested.

41  92.171676   10.1.151.50 10.102.0.43 FTP-DATA    576 FTP Data: 536 bytes (PASV) (RETR TCData.br)
67  17.385576   10.1.151.1  10.102.0.43 FTP-DATA    100 FTP Data: 60 bytes (PASV) (RETR TCData.br)

Is that implemented on the right way on both sides?

I know that the default TCP MSS is 536, but is there a required minimum size?

Improve this question
2
  • I have browsed through relevant RFCs and found no mention of a minimum value for MSS. The most relevant sources I could find were tools.ietf.org/html/rfc1122#page-85 and tools.ietf.org/html/rfc6691#section-2. From this it sounds like there is no minimum value. But a sender may need to subtract as much as 80 from the value to account for IPv4 and TCP options, thus an MSS smaller than 81 can potentially lead to breakage. It's not clear to me what the implication of IPv6 option headers would be.
    – kasperd
    Commented Jan 26, 2019 at 12:41
  • Since the MTU can be as low as 68 bytes it may be necessary to fragment a TCP segment. So for the discussion in tools.ietf.org/html/rfc6691#section-2 to make sense it would have to apply before fragmentation. That means if a sender needs to use the full 40 bytes for IPv4 options and 40 bytes for TCP options and has received an MSS of 81 and has an MTU of 68. It would first produce a 121 byte TCP packet with 1 byte of payload, which is then fragmented into 8 fragments (7 of 68 bytes and one of 65 bytes). That would be a ridiculous overhead, but from my reading it's within specs.
    – kasperd
    Commented Jan 26, 2019 at 12:49

1 Answer 1

Reset to default
0

The minimum MSS is controlled by the minimum IP datagram MTU of 576 bytes. Since TCP uses 40 bytes of overhead, then the minimum MSS is 536 bytes. If more bytes are used, say for timestamps, then the MSS would be smaller

This can be found in the IP RFC 791 Section 3.1. Internet Header Format - > Total Length.

Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams.

The number 576 is selected to allow a reasonable sized data block to
be transmitted in addition to the required header information.  For
example, this size allows a data block of 512 octets plus 64 header
octets to fit in a datagram.  The maximal internet header is 60
octets, and a typical internet header is 20 octets, allowing a
margin for headers of higher level protocols.
Improve this answer
2
  • More correctly, TCP uses at least 20 bytes of overhead for its header, plus the IPv4 header of at least 20 bytes, or the IPv6 header of 40 bytes, so the minimum TCP and IP overhead is 40 bytes.
    – Ron Maupin
    Commented Jun 23, 2020 at 17:29
  • Yes, you are correct, I missed those details
    – Kevin
    Commented Jun 23, 2020 at 19:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .