Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    RFC 4638 client support (PPPoE MTU > 1492) - testing

    Scheduled Pinned Locked Moved Development
    35 Posts 4 Posters 14.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P Offline
      pf3000
      last edited by

      Tested this patch with apu1d (http://www.pcengines.ch/apu1d4.htm) running nanobsd 2.2.4, and seems to working. This time I set MTU 1500 in the WAN interface setting.

      Before

      [2.2.4-RELEASE][root@pfSense.localdomain]/root: ifconfig re0;ifconfig pppoe0
re0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=8219b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,linkstate>ether 00:0d:b9:33:78:70
        inet6 fe80::20d:b9ff:fe33:7870%re0 prefixlen 64 scopeid 0x1
        nd6 options=23 <performnud,accept_rtadv,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex,master>)
        status: active
pppoe0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1492
        inet 208.64.38.204 --> 213.133.104.38 netmask 0xffffffff
        inet6 fe80::20d:b9ff:fe33:7870%pppoe0 prefixlen 64 scopeid 0xa
        nd6 options=21<performnud,auto_linklocal></performnud,auto_linklocal></up,pointopoint,running,noarp,simplex,multicast></full-duplex,master></performnud,accept_rtadv,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,linkstate></up,broadcast,running,simplex,multicast>

      After

      [2.2.4-RELEASE][root@pfSense.localdomain]/root: ifconfig re0 ; ifconfig pppoe0
re0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1508
        options=82098 <vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,linkstate>ether 00:0d:b9:33:78:70
        inet6 fe80::20d:b9ff:fe33:7870%re0 prefixlen 64 scopeid 0x1
        nd6 options=23 <performnud,accept_rtadv,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
pppoe0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1500
        inet 208.64.38.116 --> 213.133.104.38 netmask 0xffffffff
        inet6 fe80::20d:b9ff:fe33:7870%pppoe0 prefixlen 64 scopeid 0xa
        nd6 options=21<performnud,auto_linklocal></performnud,auto_linklocal></up,pointopoint,running,noarp,simplex,multicast></full-duplex></performnud,accept_rtadv,auto_linklocal></vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,linkstate></up,broadcast,running,simplex,multicast>

      After ping

      [2.2.4-RELEASE][root@pfSense.localdomain]/root: ping -D -s 1472 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 1472 data bytes
