mtu 1500 FTTC RFC RFC 4638 - asus routers

Merlin has kindly implemented changes at my request to allow this to be easily configured in the gui now.

changelog here.

for routers ac66u/ac68u/rt-n16u/rt-n66u.

http://www.lostrealm.ca/asuswrt-merlin/changelog.txt

?
It seems to be easy in the standard ASUS GUI, in that I can edit the field?

Mine on Plusnet is 1492, so I didn't Apply the change. Do you think it should be 1500?

1500 will work if you enable jumbo frames as well.

But this is a merlin firmware only change I dont think it will work in standard asuswrt as the gui as a failsafe will block a 1500 value been entered, traditional pppoe cannot do 1500 byte mtu.

Can you still ping bbc.co.uk with a 1500 packet?

ie. ping bbc.co.uk -l 1500

Maximum I can ping BBC is with a packet size of 1464, above that it fails.

I can however ping my isp with 1492.

Just out of interest would setting the MTU at 1500 cause packets to certain websites to fragment and cause inefficiency?

See my pings below...

C:\Users\Paul >ping bbc.co.uk -l 1464

Pinging bbc.co.uk [212.58.246.104] with 1464 bytes of data
Reply from 212.58.246.104: bytes=1464 time=30ms TTL=54
Reply from 212.58.246.104: bytes=1464 time=31ms TTL=54
Reply from 212.58.246.104: bytes=1464 time=32ms TTL=54
Reply from 212.58.246.104: bytes=1464 time=31ms TTL=54

Ping statistics for 212.58.246.104:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 32ms, Average = 31ms

C:\Users\Paul >ping bbc.co.uk -l 1465

Pinging bbc.co.uk [212.58.246.104] with 1465 bytes of data
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 212.58.246.104:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Paul >ping zen.co.uk -l 1492

Pinging zen.co.uk [212.23.0.100] with 1492 bytes of data:
Reply from 212.23.0.100: bytes=1492 time=28ms TTL=120
Reply from 212.23.0.100: bytes=1492 time=26ms TTL=120
Reply from 212.23.0.100: bytes=1492 time=26ms TTL=120
Reply from 212.23.0.100: bytes=1492 time=26ms TTL=120

Ping statistics for 212.23.0.100:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 28ms, Average = 26ms

I can when this is done properly yes. (I am on older firmware with my mtu manually configured).

bear in mind I havent tested this new firmware.

on older firmwares (using pppoe 3.11). One has to set the mtu manually in the command line, also jumbo frames has to be enabled as it requires the network device to have a mtu of 1508 to allow the extra 8 bytes overhead of pppoe. I am not sure if merlin accounted for this on his firmware changes.

so it may still need a mtu command in the command line to set the parent device to 1508 to work.

if you have flashed this firmware.
have enabled jumbo frames on the router.
have set 1500 bytes mtu

and cannot ping with unfragmented 1460 bytes then its not working as it should.

ping -f -l 1460 bbc.co.uk

if that fails set mtu back to 1492.

Edited by Chrysalis (Tue 04-Feb-14 22:59:41)

In reply to a post by Chrysalis:

Merlin has kindly implemented changes at my request to allow this to be easily configured in the gui now.

Excellent! Will have to give this a go.

In reply to a post by Chrysalis:

cannot ping with unfragmented 1460 bytes then its not working as it should.

ping -f -l 1460 bbc.co.uk

if that fails set mtu back to 1492.

Shouldn't the 1460 above be 1465 or more? 1492 MTU -28 = 1464 packet size.

If your MTU is actually 1492:
then ping -f -l 1465 bbc.co.uk should give 'Packet needs to be fragmented but DF set.'
but ping -f -l 1464 bbc.co.uk should be OK.

For an actual MTU of 1500 the biggest unfragmented packet is 1472.

Edited by XRaySpeX (Tue 04-Feb-14 23:48:00)

I assume you have read the current SIN 498, which includes:-

