Simultaneous-Use CP??

Alan87i

Well I tried the latest version and it didn't seem to work. So I uninstalled downloaded pf config NO package info and RE uploaded it .
Re installed freeraduis2 and set it up again.

Now I can't get a user to log with a mac and shared secret.
This is from the log
Apr 17 15:33:42 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 60612
Apr 17 15:33:42 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 60612
Apr 17 15:33:45 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 60612
Apr 17 15:33:45 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 60612
Apr 17 15:33:52 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 44857
Apr 17 15:33:52 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 44857

1.1. is PF lan IP The router is on DHCP at 1.100

So I reinstalled PF from the disk. and get the same problem.

Nachtfalke

@Alan87i:

Well I tried the latest version and it didn't seem to work. So I uninstalled downloaded pf config NO package info and RE uploaded it .
Re installed freeraduis2 and set it up again.

Now I can't get a user to log with a mac and shared secret.
This is from the log
Apr 17 15:33:42 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 60612
Apr 17 15:33:42 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 60612
Apr 17 15:33:45 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 60612
Apr 17 15:33:45 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 60612
Apr 17 15:33:52 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 44857
Apr 17 15:33:52 radiusd[48787]: Ignoring request to authentication address 192.168.1.1 port 1812 from unknown client 192.168.1.1 port 44857

1.1. is PF lan IP The router is on DHCP at 1.100

So I reinstalled PF from the disk. and get the same problem.

This means you did not enter the pfsense LAN IP as a "NAS" in freeradius and/or wrong shared secret. That's a communication problem between NAS/CP and freeradius.

Alan87i

Thanks I was having a brief stupid moment.
And yes things seem to be working now. I removed the used octets file and saved the user again in radius , that made a new blank used file.
I set 18432MB in radius witch should give me 3 GB.
I read in the guide that cron could be used to reset the daily folder every night.
Is that needed?

I want too run this with all users on a monthly basis. Should a cron job be set up to reset the counter monthly?
BTW
Thanks very much for all the help!!

Nachtfalke

@Alan87i:

Thanks I was having a brief stupid moment.
And yes things seem to be working now. I removed the used octets file and saved the user again in radius , that made a new blank used file.
I set 18432MB in radius witch should give me 3 GB.
I read in the guide that cron could be used to reset the daily folder every night.
Is that needed?

I want too run this with all users on a monthly basis. Should a cron job be set up to reset the counter monthly?
BTW
Thanks very much for all the help!!

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.

To make it a little more clear:
Setting up daily, monthly and so on in the GUI just places the files in different folders.
You have to setup a cron job manually to delete these folders daily, monthly or whatever
After the files were deleted by cron you need to re-run the "squid.xml" file (Users tab). There is a check if a user has set a limit but no files exist in the folder they will be created new ones. If they exist, nothing will be done. (For this behaviour I need to write an additional script or someone provides it for us).

PS: To reset a users counter just edit the user, empty the value for limit, save, edit the user again and setup a new limit. This deletes the old files and creates new ones with new limit.

Thanks for testing :-)

Alan87i

Ok With CP set too Mac format type default and radius user xx:f4:ff format I still get the octets 00X33X what have you file not found.
With CP set too ietf and user 00-99-ff format it counts .
But
The figure of the counting bug using start stop or interm seems to count much faster than 6 times the real rate.

I set the user mac too 18432 MB total daily = 18gb divide by 6 gives 3 GB
The octets file shows this as 19327352832 bytes witch is correct
I test download a 1.4 GB file
I get roughly 732MB about 1/2 of it and I get kicked
Used octets reads 21725770732 bytes witch is roughly 20.2 GB

Nachtfalke

I did some more tests and you are right. :(

The traffic counter is not working as it should. At the moment I am unsure if the CP sends the accounting information according to the RFC and my script is not correct or if it is vice versa. :(

Alan87i

I deleted the two scripts and reinstalled changed format too default ran radiusd -X

Login OK: [00:23:69:fb:79:33] (from client admin port 8 cli 00:23:69:fb:79:33)
# Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default
+- entering group post-auth {...}
cat: /var/log/radacct/datacounter/daily/max-octets-00X23X69XfbX79X33: No such file or directory
cat: /var/log/radacct/datacounter/daily/used-octets-00X23X69XfbX79X33: No such file or directory
Exec-Program output:
Exec-Program: returned: 0
++[exec] returns ok
Sending Access-Accept of id 86 to 192.168.1.1 port 1436
        WISPr-Bandwidth-Max-Up := 262144
        WISPr-Bandwidth-Max-Down := 15360000
        Session-Timeout = 53777840
Finished request 3.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 3 ID 86 with timestamp +48
Ready to process requests.

Alan87i

@Nachtfalke:

I did some more tests and you are right. :(

The traffic counter is not working as it should. At the moment I am unsure if the CP sends the accounting information according to the RFC and my script is not correct or if it is vice versa. :(

Yea I just did another test and got the same result. set radius user for 20 Gb and could not pass 1 GB before it cut the user off.
I'm happy to test any updates or ideas . I would really like to implement this on 2 networks.

Nachtfalke

Hi again,

I took some time to remember what my scripts are doing and I would like to let you know and understand:

To count the traffic we use octets. One octet is one byte. The CP sends Input and Output Octets.

If you set volume limit for a user this limit will be calculated as octets/bytes and written to the file "max-octets-username".
The script runs everytime an interim or stop/start accounting packet arrives. Both packets include information about the input and output octets. the script summates the both values and summates this with the value written in the "used-octets-username" file. After this the script checks if used-octets is greater than max-octets and rejects the connection or still allows it.

The changes below will not summate the values sent from CP with the values in the file but still writes the new values to the file.
But the problem with this is that if a user disconnects and reconnets 2hours later the CP starts to count the octets from zero.

You try to edit the script. Go to:

/usr/local/etc/raddb/scripts/datacounter_acct.sh

Change line 22 from this:

USEDOCTETS=$(($ACCTINPUTOCTETS+$ACCTOUTPUTOCTETS+`cat "/var/log/radacct/datacounter/$TIMERANGE/used-octets-$USERNAME"`))

to

USEDOCTETS=$(($ACCTINPUTOCTETS+$ACCTOUTPUTOCTETS))

This could perhaps help when using stop/start accounting.

For the problem with the username and the" : " try to edit line 4 to this on datacounter_acct.sh

USERNAME=`echo -n "\$1" | sed 's/[^0-9a-zA-Z.:_-]/X/g' `

and datacounter_auth.sh on line 4 to this

USERNAME=`echo -n "\$1" | sed 's/[^0-9a-zA-Z._:-]/X/g' `

Alan87i

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

Alan87i

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

Alan87i

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 .

Nachtfalke

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.

Alan87i

@Nachtfalke:

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>

Nachtfalke

@Alan87i:

(…)
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.

Nachtfalke

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

Alan87i

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.

Alan87i

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
2509741330

I 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 ran

rm /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 .

Nachtfalke

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.

Alan87i

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?