1480 bytes from 8.8.4.4: icmp_seq=0 ttl=51 time=134.734 ms
1480 bytes from 8.8.4.4: icmp_seq=1 ttl=51 time=133.631 ms
1480 bytes from 8.8.4.4: icmp_seq=2 ttl=51 time=133.864 ms
1480 bytes from 8.8.4.4: icmp_seq=3 ttl=51 time=133.571 ms
1480 bytes from 8.8.4.4: icmp_seq=4 ttl=51 time=134.276 ms
^C
--- 8.8.4.4 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 133.571/134.015/134.734/0.436 ms
      1 Reply Last reply Reply Quote 0
      • D Offline
        David_W
        last edited by

        @pf3000:

        Tested this patch with apu1d (http://www.pcengines.ch/apu1d4.htm) running nanobsd 2.2.4, and seems to working.

        That's good to know. My confidence in the patch is growing. So far, only gregb has failed to get this to work, and that is almost certainly down to his environment (a PPPoE <-> PPPoA bridge rather than end to end PPPoE with explicit RFC 4638 support from the ISP) rather than the patch.

        It's notable how many offload features of the apu1d's re0 interface are unavailable in jumbo mode. You lose hardware checksumming and IPv4 TSO. This contrasts with the vmx interface in your other box and the igb interface in my box, both of which lose no offload features in jumbo mode.

        1 Reply Last reply Reply Quote 0
        • D Offline
          David_W
          last edited by

          I've just submitted pull requests against pfSense 2.3:

          mpd5 changes: https://github.com/pfsense/FreeBSD-ports/pull/1
          pfSense support: https://github.com/pfsense/pfsense/pull/1959

          I have posted pointers to those pull requests on Redmine #4542. Hopefully RFC 4638 client support will appear in a future pfSense 2.3 build.

          I have also submitted the mpd5 changes as FreeBSD PR 203695.

          1 Reply Last reply Reply Quote 0
          • D Offline
            David_W
            last edited by

            I've posted a 2.2.5-RELEASE version of the patch in a new thread (still amd64 full installs only).

            1 Reply Last reply Reply Quote 0
            • M Offline
              M_Devil
              last edited by

              Hi David,

              I am looking forward to use the PPPoE MTU > 1492. Using a fiber PPPoE connection and can see the mtu=1492 on the WAN connection.

              Using 2.3 snapshot for a few days now and wondering if/when your changes for using MTU > 1492 will hit the 2.3 snapshots.

              1 Reply Last reply Reply Quote 0
              • D Offline
                David_W
                last edited by

                All the necessary binary support is in the latest pfSense 2.3 snapshots, but the changes to pfSense itself have not been merged. There is a pull request open at https://github.com/pfsense/pfsense/pull/1959 , which I hope the pfSense team will merge to pfSense 2.3 in due course.

                I've not been following pfSense 2.3 that closely in the past few weeks, but if the System Patches package is working, you should be able to install the patch using GitHub's diff feature. In System patches use URL https://patch-diff.githubusercontent.com/raw/pfsense/pfsense/pull/1959.diff with Path Strip Count 2 (not 1 as I earlier said in error) and Base Directory / . This is completely untested, but you're welcome to give it a go.

                1 Reply Last reply Reply Quote 0
                • M Offline
                  M_Devil
                  last edited by

                  I use 2.3 in production environment (home) and I hasitate to go for your sugested solution.
                  Maybe I create an VM in my lab to test it and if succesfull, I give it a try.

                  Even better when pfSense team will merge your pull request into the project.

                  1 Reply Last reply Reply Quote 0
                  • M Offline
                    M_Devil
                    last edited by

                    Tested on 2.3 built on Wed Dec 23 05:35:02 CST 2015 with System patches package

                    Fetch = ok, testing patch failed.

                    Patch can NOT be applied cleanly (detail)

                    /usr/bin/patch –directory=/ -t -p1 -i /var/patches/567e75dbd3c0c.patch --check --forward --ignore-whitespace

                    Hmm...  Looks like a unified diff to me...
                    The text leading up to this was:

                    |diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc
                    |index f7e60a6..8adadc0 100644
                    |--- a/src/etc/inc/interfaces.inc

                    +++ b/src/etc/inc/interfaces.inc
                    No file to patch.  Skipping...
                    Hunk #1 ignored at 1851.
                    Hunk #2 ignored at 1932.
                    Hunk #3 ignored at 3061.
                    Hunk #4 ignored at 3081.
                    Hunk #5 ignored at 3262.
                    Hunk #6 ignored at 3332.
                    Hunk #7 ignored at 4644.
                    7 out of 7 hunks ignored while patching src/etc/inc/interfaces.inc
                    done

                    Patch can NOT be reverted cleanly (detail)

                    /usr/bin/patch –directory=/ -f -p1 -i /var/patches/567e75dbd3c0c.patch --check --reverse --ignore-whitespace

                    Hmm...  Looks like a unified diff to me...
                    The text leading up to this was:

                    |diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc
                    |index f7e60a6..8adadc0 100644
                    |--- a/src/etc/inc/interfaces.inc

                    +++ b/src/etc/inc/interfaces.inc
                    No file to patch.  Skipping...
                    Hunk #1 ignored at 1851.
                    Hunk #2 ignored at 1924.
                    Hunk #3 ignored at 3047.
                    Hunk #4 ignored at 3063.
                    Hunk #5 ignored at 3195.
                    Hunk #6 ignored at 3228.
                    Hunk #7 ignored at 4540.
                    7 out of 7 hunks ignored while patching src/etc/inc/interfaces.inc
                    done
                    1 Reply Last reply Reply Quote 0
                    • D Offline
                      David_W
                      last edited by

                      @M_Devil:

                      Tested on 2.3 built on Wed Dec 23 05:35:02 CST 2015 with System patches package

                      Fetch = ok, testing patch failed.

                      Patch can NOT be applied cleanly (detail)

                      /usr/bin/patch –directory=/ -t -p1 -i /var/patches/567e75dbd3c0c.patch --check --forward --ignore-whitespace

                      My mistake - path strip count needs to be 2 for 2.3. I've edited my earlier post accordingly.

                      1 Reply Last reply Reply Quote 0
                      • M Offline
                        M_Devil
                        last edited by

                        No problem, i really appreciate your efforts.

                        My goal is to patch your RFC 4638 and PPP IPv6 fix.

                        Still not succesfull.

                        First patch PPP IPv6 with this test result

                        /usr/bin/patch –directory=/ -t -p1 -i /var/patches/567e80217400c.patch --check --forward --ignore-whitespace

                        Hmm...  Looks like a unified diff to me...
                        The text leading up to this was:

                        |diff --git a/etc/inc/interfaces.inc b/etc/inc/interfaces.inc
                        |index b425434..caefa85 100644
                        |--- a/etc/inc/interfaces.inc

                        +++ b/etc/inc/interfaces.inc
                        Patching file etc/inc/interfaces.inc using Plan A...
                        Hunk #1 succeeded at 1984 with fuzz 1 (offset 166 lines).
                        Hunk #2 succeeded at 1853 (offset 2 lines).
                        Hunk #3 succeeded at 3265 (offset 226 lines).
                        done

                        The RFC 4638 path test gives this:

                        /usr/bin/patch –directory=/ -t -p2 -i /var/patches/567e809abd883.patch --check --forward --ignore-whitespace

                        Hmm...  Looks like a unified diff to me...
                        The text leading up to this was:

                        |diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc
                        |index f7e60a6..8adadc0 100644
                        |--- a/src/etc/inc/interfaces.inc

                        +++ b/src/etc/inc/interfaces.inc
                        Patching file etc/inc/interfaces.inc using Plan A...
                        Hunk #1 succeeded at 1855 (offset 4 lines).
                        Hunk #2 succeeded at 1936 (offset 4 lines).
                        Hunk #3 succeeded at 3039 (offset -22 lines).
                        Hunk #4 succeeded at 3085 (offset 4 lines).
                        Hunk #5 succeeded at 3240 (offset -22 lines).
                        Hunk #6 succeeded at 3336 (offset 4 lines).
                        Hunk #7 succeeded at 4622 (offset -22 lines).
                        done

                        For the latter I used the Path Stripcount = 2

                        1 Reply Last reply Reply Quote 0
                        • M Offline
                          M_Devil
                          last edited by

                          Sorry, i was incomplete.

                          Apply patch (both) is succesfull, put putting MTU=1500 on WAN PPPoE interface and reboot still gives MTU=1492 in status->interfaces

                          1 Reply Last reply Reply Quote 0
                          • M Offline
                            M_Devil
                            last edited by

                            Checking ifconfig:

                            em2 (=NIC with 2 vlan's), MTU = 1508
                            pppoe1 on em2 (=WAN vlan), MTU = 1492

                            From log:
                            mpd_wan.conf:32: Unknown command: 'set pppoe max-payload 1500'. Try "help".

                            1 Reply Last reply Reply Quote 0
                            • D Offline
                              David_W
                              last edited by

                              @M_Devil:

                              Checking ifconfig:

                              em2 (=NIC with 2 vlan's), MTU = 1508
                              pppoe1 on em2 (=WAN vlan), MTU = 1492

                              From log:
                              mpd_wan.conf:32: Unknown command: 'set pppoe max-payload 1500'. Try "help".

                              The RFC 4638 patch is behaving as I expect: configuring the MTU of the parent interface of the PPPoE interface to 8 more than the configured PPPoE MTU (to allow for the 8 byte PPPoE overhead) and setting 'set pppoe max-payload' in the mpd configuration.

                              The problem is that your mpd5 binary doesn't contain RFC 4638 support. The changes were merged back on 12 October and should have started to appear in snapshots shortly afterwards.

                              I checked that the necessary binary and kernel support exists in the latest builds of 2.3 by installing pfSense-LiveCD-2.3-ALPHA-amd64-20151228-0402.iso.gz (the latest at the time I tried this) and updating via the GUI. RFC 4638 worked correctly on those binaries.

                              What does pkg info -o net/mpd5 show (use a shell command prompt)? If the version is mpd5-5.7_4 or above, I'd expect the patch to be present. It definitely is not present in mpd5-5.7_3.

                              If you only have mpd5-5.7_3, when did you last update your binaries? gitsync only updates the script components, not the binaries. If your binaries are old enough not to include mpd5-5.7_4, then you may well find that an update leaves you with an installation that doesn't work correctly. Your best option in this scenario is probably to back up your config.xml, reinstall pfSense 2.3 from a recent snapshot and restore your config.xml.

                              1 Reply Last reply Reply Quote 0
                              • M Offline
                                M_Devil
                                last edited by

                                Command:  pkg info -o net/mpd5 shows:

                                mpd5-5.7_4                    net/mpd5

                                So it should be present?

                                My last update is by GUI (so also updated binary?) and built on Wed Dec 23 05:35:02 CST 2015

                                I will update (by GUI) to latest snapshot now, will report back in a few minutes.

                                1 Reply Last reply Reply Quote 0
                                • M Offline
                                  M_Devil
                                  last edited by

                                  So, strange thing is:

                                  After update without apply the patch, the log gives:
                                  mpd_wan.conf:29: Error in 'set link mtu 1500': max MTU on type "pppoe" links is 1492

                                  But after apply of the patch, the log gives:
                                  mpd_wan.conf:32: Unknown command: 'set pppoe max-payload 1500'. Try "help".

                                  What am I doing wrong?

                                  One more test: I will skip your patch PPP IPv6, and only test the RFC 4638 patch. Will report back in a few minutes

                                  Edit: No, same error about unknown command

                                  Edit: I am on remote location now, so I cannot reinstall 2.3 on the moment and restore config.xml. Will try it when I am on location again

                                  1 Reply Last reply Reply Quote 0
                                  • D Offline
                                    David_W
                                    last edited by

                                    set pppoe max payload is the correct syntax for PPPoE MTU > 1492. The pfSense patch was working correctly before you uninstalled it - the problem was that mpd5 and/or the kernel on your system did not have working RFC 4638 support. You need the pfSense patch to ensure the parent interface MTU is set correctly and to ensure the correct mpd5 configuration syntax is used.

                                    mpd5-5.7_4 is built using the RFC 4638 patch, but the resulting mpd5 binary will only support RFC 4638 if it was built on a machine with the RFC 4638 kernel patch installed. Unknown command: 'set pppoe max-payload 1500'. Try "help". implies that your mpd5-5.7_4 was built on a machine without the kernel patch.

                                    If you don't want to try a total reinstall, try:
                                    pkg upgrade -f net/mpd5

                                    and answer y when asked. This should reinstall mpd5 from the pfSense-core repository (at the time of writing, this is identical to the version I tested and confirmed to be working earlier today assuming that you are using amd64).

                                    If that doesn't give you working RFC 4638 support, try an Upgrade from the pfSense GUI, which should install the latest kernel - though back up your config.xml first. As I said earlier, an upgrade on a system that is too old might leave you with an unusable mess that you have to reinstall.

                                    1 Reply Last reply Reply Quote 0
                                    • M Offline
                                      M_Devil
                                      last edited by

                                      pkg upgrade -f net/mpd5 did the trick.  :D

                                      Indeed the pkg upgrade ask for reinstall and then it worked!

                                      Thank you for your support!

                                      Will report back if this is stable.

                                      1 Reply Last reply Reply Quote 0
                                      • D Offline
                                        David_W
                                        last edited by

                                        It's good to know that a forced reinstall of mpd5 was sufficient to resolve your issue, as that might help others. If anyone else has a similar problem, I suggest pkg upgrade -fy net/mpd5 (the additional y means there's no confirmation required, so the command will work from the 'Execute shell command' part of Diagnostics -> Command Prompt).

                                        The PPP log should indicate whether you successfully negotiated an MTU of 1500. To test whether MTU 1500 is working, try ping -D -s 1472 -c 10 8.8.4.4

                                        If things are working correctly, you'll successfully send 10 1500 byte packets (1472 byte payload, 8 byte ICMP overhead and 20 byte IPv4 overhead) to Google DNS, and Google DNS will send 10 back. You can experiment with another destination instead of 8.8.4.4.

                                        If things are not working correctly, you'll get packet loss and/or complaints about 'frag needed and DF set'.

                                        The IPv6 test, if you have native IPv6 support, is ping6 -D -s 1452 -c 10 www.google.com

                                        In this case, you send 1500 byte packets (1452 byte payload, 8 bytes ICMPv6 overhead and 40 byte IPv6 overhead) and the remote end sends 72 bytes back - that's the way that ICMPv6 echo request and reply works.

                                        1 Reply Last reply Reply Quote 0
                                        • M Offline
                                          M_Devil
                                          last edited by

                                          Edit: Seems IPv4 is using my VPN connection. Dont know how to initiate ping from 'normal' WAN connection. Trying to sort it out

                                          Not sure, IPv4 gives error about wrong total length, IPv6 look ok.

                                          IPv4 ping test

                                          ping -D -s 1472 -c 10 8.8.4.4

                                          PING 8.8.4.4 (8.8.4.4): 1472 data bytes
                                          72 bytes from 8.8.4.4: icmp_seq=0 ttl=50 time=9.585 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=1 ttl=50 time=14.571 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=2 ttl=50 time=11.723 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=3 ttl=50 time=11.371 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=4 ttl=50 time=12.727 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=5 ttl=50 time=10.302 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=6 ttl=50 time=10.242 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=7 ttl=50 time=9.858 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=8 ttl=50 time=13.165 ms
                                          wrong total length 92 instead of 1500
                                          72 bytes from 8.8.4.4: icmp_seq=9 ttl=50 time=11.564 ms
                                          wrong total length 92 instead of 1500

                                          –- 8.8.4.4 ping statistics ---
                                          10 packets transmitted, 10 packets received, 0.0% packet loss
                                          round-trip min/avg/max/stddev = 9.585/11.511/14.571/1.522 ms

                                          IPv6 ping test

                                          ping6 -D -s 1452 -c 10 www.google.com
                                          PING6(1500=40+8+1452 bytes) 2001:984:XXX:X:XXXX:XXXX:XXXX:XXXX–> 2a00:1450:4013:c01::6a
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=0 hlim=56 time=7.557 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=1 hlim=56 time=7.748 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=2 hlim=56 time=7.806 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=3 hlim=56 time=7.651 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=4 hlim=56 time=7.720 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=5 hlim=56 time=7.801 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=6 hlim=56 time=7.736 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=7 hlim=56 time=7.717 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=8 hlim=56 time=7.772 ms
                                          72 bytes from 2a00:1450:4013:c01::6a, icmp_seq=9 hlim=56 time=7.590 ms

                                          --- www.google.com ping6 statistics ---
                                          10 packets transmitted, 10 packets received, 0.0% packet loss
                                          round-trip min/avg/max/std-dev = 7.557/7.710/7.806/0.081 ms

                                          Online MTU check on http://www.letmecheck.it/mtu-test.php gives good IPv4 en IPv6 MTU (1500)

                                          1 Reply Last reply Reply Quote 0
                                          • D Offline
                                            David_W
                                            last edited by

                                            @M_Devil:

                                            Not sure, IPv4 gives error about wrong total length, IPv6 look ok.

                                            All wrong total length 92 instead of 1500 means is that the Google server handling traffic to 8.8.4.4 in  your location is configured to respond with shorter packets than 1500 bytes. Try some different destinations by IP address or DNS name. Hopefully you'll find something that responds with 1500 bytes.

                                            The server you are reading this on:

                                            • responds to ping -D -s 1472 -c 10 forum.pfsense.org with 1480 bytes (1500 bytes when you add in the 20 byte IPv4 header)

                                            • responds to ping6 -D -s 1452 -c 10 forum.pfsense.org with 1460 bytes (1500 bytes when you add in the 40 byte IPv6 header)

                                            Everything else you posted is as expected.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.