NO DNS after update 2.1.4 –> 2.1.5



  • Hallo dear Community,

    over last years i was able to find a solution in this forum. Now i have one that make me crazy!

    In last hours i invoked an update on two x86 machines from 2.1.4 to 2.1.5 over the webGUI and everything was fine. But now we do not have an access to DNS. And it is very strange.

    Following Situation:

    • The Connection to the ISP over PPPoE is working i'm able to ping any v4 addresses from the router and from any machine in the local network.
    • I'm able also to resolve the DNS name over the webGUI "DNS lookup" over all DNS Servers
    • but it is not possible to get any DNS resolve on any machine in the local network.
    • also under packages in webGUI, is no Version check do to no DNS resolving of "pfsense.org".
    • as well the dynamic DNS is not updating

    log:" php: /services_dyndns_edit.php: Curl error occurred: Could not resolve host: members.dyndns.org"

    • in the same time the DNS forwarder is look like it works. I'm able to rich any Service in any of our 5 Networks (xxxx.net2 -> 192.168.9.7)

    • both machines show this issue.

    Configuration:

    more or less standard config with set DNS server (No override by PPPoE)

    • no ipv6
      Services on the machines
    • DHCP, DNs Forwarder,apinger, havp, ntpd, openvpn, squid3
    • the switching off of the suid3 and havp do not solve the problem

    I'm going crazy!!! Do some body know what is going on?

    update

    • By switching the DNS Forwarder off the local Networks get the DNS resolve
    • but if i set the suid3 in transparent mode than the system is not able resolve the the DNS over localhost! So looks like the localhost in DNS Forwarder and/or the systems are not working properly.  :(


  • OK now I'm managed but not solved.
    by selecting the option "Allow DNS server list to be overridden by DHCP/PPP on WAN" under "System -> General Setup" and reset the WAN interface everything is working fine as before update. But the system is not using the DNS  entered under the "DNS servers". By unselected override option the systems is again not able to get the DNS resolve.

    So looks like as the new bug.



  • I have the same problem  :(



  • I have a similar problem. Post update, all of the client devices on my home network will lose their internet connection. Then after a couple of hours they are able to connect again for about 20 minutes before they go down again. During the "down" time I can VPN into the network, perform DNS Lookups using the tool  under Diagnostics. The WAN Gateway shows as up and I can ping my gateway from outside. It seems to me that none of the devices are able to do name resolutions.

    I have a houseful of kids who start school on Tuesday and desperately need a solution.

    If I can't find one, how do I rollback the update?


  • Banned



  • @denningsrogue:

    I have a similar problem. Post update, all of the client devices on my home network will lose their internet connection. Then after a couple of hours they are able to connect again for about 20 minutes before they go down again. During the "down" time I can VPN into the network, perform DNS Lookups using the tool  under Diagnostics. The WAN Gateway shows as up and I can ping my gateway from outside. It seems to me that none of the devices are able to do name resolutions.

    I have a houseful of kids who start school on Tuesday and desperately need a solution.

    If I can't find one, how do I rollback the update?

    If it's nano you simply switch to the other slice (hope you did a copy to that slice recently! Otherwise it's native)

    Under Diagnostics -> nanoBSD you will find the option to switch boot slice and afterwards you can do a reboot and will end on the other slice



  • I had this exact same problem.  After hours of analysis I was able to determine that the problem was an EasyRule created under Firewall > Rules and an associated Firewall > Aliases I had created to remove pfBlocker based Firewall log entries.

    After removed both of these entries things 2.1.5 worked fine.



  • Are there any errors under Status -> System Logs -> System -> Resolver ?

    I had the same issue after a brand new installation of 2.1.5 on an Alix 2d3…despite setting DNS entries in General, they would not show up on the dashboard, and I could not resolve any names.

    I noticed that /etc/resolv.conf was missing, I had to change over to RW mode and manually create this file.



  • @denningsrogue:

    I have a similar problem. Post update, all of the client devices on my home network will lose their internet connection. Then after a couple of hours they are able to connect again for about 20 minutes before they go down again. During the "down" time I can VPN into the network, perform DNS Lookups using the tool  under Diagnostics. The WAN Gateway shows as up and I can ping my gateway from outside. It seems to me that none of the devices are able to do name resolutions.

    I have a houseful of kids who start school on Tuesday and desperately need a solution.

    If I can't find one, how do I rollback the update?

    I confirm the same Problem. The Resolver is crashing after update

    Aug 29 13:45:40 dnsmasq[51339]: exiting on receipt of SIGTERM
    Aug 29 13:31:25 dnsmasq[51339]: nameserver 160.45.10.12 refused to do a recursive query
    Aug 29 13:31:24 dnsmasq[51339]: nameserver 160.45.8.8 refused to do a recursive query
    Aug 29 13:31:23 dnsmasq[51339]: read /etc/hosts - 19 addresses
    Aug 29 13:31:23 dnsmasq[51339]: using nameserver 8.8.8.8#53
    Aug 29 13:31:23 dnsmasq[51339]: using nameserver 130.133.1.57#53
    Aug 29 13:31:23 dnsmasq[51339]: using nameserver 160.45.10.12#53
    Aug 29 13:31:23 dnsmasq[51339]: using nameserver 160.45.8.8#53
    Aug 29 13:31:23 dnsmasq[51339]: ignoring nameserver 127.0.0.1 - local interface
    Aug 29 13:31:23 dnsmasq[51339]: reading /etc/resolv.conf
    Aug 29 13:31:23 dnsmasq[51339]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC
    Aug 29 13:31:23 dnsmasq[51339]: started, version 2.70 cachesize 10000
    Aug 29 13:27:22 dnsmasq[26199]: read /etc/hosts - 19 addresses
    Aug 29 13:27:22 dnsmasq[26199]: using nameserver 8.8.8.8#53
    Aug 29 13:27:22 dnsmasq[26199]: using nameserver 130.133.1.57#53
    Aug 29 13:27:22 dnsmasq[26199]: using nameserver 160.45.10.12#53
    Aug 29 13:27:22 dnsmasq[26199]: using nameserver 160.45.8.8#53
    Aug 29 13:27:22 dnsmasq[26199]: ignoring nameserver 127.0.0.1 - local interface
    Aug 29 13:27:22 dnsmasq[26199]: reading /etc/resolv.conf
    Aug 29 13:27:22 dnsmasq[26199]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC
    Aug 29 13:27:22 dnsmasq[26199]: started, version 2.70 cachesize 10000
    Aug 29 13:27:21 dnsmasq[12936]: exiting on receipt of SIGTERM
    Aug 29 13:26:50 dnsmasq[12936]: read /etc/hosts - 19 addresses
    Aug 29 13:26:50 dnsmasq[12936]: using nameserver 8.8.8.8#53
    Aug 29 13:26:50 dnsmasq[12936]: using nameserver 130.133.1.57#53
    Aug 29 13:26:50 dnsmasq[12936]: using nameserver 160.45.10.12#53
    Aug 29 13:26:50 dnsmasq[12936]: using nameserver 160.45.8.8#53
    Aug 29 13:26:50 dnsmasq[12936]: ignoring nameserver 127.0.0.1 - local interface
    Aug 29 13:26:50 dnsmasq[12936]: reading /etc/resolv.conf
    Aug 29 13:26:50 dnsmasq[12936]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC
    Aug 29 13:26:50 dnsmasq[12936]: started, version 2.70 cachesize 10000
    Aug 29 13:26:27 dnsmasq[46406]: exiting on receipt of SIGTERM
    Aug 29 13:19:02 dnsmasq[46406]: nameserver 160.45.10.12 refused to do a recursive query
    Aug 29 13:19:00 dnsmasq[46406]: nameserver 160.45.8.8 refused to do a recursive query
    Aug 29 13:18:59 dnsmasq[46406]: read /etc/hosts - 19 addresses
    Aug 29 13:18:59 dnsmasq[46406]: using nameserver 8.8.8.8#53
    Aug 29 13:18:59 dnsmasq[46406]: using nameserver 130.133.1.57#53
    Aug 29 13:18:59 dnsmasq[46406]: using nameserver 160.45.10.12#53
    Aug 29 13:18:59 dnsmasq[46406]: using nameserver 160.45.8.8#53
    Aug 29 13:18:59 dnsmasq[46406]: ignoring nameserver 127.0.0.1 - local interface
    Aug 29 13:18:59 dnsmasq[46406]: reading /etc/resolv.conf
    Aug 29 13:18:59 dnsmasq[46406]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC
    Aug 29 13:18:59 dnsmasq[46406]: started, version 2.70 cachesize 10000

    By Query DNS servers sequentially seem to solve the Problem.


  • Banned

    Can you try and disable IPv6 on that interface?



  • I have same problem too.  :(

    Here is my log after update to new ver 2.1.5. I delete all packages and did default reset…

    Sys Log:

    Sep 3 16:43:39 pfSense php: rc.newwanip: pfSense package system has detected an ip change 173.19.0.54 -> 173.19.0.54 ... Restarting packages.
    Sep 3 21:43:39 pfSense check_reload_status: Starting packages
    Sep 3 21:43:39 pfSense check_reload_status: Reloading filter
    Sep 3 16:43:43 pfSense php: rc.start_packages: Restarting/Starting all packages.
    Sep 3 21:44:01 pfSense check_reload_status: Syncing firewall
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:04 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:05 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:06 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:06 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:06 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:08 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:08 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 21:44:08 pfSense kernel: arpresolve: can't allocate llinfo for 173.19.0.1
    Sep 3 16:44:08 pfSense php: /interfaces.php: Shutting down Router Advertisment daemon cleanly
    Sep 3 16:44:08 pfSense php: /interfaces.php: Clearing states to old gateway 173.19.0.1.
    Sep 3 21:44:09 pfSense check_reload_status: rc.newwanip starting bge0
    Sep 3 16:44:09 pfSense php: /interfaces.php: ROUTING: setting default route to 173.19.0.1
    Sep 3 16:44:11 pfSense php: rc.newwanip: rc.newwanip: Informational is starting bge0.
    Sep 3 16:44:11 pfSense php: rc.newwanip: rc.newwanip: on (IP address: 173.19.0.54) (interface: WAN[wan]) (real interface: bge0).
    Sep 3 16:44:11 pfSense php: rc.newwanip: ROUTING: setting default route to 173.19.0.1
    Sep 3 21:44:14 pfSense check_reload_status: updating dyndns wan
    Sep 3 21:44:16 pfSense check_reload_status: Reloading filter
    Sep 3 16:44:16 pfSense php: /interfaces.php: Creating rrd update script
    Sep 3 16:44:16 pfSense php: rc.newwanip: Resyncing OpenVPN instances for interface WAN.
    Sep 3 16:44:16 pfSense php: rc.newwanip: Creating rrd update script
    Sep 3 16:44:18 pfSense php: rc.newwanip: pfSense package system has detected an ip change 173.19.0.54 -> 173.19.0.54 … Restarting packages.
    Sep 3 21:44:18 pfSense check_reload_status: Starting packages
    Sep 3 21:44:18 pfSense check_reload_status: Reloading filter
    Sep 3 16:44:22 pfSense php: rc.start_packages: Restarting/Starting all packages.

    Resolver Log:

    Sep 3 09:07:58 pfSense dnsmasq[68980]: using nameserver 97.64.183.164#53
    Sep 3 09:07:58 pfSense dnsmasq[68980]: using nameserver 97.64.209.37#53
    Sep 3 09:07:58 pfSense dnsmasq[68980]: using nameserver 97.64.183.164#53
    Sep 3 09:07:58 pfSense dnsmasq[68980]: read /etc/hosts - 2 addresses
    Sep 3 16:34:55 pfSense dnsmasq[68980]: reading /etc/resolv.conf
    Sep 3 16:34:55 pfSense dnsmasq[68980]: ignoring nameserver 127.0.0.1 - local interface
    Sep 3 16:34:55 pfSense dnsmasq[68980]: using nameserver 97.64.183.164#53
    Sep 3 16:34:55 pfSense dnsmasq[68980]: using nameserver 97.64.209.37#53
    Sep 3 16:34:55 pfSense dnsmasq[68980]: using nameserver 97.64.183.164#53
    Sep 3 16:34:55 pfSense dnsmasq[68980]: using nameserver 97.64.209.37#53
    Sep 3 16:34:56 pfSense dnsmasq[68980]: exiting on receipt of SIGTERM
    Sep 3 16:34:57 pfSense dnsmasq[75486]: started, version 2.70 cachesize 10000
    Sep 3 16:34:57 pfSense dnsmasq[75486]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC
    Sep 3 16:34:57 pfSense dnsmasq[75486]: reading /etc/resolv.conf
    Sep 3 16:34:57 pfSense dnsmasq[75486]: ignoring nameserver 127.0.0.1 - local interface
    Sep 3 16:34:57 pfSense dnsmasq[75486]: using nameserver 97.64.183.164#53
    Sep 3 16:34:57 pfSense dnsmasq[75486]: using nameserver 97.64.209.37#53
    Sep 3 16:34:57 pfSense dnsmasq[75486]: using nameserver 97.64.183.164#53
    Sep 3 16:34:57 pfSense dnsmasq[75486]: using nameserver 97.64.209.37#53
    Sep 3 16:34:57 pfSense dnsmasq[75486]: read /etc/hosts - 2 addresses
    Sep 3 16:35:46 pfSense dnsmasq[75486]: exiting on receipt of SIGTERM
    Sep 3 16:35:47 pfSense dnsmasq[13668]: started, version 2.70 cachesize 10000
    Sep 3 16:35:47 pfSense dnsmasq[13668]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC
    Sep 3 16:35:47 pfSense dnsmasq[13668]: reading /etc/resolv.conf
    Sep 3 16:35:47 pfSense dnsmasq[13668]: ignoring nameserver 127.0.0.1 - local interface
    Sep 3 16:35:47 pfSense dnsmasq[13668]: using nameserver 97.64.183.164#53
    Sep 3 16:35:47 pfSense dnsmasq[13668]: using nameserver 97.64.209.37#53
    Sep 3 16:35:47 pfSense dnsmasq[13668]: using nameserver 97.64.183.164#53
    Sep 3 16:35:47 pfSense dnsmasq[13668]: using nameserver 97.64.209.37#53
    Sep 3 16:35:47 pfSense dnsmasq[13668]: read /etc/hosts - 2 addresses
    Sep 3 16:43:31 pfSense dnsmasq[13668]: exiting on receipt of SIGTERM
    Sep 3 16:43:33 pfSense dnsmasq[50952]: started, version 2.70 cachesize 10000
    Sep 3 16:43:33 pfSense dnsmasq[50952]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC
    Sep 3 16:43:33 pfSense dnsmasq[50952]: reading /etc/resolv.conf
    Sep 3 16:43:33 pfSense dnsmasq[50952]: ignoring nameserver 127.0.0.1 - local interface
    Sep 3 16:43:33 pfSense dnsmasq[50952]: using nameserver 97.64.183.164#53
    Sep 3 16:43:33 pfSense dnsmasq[50952]: using nameserver 97.64.209.37#53
    Sep 3 16:43:33 pfSense dnsmasq[50952]: using nameserver 97.64.183.164#53
    Sep 3 16:43:33 pfSense dnsmasq[50952]: using nameserver 97.64.209.37#53
    Sep 3 16:43:33 pfSense dnsmasq[50952]: read /etc/hosts - 2 addresses
    Sep 3 16:44:11 pfSense dnsmasq[50952]: exiting on receipt of SIGTERM
    Sep 3 16:44:12 pfSense dnsmasq[7589]: started, version 2.70 cachesize 10000
    Sep 3 16:44:12 pfSense dnsmasq[7589]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC
    Sep 3 16:44:12 pfSense dnsmasq[7589]: reading /etc/resolv.conf
    Sep 3 16:44:12 pfSense dnsmasq[7589]: ignoring nameserver 127.0.0.1 - local interface
    Sep 3 16:44:12 pfSense dnsmasq[7589]: using nameserver 97.64.183.164#53
    Sep 3 16:44:12 pfSense dnsmasq[7589]: using nameserver 97.64.209.37#53
    Sep 3 16:44:12 pfSense dnsmasq[7589]: using nameserver 97.64.183.164#53
    Sep 3 16:44:12 pfSense dnsmasq[7589]: using nameserver 97.64.209.37#53
    Sep 3 16:44:12 pfSense dnsmasq[7589]: read /etc/hosts - 2 addresses

    Gateway Log:

    Sep 2 22:01:37 apinger: No usable targets found, exiting
    Sep 2 22:02:04 apinger: Starting Alarm Pinger, apinger(5986)
    Sep 2 22:24:31 apinger: ALARM: WAN_DHCP(173.19.0.1) *** down ***
    Sep 2 22:24:59 apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** down ***
    Sep 2 22:28:30 apinger: Starting Alarm Pinger, apinger(26230)
    Sep 2 22:33:59 apinger: ALARM: WAN_DHCP(173.19.0.1) *** loss ***
    Sep 2 22:34:49 apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** loss ***
    Sep 2 22:43:14 apinger: ALARM: WAN_DHCP(173.19.0.1) *** down ***
    Sep 2 22:43:24 apinger: SIGHUP received, reloading configuration.
    Sep 2 22:43:24 apinger: alarm canceled (config reload): WAN_DHCP(173.19.0.1) *** down ***
    Sep 2 22:43:38 apinger: ALARM: WAN_DHCP(192.168.100.1) *** down ***
    Sep 2 22:43:41 apinger: alarm canceled: WAN_DHCP(192.168.100.1) *** down ***
    Sep 2 22:43:45 apinger: SIGHUP received, reloading configuration.
    Sep 2 22:44:45 apinger: SIGHUP received, reloading configuration.
    Sep 3 04:50:02 pfSense apinger: Starting Alarm Pinger, apinger(19573)
    Sep 3 04:50:02 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 04:59:42 pfSense apinger: Starting Alarm Pinger, apinger(22980)
    Sep 3 04:59:42 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 05:13:00 pfSense apinger: Starting Alarm Pinger, apinger(21778)
    Sep 3 05:13:00 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 05:17:43 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 05:17:59 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** down ***
    Sep 3 05:26:12 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 05:26:12 pfSense apinger: alarm canceled (config reload): WAN_DHCP(173.19.0.1) *** down ***
    Sep 3 05:26:12 pfSense apinger: No usable targets found, exiting
    Sep 3 00:32:41 pfSense apinger: Starting Alarm Pinger, apinger(3634)
    Sep 3 00:32:45 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 00:35:55 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** loss ***
    Sep 3 00:37:41 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** loss ***
    Sep 3 07:54:35 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** loss ***
    Sep 3 07:56:17 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** loss ***
    Sep 3 08:50:55 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** down ***
    Sep 3 09:07:56 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** down ***
    Sep 3 09:07:58 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 10:57:35 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 10:58:16 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 10:58:44 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 10:59:31 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 12:06:20 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 12:06:59 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 15:46:02 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 15:46:20 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 15:59:35 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 15:59:45 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 16:02:26 pfSense apinger: ALARM: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 16:02:35 pfSense apinger: alarm canceled: WAN_DHCP(173.19.0.1) *** delay ***
    Sep 3 16:43:32 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 16:43:37 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 16:44:11 pfSense apinger: SIGHUP received, reloading configuration.
    Sep 3 16:44:16 pfSense apinger: SIGHUP received, reloading configuration.



  • @Supermule:

    Can you try and disable IPv6 on that interface?

    I do not use IPv6. On every Interfaces the v6 is set on "none" and under the advanced setings -> networking the "Allow IPv6" is not set.


  • Banned

    Why does your logs have this?

    Sep 2 22:43:14  apinger: ALARM: WAN_DHCP(173.19.0.1) *** down ***
    Sep 2 22:43:24  apinger: SIGHUP received, reloading configuration.
    Sep 2 22:43:24  apinger: alarm canceled (config reload): WAN_DHCP(173.19.0.1) *** down ***
    Sep 2 22:43:38  apinger: ALARM: WAN_DHCP(192.168.100.1) *** down ***
    Sep 2 22:43:41  apinger: alarm canceled: WAN_DHCP(192.168.100.1) *** down ***
    Sep 2 22:43:45  apinger: SIGHUP received, reloading configuration.
    Sep 2 22:44:45  apinger: SIGHUP received, reloading configuration.



  • IP6 is not set but still getting this log.

    Sep 2 22:43:38  apinger: ALARM: WAN_DHCP(192.168.100.1) *** down ***
    Sep 2 22:43:41  apinger: alarm canceled: WAN_DHCP(192.168.100.1) *** down ***

    I have no clue why this happen? so I set box to default and start from scratch again here is the sys log…

    Sep 10 01:50:41 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
    Sep 10 01:50:41 kernel: FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads
    Sep 10 01:50:41 kernel: cpu0 (BSP): APIC ID: 0
    Sep 10 01:50:41 kernel: cpu1 (AP/HT): APIC ID: 1
    Sep 10 01:50:41 kernel: ioapic0 <version 2.0="">irqs 0-23 on motherboard
    Sep 10 01:50:41 kernel: wlan: mac acl policy registered
    Sep 10 01:50:41 kernel: ipw_bss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
    Sep 10 01:50:41 kernel: ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
    Sep 10 01:50:41 kernel: module_register_init: MOD_LOAD (ipw_bss_fw, 0xc07c1560, 0) error 1
    Sep 10 01:50:41 kernel: ipw_ibss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
    Sep 10 01:50:41 kernel: ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
    Sep 10 01:50:41 kernel: module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc07c1600, 0) error 1
    Sep 10 01:50:41 kernel: ipw_monitor: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
    Sep 10 01:50:41 kernel: ipw_monitor: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
    Sep 10 01:50:41 kernel: module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc07c16a0, 0) error 1
    Sep 10 01:50:41 kernel: kbd1 at kbdmux0
    Sep 10 01:50:41 kernel: cryptosoft0: <software crypto="">on motherboard
    Sep 10 01:50:41 kernel: padlock0: No ACE support.
    Sep 10 01:50:41 kernel: acpi0: <111209 RSDT1934> on motherboard
    Sep 10 01:50:41 kernel: acpi0: [ITHREAD]
    Sep 10 01:50:41 kernel: acpi0: Power Button (fixed)
    Sep 10 01:50:41 kernel: acpi0: reservation of fee00000, 1000 (3) failed
    Sep 10 01:50:41 kernel: acpi0: reservation of 0, a0000 (3) failed
    Sep 10 01:50:41 kernel: acpi0: reservation of 100000, 7bd00000 (3) failed
    Sep 10 01:50:41 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
    Sep 10 01:50:41 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
    Sep 10 01:50:41 kernel: cpu0: <acpi cpu="">on acpi0
    Sep 10 01:50:41 kernel: ACPI Warning: Incorrect checksum in table [OEMB] - 0x70, should be 0x69 (20101013/tbutils-354)
    Sep 10 01:50:41 kernel: cpu1: <acpi cpu="">on acpi0
    Sep 10 01:50:41 kernel: pcib0: <acpi host-pci="" bridge="">port 0xcf8-0xcff on acpi0
    Sep 10 01:50:41 kernel: pci0: <acpi pci="" bus="">on pcib0
    Sep 10 01:50:41 kernel: vgapci0: <vga-compatible display="">port 0xb080-0xb087 mem 0xfe400000-0xfe7fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0
    Sep 10 01:50:41 kernel: agp0: <intel gm45="" svga="" controller="">on vgapci0
    Sep 10 01:50:41 kernel: agp0: aperture size is 256M, detected 65532k stolen memory
    Sep 10 01:50:41 kernel: vgapci1: <vga-compatible display="">mem 0xfe800000-0xfe8fffff at device 2.1 on pci0
    Sep 10 01:50:41 kernel: uhci0: <intel 82801i="" (ich9)="" usb="" controller="">port 0xb800-0xb81f irq 16 at device 26.0 on pci0
    Sep 10 01:50:41 kernel: uhci0: [ITHREAD]
    Sep 10 01:50:41 kernel: uhci0: LegSup = 0x2f00
    Sep 10 01:50:41 kernel: usbus0: <intel 82801i="" (ich9)="" usb="" controller="">on uhci0
    Sep 10 01:50:41 kernel: uhci1: <intel 82801i="" (ich9)="" usb="" controller="">port 0xb480-0xb49f irq 21 at device 26.1 on pci0
    Sep 10 01:50:41 kernel: uhci1: [ITHREAD]
    Sep 10 01:50:41 kernel: uhci1: LegSup = 0x2f00
    Sep 10 01:50:41 kernel: usbus1: <intel 82801i="" (ich9)="" usb="" controller="">on uhci1
    Sep 10 01:50:41 kernel: uhci2: <intel 82801i="" (ich9)="" usb="" controller="">port 0xb400-0xb41f irq 19 at device 26.2 on pci0
    Sep 10 01:50:41 kernel: uhci2: [ITHREAD]
    Sep 10 01:50:41 kernel: uhci2: LegSup = 0x2f00
    Sep 10 01:50:41 kernel: usbus2: <intel 82801i="" (ich9)="" usb="" controller="">on uhci2
    Sep 10 01:50:41 kernel: ehci0: <intel 82801i="" (ich9)="" usb="" 2.0="" controller="">mem 0xfe9ff400-0xfe9ff7ff irq 18 at device 26.7 on pci0
    Sep 10 01:50:41 kernel: ehci0: [ITHREAD]
    Sep 10 01:50:41 kernel: usbus3: EHCI version 1.0
    Sep 10 01:50:41 kernel: usbus3: <intel 82801i="" (ich9)="" usb="" 2.0="" controller="">on ehci0
    Sep 10 01:50:41 kernel: pci0: <multimedia, hda="">at device 27.0 (no driver attached)
    Sep 10 01:50:41 kernel: pcib1: <acpi pci-pci="" bridge="">irq 17 at device 28.0 on pci0
    Sep 10 01:50:41 kernel: pci2: <acpi pci="" bus="">on pcib1
    Sep 10 01:50:41 kernel: pcib2: <acpi pci-pci="" bridge="">irq 17 at device 28.4 on pci0
    Sep 10 01:50:41 kernel: pci3: <acpi pci="" bus="">on pcib2
    Sep 10 01:50:41 kernel: pcib3: <acpi pci-pci="" bridge="">irq 16 at device 28.5 on pci0
    Sep 10 01:50:41 kernel: pci4: <acpi pci="" bus="">on pcib3
    Sep 10 01:50:41 kernel: bge0: <broadcom bcm57780="" a1,="" asic="" rev.="" 0x57780001="">mem 0xfebf0000-0xfebfffff irq 17 at device 0.0 on pci4
    Sep 10 01:50:41 kernel: bge0: CHIP ID 0x57780001; ASIC REV 0x57780; CHIP REV 0x577800; PCI-E
    Sep 10 01:50:41 kernel: miibus0: <mii bus="">on bge0
    Sep 10 01:50:41 kernel: brgphy0: <bcm57780 1000base-t="" media="" interface="">PHY 1 on miibus0
    Sep 10 01:50:41 kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
    Sep 10 01:50:41 kernel: bge0: [ITHREAD]
    Sep 10 01:50:41 kernel: uhci3: <intel 82801i="" (ich9)="" usb="" controller="">port 0xc000-0xc01f irq 23 at device 29.0 on pci0
    Sep 10 01:50:41 kernel: uhci3: [ITHREAD]
    Sep 10 01:50:41 kernel: uhci3: LegSup = 0x2f00
    Sep 10 01:50:41 kernel: usbus4: <intel 82801i="" (ich9)="" usb="" controller="">on uhci3
    Sep 10 01:50:41 kernel: uhci4: <intel 82801i="" (ich9)="" usb="" controller="">port 0xbc00-0xbc1f irq 19 at device 29.1 on pci0
    Sep 10 01:50:41 kernel: uhci4: [ITHREAD]
    Sep 10 01:50:41 kernel: uhci4: LegSup = 0x2f00
    Sep 10 01:50:41 kernel: usbus5: <intel 82801i="" (ich9)="" usb="" controller="">on uhci4
    Sep 10 01:50:41 kernel: uhci5: <intel 82801i="" (ich9)="" usb="" controller="">port 0xb880-0xb89f irq 18 at device 29.2 on pci0
    Sep 10 01:50:41 kernel: uhci5: [ITHREAD]
    Sep 10 01:50:41 kernel: uhci5: LegSup = 0x2f00
    Sep 10 01:50:41 kernel: usbus6: <intel 82801i="" (ich9)="" usb="" controller="">on uhci5
    Sep 10 01:50:41 kernel: ehci1: <intel 82801i="" (ich9)="" usb="" 2.0="" controller="">mem 0xfe9ff800-0xfe9ffbff irq 23 at device 29.7 on pci0
    Sep 10 01:50:41 kernel: ehci1: [ITHREAD]
    Sep 10 01:50:41 kernel: usbus7: EHCI version 1.0
    Sep 10 01:50:41 kernel: usbus7: <intel 82801i="" (ich9)="" usb="" 2.0="" controller="">on ehci1
    Sep 10 01:50:41 kernel: pcib4: <acpi pci-pci="" bridge="">at device 30.0 on pci0
    Sep 10 01:50:41 kernel: pci1: <acpi pci="" bus="">on pcib4
    Sep 10 01:50:41 kernel: em0: <intel(r) 1000="" pro="" legacy="" network="" connection="" 1.0.6="">port 0xec00-0xec3f mem 0xfeae0000-0xfeafffff irq 16 at device 6.0 on pci1
    Sep 10 01:50:41 kernel: em0: [FILTER]
    Sep 10 01:50:41 kernel: em1: <intel(r) 1000="" pro="" legacy="" network="" connection="" 1.0.6="">port 0xe880-0xe8bf mem 0xfeac0000-0xfeadffff irq 17 at device 6.1 on pci1
    Sep 10 01:50:41 kernel: em1: [FILTER]
    Sep 10 01:50:41 kernel: isab0: <pci-isa bridge="">at device 31.0 on pci0
    Sep 10 01:50:41 kernel: isa0: <isa bus="">on isab0
    Sep 10 01:50:41 kernel: atapci0: <intel ich9m="" sata300="" controller="">port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f,0xd080-0xd08f irq 19 at device 31.2 on pci0
    Sep 10 01:50:41 kernel: atapci0: [ITHREAD]
    Sep 10 01:50:41 kernel: ata2: <ata channel="">at channel 0 on atapci0
    Sep 10 01:50:41 kernel: ata2: [ITHREAD]
    Sep 10 01:50:41 kernel: ata3: <ata channel="">at channel 1 on atapci0
    Sep 10 01:50:41 kernel: ata3: [ITHREAD]
    Sep 10 01:50:41 kernel: pci0: <serial bus,="" smbus="">at device 31.3 (no driver attached)
    Sep 10 01:50:41 kernel: atapci1: <intel ich9m="" sata300="" controller="">port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc40f,0xc080-0xc08f irq 19 at device 31.5 on pci0
    Sep 10 01:50:41 kernel: atapci1: [ITHREAD]
    Sep 10 01:50:41 kernel: ata4: <ata channel="">at channel 0 on atapci1
    Sep 10 01:50:41 kernel: ata4: [ITHREAD]
    Sep 10 01:50:41 kernel: ata5: <ata channel="">at channel 1 on atapci1
    Sep 10 01:50:41 kernel: ata5: [ITHREAD]
    Sep 10 01:50:41 kernel: acpi_button0: <power button="">on acpi0
    Sep 10 01:50:41 kernel: atrtc0: <at realtime="" clock="">port 0x70-0x71 irq 8 on acpi0
    Sep 10 01:50:41 kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
    Sep 10 01:50:41 kernel: uart0: [FILTER]
    Sep 10 01:50:41 kernel: uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
    Sep 10 01:50:41 kernel: uart1: [FILTER]
    Sep 10 01:50:41 kernel: ppc0: <parallel port="">port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0
    Sep 10 01:50:41 kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
    Sep 10 01:50:41 kernel: ppc0: FIFO with 16/16/8 bytes threshold
    Sep 10 01:50:41 kernel: ppc0: [ITHREAD]
    Sep 10 01:50:41 kernel: ppbus0: <parallel port="" bus="">on ppc0
    Sep 10 01:50:41 kernel: plip0: <plip network="" interface="">on ppbus0
    Sep 10 01:50:41 kernel: plip0: [ITHREAD]
    Sep 10 01:50:41 kernel: lpt0: <printer>on ppbus0
    Sep 10 01:50:41 kernel: lpt0: [ITHREAD]
    Sep 10 01:50:41 kernel: lpt0: Interrupt-driven port
    Sep 10 01:50:41 kernel: ppi0: <parallel i="" o="">on ppbus0
    Sep 10 01:50:41 kernel: pmtimer0 on isa0
    Sep 10 01:50:41 kernel: orm0: <isa option="" rom="">at iomem 0xd0000-0xd1fff pnpid ORM0000 on isa0
    Sep 10 01:50:41 kernel: sc0: <system console="">at flags 0x100 on isa0
    Sep 10 01:50:41 kernel: sc0: VGA <16 virtual consoles, flags=0x300>
    Sep 10 01:50:41 kernel: vga0: <generic isa="" vga="">at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
    Sep 10 01:50:41 kernel: ata0: <ata channel="">at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
    Sep 10 01:50:41 kernel: ata0: [ITHREAD]
    Sep 10 01:50:41 kernel: ata1: <ata channel="">at port 0x170-0x177,0x376 irq 15 on isa0
    Sep 10 01:50:41 kernel: ata1: [ITHREAD]
    Sep 10 01:50:41 kernel: atkbdc0: <keyboard controller="" (i8042)="">at port 0x60,0x64 on isa0
    Sep 10 01:50:41 kernel: atkbd0: <at keyboard="">irq 1 on atkbdc0
    Sep 10 01:50:41 kernel: kbd0 at atkbd0
    Sep 10 01:50:41 kernel: atkbd0: [GIANT-LOCKED]
    Sep 10 01:50:41 kernel: atkbd0: [ITHREAD]
    Sep 10 01:50:41 kernel: est0: <enhanced speedstep="" frequency="" control="">on cpu0
    Sep 10 01:50:41 kernel: p4tcc0: <cpu frequency="" thermal="" control="">on cpu0
    Sep 10 01:50:41 kernel: est1: <enhanced speedstep="" frequency="" control="">on cpu1
    Sep 10 01:50:41 kernel: p4tcc1: <cpu frequency="" thermal="" control="">on cpu1
    Sep 10 01:50:41 kernel: Timecounters tick every 1.000 msec
    Sep 10 01:50:41 kernel: IPsec: Initialized Security Association Processing.
    Sep 10 01:50:41 kernel: usbus0: 12Mbps Full Speed USB v1.0</cpu></enhanced></cpu></enhanced></at></keyboard></ata></ata></generic></system></isa></parallel></printer></plip></parallel></parallel></at></power></ata></ata></intel></serial></ata></ata></intel></isa></pci-isa></intel(r)></intel(r)></acpi></acpi></intel></intel></intel></intel></intel></intel></intel></intel></bcm57780></mii></broadcom></acpi></acpi></acpi></acpi></acpi></acpi></multimedia,></intel></intel></intel></intel></intel></intel></intel></intel></vga-compatible></intel></vga-compatible></acpi></acpi></acpi></acpi></software></version>



  • This apinger thing is known, see here (and various other threads):

    https://forum.pfsense.org/index.php?topic=81598.0

    Go to "System" -> "Routing" and select your gateway, try an alternative IP for "monitor IP" and play arround with "Latency threshold" and "Packet Loss threshold"…



  • Thank for reply…I will try that



  • @edinburgh1874:

    Are there any errors under Status -> System Logs -> System -> Resolver ?

    I had the same issue after a brand new installation of 2.1.5 on an Alix 2d3…despite setting DNS entries in General, they would not show up on the dashboard, and I could not resolve any names.

    I noticed that /etc/resolv.conf was missing, I had to change over to RW mode and manually create this file.

    I had this issue with a new install of NanoBSD 2.1.5.  I had a broken link, /etc/resolv.conf, that pointed to nothing.  I had to delete the bad link and create another one pointing to /var/etc/resolv.conf which did exist.  I believe it did work for a matter of minutes then the link became corrupt.  I have not been able to re-create the problem.



  • Hello,

    I think have a similar issue since my last update. I use "DNS Forwarder" and DNS are very strange with randomly error specially on LAN.

    I restored 2.1.3 and no problem. I don't use any package.

    I wait for more information or an update.



  • Im having the same issue on a brand new install of 2.1.5

    Ran for 20 minutes or so today and then clients stopped getting any dns queries resolved. I had to manually enter dns into the clients to get them back online and me out of the hot seat.

    | Oct 2 21:19:43 | dnsmasq[29099]: exiting on receipt of SIGTERM |
    | Oct 2 21:19:44 | dnsmasq[72949]: started, version 2.70 cachesize 10000 |
    | Oct 2 21:19:44 | dnsmasq[72949]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC |
    | Oct 2 21:19:44 | dnsmasq[72949]: reading /etc/resolv.conf |
    | Oct 2 21:19:44 | dnsmasq[72949]: using nameserver 24.113.32.30#53 |
    | Oct 2 21:19:44 | dnsmasq[72949]: using nameserver 8.8.4.4#53 |
    | Oct 2 21:19:44 | dnsmasq[72949]: using nameserver 8.8.8.8#53 |
    | Oct 2 21:19:44 | dnsmasq[72949]: using nameserver 24.113.32.29#53 |
    | Oct 2 21:19:44 | dnsmasq[72949]: read /etc/hosts - 2 addresses |
    | | |



  • Went out to this site today and loaded 2.1.4 onto this box and used the config file generated with the 2.1.5 install.

    DNS forwarder working as it should.

    If I get brave Ill put 2.1.5 back on it and see if I can reproduce the issue.

    Ive got 4 other 2.1.5 boxes working just fine.



  • I too rolled back to 2.1.4 with my 2.1.5 config and everything is working perfectly. Holding off of going back to 2.1.5



  • @chpalmer:

    Went out to this site today and loaded 2.1.4 onto this box and used the config file generated with the 2.1.5 install.
    DNS forwarder working as it should.
    If I get brave Ill put 2.1.5 back on it and see if I can reproduce the issue.

    About 3 weeks ago I got brave and reinstalled 2.1.5 back at this site.  As before any client attempting to use this box for its DNS would not resolve.  I have "log-queries" set on the advanced config of the DNSForwarder setup and can see the queries logged, so I know they are making it to the box. The client machines simply never receive the query answers.  They are however able to query public DNS fine when set to.  2.1.4 works  2.1.5 doesn't.

    This site has a Statically configured WAN.  "Allow DNS server list to be overridden by DHCP/PPP on WAN" unchecked.  "Do not use the DNS Forwarder as a DNS server for the firewall**"** Checked.

    The same week I upgraded to 2.2 beta (latest 3 weeks ago) and found this same issue was also present on 2.2.  This was true of either DNSForwarder or DNSResolver. I tried a new switch and different interfaces (even though they worked with 2.1.4) As I did not want to go back to 2.1.4 I simply turned off both forwarder and resolver and let the DHCP server set the clients up with the DNS from the "General Settings" page.

    This last Tuesday 10/28 I entered my choice of DNS onto the DHCP server page so the server would hand out the public DNS and turned DNSForwarder back on. This would let me troubleshoot some more without disrupting the other users.

    I then proceeded to do an upgrade to the latest snapshot (built on Tue Oct 28 06:51:08 CDT 2014) and now find that the DNSForwarder is working.  No other changes than described above.

    Im still a little reluctant to set the clients back to using the firewall for their DNS but looks like something has changed.

    Anyone else?



  • You can add me to the list of people with issues on 2.1.5 with the dnsmasq process eating 100% of a cpu thread and spotty dns functionality from clients on lan/vlan10/vlan20 dhcp'd interfaces. I have 2 Soekris net6501 boxes here on 2.1.5 -

    I used my spare box to test an upgrade to 2.1.5 awhile back and left it in production with the primary sitting off to the side for a month or so. I then took the primary and put it back into play, ran the upgrade, then imported the backed up config from the backup box. I added 2 vlan interfaces to my lan interface and configured the firewall rules for the new segments and got all of that working as expected. The following morning the issues started up (or I should say users started seeing them).

    At this point if there was some kind of fix in 2.2, I suppose its a debate of rolling back to 2.1.4, waiting for a 2.1.6 (if they release one with a patch for this), taking my chances on 2.2BETA in production, or waiting for 2.2 release.