Is this normal behaviour when in the initial TCP connection, MSS value between client and server are different
for example (taken from a trace I captured)
client --> server MSS is 1460
server --> client MSS is 1342
If I understand correctly, If these values are different between client and server, does the lowest MSS value be used in the communication between client and server
thanks everyone for the info
I have an issue with clients connecting to Citrix servers - nothing changed on our network infrastructure, the internet connection and other network infrastructure (SD WAN/Router) are not managed by me but 3rd party. They have confirmed no changes done on their kit.
The connection over TCP fails but when using UDP works
If anyone is kind enough to have a quick look thru a capture file to see if the issue is with MTU/MSS
Please upload capture file(s) and share the link here. Preferable from both client and server side, to see if the MSS was changed in transit.
If you suspect a MTU/MSS issue, then you can test this with a machine with the MTU set very low, e.g. 1200. And raise it until the test fails.
Server side trace
https://drive.google.com/file/d/18n6t...
192.168.34.166 Client 10.240.77.0 Server
Also the RST,ACK is this sent by a firewall - or the client side terminating the connection
No need to be concerned. Somewhere in between the server and the client it appears the MTU has been adjusted. Typically due to some form of encapsulation which adds headers to the IP packet, or or manual manipulation of an MTU setting, decreasing the size of the MSS. I hope you can get to this URL - https://knowledgebase.paloaltonetwork...
Yes the MSS can be different. Either because the server was configured this way or a device in between performed 'TCP MSS clamping'.
The lowest value will be used by both sides.
The size of a TCP segment may not exceed the Maximum Segment Size. The MSS option is to tell the other side what the maximum size is it can receive.
When the MSS option is used by both server and client then the lowest value of both is the new maximum segment size (assuming the MTU path is symmetric). Using a higher value anyway is a violation of the protocol; it could work if the receiver is tolerant.
The goal of the MSS option is to avoid performance degradation (IP fragmentation) or communication failures (dropped packets; like the famous 'white screens' when using https).
Of course the sender may choose to send smaller segments any time.
Further reading: rfc9293
The MSS option in the SYN and SYN/ACK are advertisements, not a negotiation. This means that it is not true that the lowest value will be used by both sides. This is especially true when there are devices in the path that alter the MSS value in the SYN and/or SYN/ACK.
When a symmetric path is used and no MSS alterations are done in both directions, the result is that both systems will use the same segment sizes. This is because the side which sent the lowest MSS value will use this value itself of course (it is bound by its own limits). The side with the highest MSS value will use the received value.
When alterations are made to the MSS option and/or there is asymmetric routing (ver paths with different MTUs), then one side can end up using a MSS value that does not ...
While it is true that most of the time both systems will use the lower value, [RFC 879, "The TCP Maximum Segment Size and Related Topics, states, in Section 3, "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." So both systems using the lower value is not required.
RFC 879 has been obsoleted by RFC 9293.
RFC 9293 states:
Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
Thus the lowest value send or received must be used.
Only if the MSS was changed in transit in an asymmetric way it can be different between client and server.
Asked: 2022-12-28 11:11:23 +0000
Seen: 1,185 times
Last updated: Dec 29 '22
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
