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#210 - ltq-RFC4638 PPPoE MTU support #5285

Closed
openwrt-bot opened this issue Oct 6, 2016 · 0 comments
Closed

FS#210 - ltq-RFC4638 PPPoE MTU support #5285

openwrt-bot opened this issue Oct 6, 2016 · 0 comments
Labels

Comments

@openwrt-bot
Copy link

dwmw2:

I have a TP-Link TDW8970, used with VDSL.

It seems to limit me to a PPP MTU of 1492. I need to increase the MTU on the ptm0 device to 1508 AIUI but it won't let me. Could it be as simple as providing our own ptm_change_mtu() will will tolerate a larger MTU, instead of using eth_change_mtu()?

@openwrt-bot
Copy link
Author

mkresin:

Your analysis seam correct to me. The lantiq ptm kernel module is using [[https://git.lede-project.org/?p=source.git;a=blob;f=package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c;h=41464e6c27765745aa0c6cd9ffbe07455ff19d6d;hb=HEAD#l117|eth_change_mtu]] which allows only [[http://lxr.free-electrons.com/source/net/ethernet/eth.c?v=4.4#L320|MTUs up to ETH_DATA_LEN]]. And [[http://lxr.free-electrons.com/source/include/uapi/linux/if_ether.h?v=4.4#L34|ETH_DATA_LEN is 1500]].

Means a ptm_change_mtu() is required which accepts values up to ETH_DATA_LEN+8 (mini jumbo frames). That doesn't necessarily means that it works in the end. There might be other (hardware related) limitations.

Would you please try to add the function and report back! If it works for you, please submit a patch either via the lede-dev mailing list or via github pull request.

@openwrt-bot
Copy link
Author

dwmw2:

The really naïve test seems to work...

--- a/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c +++ b/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c @@ -107,6 +107,14 @@ static int g_queue_gamma_map[4];

static struct ptm_priv_data g_ptm_priv_data;

+static int ptm_change_mtu(struct net_device *dev, int new_mtu)
+{

  •    if (new_mtu < 68 || new_mtu > ETH_DATA_LEN + 8)
    
  •            return -EINVAL;
    
  •    dev->mtu = new_mtu;
    
  •    return 0;
    

+}
+
static struct net_device_ops g_ptm_netdev_ops = {
.ndo_get_stats = ptm_get_stats,
.ndo_open = ptm_open,
@@ -114,7 +122,7 @@ static struct net_device_ops g_ptm_netdev_ops = {
.ndo_start_xmit = ptm_hard_start_xmit,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,

  • .ndo_change_mtu = eth_change_mtu,
  • .ndo_change_mtu = ptm_change_mtu,
    .ndo_do_ioctl = ptm_ioctl,
    .ndo_tx_timeout = ptm_tx_timeout,
    };

I can then ping it from the outside:

$ ping 217.169.22.43 -s 1472 -M do
PING 217.169.22.43 (217.169.22.43) 1472(1500) bytes of data.
1480 bytes from 217.169.22.43: icmp_seq=1 ttl=59 time=20.4 ms

I'm slightly confused though, because I have a VLAN too; ptm0.101.

config switch_vlan 'ptm0_101' option device 'ptm0' option vlan '101' option vid '101'

config interface 'aa101'
option ifname 'ptm0.101'
option proto 'static'
option mtu '1508'

config interface 'ptm0'
option mtu '1508'

If I run tcpdump on the ptm0.101 interface, that looks fine:

11:21:32.598772 PPPoE [ses 0x24de] IP (tos 0x0, ttl 64, id 40501, offset 0, flags [none], proto ICMP (1), length 1500)
adsl-2.infradead.org > casper.infradead.org: ICMP echo reply, id 30233, seq 5, length 1480
0x0000: 0030 881e 9065 0020 da86 2375 8864 1100 .0...e....#u.d..
0x0010: 24de 05de 0021 4500 05dc 9e35 0000 4001 $....!E....5..@.
...
0x05e0: aeaf b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd ................
0x05f0: bebf ..

But... on the ptm0 interface, obviously I have extra VLAN overhead:

11:22:48.287214 PPPoE [ses 0x24de] IP (tos 0x0, ttl 64, id 43141, offset 0, flags [none], proto ICMP (1), length 1500) adsl-2.infradead.org > casper.infradead.org: ICMP echo reply, id 30370, seq 2, length 1480 0x0000: 0030 881e 9065 0020 da86 2375 8100 0065 .0...e....#u...e 0x0010: 8864 1100 24de 05de 0021 4500 05dc a885 .d..$....!E..... ... 0x05e0: aaab acad aeaf b0b1 b2b3 b4b5 b6b7 b8b9 ................ 0x05f0: babb bcbd bebf ......

It's working, but why? That packet is larger than the 1508 bytes I configured as the MTU for the ptm0 interface. Why don't I need to configure 1512 for ptm0 and 1508 for ptm0.101? Is that a bug somewhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant