OpenWrt Forum Archive

Topic: Recommended MTU size for PPPoE connection; PPPoE setup for OpenWrt

The content of this topic has been archived on 24 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Does someone have OpenWrt (10.03.x) running with PPPoE connection?
Can you please share your settings?

I have rather old ASUS WL-500G router running DD-Wrt v24 sp2.
It connects to my provider via PPPoE connection without any problems, and connection is very stable.
MTU size is 1492.
I don't remember where this number came from, as I did setup for this router about year ago.
Most likely I took that number form another router, which I had before (and which was not running open-source firmware)

I have now TP-Link WR841ND v5, with OpenWrt 10.03.1
Wireless N connectivity, WDS, etc. - working fine.
I decided now to connect it as Main router - to provider.
And I can't get PPPoE connection working.
Routers establishes connection, and I can ping and other sites.
I can open in browser, BUT: 
But for some reason most of other sites have timeout on connection.

I decided to check what different sources tell about MTU.
PPPoE MTU size in Windows XP

The default and maximum PPPoE MTU size is 1,480 bytes. With some Internet service providers (ISPs), you may have to reduce the MTU size of a PPPoE connection to a value between 1,400 and 1,480 (for example, to 1,454). Do not set an MTU size smaller than 1,400.

RFC2516 - A Method for Transmitting PPP Over Ethernet (PPPoE)

The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
   larger size than 1492.  Since Ethernet has a maximum payload size of
   1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
   2 octets, the PPP MTU MUST NOT be greater than 1492.

Very confusing.
Ok, according to RFC2516 MTU must not be greater than 1492.
But what exactly it should be?

I also checked PPPoE settings in Windows Vista.
And guess what? No reference to MTU size.

I would appreciate your help on tuning PPPoE connection with OpenWrt.
And settling on right size of MTU for this kind of connection.

Here is what Cisco says about MTU

Why the MTU Size Must Be Changed

When a user requests a web site, a client/server negotiation occurs between the PC and the web server that hosts the web site. During the negotiation, a maximum MTU size is negotiated. Since the PC negotiates and its default MTU size is 1500 bytes (Windows 3x, 9x, NT, ME, and so forth), the web server negotiates an MTU size of 1500 bytes. Therefore, regardless of the MTU size you configure on the router, the web server still sends packets up to 1500 bytes in size.

The reason why some pages do not fully load is that the router fragments IP packets if the PC MTU is misconfigured and a packet greater than 1492 bytes is sent to the router. This fragmentation does not occur on the return path through the universal access concentrator (UAC) (Cisco 6400 or 7200). When the UAC receives a packet greater than 1492 bytes, the packet is dropped, and the UAC generates and sends an Internet Control Message Protocol (ICMP) message to the web server that sent the oversized packet. The ICMP informs the web server that it sent an oversized packet and that it needs to resend the packet with a smaller MTU.

Note:  For information about why the MTU size is 1492 bytes, refer to the PPPoE Baseline Architecture for the Cisco 6400 white paper.

The problem occurs because many web servers block ICMP messages, which causes the server to continuously send 1500-byte packets. These packets are dropped, and as a result, the requested web site does not load. If the web server is properly configured and ICMP messages are not blocked, the server adjusts its MTU and retransmits until the page loads completely.

A partially loaded page occurs when the initial data packets sent from the web server are under the 1492 byte maximum. However, a packet is then sent that exceeds this maximum. The server continues to retransmit this oversized packet that results in a partially loaded page and a "waiting for reply..." message in the status bar.

It seems I found reason why there were problems with connection.

It was caused by cloning Mac address from local PC to WAN interface.

Let's suggest PC mac address is: 00-23-54-AA-BB-CC
You set it as Mac address for WAN interface.

    config 'interface' 'wan'
            option 'ifname' 'eth0.2'
            option 'proto' 'pppoe'
            option 'macaddr' '00:23:54:aa:bb:cc'
            option 'username' 'myusername'
            option 'password' 'mypassword'
            option 'keepalive' '10'
            option 'peerdns' '1'

And there are two hosts known to router with same Mac address - one in LAN, and another on WAN.
This doesn't cause problem with DD-Wrt, or TP-Link factory firmware. But it's a problem with OpenWrt/Gargoyle.

To overcome this, I changed Mac address on Ethernet adapter (in Windows Vista) to: 00-23-54-11-22-33
Everything works now.

Most likely, something needs to be fixed in network or firewall setup.
But hope information above would be helpful for people looking for workaround.

BTW:  PPPoE connection works with MTU 1492

pppoe-wan Link encap:Point-to-Point Protocol
          inet addr:  P-t-P:  Mask:
          RX packets:14682919 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25503581 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:984963180 (939.3 MiB)  TX bytes:2380030250 (2.2 GiB)

(Last edited by vplessky on 12 Dec 2010, 16:31)

The discussion might have continued from here.