dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
10005

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI

MVM

MTU, PPPoE, Servers and LinkSys Routers

Are you using a LinkSys router, running DSL PPPoE and having trouble serving *some* clients on ftp, http, smtp, IRC-DCC, VNC or anything else requiring forwarded ports? Read on for a very possible cure...

The easiest solution is to set the server PC to an MTU of 1492. If this doesn't work, try less (1362 seems to be another PPPoE value). If an MTU of 200 doesn't work, look elsewhere for the problem.

Doctor TCP used to alter MTU in the registry of a Windows PC is a great tool for doing just this. Get it right here in the tweaks section.

You'll notice this problem on only *some* clients. The problem clients should be mostly from company LANs and cable modems - they run MTU=1500. Other PPPoE users and dialup connections will be the ones that have no problem. IF YOU SEE THIS PATTERN YOU PROBABLY HAVE THIS EXACT PROBLEM.

Some things I found...
Recent LinkSys firmware (1.38.5 and above for BEFSRx1 I think it was) now includes an MTU setting. Unfortunately, this seems to only affect outbound connections, not inbound (like for servers).

Some DSL modems also do not seem to enforce their MTU. This may also depend on the local equipment or setup or network but there's no reason everyone would have the problem. Some may never see this.

Background
MTU is "Maximum Transmissible Unit" - the maximum size a packet can be in a network.

When a TCP connection is made a SYN/SYN-ACK exchange is the first thing done. The client sends the SYN and the server replies with the SYN-ACK. In these messages the MTUs are included so each can send packets of the right size to the other end. Actually MSS (Maximum Segment Size) is sent but for TCPIP that's a value that excludes TCPIP headers and is always 40 less (MTU=1492 is MSS=1452).

On outbound connections the LinkSys will actually change this MSS value on-the-fly to be what the setting is. You could say the LinkSys "enforces" the MTU that is set. Even if the PC sends MTU=1500 the LinkSys changes it in the SYN packet - this is how the other end *really* sees 1492 (if that is what the LinkSys is set to). This is desirable since you can run your LAN at 1500 MTU yet go out to the net at 1492 automatically!

But server connections don't seem to get this help. Not only that, the ISP equipment and/or the DSL modem lets these SYNs come in saying they're 1500 MTU! The LinkSys does no alteration (it's INbound not OUTbound). The PC is happy (it's 1500 MTU after all) so these 2 ends try 1500 MTU.... BUT THAT DOESN'T WORK ON PPPoE!

The result is large packets (above 1492 MTU) will not transfer well at all and usually just hangs the TCP stack.

One funny thing you WILL see... small data transfers of, for example, small directories or small html files DO get through OK. This is because the packet size never reaches a fatal value.

Some links to actual cases of this problem:
Test My FTP
BEFSR41 (1.39) and VNC on port 21
BEFSR41 Help!!

I hope this helps someone pulling their hair out.
All Comments and Discoveries Welcomed!
[text was edited by author 2001-10-31 13:50:13]

Muxplex
Multiplexor
join:2001-03-25
Vacaville, CA

Muxplex

Member

Well done, Bill_MI!

SnoDragon
join:2001-10-16
Surrey, BC

SnoDragon to Bill_MI

Member

to Bill_MI
Fantastic Bill!

Whoops...had to edit. Just read the top part of your message and you already stated to set both client and router to the same MTU.

Great info for the masses Bill_MI!
[text was edited by author 2001-11-01 00:51:18]
master_d
join:2001-07-31
Oceanside, CA

master_d to Bill_MI

Member

to Bill_MI
Woah! Bill, you are the man! that seemed to keep my pppoe connection solid. Pacbell used to cut me off a few times a day but now its been rocksolid for a few days now!
thanks

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI

MVM

Thanks guys. I post these when I see the same thing over and over. When the symptoms match, send them to this thread. I really think this one is affecting a lot of people and no one seems to be on top of it at all.

Master_D - that's interesting if this could also affect connectivity. Are you running some flavor of forwarding for a server? Perhaps when the MTU mismatch occurs it boots you off or something.
Bill_MI

Bill_MI

MVM

Possible Affect on FTP Clients, too.

This MTU mismatch may also show it's ugly head on FTP connections - but for clients not servers. This is because a regular (not PASV) FTP connection on port 21 includes an inbound connection to the client. There's no reason this inbound (data) connection wouldn't have the same darn problem (since it *is* a server by definition).

Most everyone with a router that uses FTP has seen the inability to list directories. This MTU mismatch can be yet another possible cause of this. Some other causes are here: REFERENCE: FTP Modes and Ports

Just a sidelight to the same root cause. Please post anything else you find.
[text was edited by author 2001-11-01 21:02:01]

John in Norwich
join:2000-08-03
Norwich, CT

John in Norwich to Bill_MI

Member

to Bill_MI

