Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[johnson]

The often suggested ZyXEL modems on this forum have great performance, but to my knowledge none support RFC 4638 with MTUs over 1492 for PPPoE connections in bridge mode. As far as I understand, all BT based FTTC connections should support it, but working examples to google are thin on the ground.

Other modems I am aware of with BCM63168 chipset:
Billion 8800nl
Netgear D6400
BT HH5B?

Does anyone have experience with one that can support over 1492 MTU when used as a modem in bridge mode?

[Moderator edited as per thread creator's request.]

[highpriest]

I'm on the lookout as well

I can't get it working on my Zyxel 8324. I'm currently playing around with a TG589vac v2. But for some reason I can't even get the PPP client on the EdgeRouter to establish a session

Will report back when I know more.

[highpriest]

TG589vac v2 is a no go. Managed to get it working as a bridged modem, but it doesn't support RFC4638 (firmware 17.2).

[johnson]

Well I finally got around to playing with MTU settings with the VMG1312 and I feel like I must be missing something but it seems to be working.

After setting a 1508 mtu on the wan interface of a router running openwrt (x86 box with seperate lan cards for wan & lan) it negotiated a ppp session with 1500 byte payload:

Code: [Select]

daemon.notice pppd[1630]: pppd 2.4.7 started by root, uid 0
daemon.debug pppd[1630]:  Send PPPOE Discovery V1T1 PADI session 0x0 length 10
daemon.debug pppd[1630]:  dst ff:ff:ff:ff:ff:ff  src 00:00:00:00:00:00
daemon.debug pppd[1630]:  [service-name] [PPP-max-payload  05 dc]
daemon.debug pppd[1630]:  Recv PPPOE Discovery V1T1 PADO session 0x0 length 48
daemon.debug pppd[1630]:  dst 00:00:00:00:00:00  src 00:00:00:00:00:00
daemon.debug pppd[1630]:  [AC-name some.thing-here] [PPP-max-payload  05 dc] [service-name] [AC-cookie  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
daemon.debug pppd[1630]:  Send PPPOE Discovery V1T1 PADR session 0x0 length 30
daemon.debug pppd[1630]:  dst 00:00:00:00:00:00  src 00:00:00:00:00:00
daemon.debug pppd[1630]:  [service-name] [PPP-max-payload  05 dc] [AC-cookie  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
daemon.debug pppd[1630]:  Recv PPPOE Discovery V1T1 PADS session 0x3e9 length 48
daemon.debug pppd[1630]:  dst 00:00:00:00:00:00  src 00:00:00:00:00:00
daemon.debug pppd[1630]:  [service-name] [PPP-max-payload  05 dc] [AC-name some.thing-here] [AC-cookie  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
daemon.debug pppd[1630]:  PADS: Service-Name: ''
daemon.info pppd[1630]:   PPP session is 1001
daemon.warn pppd[1630]:   Connected to 00:00:00:00:00:00 via interface eth2

0x05dc = 1500 for the "PPP-max-payload"

ifconfig on the router then shows a 1500 mtu for the pppoe-WAN interface where it showed 1492 before

Pings get fragmented if over 1464 still, but if you telnet into the VMG1312 and change first the ptm0 and them ptm0.1 interface to 1508 using:

Code: [Select]

ifconfig ptm0 mtu 1508
ifconfig ptm0.1 mtu 1508

Then pings with payload of 1472 magically start working:

Code: [Select]

ping -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=18.6 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=19.0 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=19.5 ms
1480 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=18.2 ms
1480 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=18.8 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 18.222/18.863/19.567/0.470 ms

Seeing as nothing breaks after setting the WAN port of the openwrt router to 1508, having to run 2 cmds on the modem after a reboot to get it working doesnt seem an issue.

Why I'm sceptical as to whether this result is accurate is that using the tester at http://www.letmecheck.it/ I still get a discovered MTU of 1492. Any idea why I can send unfragmented ICMP packets at 1500 but this test fails? I'l add that when I tried the tester there before with a definite 1492 pppoe connection from the router to modem it comes back with 1500 discovered... *scratches head*

Also tried the exact same steps on a billion 8800nl, same result.

Am I missing something? Is the test for fragmentation I'm using wrong? Have also tried:

Code: [Select]

ping -f -l 1472 8.8.8.8
From a windows 7 VM and got no DF set fragmentation message.

[j0hn]

Asus RT-AC68U running AsusWRT-Merlin with a Zyxel VMG1312-B10A in bridge mode.
Following the advice above....

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=1472 time=19ms TTL=58

Letmecheckit isn't working from my laptop though, i get the error...
This IP is being shared among many domains.
To view the domain you are looking for, simply enter the domain name in the location bar of your web browser.

[johnson]

Thanks for trying it out j0hn.

Weird error you are getting from the site, working for me albeit still giving 1492 from the MTU check.

[highpriest]

Pings get fragmented if over 1464 still, but if you telnet into the VMG1312 and change first the ptm0 and them ptm0.1 interface to 1508 using:

Code: [Select]

ifconfig ptm0 mtu 1508
ifconfig ptm0.1 mtu 1508

Then pings with payload of 1472 magically start working:

Code: [Select]

ping -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=18.6 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=19.0 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=19.5 ms
1480 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=18.2 ms
1480 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=18.8 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 18.222/18.863/19.567/0.470 ms

Seeing as nothing breaks after setting the WAN port of the openwrt router to 1508, having to run 2 cmds on the modem after a reboot to get it working doesnt seem an issue.

Nice find! Didn't think of doing that on my 8324. Will give that a go.

I did try altering the WAN IP connection (downloaded config, changed and uploaded the altered config back to the device) but it didn't do anything.

Code: [Select]

        <WANIPConnection instance="1">
          <Enable>TRUE</Enable>
          <ConnectionType>IP_Bridged</ConnectionType>
          <Name>VDSL</Name>
          <ExternalIPAddress>(null)</ExternalIPAddress>
          <SubnetMask>(null)</SubnetMask>
          <DefaultGateway>(null)</DefaultGateway>
          <MaxMTUSize>1508</MaxMTUSize>
          <MACAddress>90:EF:68:A0:FF:A0</MACAddress>
          <X_5067F0_IfName>ptm0.1</X_5067F0_IfName>
          <X_5067F0_ConnectionId>1</X_5067F0_ConnectionId>
          <X_5067F0_VlanMux8021p>2</X_5067F0_VlanMux8021p>
          <X_5067F0_VlanMuxID>101</X_5067F0_VlanMuxID>
          <PortMappingNumberOfEntries>0</PortMappingNumberOfEntries>
          <X_5067F0_Op43Enabled>TRUE</X_5067F0_Op43Enabled>
          <X_5067F0_IPv6Enabled>TRUE</X_5067F0_IPv6Enabled>
          <X_5067F0_IPv6WanMode>1</X_5067F0_IPv6WanMode>
        </WANIPConnection>


Why I'm sceptical as to whether this result is accurate is that using the tester at http://www.letmecheck.it/ I still get a discovered MTU of 1492. Any idea why I can send unfragmented ICMP packets at 1500 but this test fails? I'l add that when I tried the tester there before with a definite 1492 pppoe connection from the router to modem it comes back with 1500 discovered... *scratches head*

That's odd. Do you have MSS clamping configured on the router? What does this tester show?

https://www.speedguide.net/analyzer.php

[johnson]

Speedguide results:

Code: [Select]

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.04.08 08:40
IP address: xx.xx.xx.xxx
Client OS/browser: Linux (Firefox 59.0)
 
TCP options string: 020405b40402080ae5636c2f0000000001030307
MSS: 1460
MTU: 1500
TCP Window: 29312 (not multiple of MSS)
RWIN Scaling: 7 bits (2^7=128)
Unscaled RWIN : 229
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 1172kbps (147KBytes/s)
BDP limit (500ms): 469kbps (59KBytes/s)
MTU Discovery: ON
TTL: 52
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)

Also:

Code: [Select]

MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1448, which is less than MSS because of Timestamps, or other TCP/IP options used.

for clarity.


The MSS of 1460 seems right, but is 1448 of usable data?

Do you have MSS clamping configured on the router?

I have whatever the default is on openwrt which seems from https://wiki.openwrt.org/doc/uci/firewall#defaults to be off with "mtu_fix" 0.

[j0hn]

Code: [Select]

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.04.08 09:06
IP address: xx.xx.xx.xx
Client OS/browser: Windows 10 (Chrome 65.0.3325.181)
 
TCP options string: 020405b40103030801010402
MSS: 1460
MTU: 1500
TCP Window: 65536 (not multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 256
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 2621kbps (328KBytes/s)
BDP limit (500ms): 1049kbps (131KBytes/s)
MTU Discovery: ON
TTL: 110
Timestamps: OFF
SACKs: ON
IP ToS: 01001000 (72)
    Precedence: 010 (immediate)
    Delay: 0 (normal delay)
    Throughput: 1 (high throughput)
    Reliability: 0 (normal reliability)
    Cost: 0 (normal cost)
    Check bit: 0 (correct)
DSCP (DiffServ): AF21 010010 (18) - Assured Forwarding class 2, low drop precedence (RFC 2597).


[highpriest]

Changing the MTU to 1508 on the two ptm interfaces works for me too

The MSS of 1460 seems right, but is 1448 of usable data?

I don't get that though.

Code: [Select]

MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.
Full results:

Code: [Select]

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.04.08 09:11
IP address: xx.xx.xx.xx
Client OS/browser: Windows 10 (Chrome 65.0.3325.181)
 
TCP options string: 020405b40103030801010402
MSS: 1460
MTU: 1500
TCP Window: 65536 (not multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 256
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 2621kbps (328KBytes/s)
BDP limit (500ms): 1049kbps (131KBytes/s)
MTU Discovery: ON
TTL: 116
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

[smf22]

Thanks for trying it out j0hn.

Weird error you are getting from the site, working for me albeit still giving 1492 from the MTU check.

I was seeing the same error on the letmecheck.it site and found that this is seen when connecting via IPv6. When using IPv4 the page / site displays correctly.

Speedguide results:

Code: [Select]

MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1448, which is less than MSS because of Timestamps, or other TCP/IP options used.

for clarity.

The MSS of 1460 seems right, but is 1448 of usable data?

The 1448 byte Maximum Segment Size (MSS) you're using is due to the TCP Timestamp option that is enabled on your host. As per section 1.3 of RFC 7323 TCP Extensions for High Performance:

The Timestamps option may appear in any data or <ACK> segment, adding 10 bytes (up to 12 bytes including padding) to the 20-byte TCP header.

[johnson]

Changing the MTU to 1508 on the two ptm interfaces works for me too

Great stuff!

The 1448 byte Maximum Segment Size (MSS) you're using is due to the TCP Timestamp option that is enabled on your host. As per section 1.3 of RFC 7323 TCP Extensions for High Performance:

Thanks smf22, disabled it with "echo 0 > /proc/sys/net/ipv4/tcp_timestamps" and get:

Code: [Select]

MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.

Are there any downsides to removing the timestamp?

[highpriest]

Getting some slightly odd results.

I can ping 8.8.8.8 and bbc.co.uk using a packet size of 1472.

Code: [Select]

pi@raspi3a:~ $ ping -M do -s 1472 -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=13.2 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=13.2 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=13.1 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 13.159/13.231/13.294/0.109 ms

pi@raspi3a:~ $ ping -M do -s 1472 -c 3 bbc.co.uk
PING bbc.co.uk (151.101.0.81) 1472(1500) bytes of data.
1480 bytes from 151.101.0.81: icmp_seq=1 ttl=60 time=13.0 ms
1480 bytes from 151.101.0.81: icmp_seq=2 ttl=60 time=13.4 ms
1480 bytes from 151.101.0.81: icmp_seq=3 ttl=60 time=13.0 ms

--- bbc.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 13.057/13.183/13.419/0.191 ms
But not these:

Code: [Select]

pi@raspi3a:~ $ ping -M do -s 1472 -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2093ms

pi@raspi3a:~ $ ping -M do -s 1472 -c 3 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.

--- cloudflare.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2077ms

I can ping them fine from a VPS.

Code: [Select]

$ ping -M do -s 1472 -c 3 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.
1480 bytes from 198.41.214.162: icmp_seq=1 ttl=52 time=4.26 ms
1480 bytes from 198.41.214.162: icmp_seq=2 ttl=52 time=4.22 ms
1480 bytes from 198.41.214.162: icmp_seq=3 ttl=52 time=4.33 ms

--- cloudflare.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.225/4.277/4.338/0.070 ms

$ ping -M do -s 1472 -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=52 time=3.99 ms
1480 bytes from 1.1.1.1: icmp_seq=2 ttl=52 time=3.91 ms
1480 bytes from 1.1.1.1: icmp_seq=3 ttl=52 time=3.98 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.915/3.963/3.992/0.034 ms

[johnson]

Yeah this fails for me too:

Code: [Select]

ping -M do -s 1472 cloudflare.com

Bummer.


Edit: What ISP are you with highpriest? I'm on TTB.

[highpriest]

Yeah this fails for me too:

Code: [Select]

ping -M do -s 1472 cloudflare.com

Bummer.

Why though? Doesn't make sense.

Edit: What ISP are you with highpriest? I'm on TTB.

I'm with Zen.