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

    [BUG?] New PPPoE module (if_pppoe) causes high "Errors Out" on WAN (Vivo Fibra)

    Scheduled Pinned Locked Moved Routing and Multi WAN
    47 Posts 8 Posters 3.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

      Aha, and what is the queue length set to on WAN? Try increasing it and see if that reduces the output errors.

      brookheatherB 1 Reply Last reply Reply Quote 0
      • brookheatherB
        brookheather @stephenw10
        last edited by

        @stephenw10 do you mean the Queue Limit on the WAN shaper? I don't have anything set for this.

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

          Yes. It's usually set to 50 packets by default. You can check that in Status > Queues.

          Try setting it to 100 and see if that changes anything.

          brookheatherB 1 Reply Last reply Reply Quote 0
          • brookheatherB
            brookheather @stephenw10
            last edited by

            @stephenw10 So I just deleted my WAN shaper (but retained the LAN shaper) and re-enabled if_pppoe - after a reboot I ran a number of speed tests and there were no WAN out errors so it seems to be an issue with having a WAN shaper in conjunction with if_pppoe enabled. I would prefer to have a WAN shaper enabled as it can help when I WFH and max out the 75Mb/s upload capacity during a grid compile. I will leave the config as is for the moment and see how I get on without the WAN shaper.

            K 1 Reply Last reply Reply Quote 0
            • K
              kprovost @brookheather
              last edited by

              @brookheather It's entirely normal for a shaper to drop packets (in fact, that's how they do the shaping). if_pppoe counts those packets drops.
              The 'error' count does not indicate a bug or even anything going wrong.

              brookheatherB 1 Reply Last reply Reply Quote 0
              • brookheatherB
                brookheather @kprovost
                last edited by brookheather

                @kprovost yes I think so as well but the old PPPoE code doesn't count these traffic shaper drops as errors so the question is whether the new if_pppoe should count these as errors - I would only want to see "real" errors - btw I don't see any errors on the LAN side due to the traffic shaper which I have retained.

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

                  Yeah, you won't usually see drops on LAN because the bandwidth limit there is upstream on the pppoe link. It can send packets out to LAN clients much faster than it receives them and hence no need to drop any. But the other way it needs to queue and/or drop packets because 75Mbps is much lower than 1G.

                  You might be better off using Limiters based shaping instead of ALTQ:
                  https://docs.netgate.com/pfsense/en/latest/recipes/codel-limiters.html

                  That can be applied to traffic on the LAN side.

                  J brookheatherB 2 Replies Last reply Reply Quote 0
                  • J
                    jonathan.young @stephenw10
                    last edited by

                    @stephenw10 I have a similar problem to this (I posted earlier in this thread). I had traffic shaping enabled on my WAN interface so I disabled it and tried again with the new PPPoE module (if_pppoe). In my case, it still doesn't work. I cannot get to the web interface but can ssh. System.log is filled with messages like these:

                    Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:30 firewall check_reload_status[531]: rc.newwanip starting pppoe0
