1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Support for RFC4638 (PPPoE with >1492 MTU)

Discussion in 'Tomato Firmware' started by MiddlingMan, Jun 14, 2013.

  1. MiddlingMan

    MiddlingMan Addicted to LI Member

    In the UK, FTTC/FTTP is becoming more widely deployed (i just got it last week, yay!) and, while the current 1492 MTU for PPPoE in Tomato works fine, BT's new infrastructure can support a 1500 MTU (1508 with PPPoE overhead).

    Unfortunately it seems that BT's own Homehub is the only consumer router that actually supports this. OpenWRT doesn't support it out of the box but can be patched, and work on pfSense support hasn't begun yet.

    I'm not a developer, so was just wondering about the feasibility of such support in Tomato.

    A few links:

    The RFC itself
    Andrew's & Arnold (UK Techie ISP) info on patching OpenWRT for support
    Blog article of getting 1500 MTU
    Blog article on getting 1500 MTU using OpenBSD
     
  2. jerrm

    jerrm Network Guru Member

    Shibby just updated to rp-pppoe 3.11, which supposedly supports the RFC. I would assume it would require the WAN interface to support jumbo frames? Not sure what Tomato hardware is capable of that, or what lower-level settings may need to be tweaked or assume a 1500 mtu.
     
  3. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I checked git/tomato/release/src-rt/router/pppd/pppd/plugins/rp-pppoe on Shibby's branch and it includes the PPPOE patches. However it's not quite as simple as that. The WAN interface needs to support baby jumbo frames and when I enabled jumbo frame support on my router I lost connectivity (not that I tried very hard with the WNR3500Lv2)

    Also bear in mind that not all modems support baby jumbo frames on their Ethernet interface (Draytek vigor 120 doesn't) There may also be other places where mtus are hard coded (or limited by the gui at least)

    I suspect if you really want this then you're best off rolling your own - unfortunately there isn't a cohesive tomato development community into which you can throw your ideas and code comes out - the community will gladly take your findings and code tweaks you make though. I've recently pondered about trying to get his holiness the Reverend Kennard interested in looking at Tomato, especially with a view on DHCP6-PD, but quite frankly I suspect the guy is busy enough writing his own Radius/Sip/firebrick code & running his ISP. I can also only imagine the multiple 'WTF!'s as he looked through the Tomato code :)
     
  4. MiddlingMan

    MiddlingMan Addicted to LI Member

    A quick Google seems to indicate that the WNR3500L doesn't support jumbo frames.

    I have an RT-N16 which does support them, at least on the LAN side. I SSHed in and did an ifconfig mtu 1508 on a few interfaces and it worked fine. But i'm running the 1.28.0501.3 Toastman build, so probably don't have the new RP-PPPoE needed and i'll get shouted at if i start messing with things right now. ^_^

    But i'll try a Shibby build next week sometime and see if things work. From my, limited, understanding it should be a simple matter of adjusting the MTU on the WAN port to 1508, restarting PPP with the new options for a 1500 MTU and removing MSS clamping from iptables.

    I understand this may not be much use for people using ADSL modems since they may not support baby jumbos but practically all VDSL2 modems in the UK are supplied by BT Openreach and do support them. It'll also become more important as the new FTTP overlay rollout starts.



    Thanks for the input guys. I'm not a developer or coder of any sort, so would have trouble rolling my own, but i'll report back next week on whether i could get it working or not.
     
  5. RMerlin

    RMerlin Network Guru Member

    Personally I think that PPPoE needs to die. It adds overhead, complexity, and a performance penalty. I was stunned to discover that some European ISPs shove 300 Mbits connections through a PPPoE connection. No need to say that you need a pretty beefy device to handle PPPoE + routing of such a thing...
     
    Monk E. Boy and jerrm like this.
  6. jerrm

    jerrm Network Guru Member

    Don't worry about the "developer" part. Many times the testing is more involved than the actual coding. If you can do the legwork come up with the correct recipe of settings (and they don't seem too risky), there is a pretty good chance one of the devs will look at it.
     
  7. Mangix

    Mangix Networkin' Nut Member

    Same story in Japan. You have very fast fiber connections that use PPPoE. I don't get it.
     
  8. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Just looked and it appears your current version has the required patches. It may just work. You'd need to set a manual mtu of 1500 rather than use the default 1492
     
  9. MiddlingMan

    MiddlingMan Addicted to LI Member

    I was up early so had a fiddle with the router.

    Unfortunately i couldn't get this working. I can SSH in and do "ifconfig eth0 mtu 1508" fine. I set the PPP MTU to 1500 in the web GUI and save the settings. vlan2 correctly picks up the 1508 MTU from eth0, but ppp0 falls back to 1492.

    Here's a snippet from my logs (PPPoE run with a "debug" option):

    Code:
    Jun 15 13:48:10 gateway daemon.info pppd[6029]: Plugin rp-pppoe.so loaded.
    Jun 15 13:48:10 gateway daemon.info pppd[6029]: RP-PPPoE plugin version 3.10 compiled against pppd 2.4.5
    Jun 15 13:48:10 gateway daemon.notice pppd[6030]: pppd 2.4.5 started by root, uid 0
    Jun 15 13:48:10 gateway user.info redial[6031]: Started. Time: 30
    Jun 15 13:48:10 gateway daemon.info dnsmasq[5859]: exiting on receipt of SIGTERM
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: PADS: Service-Name: ''
    Jun 15 13:48:10 gateway daemon.info pppd[6030]: PPP session is 184 (0xb8)
    Jun 15 13:48:10 gateway daemon.warn pppd[6030]: Connected to 00:30:88:00:00:0b via interface vlan2
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: using channel 5
    Jun 15 13:48:10 gateway daemon.info pppd[6030]: Using interface ppp0
    Jun 15 13:48:10 gateway daemon.notice pppd[6030]: Connect: ppp0 <--> vlan2
    Jun 15 13:48:10 gateway daemon.warn pppd[6030]: Couldn't increase MTU to 1500
    Jun 15 13:48:10 gateway daemon.warn pppd[6030]: Couldn't increase MRU to 1500
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xf00f8953>]
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: rcvd [LCP ConfReq id=0x5e <mru 1492> <auth chap MD5> <magic 0x7b231efd>]
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: sent [LCP ConfAck id=0x5e <mru 1492> <auth chap MD5> <magic 0x7b231efd>]
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xf00f8953>]
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: sent [LCP EchoReq id=0x0 magic=0xf00f8953]
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: rcvd [CHAP Challenge id=0x1 <792d5650a9a6a668e1bf3b2d42bc6fd0>, name = "bras-red6.gi-b"]
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: sent [CHAP Response id=0x1 <ec094b78a08a5c9e4f7afef01137fb8c>, name = "00000000000-vivaciti@surfdsluk"]
    Jun 15 13:48:10 gateway daemon.debug pppd[6030]: rcvd [LCP EchoRep id=0x0 magic=0x7b231efd]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [LCP ConfReq id=0x1 <auth chap MD5> <magic 0x1b9745ff>]
    Jun 15 13:48:11 gateway daemon.warn pppd[6030]: Couldn't increase MTU to 1500
    Jun 15 13:48:11 gateway daemon.warn pppd[6030]: Couldn't increase MRU to 1500
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [LCP ConfReq id=0x2 <mru 1492> <magic 0x678267f>]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [LCP ConfAck id=0x1 <auth chap MD5> <magic 0x1b9745ff>]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [LCP ConfNak id=0x2 <mru 1500>]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [LCP ConfReq id=0x3 <magic 0x678267f>]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [LCP ConfAck id=0x3 <magic 0x678267f>]
    Jun 15 13:48:11 gateway daemon.warn pppd[6030]: Couldn't increase MRU to 1500
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [LCP EchoReq id=0x0 magic=0x678267f]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [CHAP Challenge id=0x2 <4873e72ea000c5e00afa662eb8ac07b0>, name = "lts1.sdn.the.uk.murphx.net"]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [CHAP Response id=0x2 <c305bd20f00a5d7c1c5735d4c1dd912f>, name = "00000000000-vivaciti@surfdsluk"]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [LCP ConfReq id=0x1 <auth chap MD5> <magic 0x1a0a536c>]
    Jun 15 13:48:11 gateway daemon.warn pppd[6030]: Couldn't increase MTU to 1500
    Jun 15 13:48:11 gateway daemon.warn pppd[6030]: Couldn't increase MRU to 1500
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [LCP ConfReq id=0x4 <mru 1492> <magic 0x4a32d644>]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [LCP ConfAck id=0x1 <auth chap MD5> <magic 0x1a0a536c>]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [LCP ConfNak id=0x4 <mru 1500>]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [LCP ConfReq id=0x5 <magic 0x4a32d644>]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [LCP ConfAck id=0x5 <magic 0x4a32d644>]
    Jun 15 13:48:11 gateway daemon.warn pppd[6030]: Couldn't increase MRU to 1500
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [LCP EchoReq id=0x0 magic=0x4a32d644]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [CHAP Challenge id=0x3 <e1543597a08354fc3e082f851d900bb8>, name = "lns9.uan.the"]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: sent [CHAP Response id=0x3 <b9ffb5400a51fedbb537855cd1baa4b7>, name = "00000000000-vivaciti@surfdsluk"]
    Jun 15 13:48:11 gateway daemon.debug pppd[6030]: rcvd [LCP EchoRep id=0x0 magic=0x1a0a536c]
    I'll try again tomorrow with a build using rp-pppoe 3.11 and see if i get a different result.
     
  10. RMerlin

    RMerlin Network Guru Member

    You will probably need to find a way to enable jumbo frame on the interface first - assuming both the driver and the chip support that.
     
  11. MiddlingMan

    MiddlingMan Addicted to LI Member

    Is that not what "ifconfig eth0 mtu 1508" does (for baby jumbos)? Maybe i'm not doing it right but it seems to work fine and a simple ifconfig afterwards shows the eth0 interface has a 1508 mtu.

    Just experimented and it seems to accept values up to 9720. After that it gives an
    Code:
    ifconfig: SIOCSIFMTU: Invalid argument
    .

    From what i've been able to find online the RT-N16 does support jumbo frames, and it's supposedly in the official firmware.
     
  12. RMerlin

    RMerlin Network Guru Member

    By default the switch will be configured to only handle up to 1500 bytes. You need to enable Jumbo Frames support in the switch itself. There's a chance that you could do that just by enabling Jumbo Frames on the webui (I assume Tomato has a setting for that somewhere).
     
  13. kthaddock

    kthaddock Network Guru Member

    Yes
    Advanced => Miscellaneous => Enable Jumbo Frames
     
  14. MiddlingMan

    MiddlingMan Addicted to LI Member

    There's an option in Advanced/Miscellaneous.

    I enabled it and set the MTU there to 1508 but upon reboot none of the interfaces exceeded 1500.

    ppp0 still got pushed back down to 1492, so i SSHed back in and manually set the eth0 MTU to 1508 and restarted PPPoE.

    vlan2 gets rebuilt and correctly inherits the 1508 MTU, but still no joy with ppp0.

    I did notice something in the logs that may relate:
    Code:
    Jun 15 20:42:31 gateway daemon.debug pppd[2240]: rcvd [LCP ConfNak id=0x2 <mru 1500>]
    
    Maybe my ISP doesn't support this? Which would be annoying as i know other ISPs using the BT infrastructure do.

    Anyway, i'll give it another go tomorrow.
     
  15. RMerlin

    RMerlin Network Guru Member

    Setting the MTU with ifconfig doesn't survive reboots - you have to set it back at boot time.
     
  16. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    So, 'cos I'm interested in this (and not because my ISP uses it, therefore I have no means of testing...well not without a LOT of fiddling with modems as well) it looks like /tmp/ppp/wanoptions gets written with a hard-capped mru/mtu of 1492, even if you specify an MTU of 1500 in the gui.

    There's some code in wan.c that works out a reasonable default maximum mtu for each protocol and uses that value if you're not overriding it. Unfortunately even if you do override it (ie a manual MTU) a further 'sanity' check is done which if your proposed mtu value is above this default then the default is used, gets written back to nvram *BUT* doesn't get committed so you've no idea WTF's going on.

    Which was all very well back in the days of non jumbo frames but things have moved on. I'll tweak wan.c so that it no longer overrides the maximum value for MTU *IF* jumbo frames are enabled...at some point we have to assume a user that has ticked 'manual MTU' at least has a vague idea what they're doing and just let them get on with it. The lower limit of >=576 will still be enforced.
     
  17. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    As a workaround until the above fix gets adopted, try putting "mru 1500 mtu 1500" in the pppoe options field...it'll mean 'wanoptions' has two mru/mtu entries but hopefully the last one (yours!) sticks. It doesn't throw a syntax error at least.
     
  18. M_ars

    M_ars LI Guru Member

    @KDB:

    i think you also need to change the "max"-value (1492) for pppoe and split up pppoe and ppp3g?

    Code:
      // MTU
    736
    737        switch (wan_proto) {
    738        case WP_PPPOE:
    739        case WP_PPP3G:
    740                max = [B][COLOR=#ff0000]1492;[/COLOR][/B]
    741                break;
    742        case WP_PPTP:
    743        case WP_L2TP:
    744                max = 1460;
    745                break;
    746        default:
    747                max = 1500;
    748                break;
    749        }
    750        if (nvram_match("mtu_enable", "0")) {
    751                mtu = max;
    752        }
    753        else {
    754 // KDB If we've big fat frames enabled then we *CAN* break the
    755 // max MTU on PPP link
    756                mtu = nvram_get_int("wan_mtu");
    757                if (!(nvram_get_int("jumbo_frame_enable")) && (mtu > max)) mtu = max;
    758                        else if (mtu < 576) mtu = 576;
    Edit: Sorry, no need for that :)
     
  19. RMerlin

    RMerlin Network Guru Member

    I remember that back in the day, a lot of people had trouble getting PPPoE to work properly due to people using all sort of whacky MTUs (from the default Ethernet 1500 down to seemingly random values between 1400 and 1492). That was probably the reason for those sanity checks being added to Tomato.

    Since the manual MTU must first be enabled through a checkbox I think that allowing people to truly override it should be fine.
     
  20. MiddlingMan

    MiddlingMan Addicted to LI Member

    Thanks for all your help guys.

    I believe that the Jumbo Frames option in Tomato might be broken. I enabled it and tried various values, but the MTUs stayed stubbonly stuck on 1500. Is anyone actually using Jumbo frames on Tomato successfully?

    I tried the "mru 1500 mtu 1500" in options but still no luck, even after manually setting the MTU on eth0 and restarting ppp.

    However, i have managed to get it working manually.

    An
    Code:
    ifconfig eth0 mtu 1508
    ifconfig vlan2 mtu 1508
    ifconfig ppp0 mtu 1500
    Seems to get things working correctly.

    Pre-ifconfig:
    Code:
    $ ping -D -s 1472 www.dslreports.com
    PING www.dslreports.com (209.123.109.175): 1472 data bytes
    556 bytes from gateway.lan.example.org (10.0.123.1): frag needed and DF set (MTU 1492)
    Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst
    4  5  00 dc05 0ed1  0 0000  40  01 6210 10.0.123.21  209.123.109.175
     
    Request timeout for icmp_seq 0
    556 bytes from gateway.lan.example.org (10.0.123.1): frag needed and DF set (MTU 1492)
    Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst
    4  5  00 dc05 3cc5  0 0000  40  01 341c 10.0.123.21  209.123.109.175
    Post-ifconfig:
    Code:
    $ ping -D -s 1472 www.dslreports.com
    PING www.dslreports.com (209.123.109.175): 1472 data bytes
    1480 bytes from 209.123.109.175: icmp_seq=0 ttl=54 time=96.588 ms
    1480 bytes from 209.123.109.175: icmp_seq=1 ttl=54 time=96.521 ms
    1480 bytes from 209.123.109.175: icmp_seq=2 ttl=54 time=96.946 ms
    1480 bytes from 209.123.109.175: icmp_seq=3 ttl=54 time=96.694 ms
    1480 bytes from 209.123.109.175: icmp_seq=4 ttl=54 time=97.084 ms
    So i know the hardware/software is capable of doing it.
     
  21. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    As far as I can tell, enabling jumbo frames only tells the internal switch to support them. There's no code to change MTUs or anything, in fact the only bit of code other than the 'enable fat switch' that references jumbo frames is the line I added yesterday! So the switch will pass & forward jumbo frames, but any router generated traffic will use the default Ethernet frame size (or smaller)

    I'm pleased you've got it going though. I'd be interested to know the exact requirements to do so, I suspect there are 4 key factors. Do you still have the 'mtu 1500 mru 1500' additional option included (I think you must) Also before you 'ifconfig ppp0 mtu 1500' what was the mtu on that interface?

    Do you still have debug output on pppd enabled? I'd like to see where/when it increases the MTU/MRU and if it relates to your 'ifconfig ppp0 mtu 1500' command.

    4 factors:

    1) Enable jumbo frames - allow the switch to accept larger frames. I think 1526 is the minimum here to accept the 8 byte PPPoE overhead.

    2) Increase MTU on eth0 & vlan2 - otherwise we'll never let a 1508 byte packet out of the WAN interface to talk to our modem.

    3) Tell pppd to accept the max-payload extension - add 'mru 1500 mtu 1500' - I put a fix in the git repo to accept a manually configured MTU of 1500.

    4) Increase MTU on PPP0 interface to 1500 - makes sense...am intrigued to know what it was before! If it's not 1500 I'll go hunting through the code to see where it gets set.
     
  22. MiddlingMan

    MiddlingMan Addicted to LI Member

    Before changing the MTU on ppp0 it was 1492.

    Just started from scratch, and the only thing that seems to be required are those three ifconfig commands.

    Jumbo frames need not be enabled, and "mru 1500 mtu 1500" isn't currently in my PPPoE options.

    Nothing shows in the log after manually changing the ppp0 MTU.

    Thinking about the best way for it all to be setup in the GUI and perhaps an extra option in the MTU drop-down of PPPoE called "RFC 4638" is the way to go. User-definable but defaulted to 1500. Take the value from there for PPP and then add 8 bytes and change the MTU for eth0 to that (vlan2 seems to get torn down and built up again when PPP restarts and inherits eth0's MTU), and remove the MSS clamping rule from iptables.
     
  23. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Hmm. Okay I'm officially confused then :)
     
  24. mstombs

    mstombs Network Guru Member

    Use the robocfg tool to show/examine your switch config

    Code:
    root@rtn66u:/tmp/home/root# robocfg
    Broadcom BCM5325/535x/536x/5311x switch configuration utility
    Copyright (C) 2005-2008 Oleg I. Vdovikin (oleg@cs.msu.su)
    Copyright (C) 2005 Dmitry 'dimss' Ivanov of "Telecentrs" (Riga, Latvia)
     
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU General Public License for more details.
     
    Usage: robocfg <op> ... <op>
    Operations are as below:
            show -- show current config
            showports -- show only port config
            showmacs -- show known MAC addresses
            switch <enable|disable>
            port <port_number> [state <enabled|rx_disabled|tx_disabled|disabled>]
                    [stp none|disable|block|listen|learn|forward] [tag <vlan_tag>]
                    [media auto|10HD|10FD|100HD|100FD|1000HD|1000FD] [mdi-x auto|on|                                                                                                                                                                              off]
                    [jumbo off|on]
            vlan <vlan_number> [ports <ports_list>]
            vlans <enable|disable|reset>
     
            ports_list should be one argument, space separated, quoted if needed,
            port number could be followed by 't' to leave packet vlan tagged (CPU
            port default) or by 'u' to untag packet (other ports default) before
            bringing it to the port, '*' is ignored
     
    Samples:
    1) ASUS WL-500g Deluxe stock config (eth0 is WAN, eth0.1 is LAN):
    robocfg switch disable vlans enable reset vlan 0 ports "0 5u" vlan 1 ports "1 2                                                                                                                                                                              3 4 5t" port 0 state enabled stp none switch enable
    2) WRT54G, WL-500g Deluxe OpenWRT config (vlan0 is LAN, vlan1 is WAN):
    robocfg switch disable vlans enable reset vlan 0 ports "1 2 3 4 5t" vlan 1 ports                                                                                                                                                                              "0 5t" port 0 state enabled stp none switch enable
    root@rtn66u:/tmp/home/root# robocfg show
    Switch: enabled gigabit
    Port 0: 1000FD enabled stp: none vlan: 2 jumbo: off
    Its included in shibby firmware, and used for the neat port state web gui display, and should be the tool invoked when jumbo frames enabled?
     
    Monk E. Boy likes this.
  25. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    Nope, init.c does: et robowr 0x40 0x05 nvram_safe_get("jumbo_frame_size"));
     
  26. MiddlingMan

    MiddlingMan Addicted to LI Member

    So far as i've been able to determine from reading online there's no switch to enable jumbo frames on an interface in any OS. If the MTU on an interface exceeds 1500B then it's a jumbo frame.

    There is an option in Tomato to "enable" jumbo frames, which makes available an entry field where you can set your desired MTU. Unfortunately it doesn't seem to work. No matter what i put in the field the MTU always stays at 1500.

    In this PPPoE case only the WAN port should have jumbo frames so that LAN and WLAN both have 1500 MTUs and the WAN has 1508 (1500+8 PPPoE overhead) so, even if worked, the "enable jumbo frames" option in the Tomato GUI wouldn't be the best solution as it would presumably set both LAN and WAN to 1508 MTUs.

    Anyway i started encountering slow/non-loading sites that i believe may be down to fragmentation. This is only speculation but i *believe* it might be because the initial PPP link wasn't negotiated to 1500 but manually adjusted by me (i did try "mru 1500 mtu 1500" in options but initial connection still defaulted to 1492). If so, that problem should be resolved once Kevin's fix for manually setting the PPPoE MTU makes it into a build.

    I'll still need to manually set the MTU on eth0 to 1508, but i believe i can do this by putting the command in Administration/Scripts/Init (if this runs after the physical interfaces are set up)?

    The firewall also needs to be restarted so that the MSS clamping rule in iptables can get the new values. This probably already happens automatically when the ppp interface comes up, but because i've been adjusting the MTUs on already existing sessions i've had to do it myself.

    Anyway, i'm going to stop fiddling with this for a while as i've been getting complaints that i've "broken the Internet". I'll try again once Kevin's fix makes it into a build.

    Thanks for all the help guys, it should prove useful for future UK FTTC/Tomato users.
     
  27. RMerlin

    RMerlin Network Guru Member

    We're not talking about the OS, but the hardware here. Hardware must be told to enable Jumbo Frames. For WIndows, this is done by going to Device Manager, and going to the Advanced Settings for your network adapter. There will be a field for enabling Jumbo Frames, and selecting the size of those frames.

    This is similar to what the router FW does using the "et" tool - it enables jumbo frames in the switch's registers.
     

Share This Page