Can not enable MTU discovery

Get help and discuss anything related to tweaking your internet connection, as well as the different tools and registry patches on the site. TCP Optimizer settings and Analyzer results should be posted here.
Post Reply
endezeichen
New Member
Posts: 15
Joined: Sun Dec 31, 2006 12:10 am

Can not enable MTU discovery

Post by endezeichen »

Hey everyone, I've been trying to tweak my connection for the past 3 hours. I'm a newbie to say the least. After reading for 2 hours I ended up using an RWIN caculator to change my RWIN. I then finally stumbled upon TCP optimizer and noticed it had a preset RWIN for my connection (supposedly 10mbps). I was trying to think of how it determined that number before running any tests and couldn't figure it out. Needless to say, I kept the RWIN from my own calculations and just let TCPopt optimize everything else. TCP opt suggested 513920 opposed to my calculation of 271250, which TCP opt helped me calculate so idk. OH YEAH... my problem :) My MTU discovery was turned off by default so I edited the registry and got it working. Problem is, it only works when I'm not using my router, and I don't think it can be enabled through the router setup. I was talking to a rep on linksys online chat and explained the situation about the MTU discovery and RWIN and of course, she was like "huh?". What do I do as far as that problem goes? Also, feel free to check out my tweeks and point me in the right direction.

« SpeedGuide.net TCP Analyzer Results »
Tested on: 12.31.2006 00:19
IP address: 70.44.xx.xxx

TCP options string: 020405b40103030301010402
MSS: 1460
MTU: 1500
TCP Window: 271560 (multiple of MSS)
RWIN Scaling: 3
Unscaled RWIN : 33945
Reccomended RWINs: 64240, 128480, 256960, 513920
BDP limit (200ms): 10862kbps (1358KBytes/s)
BDP limit (500ms): 4345kbps (543KBytes/s)
MTU Discovery: OFF
TTL: 52
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

Speed Test
1282 kbps down (~1.28 Mbps, 157 KB/s) ↓
228 kbps up (~0.23 Mbps, 28 KB/s) ↑
Details:

3072 KB downloaded in 19.625 seconds
500 KB uploaded in 17.953 seconds
Speed @ 52% of the average for haw.ptd.net
24 times faster than 56k dialup
Tested on: 2006.12.31 00:38 EST
Tested from: http://www.123facts.com
Test ID: Y7GHAXKJF04
User Test History: User Stats
Browser/OS: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
IP Address: 70.44.30.133
Latency: 69ms
Provider: haw.ptd.net
Location: US

Is it just me or does that say I use Windows NT? I use XP. Maybe I'm just reading it wrong. Anyway, pretty pitiful for a 10mbps connection. Any suggestions? Thanks
User avatar
trogers
SG VIP
Posts: 12323
Joined: Wed Jan 26, 2005 11:14 pm
Location: Bangkok, Thailand

Post by trogers »

Do this nitro test and post the report under the 'Statistics' button:

http://nitro.ucsc.edu/
endezeichen
New Member
Posts: 15
Joined: Sun Dec 31, 2006 12:10 am

Post by endezeichen »

WEB100 Enabled Statistics:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client-to-server [C2S]) . . . . . 150.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 2.70Mb/s

------ Client System Details ------
OS data: Name = Windows XP, Architecture = x86, Version = 5.1
Java data: Vendor = Sun Microsystems Inc., Version = 1.5.0_10

------ Web100 Detailed Analysis ------
Cable modem/DSL/T1 link found.
Link set to Full Duplex mode
Information: throughput is limited by other network traffic.
Good network cable(s) found
Normal duplex operation found.

Web100 reports the Round trip time = 171.35 msec; the Packet size = 1460 Bytes; and
There were 31 packets retransmitted, 127 duplicate acks received, and 153 SACK blocks received
The connection was idle 0 seconds (0%) of the time
C2S throughput test: Packet queuing detected: 2.54%
S2C throughput test: Packet queuing detected: 2.15%
This connection is network limited 99.82% of the time.

Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgment: ON
RFC 896 Nagle Algorithm: ON
RFC 3168 Explicit Congestion Notification: OFF
RFC 1323 Time Stamping: OFF
RFC 1323 Window Scaling: ON

