Bug #7075


firewall states show negative value for total bytes processed

Added by Bryan Stenson about 6 years ago. Updated almost 6 years ago.

Web Interface
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


As seen in the screenshot, the "Firewall >> Rules >> LAN" page shows a negative number for total bytes processed by a given rule. This is likely an integer overflow, and possibly the cause of something more nefarious...

Let me know what additional data I can provide to track this down.

Here are my details:
2.3.2-RELEASE (i386)
built on Tue Jul 19 13:09:39 CDT 2016
FreeBSD 10.3-RELEASE-p5


Actions #1

Updated by Matt Perry about 6 years ago

I'm also seeing this problem in the latest release.

2.3.2-RELEASE-p1 (i386)
built on Tue Sep 27 12:13:32 CDT 2016
FreeBSD 10.3-RELEASE-p9

Actions #2

Updated by Phillip Davis about 6 years ago

These are both 32-bit installs (i386). So MAXINT will be int(2147483647) (2 gig). The numbers are returned by:
$rulescnt = pfSense_get_pf_rules();

Certainly $rulescnt array entries are going to wrap around at MAXINT. Maybe pfSense_get_pf_rules() on a 32-bit system will already have wrapped the number around anyway, even before trying to stuff them into PHP vars.

i386 is going away, but the SG-1000 is a 32-bit ARM device. I wonder if PHP on that hardware has the same MAXINT, or if does tricky enough stuff to keep track of overflow and effectively manage int up to 64-bit?

Actions #3

Updated by Matt Perry about 6 years ago

This isn't a PHP problem. pfSense_get_pf_rules() is a PHP function written in C as part of php56-pfSense-module. It can be seen at

I'm not much of a C hacker, but maybe it would help if those casts to long were unsigned, or cast to long long.

Actions #4

Updated by Phillip Davis about 6 years ago

Yes, that is true. It depends on what "long" does in the environment in which the C is compiled. When compiled in the 64-bit image maybe it is a 64-bit integer, and maybe add_assoc_long() does the correct thing to transfer a 64-bit binary integer value into a PHP array value.

If it is made longlong in the C, then add_assoc_long() has to work with it (is there an add_assoc_longlong()?) and then what will happen on a 32-bit system that has C support for 64-bit integers (i.e. manipulating them as 2 pieces and sorting out the carries...) but the PHP on that 32-bit system still only supports 32-bit MAXINT. And the underlying pf needs to also use longlong underneath when accumulating the counter...

Actions #5

Updated by Luiz Souza about 6 years ago

  • Assignee set to Luiz Souza
Actions #6

Updated by Luiz Souza about 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

Should be fixed now:

Unfortunately PHP does not have a native 64 bit integer type, there is long and then float/double (not even long long).

Actions #7

Updated by Renato Botelho about 6 years ago

  • Target version set to 2.4.0
Actions #8

Updated by Anonymous almost 6 years ago

Can not duplicate this behavior in 2.4.0.b.20170401.1306, only positive numbers in the States column

Actions #9

Updated by Jim Pingle almost 6 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF