Version 3.0.4 sql groups handling issue

[Arran Cudbard-Bell]

> On 27 Nov 2014, at 12:08, Philippe MARASSE <philippe.marasse at ch-poitiers.fr> wrote:
> 
> Hello,
> 
> I'm upgrading from FR 3.0.0 to 3.0.4, during the tests, I've ran into an issue :
> 
> - My NAS are sorted into 2 different huntgroups
> - My users are members of 2 SQL groups
> - Each SQL group is attached to one huntgroup
> 
> Under v3.0.4 group processing stops when the first group get processed whether huntgroup matches or not.
> 
> I think I've found the culprit line 621 in rlm_sql.c, the continue instruction skips lines 659 & 660 :
>    pairdelete(&request->packet->vps, PW_SQL_GROUP, 0, TAG_ANY);
>    entry = entry->next;
> 
> As far as Fall-Through's default value has changed from 1 in v3.0.0 to FALL_THROUGH_DEFAULT (0), my second group never get processed.
> 
> Another test : I've added Fall-Through = Yes into my radreply table : bang, infinite loop on the first group ! From my log :

Oops, that's not meant to happen.

Your diagnosis is correct, that was the issue. I've fixed the code, and made it a little more efficient.
There's no reason to add/remove SQL-Group on every iteration, we just need to add it once and change its
value.

Also spotted a minor issue where if you'd set Fall-Through in the user's reply items, and had no reply
query for groups, it would have automatically gone on to query for profiles.

Could you check the code in v3.0.x to make sure the infinite loop issue is fixed for you?

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2