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

    New PPPoE backend, some feedback

    Scheduled Pinned Locked Moved Development
    216 Posts 17 Posters 23.8k 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.
    • B
      benbng
      last edited by

      I noticed that when using if_pppoe the file containing the gateway address at location /tmp/pppoe1_routerv6 was missing; this file is supposed to be created by the rtsold script within /var/etc (and then used by function get_interface_gateway_v6.)

      I manually created this file (taking the gateway address from the default route) and then under Diagnostics > Command Prompt ran PHP Command: setup_gateways_monitor(); after this my IPv6 gateway shows as Online, however despite the fact it is the default gateway for IPv6 it is still not forwarding traffic.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Hmm, good catch. Do you see the policy routing rules in the ruleset? (/tmp/rules.debug) Do they have the gateway on them?

        1 Reply Last reply Reply Quote 0
        • B
          benbng
          last edited by

          Ah thanks for that, I did a filter reload (via Status > Filter Reload) and it's routing now!

          Something I have noticed is my ISP doesn't seem to be sending a Router Advertisement:
          f6436d6d-e2d0-4802-b03f-1bd4b8bd5d26-image.png

          Could the rtsold behaviour be different when using if_pppoe in this situation? This is quite old but I wonder if it could potentially be related? https://redmine.pfsense.org/issues/14072

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Hmm, it could. The RA behaviour of different ISPs seems to vary significantly.

            Mine sends an RA each time the pppoe link connects. And only then. Which makes everything work just fine!

            RobbieTTR 1 Reply Last reply Reply Quote 0
            • RobbieTTR
              RobbieTT @stephenw10
              last edited by

              @stephenw10 said in New PPPoE backend, some feedback:

              Hmm, it could. The RA behaviour of different ISPs seems to vary significantly.

              Mine sends an RA each time the pppoe link connects. And only then. Which makes everything work just fine!

              Is that an actual RA or solicited?

              The variance of ISPs is probably the point and perhaps requires more care with if_pppoe. As it is:

              2025-06-09 20:09:04.501728+01:00	php	57356	/usr/local/sbin/ppp-ipv6: Starting rtsold process on wan(pppoe0)
2025-06-09 20:09:04.501539+01:00	php	57356	/usr/local/sbin/ppp-ipv6: Starting DHCP6 client for interfaces pppoe0
2025-06-09 20:09:04.469732+01:00	php	57356	/usr/local/sbin/ppp-ipv6: Accept router advertisements on interface pppoe0
2025-06-09 20:09:04.046407+01:00	kernel	-	pppoe0: link state changed to UP

              As soon as the pppoe link is up if_pppoe is always set to accept RAs and then (with not wait for RAs set) is directed to start the rtsold process. Perhaps asking the system to respond to both even with 'do not wait' set is asking for trouble?

              ☕️

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                It could be since I only see it after the parent pppoe connects:

                Jun 8 06:45:47 	rtsold 	82638 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
Jun 8 06:27:57 	rtsold 	13619 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
May 28 16:24:04 	rtsold 	99252 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
May 28 15:30:10 	rtsold 	87300 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
May 26 05:02:01 	rtsold 	64029 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
May 18 17:11:41 	rtsold 	50394 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
May 16 19:31:17 	rtsold 	53108 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
May 14 04:24:39 	rtsold 	49956 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
May 10 20:01:04 	rtsold 	60529 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
May 6 20:36:28 	rtsold 	99065 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
Apr 30 15:01:59 	rtsold 	55432 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
Apr 30 14:34:11 	rtsold 	12977 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
Apr 30 14:03:08 	rtsold 	20686 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
Apr 28 14:09:46 	rtsold 	73063 	Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)

                I don't see anything logged either way but I wouldn't expect to.

                1 Reply Last reply Reply Quote 0
                • B
                  benbng
                  last edited by

                  Looking through my logs I see no events from rtsold as you do and having reviewed the rtsold man page I strongly suspect that in my case the supplement script will never run since an RA doesn't appear to be sent from my ISP.

                  I have noticed within /var/etc/mpd_opt10.conf the following line: set iface up-script /usr/local/sbin/ppp-linkup and within this script I can see: echo "${REMOTE_IP}" > "/tmp/${IF}_routerv6" I'm guessing this could be missing for if_pppoe?

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    if_pppoe uses pppoe-handler instead of those scripts:
                    https://github.com/pfsense/pfsense/blob/master/src/usr/local/sbin/pppoe-handler#L50

                    1 Reply Last reply Reply Quote 0
                    • B
                      benbng
                      last edited by

                      Can you see a tunnel6 value when you execute the following PHP command: print_r(get_interface_addresses("pppoe1"));?

                      I cannot:

                      Array
