Print

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

[johnson]

j0hn could you try a 1472 byte ping to cloudflare?

[j0hn]

Code: [Select]

^Cpi@raspberrypi:~ $ ping -4 -M do -s 1464 -c 4 cloudflare.com
PING cloudflare.com (198.41.214.162) 1464(1492) bytes of data.
1472 bytes from 198.41.214.162: icmp_seq=1 ttl=57 time=96.7 ms
1472 bytes from 198.41.214.162: icmp_seq=2 ttl=57 time=22.1 ms
1472 bytes from 198.41.214.162: icmp_seq=3 ttl=57 time=22.4 ms
1472 bytes from 198.41.214.162: icmp_seq=4 ttl=57 time=22.3 ms

--- cloudflare.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 22.133/40.926/96.772/32.243 ms
pi@raspberrypi:~ $ ping -4 -M do -s 1472 -c 4 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.

--- cloudflare.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3133ms
Looks like they don't support 1472 MTU?
I can't see why else some hosts would work and others not.

[highpriest]

Looks like they don't support 1472 MTU?
I can't see why else some hosts would work and others not.

They definitely support it.

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=61 time=0.978 ms
1480 bytes from 198.41.214.162: icmp_seq=2 ttl=61 time=1.20 ms
1480 bytes from 198.41.214.162: icmp_seq=3 ttl=61 time=1.13 ms

--- cloudflare.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.978/1.103/1.200/0.096 ms

This is from a Linode VPS.

[burakkucat]

A ZyXEL VMG1312-B10A is used at The Cattery and the MTU is configured as 1500 from the GUI. Testing shows --

Code: [Select]

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.04.08 14:03
IP address: xxx.xxx.xxx.xxx
Client OS/browser: Linux (Firefox 52.0)
 
TCP options string: 020405b40402080a015972080000000001030307
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: 49
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)

Pinging various targets --

Code: [Select]

[Duo2 ~]$ ping -M do -s 1472 -c 3 bbc.co.uk
PING bbc.co.uk (151.101.64.81) 1472(1500) bytes of data.
1480 bytes from 151.101.64.81: icmp_seq=1 ttl=57 time=52.4 ms
1480 bytes from 151.101.64.81: icmp_seq=2 ttl=57 time=52.1 ms
1480 bytes from 151.101.64.81: icmp_seq=3 ttl=57 time=53.2 ms

--- bbc.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2056ms
rtt min/avg/max/mdev = 52.170/52.626/53.270/0.468 ms
[Duo2 ~]$

[Duo2 ~]$ 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=58 time=53.5 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=56.1 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=58.4 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2062ms
rtt min/avg/max/mdev = 53.599/56.069/58.493/2.007 ms
[Duo2 ~]$

[Duo2 ~]$ 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=57 time=51.6 ms
1480 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=51.3 ms
1480 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=53.0 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2056ms
rtt min/avg/max/mdev = 51.318/52.012/53.049/0.769 ms
[Duo2 ~]$

[Duo2 ~]$ 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=57 time=51.4 ms
1480 bytes from 198.41.214.162: icmp_seq=2 ttl=57 time=51.0 ms
1480 bytes from 198.41.214.162: icmp_seq=3 ttl=57 time=49.5 ms

--- cloudflare.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2052ms
rtt min/avg/max/mdev = 49.503/50.675/51.441/0.861 ms
[Duo2 ~]$


[j0hn]

The problem seems to only exist with bridging PPPoe

https://support.aa.net.uk/VMG1312-B10A:_Bugs

Bridging 1508 bytes ethernet
Issue Description
Bridging does work, but we'd very much like the router to support baby jumbo frames bridging to VDSL and ADSL, to support *at least* 1508 bytes to allow RFC4638 PPPoE to a connected device.

Date Reported
2015-02-19

2016-10-24 Sadly (even though the hardware can support it) ZyXEL have told us that they will not be adding support for baby jumbo frames.

Resolution
Not going to be supported. (sorry)

This is where being with an ISP like AAISP pays off. They have the technical ability to help diagnose these issues.
They have sold/issued large amounts of these modems so they may be interested in helping.

[GigabitEthernet]

My understanding (as confirmed by the AAISP bug above), was under bridging it doesn't work.

The only modem I know that works with bridged PPPoE is the Huawei HG612!

[highpriest]

A ZyXEL VMG1312-B10A is used at The Cattery and the MTU is configured as 1500 from the GUI. Testing shows --

Are you on ADSL, burakkucat? Looks like it is working perfectly for you. I still can't explain why I can ping some with a 1472 byte payload and not others.

