Hi: I am testing 802.1x accounting under fr 3.0.8. steps below: 1. use my notebook to login AP. accounting begin. 2. poweroff/poweron the AP. AP send "Accounting on". and previous accounting log closed with "NAS-Reboot".that's good. 3. use my notebook to login AP. fr can not create a new accounting entry, it seems "Acct-Session-Id" will be reused and cause "acctuniqueid" duplicate. error message like below: (11) sql: rlm_sql_mysql: ERROR 1062 (Duplicate entry 'e8db0ea9accf3a44b835ff8a0e5b62c0' for key 'acctuniqueid'): 23000 (11) sql: SQL query returned: need alt query (11) sql: Trying next query... (11) sql: EXPAND UPDATE radacct SET acctstarttime = FROM_UNIXTIME(%{integer:Event-Timestamp})................... then fr will try to update an existing entry instead of log a new entry. is the behavior expected? how can I setup to prevent it? thanks a lot for help! Regards, tbskyd
On 4 Jun 2015, at 05:02, d tbsky <tbskyd@gmail.com> wrote:
Hi: I am testing 802.1x accounting under fr 3.0.8. steps below:
1. use my notebook to login AP. accounting begin. 2. poweroff/poweron the AP. AP send "Accounting on". and previous accounting log closed with "NAS-Reboot".that's good. 3. use my notebook to login AP. fr can not create a new accounting entry, it seems "Acct-Session-Id" will be reused and cause "acctuniqueid" duplicate. error message like below:
(11) sql: rlm_sql_mysql: ERROR 1062 (Duplicate entry 'e8db0ea9accf3a44b835ff8a0e5b62c0' for key 'acctuniqueid'): 23000 (11) sql: SQL query returned: need alt query (11) sql: Trying next query... (11) sql: EXPAND UPDATE radacct SET acctstarttime = FROM_UNIXTIME(%{integer:Event-Timestamp})...................
then fr will try to update an existing entry instead of log a new entry.
is the behavior expected? how can I setup to prevent it?
FreeRADIUS is behaving as expected. But you've got insufficient attributes in your acct_unique_id policy to ensure the value is unique. One trick you can do is send back a class attribute with a random value on authentication, and then use that as part of the acct_unique_id. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi: 2015-06-04 21:06 GMT+08:00 Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
FreeRADIUS is behaving as expected. But you've got insufficient attributes in your acct_unique_id policy to ensure the value is unique.
One trick you can do is send back a class attribute with a random value on authentication, and then use that as part of the acct_unique_id.
-Arran
after some trying and testing, now I add "%l" to the last acct-unique-id, so it becomes: &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{N AS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port},%l}" I think the AP won't finish poweroff/poweron/authenticate in one second, so it should be safe. after testing it is working. do you think it is ok to use it? Regards, tbskyd
On Jun 9, 2015, at 1:33 AM, d tbsky <tbskyd@gmail.com> wrote:
after some trying and testing, now I add "%l" to the last acct-unique-id, so it becomes:
Don't do that. That means the Acct-Unique-Id depends on the time the packet was received, which means it's always different. The intention behind the attribute was to identify a user's session. Therefore, it is calculated from attributes which identify the user session. Like NAS-IP-Address, NAS-Port, etc. Alan DeKok.
Hi: 2015-06-09 20:32 GMT+08:00 Alan DeKok <aland@deployingradius.com>:
On Jun 9, 2015, at 1:33 AM, d tbsky <tbskyd@gmail.com> wrote:
after some trying and testing, now I add "%l" to the last acct-unique-id, so it becomes:
Don't do that. That means the Acct-Unique-Id depends on the time the packet was received, which means it's always different.
The intention behind the attribute was to identify a user's session. Therefore, it is calculated from attributes which identify the user session. Like NAS-IP-Address, NAS-Port, etc.
Alan DeKok.
you are right. the Acct-Unique-Id will change for every accounting request. but in current freeradius "queries.conf" design, it seems works fine. because in "queries.conf", "Acct-Unique-Session-Id" is only used when creating new record. when freeradius need to update existing record, it only use "acctsessionid + username + nasipaddress", but not "acctuniqid". I don't know why freeradius create the id for every accounting request but only use it once. since it is only used once so my setting works. although I don't know this is a good thing or bad thing... Regards, tbskyd
Hi: 2015-06-10 13:07 GMT+08:00 d tbsky <tbskyd@gmail.com>:
Hi:
2015-06-09 20:32 GMT+08:00 Alan DeKok <aland@deployingradius.com>:
On Jun 9, 2015, at 1:33 AM, d tbsky <tbskyd@gmail.com> wrote:
after some trying and testing, now I add "%l" to the last acct-unique-id, so it becomes:
Don't do that. That means the Acct-Unique-Id depends on the time the packet was received, which means it's always different.
The intention behind the attribute was to identify a user's session. Therefore, it is calculated from attributes which identify the user session. Like NAS-IP-Address, NAS-Port, etc.
Alan DeKok.
you are right. the Acct-Unique-Id will change for every accounting request. but in current freeradius "queries.conf" design, it seems works fine. because in "queries.conf", "Acct-Unique-Session-Id" is only used when creating new record. when freeradius need to update existing record, it only use "acctsessionid + username + nasipaddress", but not "acctuniqid". I don't know why freeradius create the id for every accounting request but only use it once. since it is only used once so my setting works. although I don't know this is a good thing or bad thing...
Regards, tbskyd
after checking the detail of "queries.conf". I found it is actually a bad thing. when updating it really only use "acctsessionid + username + nasipaddress" to locate existing record without other constraint. so in my case, even I create a unique 'acctuniqid', all the existing records with the same "acctsessionid" will be updated at once. maybe the whole update process in queries.conf should be modified to use "acctuniqid" when locate existing record?
On Jun 10, 2015, at 1:21 AM, d tbsky <tbskyd@gmail.com> wrote:
after checking the detail of "queries.conf". I found it is actually a bad thing. when updating it really only use "acctsessionid + username + nasipaddress" to locate existing record without other constraint. so in my case, even I create a unique 'acctuniqid', all the existing records with the same "acctsessionid" will be updated at once. maybe the whole update process in queries.conf should be modified to use "acctuniqid" when locate existing record?
Hmm... in v3.0.x in git, the queries do use Acct-Unique-Session-Id. Which version are you using? Which queries don't use Acct-Unique-Session-Id? Alan DeKok.
Hi: 2015-06-10 21:51 GMT+08:00 Alan DeKok <aland@deployingradius.com>:
On Jun 10, 2015, at 1:21 AM, d tbsky <tbskyd@gmail.com> wrote:
after checking the detail of "queries.conf". I found it is actually a bad thing. when updating it really only use "acctsessionid + username + nasipaddress" to locate existing record without other constraint. so in my case, even I create a unique 'acctuniqid', all the existing records with the same "acctsessionid" will be updated at once. maybe the whole update process in queries.conf should be modified to use "acctuniqid" when locate existing record?
Hmm... in v3.0.x in git, the queries do use Acct-Unique-Session-Id.
Which version are you using? Which queries don't use Acct-Unique-Session-Id?
Alan DeKok.
I am using fr 3.0.8 and my queries.conf comes from 3.0.x git. i am using mysql, the queries.conf is at /etc/raddb/mods-config/sql/main/mysql/queries.conf all the update queries don't use Acct-Unique-Session-Id. it only use acctsessionid like below: interim-update { # # Update an existing session and calculate the interval # between the last data we received for the session and this # update. This can be used to find stale sessions. # query = "\ UPDATE ${....acct_table1} \ SET \ acctupdatetime = (@acctupdatetime_old:=acctupdatetime), \ acctupdatetime = FROM_UNIXTIME(\ %{integer:Event-Timestamp}), \ acctinterval = %{integer:Event-Timestamp} - \ UNIX_TIMESTAMP(@acctupdatetime_old), \ framedipaddress = '%{Framed-IP-Address}', \ acctsessiontime = '%{Acct-Session-Time}', \ acctinputoctets = '%{%{Acct-Input-Gigawords}:-0}' \ << 32 | '%{%{Acct-Input-Octets}:-0}', \ acctoutputoctets = '%{%{Acct-Output-Gigawords}:-0}' \ << 32 | '%{%{Acct-Output-Octets}:-0}' \ WHERE acctsessionid = '%{Acct-Session-Id}' \ AND username = '%{SQL-User-Name}' \ AND nasipaddress = '%{NAS-IP-Address}'"
On Jun 10, 2015, at 10:34 AM, d tbsky <tbskyd@gmail.com> wrote:
Hi:
2015-06-10 21:51 GMT+08:00 Alan DeKok <aland@deployingradius.com>:
On Jun 10, 2015, at 1:21 AM, d tbsky <tbskyd@gmail.com> wrote:
after checking the detail of "queries.conf". I found it is actually a bad thing. when updating it really only use "acctsessionid + username + nasipaddress" to locate existing record without other constraint. so in my case, even I create a unique 'acctuniqid', all the existing records with the same "acctsessionid" will be updated at once. maybe the whole update process in queries.conf should be modified to use "acctuniqid" when locate existing record?
Hmm... in v3.0.x in git, the queries do use Acct-Unique-Session-Id.
Which version are you using? Which queries don't use Acct-Unique-Session-Id?
Alan DeKok.
I am using fr 3.0.8 and my queries.conf comes from 3.0.x git. i am using mysql, the queries.conf is at /etc/raddb/mods-config/sql/main/mysql/queries.conf all the update queries don't use Acct-Unique-Session-Id. it only use acctsessionid like below:
interim-update { # # Update an existing session and calculate the interval # between the last data we received for the session and this # update. This can be used to find stale sessions. # query = "\ UPDATE ${....acct_table1} \ SET \ acctupdatetime = (@acctupdatetime_old:=acctupdatetime), \ acctupdatetime = FROM_UNIXTIME(\ %{integer:Event-Timestamp}), \ acctinterval = %{integer:Event-Timestamp} - \
UNIX_TIMESTAMP(@acctupdatetime_old), \ framedipaddress = '%{Framed-IP-Address}', \ acctsessiontime = '%{Acct-Session-Time}', \ acctinputoctets = '%{%{Acct-Input-Gigawords}:-0}' \ << 32 | '%{%{Acct-Input-Octets}:-0}', \ acctoutputoctets = '%{%{Acct-Output-Gigawords}:-0}' \ << 32 | '%{%{Acct-Output-Octets}:-0}' \ WHERE acctsessionid = '%{Acct-Session-Id}' \ AND username = '%{SQL-User-Name}' \ AND nasipaddress = '%{NAS-IP-Address}'"
I'll go fix that. Might have only been for PG we did the fixes. -Arran
Hi Alan and Arran: 2015-06-10 22:49 GMT+08:00 Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
I'll go fix that. Might have only been for PG we did the fixes.
-Arran
I use the new queries.conf from github, and enable "insert_acct_class" at default virtual server. it works fine. now I have unique acctuniqueid, and sql update is correct. thanks again for your kindly help!! Regards, tbskyd
On Jun 4, 2015, at 7:02 AM, d tbsky <tbskyd@gmail.com> wrote:
3. use my notebook to login AP. fr can not create a new accounting entry, it seems "Acct-Session-Id" will be reused
Your AP is broken. Throw it in the garbage, and buy one that follows the RADIUS standards. RFC 2866 Section 5.5 says that the Acct-Session-Id is unique to each session. We recognize that that some vendors get it slightly wrong, which is why we create the "unique" session ID. An AP vendor using the *same* Acct-Session-Id for all sessions isn't a bug. It's incompetence. It's from someone who cares so little about the standards and their customers, that they will ship you a steaming pile of garbage, then take you money, and run.
is the behavior expected? how can I setup to prevent it?
Buy an AP that isn't garbage. No amount of poking FreeRADIUS will make the AP follow the RADIUS standards. Alan DeKok.
Hi Alan: 2015-06-04 21:17 GMT+08:00 Alan DeKok <aland@deployingradius.com>:
On Jun 4, 2015, at 7:02 AM, d tbsky <tbskyd@gmail.com> wrote:
3. use my notebook to login AP. fr can not create a new accounting entry, it seems "Acct-Session-Id" will be reused
Your AP is broken. Throw it in the garbage, and buy one that follows the RADIUS standards. RFC 2866 Section 5.5 says that the Acct-Session-Id is unique to each session.
my test AP is running openwrt + hostpad. I think the Acct-Session-Id is unique for every live session. but after reboot the Acct-Session-Id will be re-used again. I check RFC 2866, but it didn't say Acct-Session-id should be unique after reboot. but maybe the AP should make it unique for every session ever connected? I am confused about this.. Regards, tbskyd
Hi Alan: 2015-06-05 0:47 GMT+08:00 d tbsky <tbskyd@gmail.com>:
Hi Alan:
2015-06-04 21:17 GMT+08:00 Alan DeKok <aland@deployingradius.com>:
On Jun 4, 2015, at 7:02 AM, d tbsky <tbskyd@gmail.com> wrote:
3. use my notebook to login AP. fr can not create a new accounting entry, it seems "Acct-Session-Id" will be reused
Your AP is broken. Throw it in the garbage, and buy one that follows the RADIUS standards. RFC 2866 Section 5.5 says that the Acct-Session-Id is unique to each session.
my test AP is running openwrt + hostpad. I think the Acct-Session-Id is unique for every live session. but after reboot the Acct-Session-Id will be re-used again. I check RFC 2866, but it didn't say Acct-Session-id should be unique after reboot. but maybe the AP should make it unique for every session ever connected? I am confused about this..
just find out the latest hostapd 2.4 changelog (https://w1.fi/cgit/hostap/plain/hostapd/ChangeLog): fixed Accounting-Request to not include duplicated Acct-Session-Id so I think the AP should really keep the Acct-Session-Id unique even after reboot? and maybe I can keep the AP now. open source rocks!! Regards, tbskyd
2015-06-05 0:59 GMT+08:00 d tbsky <tbskyd@gmail.com>:
Hi Alan:
2015-06-05 0:47 GMT+08:00 d tbsky <tbskyd@gmail.com>:
Hi Alan:
2015-06-04 21:17 GMT+08:00 Alan DeKok <aland@deployingradius.com>:
On Jun 4, 2015, at 7:02 AM, d tbsky <tbskyd@gmail.com> wrote:
3. use my notebook to login AP. fr can not create a new accounting entry, it seems "Acct-Session-Id" will be reused
Your AP is broken. Throw it in the garbage, and buy one that follows the RADIUS standards. RFC 2866 Section 5.5 says that the Acct-Session-Id is unique to each session.
my test AP is running openwrt + hostpad. I think the Acct-Session-Id is unique for every live session. but after reboot the Acct-Session-Id will be re-used again. I check RFC 2866, but it didn't say Acct-Session-id should be unique after reboot. but maybe the AP should make it unique for every session ever connected? I am confused about this..
just find out the latest hostapd 2.4 changelog (https://w1.fi/cgit/hostap/plain/hostapd/ChangeLog):
fixed Accounting-Request to not include duplicated Acct-Session-Id
No.. check the detail of the commit (http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=aff039fada2f10b095631...) the fix is not related to unique Acct-Session-Id.. so still confused about if the id should be unique after reboot..
On Jun 4, 2015, at 12:47 PM, d tbsky <tbskyd@gmail.com> wrote:
my test AP is running openwrt + hostpad. I
Ah. OpenWRT is running on hardware which doesn't have a clock. hostapd depends on the clock to generate Acct-Session-Id. I'll poke them with a patch.
think the Acct-Session-Id is unique for every live session. but after reboot the Acct-Session-Id will be re-used again.
It's not supposed to be re-used again. Ever,
I check RFC 2866, but it didn't say Acct-Session-id should be unique after reboot. but maybe the AP should make it unique for every session ever connected? I am confused about this..
The AP should make it unique. Alan DeKok.
Hi Alan: 2015-06-05 6:32 GMT+08:00 Alan DeKok <aland@deployingradius.com>:
On Jun 4, 2015, at 12:47 PM, d tbsky <tbskyd@gmail.com> wrote:
my test AP is running openwrt + hostpad. I
Ah. OpenWRT is running on hardware which doesn't have a clock. hostapd depends on the clock to generate Acct-Session-Id.
I'll poke them with a patch.
think the Acct-Session-Id is unique for every live session. but after reboot the Acct-Session-Id will be re-used again.
It's not supposed to be re-used again. Ever,
ok. I learn a lot from the email list. really thanks for your time and patience. Regards, tbskyd
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
d tbsky