PMTU shows as off!

Scoot · Post by **Scoot** » Wed Mar 28, 2001 1:26 pm

TCP options string = 020405b001010402

MTU = 1496
MTU is fully optimized for broadband.

MSS = 1456
Maximum useful data in each packet = 1456, which is equal to MSS.

Default Receive Window (RWIN) = 37000
RWIN Scaling (RFC1323) = 0 bits
Unscaled Receive Window = 37000
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
512512 (MSS x 44 * scale factor of 8)
256256 (MSS x 44 * scale factor of 4)
128128 (MSS x 44 * scale factor of 2)
64064 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 1480 kbps (185 KBytes/s) @ 200ms
Your RcvWindow limits you to: 592 kbps (74 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = OFF

Time to live left = 119 hops
TTL value is ok.

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 00000000

59373 connections tested since 03-10-2001, 14:30 ET
Analyzer version: Beta 0.94
Here is my registry:
REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"LocalCopyMade"="1"
"EnableDNS"="1"
"Lanabase"="0"
"MaxDupAcks"="1"
"DefaultMSS"="1436"
"AllowATM"="1"
"GlobalMaxTcpWindoSize"="522680"
"SackOpts"="1"
"MaxMSS"="1460"
"MaxMTU"="1500"
"LMHostFile"="C:\\WINDOWS\\lmhosts"
"Tcp1323Opts"="2"
"DefaultRcvWindow"="37000"
"PMTUDiscovery"="1"
"DefaultTTL"="128"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params\AllowATM]
"ParamDesc"="Allow Binding To ATM"
"default"="0"
"type"="enum"
@="0"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params\AllowATM\enum]
"0"="No"
"1"="Yes"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\ATMDefaults]
"ARPServerList"="4700790001020000000000000000A03E00000200"
"MARServerList"="4700790001020000000000000000A03E00000200"
"SapSelector"=hex:01,00,00,00
"MTU"=hex:dc,23,00,00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters]
"BSDUrgent"="0"
"TcpTimedWaitDelay"=dword:00000000
"MaxDupAcks"=dword:00000002

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters\Winsock]
"MaxSockAddrLength"=hex:10,00,00,00
"MinSockAddrLength"=hex:10,00,00,00
"HelperDllName"="%windir%\\system\\wsock32.dll"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\ServiceProvider]
"LocalPriority"=hex:05,00,00,00
"HostsPriority"=hex:06,00,00,00
"DnsPriority"=hex:07,00,00,00
"NetbtPriority"=hex:08,00,00,00
"Class"=hex:08,00,00,00
"ProviderPath"="%windir%\\system\\wsock32.dll"

Why does it show up on the tweak test as off???

Lobo · Post by **Lobo** » Wed Mar 28, 2001 1:31 pm

Whos patch is this and what have you done to it

Scoot · Post by **Scoot** » Wed Mar 28, 2001 1:36 pm

I have uninstalled all the patches I ever used and manually set it up. My speed are great. The RWIN could probably be a little higher but I get over 2500 down.
@home cable
My up is capped at 128
I found with the real high RWIN that I get really bad download speeds. They start out high and drop fast.
I just want to know why my registry shows PMTU on (1) and the tweak test shows it off??

Lobo · Post by **Lobo** » Wed Mar 28, 2001 1:41 pm

Looks like you did not know also that RWIN and Globalmax should be the same, Tcp1323 Opts needs to be a 1 or 3, do this to turn on MTU:
Please go to:www.dslreports.com/front/drtcp.html
Download DR. TCP to your desktop
Where it saids adapter settings, select your adapter
Where it says Windows sclaing- yes
Where it says Selective Acks-yes
Path MTU Discovery - yes
Black Hole Detection - No
TTL-64 or 32 (up to you) No affect on speed.

Where it says Time Stamping, no
click apply
Reboot for changes to take affect

Do not change any numbers in this box unless you know what you are doing.
A blank box only means that the default setting is being used

Scoot · Post by **Scoot** » Wed Mar 28, 2001 2:04 pm

Dr.TCP says it is on.
Tried changing values to the same in registry as you said.
Same result. Could something like a router on the internet be masking it?
HUH, confusing.
Thanks

Lobo · Post by **Lobo** » Wed Mar 28, 2001 2:10 pm

I have seem alot of registies but none quite like yours, Cablenut has new patch out and not the big RWIN, normal cable 102200, fast cable 204400, I think doing this would be your best best ashis patch would take your registry back to default first, here's how:
First go to www.cablenut.com , click on software at top of page
Download 4.0 (Only users of WIN 95 and WIN ME need 4xx to 4.02 too along with 4.0 )
His patch will uninstall previous patchs
Install 4.0 (If running WIN 95 or WIN ME Install 4xx to 4.02 too)
(NOTE) If you are running WIN 98 or SE, you need to download and install Vtcp386 for patch for 4.0 to work.
Then on desktop click on cablenut 4.0
Click on ccs files
then click on cable, PPPoE or 56K
Select either normal cable or fast cable (See instructions)
this will enter settings
click on save to registry at bottom, reboot or it will not work.

If you decide to remove Cablenut's patch, use uninstaller in Cablenut 4.0 folder on desktop. This will take you back to Windows default.
Retest and repost so I can see if patch is in Copy all this by highlighting everything in box with mouse
(you may have to make box smaller. To copy contents of box, highlight, then hit Ctrl & c, on your keyboard, when you return to Speedguide in reply box, with cursor blinking, hit Ctrl & v, this will copy contents in box so I may look at it. Thank you.
Click on Cablenut 4.0 on desktop, RIGHT click on adjuster and select short cut to desktop, the same with Reboot.

CHECK BACK FOR UPDATES
Would not be bad idea to bookmark this page so you can return for updates or reading.

rmrucker · Post by **rmrucker** » Wed Mar 28, 2001 10:43 pm

Scoot, you are not the worst, but you definitely are a finalist in the most screwed up Registry!

The following are not correct:

"MaxDupAcks"="1"
"DefaultMSS"="1436"
"MaxMSS"="1460"
"MaxMTU"="1500"
"GlobalMaxTcpWindoSize"="522680"
"BSDUrgent"="0"

They should all be deleted. They are doing NOTHING for you. Most of them are even listed in the WRONG keys.

Next you are likely using a router or hub or other device that is turning OFF your PMTUD.

[ 03-28-2001: Message edited by: rmrucker ]

cablenut · Post by **cablenut** » Thu Mar 29, 2001 2:47 am

I agree with rmrucker on this one..

dannjr · Post by **dannjr** » Thu Mar 29, 2001 3:20 am

I go along with rmrucker and cablenut...
rmrucker when are you gonna change that sig to rfc rucker just a thought..

rmrucker · Post by **rmrucker** » Thu Mar 29, 2001 9:56 am

I tried to change my name, but SpeedGuide won't let me! I was told that option was not available. (At least not without losing my "Advanced" status!)

Scoot · Post by **Scoot** » Thu Mar 29, 2001 11:49 am

If you mean using a router or hub from my house, no go. I have one pc through @home with ZA as a firewall. No hardware externals at all.
If you mean somewhere in cyberspace please explain as I do not understand how this is turning it off??
I deleted those keys and used DrTCP to set my RWIN and PMTU. I have tried both normal and fast win98 cablenut patches and they decreased my speeds to under 1000 down on the speed test at Dslreports. With the settings as this reg file shows I get 2500 down and 125 up. I am satisfied with my speed, It is just driving me nuts to have PMTU show up as off when my registry shows it as on! Web pages all load fast except DslReports??? Everywhere else is fine. Anyone else experience show pages at that site?
Anyway, thanks for taking the time to help fellas!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"LocalCopyMade"="1"
"EnableDNS"="1"
"Lanabase"="0"
"HostName"="xxxxxxxxx-a"
"Domain"="xxxxxxxxxx"
"SearchList"="xxxxxxxxxxxx"
"NameServer"="xxxxxxxxxxxx"
"AllowATM"="1"
"SackOpts"="1"
"LMHostFile"="C:\\WINDOWS\\lmhosts"
"Tcp1323Opts"="1"
"DefaultRcvWindow"="37000"
"PMTUDiscovery"="1"
"DefaultTTL"="128"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params\AllowATM]
"ParamDesc"="Allow Binding To ATM"
"default"="0"
"type"="enum"
@="0"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params\AllowATM\enum]
"0"="No"
"1"="Yes"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\ATMDefaults]
"ARPServerList"="4700790001020000000000000000A03E00000200"
"MARServerList"="4700790001020000000000000000A03E00000200"
"SapSelector"=hex:01,00,00,00
"MTU"=hex:dc,23,00,00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters]
"BSDUrgent"="0"
"TcpTimedWaitDelay"=dword:00000000
"MaxDupAcks"=dword:00000002
It recreated this key?

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters\Winsock]
"MaxSockAddrLength"=hex:10,00,00,00
"MinSockAddrLength"=hex:10,00,00,00
"HelperDllName"="%windir%\\system\\wsock32.dll"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\ServiceProvider]
"LocalPriority"=hex:f3,01,00,00
"HostsPriority"=hex:f4,01,00,00
"DnsPriority"=hex:d0,07,00,00
"NetbtPriority"=hex:d1,07,00,00
"Class"=hex:08,00,00,00
"ProviderPath"="%windir%\\system\\wsock32.dll"