Server 'nitro.ucsc.edu' is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]
Packet size is preserved End-to-End
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client's IP address
Server says [70.44.30.133] but Client says [192.168.1.101]

hmmm... behind a firewall? I don't have a firewall installed and have xp fw off. Must be something with my router.
User avatar
trogers
SG VIP
Posts: 12323
Joined: Wed Jan 26, 2005 11:14 pm
Location: Bangkok, Thailand

Post by trogers »

endezeichen wrote:WEB100 Enabled Statistics:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client-to-server [C2S]) . . . . . 150.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 2.70Mb/s

------ Client System Details ------
OS data: Name = Windows XP, Architecture = x86, Version = 5.1
Java data: Vendor = Sun Microsystems Inc., Version = 1.5.0_10

------ Web100 Detailed Analysis ------
Cable modem/DSL/T1 link found.
Link set to Full Duplex mode
Information: throughput is limited by other network traffic.
Good network cable(s) found
Normal duplex operation found.

Web100 reports the Round trip time = 171.35 msec; the Packet size = 1460 Bytes; and
There were 31 packets retransmitted, 127 duplicate acks received, and 153 SACK blocks received
The connection was idle 0 seconds (0%) of the time
C2S throughput test: Packet queuing detected: 2.54%
S2C throughput test: Packet queuing detected: 2.15%
This connection is network limited 99.82% of the time.

Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgment: ON
RFC 896 Nagle Algorithm: ON
RFC 3168 Explicit Congestion Notification: OFF
RFC 1323 Time Stamping: OFF
RFC 1323 Window Scaling: ON

Server 'nitro.ucsc.edu' is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]
Packet size is preserved End-to-End
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client's IP address
Server says [70.44.xxx.xxx] but Client says [192.168.1.101]

hmmm... behind a firewall? I don't have a firewall installed and have xp fw off. Must be something with my router.
Test indicates background internet traffic during testing. Go into Windows 'Safe Mode' and scan and remove possible spyware/malware.

Round trip time of 171ms is slightly high from normal range of 90-130ms.

If firewall is not on, do a tracert to yahoo.com and check the state of your ping times, esp hop 1 and 2.
endezeichen
New Member
Posts: 15
Joined: Sun Dec 31, 2006 12:10 am

Post by endezeichen »

Here're 2 tracert results. The first one is with the router connected and second without. Both seem to be bad. Sorry for the big logfiles.

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\eddie>tracert yahoo.com

Tracing route to yahoo.com [66.94.234.13]
over a maximum of 30 hops:

1 * * * Request timed out.
2 12 ms 9 ms 9 ms 10.50.0.1
3 11 ms 32 ms 13 ms 216.144.186.14
4 29 ms 20 ms 14 ms 207.44.127.78
5 20 ms 28 ms 20 ms 12.119.12.69
6 21 ms 24 ms 22 ms 12.123.219.182
7 20 ms 22 ms 21 ms 12.123.0.89
8 22 ms 25 ms 20 ms 192.205.33.94
9 26 ms 22 ms 22 ms 4.68.97.161
10 100 ms 92 ms 93 ms 64.159.1.130
11 95 ms 91 ms 96 ms 4.68.123.141
12 93 ms 93 ms 95 ms 4.71.112.14
13 92 ms 92 ms 93 ms 216.115.106.211
14 95 ms 94 ms 94 ms 66.218.82.221
15 94 ms 92 ms 94 ms 66.94.234.13
Trace complete.

Tracing route to http://www.yahoo-ht2.akadns.net [209.73.186.238]
over a maximum of 30 hops:
1 8 ms 8 ms 6 ms 10.50.0.1.res-cmts.haw.ptd.net [10.50.0.1]
2 8 ms 6 ms 7 ms gateway-g0-1-019-hawblocal1.mlf.ptd.net [216.144
.186.14]
3 9 ms 10 ms 7 ms gateway2-g5-2-049-str2mlf.str.ptd.net [207.44.12
7.78]
4 17 ms 17 ms 18 ms nw2nj31ck4-pos2-0.att.net [12.119.12.69]
5 20 ms 19 ms 19 ms tbr1-p013902.n54ny.ip.att.net [12.123.219.129]
6 19 ms 17 ms 20 ms ggr2-p310.n54ny.ip.att.net [12.123.3.105]
7 17 ms 17 ms 18 ms 192.205.33.94
8 22 ms * * ae-32-54.ebr2.NewYork1.Level3.net [4.68.97.126]

