Project

General

Profile

Bug #7075

firewall states show negative value for total bytes processed

Added by Bryan Stenson 4 months ago. Updated 23 days ago.

Status:
Resolved
Priority:
Normal
Category:
Web Interface
Target version:
Start date:
01/03/2017
Due date:
% Done:

100%

Affected version:
2.3.2
Affected Architecture:
i386

Description

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

Screen Shot 2017-01-03 at 9.47.43 AM.png (47.4 KB) Bryan Stenson, 01/03/2017 11:50 AM

History

#1 Updated by Matt Perry 3 months 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

#2 Updated by Phillip Davis 3 months 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 3 months 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 3 months 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...

#5 Updated by Luiz Otavio O Souza 3 months ago

  • Assignee set to Luiz Otavio O Souza

#6 Updated by Luiz Otavio O Souza 3 months ago

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

Should be fixed now: https://github.com/pfsense/FreeBSD-ports/commit/2f5f4b5ac53ead4c12761273a3cc332b08806e26

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

#7 Updated by Renato Botelho 3 months ago

  • Target version set to 2.4.0

#8 Updated by James Dekker 25 days ago

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

#9 Updated by Jim Pingle 23 days ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF