FreeRADIUS 2.X.X small functionality extensions

[Arran Cudbard-Bell]

On 4 Jun 2014, at 17:08, Kostas Zorbadelos <kzorba at otenet.gr> wrote:

> 
> 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.

You can strip those out trivially in a regex...

Say you had /1/01/01/12

Your regex would be

/0?([0-9]+)/0?([0-9]+)/0?([0-9]+)/0?([0-9]+)

https://www.debuggex.com/r/sgPccw67Z_fviF9u

The optional 0s are consumed before the capture group data starts.

In the examples above there still only appears to be 5 bits of data being
pulled out.

For v2.x.x the 0 stripping stuff can be done in a bunch of ways without 
requiring extra code, so that's definitely not going to be added.

Alan has final on the number of capture groups and whether they'll be 
increased for v2.x.x. I suspect they won't be as it's in feature freeze.

It's the sort of thing that would be quite nice to define at build time 
TBH. Instead of increasing it for everyone, as there is a performance 
penalty.

> 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.

That's pretty small for an ISP TBH, but sure, throwing rlm_perl into the
mix is probably a bad idea, and the GIL hurts rlm_python's performance in
a multithreaded environment.

> 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.

Sure. I'm assuming that's because you don't have the facilities to properly
test your RADIUS service, and don't want to introduce changes where you 
can't fully determine what the impact will be.

> 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. 

Well the LDAP code doesn't suck, you'd probably get a marked performance 
improvement just from using the new rlm_ldap module.

In general the policy language is more efficient, and there's a greater 
number of validation checks on startup. It's generally a lot more 
consistent with v2.x.x.

But i'm not here to sell it to you. Upgrade when you want... or don't.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140604/f2a20076/attachment.pgp>