9 36 ms * * ae-3.ebr2.Washington1.Level3.net [4.69.132.93]
10 24 ms 27 ms 24 ms ae-21-56.car1.Washington1.Level3.net [4.68.121.1
78]
11 26 ms 26 ms 28 ms 4.79.228.2
12 27 ms 26 ms 34 ms ge-2-1-0-p140.msr1.re1.yahoo.com [216.115.108.17
]
13 28 ms 27 ms 24 ms ge-1-41.bas-a2.re3.yahoo.com [66.196.112.201]
14 26 ms 25 ms 25 ms f1.http://www.vip.re3.yahoo.com [209.73.186.238]
Trace complete.

I ran spybot and adaware and found one trojan, which happened to be in the xp sp2 patch dl'ed from the developer's site. I also flashed both my router and modem and moved then about 4 feet away from my monitor and everything else. Again, I can't seem to enable MTU discovery on my router. Does that have anything to do with any of this?
I don't know how you do it trog.... all these numbers from all these people.... Any help is appreciated. Thanks again
User avatar
trogers
SG VIP
Posts: 12323
Joined: Wed Jan 26, 2005 11:14 pm
Location: Bangkok, Thailand

Post by trogers »

Your tracert with the router at hop 1 shows its firewall or ping blocking is turned on and causing the timed out. This is the reason the ntiro test reports the presence of a firewall.

You may need to reset your router to factory default by pressing the reset button at the rear of the router for a few seconds and then use the guide of this link to rerun a proper router setup:

http://www.hansenonline.net/Networking/Linksys101.html
endezeichen
New Member
Posts: 15
Joined: Sun Dec 31, 2006 12:10 am

Post by endezeichen »

Ok I reset my router and had a problem. Maybe I should have mentioned this before, but my router was not set to a static ip and still isn't. However, my ip did not change when I restarted my computer so is that still a problem? I tried to set up a static ip using a guide from the website you provided and did everything exactly as the directions told me. I think the problem was in the WAN ip address that my router required. I found a website that gave it to me and when I tried it I lost internet. The first ping is still timing out in tracert. It may be important to note that it's still timing out even when directly connected to the modem. Thanks again and sorry for all of this.
endezeichen
New Member
Posts: 15
Joined: Sun Dec 31, 2006 12:10 am

Post by endezeichen »

just an update here. I retweaked according to similar 10mbps connection posts. Speed is much worse but my tcp window is to the point where I would like it to be. Still having the ping problem with the router (timing out on first one) When connected to the modem it doesnt time out but is greater than 10ms. The router is set to accept WAN requests, there is no spyware, and absolutley no firewall. I even tried enabling DMZ host on the router to see if that would help. Here are a few new test results:

« SpeedGuide.net TCP Analyzer Results »

TCP options string: 020405b40103030201010402
MSS: 1460
MTU: 1500
TCP Window: 256960 (multiple of MSS)
RWIN Scaling: 2
Unscaled RWIN : 64240
Reccomended RWINs: 64240, 128480, 256960, 513920
BDP limit (200ms): 10278kbps (1285KBytes/s)
BDP limit (500ms): 4111kbps (514KBytes/s)
MTU Discovery: OFF
TTL: 52
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

This time I forwarded ports 3001-3003. Like an idiot, I didn't see the big red letters last time :)

WEB100 Enabled Statistics:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client-to-server [C2S]) . . . . . 244.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 130.91kb/s

------ Client System Details ------
OS data: Name = Windows XP, Architecture = x86, Version = 5.1
Java data: Vendor = Sun Microsystems Inc., Version = 1.5.0_10

------ Web100 Detailed Analysis ------
Cable modem/DSL/T1 link found.
Link set to Full Duplex mode
Information: throughput is limited by other network traffic.
Good network cable(s) found
Normal duplex operation found.

