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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