(
    [status] => up
    [multicast] => 1
    [pointtopoint] => 1
    [simplex] => 1
    [iftype] => other
    [mtu] => 1500
    [caps] => Array
        (
            [flags] => 0
        )

    [encaps] => Array
        (
            [flags] => 0
        )

    [ipaddr] => 98.96.169.137
    [subnetbits] => 32
    [subnet] => 255.255.255.255
    [tunnel] => 199.15.239.1
    [ipaddr6] => 2001:db8:abcd:0012::1
    [subnetbits6] => 128
)
                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        I do, yes:

                        Array
(
    [status] => up
    [multicast] => 1
    [pointtopoint] => 1
    [simplex] => 1
    [linkstateup] => 1
    [iftype] => other
    [mtu] => 1500
    [caps] => Array
        (
            [flags] => 0
        )

    [encaps] => Array
        (
            [flags] => 0
        )

    [ipaddr] => 86.191.x.x
    [subnetbits] => 32
    [subnet] => 255.255.255.255
    [tunnel] => 172.16.13.252
)

                        No IPv6 value because it's PD only.

                        1 Reply Last reply Reply Quote 0
                        • B
                          benbng
                          last edited by benbng

                          I can't see tunnel6 in the output you shared, I guess that won't be an issue for you since the rtsold script is creating /tmp/if_routerv6 but in my case since the rtsold script isn't firing the only way would be if that value is returned as per: https://github.com/pfsense/pfsense/blob/master/src/usr/local/sbin/pppoe-handler#L51

                          So is this a bug when using ISPs that don't send an RA using if_pppoe?

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            It could be. There's certainly significant variation between ISPs RA handling.

                            L 1 Reply Last reply Reply Quote 0
                            • L
                              louis2 @stephenw10
                              last edited by louis2

                              @stephenw10

                              Stephen, I wonder if it is perhaps a good idea to create a special version of the pppoe module which generates some debug logging's.

                              If you make that available as a patch I would more than happy to (temporarely) install and test it.

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                You can enable debug mode on the interface but I don't think it will help with this. The IPv6 connection all runs on top of the PPPoE once it comes up. Anything different should be visible there.

                                1 Reply Last reply Reply Quote 0
                                • B
                                  benbng
                                  last edited by

                                  In my opinion the logic for setting the IPv6 gateway could be improved in the pppoe_add_addrv6 function (within pppoe-handler) since it currently appears ineffective regardless of whether a RA is received since a tunnel6 value is not returned for the PPPoE interface

                                  L 1 Reply Last reply Reply Quote 0
                                  • L
                                    louis2 @benbng
                                    last edited by

                                    @stephenw10

                                    I think there are probably multiple issues under the hood.

                                    However one of them is IMHO simple to fix, that is the fact that the status of the IPV6 connection on the dashboard is not at all correct.

                                    If you go to status interfaces there is the correct
                                    IPv6 Link Local address. In my case at the moment
                                    fe80::2a0:c9ff:fe22:60aa%pppoe0

                                    And I can ping that address using pfsense ping tool using WAN as origin.

                                    It feels like peanuts to use a ping to that address to check the availability of the IPV6-connecition.

                                    So why not solve this part of the problem !??

                                    RobbieTTR 1 Reply Last reply Reply Quote 0
                                    • RobbieTTR
                                      RobbieTT @louis2
                                      last edited by

                                      @louis2

                                      Not sure what you mean. My dashboard / Gateways looks like this for reference:

                                      2025-06-11 at 11.36.59.png

                                      ☕️

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        Yup me too. LL gateway works just fine for me. Which doesn't really help much. 😉

                                        But I think @benbng may be on to something there. Check the values in the pppoe files in /tmp. Perhaps you don't have a /tmp/pppoe0_defaultgwv6 file at all?

                                        RobbieTTR 1 Reply Last reply Reply Quote 0
                                        • RobbieTTR
                                          RobbieTT @stephenw10
                                          last edited by

                                          @stephenw10

                                          Perhaps, as the status > interface page should have 2 link local addresses listed; one for the router and one for the default gateway (as per the file in /tmp/). Pinging its own link local would give a result in µs and the default gateway address would be in ms.

                                          I think we need to see what @benbng is looking at.

                                          ☕️

                                          L 1 Reply Last reply Reply Quote 0
                                          • L
                                            louis2 @RobbieTT
                                            last edited by

                                            @RobbieTT

                                            Mine is like this (since the new ppoe)

                                            133d0b34-178c-460c-a871-916b56986c72-image.png

                                            However IPV6 is working

                                            With the old PPOE after some time the IPV6 looked to be gone, but it was still working. There is a ticket related to that old item.

                                            However I think it is the same item.

                                            And I did complain a couple of times that the indicated IPV6 times in the gui where IMHO also too high not correct.

                                            And in my option all those sings are related to the same wrong way of checking the IPV6 interface

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