Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#2667 - Lantiq specific, "dsl interfae" VDSL driver, unhelpful default MTU!. #7472

Open
openwrt-bot opened this issue Dec 10, 2019 · 4 comments
Labels
flyspray release/19.07

Comments

@openwrt-bot
Copy link

openwrt-bot commented Dec 10, 2019

enyc:

Probably, FAO "John Crispin" Lantiq maintainer, apparently!,

On OpenWRT 19.07.0rc2, both on TP-LINK TD-W8980 and also BT-Homehub-v5-type-A [lantiq xrx200 devices] ...

I am finding a consistent frustrating limitation, that the default config, and LuCI web interface, does not provide any way to expose the MTU capability of the built-in VDSL driver, which allows for full 1500 MTU to be carried on PPPoE on VDSL, as is commonplace in provided routers.

Specifically, the VDSL device "dsl0" (and, in my case, VLAN 101, "dsl0.101"), has an unhelpful default MTU restriction to 1500, such that PPPoE (as is common in UK!) does not work at the normally expected 1500MTU, requiring workarounds 1492MTU MSS-clamping hacks. Turns out this is fixable at the configuration-level, but not via anything exposed in web-interface (as underlying DSL MTU is wrong from the start...).

Example below, extra /etc/config/network lines to support the standard MTU:-

==========================================================================

config interface 'wan'
option ifname 'dsl0.101'
option proto 'pppoe'
option password 'PASSWORD'
option ipv6 'auto'
option username 'USERNAME'
option mtu '1500' #exposed via web, still needs setting, to try to negotiate that MTU 1500 inside PPPoE...

config device 'wan_dev'
option name 'dsl0'
option macaddr 'e8:11:22:33:44:4b'
option mtu '1508' #This line Had to be added manually

config device 'wan_dev2' # Extra section added, if not done,
option name 'dsl0.101' # MTU wrong for the dsl 0.101 link!
option macaddr 'e8:11:22:33:44:4b' # As in this case having to use VLAN101
option mtu '1508' # As per UK Openreach VDSL configuration...

==========================================================================

In my view, at the very least, the 'internal' DSL driver, should be allowing a larger mtu like 1508, 'by default'. Possibly, if this is done at driver level, the PPPoE MTU won't need to be specified at all.

The PPPoE over VDSL configuration, also needed to be told to attempt 1500 MTU, which I understand relies upon rfc4638 PPP extension, in order to have fully functional 1500MTU connection. Not having this has caused connectivity issues requiring MSS clamping etc. and is, in short, undesirable!.

It think, the PPPoE over PTM over VDSL should, additionally, attempt this 1500-MTU 'by default' unless the MTU is reduced manually in the configuration.

I understand this should be passed to Lantiq maintainer, "John Crispin" apparently!, according to IRC-discussions!.

With many thanks,

@openwrt-bot
Copy link
Author

openwrt-bot commented Dec 10, 2019

moeller0:

It think, the PPPoE over PTM over VDSL should, additionally, attempt this 1500-MTU 'by default' unless the MTU is reduced manually in the configuration.

I am pretty sure that with the incumbent Telekom in Germany MTU > 1500 is not actually a valid configuration so we first would need to confirm that your proposed change does not render PPPE links in other parts of the world inoperable by default. Losing 8 Bytes of potential packet size might be annoying, but it certainly beats not getting a PPPoE connection up and running in the first place. Also, if the PPPoE terminating Openwrt router does not also house the modem, you will need to make sure a valid MTU1508 path exists all the way to the modem (so jumbo frames need to be opartional and configured for the rputer's WAN-side interface and the modem's LAN-side interface).

Have you thought about adding your instruction to the ISP configurations wiki page: [[http://example.com|External Linkhttps://openwrt.org/docs/guide-user/network/wan/isp-configurations]] as a work-around?

@openwrt-bot
Copy link
Author

openwrt-bot commented Dec 10, 2019

enyc:

moeller0,
Totally agree defaults and configurability for PPPoE need careful testing, seems that I have opened a can-of-worms here, turns out there are many difficulties with config system and interface and getting correct mtu through to PPPoE etc.
THIS bug report is mostly about the VDSL-internal-MTU dsl0 being bad-by-default and not the PPPoE-mtu/fallback aspects...
I wonder, particularly, if RFC4638 fallback in current pppd, covers the potential snag you mention!, or if e.g. the discontiuity between pppd and interface-MTU-settings, will go wrong, again.

@openwrt-bot
Copy link
Author

openwrt-bot commented Dec 10, 2019

enyc:

FIRSTLY: Turns out that not all the mtu-overrides/sections in my original report are necessarially required, I'm new to this issue and may have made mistakes!.

SECONDLY, for record, jow points out this raises 3 points in terms of OpenWRT improvements of MTU handling and related generally:-

  1. LuCI needs to gain support for managing "config device" (this is known already)
  2. ppp.sh needs to start honouring "config device" settings for the target device (pppoe-xyz)
  3. netifd's handling of "option mtu" in the "config interface" context needs a complete overhaul - or ideally it should be deprecated entirely as it is not well defined and full of quirks

However the "dsl driver does not offer proper mtu by default on INTERNAL dsl0* interface(s)" underpinning issue, still stands!. Would like Lantiq maintainer to look at this aspect, please!.

@openwrt-bot
Copy link
Author

openwrt-bot commented Dec 11, 2019

enyc:

To be clear, the config example above, sort-of-worked, interfaces set with suitable MTU, but the PPPd is called with MTU 1492 which now creates a blackhole for 1500 byte IP packets!. This goes back to the point about configuration structure overhaul.

@aparcar aparcar added the release/19.07 label Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray release/19.07
Projects
None yet
Development

No branches or pull requests

2 participants