Page MenuHomeVyOS Platform

PPPoE MTU on boot up
Closed, ResolvedPublicBUG

Description

Hi,

I am seeing an issue with MTU on PPPoE whereby it is setting 1492 on first boot even though the config is set to 1500. Once the router is booted, disconnect pppoe and connect pppoe correctly sets the MTU to 1500

ethernet eth3 {
    address 192.168.5.1/24
    duplex auto
    mtu 1508
    pppoe 0 {
        default-route auto
        mtu 1500
        name-server none
        password 
        user-id [email protected]
    }

after boot
pppoe0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3

disconnect interface pppoe0
connect interface pppoe0
pppoe0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 3

Details

Difficulty level
Unknown (require assessment)
Version
1.2RC9
Why the issue appeared?
Will be filled on close

Event Timeline

syncer triaged this task as Normal priority.
syncer edited projects, added VyOS 1.2 Crux ( VyOS 1.2.0-rc11); removed VyOS 1.2 Crux.
hagbard changed the task status from Open to In progress.Dec 3 2018, 5:03 PM

Bug confirmed, but not easy to fix.

It's actually a ppp bug, it simply ignores mtu when setup in the peers config. I'm about to update pppd, since a new version from backports is working however it creates instead of pppoe interfaces a ppp interface, which may break something else.
Maybe its now the time to rewrite the pppoe client from scratch.

<<<<<<< HEAD

#define RCSID "$Id: tty.c,v 1.25 2006/06/04 07:04:57 paulus Exp $"

#define RCSID "$Id: tty.c,v 1.27 2008/07/01 12:27:56 paulus Exp $"

ppp-2.4.7

Found many of those, but the vyos package says it's already 2.4.7, but when I check the files, it is not.

@SteveP Can you please test if the pppoe server supports a mtu of 1500? In my tests an mtu of 1500 is requested by the client, I just send from the server back 1492 which is then used on the interface.

[PPPoE PADI 08:00:27:e9:16:1f => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 430c0000> <PPP-Max-Payload 1500>]

HI,

Do you mean test whether my ISP (BT) supports 1500? If that is the case, I know it does. https://community.bt.com/t5/Home-setup-Wi-Fi-network/MTU-1500-on-FTTP-FTTH/m-p/1782374 This thread confirms that it works with UBNT.

When I disconnect PPPoE and re-connect, my MTU shows 1500 and my internet is working, after a reboot (MTU 1492), my internet is not working.

If this is not what you meant, please could you give me some instruction as to how to get the info you require.

Thanks

SteveP

Can you record the PADI requests when the router reboots? It's plain text anyway, important question is if it sends "PPP-Max-Payload 1500", which it does in all my tests. I was only able to reproduce your issue when the sends a max mtu 1492 or even lower, then the client (depending on mru) negotiates the highest possible mtu and sets it on the pppoe interface. But it's also possible that my tests are different from what you see. I used accel-ppp to use as pppoe server.

Hi,

I have had a chance to look at this again and believe we can get what we want from /var/log/Vyatta/ppp_pppoe0.log

changes to /var/log/Vyatta/ppp_pppoe0.log after reboot:

Terminating on signal 15
Connect time 9987.6 minutes.
Sent 1406131208 bytes, received 1590207115 bytes.
Script /etc/ppp/ip-down started (pid 8583)
sent [LCP TermReq id=0x5 "User request"]
rcvd [LCP TermAck id=0x5]
Connection terminated.
Waiting for 1 child processes...

script /etc/ppp/ip-down, pid 8583

Script /etc/ppp/ip-down finished (pid 8583), status = 0x0
Sat Dec 8 07:52:26 GMT 2018: PPP interface pppoe0 created
Sat Dec 8 07:52:27 GMT 2018: Stopping PPP daemon for pppoe0
Sat Dec 8 07:52:27 GMT 2018: Starting PPP daemon for pppoe0
Send PPPOE Discovery V1T1 PADI session 0x0 length 12
dst ff:ff:ff:ff:ff:ff src 4c:02:89:12:16:d1
[service-name] [host-uniq 07 13 00 00]
Send PPPOE Discovery V1T1 PADI session 0x0 length 12
dst ff:ff:ff:ff:ff:ff src 4c:02:89:12:16:d1
[service-name] [host-uniq 07 13 00 00]
Recv PPPOE Discovery V1T1 PADO session 0x0 length 48
dst 4c:02:89:12:16:d1 src a4:7b:2c:5f:ef:63
[service-name] [AC-name acc-aln22.bs] [host-uniq 07 13 00 00] [AC-cookie 88 4a 29 6e d4 37 d6 69 50 9f 62 65 e7 c1 a0 3b]
Send PPPOE Discovery V1T1 PADR session 0x0 length 32
dst a4:7b:2c:5f:ef:63 src 4c:02:89:12:16:d1
[service-name] [host-uniq 07 13 00 00] [AC-cookie 88 4a 29 6e d4 37 d6 69 50 9f 62 65 e7 c1 a0 3b]
Recv PPPOE Discovery V1T1 PADS session 0x1751 length 12
dst 4c:02:89:12:16:d1 src a4:7b:2c:5f:ef:63
[service-name] [host-uniq 07 13 00 00]
PADS: Service-Name: ''
PPP session is 5969
Connected to a4:7b:2c:5f:ef:63 via interface eth3
using channel 1
Using interface ppp0
Connect: ppp0 <--> eth3
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x5f9c79be>]
rcvd [LCP ConfReq id=0xf0 <mru 1492> <auth chap MD5> <magic 0x387e77e5>]
sent [LCP ConfAck id=0xf0 <mru 1492> <auth chap MD5> <magic 0x387e77e5>]
rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x5f9c79be>]