tcpdump shows echo replies from 8.8.8.8...

Code: [Select]

ubnt@ubnt:~$ sudo tcpdump host 192.168.1.9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on switch0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:35:01.078275 IP 192.168.1.9 > google-public-dns-a.google.com: ICMP echo request, id 2887, seq 1, length 1480
14:35:01.090980 IP google-public-dns-a.google.com > 192.168.1.9: ICMP echo reply, id 2887, seq 1, length 1480
14:35:02.079648 IP 192.168.1.9 > google-public-dns-a.google.com: ICMP echo request, id 2887, seq 2, length 1480
14:35:02.092094 IP google-public-dns-a.google.com > 192.168.1.9: ICMP echo reply, id 2887, seq 2, length 1480
14:35:03.080804 IP 192.168.1.9 > google-public-dns-a.google.com: ICMP echo request, id 2887, seq 3, length 1480
14:35:03.093998 IP google-public-dns-a.google.com > 192.168.1.9: ICMP echo reply, id 2887, seq 3, length 1480

But nothing from cloudflare.com.

Code: [Select]

14:35:15.137375 IP 192.168.1.9 > 198.41.215.162: ICMP echo request, id 2888, seq 1, length 1480
14:35:16.157058 IP 192.168.1.9 > 198.41.215.162: ICMP echo request, id 2888, seq 2, length 1480
14:35:17.180946 IP 192.168.1.9 > 198.41.215.162: ICMP echo request, id 2888, seq 3, length 1480


[johnson]

I still can't explain why I can ping some with a 1472 byte payload and not others.

This is what makes it so infuriating. PPPoE -> modem -> VDSL cab and beyond are clearly passing 1500 byte packets, why does the server you communicate with matter?

Think I'l break out the HG612 this evening to see if its the same.

[highpriest]

This is what makes it so infuriating. PPPoE -> modem -> VDSL cab and beyond are clearly passing 1500 byte packets, why does the server you communicate with matter?

Think I'l break out the HG612 this evening to see if its the same.

Heh, exactly! I was thinking of resurrecting the HG612 as well. I've got one here somewhere.

[burakkucat]

Are you on ADSL, burakkucat? Looks like it is working perfectly for you.

Yes, that is correct. The circuit is set to use only G.992.3  and not G.992.5 nor G.992.1

[Chrysalis]

Its sad cause in a video recorded at one of the broadband uk events, the BT guy said he wanted to ditch pppoe due to how crap it is, yet BT kept it in the end on g.fast so its here for a while yet.

Bad MTU sizes is the one obvious problem alongside the high cpu resources required on pppoe, horrible protocol.

Its one of the major reasons I am still on sky, I have wanted to move to aaisp for a while but MER has kept me on sky.

[highpriest]

Heh, exactly! I was thinking of resurrecting the HG612 as well. I've got one here somewhere.

Dusted off the HG612, installed the unlocked firmware (B030SP08 with GUI) and it handles baby jumbos perfectly. Everything works flawlessly.

I find it annoying that I have to switch to a nearly 10 year old device to get this working

I've acquired a cheap BT Business Smart Hub off of eBay and will be testing that when it arrives (it supports bridge mode).

[highpriest]

Yes, that is correct. The circuit is set to use only G.992.3  and not G.992.5 nor G.992.1

Off-topic, but why disable ADSL2+?

[burakkucat]

Off-topic, but why disable ADSL2+?

Due to the overall length of the circuit, the sub-carriers from 256 to 512 are never used. 

When a 2Wire 2700HG-B was used, it would always attempt to synchronise using G.992.5 but after reporting an inconsistent signal would drop back to G.992.3 . . . The diagnostic pages of the 2Wire devices were very useful in displaying the circuit's status, including bit-loading. Subsequent to those historic events, I have checked with more capable devices (e.g. ZyXEL VMGxxxx-B10x) and have shown that G.993.2 is optimum.

[highpriest]

This is interesting. Looks like AAISP is actively working with ZyXEL to add RFC4638 support on the two devices supplied by AA (the VMG3925-B10B and the VMG1312-B10D).

https://support.aa.net.uk/Category:ZyXEL_VMG3925_B10B

MTU 1500 when in bridge mode not possible yet, but we are working with ZyXEL on this. (2018-03)

https://support.aa.net.uk/Category:ZyXEL_VMG1312_B10D

MTU 1500 when in bridge mode not possible yet, but we are working with ZyXEL on this. (2017-11)

Here's hoping they add this to all their devices in the near future.