Modify

Opened 4 years ago

Last modified 3 years ago

#14148 new defect

Custom MTU for PPPoE connection is set for Ethernet adapter too

Reported by: alexatkinuk Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: pppoe mtu Cc:

Description

If I set a custom MTU for a PPPoE WAN connection it affects both the PPPoE settings AND the ethernet adapter itself. This is clearly wrong, as the ethernet adapter needs to be 8 bytes greater than the PPPoE setting in order to accommodate the PPP headers.

PPPoE also is defaulting to an MTU of 1480 when surely it should be 1492?

It seems we need a seperate configuration variable for PPPoE MTU rather than using the single entry in /etc/config/network, or some calculation to be done to ensure the PPPoE MTU is never higher than the ethernet one.

This should also take into account the fact the new PPP (not yet in OpenWRT) will support 1500 MTU for PPPoE by enabling baby jumbo frames on the ethernet adapter.

Attachments (0)

Change History (5)

comment:1 Changed 4 years ago by anonymous

You should use something like: option pppd_options 'mtu 1452'

comment:2 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:3 Changed 3 years ago by Vortify12

I can't believe that this ticket is a year old and still has not been fixed. the MTU setting in /etc/config/network , affects the interface itself rather than only applying to pppoe. then the script in /lib/netifd/proto/ppp.sh , reads the value and set it for both MTU and MRU of the pppoe connection. this is very wrong and problematic. for starters, the applied MTU to the pppoe interface, is always 8 bytes lower that whats been set(luckily the pppd daemon is smart enough to figure that out), also there is absolutely no guarantee that MRU value is always the same as MTU. there also could be different pppoe instances on a same interface which you would have no way of separating MTU/MRU for each of them. not only that, why would i want to limit my ethernet interface throughput just because i have to limit my MTU/MRU of a pppoe interface on that link? i could be using that interface for other purposes as well.
In conclusion, we indeed need separate set of settings for pppoe MTU/MRU values.
Even pppd engine is not happy when you directly change your ethernet MTU as can be observed in the log:

daemon.err pppd[3744]: Interface eth0.2 has MTU of 1488 -- should be at least 1500.
daemon.err pppd[3744]: This may cause serious connection problems

also, default values for MTU/MRU for pppoe, should be set to 1480 (this does not include the pppoe overhead obviously)

Replying to anonymous:

You should use something like: option pppd_options 'mtu 1452'

This will likely not work as MTU and MRU are already explicitly set in pppd arguments generated by ppp.sh . and even if it does, you are still not able to set different values for different pppoe connections.

Last edited 3 years ago by Vortify12 (previous) (diff)

comment:4 Changed 3 years ago by anonymous

this might be of use https://web.archive.org/web/20131029215600/http://www.sinet.bt.com/498v5p1.pdf

"CPs should also be aware of the following:

Where Openreach has provided and is managing the modem, daily status reports will be generated and ransmitted consisting of no more than 8k bytes (64k bits) of data upstream at full line rate. These flows will take priority over EU data. The impact clearly depends on the VDSL2 traffic rate at the time "

and this http://wiki.aa.org.uk/FTTC_Modem

MTU = 1500 (if your equipment can handle baby jumbo frames and RFC 4638), otherwise 1492

openwrt profile vg3505j are in this class of devices and to get maximum throughput i would guess is needed ? CPE with an integrated VDSL2 modem (up to profile 30a)

http://monki.org.uk/blog/2013/04/14/patching-openwrt-for-bt-fttc/

comment:5 Changed 3 years ago by angelmanjk@…

still a problem

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.