pfSense

Does not seem like the fix is working.

I am running pfSense 2.1 built on April 24 and the reported bytes-in and bytes-out seem to be 6-7 times wrong, for example:

When transfering a 100MB+ file - the RX delta that ifconfig on my client linux machine reports is 153MB, while bytes-out reported by radius are around 1049MB, same value is confirmed using "ipfw table 1 entrystats" command on the pfSense machine.

This has been fixed on latest snapshots.
Please try those.

Thanks, however the captive portal in the latest snapshots doesn't work, I believe there is a bug open about that: 2454
Could please direct me to the revision where it was fixed so I could pull that fix?

I just tested this in the latest snapshot (built Mon Jun 25 16:02:04 EDT 2012) and the problem still doesn't seem to be fixed. The reported bytes seem to still be approximately 6 times higher than they should be.

I have been testing this bug all week.
Below are files sizes downloaded and what CP sent too freeradius2.
5MB download counted 23MB
10MB download counted 49MB
20MB download counted 118MB
50MB download counted 286MB
100MB download counted 570MB
1.1GB download counted 6474MB

It should be fixed on snapshots of 2.0.x and 2.1

It appears to be much better now
From syslog
user at 81MB used
Upload 100MB
User at 186MB used
download 100MB
User at 295MB

Just a note here for other people:
The implementation of volume counter on freeradius2 packages is summarizing the UPLOAD AND DOWNLOAD data.
So downloading an 100MB file will probably result in a counting of 100MB + x because overhead and some uploads (ACK) the client is sending or other services in the background of the OS produce.

Downloading 100MB and uploading 50MB will result in 150MB + some overhead.

Further the accounting is done every minute and the output of the value is based on this. So if a download has finished between two accounting packets the the next recieved accounting value after the download should show the correct amount.

This is just for information - I didn't do any further tests after this patch was commited!

Indeed there is always over head .
When testing from the PF2.1 box through a cheap router then wireless too a laptop I could see random changes in the data speed too the laptop , I imagine this is retries on the wireless side. Thus sometimes a poor connection would count 120 too 150 MB using a 100 MB test file. Where through a lan cable I would notice 5 too 10 MB at the most over head mainly from ack packets.

Another note:
My test system does show more overhead in MB downloading through the Captive portal than it does when I upload the same file through the portal. I think this is normal in my case even on a wire, as I have seen this before where TX and RX speeds when transferring files between the same two computers are not always the same speed.

Seems to be very accurate!!

I can confirm this has been fixed in the 2.1 snapshots. Thank You!

I don't think this has been solved yet. I downloaded "pfSense-LiveCD-2.1-BETA0-i386-20120831-1027.iso.gz" from snapshots.pfsense.org, created a captive portal, logged in with a client and downloaded a 100mb bin file.

Result:

[2.1-BETA0][admin@pfSense.localdomain]/root(30): ipfw table 1 entrystats 192.168.1.163
192.168.1.163/32 0 24296 1285970 1346530232

Clearly, 1285970 bytes = 1255 MB and not ~100MB.

Not it is not fixed it was much better some time ago but recent tests have the same results 700 MB through the portal counts up to well over 2000 MB.

Testing in the 2.0.3 release and it seems to work fine.
I last tested it in 2.1 beta a month or so ago and it over counted.

Be sure to include your architecture (amd64 or i386) when reporting, that can make a difference.

Allan Stanley wrote:

Testing in the 2.0.3 release and it seems to work fine.
I last tested it in 2.1 beta a month or so ago and it over counted.

Edit Sorry
i386 for both. 2.03 and 2.1 beta.

Christophe B wrote:

I don't think this has been solved yet. I downloaded "pfSense-LiveCD-2.1-BETA0-i386-20120831-1027.iso.gz" from snapshots.pfsense.org, created a captive portal, logged in with a client and downloaded a 100mb bin file.

Result:

[2.1-BETA0][admin@pfSense.localdomain]/root(30): ipfw table 1 entrystats 192.168.1.163
192.168.1.163/32 0 24296 1285970 1346530232

Clearly, 1285970 bytes = 1255 MB and not ~100MB.

Two things I would like to note here:

The first one is 1285970 bytes 1255 Kb 1.22 Mb and not 1255 MB.

The second is you should check table 2 instead of table 1. Table 1 will show upload stats and table 2 download stats.

This problem seems to still exist on 2.1.5-RELEASE (amd64). The radius accounting logs say the amount of data used over the past eight hours is 1707 MB. For roughly the same eight hour period, the RRD traffic graph for the CP interface read 4.15 MB in and 12.72 MB out.

Using freeradius2 2.1.12_1/2.2.5_3 pkg v1.6.10

should be accurate on 2.2, I don't recall for sure on 2.1.5.

It seems there is a regression, at least in 2.2 for 32bit.

Radius is reporting 1320 MB while according to BandwidthD (that apparently is working well) only 209 MB have been transferred.

Do you need any log or further evidence?

I can confirm that this behaviour is the same in 2.2.2 for 32bit.

The bug is still here on 2.2.4 release 32bits as well as 64bits, why is this taking so much to resolve ?
Browsed and downloaded barely 3 MB, counted as 24 MB !!