Simultaneous-Use CP??
-
Ok that seems to fix the : mac address bug for octets file not found.
I noticed one other thing for the back burner,
I'm testing this with a PC WAN too a switch on MY lan 100 Mbps
I have tried several max speeds , but to make things faster I set it for now too 45000 Kbits .
I'm downloading from a PC running an HFS file server. (It will not allow a full 100 MB download ever on the lan )
I cleared the usage total and saved to clean the used octets file and started a download, (forgot too reset the usage limit. ( never changed the speed up/down. )
I noticed it was running up over 1M per second where normally with the limit for usage set it runs at 700/706 KB.Updated the scripts and testing another download will report back later.
Thanks -
Ok those updates seem to work !
I have start/stop set in CP
Mac is with :: in radius and default in cp.
I downloaded a 1.1 gb file and the used octets show 1184268463 = 1.1 GB -
Yes, you must setup a cron job. When I wrote the documentation in the past I forgot to mention that after the cron job deletes "used" and "max" octets files it does not automaticalle recreate the files with the new/resetted values. I need to create a script which recreates the users file and recreates the max-octets file after cron job deleted them.
If you chose "daily", "monthly" or whatever in the GUI places the files in the specific ../datacounter/daily or ../datacounter/monthly folder.
I'm no script writer but could you make a script that would simply delete the used octets file contents every 30 days /24 hours or 7 days ?
That way they would not have to be recreated.
Even better would be the option too back the octet files up too another folder with the date as the folder name. That way some one could manually add them up or use another program to read and chart the usage.
Random thoughts . -
I will think about that but I am no script writer, too. ;)
But I thought about a script that rotates the files or something like this.PS: The changes you made on the script has a side effect:
If you set a limit of 1GB and the user disconnects after 950MB and reconnects then the user has again 1GB traffic. -
I will think about that but I am no script writer, too. ;)
But I thought about a script that rotates the files or something like this.PS: The changes you made on the script has a side effect:
If you set a limit of 1GB and the user disconnects after 950MB and reconnects then the user has again 1GB traffic.Ya that will become a problem. I haven't tested it for the reconnect yet.
Most of the users will be routers or a CPE wireless radio. 1 or 2 will be a PC.
Except for the PC's shutting off at night the routers/radios should stay connected unless the power goes out.
I have also noticed since changing those 3 lines that the syslog no longer reports the client (user) reconnecting every minute although this is still checked in CP.Ok I just set the user limit too below what has already been used.
See the syslog below. Seems disconnecting from radius restarting has had no ill effect. I'm not able too connect. Only the 2 sites I enabled pass through are working.
Apr 19 08:44:56 check_reload_status: Syncing firewall Apr 19 08:44:59 radiusd[2890]: Loaded virtual server <default> Apr 19 08:44:59 radiusd[2964]: Ready to process requests. Apr 19 08:45:01 radiusd[2964]: rlm_radutmp: Logout for NAS admin port 8, but no Login record Apr 19 08:45:01 radiusd[2964]: rlm_radutmp: Logout for NAS admin port 8, but no Login record Apr 19 08:45:02 radiusd[2964]: Login OK: [00:23:69:fb:79:33] (from client admin port 8 cli 00:23:69:fb:79:33) Apr 19 08:45:02 radiusd[2964]: Login OK: [00:23:69:fb:79:33] (from client admin port 8 cli 00:23:69:fb:79:33) Apr 19 08:45:02 root: FreeRADIUS: Credentials are probably correct but the user 00:23:69:fb:79:33 has reached the daily Amount of Upload and Download Traffic which is 2048 MB! The user was rejected!!! Apr 19 08:45:56 radiusd[2964]: Login OK: [00:23:69:fb:79:33] (from client admin port 8 cli 00:23:69:fb:79:33) Apr 19 08:45:56 radiusd[2964]: Login OK: [00:23:69:fb:79:33] (from client admin port 8 cli 00:23:69:fb:79:33) Apr 19 08:45:56 root: FreeRADIUS: Credentials are probably correct but the user 00:23:69:fb:79:33 has reached the daily Amount of Upload and Download Traffic which is 2048 MB! The user was rejected!!! Apr 19 08:46:01 radiusd[2964]: Login OK: [00:23:69:fb:79:33] (from client admin port 10 cli 00:23:69:fb:79:33) Apr 19 08:46:01 radiusd[2964]: Login OK: [00:23:69:fb:79:33] (from client admin port 10 cli 00:23:69:fb:79:33) Apr 19 08:46:02 root: FreeRADIUS: Credentials are probably correct but the user 00:23:69:fb:79:33 has reached the daily Amount of Upload and Download Traffic which is 2048 MB! The user was rejected!!! Apr 19 08:46:07 radiusd[2964]: Login OK: [00:23:69:fb:79:33] (from client admin port 12 cli 00:23:69:fb:79:33) Apr 19 08:46:07 radiusd[2964]: Login OK: [00:23:69:fb:79:33] (from client admin port 12 cli 00:23:69:fb:79:33) Apr 19 08:46:07 root: FreeRADIUS: Credentials are probably correct but the user 00:23:69:fb:79:33 has reached the daily Amount of Upload and Download Traffic which is 2048 MB! The user was rejected!!!</default>
-
(…)
Ya that will become a problem. I haven't tested it for the reconnect yet.
Most of the users will be routers or a CPE wireless radio. 1 or 2 will be a PC.
Except for the PC's shutting off at night the routers/radios should stay connected unless the power goes out.Perhaps it will help that you setup the idle timeout on CP on a high value so that there is no early disconnect. But pay attention on the lease time of DHCP. DHCP lease should be higher than idle/hard timeout because of IP/MAC mismatch check on CP.
-
I did some fixes on the scripts. Further I updated the documentation (how to create a cron job).
In the shell scripts (datacounter_auth.sh and datacounter_acct.sh) I added a line I commented out because this line was just for you in this case. So go and edit the scripts like I describe some posts above after you have installed the newest freeradius package version (1.6.6_3)
More infos here.
http://forum.pfsense.org/index.php/topic,43675.msg256682.html#msg256682 -
I updated and re=added the patches (3 lines ) .
Then I installed cron package and played with that. Tried the daily reset from the wiki.
I set up a few downloads and quit for the night.
It seems that after installing the cron package CP stopped authing every minute, As in the sys log this morning there was nothing listed since last night (package started cron)Also the command for the daily reset didn't remove the count from the used octets files. Note I have one used octet file still with - - not : and it was set too 0 I have two with : and they were the same as when I checked last night. A mix of installing cron maybe Since they did not update all night.
I just rebooted PF and will check later. For now syslog reports as normal with CP re authing every minute.One other thing I noted was after rebooting PF a laptop user had the octets file reset! But another user where a linksys router MAC is the user did not reset. I think this is because The router did not have time to notice and request an IP, where the laptop did. So I wonder if setting the leases to static would not help.
As soon as the system rebooted CP status showed the laptop as connected and the router was not in the list. -
Ok I found a different bug with the latest version. And the 3 lines patched like you said.
The used counter seems to add fine for a while then resets it's self too a lower number.Copied these while downloading over 2 GB from my server.
2515282576
2345490533
2657888437
1304058479
2509741330I ran this from the command prompt
/bin/rm /var/log/radacct/datacounter/daily/used-octets-*
The first time when I checked the used octets files were gone .
Then I refreshed a page on both user PC's and they returned but both still had the same numebr or bytes in the file.
So I ranrm /var/log/radacct/datacounter/daily/used-octets-*
That took them out and a refresh did not bring them back. So I resaved the 2 users in radius and they were back Both still showing the same amount of bytes , not a 0 .
-
That's not a bug of the script - that's the sideffect of the CP accounting "problem".
The octets increase - CP continuosliy increases the octets if the users is downloading somthing. this value will be added to the used-octets-file.
If you reset the counter (used-octets-*) this does not reset the information of the used octets the CP has. For this you would need to disconnect the user from CP /Status -> Captive Portal -> Disconnect) or restart the CP.If you reset the used-octets file to a value of zero and you did not restart the CP it will write the used-octets to the file that CP knows from before.
We will not find a clean solution for that until CP is resetting the countet octets between every stop/start accounting packet. I am sorry to say that but we need to hope that this is fixed on pfsense 2.1.
-
Bummer
Any word on when that might happen?
Is your radius2 package running on 2.1?Do you know if I can accomplish what I want too do with M0nowall?
-
Bummer
Any word on when that might happen?
Is your radius2 package running on 2.1?Do you know if I can accomplish what I want too do with M0nowall?
They want to release pfsense 2.1 on world IPv6 day - someone in june as far as I know.
For pfsense 2.1 all freeradius2 binaries needs to be recompiled and .pbi packages needs to be build. The compilation of the binaries did another forum user for me who has more knowledge about that.I didin't ask him about that till now because he seems to be very busy if I follow his other posts.
Monowall:
You can try the CP of monowall with freeradius2 package. perhaps it will do accurate accounting but I don't know.