Web100 reports the Round trip time = 209.09 msec; the Packet size = 1460 Bytes; and
There were 17 packets retransmitted, 33 duplicate acks received, and 40 SACK blocks received
The connection stalled 3 times due to packet loss
The connection was idle 2.04 seconds (20.40%) of the time
C2S throughput test: Packet queuing detected: 2.59%
S2C throughput test: Packet queuing detected: 35.82%
This connection is network limited 99.9% of the time.
Excessive packet loss is impacting your performance, check the auto-negotiate function on your local PC and network switch

Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgment: ON
RFC 896 Nagle Algorithm: ON
RFC 3168 Explicit Congestion Notification: OFF
RFC 1323 Time Stamping: OFF
RFC 1323 Window Scaling: ON

Server 'nitro.ucsc.edu' is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]
Packet size is preserved End-to-End
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client's IP address
Server says [70.44.30.133] but Client says [192.168.1.101]


Something to do with dynamic ip?
User avatar
trogers
SG VIP
Posts: 12323
Joined: Wed Jan 26, 2005 11:14 pm
Location: Bangkok, Thailand

Post by trogers »

endezeichen wrote:just an update here. I retweaked according to similar 10mbps connection posts. Speed is much worse but my tcp window is to the point where I would like it to be. Still having the ping problem with the router (timing out on first one) When connected to the modem it doesnt time out but is greater than 10ms. The router is set to accept WAN requests, there is no spyware, and absolutley no firewall. I even tried enabling DMZ host on the router to see if that would help. Here are a few new test results:

« SpeedGuide.net TCP Analyzer Results »

TCP options string: 020405b40103030201010402
MSS: 1460
MTU: 1500
TCP Window: 256960 (multiple of MSS)
RWIN Scaling: 2
Unscaled RWIN : 64240
Reccomended RWINs: 64240, 128480, 256960, 513920
BDP limit (200ms): 10278kbps (1285KBytes/s)
BDP limit (500ms): 4111kbps (514KBytes/s)
MTU Discovery: OFF
TTL: 52
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

This time I forwarded ports 3001-3003. Like an idiot, I didn't see the big red letters last time :)

WEB100 Enabled Statistics:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client-to-server [C2S]) . . . . . 244.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 130.91kb/s

------ Client System Details ------
OS data: Name = Windows XP, Architecture = x86, Version = 5.1
Java data: Vendor = Sun Microsystems Inc., Version = 1.5.0_10

------ Web100 Detailed Analysis ------
Cable modem/DSL/T1 link found.
Link set to Full Duplex mode
Information: throughput is limited by other network traffic.
Good network cable(s) found
Normal duplex operation found.

Web100 reports the Round trip time = 209.09 msec; the Packet size = 1460 Bytes; and
There were 17 packets retransmitted, 33 duplicate acks received, and 40 SACK blocks received
The connection stalled 3 times due to packet loss
The connection was idle 2.04 seconds (20.40%) of the time
C2S throughput test: Packet queuing detected: 2.59%
S2C throughput test: Packet queuing detected: 35.82%
This connection is network limited 99.9% of the time.
Excessive packet loss is impacting your performance, check the auto-negotiate function on your local PC and network switch

Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgment: ON
RFC 896 Nagle Algorithm: ON
RFC 3168 Explicit Congestion Notification: OFF
RFC 1323 Time Stamping: OFF
RFC 1323 Window Scaling: ON

