NSAPI changes Acct-Session-Id from upstream provider

[Conrad Classen]

We have seen similar cases, and were able to use the IMEISV field to 
identify the devices on our APN's.

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.

The connectivity is too slow, and it is being dropped, more specifically 
to Ericsson APN systems. We had to ensure that the APN was enforcing 
"Simultaneous-Use = 1"  and that the Session Timeout did not exceed 1 day.

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.

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.

Most of these devices had modems made in China, but not all.


On 2025/02/24 09:05, Gabriel Marais wrote:
> Hi Guys
>
> This might be off topic but I was wondering if someone with more
> knowledge than me, would be able to confirm the following :-
>
> In a mobile network scenario with thousands of IoT devices
>
> On our radius servers, we've been noticing a lot of 0-byte sessions on
> our databases and upon investigation, we've seen the following
> behaviour :-
>
>> Authentication Request Received
> < Access Accept sent back
>> Accounting Start Packet Received with a Acct-Session-Id
> < Acknowledgement sent back
>> Interim Accounting Packet Received - This time with a different Acct-Session-Id for the same connection
> ** At this point, things start going bad as we are not able to update
> the original DB entry created with the Acct Start Packet, since the
> Acct-Session-Id differs between the packet received in the Accounting
> Start Packet and the Interim Accounting Packet.
>
> This results in a 0-session entry in the DB for the Accounting Start
> Packet entry as a new entry is written into the DB based on the new
> Acct-Session-Id received in the Interim Accounting packet.
>
> Any subsequent packets received with a different Acct-Session-Id,
> results in writing a new DB entry when the Interim Accounting Packet
> is received.
>
> We queried this with the upstream provider, and they advised that the
> 3GPP-NSAPI number changes when packets are received and they claim
> that the Acct-Session-Id on their side would change based on the
> 3GPP-NSAPI value that could (and in most cases) changes.
>
> < Acknowledgement Sent back
>
>  From what I've been reading, The Acct-Session-Id should remain
> constant for the entire PDP context/session, even when the NSAPI
> changes because the Acct-Session-Id is meant to uniquely identify the
> entire user session. NSAPI changes are considered sub-sessions within
> the main PDP context and keeping the same Acct-Session-Id helps
> maintain session continuity for billing and tracking purposes, which
> is exactly our use case for accounting which is not working as
> expected.
>
> Any thoughts and insights would be appreciated if someone faced a
> similar situation.
>
>
> Many thanks, Gabriel
> -
> List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html