For example, if the reported downstream VDSL2 data rate is 40,000 kbit/s and the IP packet size is 1500 bytes (i.e. Ethernet frame size at End User LAN is 1514 bytes

and

The maximum supported Ethernet frame size is 1530 bytes (excluding IFG and pre-amble and single/double tag � see 2.1.3).

correct, sorry for misinformation, so 1472 bytes for a 1500 byte mtu. make sure the -f flag is on the ping command.

C:\windows\system32>ping -f -l 1472 bbc.co.uk

Pinging bbc.co.uk [212.58.246.104] with 1472 bytes of data:
Reply from 212.58.246.104: bytes=1472 time=17ms TTL=56
Reply from 212.58.246.104: bytes=1472 time=17ms TTL=56
Reply from 212.58.246.104: bytes=1472 time=17ms TTL=56
Reply from 212.58.246.104: bytes=1472 time=17ms TTL=56

Ping statistics for 212.58.246.104:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 17ms, Average = 17ms

Edited by Chrysalis (Wed 05-Feb-14 04:23:47)

In reply to a post by XRaySpeX:

In reply to a post by Chrysalis:

cannot ping with unfragmented 1460 bytes then its not working as it should.

ping -f -l 1460 bbc.co.uk

if that fails set mtu back to 1492.

Shouldn't the 1460 above be 1465 or more? 1492 MTU -28 = 1464 packet size.

If your MTU is actually 1492:
then ping -f -l 1465 bbc.co.uk should give 'Packet needs to be fragmented but DF set.'
but ping -f -l 1464 bbc.co.uk should be OK.

For an actual MTU of 1500 the biggest unfragmented packet is 1472.

So only out of interest how come I can ping Zen with a different packet size to BBC.co.uk?

Probably cuz it's fragmenting the packet and it's the 1st or early hop in Zen's network.

The proper test for MTU size is to use the '-f' flag in the ping and see when it stops fragmenting.

Don't confuse the MTU size with the ping's packet size; the former is +28 bytes larger than the latter to accommodate the protocol overheads.

if I get enough free time I will try to upgrade to this firmware this weekend and give a direct opinion on if it works with gui only configuration.

Nice to see RFC 4638 support gaining some traction.

I switched from an Asus to TPLink router running OpenWRT so can't take advantage of it, but hopefully OpenWRT will also support it soon.

Got this working with an RT-AC66U running Merlin 3.0.0.4.374.39.

This firmware does not fully support the enabling of RFC 4638 in the web interface because it only lets you set the ppp0 MTU/MRU to 1500.
For it to work properly you also need to enable baby jumbo frames on the WAN interface eth0.
I haven't enabled jumbo frames on the LAN switch yet as I don't understand why it would be needed.

Steps:
1) Set the MTU and MRU to 1500 in the web interface WAN settings for the ppp0 interface.
2) Enable baby jumbo frames (1508) on the WAN interface eth0 and set it every time the WAN interface starts. Create a UNIX text file /jffs/scripts/wan-start and insert the following:

#!/bin/sh
ifconfig eth0 mtu 1508 up

After rebooting, run ifconfig and check that the appropriate interfaces show the correct MTU.

On a connected device, test with: ping -f -l 1472 bbc.co.uk
and http://www.letmecheck.it/mtu-test.php

Pinging bbc.co.uk [212.58.244.20] with 1472 bytes of data:
Reply from 212.58.244.20: bytes=1472 time=8ms TTL=53
Reply from 212.58.244.20: bytes=1472 time=8ms TTL=53
Reply from 212.58.244.20: bytes=1472 time=8ms TTL=53
Reply from 212.58.244.20: bytes=1472 time=8ms TTL=53

Ping statistics for 212.58.244.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 8ms, Average = 8ms

Full support in OpenWRT is probably going to take forever but you can patch it yourself with this guide:
http://monki.org.uk/blog/2013/04/14/patching-openwrt...

Edited by CharlesBrown (Mon 24-Feb-14 14:32:33)

this is working 100% now in 374.40 beta

quote from changelog

- FIXED: PPPoE with an MTU of 1500 requires the WAN interface
to have its MTU set at 1508 (patch by pinwing)

So I set 1500 mtu and 1500 mru in gui, thats it, no cli commands needed, no extra ppp options needed.
Since my windows is set to auto mtu, I checked on speedguide,net and 1500 bytes reported.

C:\windows\system32>ping -f -l 1472 bbc.co.uk

Pinging bbc.co.uk [212.58.246.104] with 1472 bytes of data:
Reply from 212.58.246.104: bytes=1472 time=21ms TTL=56
Reply from 212.58.246.104: bytes=1472 time=20ms TTL=56
Reply from 212.58.246.104: bytes=1472 time=20ms TTL=56
Reply from 212.58.246.104: bytes=1472 time=20ms TTL=56

