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.0k 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.
    • 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
                                    • M Offline
                                      M_Devil
                                      last edited by

                                      Yes, that is it!

                                      _ping -D -s 1472 -c 10 forum.pfsense.org

                                      PING forum.pfsense.org (208.123.73.18): 1472 data bytes
                                      1480 bytes from 208.123.73.18: icmp_seq=0 ttl=49 time=116.153 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=1 ttl=49 time=114.547 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=2 ttl=49 time=113.842 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=3 ttl=49 time=114.175 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=4 ttl=49 time=115.382 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=5 ttl=49 time=115.378 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=6 ttl=49 time=115.167 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=7 ttl=49 time=114.280 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=8 ttl=49 time=113.387 ms
                                      1480 bytes from 208.123.73.18: icmp_seq=9 ttl=49 time=114.075 ms
                                      

                                      –- forum.pfsense.org ping statistics ---
                                      10 packets transmitted, 10 packets received, 0.0% packet loss
                                      round-trip min/avg/max/stddev = 113.387/114.639/116.153/0.809 ms_

                                      1 Reply Last reply Reply Quote 0
                                      • P Offline
                                        pf3000
                                        last edited by

                                        Tested and working on 2.3. I used the patch in post 11 and the most recent build.

                                        ping -D -s 1472 -c 3 8.8.8.8
                                        PING 8.8.8.8 (8.8.8.8): 1472 data bytes
                                        1480 bytes from 8.8.8.8: icmp_seq=0 ttl=52 time=115.295 ms
                                        1480 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=115.393 ms
                                        1480 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=115.577 ms
                                        
                                        --- 8.8.8.8 ping statistics ---
                                        3 packets transmitted, 3 packets received, 0.0% packet loss
                                        round-trip min/avg/max/stddev = 115.295/115.422/115.577/0.117 ms
                                        
                                        

                                        (PPP log in reverse order)

                                        Jan 4 10:46:33     ppp         [wan] IFACE: Rename interface ng0 to pppoe0
                                        Jan 4 10:46:33     ppp         [wan] IFACE: Up event
                                        Jan 4 10:46:32     ppp         [wan] 2.3.4.5 -> 1.1.1.1
                                        Jan 4 10:46:32     ppp         [wan] IPCP: LayerUp
                                        Jan 4 10:46:32     ppp         [wan] IPCP: state change Ack-Sent --> Opened
                                        Jan 4 10:46:32     ppp         [wan] SECDNS 2.2.2.2
                                        Jan 4 10:46:32     ppp         [wan] PRIDNS 3.3.3.3
                                        Jan 4 10:46:32     ppp         [wan] IPADDR 2.3.4.5
                                        Jan 4 10:46:32     ppp         [wan] IPCP: rec'd Configure Ack #3 (Ack-Sent)
                                        Jan 4 10:46:32     ppp         [wan] SECDNS 2.2.2.2
                                        Jan 4 10:46:32     ppp         [wan] PRIDNS 3.3.3.3
                                        Jan 4 10:46:32     ppp         [wan] IPADDR 2.3.4.5
                                        Jan 4 10:46:32     ppp         [wan] IPCP: SendConfigReq #3
                                        Jan 4 10:46:32     ppp         [wan] SECDNS 2.2.2.2
                                        Jan 4 10:46:32     ppp         [wan] PRIDNS 3.3.3.3
                                        Jan 4 10:46:32     ppp         [wan] 2.3.4.5 is OK
                                        Jan 4 10:46:32     ppp         [wan] IPADDR 2.3.4.5
                                        Jan 4 10:46:32     ppp         [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent)
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: LayerFinish
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: state change Req-Sent --> Stopped
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: protocol was rejected by peer
                                        Jan 4 10:46:32     ppp         [wan_link0] LCP: protocol IPV6CP was rejected
                                        Jan 4 10:46:32     ppp         [wan_link0] LCP: rec'd Protocol Reject #63 (Opened)
                                        Jan 4 10:46:32     ppp         [wan] SECDNS 0.0.0.0
                                        Jan 4 10:46:32     ppp         [wan] PRIDNS 0.0.0.0
                                        Jan 4 10:46:32     ppp         [wan] IPADDR 0.0.0.0
                                        Jan 4 10:46:32     ppp         [wan] IPCP: SendConfigReq #2
                                        Jan 4 10:46:32     ppp         [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
                                        Jan 4 10:46:32     ppp         [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent)
                                        Jan 4 10:46:32     ppp         [wan] IPCP: state change Req-Sent --> Ack-Sent
                                        Jan 4 10:46:32     ppp         [wan] IPADDR 1.1.1.1
                                        Jan 4 10:46:32     ppp         [wan] IPCP: SendConfigAck #173
                                        Jan 4 10:46:32     ppp         [wan] 1.1.1.1 is OK
                                        Jan 4 10:46:32     ppp         [wan] IPADDR 1.1.1.1
                                        Jan 4 10:46:32     ppp         [wan] IPCP: rec'd Configure Request #173 (Req-Sent)
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: SendConfigReq #1
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: state change Starting --> Req-Sent
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: Up event
                                        Jan 4 10:46:32     ppp         [wan] SECDNS 0.0.0.0
                                        Jan 4 10:46:32     ppp         [wan] PRIDNS 0.0.0.0
                                        Jan 4 10:46:32     ppp         [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
                                        Jan 4 10:46:32     ppp         [wan] IPADDR 0.0.0.0
                                        Jan 4 10:46:32     ppp         [wan] IPCP: SendConfigReq #1
                                        Jan 4 10:46:32     ppp         [wan] IPCP: state change Starting --> Req-Sent
                                        Jan 4 10:46:32     ppp         [wan] IPCP: Up event
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: LayerStart
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: state change Initial --> Starting
                                        Jan 4 10:46:32     ppp         [wan] IPV6CP: Open event
                                        Jan 4 10:46:32     ppp         [wan] IPCP: LayerStart
                                        Jan 4 10:46:32     ppp         [wan] IPCP: state change Initial --> Starting
                                        Jan 4 10:46:32     ppp         [wan] IPCP: Open event
                                        Jan 4 10:46:32     ppp         [wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps
                                        Jan 4 10:46:32     ppp         [wan_link0] Link: Join bundle "wan"
                                        Jan 4 10:46:32     ppp         [wan_link0] Link: Matched action 'bundle "wan" ""'
                                        Jan 4 10:46:32     ppp         [wan_link0] LCP: authorization successful
                                        Jan 4 10:46:32     ppp         [wan_link0] MESG: Login ok
                                        Jan 4 10:46:32     ppp         [wan_link0] PAP: rec'd ACK #1 len: 13
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: LayerUp
                                        Jan 4 10:46:31     ppp         [wan_link0] PAP: sending REQUEST #1 len: 22
                                        Jan 4 10:46:31     ppp         [wan_link0] PAP: using authname "xxxxxxx"
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: auth: peer wants PAP, I want nothing
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: state change Ack-Sent --> Opened
                                        Jan 4 10:46:31     ppp         [wan_link0] MAGICNUM 17677400
                                        Jan 4 10:46:31     ppp         [wan_link0] MRU 1500
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: rec'd Configure Ack #2 (Ack-Sent)
                                        Jan 4 10:46:31     ppp         [wan_link0] MAGICNUM 17677400
                                        Jan 4 10:46:31     ppp         [wan_link0] MRU 1500
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: SendConfigReq #2
                                        Jan 4 10:46:31     ppp         [wan_link0] PROTOCOMP
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: rec'd Configure Reject #1 (Ack-Sent)
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: state change Req-Sent --> Ack-Sent
                                        Jan 4 10:46:31     ppp         [wan_link0] MAGICNUM 4413e422
                                        Jan 4 10:46:31     ppp         [wan_link0] AUTHPROTO PAP
                                        Jan 4 10:46:31     ppp         [wan_link0] MRU 1500
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: SendConfigAck #62
                                        Jan 4 10:46:31     ppp         [wan_link0] MAGICNUM 4413e422
                                        Jan 4 10:46:31     ppp         [wan_link0] AUTHPROTO PAP
                                        Jan 4 10:46:31     ppp         [wan_link0] MRU 1500
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: rec'd Configure Request #62 (Req-Sent)
                                        Jan 4 10:46:31     ppp         [wan_link0] MAGICNUM 17677400
                                        Jan 4 10:46:31     ppp         [wan_link0] MRU 1500
                                        Jan 4 10:46:31     ppp         [wan_link0] PROTOCOMP
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: SendConfigReq #1
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: state change Starting --> Req-Sent
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: Up event
                                        Jan 4 10:46:31     ppp         [wan_link0] Link: UP event
                                        Jan 4 10:46:31     ppp         [wan_link0] PPPoE: connection successful
                                        Jan 4 10:46:31     ppp         [wan_link0] PPPoE: rec'd PPP-Max-Payload '1500'
                                        Jan 4 10:46:31     ppp         PPPoE: rec'd ACNAME "AL301"
                                        Jan 4 10:46:31     ppp         [wan_link0] PPPoE: Connecting to 'any'
                                        Jan 4 10:46:31     ppp         [wan_link0] PPPoE: Set PPP-Max-Payload to '1500'
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: LayerStart
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: state change Initial --> Starting
                                        Jan 4 10:46:31     ppp         [wan_link0] LCP: Open event
                                        Jan 4 10:46:31     ppp         [wan_link0] Link: OPEN event
                                        Jan 4 10:46:31     ppp         [wan] Bundle: Interface ng0 created
                                        Jan 4 10:46:31     ppp         web: web is not running
                                        Jan 4 10:46:31     ppp         process 4843 started, version 5.7 (root@pfSense_master_amd64_amd64-pfSense_master-job-01 19:14 31-Dec-2015)
                                        Jan 4 10:46:31     ppp         Multi-link PPP daemon for FreeBSD 
                                        
                                        1 Reply Last reply Reply Quote 0
                                        • D Offline
                                          David_W
                                          last edited by

                                          RFC 4638 support has now been merged into pfSense 2.3 and should show up in snapshots shortly.

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

                                            Great, so if it is available in snapshot, I can delete your RFC 4638 patch.

                                            But I guess we still need your PPP IPv6 fix to get an initial IPv6 connection, right?

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