On 4 Jun 2014, at 14:39, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
Greetings to all,
in our company (a big commercial telecom/ISP) we run a project to completely migrate our AAA infrastructure to FreeRADIUS (we use FreeRADIUS in parts of it for many years). One of our requirements in authentication/authorization is DSLAM port checking. The port info comes in NAS-Port-Id in our case and can be extracted in a normalized form with a regular expression. The problem was that FreeRADIUS provided in variables only the first 8 matching groups in %{0}..%{8}, whereas in our setup we needed up until %{12} to get the port information.
OK then 16 does make sense. Just for our edification could you provide an example of such a port string, and provide info on the BNG and L1 termination device (if different).
So I developed a relevant patch which I communicated through GitHub as a pull request (following procedure described in http://wiki.freeradius.org/contributing/GitHub).
FreeRADIUS v2.x.x is in feature freeze, and will not feature thaw. You're welcome to resubmit against v3.0.x.
The patch is against 2.X.X (tested with 2.2.5) and provides two functions:
- make available %{0}..%{16} in regex matches - make available a new xlat function tonumber() to translate strings as numbers
As I said in the GitHub ticket, I'm not sure this is needed. Even in v2.x.x you should be able to do update request { Tmp-Integer-0 := "%{<cap group number>}" } update request { Tmp-String-0 := "%{Tmp-Integer-0}" } and it'll strip any leading zeros. You could also define your own integer type attributes and use those to record the port string components. When the string is stored in the integer attribute the leading zeros should be stripped. I'm very much against duplicative behaviour unless there's a real benefit and I don't see a benefit here. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2