In PFSENSE how to make MTU of 1500 persist on PPPoE WAN connection (RFC4638)



  • I have a Draytek Vigor 130 connected to the WAN interface of my PFSENSE box. The MTU values configured in interfaces.php and interfaces_ppps_edit.php have no effect on the MTU reported by ifconfig pppoe0 (at any point during the dialling process).

    When I use this nmap script to detect the MTU between a LAN connected host and the internet, the MTU is detected as 1492 (as expected given the value reported by ifconfig pppoe0)

    However running ifconfig pppoe0 mtu 1500 successfully sets the MTU to 1500. This also causes LAN connected clients to detect an MTU of 1500 to the internet. (Up from the old 1492. Success!)

    How do I make this change persist though? Obviously this only has an effect until the next reboot. I have tried making a startup script in /usr/local/etc/rc.d/, and while the script executed correctly, it clearly executed before the PPP connection was established and therefore did not have any effect on the final MTU.



  • Hi!

    Tried in Webinterface on Interfaces / WAN? There is an item MTU. Maybe settings in Vigor130 for MTU also necessary.

    BR wkn



  • Thanks for the suggestion. As mentioned in the question I have configured the MTU values in both places in the web interface, and these have no effect.

    The MTU values configured in interfaces.php and interfaces_ppps_edit.php have no effect on the MTU reported by ifconfig pppoe0 (at any point during the dialling process).



  • With regards to the Vigor 130 the product page states that it supports the required baby jumbo frames (MTU1508, RFC4638).

    Furthermore if the Vigor 130 was the issue I would not have expected it to be possible to get this working even temporarily. Which I am able to do with ifconfig pppoe0 mtu 1500

    Thanks for the help :)


  • Netgate Administrator

    Hmm, this should work it was addressed a while back:
    https://redmine.pfsense.org/issues/4542

    Also: https://forum.netgate.com/topic/91397/rfc-4638-client-support-pppoe-mtu-1492-patch-available-for-2-2-6-release/2

    It seems to work here, just setting it on the appropriate interface in fact:

    pppoe1: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
    	inet6 fe80::290:7fff:fe3c:9609%pppoe1 prefixlen 64 scopeid 0xf
    	inet 81.152.213.178 --> 172.16.11.149 netmask 0xffffffff
    	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    

    Do you see it change immediately when you set it? Does it only lose the setting at boot? At reconnect?

    Steve



  • When I set and apply the PPP MTU (as described) in the web configurator the connection redials, during the redial process the MTU on the pppoe0 interface is initially and briefly 1500, until the PPP connection is established at which point the MTU drops to 1492. This process and the MTU values described do not change, regardless of the MTU values specified in the web configurator.

    I can successfully set the MTU of the interface with the ifconfig as described. However, this is lost on reconnection and/or reboot.



  • I should add that the web configurator always shows the MTU value set previously, it is just that this value doesn't have any effect.


  • Netgate Administrator

    Hmm, curious. I'm setting it in interfaces.php and it seems to work OK. I have not tried interfaces_ppps_edit.php.

    This is in 2.4.3_1? Have you tried any other versions?

    Setting that does seem to have broken IPv6 for some reason. Could be coincidental...

    Steve



  • Yeah this is 2.4.3-RELEASE-p1, I have also previously tried this on 2.4.2 with identical results.

    Thanks for looking at this.


  • Netgate Administrator

    Hmm, that particular box where I'm seeing it work as expected is still running 2.3.5. I wonder if there was a regression. I would have expected that to have been reported by now though. I'm not sure I have anything 2.4.3 to test that against directly. I'll try to get something setup.

    It did definitely stop it pulling a v6 prefix for some reason though the one time I tested it.

    Steve



  • Yeah a regression is a possibility. But as you say, I would have thought this would have caused somebody else issues as well previously. Anything you manage to find is appreciated, thanks for looking at it.



  • This post is deleted!