
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><blockquote type="cite">Yes indeed, he refused to add it.<br>I our case I managed to overcome the problem by defining a slightly<br>different regex. It is true that the info I 'd like to extract is only 5<br>variables (fitting in the 8) but more groups can be needed in more<br>compicated expressions. In our case the original regex was<br><br>/.*_((HUA)|(ALU))_([[:digit:]]+)(.*)? ((atm)|(eth)) ([[:digit:]]+)\/([[:digit:]]+)\/([[:digit:]]+)\/([[:digit:]]+)(:)?.*/<br><br>and I reduced the groups with<br><br>/.*__([[:digit:]]+)(.*)? [atmeth]{3} 0?([[:digit:]]+)\/0?([[:digit:]]+)\/0?([[:digit:]]+)\/0?([[:digit:]]+)(:)?.*/)<br><br>Not exactly the same but fits our purposes fine.</blockquote><div><br></div><div><br></div><blockquote type="cite">[HUAALU]{3}</blockquote><div><br></div>That'll work, but it's pretty bad.<br><div><br></div><div><blockquote type="cite">((HUA)|(ALU))</blockquote><div><br></div><div>Inputting (ALU|HUA) on debuggex, you get:</div><div><br></div><img name="F6d_PXvs0Qut3cLn.png" apple-inline="yes" id="563A495A-ABB8-42A9-8326-5AD92C45A32E" height="83" width="146" apple-width="yes" apple-height="yes" src="cid:0BB22064-3DBA-44C7-B5A1-6E8C65E4FA36@sns.bskyb.corp"></div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><br></div><div>I can't remember if it's the same in extended regular expressions but for PCRE at least </div><div><br></div><div>(?:<expression>) makes expression an atom, but doesn't add the match to the capture groups.</div><div><br></div><div>'foo bar baz' =~ /([[:alnum:]]+) (?:[[:alnum:]]+) ([[:alnum:]]+)/</div><div><br></div><div>Would result in </div><div><br></div><div>%{0} -> 'foo bar baz'</div><div>%{1} -> 'foo'</div><div>%{2} -> 'baz'</div><div><br></div><div>So you don't waste the capture groups if you're not actually going to use the data.</div><div><br></div><div>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.</div><br><blockquote type="cite"><blockquote type="cite">It's the sort of thing that would be quite nice to define at build time <br>TBH. Instead of increasing it for everyone, as there is a performance <br>penalty.<br><br></blockquote><br>I think generally this is the way to go, have it configurable since<br>people can use it. Matching multiple times to reduce the number of<br>groups is at least "not elegant". Maybe you can have it in the v3.x.x<br>branch? <br></blockquote><div><br></div>Yes, i'll have a look.<div><br><blockquote type="cite"><blockquote type="cite"><br>Sure. I'm assuming that's because you don't have the facilities to properly<br>test your RADIUS service, and don't want to introduce changes where you <br>can't fully determine what the impact will be.<br><br></blockquote><br>We do have such facilities, however:<br><br>- we have a short timeframe for this project<br>- the project is generally very big (company wide) and involves large<br> changes in various layers<br>- we already operate FreeRADIUS v2.x.x for many years<br>- (rather important) the environment I work is REALLY conservative in<br> changes<br></blockquote><div><br></div>Yes, I know what ISPs can be like :)</div><div><br><blockquote type="cite">These are the reasons we will go with 2.x.x for now. We can revisit the<br>subject and upgrade in the future (I also need to catchup with 3.x.x).<br><br><blockquote type="cite"><br>Well the LDAP code doesn't suck, you'd probably get a marked performance <br>improvement just from using the new rlm_ldap module.<br><br>In general the policy language is more efficient, and there's a greater <br>number of validation checks on startup. It's generally a lot more <br>consistent with v2.x.x.<br></blockquote></blockquote><div><br></div>*than v2.x.x<br><br><div>Arran Cudbard-Bell <<a href="mailto:a.cudbardb@freeradius.org">a.cudbardb@freeradius.org</a>><br>FreeRADIUS Development Team<br><br>FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2<br></div><br></div></body></html>