sent [LCP EchoReq id=0x0 magic=0x5f9c79be]
rcvd [CHAP Challenge id=0x1 <f4a6240049d00cc70bca9c61a139b6ed88a9029b48219621e85d9014bc11b731b85c32812dbd49b888>, name = "acc-aln22.bs"]
sent [CHAP Response id=0x1 <083c3151b0fd3fb9fe3a1da7e5ae2326>, name = "[email protected]"]
rcvd [LCP EchoRep id=0x0 magic=0x387e77e5]
rcvd [CHAP Success id=0x1 "CHAP authentication success"]
CHAP authentication succeeded: CHAP authentication success
CHAP authentication succeeded
peer from calling number A4:7B:2C:5F:EF:63 authorized
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPV6CP ConfReq id=0xc <addr fe80::a67b:2cff:fe5f:ee1f>]
Unsupported protocol 'IPv6 Control Protocol' (0x8057) received
sent [LCP ProtRej id=0x2 80 57 01 0c 00 0e 01 0a a6 7b 2c ff fe 5f ee 1f]
rcvd [IPCP ConfReq id=0x0 <addr 172.16.15.188>]
sent [IPCP ConfAck id=0x0 <addr 172.16.15.188>]
rcvd [IPCP ConfNak id=0x1 <addr 213.121.3.135>]
sent [IPCP ConfReq id=0x2 <addr 213.121.3.135>]
rcvd [IPV6CP TermReq id=0xd]
Unsupported protocol 'IPv6 Control Protocol' (0x8057) received
sent [LCP ProtRej id=0x3 80 57 05 0d 00 04]
rcvd [IPCP ConfAck id=0x2 <addr 213.121.3.135>]
Script /etc/ppp/ip-pre-up started (pid 5087)
Script /etc/ppp/ip-pre-up finished (pid 5087), status = 0x0
local IP address 213.121.3.135
remote IP address 172.16.15.188
Script /etc/ppp/ip-up started (pid 5125)
Script /etc/ppp/ip-up finished (pid 5125), status = 0x0
rcvd [IPV6CP TermReq id=0xe]
Unsupported protocol 'IPv6 Control Protocol' (0x8057) received
sent [LCP ProtRej id=0x4 80 57 05 0e 00 04]

changes to /var/log/Vyatta/ppp_pppoe0.log after disconnect:

Sat Dec 8 07:54:15 GMT 2018: User stevep stopping PPP daemon for pppoe0 by disconnect command
Terminating on signal 15
Connect time 1.8 minutes.
Sent 1699624 bytes, received 1551500 bytes.
Script /etc/ppp/ip-down started (pid 5802)
sent [LCP TermReq id=0x5 "User request"]
rcvd [LCP TermAck id=0x5]
Connection terminated.
Waiting for 1 child processes...

script /etc/ppp/ip-down, pid 5802

Script /etc/ppp/ip-down finished (pid 5802), status = 0x0

changes to /var/log/Vyatta/ppp_pppoe0.log after connect:

Sat Dec 8 07:54:31 GMT 2018: User stevep starting PPP daemon for pppoe0 by connect command
Send PPPOE Discovery V1T1 PADI session 0x0 length 18
dst ff:ff:ff:ff:ff:ff src 4c:02:89:12:16:d1
[service-name] [host-uniq 26 17 00 00] [PPP-max-payload 05 dc]
Recv PPPOE Discovery V1T1 PADO session 0x0 length 54
dst 4c:02:89:12:16:d1 src a4:7b:2c:5f:ef:63
[service-name] [AC-name acc-aln22.bs] [host-uniq 26 17 00 00] [AC-cookie 88 4a 29 6e d4 37 d6 69 50 9f 62 65 e7 c1 a0 3b] [PPP-max-payload 05 dc]
Send PPPOE Discovery V1T1 PADR session 0x0 length 38
dst a4:7b:2c:5f:ef:63 src 4c:02:89:12:16:d1
[service-name] [host-uniq 26 17 00 00] [PPP-max-payload 05 dc] [AC-cookie 88 4a 29 6e d4 37 d6 69 50 9f 62 65 e7 c1 a0 3b]
Recv PPPOE Discovery V1T1 PADS session 0x1753 length 18
dst 4c:02:89:12:16:d1 src a4:7b:2c:5f:ef:63
[service-name] [host-uniq 26 17 00 00] [PPP-max-payload 05 dc]
PADS: Service-Name: ''
PPP session is 5971
Connected to a4:7b:2c:5f:ef:63 via interface eth3
using channel 2
Using interface ppp0
Connect: ppp0 <--> eth3
sent [LCP ConfReq id=0x1 <magic 0x83bd0c32>]
rcvd [LCP ConfReq id=0xbd <mru 1500> <auth chap MD5> <magic 0x65c0d6d9>]
sent [LCP ConfAck id=0xbd <mru 1500> <auth chap MD5> <magic 0x65c0d6d9>]

rcvd [LCP ConfAck id=0x1 <magic 0x83bd0c32>]
sent [LCP EchoReq id=0x0 magic=0x83bd0c32]
rcvd [CHAP Challenge id=0x1 <f88e2c9d95b799e4c049e4c4b85b96c07abc4ba65b15fc2b725dd86682f8d7fa8704999dbbb202fbfbe6c0b443>, name = "acc-aln22.bs"]
sent [CHAP Response id=0x1 <11136fdcfd2b2912ad9fea95d8dcf8be>, name = "[email protected]"]
rcvd [LCP EchoRep id=0x0 magic=0x65c0d6d9]
rcvd [CHAP Success id=0x1 "CHAP authentication success"]
CHAP authentication succeeded: CHAP authentication success
CHAP authentication succeeded
peer from calling number A4:7B:2C:5F:EF:63 authorized
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPV6CP ConfReq id=0x0 <addr fe80::a67b:2cff:fe5f:ee1f>]
Unsupported protocol 'IPv6 Control Protocol' (0x8057) received
sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a a6 7b 2c ff fe 5f ee 1f]
rcvd [IPCP ConfReq id=0x58 <addr 172.16.15.188>]
sent [IPCP ConfAck id=0x58 <addr 172.16.15.188>]
rcvd [IPCP ConfNak id=0x1 <addr 86.174.92.68>]
sent [IPCP ConfReq id=0x2 <addr 86.174.92.68>]
rcvd [IPV6CP TermReq id=0x1]
Unsupported protocol 'IPv6 Control Protocol' (0x8057) received
sent [LCP ProtRej id=0x3 80 57 05 01 00 04]
rcvd [IPCP ConfAck id=0x2 <addr 86.174.92.68>]
Script /etc/ppp/ip-pre-up started (pid 5933)
Script /etc/ppp/ip-pre-up finished (pid 5933), status = 0x0
local IP address 86.174.92.68
remote IP address 172.16.15.188
Script /etc/ppp/ip-up started (pid 5968)
Script /etc/ppp/ip-up finished (pid 5968), status = 0x0
rcvd [IPV6CP TermReq id=0x2]
Unsupported protocol 'IPv6 Control Protocol' (0x8057) received
sent [LCP ProtRej id=0x4 80 57 05 02 00 04]