Server 'nitro.ucsc.edu' is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]
Packet size is preserved End-to-End
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client's IP address
Server says [70.44.xxx.xxx but Client says [192.168.1.101]


Something to do with dynamic ip?
The router should serve as a DHCP server issuing dynamic LAN IP addresses automatically.

Your connection stalled and has excessive packet losses.This is the reason for the slow speed. My guess is that you may have placed the router too near to your modem.
endezeichen
New Member
Posts: 15
Joined: Sun Dec 31, 2006 12:10 am

Back again

Post by endezeichen »

Thanks for all your advice thusfar trogers. Your advice was correct. Part of the problem, the packets being lost, was due to interference. I wasn't thinking about the computer in the other room with it's speakers on hehe. I removed the speakers and the packets improved considerably, but weird thing is the speed dropped from 2.79mbps to 2.5mbps even over a few tests with the nitro link. Results were consistant... very weird. Now, out of nowhere, the lost packets are appearing, just as bad as before. Theres nothing around the router or modem within 3 feet, including themselves. Anyway, I'm somewhat happy of the speed I've ahieved. Although it's nowhere near 10mbps as advertised, its above average for my area. I'm rated for 350kb/s in the speed test. If interference is the problem, I'm in a jam. Don't have much more room to spread things out. I just wish I new what the errors below were about. I did end up setting a static ip because DHTP was interfering with port forwarding. I don't see a way to make my WAN address and LAN address the same, and I believe that's what's causing the firewall problem as shown in green. I also have a feeling that not being able to enable MTU discovery path has a good deal to do with the rest.

Server 'nitro.ucsc.edu' is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]
Packet size is preserved End-to-End
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client's IP address
Server says [70.44.30.133] but Client says [192.168.1.136]
User avatar
trogers
SG VIP
Posts: 12323
Joined: Wed Jan 26, 2005 11:14 pm
Location: Bangkok, Thailand

Post by trogers »

endezeichen wrote:Thanks for all your advice thusfar trogers. Your advice was correct. Part of the problem, the packets being lost, was due to interference. I wasn't thinking about the computer in the other room with it's speakers on hehe. I removed the speakers and the packets improved considerably, but weird thing is the speed dropped from 2.79mbps to 2.5mbps even over a few tests with the nitro link. Results were consistant... very weird. Now, out of nowhere, the lost packets are appearing, just as bad as before. Theres nothing around the router or modem within 3 feet, including themselves. Anyway, I'm somewhat happy of the speed I've ahieved. Although it's nowhere near 10mbps as advertised, its above average for my area. I'm rated for 350kb/s in the speed test. If interference is the problem, I'm in a jam. Don't have much more room to spread things out. I just wish I new what the errors below were about. I did end up setting a static ip because DHTP was interfering with port forwarding. I don't see a way to make my WAN address and LAN address the same, and I believe that's what's causing the firewall problem as shown in green. I also have a feeling that not being able to enable MTU discovery path has a good deal to do with the rest.

Server 'nitro.ucsc.edu' is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]
Packet size is preserved End-to-End
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client's IP address
Server says [70.44.xxx.xxx] but Client says [192.168.1.136]
WAN address will be different from LAN address. WAN IP address is issued by your ISP when you reboot the modem in the format 70.44.xxx.xxx Have you power off your modem for a few minutes and reboot it? I have noticed your WAN IP address remained the same throughout this thread.

Unless you have paid extra and been issued a Static IP address by your ISP, i would have expected your WAN IP address to be different each time your reboot your modem.

When you set your router with DHCP function on, you can still set each comp connected to it with a static LAN IP address. You can follow the guide of this link on port forwarding and setting of static LAN IP addresses:

http://www.portforward.com/english/rout ... rindex.htm

I will try to Goggle over your problem of MTU Discovery being fixed at 'off' setting.
User avatar
trogers
SG VIP
Posts: 12323
Joined: Wed Jan 26, 2005 11:14 pm
Location: Bangkok, Thailand

Post by trogers »

A possible cause for your MTU Discovery to appear "off' is that your comp is not responding to ICMP pings. The Discovery mode functions by sending out a query ping and the other side would return a ICMP ping on Path MTU Discovery. Your router may be blocking out this ICMP ping and thus Discovery mode is not working as intended even though it has been turned on by TCP Optimizer.

Read this link for more info:

http://www.netheaven.com/pmtulist.html
ColPeters
New Member
Posts: 7
Joined: Wed Dec 27, 2006 4:24 am

Post by ColPeters »

Hi trogers,

I was just looking at the link you posted above, and what you say isn't quite correct. The site says that the ICMP type used for PMTU discovery isn't actually an ICMP ping (which is type 8) but another ICMP type. I don't know about other routers but my d-link dsl-502T only offers to block incoming 'pings' (this is i think set ON by default).
At least I hope so, it would be very disturbing if my (and other) routers were blocking all ICMP types and referring to them in general as "pings".
Worth looking into, thanks for your posts and links I'm learning HEAPS here !

Cheers
Col
Post Reply