Jun 21 14:17:30 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall kernel: ovpnc6: link state changed to DOWN
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall kernel: ovpnc4: link state changed to DOWN
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall kernel: ovpnc3: link state changed to UP
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: rc.newwanip starting ovpnc3
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:31 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:32 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:32 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:32 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:32 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:32 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:32 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:32 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket
Jun 21 14:17:32 firewall check_reload_status[531]: Could not connect to /var/run/php-fpm.socket

                    I do have some OpenVPN and WireGuard client connections to VPN servers. Would that make a difference? Disabling the new PPPoE module (if_pppoe) returns everything back to normal. So it's still broken for me.

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

                      Hmm, that looks like PHP stopped responding. But that could be a symptom of whatever check_reload_status is doing.

                      Does it clear it if you restart php from the console menu?

                      Is that the first error logged after enabling the shaper?

                      How is the shaper configured?

                      1 Reply Last reply Reply Quote 0
                      • brookheatherB
                        brookheather @stephenw10
                        last edited by brookheather

                        @stephenw10 thanks - I have now moved to using limiters with if_pppoe and these work fine without generating any WAN out errors. I followed the guide - can I ask that you update the floating rule documentation slightly and add a note for IPv6 as the Source should by "Any" instead of "WAN Address" for IPv6 - otherwise the limiter has no effect.

                        If the expected behaviour for if_pppoe is that it will increment the WAN out error count for ALTQ shaper dropped packets then it would be useful to note this by the if_pppoe checkbox - perhaps state that ALTQ shapers are not recommended and limiters should be used in their place?

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

                          Mmm, something could be added. Though as I understand it if_pppoe actually works as expected with ALTQ. It's just that users don't expect to see the dropped packets logged as errors,

                          1 Reply Last reply Reply Quote 0
                          • D
                            dorabiatto
                            last edited by

                            [EN_US]

                            Good morning, everyone,

                            I'm a bit lost regarding the PPPoE issue.
                            Has the root cause of the errors been identified?
                            Also, will the fix be included via System Patches? If so, is there an estimated timeline for when that might happen?

                            Thanks in advance!

                            [PT_BR]

                            Bom dia, pessoal!

                            Estou um pouco perdido em relação ao problema com o PPPoE.
                            Vocês já identificaram a causa desses erros?
                            Gostaria de saber também se o fix será incluído via System Patches — e, se sim, há alguma previsão de quando isso deve acontecer?

                            Agradeço desde já!

                            K 1 Reply Last reply Reply Quote 0
                            • K
                              kprovost @dorabiatto
                              last edited by

                              @dorabiatto said in [BUG?] New PPPoE module (if_pppoe) causes high "Errors Out" on WAN (Vivo Fibra):

                              Has the root cause of the errors been identified?

                              Yes. ALTQ decides to drop packets on congestion (which is what it does, this is not a bug) and if_pppoe counts this. Again, not a bug.

                              Also, will the fix be included via System Patches? If so, is there an estimated timeline for when that might happen?

                              There is not fix because there is no bug. We are accurately counting dropped packets. Packets which we meant to drop.

                              1 Reply Last reply Reply Quote 0
                              • D
                                dorabiatto
                                last edited by

                                What can I do to avoid having these errors here in our pfsense? Is there anything I can do or are these thousands of errors normal?

                                brookheatherB 1 Reply Last reply Reply Quote 0
                                • brookheatherB
                                  brookheather @dorabiatto
                                  last edited by brookheather

                                  @dorabiatto do you use the ALTQ traffic shaper? If so just change to use the equivalent limiter instead - you will no longer have errors.

                                  I'm not sure I agree that it is not a bug that if_pppoe shows dropped packets as errors - this wasn't the case with the old code. To me an error should not be shown if it results from expected behaviour of dropping congested packets... a better solution would be to show a separate counter for dropped packets - that would actually be useful.

                                  D 1 Reply Last reply Reply Quote 0
                                  • D
                                    dorabiatto @brookheather
                                    last edited by

                                    @brookheather But is this discarding behavior normal?

                                    Our pfsense is simple, we use it for NAT, VPN, and other simple, everyday things.

                                    I don't think we use ALTQ

                                    Even so, the number of Errors Out is very high.

                                    So, what can I do to avoid having more discarded packets?

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

                                      Check Status > Queues. If there are any queues then you're using ATLQ.

                                      J D 2 Replies Last reply Reply Quote 0
                                      • J
                                        jonathan.young @stephenw10
                                        last edited by

                                        @stephenw10 I disabled any queues that I was using but still my problem persists. I am beginning to think that my problem although related is not the same as the one originally reported so I might create a new thread.

                                        1 Reply Last reply Reply Quote 0
                                        • D
                                          dorabiatto @stephenw10
                                          last edited by

                                          @stephenw10 I checked here.

                                          Traffic shaping is not configured.

                                          ^ I dont have Traffic Shaping.

                                          1 Reply Last reply Reply Quote 0
                                          • D
                                            dorabiatto
                                            last edited by

                                            @brookheather @stephenw10 From what I understand, Errors Out happens to those who use Traffic Shaping and those who don't.

                                            So why does Errors Out happen? Is there any way to avoid it?

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