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

    dpinger stops (crashes?) after update to 2.6.0

    Scheduled Pinned Locked Moved General pfSense Questions
    47 Posts 6 Posters 9.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.
    • K
      Klaus2314 @stephenw10
      last edited by Klaus2314

      @stephenw10 The route works just fine even when dpinger stops operating. No problems there. The gateway works as well. Strange. Never happened before in 200+ non-stop up days. It started after the upgrade to 2.6.0 and now happens many times every day.
      But it has zero impact on my network. I only notice it when I login to pfense once a day and see that dpinger is "off" in the status widget.
      I have now added dpinger to the service watchdog to get notifications when it's force started again. I have now also changed the default gateway from Auto to the WAN interface maybe 2.6.0 wants this to be set manually now. I only have one WAN interface so it doesn't really matter.
      I also found this https://forum.netgate.com/topic/169990/failover-on-pfsense-2-6
      Might be connected?

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

        Not enough info on that other ticket, yet, to know if it's related.

        I assume you are also using 9.9.9.9 as your monitoring ping target?
        Does it change if you allow it to monitor the gateway directly?

        If you only have one gateway it should always be the default. Nothing has changed there in 2.6.
        Setting it to WAN specifically does not hurt though.

        Are there really no log entries when it stops other than the watchdog?

        Steve

        K 1 Reply Last reply Reply Quote 0
        • K
          Klaus2314 @stephenw10
          last edited by Klaus2314

          @stephenw10 The default gateway can be set to auto or a specific one in the drop down menu. For the last 2 years it was set to auto and worked fine. I have now changed it from auto to the WAN interface and dpinger has been fine.
          And yes it was pinging 9.9.9.9 for the last 2 years.
          Also there has never been an interruption of internet access when dpinger stopped.
          Not sure what happened but setting the default gateway manually seems to have fixed it. Even without the watchdog.
          Oh, and no there were no other log entires than the ones mentioned.

          Thanks for chiming in!

          Klaus.

          1 Reply Last reply Reply Quote 1
          • K
            Klaus2314
            last edited by Klaus2314

            Sorry, celebrated too early. dpinger still stops to work and I see these gateway logs. I don't quite understand why the pinger stops to work when the gateway can't be pinged. Shouldn't it keep on trying? (regardless the state of the gateway I mean?)

            Bildschirmfoto 2022-02-18 um 16.25.15.png

            Bildschirmfoto 2022-02-18 um 16.23.05.png

            I'll active service watchdog now.

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

              Hmm, those logs are both dpinger starting. There are no errors on the system log in between those showing why it stopped?

              K 1 Reply Last reply Reply Quote 0
              • K
                Klaus2314 @stephenw10
                last edited by Klaus2314

                @stephenw10 only this
                404e07b1-2143-4adf-9e27-c985402c5386-image.png

                (this was just weh it happened the next time)

                255eb52c-11d7-4913-802d-52439e9b754f-image.png

                Needless to say during that event Internet didn't go down for me.

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

                  Hmm, none of that is an error. It just stops silently....

                  Is that with 'Gateway Monitoring Action' disabled? I wonder if it's trying to do something and failing.

                  K 1 Reply Last reply Reply Quote 0
                  • K
                    Klaus2314 @stephenw10
                    last edited by

                    @stephenw10 4daefe2d-7735-4a73-9907-ea64b969a3f4-image.png

                    1 Reply Last reply Reply Quote 0
                    • K
                      Klaus2314
                      last edited by Klaus2314

                      Just to see what happens I have now set the monitor address to the Fibre modem (the actual gateway) instead of Quad9.

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

                        Ok, that's a reasonable test.

                        If you only have one WAN disabling the monitoring action is also a good test.

                        1 Reply Last reply Reply Quote 0
                        • K
                          Klaus2314
                          last edited by Klaus2314

                          Ok, so after a couple of days I can see that dpinger stops (and is restarted by watchdog) right after pfblocker has updated at 3AM which also leads to a restart of unbound. So somehow dpinger doesn't seem to like that and decides to stop.
                          All the same cron settings since before the update to 2.6.0 though.
                          Interestingly it doesn't happen at all on my second installation (21.6) SG1100 also running pfblocker. For some reason on that system dpinger keeps on trucking.

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

                            Do you have DNS-BL runing on both? That's what would restart Unbound.

                            No idea why restarting Unbound would cause an issue for dpinger though.

                            K 1 Reply Last reply Reply Quote 0
                            • K
                              Klaus2314 @stephenw10
                              last edited by Klaus2314

                              @stephenw10 Yes more or less same setup on both appliances. No crashes on the SG1100.
                              Another thing. It seems like the notification page does not store the email password so I am not getting any notifications anymore. When I paste the password again and trigger a test email it will go through. However after hitting save and coming back to that page the PW has been lost.
                              This also has worked just fine before the update. And: The latter also only happens on the 2.6.0 installation, not on the SG1100.
                              After sending the test email I can see the PW field on that settings page fall back to some old PW it has stored by the amount of dots in that field. When I hit send test email again it fails because of wrong PW. So it just doesn't seem to store that setting.

                              1 Reply Last reply Reply Quote 0
                              • K
                                Klaus2314
                                last edited by

                                Ok sorry, the email thing was user error. It's a bit confusing. The email pw gets used AFTER saving. So that works now. And 5 minutes later I get a message that dpinger has been relaunched by watchdog.

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

                                  Hmm, well anything logged to show why Unbound stops? In the system or resolver logs?

                                  K 1 Reply Last reply Reply Quote 0
                                  • NollipfSenseN
                                    NollipfSense
                                    last edited by

                                    I get the same exact behavior mostly night at 16minutes pass midnight dpinger stops and sometimes at 5minutes pass midnight and on rare occasion during it stops. Most of the time now the error is sento 50, sometimes there are latency alarm and clear latency. I added this to the system turnable: kern.ipc.maxsockbuf Maximum socket buffer size 1000000
                                    That seems to take of the sento error 65.

                                    pfSense+ 23.09 Lenovo Thinkcentre M93P SFF Quadcore i7 dual Raid-ZFS 128GB-SSD 32GB-RAM PCI-Intel i350-t4 NIC, -Intel QAT 8950.
                                    pfSense+ 23.09 VM-Proxmox, Dell Precision Xeon-W2155 Nvme 500GB-ZFS 128GB-RAM PCIe-Intel i350-t4, Intel QAT-8950, P-cloud.

                                    1 Reply Last reply Reply Quote 0
                                    • K
                                      Klaus2314 @stephenw10
                                      last edited by Klaus2314

                                      @stephenw10 So I tried to reproduce the dpinger thing and simply pulled the cable going to the WAN port of pfsense (instead of waiting for the next time the connect goes down) and put it back in. A second later I receive a notification email that dpinger was relaunched by watch dog. I did it 3-4 times again. Dpinger stops every single time.

                                      This was with Gateway Monitoring Action turned off, btw.

                                      On the same ticket I found that the patch cable going into pfsense has a bad connection when moved so the ping dropping out might have been caused by the cable being just on the edge of failing and then reconnecting.

                                      However this doesn't explain why dpinger decides to stop doing it's thing when that happens. And this definitely didn't happen before the upgrade.

                                      Hm...

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

                                        Mmm, I would expect dpinger to stop if the WAN loses link and that's the only gateway. But it should start again when you reconnect it. Without needing the watchdog package.

                                        Steve

                                        K dennypageD 2 Replies Last reply Reply Quote 0
                                        • K
                                          Klaus2314 @stephenw10
                                          last edited by

                                          @stephenw10 Right, that makes sense. So maybe that's a new bug then? The fact that dpinger doesn't come back to life after a disconnect? (unlike the previous version of pfsense I mean)

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

                                            Mmm, it could be. It feels like a timing issue. Not sure what might have changed there though.

                                            I expect to see something logged with it trying to start and failing....

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