Looks like on a reboot we are requesting 1492 and after disconnect, a connect is correctly requesting 1500

I have also confirmed that there is nothing in vyatta-postconfig-bootup.script (I used to use 1.1.8 with sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe0 -j TCPMSS --clamp-mss-to-pmtu in vyatta-postconfig-bootup.script and, as this 1.2 install is an upgrade, I wondered whether I had forgotten to remove these settings before trying baby jumbo frames but I had removed them)

SteveP

All right. First of all MTU != MRU. (MTU - 8 byte IP header = MRU). I used your config example and I see a difference. The conf request has to come from your side, that happens durig the discovery pahase (PADI). I see that it is not being sent before you reconnect.

Send PPPOE Discovery V1T1 PADI session 0x0 length 12
dst ff:ff:ff:ff:ff:ff src 4c:02:89:12:16:d1
[service-name] [host-uniq 07 13 00 00] <-- here should come the the max payload size (see below)

Send PPPOE Discovery V1T1 PADI session 0x0 length 18
dst ff:ff:ff:ff:ff:ff src 4c:02:89:12:16:d1
[service-name] [host-uniq 26 17 00 00] [PPP-max-payload 05 dc] (05dc == 1500)

So , now the question is why it doesn't sent it after a reboot but does when you connect and disconnect.

I can reproduce the issue, which seems to be an issue of pppd.

Hi @SteveP,

can you please do the following and post the result:

  1. log in into vyos
  2. connect pppoe
  3. 'sudo ifconfig pppoe0' and find the destination end point (will be behind P-t-P:<ip address>)
    1. 'sudo /bin/ping -M do -s 1500'

thx

Hi,

sudo ifconfig pppoe0
pppoe0 Link encap:Point-to-Point Protocol

inet addr:86.174.92.68  P-t-P:172.16.15.188  Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
RX packets:39321606 errors:0 dropped:0 overruns:0 frame:0
TX packets:11454389 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:57128999317 (53.2 GiB)  TX bytes:889897287 (848.6 MiB)

sudo /bin/ping 172.16.15.188 -M do -s 1500
PING 172.16.15.188 (172.16.15.188) 1500(1528) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

sudo /bin/ping 86.174.92.68 -M do -s 1500
PING 86.174.92.68 (86.174.92.68) 1500(1528) bytes of data.
1508 bytes from 86.174.92.68: icmp_seq=1 ttl=64 time=0.084 ms
1508 bytes from 86.174.92.68: icmp_seq=2 ttl=64 time=0.093 ms
1508 bytes from 86.174.92.68: icmp_seq=3 ttl=64 time=0.094 ms

SteveP

All right, thanks bunch. I think I found the issue but before I expose it into the image, I'd like to test with you the functionality.

  1. login into the router
  2. open /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/pppoe/node.def (sudo nano /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/pppoe/node.def)
  3. add the value priority: 350

example:

tag:

type: u32

help: PPPOE unit number

priority: 350 <----

val_help: 0-15; Point-to-Point Protocol over Ethernet (PPPOE) unit number

Save it and restart your router. In all the tests I've done, the first PADI does not contain [PPP-Max-Payload 0x05DC] from the very start.
Please let me know if it works for you since I don't have any real test scenario other than home brewed VMs chained together.

I've tested it successfully multiple times and pushed the fix upstream, the configured MTU is now being requested with the first PADI.

18:46:35.736163 08:00:27:70:1d:76 > ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 38: PPPoE PADI [Service-Name] [Host-Uniq 0x34080000] [PPP-Max-Payload 0x05DC]

Confirmed fixed thanks

SteveP