OK, this post is not for everyone! If you have not been following this all along, this post will either bore the hell out of you, or give you the worst headache of you life. Read on if you wish, but you have been fore-warned!!

~~~~~~~

My Set up: Win98SE, capped Cable 512/128, no ICS

My Registry:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"LMHostFile"="C:\\WINDOWS\\lmhosts"
"LocalCopyMade"="1"
"EnableDNS"="0"
"Lanabase"="0"
"PreloadHeapCount"="6"
"DefaultTTL"="128"
"PMTUDiscovery"="1"
"SackOpts"="1"
"DefaultRcvWindow"="127424"
"PMTUBlackHoleDetect"="0"
"Tcp1323Opts"="3"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters]
"MaxDupAcks"=dword:00000003

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0003]
"MaxMTU"="1500"
"MaxMSS"="1200"

~~~~~~~~~

OK, let me make some guesses here and see if I am right. Based *only* on the above numbers, here are my guesses:

1) SYN packet window field = 127424 mod 65536 = 61888 => 0xF1C0

Alternatively, this could be figured out in Hex:

127424 => 0x1F1C0; lower 16-bits are "F1C0" => 61888

2) MSS = MaxMTU - 40 => 1500 - 40 = 1460 => 0x05B4

3) Scaling bit(s):

127424/65535 = 1.944... [Rounds up to 2 - the next highest power of 2]
log 2 / log 2 = 1 [=> Scaling bits = 1]

3) ACK packet window field:

{I am only POSITIVE about how to do this in binary - there is probably an easier way}

127424 => 1 11110001 11000000

Shift this over by the number of scaling bits:

11111000 11100000 => 63712 => 0xF8E0

Also, since the 'terminal bit' that I dropped above was a "0", I know ahead of time that the true "scaled" initial receive window will be *exactly* the same as my set RWIN!

*OK, lets look at the data!

~~~~~~~~

Packet sniffer (sniffing the dslrepeort Tweak test:

SYN Packet: (both IP and TCP Headers)

45 00
00 40 5E 00 | 40 00 80 06 | 66 CC D8 CF | CF 58 XX XX
XX XX 04 0E | 1F 93 00 09 | 71 45 00 00 | 00 00 B0 02
F1 C0 79 64 | 00 00 02 04 | 05 B4 01 03 | 03 01 01 01
08 0A 00 00 | 00 00 00 00 | 00 00 01 01 | 04 02

SYN,ACK Packet: (TCP Header)

1F 93 | 04 0E CF 2E | 74 33 00 09 | 71 46 80 12
16 D0 49 FA | 00 00 02 04 | 05 B4 01 01 | 04 02 01 03
03 00


"ACK" Packet: (TCP Header)

04 0E | 1F 93 00 09 | 71 46 CF 2E | 74 34 50 10
F8 E0 A8 B4 | 00 00

The "Packet after the ACK Packet" (i.e., first data transmitted):

04 0E | 1F 93 00 09 | 71 46 CF 2E | 74 34 50 10
F8 E0 A3 00 | 00 00 (followed by exactly 1460 bytes of data!)

~~~~~~~

OK, what did I find...

In the SYN packet:

1) The 02 before the window field shows that this is flagged only with "SYN".
2) The 'advertised' window size was as I calcuated: F1C0 => 61888
3) The MSS was as I calculated: 05B4 => 1460
4) The scale bit was as I calculated it: 1

In the SYN,ACK packet:

1) Flags at 12 = SYN and ACK are set
2) Window request from dslreports is as it always is, but this is ignorred.
3) This packet's main purpose (for us) is to verify that the computer we are connecting to *is* RFC1323 compliant. We can tell this because the TCP header shows a window scale factor request -- the 030300 above! IF it was not RFC1323 compliant, this would not be present.

In the "ACK" packet:

1) Flag at 10 = only ACK set
2) Window field is exactly as I calculated: F8E0 => 63712
3) There is no TCP options line in the ACK packet

In the "NEXT" packet:

1) All of the subsequent packets asked to be ACKnowledged
2) We see that the ACK packet window request WAS accepted (F8E0)
3) The TCP header SEEMS to have stayed the EXACT SAME size - 20 bytes!
4) The data that follows is EXACTLY my "MSS" size - 1460 bytes.

~~~~~~

OK, what does this mean to me?

1) The initial receive window size will NOT be based on the SYN packet window field, but instead on the "ACK" packet window field. What will it be?

63712 * 2^1 = 127424 (My set RWIN!)

2) The MSS will be set at MTU - 40 by MSTCP no matter what Tcp Options you set and no matter what value you enter into "MaxMSS".
3) I have yet to demonstrate how the TSopt and SackOpts effect the Tcp Header and the ultimate size of your data -- but I am not sure I have done the correct test! I plan to look into this further...


~~~~~~

OK, just to take this FULL circle, let's look at the Tweak test results. But first, let me GUESS how they will turn out -- and I'll show you how. I'll grab the SYN packet from above:

45 00
00 40 5E 00 | 40 00 80 06 | 66 CC D8 CF | CF 58 XX XX
XX XX 04 0E | 1F 93 00 09 | 71 45 00 00 | 00 00 B0 02
F1 C0 79 64 | 00 00 02 04 | 05 B4 01 03 | 03 01 01 01
08 0A 00 00 | 00 00 00 00 | 00 00 01 01 | 04 02

1) 40 is in the Flag area of the IP header. This says "Don't Fragment", so the Tweak test will tell me my PMTU-Disc. is "ON".
2) 80 is in the TTL area of the IP header (0x80 => 128). I should use up about 10 hops, so I should have about 118 left over.
3) My IP address is grabbed out of the IP header as well! I X'd it out!
4) The tweak test will erroneously scale my SYN packet window field, so...

F1C0 => 61888 -- 'scaled' up: 61888 * 2^1 => 123776

5) The Tweak test should find my MSS as 05b4, my scaling bit(s) at "1", Timestamping and SACK are "ON".

And here you go:

~~~~~~

Tweak test result:

* Results
* Your public IP address is (none of your business)
Hops left before discard (TTL) is 119
TCPopts hex string is 020405b4010303010101080a000000000000000001010402
Max Segment Size is 1460
* Your MTU is set ok
Window Scaling 1 bits (RFC1323)
TSOPT - time stamp option (RFC1323)
SACK Permitted (RFC2018)
Ping stability 120 90 92 90 89 102 89 91 90 89
* Quick packet-loss tested ok
Scaled DefaultRcvWindow (RWIN) is 123776
Your RWIN limits you @94.2ms to 10511kbps
Your RWIN limits you @200ms to 4951kbps
* Your RWIN is advertised as 123776 (scaling is on)
(Beyond 65k, advertised RWIN is scaled)
Your Path MTU Discovery is ON
Max sized data packet from you 1500
* Conclusion.. HEALTHY SETUP!
* End

~~~~~~

Everybody on the same page now??

Your comments and alternative interpretation is welcome. Cheers!

[This message has been edited by rmrucker (edited 11-16-2000).]