rmrucker · Post by **rmrucker** » Thu Mar 29, 2001 4:03 pm

Gotcha. You may be going through a Proxy - like dannjr. says. Check out the FAQ's here and see how to disable this.

Then, run the Tweak Tester at dslreports: http://www.dslreports.com/tweaks

The bottom line is this: if the dlsr tweak tester shows your MTU up and down is 1496, then something OTHER than your machine is turning off PMTUD.

Scoot · Post by **Scoot** » Thu Mar 29, 2001 7:25 pm

Ok Dan and R2,
The tweakser at dslreports is offline.
I did as you said.
TCP options string = 020405b00103030001010402

MTU = 1496
MTU is fully optimized for broadband.

MSS = 1456
Maximum useful data in each packet = 1456, which is equal to MSS.

Default Receive Window (RWIN) = 64240
RWIN Scaling (RFC1323) = 0 bits
Unscaled Receive Window = 64240
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
512512 (MSS x 44 * scale factor of 8)
256256 (MSS x 44 * scale factor of 4)
128128 (MSS x 44 * scale factor of 2)
64064 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 2569.6 kbps (321.2 KBytes/s) @ 200ms
Your RcvWindow limits you to: 1027.84 kbps (128.48 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = OFF

Time to live left = 114 hops
TTL value is ok.

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 00000000

Scoot · Post by **Scoot** » Thu Mar 29, 2001 7:28 pm

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"LocalCopyMade"="1"
"EnableDNS"="1"
"Lanabase"="0"
"HostName"="xxxxxxx"
"Domain"="xxxxx"
"SearchList"="xxxxxxx"
"NameServer"="xxxxxxxx"
"AllowATM"="1"
"SackOpts"="1"
"LMHostFile"="C:\\WINDOWS\\lmhosts"
"Tcp1323Opts"="1"
"DefaultRcvWindow"="64240"
"PMTUDiscovery"="0"
"DefaultTTL"="128"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params\AllowATM]
"ParamDesc"="Allow Binding To ATM"
"default"="0"
"type"="enum"
@="0"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\params\AllowATM\enum]
"0"="No"
"1"="Yes"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Ndi\ATMDefaults]
"ARPServerList"="4700790001020000000000000000A03E00000200"
"MARServerList"="4700790001020000000000000000A03E00000200"
"SapSelector"=hex:01,00,00,00
"MTU"=hex:dc,23,00,00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters]
"BSDUrgent"="0"
"TcpTimedWaitDelay"=dword:00000000
"MaxDupAcks"=dword:00000002

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\Parameters\Winsock]
"MaxSockAddrLength"=hex:10,00,00,00
"MinSockAddrLength"=hex:10,00,00,00
"HelperDllName"="%windir%\\system\\wsock32.dll"

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\ServiceProvider]
"LocalPriority"=hex:f3,01,00,00
"HostsPriority"=hex:f4,01,00,00
"DnsPriority"=hex:d0,07,00,00
"NetbtPriority"=hex:d1,07,00,00
"Class"=hex:08,00,00,00
"ProviderPath"="%windir%\\system\\wsock32.dll"

rmrucker · Post by **rmrucker** » Thu Mar 29, 2001 7:40 pm

The Tweak Tester at SpeedGuide is not able to measure Upload packet size. That will be the key to telling us if your computer believes PathMTU Discovery is ON or OFF. You have to test it at dslr. The Tweak Tester there is still relatively new and is being adjusted daily -- so it is down quite often -- but it will be back.

Be sure to turn your PathMTU Discovery ON before you test it there...

Also, were you able to find the Proxy information in the FAQ's? If not, I'll dig them up.

Scoot · Post by **Scoot** » Thu Mar 29, 2001 7:57 pm

No, I did not look at the faq. I just made sure no proxy was inabled under lan settings in my browser. I have never had @home software on my puter.
Explain to me what kind of proxy you mean?
I thought Dan said not to have Pmtu turned on?
I guess I will change it back. Do I need to keep manually playing with my registry or is DRTcp ok.
The rest of the key's look ok.
Thanks R2
Rocktagon
hehe

