HI Alan In this case the data is from an upstream proxy (I am trying to edit one reply attribute from logins that are received from the proxy). This isn't data from a NAS. During the testing the upstream radius is another freeradius instance grabbing data from our SQL server. Moving forward it will be another radius server we don't control. However after reading a little more it seems the answer is to use if (&proxy-reply:Cisco-AVPair =~ /ip:route=([^ ]+) ([^ ]+)/) { Which now finds the data - and the rest of the example just works Thanks for the pointers Richard On Sunday 12/11/2017 at 1:07 pm, Alan DeKok wrote:

On Nov 12, 2017, at 6:16 AM, Richard J Palmer <richard@merula.net> wrote:

...

(1) if (&Cisco-AVPair =~ /ip:route=([^ ]+) ([^ ]+)/) { (1) ERROR: Failed retrieving values required to evaluate condition

That's because the incoming packet doesn't contain Cisco-AVPair.

Again... read the debug output. ALL of it. You'll see the server isn't receiving a Cisco-AVPair attribute from the NAS.

...

I am reasonably certain there is a issue somewhere with if (&Cisco-AVPair =~ /ip:route=([^ ]+) ([^ ]+)/)

Yes. You can only match a Cisco-AVPair against a regex... if the packet contains Cisco-AVPiar.

...

Using an online Regex testing tool and using the above as a basis I can see that Cisco-AVPair = \"ip:route=([^ ]+) ([^ ]+)\"

This retrieves the data I need - However that is not accepted by the freeradius config (understandably as it's not quote the same thing).

Really? The format of the configuration files is documented. See "man unlang".

There should be *no* surprise that random text isn't accepted by FreeRADIUS.

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html