This may be pretty similar to the question here, however, I think it was either in the wrong place, or it wasn't clear enough, so it hasn't got to the right audience. Thus, I have re-formulated it here:


The TCP Receive Window is the size of the buffer on the receiving end of a TCP connection. According to (RFC7323 - Section-1.1) the TCP standard has a 16-bit field to denote the size (2^16 = 65,536 Bytes max). However, this has been seen to limit performance in high latency networks (RFC7323). Thus, a field has been included in the TCP options/extensions called the "Window Scale" (RFC7323 - Section-2) in order to improve performance by increasing the Receive Window size by multiplying it by a scaling factor, thus Scaling Factor = 2 ^ Window Scaling Factor Value. So in essence the TCP Receive Window Size = TCP Receive Window Value * (2 ^ Window Scaling Factor Value) (Haven't fully understood how the scaling factor actually works, so this might not be entirely accurate).


The essence of this question is, according to RFC7323 - Section 2.1, it seems that the TCP stack implemented in different operating systems has a different default initial value. What is the default initial TCP Receive Window size in Android? Has it changed over the different versions?


RFC 7323 - https://tools.ietf.org/html/rfc7323

  • 3 close votes and 3 upvotes! Interesting case. – Firelord Feb 16 '16 at 14:31

I can answer you about TCP WINDOW SIZE and TCP WINDOWSCALE fields as they appear in the TCP header.

Initial TCP Window Size should be 0x3908 = 14600, at least it is what I found so far using several versions.

(On most Linux distro I've used it is exactly the double 0x7210 = 29200.)

Window Scale has different values depending on the version, older set it to 6, newer set it to 8, at least for what I experienced so far.

You can check both values with this app: https://play.google.com/store/apps/details?id=be.ac.ulg.mobiletracebox It will show you them in the first line 0: youraddress ... TCP::Window (0xXXXX) ... TCP::WindowScale (0xXX) Values are hexadecimal.

For Window Size use regular Syn probe.

For Window Scale use Window Scale probe.

(If no value is shown for Window, it should be the max (0xffff=65535). If your device is rooted you should set mode to server based.)

PS I don't know if talking about an app is OK here, if not I'm more than willing to edit my comment.

  • Um. That sounds reasonable, but tracebox looks like a tracing tool? Is there a way to double-check I'm looking for the values that apply to my device, as opposed to the server I'm running the app against? – sourcejedi Feb 17 '16 at 18:56
  • 1
    It's a tool about tracing modifications on your packets. It shows the packet sent and how it is received at tracebox server. Then if it shows a certain value for the sent packet and doesn't show any modification on that value on the received packet, it's quite probable that value shown is the actual value. – the structure Feb 17 '16 at 19:04
  • Um again. Do you mean it shows the reply received by the device? That would make perfect sense, it's just not how I interpeted that explanation at first. I can't think of any other way tracebox could know what the packet looked like, when it was received at tumblr.com (second screenshot on the app page). – sourcejedi Feb 17 '16 at 19:30
  • 1
    It has two modes. One is like an enhanced traceroute and you choose the destination (tumblr.com for example) but unfortunately it needs root and doesn't help our case. The other is with the help of a server: the app sends a packet to server that sends it back as it has been received. – the structure Feb 17 '16 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.