Max length of SQl return string?
Hello, We are doing a query which are supposed to comeback with a bunch of subscriber accounts. update request { Subscriber-Accounts := "%{sql-cisco-bng:SELECT GROUP_CONCAT(username SEPARATOR ';') FROM radcheck WHERE username LIKE '%{User-Name}%%'}" } But it seems that there is a limit on how long the return string can be? In this case a query for acccount for user "10.33.2.3_GigabitEthernet0/0/2" did return below accounts but the return query cuts off after a while. (And yes port 1 and port 2 also gets account for 10-19 and 20-22 which is why we noticed this bugg/feature..?) 10.33.2.3_GigabitEthernet0/0/21 10.33.2.3_GigabitEthernet0/0/20 CH_VoIP 10.33.2.3_GigabitEthernet0/0/20 CH_IPTV 10.33.2.3_GigabitEthernet0/0/20 10.33.2.3_GigabitEthernet0/0/2 KAL_IPTV 10.33.2.3_GigabitEthernet0/0/20 KAL_IPTV 10.33.2.3_GigabitEthernet0/0/2 Here is from the debug where one can see where it gets cut off rlm_perl: sub-pre-auth: Debug: RAD_REQUEST in sub authorize: Subscriber-Accounts = 10.33.2.3_GigabitEthernet0/0/21;10.33.2.3_GigabitEthernet0/0/20 CH_VoIP;10.33.2.3_GigabitEthernet0/0/20 CH_IPTV;10.33.2.3_GigabitEthernet0/0/20;10.33.2.3_GigabitEthernet0/0/2 KAL_IPTV;10.33.2.3_GigabitEthernet0/0/20 KAL_IPTV;10.33.2.3_GigabitEth And and after splitted rlm_perl: sub-pre-auth: i = 0, SQL Found Account[0]: 10.33.2.3_GigabitEthernet0/0/21 rlm_perl: sub-pre-auth: i = 1, SQL Found Account[1]: 10.33.2.3_GigabitEthernet0/0/20 CH_VoIP rlm_perl: sub-pre-auth: i = 2, SQL Found Account[2]: 10.33.2.3_GigabitEthernet0/0/20 CH_IPTV rlm_perl: sub-pre-auth: i = 3, SQL Found Account[3]: 10.33.2.3_GigabitEthernet0/0/20 rlm_perl: sub-pre-auth: i = 4, SQL Found Account[4]: 10.33.2.3_GigabitEthernet0/0/2 KALEJDO_IPTV rlm_perl: sub-pre-auth: i = 5, SQL Found Account[5]: 10.33.2.3_GigabitEthernet0/0/20 KALEJDO_IPTV rlm_perl: sub-pre-auth: i = 6, SQL Found Account[6]: 10.33.2.3_GigabitEth So my question is if there is a limitation can i change it somewhere and why is there one in the first place? We temporary fixed it by a better matched SQL query which doesnt give us accounts we are not asking for.. Subscriber-Accounts := "%{sql-cisco-bng:SELECT GROUP_CONCAT(username SEPARATOR ';') AS FOO_RID FROM radcheck WHERE username LIKE '%{User-Name} %' OR username = '%{User-Name}'}" but it is still going to give us problems in the future since users can have more than above exemples of accounts. Thanks for your time. Alex ********* DISCLAIMER ********* This message and any attachment are confidential and may be privileged or otherwise protected from disclosure and may include proprietary information. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person
On 28/11/13 14:41, Alexander Silveröhrt wrote:
Hello,
We are doing a query which are supposed to comeback with a bunch of subscriber accounts.
update request { Subscriber-Accounts := "%{sql-cisco-bng:SELECT GROUP_CONCAT(username SEPARATOR ';') FROM radcheck WHERE username LIKE '%{User-Name}%%'}" }
But it seems that there is a limit on how long the return string can be?
Well, it's a radius attribute, so it's probably 253 bytes. Not sure if this limit is changed/removed in later versions of the server (e.g. for attributes which are internal, since they never go on the wire there's no protocol reason to limit their length)
On 28 Nov 2013, at 14:54, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/11/13 14:41, Alexander Silveröhrt wrote:
Hello,
We are doing a query which are supposed to comeback with a bunch of subscriber accounts.
update request { Subscriber-Accounts := "%{sql-cisco-bng:SELECT GROUP_CONCAT(username SEPARATOR ';') FROM radcheck WHERE username LIKE '%{User-Name}%%'}" }
But it seems that there is a limit on how long the return string can be?
Well, it's a radius attribute, so it's probably 253 bytes.
Not sure if this limit is changed/removed in later versions of the server (e.g. for attributes which are internal, since they never go on the wire there's no protocol reason to limit their length)
It's... better. But there are many places static buffers are still used. The VP themselves now have a char pointer in the union, which points to a chunk of talloced memory in the VP context. However, the xlat functions still need to be updated to do dynamic allocation, the limit is probably around 1000bytes. break on rlm_sql.c:144, p freespace and see :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Thx for the update on this. I guess the only way is to make a workaround like checking if the string is >250 chars and if it is then instatiate a DBI call from the perl hook instead that retrieves all the accounts. Hopefully that will no be that many cases. Its just that i wanted to move away from the DBI inside the hooks bc it takes far to long for the script to execute no matter caching variables across threads or not as Alan recommended a while back. Thank you again for the answers. best regards Alex ________________________________________ Från: freeradius-users-bounces+alexander.silverohrt=itux.se@lists.freeradius.org [freeradius-users-bounces+alexander.silverohrt=itux.se@lists.freeradius.org] för Arran Cudbard-Bell [a.cudbardb@freeradius.org] Skickat: den 28 november 2013 16:24 Till: FreeRadius users mailing list Ämne: Re: Max length of SQl return string? On 28 Nov 2013, at 14:54, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/11/13 14:41, Alexander Silveröhrt wrote:
Hello,
We are doing a query which are supposed to comeback with a bunch of subscriber accounts.
update request { Subscriber-Accounts := "%{sql-cisco-bng:SELECT GROUP_CONCAT(username SEPARATOR ';') FROM radcheck WHERE username LIKE '%{User-Name}%%'}" }
But it seems that there is a limit on how long the return string can be?
Well, it's a radius attribute, so it's probably 253 bytes.
Not sure if this limit is changed/removed in later versions of the server (e.g. for attributes which are internal, since they never go on the wire there's no protocol reason to limit their length)
It's... better. But there are many places static buffers are still used. The VP themselves now have a char pointer in the union, which points to a chunk of talloced memory in the VP context. However, the xlat functions still need to be updated to do dynamic allocation, the limit is probably around 1000bytes. break on rlm_sql.c:144, p freespace and see :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ********* DISCLAIMER ********* This message and any attachment are confidential and may be privileged or otherwise protected from disclosure and may include proprietary information. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person
participants (3)
-
Alexander Silveröhrt -
Arran Cudbard-Bell -
Phil Mayers