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

    dpinger does not fallback automatically when interface is availabe again

    Scheduled Pinned Locked Moved Routing and Multi WAN
    3 Posts 2 Posters 237 Views 2 Watching
    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.
    • C Offline
      conover
      last edited by

      Some time ago (must be with the release 24.11, currently running 25.07.1) dpinger stops to recover automatically an interface when the monitored IP is available again.
      After manually restarting the dpinger service the (as failed/offline marked) interface is immediately available again.

      Maybe I changed a configuration item by accident which is responsible for this behaviour, but I can't find something which sounds related to that. As mentioed above, this works perfectly in the past....

      Any help is much appreciated....

      GertjanG 2 Replies Last reply Reply Quote 0
      • GertjanG Offline
        Gertjan @conover
        last edited by

        @conover said in dpinger does not fallback automatically when interface is availabe again:

        Some time ago (must be with the release 24.11, currently running 25.07.1) dpinger stops to recover automatically an interface when the monitored IP is available again.

        When dpinger stops receiving replies to the ping requests, it will :
        Stop itself.
        And just before doing so, it will take the interface down. This interface is typically a WAN type interface.

        Just for the fun : restart reading my reply again - with one new info in your head : what happens if the dpinger ping destination stops replies to ping ? For example : half the planet is using 8.8.8.8 as a ping destination. What will happen when 8.8.8.8 stops answering to ping ?
        Right : half the planet will get disconnected from the internet. And only because 8.8.8.8 stopped answering to ping.
        Seems pretty broken, right ? 😊

        The thing is : there is no good way to determine if a connection is 'working'.

        A real thing is : you should chose your ping destination.
        By default this is the upstream gateway, which could be your own ISP box, sitting right next to pfSense. Not a good choice then. Another "ISP" gateway, more upstream, might not even reply to ping .... (as : why should they ?)

        So, yeah, if dpinger pings an IP, and if that IP stops replying, then that interface will be 'useless' (take down), - the interface then will be taken UP again, dpinger start .... and will fail again, etc.

        If your ISP is 'good enough' you could consider stopping the dpinger 'action' :

        060998db-379c-4b84-a0c7-27628b5ce241-image.png

        or even stop the using dpinger all together - you will lose the stats of course, and the link will be considered as "always up".

        @conover said in dpinger does not fallback automatically when interface is availabe again:

        After manually restarting the dpinger service the (as failed/offline marked) interface is immediately available again.

        This is normally done automatically.
        dpinger will send an interface 'DOWN' even.
        Moments later, the electrical link chip that deals with the physical connection of the RJ45 cable will sync up with the NIC on the other side of the cable, and the link will auto create an interface "UP" event. You can see this with your own eyes : the led, the state indicator, next to the RJ45 plug will light up, on both sides of the connenction. This will start the DHCP client, PPPOE driver, or static setup or whatever you use for your connection. dpinger will also get launched.

        1 Reply Last reply Reply Quote 0
        • GertjanG Offline
          Gertjan @conover
          last edited by

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