Ping statistics for 212.58.246.104:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 20ms, Maximum = 21ms, Average = 20ms

Edited by Chrysalis (Sat 01-Mar-14 15:25:20)

Thanks Chrysalis.
I'll stick with the stable version for now but can you check something for me with the beta please?
Type ifconfig at the shell and post the MTU values for all of the interfaces.
Cheers!

br0 1500
eth0 1508
eth1 1500
eth2 1500
lo 16436
ppp0 1500
vlan1 1500

normally I wouldnt use beta firmwares but I needed to test this as the previous build had broken ipv6.

Great, thanks - same as mine - looks like I've set it up correctly then

I am back on the older nov firmware I was using before, I was using the beta to confirm the ipv6 (and pppoe) are fine which they are but on ac66 routers its buggy on the wireless, the extension channel doesnt work on 5ghz when a channel is manually configured.

In reply to a post by Chrysalis:

...on ac66 routers its buggy on the wireless, the extension channel doesnt work on 5ghz when a channel is manually configured.

My AC66 has the same issue on Merlin 374.39, with 5Ghz channels set to either auto or manual. Web GUI shows two channels in use e.g. 42+44 but inSSIDer 3.1.2.1 shows the router only using the control channel (in this case 44).

Don't really want to flash 374.35_4 as it doesn't have MTU 1500 support.
I can live with the 5GHz issue for now.

You may be aware of this. InSSIDer often only shows one channel of the two except when the second is called into play. I have seen this on a few routers of my own, and also observing the surrounding ones.

When this occurs, the connection speed always continuously reflects the overall, not the single channel when only that is showing.

I wasn't aware, thanks.
The router must be working as intended then, as the connection speed continues to display 866.7Mbps in Windows.

In reply to a post by CharlesBrown:

In reply to a post by Chrysalis:

...on ac66 routers its buggy on the wireless, the extension channel doesnt work on 5ghz when a channel is manually configured.

My AC66 has the same issue on Merlin 374.39, with 5Ghz channels set to either auto or manual. Web GUI shows two channels in use e.g. 42+44 but inSSIDer 3.1.2.1 shows the router only using the control channel (in this case 44).

Don't really want to flash 374.35_4 as it doesn't have MTU 1500 support.
I can live with the 5GHz issue for now.

ahh so that issue as intriduced in an earlier version?

374.35_4 does have support just not in the GUI, here is a rundown.

374.35_4 has the latest pppoe which supports RFC 4638, however no gui support so has to be activated via custom options appended to pppoe using the extra options box and of course manually setting mtu in the CLI.
The FW build after 374.35_4 downgraded pppoe back to 3.10 which disabled RFC 4638 support.
Then in the 374.39 build you are using pppoe was reupgraded again to 3.11 reintroducing support but also the gui was unlocked allowing a value of 1500 to be entered in the mtu box. But of course you revealed the mtu on the interface still needs manually adjusting.
Then in 374.40 the 1508 interface adjustment became automated allowing it to be done fully via the gui.

So yes I havent used any builds in between 374.39 and 374.35_4, and I only used 374.39 very briefly due to the ipv6 issue meaning I never tested wireless on it, it's plausible the wifi bug was introducted on any build between 374.40 and 374.35_4.

So to verify we talking about the same bug.

on 374.35_4 I can manually select any channel on 5ghz, and a extension channel is added (in my case always 42 if a low channel number). There is no extension channel box on the wifi setup screen.
On 374.40 If I select a channel in the 36 to 64 range the extension channel is not added and the connection speed is very bad, to the point wireless N is faster than AC. I dont know what happens when manually selecting a high channel. If I select it to automatically choose a channel it uses a high channel above 100 and assigns a extension channel but since that range is much weaker my 5ghz speed is less than half its normal speed. There is a extension channel pull down menu on the wifi setup screen but its only option is auto.

Sounds about right?

Merlin seems very frustrated, he isnt responding to wifi problem reports, and issued a statement saying these bugs have all been introduced in the recent asus firmware's released in the past 3 month period and he is fighting a war to fix them, for this reason 374.40 will be the last release until asus start releasing stable firmware's again. It seems asus decided to rewrite various wifi and ipv6 code during this period.

--edit--

reread your post, seems you dont have this issue so I am assuming introduced in 374.40.

Edited by Chrysalis (Fri 07-Mar-14 17:23:20)

