Auth failed accounts and write to SQL database
Alan DeKok
aland at deployingradius.com
Fri Mar 24 12:36:05 UTC 2023
On Mar 24, 2023, at 5:46 AM, Steven Walters <steven.walters1 at gmail.com> wrote:
> 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.
That has to be one of the stupidest things I've ever seen.
I could understand them wanting to know which sessions are associated with what network. So it makes a certain amount of sense to mangle the Class attribute before it's sent to the NAS.
But it's fundamentally idiotic to *not* mangle the Class attribute back before sending it to you.
> For example, if I set Class = reject, I receive:
>
> 0x4958583078373236353661363536333734
>
> When I do string:Class I get:
>
> IXX0x72656a656374
>
> Using a calculator, if I convert 0x72656a656374 from hex to string I get
> the value reject.
>
> 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.
The simplest thing is:
if (&Class == 0x4958583078373236353661363536333734) {
update request {
&Class := "reject"
}
}
:)
Alan DeKok.
More information about the Freeradius-Users
mailing list