Captive Portal RADIUS accounting bytes wrong
|Affected version:||2.0||Affected Architecture:|
As discussed here:
ipfw entrystats is returning wrong values, leading RADIUS accounting to have values considerably higher than reality.
#1 Updated by Ermal Luçi over 1 year ago
- Status changed from New to Feedback
This is fixed in latest code
#3 Updated by Yuri Keren about 1 year ago
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.
#5 Updated by Yuri Keren about 1 year ago
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.
#7 Updated by Allan Stanley 12 months ago
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
#9 Updated by Allan Stanley 12 months ago
It appears to be much better now
user at 81MB used
User at 186MB used
User at 295MB
#10 Updated by Alexander Wilke 12 months ago
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!
#11 Updated by Allan Stanley 12 months ago
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.
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!
#14 Updated by Christophe B 10 months ago
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.
[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.
#15 Updated by Allan Stanley 3 months ago
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.
- Status changed from Resolved to New
Recent comments indicate this is still an issue.
#17 Updated by Allan Stanley 29 days ago
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.