possible bug in rlm_preprocess parsing of huntgroups?

[Christopher Carver]

The scenario is complicated.  I will try to keep this as short and 
simple as possible.  We are experiencing odd and different behavior when 
we modify just the order of the huntgroups being built in 
raddb/huntgroups.  Nothing else is changed, just the ordering.  FreeBSD 
5.3-RELEASE w/ Freeradius-1.0.5.

We authenticate dialup users.  In our users file we want to pass back to 
the NAS a specific ip pool if the customer's Calling-Station-Id is a 
certain set of area codes and exchanges.  However, we want to have 
exceptions to this.  So, we have a huntgroup called "migration" for the 
set of Calling-Station-Id area codes and exchanges and an "exceptions" 
huntgroup that has the Calling-Station-Id values of people who will not 
get the ip pool even though they are part of the set defined under 
"migration".

raddb/huntgroups (note the ordering, migration THEN exceptions):

migration       Calling-Station-Id =~ "^304729"
migration       Calling-Station-Id =~ "^304297"

exceptions      Calling-Station-Id =~ "3047291185"
exceptions      Calling-Station-Id =~ "3047299137"
exceptions      Calling-Station-Id =~ "3042972446"

raddb/users (note the use of fall-through to keep exceptions matches 
from getting the ip pool):

DEFAULT Autz-Type := NoTollfree, Simultaneous-Use := 1, Session-Type := 
dialup
        Port-Limit = 1,
        Idle-Timeout = 1800,
        Framed-Protocol = PPP,
        Service-Type = Framed-User,
        Fall-Through = yes

DEFAULT Huntgroup-Name == exceptions
        Fall-Through = no

DEFAULT Huntgroup-Name == migration
        cisco-avpair = "ip:addr-pool=migration",

Now we test with an authentication request packet in a file and 
radclient.  Here is the contents of the file and output when testing 
with radclient:

# auth request packet
User-Name = test
Password = test
Calling-Station-Id = 3047291185

# radiusd reply packet
        Idle-Timeout = 1800
        Framed-Protocol = PPP
        Service-Type = Framed-User
        Cisco-AVPair = "ip:addr-pool=migration"
        Port-Limit = 2

It obviously didn't match the exceptions huntgroup in the huntgroups 
file because 3047291185 is clearly a member of that huntgroup.  radiusd 
-x verifies it did not.  Now watch what happens when we do nothing but 
reverse the order of the huntgroups and restart radiusd.  The users file 
and authentication request packet will both remain exactly the same.  
Here's the new raddb/huntgroups file:

exceptions      Calling-Station-Id =~ "3047291185"
exceptions      Calling-Station-Id =~ "3047299137"
exceptions      Calling-Station-Id =~ "3042972446"

migration       Calling-Station-Id =~ "^304729"
migration       Calling-Station-Id =~ "^304297"

Now the new output after testing with radclient (keeping the auth packet 
and users file exactly the same):

        Idle-Timeout = 1800
        Framed-Protocol = PPP
        Service-Type = Framed-User
        Port-Limit = 2

This time it DID match on the proper huntgroup.  Radiusd debugging 
confirms this, but for the sake of brevity I omitted it here.  This 
email is already long enough.  Is this a bug or am I clearly doing 
something wrong?  This behavior is not seen in freeradius-0.9.3.  It 
seems to surface after 1.x.  Prior to 1.x users file huntgroup matching 
happens perfectly regardless of order and quantity of huntgroups.

Any ideas?  Thanks in advance!

Chris Carver