I am not using inssider, I am using the info that shows when hovering over the wifi logo at the top right of the firmware.

In terms of the connection speed I am using both the info displayed by windows on the network status window and throughput, throughput seems to reflect what windows reports.

Here is some data.

374.35_4 - channel 36 - BT AC dongle gets 866mbit connection speed (max for the dongle)
374.40 - channel 36 - dongle gets fluctuating speeds between about 150 and 210mbit/sec. throughput drops sharply to reflect this..
374.40 - auto channel which chooses a channel over 100, it connects usually at 400mbit, throughput is roughly double of '374.40 - channel 36' to reflect this.

374.40 - channel 36 seems to work better when selecting a 40mhz width but that of course is dropping down to lower spec, gives a 270mbit connection speed.

Edited by Chrysalis (Fri 07-Mar-14 17:09:08)

In reply to a post by Chrysalis:

374.35_4 does have support just not in the GUI, here is a rundown.

Thanks for the rundown, that really helps.

In reply to a post by Chrysalis:

So to verify we talking about the same bug.

On 374.39 I can manually choose from 36-48 or auto, in every case the extension channel pulldown only has one option (auto). If I choose auto for the control channel it always auto selects 36, and the extension channel is auto selected @ 40. If I manually choose a control channel like 44 then the extension channel is automatically set, to 42 in this case, and in all cases both channels are shown in the GUI when clicking on the wifi icon at the top right (42+44 or 36+40).

FTP or SMB transfer from PC to laptop maxes out at around 30 MB/s. I have yet to see higher throughput so I assumed that this was the max after overheads. This is the only firmware I've tried since buying the router.

Laptop with Intel 7260-AC 2x2 connected at 866.7Mbps, 2 or 3 feet away from router, writing to SSD.
PC wired to router, reading from SSD.

In reply to a post by Chrysalis:

It seems asus decided to rewrite various wifi and ipv6 code during this period.

That would explain it!

In reply to a post by Chrysalis:

--edit--
reread your post, seems you dont have this issue so I am assuming introduced in 374.40.

It does appear that I have a slightly different issue.

In reply to a post by RobertoS:

You may be aware of this. InSSIDer often only shows one channel of the two except when the second is called into play

Checked again, and inSSIDer only shows one channel in use, even during the file transfer, so the second channel is never called into play in my case - or maybe it is and it's just not being displayed. I've also tried the other channels with similar results.
There is a Virgin Superhub @ 5GHz in the neighbourhood which always shows two channels in use (36+40).
Pic

Edited by CharlesBrown (Fri 07-Mar-14 19:35:11)

Further update I am now using the 374.40 release version, the wifi issue is gone and wifi is better than I had before now.

However i had to do a recovery flash, I think somehow my config got corrupt.

In reply to a post by Chrysalis:

Further update I am now using the 374.40 release version, the wifi issue is gone and wifi is better than I had before now.

Good to know. I might update my 66U

However i had to do a recovery flash, I think somehow my config got corrupt.

That isn't good

yeah I dont think thats a 374.40 specific issue.

bear in mind I went from 374.35_4 to 374.39
then downgraded again
then up to 374.40 beta 1
then downgraded again

probably not the right thing to do

now I am back on 374.40 release version and things seem fine.

In reply to a post by Chrysalis:

now I am back on 374.40 release version and things seem fine.

Good I hit the button yesterday, set up MTU 1500 and its all working (don't have IPv6 yet) and I've no complaints.

WiFi both bands seems fine, as tested on my MacBook Air using WiFi Scanner, and on my corporate laptop using InSSIDer 3.

In reply to a post by Chrysalis:

now I am back on 374.40 release version and things seem fine.

You've gone up and down the versions so often I've lost track (), is 374.40 OK with IPv6?

its fine, Merlin has fixed the asus ipv6 bugs that stopped it working on plusnet with last few asus fw versions.

Great, thanks.

OpenWrt now supports this in trunk, so it'll be in the next release, Barrier Breaker.

No nice GUI for configuring it, but i'm willing to do it manually in exchange for all the other features OpenWrt provides. Good to finally see this making its way into firmwares (and since many manufacturers use OpenWrt as the basis for their own firmware it'll eventually trickle down to stock).

Here's how to enable it for the WDR4900 (and other routers using the same switch. WDR3600, WDR4300, etc).