OS and Software > Broadband Tweaks > Tweak Test MTU stuck on 1362?

Tweak Test MTU stuck on 1362?

Try connecting the computer directly to the modem (not going through the router). See what MTU you get.

BTW, the Tweak test is not stuck on 1362.

reply to Devistater
Also you should turn ON MTU discovery

said by 61999674:

---

Also you should turn ON MTU discovery

---

You can read up on Parth MTU Discovery here: »www.netheaven.com/pmtu.html

You should however leave it on/default. As for your MTU, check to make sure your MTU is set to the right number in the router and if that doesn't work check with Linksys for an updated version of firmware.
--
A slave to corporate America.

said by Lanik:

---

You should however leave it on/default. As for your MTU, check to make sure your MTU is set to the right number in the router and if that doesn't work check with Linksys for an updated version of firmware.

---

same problem with me with a netgear wireless mr814v2 router. router setting is @ 1492. NIC setting changed from blank to 1492 to no avail.

reply to Devistater
Some more updates. I've tried a number of things with the router and computer, still the test claims I'm at 1362. I went to this great page »AT&T Southeast Forum FAQ »How do I find my optimum MTU setting? on how to find out your MTU, and I pinged the router, I pinged myself, I pinged my internet IP, I pinged every IP that I could on a tracert from here to DSL reports, I pinged google, speakeasy, etc. All show I can send the proper MTU of 1492 (includes overhead). I just can't figure out where this 1362 is coming from. Anyone know what the address is for the test server? Is is speakeasy or dslreports? I'd like to try and ping it and see if I can get a packet out successfully.
Any more suggestions would be welcome.

reply to Devistater
Just for a note,

If you are also running ATT VPN software that will over ride the windows settings. Even if the router is set to 1492 it will only allow windows to connect around the 1300 to 1430 range. You will have to edit the registry for the ATT software in order to increase the MTU. Hope this helps.

I had this issue because I use the ATT VPN software, but it could span out to other brands as well.

reply to Devistater
Thanks for the idea, but no I'm not running any VPN software or VOIP or anything else like that. Just some computers hooked up to a router.

reply to Devistater
Contrary to popular belief, just because you can ping with an MTU of 1492 does not mean you can use TCP/IP with an MTU of 1492. If the Tweak Tester says your MTU is 1362, then your TCP/IP packets are using an MTU 1362. It isn't a problem with the Tester.

Also, if your MTU is 1362 then your PathMTUDiscovery is turned ON in your computer -- regardless of what result you see on the Tester.

No matter how much you think the router is set to 1492, my first guess is still going to be that the router is causing these issues. Take the router out of the connection and connect directly to the Internet -- now what is your MTU?

The router is also likely responsible for modifying the "PathMTU" field in your packets, which causes the Tweak Test to report that it is off. In theory, I guess your ISP could be doing this as well, but I would consider it unlikely...

Well is there any reliable way to get MTU information on a particular IP? Then I can do each IP on a tracert and find out where my problem is or if its me. (I'll have to try direct without router as well).

In this day and age there are VERY few paths that don't allow you to use a "full size" packet (1500). I would assume that any web site you are trying to reach is going to go through modern-day routers with modern-day packet handling. If your MTU is less than 1500, then it is NOT because some intermediary router down the road was unable to handle the size of your packets.

Clearly, something is changing your PathMTU setting (the Tweak Tester says it is off, but your computer MUST have it on) and likely that same entity is modifying your TCP/IP packet size. 99% of the time it is the user's home router. Statistically, the same thing is happening to you. I guess there could be an ISP out there that interferes with your packets that much (reducing the size and flipping the PathMTU bit), but that is less likely.

The simplest thing by far to do is to remove the router and test your connection. If you STILL see your packets read out as PathMTU off and MTU at 1362, then you can start looking elsewhere.

Tracert is NOT going to help you and neither is Ping. You've got to send out TCP/IP packets -- not ICMP. If your ISP is simply grabbing each SYN request and modifying header fields for MSS and PathMTU, it might be very difficult to prove. Perhaps if you had a nearby neighbor on the same ISP, you could try to connect to his box through your ISP. You would both need to use a Packet Sniffing program. Then, you would need to examine the SYN request that left your box and compare it to the SYN request that arrived at your neighbor's box. If the MSS and PathMTU fields don't match, then your ISP is changing them.

It sounds a lot easier to just take the router out of the loop and retest....

reply to Devistater
Just for the record. I had this same issue with a Linksys router (N041) and did some extensive testing and packet sniffing. Even though the packet header said 1362, the actual packet size was 1492 with header info included. Turned out that the router was misreporting the packet size due to the VPN passthrough being on. Turned off VPN pass through and all was well. Don't know if this is your issue, but look at it anyway.
--
Help Team Starfire get into fifth place... Join Team Starfire today!!
Gumballs are messy!!!

Thanks. That is interesting. Did the Tweak Tester here catch the discrepancy? If the SYN packet header is modified, then you might have been sending out full-size packets, but you should have been receiving back the smaller ones -- because that is what your router was requesting.

reply to Devistater
Tweak tester was showing the lower MTU. I did not check packets received just the outgoing. Hmm, wish I still had the router so I could check that. Anyway, I was told that there were a couple of the Linksys routers that misreport the MTU, don't know if they fixed it with firmware upgrades or not, cuz I switched to wireless and no longer have the problem.
--
Help Team Starfire get into fifth place... Join Team Starfire today!!
Gumballs are messy!!!

Block WAN Request: Enable
IPSec Pass Through: Enable
PPTP Pass Through: Enable
L2TP Pass Through: Enable
Remote Management: Disable
Use default MTU: Enable Size: (Default value: PPPoE 1492, Static/Dynamic 1500)

Those are my settings. I dont think mine does VPN unless one of those options is it. And yes I have tried setting MTU to non default and manual number.
I'll try to take router out of the loop. I want to figure this out even if its not whats causing my speed loss You guys have me curious now.

I believe the IPSec Passthrough is the VPN setting.

reply to Devistater
i have the same freaking problem man i cant download that fast because of this im on a 5.0mbit connection the mtu is fuckin it up though so i dont use the router that much im gonna email netgear if they could come out witha patch to this problem because its driving me crazy already.

reply to Devistater
Just yesterday I got a linksys WRT54G wireless/wired router from OD (I ordered it online since its $20 cheaper on the website--price mistake?). I got really lucky cause I got a CSR on the phone to apply a $20 off coupon thats not supposed to be applied to tech items. So it was pretty good deal at the $59 after rebates, now its $39 after rebates with that coupon

Anyway I am so in love with this thing. It took my speed from about 3.5mbit to about 5mbit down!! Thats like a 40% increase in download speed! I guess the old NR041 router was kinda sucky or something I dunno. But I so love this thing, if fixed both the problem with tweak test saying the 1362 MTU and the speed problem (dunno if they were both the same problem or not). Next task will be to play around with modded firmware, get some packetshaping in, and some static DHCP going
»support.sbcglobal.net/cgi-bin/sp···obal.net