rmrucker · Post by **rmrucker** » Thu Mar 29, 2001 8:12 pm

Rock- Don't worry -- I knew all along who you were/are!

Yup, that is the right Proxy stuff -- I was trying to save my time by not explaining it.

Dan did say that, but SPECIFICALLY for testing at dslr, turn it ON so I can see what the upload packet size is!!

R2

Scoot · Post by **Scoot** » Thu Mar 29, 2001 8:14 pm

Ok, I read the faq at Dslreports if that is what you meant. I tried entering both .dll entries in the run box and got a load error.
No @home software.
Got the tweaktester to work.
I will post the linkhttp://monitor.dslreports.com/tweak/block:37cdd;805a5a29feee7c67489ec7f49a61d983;1.1;www.dslreports.com.

Scoot · Post by **Scoot** » Thu Mar 29, 2001 8:19 pm

Hope you can figure out how to paste that..hehe
Why doesn't this test show if your PMTU is on?
There is a lot of stuff there. I don't understand it.
I used to have all the tests show fine and would download over 600K but things have slowed to 200+K.
The only real change would be the PGP encryption software installed a VPN adaptor in my network settings. It is for secure sharing. I havn't used it but may in the future. Could this being causing this?
EDIT:
Ok I found it http://monitor.dslreports.com/tweak/block:37cdd

[ 03-29-2001: Message edited by: Scoot ]

rmrucker · Post by **rmrucker** » Thu Mar 29, 2001 9:13 pm

OK, that clinches it. The Upload packet size is here:
Max size packet recd: 1496

You can in NO way get a packet that size if your Registry is set with PathMTU Discovery OFF. Give it a try. Set this key: "PMTUDiscovery" to "0" -- and retest. You will see the upload packet size drop to 576. MSTCP requires this.

Justin's Tweak Tester II FAILS to mention if Path MTU Discovery is OFF. I have complained about this to him and Pinan to NO END, yet he refuses to budge. Initailly he DENIED it did this, and now I believe it is a pride thing -- or something equally silly.

The bottom line is that something OUTSIDE your usual registry settings is doing this. Your registry is correctly set with PathMTU Discovery ON.

I have NOT heard of PGP doing this -- and in fact I have PGP on this computer -- but there is no VPN Adapter... However, I have had VPN on this computer in the past and it never did it either. So, I don't think PGP/VPN are responsible.
_______________________________

How do the TCP/IP Analyzer and Tweak Tester determine if PMUTD is ON?? Quite simply they look for the "Don't Fragment" bit to be set in the IP header of the first packet you send them. If the bit is set, they report PMTUD is ON. If there is no bit there, they report PMTUD is OFF.

