[EXTERNAL] NSAPI changes Acct-Session-Id from upstream provider

[Gabriel Marais]

On Mon, Feb 24, 2025 at 2:53 PM Alan DeKok <aland at deployingradius.com> wrote:
>
> On Feb 24, 2025, at 7:01 AM, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> > Just in case, I have seen at least one instance where there is an Acct-Multi-Session-Id that is stable, and Acct-Session-Id is not.
>
>   That's actually required by RFC 2866 Section 5.11, which defines Acct-Multi-Session-Id :
>
>      This attribute is a unique Accounting ID to make it easy to link
>      together multiple related sessions in a log file. Each session
>      linked together would have a unique Acct-Session-Id but the same
>      Acct-Multi-Session-Id.
>
>   This behavior makes no sense to me.  What would be sane is having Acct-Session-ID as stable, so you have a common session identifier, even if Acct-Multi-Session-ID doesn't exist.

It would have made things a lot easier if Acct-Session-Id was the stable.
In this case, Acct-Multi-Session-Id makes sense, but we are not
getting that attribute in any of our radius packets which makes it
even harder to keep track of session data usage and creates even more
overhead on the amount of DB entries purely because now, we have no
way to link same session data together.

>
>   Instead, you have to check for Acct-Multi-Session-ID.  If it exists, it's the stable session identifier.  Otherwise, Acct-Session-ID is the stable session identifier.
>
>   And then I'm
>
> > Worth a check, you never know given how many manufacturers coders seem to have limited ability to read a standard and implement what it says.
>
>   I could forgive incompetence and inexperience.  What I find baffling is when there are clear intentions to ship idiotic code.
>
>   Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html