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