FreeRADIUS 2.X.X small functionality extensions

[Kostas Zorbadelos]

Hello,

let me be more specific to display the need.
We operate DSLAMs of various vendors (we have at least 3 now and noone
knows if that number will grow in the future).
The BRAS/BNG terminating devices send a NAS-Port-Id as in the following
examples: 

NAS-Port-Id -> Physical access ID (parsed form)
------------------------------------------------
(HUAWEI)
<#VOIOT_LEFKTRA_D_HUA_10261 atm 0/1/0/40:8.35%Up:975kbps Down:1582#> ->
10261:0/1/0/40
<#KYKLA_EMPORIO_D_HUA_9440 atm 0/12/0/54:8.35%Up:947kbps Down:4846#> ->
9440:0/2/0/54
<#THESS_KALAM_D_HUA_13115_ONU_9502 atm 0/2/0/7:8.35#> -> 13115:0/2/0/7
<#THESS_FINIK_D_HUA_9732_ONU_9543 atm 0/1/0/57:8.35%Up:1023kbps Do#> ->
9732:0/1/0/57
<#LAKON_ELAIA_D_HUA_10157_ONU atm 0/0/0/59:8.35%Up:1023kbps Down:1#> ->
10157:0/0/0/59
<#LASIT_MOCHLOS_D_HUA_14154_KV atm 0/0/0/37:8.35%Up:1023kbps Down:#> ->
14154:0/0/0/37
<#CHALK_PSAKOUDIA_D_HUA_14214_DLC atm 0/1/0/1:8.35%Up:511kbps Down#> ->
14214:0/1/0/1
<#KERKY_POTAM_D_HUA_9857_DLC_7073 atm 0/9/0/9:8.35%Up:1023kbps Dow#> ->
9857:0/9/0/9 

(ALCATEL)
<#KEFAL_ARGOSTOLI_D_ALU_13748_KV atm 1/1/01/47:8.35#2671024780> ->
13748:1/1/1/47
<#ACHAI_EGLYKADA_D_ALU_14296 eth 1/1/01/42:835#2610621234> ->
14296:1/1/1/42
<#ATTIC_PENTELI_D_ALU_13822_KV eth 1/1/01/12:835#> -> 13822:1/1/1/12
<#THESS_COSMO_D_ALU_14419_ONU_8523 atm 1/1/01/03:8.35#2310476377> ->
14419:1/1/1/3   
 
The parsed form is the string we want to extract and use it later
against an LDAP repository containing ports to verify the port status
and make decisions based on that. We have reached in a regex containing
more than 8 groups. Also, as you can see, some DSLAMs send initial zeroes
in front of numbers describing DSLAM port/slot.
Given the fact that our LDAP repo will contain the parsed forms I
describe could you provide an alternative config to express the desired
functionality? 
I know I can develop a specific module for the port parsing (have it
parse and store the value in a specific attribute of my choice) but I
found it more elegant to have a simple extension in the already provided
functionality of the core server. This will also allow me to have it in
config files (changing the expression as needed in the future). I also
think others can find it useful. 
Finally, I would rather not use rlm_perl or rlm_python (which would be my
choice). Performance in our environment is critical, we host more than
one million subscribers.
As I said I would not like to maintain seperate patches. I understand
the feature freeze of 2.x.x branch but we will not run 3.x in our
environment for now, we focus on stability. In my opinion, I do not find
it a "big" change or feature but of course I am not the "owner" or even
master of the sources so I cannot provide an authoritative judgement on
the matter. 

Thoughts, comments are welcome.

Regards,

Kostas