Slow FTP-TCP connection on indirect routes - MSS always 536 Bytes

[CorderBollie]

Hello.

I'm running MQX 4.1.1 and a FTP server is running on a MQX device behind a router. The devices IP address is 192.168.1.100. The router has a public IP address and port forwards FTP requests to the MQX device.

When a connection is established from outside the local network the FTP servers accepts the connection but advertises a window size of 512 Bytes whereas the maximum segement size (MSS) is 536 Bytes. In my opinion the window size should be equal to or a multiple of MSS. However this is not critical.

The problem I have is that when the FTP server opens the active connection to the connected client it always advertises a MSS of 536 Bytes although the ENET interface is setup for a MTU of 1500 bytes.

I tracked down the problem to the function IP_MTU (called form tcp.c->TCP_Process_packet) that determines the correct MTU size depending on the route type of the connection.

I seems like there are three types (DIRECT, INDIRECT, VIRTUAL) however if the route type is indirect the method always returns the default MTU of 576 Bytes.

In my case the route type is INDIRECT but IP_MTU does not handle that case, instead returns a MTU of 576 Bytes.

In tcp.c (TCP_Process_packet) the return value is evaluated (see code below)

if ( tcb->remote_host == INADDR_ANY ) {

  tcb->remote_host = source;

  tcb->rcvmss = IP_MTU(tcb->local_host, source)

  - (uint_16) (IP_HEADSIZE + TCP_HEADSIZE);

  if (tcb->sndmss > tcb->rcvmss) {

  tcb->sndmss = tcb->rcvmss;

  }

  tcb->sndmax = tcb->sndmss;

  } /* Endif */

Here tcb->sndmss (which is 1400 bytes) is greater than the reported tcb->rcvmss (536 bytes) and this results in advertising a window size of 536 Bytes and MSS of 536 bytes. This slows down the transfer rate.

Is this behaviour correct or should IP_MTU return the ethernet interfaces MTU of 1500 even if the route type is INDIRECT?

[CorderBollie]

Found this in RFC 1191 (p.5):

...Actually, many TCP implementations always send an MSS option, but set

  the value to 536 if the destination is non-local. This behavior was

  correct when the Internet was full of hosts that did not follow the

  rule that datagrams larger than 576 octets should not be sent to

  non-local destinations. Now that most hosts do follow this rule, it

  is unnecessary to limit the value in the TCP MSS option to 536 for

  non-local peers.

  Moreover, doing this prevents PMTU Discovery from discovering PMTUs

  larger than 576, so hosts SHOULD no longer lower the value they send

  in the MSS option....

I will give it a try and also return the ENET devices MTU for indirect routes.

[RadekS]

Thank you for issue report.

I reported it to designers team and they will analyze that.

In case of confirmation obsolete behavior of MTU, code will be changed in one of next MQX releases.

Just for sure, did you enable VLAN support in RTCS by RTCSCFG_LINKOPT_8021Q_PRIO definition?

#define RTCSCFG_LINKOPT_8021Q_PRIO            1

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[CorderBollie]

No, RTCSCFG_LINKOPT_8021Q_PRIO is not enabled. Do you expect an other behaviour when this option is set?

[RadekS]

This issue was solved by RTCS change where we follow RFC 6691. According this RFC, RTCS will send TCP MSS option as the MTU (of the local interface) decreased by the size of fixed IP and TCP headers.

Resolution: Removed 536 bytes limit for TCP MSS option for connections to indirect networks. TCP MSS for non-local peers is set to MTU of local interface minus fixed size TCP header minus fixed size IP header.

Change will be applied in next MQX release, probably MQX4.2.