Unable to set pppoe-wan MTU to 1500 with eth0 and eth0.6 to 1508

I have a TP-Link TL-WDR4300 running OpenWrt 18.06.4 behind a DrayTek Vigor 165 in MPoA full bridge mode. My ISP is XS4ALL, and they support RFC4638 / baby jumbo frames on their VDSL2 and FttH connections. XS4ALL requires a PPPoE connection with 802.1Q tags on VLAN 6.

I am trying to get baby jumbo frames to work on my router, but I am unable to set the PPPoE MTU 8 bytes lower than the VLAN device's MTU. I have tried everything I could think of, but in all cases I either ended up with a black hole situation, or at best the MTU of outbound traffic being 1500, but inbound traffic still being fragmented.

In a normal situation, the tunnel negotiates an MTU of 1492, and everything works fine.

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eth0.6@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492
wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

As you can see, all MTU's are 1500, with the exception of pppoe-wan, which is 1492. I have not configured any MTU manually in this example. (The term 'mtu' does not show up in /etc/config/network.)

My ppp daemon runs with the following parameters:

/usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan lcp-echo-interval 1 lcp-echo-failure 5 lcp-echo-adaptive +ipv6 set AUTOIPV6=1 nodefaultroute usepeerdns maxfail 1 user xs4all password xs4all ip-up-script /lib/netifd/ppp-up ipv6-up-script /lib/netifd/ppp6-up ip-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down mtu 1492 mru 1492 plugin rp-pppoe.so nic-eth0.6

As you can see, the mtu / mru parameters match the pppoe-wan device's MTU of 1492.

Although there isn't really documentation for RFC4638 on OpenWrt, I have found numerous forum posts telling me to raise the switch device's MTU to 1508, set the LAN's MTU to 1500, and the WAN's MTU to 1508. Then the pppoe-wan device should be set to 1500 and the 1500 mtu / mru parameters should magically be set by pppd.

But it doesn't work like that for me.

In /etc/config/network, I set things up like this:

config interface 'switch'
	option ifname 'eth0'
	option mtu '1508'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option mtu '1500'
	...

config interface 'wan'
	option ifname 'eth0.6'
	option mtu '1508'
	option proto 'pppoe'
	...

When I then reload my network, the interfaces will look like this:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508
br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508
eth0.6@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508
pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500
wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

It looks OK at first sight, but however it completely breaks my connection. I suspect this is because of the parameters pppd runs with in this case:

/usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan lcp-echo-interval 1 lcp-echo-failure 5 lcp-echo-adaptive +ipv6 set AUTOIPV6=1 nodefaultroute usepeerdns maxfail 1 user xs4all password xs4all ip-up-script /lib/netifd/ppp-up ipv6-up-script /lib/netifd/ppp6-up ip-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down mtu 1508 mru 1508 plugin rp-pppoe.so nic-eth0.6

This is not right, because the "inner" MTU is now identical to the VLAN's MTU, and 8 bytes higher than the tunnel's MTU. In this case, I can initiate connections, but after the TCP handshake, everything is dropped.

What I would suspect to be right, is pppd negotiating an mtu / mru of 1500, not 1508, but that does not happen for some reason. So I tried to add an option to force those values:

config interface 'wan'
	option ifname 'eth0.6'
	option mtu '1508'
	option proto 'pppoe'
	...
	option pppd_options 'mtu 1500 mru 1500'

I restarted the network service, but it didn't end well:

/usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan lcp-echo-interval 1 lcp-echo-failure 5 lcp-echo-adaptive +ipv6 set AUTOIPV6=1 nodefaultroute usepeerdns maxfail 1 user xs4all password xs4all ip-up-script /lib/netifd/ppp-up ipv6-up-script /lib/netifd/ppp6-up ip-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down mtu 1508 mru 1508 plugin rp-pppoe.so nic-eth0.6 mtu 1500 mru 1500

Apparently, the pppd_options are only appended, and clearly only the first parameters are being used. So the situation is identical to what I had before: a black hole situation.

Then I wanted to find out what would happen if I'd set an MTU of 1500 for the WAN interface, leaving eth0 at 1508. So I set it up like this:

config interface 'switch'
	option ifname 'eth0'
	option mtu '1508'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option mtu '1500'
	...

config interface 'wan'
	option ifname 'eth0.6'
	option mtu '1500'
	option proto 'pppoe'
	...

I then checked the pppd command line, and it was looking well:

/usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan lcp-echo-interval 1 lcp-echo-failure 5 lcp-echo-adaptive +ipv6 set AUTOIPV6=1 nodefaultroute usepeerdns maxfail 1 user xs4all password xs4all ip-up-script /lib/netifd/ppp-up ipv6-up-script /lib/netifd/ppp6-up ip-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down mtu 1500 mru 1500 plugin rp-pppoe.so nic-eth0.6

But when I ran ip link, it wasn't looking so well:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508
br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508
eth0.6@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492
wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

So even though pppd claims to be running with an mtu / mru of 1500, the pppoe-wan tunnel device has an MTU of 1492. My connection works fine this way, but my MTU is only 1492 (read: I can't ping with a size of 1472 without fragmentation). So it doesn't change anything compared to the defaults.

Then I figured I could just change the MTU of the pppoe-wan device to test if that would help. So I ran:

ip link set pppoe-wan mtu 1500

And it was indeed increased:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508
br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508
eth0.6@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500
wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

So I figured that I'd just add an extra couple of lines to /etc/config/network to automate this:

config interface 'switch'
	option ifname 'eth0'
	option mtu '1508'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option mtu '1500'
	...

config interface 'wan'
	option ifname 'eth0.6'
	option mtu '1500'
	option proto 'pppoe'
	...

config interface 'pppoe'
	option ifname 'pppoe-wan'
	option mtu '1500'

I restarted the network service, and it indeed set the pppoe-wan MTU to 1500 instead of 1492.

In this situation, I could ping with -D -s 1472 without problems from my LAN to the internet. But from my server to my router's IP's (both IPv4 and IPv6), it broke, and I got an error from my ISP's access router:

From 0.ae1.dr23.2f300.xs4all.net (194.109.7.186) icmp_seq=1 Frag needed and DF set (mtu = 1492)

So my connection was pretty weird now, with some things randomly breaking. (Especially upstreams being weirdly low, and some elements on websites not loading.)

My guess is that this is because the eth0.6@eth0 device still has an MTU of 1500 (because that is what I set under the WAN interface), but it should be 1508 instead. However, I am not able to change this. Running ip link set eth0.6 mtu 1508 changes nothing; the MTU remains at 1500.

And when I set the WAN interface's MTU to 1508, the pppd process will set the mtu / mru parameters to 1508 again, which does not work at all (black hole).
I have also tried adding the mtu 1500 and mru 1500 parameters to /etc/ppp/options, but that seems to be ignored: it was still set to 1508 and not working.

So, I am out of ideas. I think what I want is pretty simple:

  • eth0's MTU should be 1508
  • br-lan's MTU should be 1500
  • eth0.6's MTU should be 1508
  • pppoe-wan's MTU should be 1500
  • pppd should run with mtu 1500 mru 1500 parameters

But I can't seem to find any way to get this combination to work.

Did anybody else get this to work or does anyone have any suggestions I could try?

Thanks!

1 Like

I don't claim deep knowledge of the subject (or reading your entire post thoroughly to be honest), but I think you shouldn't change the PPPoE MTU because this is dependent on your ISP. You should keep it as it's and work out everything else accordingly.

My ISP explicitly says they support frames of 1508 bytes. Therefore I want to use it. There seems to be a bug in OpenWrt that doesn't allow me to configure it correctly, with options conflicting in every way I tried. I'd like to find a way to get it to work, because it is possible and it is supported by my ISP.

Can you configure/modify the MTU on the drytek device?

I can configure it, but it's max 1500. I doubt that setting has any function in MPoA bridge mode though. I assume the MTU setting there only makes a difference when you use it as a router, which I don't.

Do you know if the Drytek supports MTU > 1500 on the (ethernet/lan) interfaces?

I have read numerous posts of people all over the world using MTU 1508 on their routers behind DrayTek Vigor 130 / 165 modems in MPoA bridge mode, so I would say yes.

I really think the problem is with OpenWrt that is not able to set the eth0.6 MTU to 1508, the pppoe-wan MTU to 1500 while setting an mtu / mru parameter of 1500 in the pppd command line.

In all of my tests, there was always something not right, and that is probably the reason it didn't work (well). I just haven't found a way to configure everything correctly yet.

Does this work?
In /etc/config network

config interface 'wan'
	option ifname 'eth0.6'
	option mtu '1500'
	option proto 'pppoe'

In terminal:

ip link set eth0.6 mtu 1508
/etc/init.d/network restart

Nope, like I said, changing the eth0.6 MTU with ip link doesn't actually change the MTU. It stays at 1500.

I guess the problem is that your pppoe connection is directly configured to eth0.6.
So using:

config interface 'wan'
	option ifname 'eth0.6'
	option mtu '1500'
	option proto 'pppoe'

Will reset the interfaces mtu back to 1500 from 1508.
And using 1508 in this config section will break pppd as you wrote in your first post.

You also tested this:

config interface 'wan'
	option ifname 'eth0.6'
	option mtu '1500'
	option proto 'pppoe'
	...

config interface 'pppoe'
	option ifname 'pppoe-wan'
	option mtu '1500'

Does this variation below work?

config interface 'pppoe-wan'
	option ifname 'eth0.6'
	option mtu '1508'

And no other options.
I'm not sure if you actually have to use the proto option.
There is proto option none. But in the wiki it states that all other configuration option will be ignored.
So best is to not use the proto option
I never used pppoe on OpenWRT. But i guess you have to create some kind of "dummy" interface that uses eth0.6 with 1508 MTU and then use that dummy interface as a pppoe interface with an MTU 1500.

config interface 'pppoe'
	option ifname 'pppoe-wan'
	option mtu '1500'

And all your other pppoe options

//edit
If that doesn't work.
Try:

config interface 'pppoe-wan'
	option ifname 'eth0.6'
	option proto 'none'                                                     
	option auto '1' 
	No other options

config interface 'pppoe'
	option ifname 'pppoe-wan'
	option mtu '1500'
	option proto 'pppoe'
	....
	All your other pppoe options

config device 'wan_dev'
	option ifname 'eth0.6'
	option mtu '1508'
	No other options

The tricky part is that you cannot configure pppoe-wan because it is a virtual interface. So when you set option proto 'pppoe' for the wan interface, it creates a virtual device called pppoe-wan after that link is established.

However, pppd will force the MTU of the interface it starts its PPPoE discovery on. So if eth0.6 is set to 1508, it will negotiate 1508. The virtual device pppoe-wan will then subtract 8 bytes from that, so set its MTU to 1500. But the PPPoE tunnel will internally use 1508, which breaks.

I think the latter part is the main problem: pppd should not use the MTU of the underlying device without an option to override it.

1 Like

What about:

config interface 'wan'
	option ifname 'eth0.6'
	option proto 'none'                                                     
	option auto '1' 
	No other options (maybe try MTU 1508 here and remove the config device section)

config interface 'pppoe'
	option ifname 'wan'
	option mtu '1500'
	option proto 'pppoe'
	....
	All your other pppoe options

config device 'wan_dev'
	option ifname 'eth0.6'
	option mtu '1508'
	No other options

If that also doesn't work. I don't know. Someone else maybe has better knowledge.
Last thing I would try is to modify the pppoe connection setup script.
(To override/change pppd mtu/mru paramters)

It fails with Network device is not present. It wanted to create an interface called pppoe-pppoe.

I think that makes sense, because I don't think you can set a virtual interface in the ifname field. It has to be something like eth0.X.

:disappointed:
I don't know..
Here is a config example:
https://openwrt.org/docs/guide-user/network/wan/isp-configurations

XS4ALL

config interface 'wan'
    option ifname 'eth0.6'
    option proto 'pppoe'
    option username 'FB7581@xs4all.nl'
    option password '1234'
    option ipv6 'auto'
    option mtu '1508'  # only works for FTTH since FritzBox doesn't support higher MTU

I don't know why this should work. :thinking:
It will result in mtu/mru of 1508. Which is wrong? You want 1500.
So i guess
option mtu 1500
should go there.

and also add (?):

config device 'wan_dev'
	option ifname 'eth0.6'
	option mtu '1508'

Maybe my assumption was wrong that using proto pppoe + option mtu overrides the underlying interface mtu (eth0.6) and the mtu value is only used for the pppoe-wan interface that gets automatically created.

You can try to edit /lib/netifd/proto/ppp.sh and hardcore mtu/mru to 1500
Line 157:
${mtu:+mtu $mtu mru $mtu}
change to:
${mtu:+mtu 1500 mru 1500}

And did you actually try to set the MTU on the drytek from 1492 to 1500 even though it is set to bridge mode.

Setting the wan_dev to 1508 will result in the same problem of the mtu / mru of pppd being 1508, even if the wan interface is set to 1500, so that doesn't help.

The DrayTek has always been at 1500; never at 1492.

I guess that editing the ppp.sh is indeed the last thing I can try, but it seems like a desparate measure. It's really weird that it has to be done like that. I mean, in a normal situation where I don't set the MTU anywhere, eth0.6 is set to 1500, while pppd negotiates 1492 with the PPPoE server, and then sets pppoe-wan to 1492 as well.

It makes no sense to me that setting eth0.6 8 bytes higher, it then negotiates the tunnel 16 bytes higher, while setting the virtual interface only 8 bytes higher.

Because the default MTU is 1500.
When no MTU is specified the ppp.sh script uses 1492.
I don't know why the scripts doesn't get the actual interface MTU and subtracts 8 bytes from that. Maybe I overlooked something....

Does it work when you set a MTU of 1508 on interface wan and after the pppoe connection is established execute:
ip link set pppoe-wan mtu 1500

If yes, you can also use an if-up hot plug script to execute the ip command.

When I set an MTU of 1508 on wan, the MTU of the pppoe-wan interface is already set to 1500. However, pppd runs with mtu 1508 mru 1508 in that case, which should also be 1500. Adding that to pppd_options will only append it, so I'd end up with mtu 1508 mru 1508 ... mtu 1500 mru 1500, and only the first two seem to be parsed.

Do you get an error message in system log from pppd complaining about that it couldn't use a MTU of 1508 ? And did it automatically lower the MTU to 1500?
If yes I guess is not a problem that pppd uses MTU/MRU that is too large and the problem is somewhere else.
And can you set an higher MTU than 1500 on the drytek?

It doesn't look like pppd is complaining about the MTU of the interface mismatching the MTU of the tunnel..

Here is my log:

Sun Aug 18 11:21:04 2019 daemon.info pppd[25693]: Plugin rp-pppoe.so loaded.
Sun Aug 18 11:21:04 2019 daemon.info pppd[25693]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Sun Aug 18 11:21:04 2019 daemon.notice pppd[25693]: pppd 2.4.7 started by root, uid 0
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: Send PPPOE Discovery V1T1 PADI session 0x0 length 10
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  dst ff:ff:ff:ff:ff:ff  src e8:94:f6:xx:xx:xx
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  [service-name] [PPP-max-payload  05 dc]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 48
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  dst e8:94:f6:xx:xx:xx  src 9c:cc:83:c6:e7:e5
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  [AC-name dr23.2f300] [PPP-max-payload  05 dc] [service-name] [AC-cookie  95 2a ff 50 17 66 d5 64 ca d3 85 21 31 48 4c 5a] [end-of-list]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: Send PPPOE Discovery V1T1 PADR session 0x0 length 30
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  dst 9c:cc:83:c6:e7:e5  src e8:94:f6:xx:xx:xx
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  [service-name] [PPP-max-payload  05 dc] [AC-cookie  95 2a ff 50 17 66 d5 64 ca d3 85 21 31 48 4c 5a]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 46
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  dst e8:94:f6:xx:xx:xx  src 28:8a:1c:e0:90:ce
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  [AC-name dr13.d12] [PPP-max-payload  05 dc] [service-name] [AC-cookie  95 2a ff 50 17 66 d5 64 ca d3 85 21 31 48 4c 5a] [end-of-list]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: Recv PPPOE Discovery V1T1 PADS session 0x5e8 length 48
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  dst e8:94:f6:xx:xx:xx  src 9c:cc:83:c6:e7:e5
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]:  [service-name] [PPP-max-payload  05 dc] [AC-name dr23.2f300] [AC-cookie  95 2a ff 50 17 66 d5 64 ca d3 85 21 31 48 4c 5a] [end-of-list]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: PADS: Service-Name: ''
Sun Aug 18 11:21:04 2019 daemon.info pppd[25693]: PPP session is 1512
Sun Aug 18 11:21:04 2019 daemon.warn pppd[25693]: Connected to 9c:cc:83:c6:e7:e5 via interface eth0.6
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: using channel 3
Sun Aug 18 11:21:04 2019 kern.info kernel: [ 7290.713409] pppoe-wan: renamed from ppp0
Sun Aug 18 11:21:04 2019 daemon.info pppd[25693]: Using interface pppoe-wan
Sun Aug 18 11:21:04 2019 daemon.notice pppd[25693]: Connect: pppoe-wan <--> eth0.6
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: sent [LCP ConfReq id=0x1 <magic 0x5e30b453>]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: rcvd [LCP ConfReq id=0xcd <auth pap> <magic 0x6468dcca>]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: sent [LCP ConfAck id=0xcd <auth pap> <magic 0x6468dcca>]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: rcvd [LCP ConfAck id=0x1 <magic 0x5e30b453>]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: sent [LCP EchoReq id=0x0 magic=0x5e30b453]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: sent [PAP AuthReq id=0x1 user="xs4all" password=<hidden>]
Sun Aug 18 11:21:04 2019 daemon.debug pppd[25693]: rcvd [LCP EchoRep id=0x0 magic=0x6468dcca]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: rcvd [PAP AuthAck id=0x1 ""]
Sun Aug 18 11:21:05 2019 daemon.notice pppd[25693]: PAP authentication succeeded
Sun Aug 18 11:21:05 2019 daemon.notice pppd[25693]: peer from calling number 9C:CC:83:C6:E7:E5 authorized
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: sent [IPV6CP ConfReq id=0x1 <addr fe80::5826:c57e:ee5d:0efe>]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: rcvd [IPCP ConfReq id=0x2f <addr 194.109.5.205>]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: sent [IPCP ConfAck id=0x2f <addr 194.109.5.205>]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: rcvd [IPCP ConfNak id=0x1 <addr 80.100.x.x> <ms-dns1 194.109.6.66> <ms-dns2 194.109.9.99>]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: sent [IPCP ConfReq id=0x2 <addr 80.100.x.x> <ms-dns1 194.109.6.66> <ms-dns2 194.109.9.99>]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: rcvd [IPV6CP ConfReq id=0xa1 <addr fe80::9ecc:83ff:fec6:e7e5>]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: sent [IPV6CP ConfAck id=0xa1 <addr fe80::9ecc:83ff:fec6:e7e5>]
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: rcvd [IPCP ConfAck id=0x2 <addr 80.100.x.x> <ms-dns1 194.109.6.66> <ms-dns2 194.109.9.99>]
Sun Aug 18 11:21:05 2019 daemon.notice pppd[25693]: local  IP address 80.100.x.x
Sun Aug 18 11:21:05 2019 daemon.notice pppd[25693]: remote IP address 194.109.5.205
Sun Aug 18 11:21:05 2019 daemon.notice pppd[25693]: primary   DNS address 194.109.6.66
Sun Aug 18 11:21:05 2019 daemon.notice pppd[25693]: secondary DNS address 194.109.9.99
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: Script /lib/netifd/ppp-up started (pid 25755)
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::5826:c57e:ee5d:0efe>]
Sun Aug 18 11:21:05 2019 daemon.notice pppd[25693]: local  LL address fe80::5826:c57e:ee5d:0efe
Sun Aug 18 11:21:05 2019 daemon.notice pppd[25693]: remote LL address fe80::9ecc:83ff:fec6:e7e5
Sun Aug 18 11:21:05 2019 daemon.debug pppd[25693]: Script /lib/netifd/ppp6-up started (pid 25756)
Sun Aug 18 11:21:06 2019 daemon.notice netifd: Network device 'pppoe-wan' link is up
Sun Aug 18 11:21:06 2019 daemon.notice netifd: Interface 'wan' is now up

And no, I cannot set an MTU of >1500 on the DrayTek. I have actually just e-mailed DrayTek asking them whether anything needs to be done about the MTU in MPoA Full Bridge Mode, but I doubt it.

This can be done by prepending the interface with '@':

	option ifname '@wan'