NSAPI changes Acct-Session-Id from upstream provider

[Conrad Classen]

Hi Alan

On 2025/02/24 15:00, Alan DeKok wrote:
> On Feb 24, 2025, at 5:14 AM, Conrad Classen<conrad.classen at gmail.com> wrote:
>> We have seen similar cases, and were able to use the IMEISV field to identify the devices on our APN's.
>    Were other attributes for the session stable?  i.e. NAS-IP-Address, NAS-Port, etc.  If so, that could help too.
>
>    Note that RFC 2866 doesn't say that the values of NAS-Identifier, etc. must be stable across all accounting packets for one session.  So yes, there are vendors who send different values.
The NAS-IP-ADDRESS did not change unless there were two or more GGSN's 
working together to accept requests for load balancing purposes. then 
the multiple sessions were established over all, which each having a 
different NAS-IP-ADDRESS


We had to eventually request that the additional GGSN's were removed so 
that we could dig deeper into what the issues were.

As usual, the ISP's are not very forth coming in accepting that the 
problems seen were partly due to their configurations.

I had to copy/paste the from the RFC's to them to show that they had 
things wrong.

>> It seems that there are some newer devices that attempt to build connections on top of a connection, even if it has not accepted the Access-Accept Response even though it was Authenticated.
>    <sigh>  I've updated the RADEXT Wiki with this information.
>
>> Further to this, we had to get the developers for the devices involved, because they were taking short-cuts to ensure connectivity as fast as possible instead of complying with the AAA standards.
>    For the future, please reach out to me via email.  I am more than happy to join any conversions via email, or even calls, no matter what the time / time zone.
>
>    These kind of issues cost me time and money.  They cost FreeRADIUS users time and money.  It's worth my time to join any conversation about broken NAS equipment, and then to pull rank on the vendor.
>
>    I've generally
>
>> On some devices, the number of connectivity attempts was 19 before the Radius had even responded with the Access-Accept, each with their own Session-Id to the same device.
>    I can't even imagine the situation where this would ever be a good idea.  The vendors are going out of their way to do extra work which is stupid, useless, and broken.
>
>    At this point, it looks like it's becoming necessary to update the RADIUS RFCs.  That is generally the only way to fight back against such vendor craziness.
>
>    Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html