On my wireshark trace I can see that SMB traffic is being sent across wire at 536 bytes with DF flag set to 1. I know the DF flag is set to 1, because Windows 2008 and above cannot deal with packets smaller than this, see this blog post: http://blogs.technet.com/b/nettracer/archive/2010/07/30/why-doesn-t-windows-2008-server-send-tcp-segments-smaller-than-536-bytes.aspx My question is why is the size being negotiated at 536 bytes for SMB when the MTU of the link is 1500? In the SYN\ACK requests for traffic, I can see the TCP Option Maximum Segment Size for a lot of communication is 1460 bytes (see here for more info on this: http://serverfault.com/questions/511299/determing-mss-value-on-windows-server) Can this reversion to the lowest MSS be caused by a lower MTU somewhere along the path? What else can explain this? See for example here: https://msdn.microsoft.com/en-us/library/cc558565(v=bts.10).aspx where this reversion to 536 bytes is discussed:
asked 08 Nov '15, 07:22  wshark_man_123 |
One Answer:
DF flag means "Don't Fragment". It's an instruction to routers or switches not do fragment this packet. In another word. the SMB server/client just want to be extra sure that the packets don't get fragmented on the path. It doesn't hurt to be extra cautious, does it? Hope it helps. answered 08 Nov '15, 07:27  pktUser1001 showing 5 of 6 show 1 more comments |
Thanks for the reply.
I know why the DF flag is set (that was discussed in my question), Windows sets it because, as the blog post I reference mentions, it cannot deal with packets smaller than this.
My question was WHY is the packet being sent at the minimum possible MSS when the MTU of the link is 1500?
What is causing the negotiation of a 536 MSS?
I would expect the traffic for a large SMB transfer to be sent in 1460 byte chunks? Or is this not the case?
So you are saying the MSS from both SYN and SYNACK packets are 1460 but the max data size in this session is only 536. I guess it could be some configuration on either the client or the server side? I have a pcap on SMB and data in some TCP packets are indeed 1460 (occurred during downloading a big file). I think the issue where your TCP data size is smaller than optimum is not related to the DF bit in IP header. Thx.
Thanks. Yes the DF is there because this is the smallest packet Windows 2008 and above accept, so packets of this size have the DF flag set. See the blog post I referenced that discussed this http://blogs.technet.com/b/nettracer/archive/2010/07/30/why-doesn-t-windows-2008-server-send-tcp-segments-smaller-than-536-bytes.aspx.
I have captured some other SMB traffic from different locations and can see 1460 bytes on the wire.
I am going to play with MTU values and see if there is this odd reversion to 536.
Good luck to you. Curious to know the root cause. Please keep us posted on what you find out.
Did you take the captures at both ends of the session. Maybe it helps.
The DF is set for all IPv4 datagrams (not used in IPv6 because there is no DF field) to prevent fragmentation so that we can determine the path MTU using ICMP messages.
What are the operating systems involved ? Are they in same LAN or do you access the target on a remote network?
You could also use ping to determine the MTU manually to see whether you can send above 567 bytes without causing fragmentation.