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

    PPPoE WAN does not restart correctly after reconfiguring interfaces.

    Scheduled Pinned Locked Moved General pfSense Questions
    67 Posts 6 Posters 6.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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      It's probably the same race condition caused by VIPs on PPPoE. Not sure what would trigger it in your case though.

      RobbieTTR w0wW 2 Replies Last reply Reply Quote 0
      • RobbieTTR
        RobbieTT @stephenw10
        last edited by

        @stephenw10
        Can PPPoE itself be comparable to a VIP - it is a tunnel within a real interface IP?

        ☕️

        stephenw10S 1 Reply Last reply Reply Quote 1
        • w0wW
          w0w @stephenw10
          last edited by

          @stephenw10
          Any thoughts how to debug this?

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

            @RobbieTT said in PPPoE WAN does not restart correctly after reconfiguring interfaces.:

            @stephenw10
            Can PPPoE itself be comparable to a VIP - it is a tunnel within a real interface IP?

            Yes interesting question. Certainly there are plenty of people doing that. If you get a 'business' connection with a /29 from BT for example that is how you might use them.
            But is that valid on a point to point connection? It seems like a regression but possibly it worked previously just by luck.

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

              @stephenw10

              Continuing the thinking, do all the different IPv6 addresses we create on an interface count as VIPs?

              ☕️

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

                No, not in the same way that's triggering that flapping. I've never seen the competing mpd instances here for example.

                w0wW 1 Reply Last reply Reply Quote 0
                • w0wW
                  w0w @stephenw10
                  last edited by w0w

                  @stephenw10
                  Well, can’t the mpd itself be the cause? It starts with the -k key, but for some reason it cannot access the PID file of the previously started process. I looked at your competitors project, it seems like they have a similar problem and Franco suggested that it’s the MPD itself, their patch calls a external non mpd function that kills the process by the PID, this is, of course, if I understood everything correctly.

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

                    It's certainly possible. It feels more like a regression in the boot code though. Or at least a change there. It didn't used to do this in earlier versions and mpd really hasn't changed much. Though it was never that great! 😉

                    1 Reply Last reply Reply Quote 0
                    • P
                      pFence
                      last edited by

                      I have two WAN interfaces, and both are configured for DHCP6 (next to PPPoE for IPv4 on one of them, and DHCP on the other). In that case an automatic periodic reset configured for PPPoE or manually issuing

                      /usr/local/sbin/pfSctl -c 'interface reload wan'
                      

                      will break PPPoE, and a second mpd is active for about 30 seconds before it vanishes.
                      However, as soon as I disable DHCP6 on either of them, issuing the command will not break PPPoE, and a second mpd is active for only about 5 seconds before it vanishes.
                      Note that this happens even if one of the WAN interfaces actually has no communication because I interrupted the link one hop behind the router. So the bug seems to be related to multiple IPv6 configurations (and not primarily to multiple PPPoE or DHCP communications)?

                      Is there a bug associated to this issue?

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

                        Hmm, do those IPv6 link both work initially? There have been problems with dual PPPoE link carrying IPv6 in the past: https://redmine.pfsense.org/issues/13939

                        There is only a problem when it resets?

                        P 1 Reply Last reply Reply Quote 0
                        • P
                          pFence @stephenw10
                          last edited by

                          @stephenw10 said in PPPoE WAN does not restart correctly after reconfiguring interfaces.:

                          Hmm, do those IPv6 link both work initially? There have been problems with dual PPPoE link carrying IPv6 in the past: https://redmine.pfsense.org/issues/13939

                          That is not the issue here. My configuration is

                          • WAN1: PPPoE and DHCP6
                          • WAN2: DHCP and DHCP6

                          When I remove one of the DHCP6 configurations and reload, the PPPoE on WAN1 immediately activates. If I keep both and reload, even after hours PPPoE on WAN1 remains dead.

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

                            Ah I see. Does restarting the DHCP WAN also trigger it?

                            1 Reply Last reply Reply Quote 0
                            • P
                              pFence
                              last edited by

                              I do not know the syntax to send a reload command just for interface WAN2.

                              /usr/local/sbin/pfSctl -c 'interface reload wan2'
                              

                              does not work.

                              Using the GUI though, when I enable interface WAN2 with a DHCP6 configuration where it didn't have one before, that does not kill PPPoE on interface WAN1. But I am not sure whether that is equivalent to an 'interface reload' command.

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

                                You'd have to use the internal interface name there so possibly:
                                /usr/local/sbin/pfSctl -c 'interface reload opt1'

                                Check the config or console menu to see those like:

                                 WAN (wan)   -> ix3  -> v4/DHCP4: 172.21.16.23/24
                                 LAN (lan)   -> igc0 -> v4: 192.168.23.1/24
                                 WAN2 (opt1) -> ix2  -> 
                                 WAN3 (opt2) -> ix0  -> 
                                 WAN4 (opt3) -> ix1  -> 
                                 LAN2 (opt4) -> igc1 -> 
                                
                                1 Reply Last reply Reply Quote 0
                                • P
                                  pFence
                                  last edited by

                                  It is indeed opt1. And no, issuing

                                  /usr/local/sbin/pfSctl -c 'interface reload opt1'
                                  

                                  does not break PPPoE on interface WAN1. Only

                                  /usr/local/sbin/pfSctl -c 'interface reload wan'
                                  

                                  does.

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

                                    We're probably going to need to see some logs.

                                    How do you have the periodic reset configured?

                                    1 Reply Last reply Reply Quote 0
                                    • P
                                      pFence
                                      last edited by

                                      It is configured as "Custom" periodic reset within the PPPoE configuration of interface WAN1.

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

                                        OK, that should work.

                                        If the second WAN is disabled does the dhcpv6 on WAN reconnect correctly?

                                        1 Reply Last reply Reply Quote 0
                                        • P
                                          pFence
                                          last edited by pFence

                                          Yes, both PPPoE (IPv4) and DHCP6 connect correctly.

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

                                            Ok I thing we're going to need to see some logs of the reconnection to see what's happening there.

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