Yes indeed, he refused to add it.
I our case I managed to overcome the problem by defining a slightly
different regex. It is true that the info I 'd like to extract is only 5
variables (fitting in the 8) but more groups can be needed in more
compicated expressions. In our case the original regex was

/.*_((HUA)|(ALU))_([[:digit:]]+)(.*)? ((atm)|(eth)) ([[:digit:]]+)\/([[:digit:]]+)\/([[:digit:]]+)\/([[:digit:]]+)(:)?.*/

and I reduced the groups with

/.*__([[:digit:]]+)(.*)? [atmeth]{3} 0?([[:digit:]]+)\/0?([[:digit:]]+)\/0?([[:digit:]]+)\/0?([[:digit:]]+)(:)?.*/)

Not exactly the same but fits our purposes fine.

[HUAALU]{3}

That'll work, but it's pretty bad.

((HUA)|(ALU))

Inputting (ALU|HUA) on debuggex, you get:

Meaning HUA and ALU count as atoms for the alternation. In fact (HUA|ALU) is exactly the same thing as ((HUA)|(ALU)) but uses two fewer capture groups.

I can't remember if it's the same in extended regular expressions but for PCRE at least

(?:<expression>) makes expression an atom, but doesn't add the match to the capture groups.

'foo bar baz' =~ /([[:alnum:]]+) (?:[[:alnum:]]+) ([[:alnum:]]+)/

Would result in

%{0} -> 'foo bar baz'

%{1} -> 'foo'

%{2} -> 'baz'

So you don't waste the capture groups if you're not actually going to use the data.

Try it with extended regular expressions and see if it works. If it doesn't the only way to fix it would be upgrade to v3.0.x and build with PCRE unfortunately.

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.

I think generally this is the way to go, have it configurable since
people can use it. Matching multiple times to reduce the number of
groups is at least "not elegant". Maybe you can have it in the v3.x.x
branch?

Yes, i'll have a look.

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.

We do have such facilities, however:

- we have a short timeframe for this project
- the project is generally very big (company wide) and involves large
changes in various layers
- we already operate FreeRADIUS v2.x.x for many years
- (rather important) the environment I work is REALLY conservative in
changes

Yes, I know what ISPs can be like :)

These are the reasons we will go with 2.x.x for now. We can revisit the
subject and upgrade in the future (I also need to catchup with 3.x.x).

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.

*than v2.x.x

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

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