firewall states show negative value for total bytes processed
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:
built on Tue Jul 19 13:09:39 CDT 2016
#2 Updated by Phillip Davis about 1 year 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?
#3 Updated by Matt Perry about 1 year 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 https://github.com/pfsense/FreeBSD-ports/blob/devel/devel/php56-pfSense-module/files/pfSense.c#L3012-L3050
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.
#4 Updated by Phillip Davis about 1 year 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...
#6 Updated by Luiz Souza about 1 year ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Unfortunately PHP does not have a native 64 bit integer type, there is long and then float/double (not even long long).