On 24/03/2023 09:46, Steven Walters wrote:
In the Access-Accept I set the Class attribute equal to reject which works fine in the case where we have our own BNGs. The value I set is the value I receive from the BNG in the Accounting-Start message.
Your BNGs aren't broken then, at least.
However, where we consume network services where we don't use our own BNG, the PPPoE gets proxied to us by the access provider's RADIUS. Whatever value we set in the Class they will encode to hex, add IXX and then encode to hex again.
Ugh. What were they thinking? That's hideous (as well as just plain broken).
Using the below I am trying to extract 0x72656a656374 from IXX0x72656a656374 which I write to Tmp-String-2 and then apply string to Tmp-String-3. However I end up with Tmp-String-3 = 0x72656a656374 but would like the original value (reject) I set in the Access-Accept message.
if ("%{string:Class}" =~ /(IXX)(0x[0-9a-f]{12})/) { update request { &Tmp-String-2 := "%{2}" &Tmp-String-3 := "%{string:Tmp-String-2}" } }
Try splitting the update in two - the inputs to each will be the state of the attributes before the update section was processed, so the second attribute assignment won't see the first. I seem to remember this behaviour does vary between some different versions of FR, so it's always safer to separate things in this case. So update request { &Tmp-String-2 := "%{2}" } update request { &Tmp-String-3 := "%{string:Tmp-String-2}" } (You also might need to use Tmp-Octets-xxx instead of Tmp-String-xxx, look at the debug output and find out what's happening.) If you're just using "reject" for everyone then you could of course just match the string they send back and be done with it. But of course you can do e.g. "reject-something" and extract the "something", which can be a lot more useful, in which case you do need to decode it. -- Matthew