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

    DNS Resolver not resolving part 1234

    Scheduled Pinned Locked Moved DHCP and DNS
    41 Posts 4 Posters 5.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.
    • GertjanG
      Gertjan @henkbart
      last edited by

      @henkbart said in DNS Resolver not resolving part 1234:

      45451 root 1 52 0 12M 2252K kqread 1 0:00 0.00% dhcpleases

      Ok.
      Doesn't make any sense.

      I propose :
      Switch back to 'dhcp' mode.
      Save.
      Goto the Resolver settings.
      Now, the DHCP Client registration (and "Static DHCP Client Registration") should be visible.
      Note that your "DHCP Client registration" is checked - is this the case ?
      Uncheck it.
      Save, and then Apply.

      Go back to System > Advanced > Networking and select kea again.

      The "dhcpleases" process is gone now. Correct ?

      Btw :
      As far as I can see on my my pfSense, while using kea, the /var/dhcpd/var/db/dhcpd.leases file isn't used. That file is "watched" by the dhcpleases process, and if it changes, unbound is send a signal to restart.
      So, harmess, I guess.
      But still, strange, as it should even be started in the first place.

      No "help me" PM's please. Use the forum, the community will thank you.
      Edit : and where are the logs ??

      H 1 Reply Last reply Reply Quote 0
      • GertjanG
        Gertjan @henkbart
        last edited by

        @henkbart said in DNS Resolver not resolving part 1234:

        The problem is, that every now and then (and that could be weeks) i loses the ability to connect to the internet.

        You can check your uplink quality.

        15c274b4-846b-4b94-bac5-57ad1067ebcc-image.png

        It should be constant, flat and as small as possible.
        If it start to go up and down, or worse :

        1. you are saturating your connection, and if the 'pipe', up or down is to full, dpinger starts to miss ping packets, it can go in panic mode, and 'restart' your WAN interface.
          No need to explain that if the pipe (uplink) is bad or full, or not working well, the resolver can't do its work neither. Right ?
          .....
        2. call your ISP and say : good bye, I'll leave you for a better one.

        No "help me" PM's please. Use the forum, the community will thank you.
        Edit : and where are the logs ??

        J H 3 Replies Last reply Reply Quote 0
        • H
          henkbart @Gertjan
          last edited by

          @Gertjan
          Hello,
          I did what you wrote.
          Enable DHCP.
          Got :
          FireShot Pro Webpage Capture 278 - 'firewall.private.lan - Services_ DNS Resolver_ General Settings' - 192.168.1.1.png

          So disabled the DHCP Client Registration.
          Saved it.
          And then switch to KEA

          And the dhcpleases is gone now.

          1 Reply Last reply Reply Quote 0
          • J
            jrey @Gertjan
            last edited by jrey

            @Gertjan said in DNS Resolver not resolving part 1234:

            dpinger starts to miss ping packets,

            if that's the problem OP might be able to mitigate some of that by changing the ping times / loss interval etc or by selecting a different monitor IP. (if that is even setup)

            Most users wouldn't notice the difference between the default 500ms setting and even 2-3-4 or 5 seconds.

            if Applicable OP could look https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html

            for the Probe Interval, Loss Interval, Time Period, and Alert Interval seeing how the adjusts could be made and the rules to follow.

            1 Reply Last reply Reply Quote 0
            • H
              henkbart @Gertjan
              last edited by

              @Gertjan
              Here is mine

              FireShot Pro Webpage Capture 279 - 'firewall.private.lan - Status_ Monitoring' - 192.168.1.1.png

              1 Reply Last reply Reply Quote 0
              • J
                jrey @Gertjan
                last edited by

                @Gertjan said in DNS Resolver not resolving part 1234:

                It should be constant, flat and as small as possible.

                Like anything, that depends a lot on scaling resolution, duration of sample as well as the connection. Great guideline but not to be interpreted as a blanket statement.

                For example, the scaling that appears on the graphs, when everything is mostly sub 1ms as shown from my system the graph appears much less flat, but doesn't mean there is a problem.

                Screen Shot 2023-12-12 at 11.06.59 AM.png

                Looking at the data summary under the pretty graph might tell us more ?

                Screen Shot 2023-12-12 at 11.18.51 AM.png

                H 1 Reply Last reply Reply Quote 0
                • H
                  henkbart @jrey
                  last edited by

                  @jrey

                  FireShot Pro Webpage Capture 280 - 'firewall.private.lan - Status_ Monitoring' - 192.168.1.1.png

                  That is mine

                  J 2 Replies Last reply Reply Quote 0
                  • J
                    jrey @henkbart
                    last edited by

                    @henkbart

                    Nothing really interesting here, did you have an issue with connectivity as you've described in the past day?

                    1 Reply Last reply Reply Quote 0
                    • J
                      jrey @henkbart
                      last edited by

                      @henkbart

                      Anything interesting in

                      System Logs > System (Tab) -> Gateways (Tab)?

                      H 1 Reply Last reply Reply Quote 0
                      • H
                        henkbart @jrey
                        last edited by

                        @jrey

                        This is in the Gateway

                        Dec 12 11:01:24 dpinger 91974 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% alarm_hold 10000ms dest_addr 213.93.180.1 bind_addr 213.93.180.238 identifier "WAN_DHCP "
                        Dec 12 11:01:24 dpinger 91974 exiting on signal 15
                        Dec 12 11:01:24 dpinger 97044 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% alarm_hold 10000ms dest_addr 213.93.180.1 bind_addr 213.93.180.238 identifier "WAN_DHCP "
                        Dec 12 11:01:26 dpinger 97044 exiting on signal 15
                        Dec 12 11:01:26 dpinger 57389 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% alarm_hold 10000ms dest_addr 213.93.180.1 bind_addr 213.93.180.238 identifier "WAN_DHCP "
                        Dec 12 11:01:27 dpinger 57389 exiting on signal 15
                        Dec 12 11:01:27 dpinger 81718 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% alarm_hold 10000ms dest_addr 213.93.180.1 bind_addr 213.93.180.238 identifier "WAN_DHCP "

                        J 1 Reply Last reply Reply Quote 0
                        • J
                          jrey @henkbart
                          last edited by

                          @henkbart
                          Ah - so read this

                          https://forum.netgate.com/topic/174601/dpinger-exiting-on-signal-15?_=1702390469713

                          is that logging constant of just those few entries. What else happened at the same time?

                          take that time stamp and start looking at system and other logs, there will likely be something obvious - or something you observed at that time.

                          do you have both the gateways and interfaces widgets on the dashboard?
                          yes -> do you see any of the ports bouncing up and down?
                          no -> put them both on the dashboard?

                          You'll need to figure out what is killing dpinger that rapidly, as mentioned on the other thread it is being explicitly terminated. That can then lead to a whole bunch of other things happening.

                          is the port connection speed and duplex what you expect and what it should be?

                          Tried a different cable? (modem <-> wan)

                          dest_addr 213.93.180.1 so VODAFONE_ZIGGO
                          that's your gateway.
                          ping something further out, setup a monitor IP on
                          System -> Routing -> Gateways - Edit
                          The field is "Monitor IP" try something external but local to you or pick one of the any-cast big boys 8.8.8.8 or 1.1.1.1 etc
                          what kind of response you get from that?

                          Could still be DHCP / but I think you have tried all those checks based on previous items posted.

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