We have freqeuntly seen ROUTERS (eg, Netgear), PROXIES, and Satellite modems change these settings. In your case NONE of these is responsible. Is it possible that some other router "OUT THERE" is changing your DF (don't fragment) bit?

Anything is possible, I have just never seen it before. What if you run a ping test to monitor.dslreports.com with a buffer size of 1500?? What happens?

Scoot · Post by **Scoot** » Thu Mar 29, 2001 9:22 pm

Thank you speedguide.net GOD
Someone needs to give you that title

Appreciate the help,check your other IM also.
I will reset the PMTU to 0 and retest to prove your theory.
OOps-EDIT-I had forgoten the numbers

Looks like I am losing packets

Microsoft(R) Windows 98
(C)Copyright Microsoft Corp 1981-1999.

C:\WINDOWS\Desktop>ping -f -l 1464 www.dslreports.com

Pinging dslreports.com [209.123.109.175] with 1464 bytes of data:

Reply from 209.123.109.175: bytes=1464 time=94ms TTL=238
Request timed out.
Reply from 209.123.109.175: bytes=1464 time=117ms TTL=238
Reply from 209.123.109.175: bytes=1464 time=97ms TTL=238

Ping statistics for 209.123.109.175:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 94ms, Maximum = 117ms, Average = 77ms

C:\WINDOWS\Desktop>ping -f -l 1472 www.dslreports.com

Pinging dslreports.com [209.123.109.175] with 1472 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 209.123.109.175:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\WINDOWS\Desktop>ping -f -l 1468 www.dslreports.com

Pinging dslreports.com [209.123.109.175] with 1468 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 209.123.109.175:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\WINDOWS\Desktop>

[ 03-29-2001: Message edited by: Scoot ]

Scoot · Post by **Scoot** » Thu Mar 29, 2001 9:37 pm

Yup, here is with it off
Actual data bytes sent: 181040
Actual data packets: 124
Max size packet sent: 1500
Max size packet recd: 576
Retransmitted data packets: 24
sacks you sent: 24
pushed data pkts: 7
data transmit time: 2.169 secs
our max idletime: 545.2 ms
transfer rate: 56557 bytes/sec
transfer rate: 452 kbits/sec
This is not a speed test!
transfer efficiency: 80%
I reset my MaxMTU in DRTcp to blank for all adapters and will try the ping test again untill it fragments. I wonder if @home has been messing with things?

Scoot · Post by **Scoot** » Thu Mar 29, 2001 9:43 pm

Pinging dslreports.com [209.123.109.175] with 1472 bytes of data:

Reply from 209.123.109.175: bytes=1472 time=105ms TTL=238
Reply from 209.123.109.175: bytes=1472 time=103ms TTL=238
Reply from 209.123.109.175: bytes=1472 time=97ms TTL=238
Reply from 209.123.109.175: bytes=1472 time=96ms TTL=238

Ping statistics for 209.123.109.175:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 96ms, Maximum = 105ms, Average = 100ms
Well it looks like I should leave it at 1500 then. This used to fragment out at 1468.
Does it make any difference that I did the ping test with the PMTU off?
I'll be back...gonna turn it back on and reboot.
EDIT: http://monitor.dslreports.com/tweak/block:21215
Looks better huh?
EDIT-2
Except speed?
Test running..Downloaded 60900bytes in 3020ms
Downloaded 696000bytes in 7740ms
First guess is 719kbps
medium speed line - now test 1mb
Downloaded 1109250bytes in 11420ms
Upload got ok 1 bytes uploaded
Uploaded 1bytes in 880ms
Upload got ok 1 bytes uploaded
Uploaded 1bytes in 870ms
Upload got ok 1 bytes uploaded
Uploaded 1bytes in 930ms
Upload got ok 50000 bytes uploaded
Uploaded 50000bytes in 4340ms

** Speed 777(down)/115(up) kbps **
(At least 15 times faster than a 56k modem)
Logging result
Finish.

[ 03-29-2001: Message edited by: Scoot ]

[ 03-29-2001: Message edited by: Scoot ]

dannjr · Post by **dannjr** » Fri Mar 30, 2001 12:51 am

Ok I´m gonna go out on a limb here only because I´ve seen this profile in a couple of other connections...
Your probably on there proxy yes or cache server someplace in cyberspace.
set your Rwin to 64240
turn off PMTUDiscovery all together.
Take out GlobalTcpWindoSize all together
Tcp1323Opts should be 1
post the tweak test with your other results

Like I said I have only seen this on a few connections see what it does..

[ 03-29-2001: Message edited by: dannjr ]

rmrucker · Post by **rmrucker** » Fri Mar 30, 2001 9:08 am

Just got up. OK, that is strange. First, you can see that if your PMTUD is OFF in the registry (PMTUDiscovery = "0"), then MSTCP restricts the out-going packet size to 576.

So the fact that the Tweak Tester EVER shows your uploaded packet size OVER 576 proves that YOUR REGISTRY believes PMTUD is ON. So something ELSE is turning it OFF.

Again, ALL that "ON" means is that a little teeny, tiny bit has been set to "1" instead of "0" -- the "DF" bit. There is no other Magic involved.

So your packets are at least leaving your TCP layer with this bit set. The question becomes this -- is something else in your computer changing this bit to "0" or is there something out on the Internet that is doing it. The only way to know for sure is to download the Italian Packet Capture Analyzer and check what the DF bit looks like. You can get this from links on dannjr.'s site.

Now, what is strange is this: you ARE able to get packets OUT of your computer and on to the Internet with the IP "DF" bit set -- otherwise you could never get this message:

"Packet needs to be fragmented but DF set."

Got it? Nothing "out there" switched the DF bit in those packets. The DF bit STAYED at "1" for your ICMP ping tests.

NO, setting PMTUD in your registry has NO effect on your ICMP ping packets. The PMTUD setting is specifically for TCP/IP and pinging is done is ICMP. The "-f" in the ping command line is doing the same thing -- setting the DF bit.

Dropped or Timed Out packets usually represent problems in the route or routers on the Internet.