Radius / netflow accounting amount bug (ipfw related)?
TL;DR? There seems to be a bug in pfSense (even the reported RC3 which was said not to have this bug) that prevents any correct accounting. This is not a "fixed" amount, e.g. 6x original values but seems to happen when a specific amount is exceeded, e.g. after 2GB suddenly acctoutputoctets will be more than doubled in size.
I want to log the amount of bytes sent / transfered to and from pfSense on a per-ip basis.
In order to achieve this goal, I set up Captive Portal with interim Accounting updates, allowing me to monitor used bandwidth almost in real time. I've set up FreeRADIUS on a dedicated box, with accounting to a MySQL database enabled.
The weird thing is, accounting actually is very accurate until the bug happens. There only seems to be a 0,5% or so deviation between measured bandwidth usage on the client and the reports in acctoutputoctets and acctinputoctets.
After a while though, something strange happens and the value in acctinputoctets becomes totally unusable, reporting values that are more than the double of the measured amounts.
In order to eliminate some bug in the Captive Portal / FreeRadius setup, I also tried using pfflowd with flow-capture. Using this method also seems to be accurate at first (though be it less accurate than the Radius method) and after a while totally drifting of.
Similar topics I found regarding this issue:
There also seems to be a bug report for a similar, (or the same?) bug mentioned at http://redmine.pfsense.org/issues/1974
Could someone please tell me if the issue I am having is the same as the fore mentioned, and if someone is looking into this problem?
I am willing to do extensive testing in order to find a solution.
Thanks in advance guys :)
In order to rule out all other variables besides pfSense, I just tested with a fresh m0n0wall 1.33 install.
I've downloaded over 6 GB and yet, acctoutputoctets is spot on :)
Hopefully, with this knowledge, it will be easier to spot and fix the bug in pfSense?
m0n0wall isn't even close to the same anymore, so that has no relevance. Haven't had time to dig into it yet, of course people can always change our priorities immediately via commercial support (see link in my sig).