Project

General

Profile

Bug #1974

Captive Portal RADIUS accounting bytes wrong

Added by Chris Buechler about 8 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
Start date:
10/23/2011
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

As discussed here:
http://forum.pfsense.org/index.php/topic,39555.0.html

ipfw entrystats is returning wrong values, leading RADIUS accounting to have values considerably higher than reality.

History

#1 Updated by Ermal Luçi over 7 years ago

  • Status changed from New to Feedback

This is fixed in latest code

#2 Updated by Chris Buechler over 7 years ago

  • Target version set to 2.1

#3 Updated by Yuri Keren over 7 years 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.

#4 Updated by Ermal Luçi over 7 years ago

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

#5 Updated by Yuri Keren over 7 years 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?

#6 Updated by Kevin Trace over 7 years ago

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 over 7 years 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

#8 Updated by Ermal Luçi over 7 years ago

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

#9 Updated by Allan Stanley over 7 years ago

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

#10 Updated by Alexander Wilke over 7 years 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 over 7 years 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.

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!!

#12 Updated by Kevin Trace over 7 years ago

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

#13 Updated by Jim Pingle about 7 years ago

  • Status changed from Feedback to Resolved

#14 Updated by Christophe B about 7 years 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.

Result:

[2.1-BETA0][]/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 over 6 years 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.

#16 Updated by Jim Pingle over 6 years ago

  • Status changed from Resolved to New

Recent comments indicate this is still an issue.

#17 Updated by Allan Stanley over 6 years 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.

#18 Updated by Jim Pingle over 6 years ago

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

#19 Updated by Allan Stanley over 6 years ago

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.

#20 Updated by Renato Botelho over 6 years ago

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][]/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.

#21 Updated by Chris Buechler about 6 years ago

  • Status changed from New to Resolved

Ermal thought this was specific to 32 bit, but it seems to be fine on both 32 and 64 now. A number of test sessions later, all the accounting data is correct.

#22 Updated by Mikael K almost 5 years ago

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

#23 Updated by Chris Buechler almost 5 years ago

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

#24 Updated by Fran Secs over 4 years ago

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?

#25 Updated by Fran Secs over 4 years ago

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

#26 Updated by houari benayada about 4 years ago

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 !!

Also available in: Atom PDF