Page MenuHomeVyOS Platform

pppoe: allow to specify MRU in addition to already configurable MTU
Closed, ResolvedPublicFEATURE REQUEST

Description

From https://forum.vyos.io/t/missing-mru-in-dial-pppoe-interfaces/11880/4?u=c-po

https://linux.die.net/man/8/pppd

mru n

Set the MRU [Maximum Receive Unit] value to n. Pppd will ask the peer to send packets of no more than n bytes. 
The value of n must be between 128 and 16384; the default is 1500. A value of 296 works well on very slow links
(40 bytes for TCP/IP header + 256 bytes of data). Note that for the IPv6 protocol, the MRU must be at least 1280.

Details

Difficulty level
Normal (likely a few hours)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible
Issue type
Improvement (missing useful functionality)

Related Objects

Mentioned In
1.3.5

Event Timeline

c-po changed the task status from Open to In progress.Oct 3 2023, 4:08 PM
c-po claimed this task.
c-po triaged this task as Normal priority.
c-po created this task.
c-po changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).

The new MRU config in 1.3.4 seems to have caused my MTU to be lower.

I only have "mtu 1500" in my config. I have not manually set MRU.

Yet if I look in /etc/ppp/peers/pppoe0 I see

persist
ifname pppoe0
ipparam pppoe0
debug
mtu 1500
mru 1492

and my PPPoE log shows:

Oct 18 08:49:08 pppd[2357]: Connect: pppoe0 <--> eth0
Oct 18 08:49:08 pppd[2357]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xf255bf95>]
Oct 18 08:49:08 pppd[2357]: rcvd [LCP ConfReq id=0xab <mru 1492> <auth pap> <magic 0x728eb5ee>]
Oct 18 08:49:08 pppd[2357]: sent [LCP ConfAck id=0xab <mru 1492> <auth pap> <magic 0x728eb5ee>]
Oct 18 08:49:08 pppd[2357]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xf255bf95>]
Oct 18 08:49:08 pppd[2357]: sent [LCP EchoReq id=0x0 magic=0xf255bf95]
Oct 18 08:49:08 pppd[2357]: sent [PAP AuthReq id=0x1 user="<hidden>" password=<hidden>]
Oct 18 08:49:08 pppd[2357]: rcvd [LCP EchoRep id=0x0 magic=0x728eb5ee]
Oct 18 08:49:08 pppd[2357]: rcvd [PAP AuthAck id=0x1 "Login ok"]
Oct 18 08:49:08 pppd[2357]: Remote message: Login ok

And now my Interface which was 1500 is now 1492

tim@ferrari:~$ show interfaces pppoe pppoe0
pppoe0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc htb state UNKNOWN group default qlen 3

It seems there needs to be a check "If MTU is set but MRU isn't set manually, then make MRU=MTU"

?

Furher to this, manually setting "mru 1500" gives me my 1500 MTU back again.

The reason I noticed this was because NO Apple Apps would load/update. Both sides had an MTU of 1492:

Nokia BNG:

LCP State            : Opened
IPCP State           : Opened
IPv6CP State         : Closed
PPP MTU              : 1492
PPP Auth-Protocol    : PAP

And my side as above. But there was still something not quite right with the packets - I think I was sending out large packets still and they were being dropped.

I guess this will affect very few people, as being able to set MTU of 1500 on PPPoE is not something a lot of people realise can be done.

A fix that changes the behavior back to it was https://github.com/vyos/vyos-1x/pull/2527

This fixes the implementation in e062a8c ("pppoe: T5630: allow to specify MRU in addition to already configurable MTU") and restores the bahavior that MRU defaults to MTU if MRU is not explicitly set.

This was the behavior in VyOS 1.3.3 and below before we added ability to define the MRU value.