This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Traffic (SMB) sent across link at 536 bytes with DF flag set to 1? Why is traffic not sent in bigger chunks?

0

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:

The EnablePMTUBHDetect value governs whether TCP tries to detect black hole routers during the Path MTU (maximum transmission unit) discovery process. Enabling black hole detection increases the maximum number of times TCP retransmits a given segment. If the value of this entry is 1, TCP recognizes when it has transmitted the same segment several times without receiving an acknowledgement. It reduces the maximum segment size (MSS) to 536 bytes, and it sets the Don't-Fragment bit. If, as a result, receipt of the segment is acknowledged, TCP continues this practice in all subsequent transmissions on the connection.

asked 08 Nov '15, 07:22

wshark_man_123's gravatar image

wshark_man_123
6224
accept rate: 0%


One Answer:

0

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's gravatar image

pktUser1001
201495054
accept rate: 12%

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?

(08 Nov '15, 07:30) wshark_man_123

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.

(08 Nov '15, 07:39) pktUser1001

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.

(08 Nov '15, 07:46) wshark_man_123

Good luck to you. Curious to know the root cause. Please keep us posted on what you find out.

(08 Nov '15, 07:49) pktUser1001

Did you take the captures at both ends of the session. Maybe it helps.

(08 Nov '15, 10:09) Christian_R

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.

(11 Nov '15, 06:26) adasko
showing 5 of 6 show 1 more comments