Logs full of: pfr_update_stats: assertion failed.



  • Hi all, i have a Pfsense system which is running since around 2014 and have been always update. A lot of time ago (i guess since some 2.2 or 2.2.x update) i started getting the logs full of this:

    pfr_update_stats: assertion failed. 
    

    It happens randomly, sometimes many times in a minute, sometimes it doesn't show for five minutes. I googled around for all this time hoping to find someone with the same problem or seeing it magically fixed by some version upgrade  ;D

    The only extension i have installed are nmap, arping and openvpn client export. I heard many had this problem with PFblockerNG but i never installed it so this isn't the case.

    Anyone else of you had the same problem and solved it succesfuly?

    Thank you in advance !



  • Unfortunately this is a "me too" post rather than a fix, but i'm also seeing this on a freshly built system. Unlike the previous reports of this error, I don't have pfBlockerNG installed. I manually checked the raw pf rules in /tmp/rules.debug and the only rules that had a mention of 127.0.0.1 in them (this seemed to be the cause of the pfBlockerNG related errors) are default rules for NAT and blocking private address ranges on the WAN interface.

    This is on a freshly installed and fully up to date 2.3.2-RELEASE-p1 (amd64) install, running on a Shuttle DS68U with an Intel(R) Celeron(R) CPU 3855U @ 1.60GHz.



  • Hi,
    I have the same problem:

    
    Aug 25 15:04:12	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:51:13	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:45:54	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:37:32	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:32:15	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:32:04	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:31:52	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:22:45	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:22:45	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:22:23	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:22:23	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:21:37	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:10:19	kernel		pfr_update_stats: assertion failed.
    Aug 25 14:07:55	kernel		pfr_update_stats: assertion failed.
    Aug 25 13:50:40	kernel		pfr_update_stats: assertion failed.
    
    

    PfSense 2.3.4-RELEASE-p1 (amd64) installed on HDD, the only package that is installed is FTP_Client_Proxy.
    It is a Dell PowerEdge R310 with these network adapters:
    2 embedded Broadcom NetXtreme II Gigabit Ethernet (firmware 08.07.26)
    Intel(R) Gigabit ET Quad Port Server Adapter

    The problem started with the update from 2.1.5 to 2.3.4_1 (via 2.3.4).
    The day before I updated the Broadcom firmware to the latest version by Dell, but I did not see this error until I updated pfsense.

    This was the secondary firewall of an HA firewall pair with pfsense 2.1.5 amd64 full install with package pfflowd.
    Not complex configuration, but we have many rules.
    We have 13 interfaces and an interface group, we use carp, pfsync, xmlrpc sync, vpn: more than 60 openvpn and 10 ipsec, lag, vlan, dhcp server, dns forwarder, ntp…

    I have 2 LAG (whith LACP): igb0,igb1 and igb2,igb3.
    One LAG is assigned to an interface, the other has some VLANs.
    One Broadcom is directly connected to the other firewall (sync).

    The primary firewall has carp disabled,
    I have disabled pfsync and xmlrpc sync in both firewall and I have tried to shutdown the primary firewall.
    I tried to disable the only floating rule that we have (deny rule).
    I have backupped the config and done a fresh install of pfsense 2.3.4, upgraded to 2.3.4_1 and imported the config, but The problem persists.

    EDIT: I started again primary firewall with 2.1.5 (with same Dell firmware updates of secondary firewall), it worked fine for serveral hours and the secondary firewall with 2.3.4_1 didn't log errors anymore,
    ok it was in backup state, so no virtual ip, no vpn and no one used it as a gateway, but it received broadcast traffic, traffic directed to its ips and dhcp server has continued working.
    When I turned off carp on the 2.1.5 firewall, the 2.3.4 came back primary and after few minutes the error appeared again.

    Any suggestion to fix this issue?
    Thanks in advance,
    Gianluca.