Re: MTU, PPPoE, Servers and LinkSys Routers

Sorry, I need a little more guidance... I've Got Win2K SP2, Outlook 2002, BEFSR41 (MTU 1492), and Speedstream 5260 modem. I'm having a terrible time sending attachments and sometimes plain email (I hadn't noticed, but given your post, I bet the ones that went successfully were under the MTU). What should I change to increase the probability of getting my email out?

I never used to have problems...is it possible that my ISP changed their MTU when they added email servers a few weeks back?

-John

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI

MVM

John, I suggest setting MTU 1492 in the LinkSys. Your problem sounds more like an outbound one and may or may not be MTU related. But yes, when little files go and larger ones don't MTU is a suspect. I'm talking 5k files as large enough to show MTU problems - it doesn't take megabytes.

The MTU issue described here is more a server phenomena - inbound connections (and some silly things like ftp that has a hidden server-side connection).

Last, double check using the TWEAKS here on DSLR and see what they say your MTU is seen as. The tweaks forum has the knowledge, too. I am NOT the guy for PPPoE since I've never ran it myself.
[text was edited by author 2001-11-14 18:49:36]

azacamis
join:2000-12-16
Singapore

azacamis to Bill_MI

Member

to Bill_MI
changing the MTU on the router would not do much good. Change it from the source - PC. This article from cisco explain why

»www.cisco.com/warp/publi ··· mtu.html

Bob Carrick

join:2000-04-24
New York, NY

Bob Carrick to Bill_MI

to Bill_MI
The MTU should be changed generally on the router. If the router is configured properly (via firmware) it will use 1500 to speak to the PCs and then a seperate MTU for the internet, IE: 1492. My Nexland actually allows me to adjust the MTU speaking to my computers (which you leave at 1500, since it's straight Ethernet) and the MTU going out to the real world. 1470 in my PPPoE case.

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI to azacamis

MVM

to azacamis
Aza, Cisco apparently doesn't modify MSS-on-SYN the way the LinkSys does. When you set the LinkSys MTU to 1492, for example, the PCs running at 1500 connecting outbound gets their MSS changed on the way out. So... you can run 1500 on the LAN with no problem yet go to the net at 1492 in this fashion... BUT...

The same doesn't happen inbound. That's the whole reason for this thread - servers better set their box or they'll incorrectly negotiate 1500 MTU.

Don't take my word... you can sniff the outbound SYN packets and see for yourself what the LinkSys does. Cisco's first paragraph does not apply to the LinkSys.

azacamis
join:2000-12-16
Singapore

azacamis

Member

thanks for the info Bill, I didn't know that
billbliss
join:2001-11-13
Kirkland, WA

billbliss to Bill_MI

Member

to Bill_MI
Bill, I read this thread with great interest.

My question is this... You mentioned that in some applications such as FTP, the client actually acts as a server. Is VPN one of those scenarios? From what I've read, I think it may be.

The reason I ask is that I've noticed when I'm connected over VPN, especially when running Outlook, that I get disconnected fairly frequently but I never knew why. I've band-aided it by setting the automatic-redial-on-disconnect flag on the WinXP connectoid but that's kind of a hack and it gets Outlook all bent out of shape.

This looks like it might be a possible explanation, and if so, you'd have to set MTU on the VPN clients too.

azacamis
join:2000-12-16
Singapore

azacamis to Bill_MI

Member

to Bill_MI
sorry if this is already mentioned but you can actually test how much your MTU must be reduce by dong this ping command from the PC

1) Determine the WAN gateway

2) From a command prompt on a PC, type PING -f -l (MTU)(WAN gateway) . Start with an MTU size of 1,454.

3) If this fails with an error message indicating that it must be fragmented, decrease the MTU size and try again. Repeat this until the ping command succeeds

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI to billbliss

MVM

to billbliss
said by billbliss:
You mentioned that in some applications such as FTP, the client actually acts as a server. Is VPN one of those scenarios? From what I've read, I think it may be.
I'm not up on all the VPNs but I believe you're right. But some VPNs set their own MTU separately or even have their own characteristic MTU. And it's usually much lower than 1492 as I recall. If it tries to be higher, problems will occur (lower is fine).

Aza has the best way to determine what your MTU is. It can't identify what's limiting it but sure is handy:

ping -f -l 1472 yahoo.com
(edit: -l is a lower-case L)

1472 is a number 28 less than MTU so 1472 will work on a 1500 MTU but 1473 will not. pass/fail for 1492 MTU will be 1464/1465. Connect VPN and try it!

Then there's my Telocity modem/gateway. I can measure 1492 all day yet a TCP-SYN gets reduced by the darn thing to 1362!!! Ping test says they're wasting MTU in this case (PPPoE underneath a fixed-IP kludge system it is!).
[text was edited by author 2001-11-14 22:25:16]

azacamis
join:2000-12-16
Singapore

azacamis to Bill_MI

