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