Member

to Bill_MI
bill, does that mean that if I must add 28 for overheads? meaning if 1472 passed then I can actually use 1500 after adding the overhead?

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI

MVM

That's right, Aza. The ping command -l (length) option doesn't include the ICMP header of 28 bytes. Thanks for mentioning this technique, this is a good thread to include it. This technique doesn't care what your settings are, it just... measures it!
gwl01
join:2001-11-14
Cary, NC

gwl01 to Bill_MI

Member

to Bill_MI
This worked like a charm!!!!

In Linux (Mandrake 7.2)

# /sbin/ifconfig eth0 mtu 1410
- to try it out (assuming eth0 is your ethernet port).

To make the change stick across reboots I added a line:

MTU=1410

to file: /etc/sysconfig/network-scripts/ifcfg-eth0

(values slightly larger than 1410 may work also, refer back to the initial post)

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI

Bill_MI

MVM

Thanks for the info, Gwl. And it shouldn't matter Linux, Windows or MAC - if the wrong MTU gets negotiated it's toast.
MrBM
join:2001-11-24
L'Ile-Bizard, QC

MrBM

Member

Hey ! Thanks to both of you !!!
I needed both pieces of information.
I've been up all night trying to solve this.

You guys ROCK !!!

2yLiTe
@qwest.net

2yLiTe to Bill_MI

Anon

to Bill_MI
sorry to add to this "older" post...

I have an exchange 2000 server behind a linksys router, and all seems to work ok... the only thing issue is with VNC, it hangs at the "Please wait - initial screen loading" screen.

could this also be classified as an MTU issue?

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI

MVM

said by 2yLiTe:
... the only thing issue is with VNC, it hangs at the "Please wait - initial screen loading" screen.
could this also be classified as an MTU issue?
It sure could but it makes you wonder why Exchange doesn't have the same issue. Try reducing the MTU of the box with the VNC server and if the problem disappears you know what it is.

Remember, if the MTU of the accessing site is already low enough the problem won't be seen at all. If it's easier to reduce the MTU of the VNC client end to try that'll prove it, too. I assume the VNC server is behind the LinkSys on a PPPoE connection?

chablis
@dialup.mindspring.co

chablis to Bill_MI

Anon

to Bill_MI
Bill after all day of searching trying to figure out why I was having this problem with dcc's (until recently I had no problem sending to 56K modems but did with broadband connections) I finally found your information on MTU I had just updated my linksys firmware to 1.4 and went in and set it where you instructed and OHHHHHHHHH YESSSSSSSSSSS IT WORKS!!!!!!!!!!!!! Before I would actually connect and then would hang.

jw55505
Fish Head
Premium Member
join:2001-11-28
Mechanicsville, VA

jw55505 to Bill_MI

Premium Member

to Bill_MI
For any of the FreeBSD users out there who are running servers with your PPPoE/Linksys setup, you can change the MTU on your NIC with ifconfig like this:

"ifconfig eth0 MTU=1492"

I believe this also works with Linux. I set the MTU on all of my internal machines to 1492 from day one and have never had any problems. I run a FTP and web server no problem with my PPPoE/Linksys setup. I run FreeBSD, Win NT4, Win 2K and Win 98. All run smoothly.

Here is a link to an interesting article that talks about the same issues Bill was talking about when running a gateway on PPPoE. Scroll down to section 6.3
alhull
join:2002-01-16
Canton, MI

alhull to Bill_MI

Member

to Bill_MI
I have my new Earthlink DSL service working fine with no drops/freezes, etc, connected directly to a single PC's NIC. So the DSL service is working fine. It ran web radio all night long with no disconnects.

But when I try to get my LAN going again using my BESFR41, I can only get a PPPoE connection that lasts maybe 5 minutes and then I always lose the connection to the PPPoE server.

My Linksys firmware is still back at v1.33.4 or such. I've got PPPoE enabled on the router with "Keep Alive", currently have all DHCP disabled and I'm using static IPs on my PC (192.168.2.x), Router is 192.168.2.1.

The MTU on my PC is set to 1500 as DrTCP util shows. Is losing the connection to the PPPoE server a symptom of the same issue being discussed here? Should I get the latest Linksys firmware upgrade with the MTU feature in it and reset my MTU down from 1500 to an appropriate lower value?

I am desperate to get my LAN working again. HELP please!!

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI

MVM

I don't run PPPoE (yet) but constantly hear the latest firmware is much better at it. Not to mention the MTU setting (set it to 1492). The Earthlink and Covad forums are probably full of good info, too.

If you're running a server like http or ftp then this thread is all about the more special MTU issue that can exist.
alhull
join:2002-01-16
Canton, MI

alhull to Bill_MI

Member

to Bill_MI
The new firmware seems to have done the trick!! No dropped connection for over 5 hrs so far. Thanks for the tip!
Regards, Al